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

[Stephen Sprunk]

On 2016-06-20 16:18, Paul Johnson wrote:
> On Mon, Jun 20, 2016 at 2:02 PM, Stephen Sprunk <stephen at sprunk.org>
> 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.

Same here and many other cities I've looked, so I didn't think it was 
that big of a deal.

> 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.

*facepalm*

I have plenty of complaints about the transit agencies where I live, but 
at least they manage to post signs properly and provide proper 
maps/schedules.  Their GTFS data isn't as accurate as I'd hoped, but 
it's obvious they're _trying_ to get it right.

>> 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).

Really?  I've looked at a couple dozen feeds for major US and European 
cities, and they seem to be reasonably complete and accurate.  Then 
again, all of the ones I've looked at so far are ones that offer rail 
services, and the nature of rail implies a high enough level of funding 
that one can probably take things like a decent GTFS feed for granted.  
A small, bus-only agency can run on a shoestring budget where such 
things may be seen as "unnecessary" or "too much effort".

> The situation with GTFS data itself is so bad that Google stopped
> offering Navigation for the transit mode in it's own Maps service.

It's still available where I live and several other major cities I 
checked, so perhaps they just disabled it in your area because they 
recognized the GTFS data there was so bad?

>>> 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.
>> 
>> ...
> 
> 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.

Unfortunately, that could create problems if navigation tools think that 
a person has to walk to the center of the platform to actually board the 
train, whereas trains often run the full length of the platform but are 
often shorter (or even longer!) than the platform.

Worse, some trains only allow boarding for mobility impaired persons at 
certain points along the platform, and they may not be able to make it 
from the center to that location within the dwell time.

Worse still, a short train may not even be _present_ at the center of 
the platform if it's short and stops at one end or the other.  While 
improbable, in theory that could lead a vision-impaired person to walk 
off the platform and fall onto the tracks.

I'm not sure what the solution is, though, so I've been putting the stop 
positions at the center of the platform until someone tells me better.  
FWIW, that seems to be what folks in other cities have done--if they 
mapped any stop positions at all.

>>> 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.
> 
> 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.

It's always baffled me that so many agencies are willing to give the 
same designation to different routes just because they share several 
stops.  IMHO, it'd be better to give each variant a suffix so they can 
be easily identified (e.g. route 1A vs route 1B, rather than route 1 to 
Wherever and route 1 to Elsewhere; references without a suffix could 
still refer to the common section.  Worse, what appears to be the same 
route can often be different variants depending on the time of day.  My 
local agency has several routes where route A stops at certain places in 
the off-hours but skips those stops during peak hours when route B 
serves those stops instead--and route B doesn't go to all the _other_ 
places that route A does.

Part of the reason we _need_ transit navigation apps (and reliable 
route/schedule data to feed into them) is to hide this sort of 
complexity from users.

>>> - 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.

Oh, sorry.  I was assuming a decent GTFS feed, where every stop should 
have an official name, even if it's only cross-streets (typical for bus 
stops).  I thought the question was where to put that it in OSM and/or 
where renderers should look for it.

One of the challenges I've run into is whether to name every part of a 
stop area; if I do, platform or stop position names often get rendered 
_instead of_ the station name, but if I don't, it's really hard to 
maintain all the relations because all the elements of a given type look 
the same, plus navigators can't direct pedestrians to the right 
platforms.

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