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

[Stephen Sprunk]

On 2016-06-20 03:33, Jo wrote:
> I've been looking around and I see two main divergent "factions".
> 
> Basically the differences stem from how bus stops were mapped before
> v2 came along. Are the stop_position nodes the bus stop, or is it that
> place next to the road where the passengers wait. For those places
> where the latter is considered the way to go, I see nodes with
> ...
> The other faction is in some regions of Germany and some regions of
> France. I don't see it in many other places.
> ...
> 
> Needless to say I prefer the first way of tagging,

That's what my reading of the wiki page says to do; I don't get how 
someone would think the second way conforms to the scheme, and as you 
note, it has practical problems.

 From what I can tell, the "stops" in a GTFS feed match platforms (or 
poles) or sometimes entire stations but never the stop positions.  OTOH, 
the points in a GTFS shape are probably supposed to match the stop 
positions.

> even though those platform nodes often represent the pole with the flag
> on it, but let's not muddy the waters by introducing a 
> public_transport=pole.
> Nodes with public_transport=platform work just fine for the purpose.

Agreed.  There is a slight ambiguity vs a real platform that isn't fully 
mapped yet, but I don't think renderers (or other consumers) would care 
about that.

> Now if the details are mapped on those nodes next to the way, then I
> fail to see why one would need to add the stop_position nodes over and
> over to the route relations (also keep in mind they are not
> necessarily always mapped in the first scenario).

I puzzled over that for quite a while myself.

The best I've come up with so far is that it allows validating that all 
of the stop positions are on the ways, and it helps render maps 
correctly when giving directions to get on/off at an intermediate stop.  
At first, I thought it was needed when a single platform serves multiple 
stop positions, but I think you could figure that out easily from the 
ways.  There's still a problem where you have multiple stop positions on 
the same way served by the same platform, but I suspect in such cases 
the platform should be chopped up* to one per stop position.

One problem I've run into, perhaps unique to rail, is where to _put_ the 
stop positions; I've been putting them beside the center of the 
platform, but that probably isn't accurate.  In reality, the entire way 
segment adjacent to the platform is the stop position, which has the 
added benefit of moving the stop position into the way list rather than 
being separate.  (IMHO, even if the stop position is a node, that should 
be allowed if it's a node that joins the preceding and following ways, 
without being considered a gap.)

* Incidentally, is there an easy way in JOSM to split a single area for 
cases like this?  It already has a function to join two areas with a 
shared wall, so you'd think adding a way through the middle of an area 
would allow you to un-join it, but not that I've found...

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