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
_______________________________________________
Talk-transit mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-transit
