[Tagging] Feature Proposal - RFC - Public Transport v3

Jo winfixit at gmail.com
Wed Mar 11 12:12:03 UTC 2020

That stop_position nodes became optional is probably because of my
influence. In the beginning they were definitely part of how PTv2. I
disliked this very much because all of a sudden we were using 2 objects to
define a single stop, duplicating details, which seemed like a very bad
idea. And it was.

About the stops, I would have all the details on a single node,
highway=bus_stop, railway=tram_stop next to the road where the passengers
wait. If there is a physical platform, I would add a way highway=platform,
railway=platform. This way would only have tags describing the attributes
of the platform like wheelchair and tactile_paving.

Only the  highway=bus_stop, railway=tram, which has the details like name,
ref, etc would be a member in the route relations.

I think it's good that we are discussing how to map PT in a reasonable way.
My take on all this, is that I would prefer to 'simplify' it by adding
another layer of subrelations in between.

This would definitely make it easier to reroute several bus itineraries in
one go. Or fix several by making a single intervention.

It would not be clear anymore which buses use which ways directly, but that
would be the effect of the current proposal as well.

Anyway, the reason why I am not making an official proposal for years now,
even though I'm telling myself I should is that

1. it would be very hard to get it to pass
2. even if it passes, it may not be adopted in some places


PS: I saw PT_Assistant mentioned a few times. I'm glad it's being used. If
it doesn't work like you expect, let me know, maybe we can improve it.
Also, not all validator warnings are of the same importance. If your bus
travels against a oneway restriction, or the route is interrupted, it would
be good to fix that. If it complains about first or last way not matching
with first or last stop, it may be that the stops aren't ordered correctly.
If it complains about the first or last way isn't split near the stop,
that's not crucially important, I'd say.

On Wed, Mar 11, 2020 at 12:46 PM Peter Elderson <pelderson at gmail.com> wrote:

> I get the impression that consensus and general adoption will not be
> reached during my lifetime.
> Good luck with it, I'm out!
> Vr gr Peter Elderson
> Op wo 11 mrt. 2020 om 12:13 schreef alan_gr <alangrant72 at gmail.com>:
>> John Doe wrote
>> > I don't understand why the critics of PTv2 seem to think stop positions
>> > are such a big deal - they are optional!
>> My memory of starting to map bus stops a few years ago is that it wasn't
>> clear from the documentation that stop positions are optional. I certainly
>> formed the impressions that they were required, and came to regret
>> spending
>> so much time mapping both stop positions and platforms. At that time I
>> think
>> the main reference for how to map using PTv2 was the proposal page itself,
>> now archived at https://wiki.openstreetmap.org/w/index.php?oldid=625726.
>> That doesn't indicate that stop_position is optional (see "the Schema in
>> short", where stop_area is explicitly described as optional, but
>> stop_position is not).
>> It seems other wiki pages have since been edited to make this optionality
>> clearer. I notice that they also refer to adding bus=yes etc to platforms
>> representing bus stops, which was not part of the PTv2 proposal, but I
>> guess
>> tries to deal with one of the issues that led people to prefer
>> highway=bus_stop.
>> Bringing this closer to the original topic ... if the proposal for PTv3 is
>> "PTv2 with some exceptions", is there a single coherent reference for what
>> is meant by "PTv2"?
>> --
>> Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html
>> _______________________________________________
>> Tagging mailing list
>> Tagging at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20200311/fab9a3cb/attachment.htm>

More information about the Tagging mailing list