[Talk-transit] GTFS, tools and pt tags generally

Stephen Sprunk stephen at sprunk.org
Mon Jun 20 19:02:23 UTC 2016


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



More information about the Talk-transit mailing list