[Tagging] Feature Proposal - RFC - Public Transport v3

Alan Mackie aamackie at gmail.com
Tue Mar 10 09:37:13 UTC 2020

On Tue, 10 Mar 2020 at 07:55, John Doe <music.kashish at gmail.com> wrote:

> > A new housing estate with two connections to the existing road system
> could cause the bus to be re-routed.
> Sounds a little odd - would a router really route a bus on a
> highway=residential or highway=service?

I should hope so, many bus stops are on residential roads.

> But, be that as it may, your response helped me see two things -
> 1. It will be helpful to have a route visualizer in editors that can
> preempt ambiguities.
> 2. Hail and ride routes longer than last-mile services really do suffer
> under this schema.
> > Which is fine if they're alternative ways of mapping bus routes. But the
> proposers seem to want to make this the one and only way of doing things.
> I reiterate that I initially wanted it to be just that - an additional way
> to map. But I also don't want to see it go the way of PTv2, where some
> consumers still don't support the new schema even after 8 years of being
> asked to. And I definitely don't want ways in routes where there's no need
> for them, but someone decides to add them 'for completeness' (for instance,
> so many appear to have difficulty in comprehending that stop positions in
> PTv2 are optional 🤦♀️), oblivious to the maintenance issues.

If you think that "after 8 years" people have serious misunderstandings
about PTv2 and "difficulty in comprehending" it, then please improve the
documentation on the wiki. The burden in written communication does not lie
solely on the reader.

Whenever I have tried to use PTv2 'in anger' I have found the wiki
confusing and seriously lacking in a summary page. The page that comes
closest to an overview for the buses seems to be the generic buses
<https://wiki.openstreetmap.org/wiki/Buses> page, but even it has
diversions into clicking certain buttons and "dragged and dropped" objects
(In what editor?) and seems quite rambly. I think the authors suspect the
meaning isn't getting through from their frequent use of bold phrases, but
this doesn't seem to have helped with readability. It also takes the
unusual step of saying that the PTv1 roles are "invalid"  rather than
'depreciated' as tends to be the phrasing when tagging styles move on which
seems deliberately inflammatory given that from the responses here v2 is
still somewhat controversial.

The main route=bus page implies that ALL roles are equally optional
although presumably you have to have some instances of something or you end
up with an empty relation. If anything this page has the opposite problem
to the buses page, it is brief enough that it might serve as a reminder to
those already familiar with the schemes, but provides little to no
clarification for those that aren't.

Which gives me the following idea - would it help you if only routes with
> hail_and_ride=yes were permitted to have ways? For selective hail and ride,
> we can use the via roles as currently written in the proposal. That lets
> you use ways where they are most important (longer, completely hail and
> ride routes), and keeps them out of where they're a nuisance.
> (Routes with hail_and_ride=yes could still opt to omit ways and use
> points, which would be better for shorter routes.)
This seems reasonable, but explicitly banning ways seems to be a serious
break in backward compatibility. In that cases I would suggest dropping the
PTv3 moniker and referring to this as an abbreviated or condensed route
relation. PT-zip, simPT? If the original idea was to be a simplification
of  PTv2 tagging then this might not be a bad idea anyway.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20200310/f6b63255/attachment.htm>

More information about the Tagging mailing list