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.
OTOH, this doesn't seem like a huge problem if we're importing the data from elsewhere using automated tools and only tweaking by hand where it's wrong--and ideally, there should be some sort of feedback mechanism to get the source corrected so even that's a short-term problem.
I'm interested in GTFS because it gives us a wealth of data from hundreds of transit agencies around the world. It's not perfect, of course, but I think better tools would solve a lot of the disagreements over the tagging scheme and its complexity.
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.
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.
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.
And: how to tell apart services that run a few times per day from those that have a headway of a few minutes?
That's starting down a slippery slope to including full schedule data.
Given that, it would help have an algorithm to answer the simple questions for real world examples and their current tagging: - Where to start/end routing of passengers?
Isn't that what the current scheme is all about?
- Where to start/end routing of vehicles?
Do our consumers really care about that? Do we need to include "deadhead" trips to/from service facilities or cases where one vehicle switches from one route to another at a given stop? The latter is in GTFS, but I'm not sure I'd want that in a map.
- How to obtain a name of a station?
How is this complicated?
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.
S -- Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov _______________________________________________ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
