On Mon, Jun 20, 2016 at 2:02 PM, Stephen Sprunk <[email protected]> wrote:
> On 2016-06-20 02:07, Roland Olbricht wrote: > >> There had been a group that was very vocal for making a textbook >> example of design by committee, and the result is now known as >> "approved public transport scheme". They did not ask for input from >> experienced mappers or developers. I decided to consider it a waste of >> time and stopped developing. >> > > I wasn't around at the time, so I can't speak to how it happened, but the > result seems to be a partial implementation of Transmodel, which > distinguishes a _lot_ of different things (and the complex relationships > between them) in excruciating detail because the real world is, in fact, > that complicated. > > If one is putting data in by hand, it certainly seems unwieldy. It took > me over a week to do just a few rail routes in my area, and I'm still not > completely sure I got them right. I can't imagine trying to do the > hundreds of bus routes too. > I really wonder how TriMet ultimately accomplished this, since that would seem like a decent-ish starting point since that system is in charge of a fairly multimodal system with above and below ground stations, split-level stations, and transit centers of almost every description. One thing that breaks things badly for me in the Tulsa area is the vast overwhelming majority of stops in the Tulsa Transit (and presumably other transit systems in the region) GTFS have...literally zero indication on the ground, there's no way to tell if there is an actual bus stop (which is typically just a signpost with a bus stop sign on it), and if it is, whether or not that's verifiable because the sign's gone missing. Or the more likely case with mass transit in the southern midwest, no amenities whatsoever are provided, you just need to know the bus runs on that street and stand about a bus length after the downstream side of an intersection that doesn't have a signposted stop and flag down the driver to catch the bus (likewise, you have to be unusually precise at pulling the stop cord as the driver will automatically assume immediately after the next intersection, regardless of how minor). Worse, there's a large number of duplicates with more than one stopID for the same stop position (this is a GTFS data issue, Tulsa Transit's feed is a hot mess to start with), and there's a significant portion (perhaps to the point of "almost all") major transfer points that fall into the category of totally unsigned stops, and another rash of locations that have no GTFS entry but are considered to be valid, totally unposted bus stops. My completely shitty answer to this problem right now is to map only signposted stops I've verified. I have no idea how many there actually are, nor do I have any reason to believe that Tulsa Transit has any clue how many there are in actuality either. I'm also a big fan of the V1 tagging scheme as it's substantially easier to deal with. On the ground mapping should become easier with time as Tulsa Transit's starting to get more funding (Finally!), though focus right now is on getting more safe vehicles on the road more frequently, longer hours and to more places (currently any trip requiring more than one transfer, or even a particularly long trip involving no transfers and only one possible route, is a major test of patience, as it's annoyingly common for a scheduled bus to be cancelled completely without warning due to lack of usable equipment that has things like an intact floor that hasn't rusted out to the street below). I would hope that the GTFS feed improves as ridership increases and stops get signposted, but I'm really not counting on the GTFS improving or bus stops to get maintained, much less posted more formally than someone scratching something like MTTA 3421 on a handy streetlamp or telephone pole at unposted stops frequented by people who figured out the stop ID for that location independently to look up when the next bus arrives via text message... > Also, like it or not, Google Maps (and hence GTFS) has set a bar for what > users expect from online maps. I'd certainly like OSM to be better, of > course, but the current situation is that OSM is generally far, far worse. It doesn't help that the only implementations of GTFS that actually are anywhere near complete are basically the reference implementations Google did in cooperation with TriMet and Tillamook County Transit, and adjacent systems that asked TriMet how they did that (like Clark County Transit, aka C-Tran). The situation with GTFS data itself is so bad that Google stopped offering Navigation for the transit mode in it's own Maps service. Which was actually a pretty slick thing, and I actually used it a lot for the last few months that feature was even available, since if your route suddenly became impossible to make a transfer because of a delay or the GTFS Live feed indicated there was a problem, it would *automatically reroute you* to an actually viable service. This was fantastic since the whole reason I ended up stranded in Portland in the first place was I got laid off during a service call and had to find my own way back to Oklahoma, and my car was in the shop. So temping often meant 3-5 transfer trips across three counties in two states on two different transit systems at varying hours and locations; when this feature stopped being a thing, getting around my hometown by transit became "plan the trip up front, and if anything goes wrong, replan the trip midway through" and "pray to God nothing happens to the C105 or 62 bus routes" as I simply wasn't familiar with alternative options for either of those routes. I'm not the only one. Tagging never really got traction, and only a >> tiny fraction of stops conforms to that approach. This is why we have >> now the mess we have. >> >> One example is the dissent on whether the bus stop should be a node on >> the vehicle's way or a node where the passengers wait. You will find >> all solutions implemented, because each local community decided >> different. The "approved scheme" will allow any variant. It's even >> worse for where to put the name: I got even within local communities >> incompatible answers, all referring to the "approved scheme". >> > > I think it's fairer to say that the approved scheme allows either or > both--using different tags, so you know which you are dealing with. IMHO, > that's an improvement over folks using the same tags for two different > things. > > Unfortunately, GTFS _doesn't_ help solve this particular problem. Worse, > each agency seems to have their own idea of what a "stop" or "station" is, > so local mappers might have to tweak things--and the tools would need to > respect those tweaks during future imports. I'm a proponent of it being the location where passengers wait for bus service, and the center of the position the train stops for rail halts, for what it's worth. I don't know what makes the most sense for data consumers, which would help significantly. Then would need to get JOSM on board with not barfing on routes that contain the same member multiple times in the same relation, another frequent issue I have with Tulsa Transit routes, particularly at the Denver Avenue Station where the station layout and the street grid can necessitate going in circles repeatedly to get to the correct bus platform and the correct exit (ignoring that some drivers Do Not Care and will pull into a more convenient (for them) bay anyway if the station's not busy). Or for out and back legs where a route will turn off it's ostensibly named-for street to go a mile out of the way, turn around in a parking lot, come back up the other side of the same street, and then turn back onto it's named-for street to continue. JOSM actively fights you in both cases, and god help you if you click "sort route"... Another example are route relations. While there are wild >> constructions called route_master and network which are basically >> collection relations, the problem that bothers most people in practice >> has never been tackled: We would like to see per way segment only one >> or very few relations and need a construction to assemble itineraries >> from that. That would greatly reduce maintenance. >> > > I'll admit I was a bit annoyed at having to duplicate way data for several > routes where some trips run A-B-C-D, some A-B-C and some B-C-D; it would > have been handy to create segments A-B, B-C and C-D, and then just include > the right ones in each route. But then I realized my real complaint was > that I had to do this _at all_ when there's a GTFS feed that has _all_ of > that information and could easily be used to create/update all the > relations. If it's automated, only developers should have to care how > complicated or repetitive it is; the important thing is that individual > mappers don't, at least in the general case. > > In my day job, our goal for most process is to automate 90% of "easy" > things because automating the last 10% would cost more than handling them > manually does. I think we can aim higher than that here, at least after > the first pass, but I suspect that mappers who are doing 100% of one thing > today aren't likely to complain about doing 10% of two things instead > tomorrow. Hadn't learned of Route Master before, but this frustration with some routes not going full length or having optional loops or changed route based on time of day or whether or not it's snowing without changing the route name or number actually hit me as one of those, "are you actually kidding me?" kind of moments with Tulsa Transit. There's one route that has something like six or eight different relations because of this. > - How to obtain a name of a station? >> > > How is this complicated? A lot of cities name stops without signposting the name, often in the form of "The Street The Route Is On at The Cross Street We're Stopping At", such as "South Memorial Drive at East 56th Street" or some similar pattern. > It's not enough if the solution works fine in your local area and >> hopefully works somewhere else, more or less untested. We need an >> algorithm to do the right thing in 95% or better 99% of all places >> around the world. >> > > Of course. Transmodel tries to be right 100% of the time, but that means > ridiculous complexity; GTFS isn't right quite as often, but it seems to be > good enough for the vast majority of places and with a lot less complexity. Assuming the agency actually uses it correctly. Which is almost certainly not the case.
_______________________________________________ Talk-transit mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-transit
