[Tagging] Feature Proposal - RFC - Public Transport v3

Phake Nick c933103 at gmail.com
Mon Mar 9 13:43:56 UTC 2020

At 2020-03-09 Mon 16:04, John Doe <music.kashish at gmail.com>  wrote:

> Hey, thanks for sharing your views 🙂
> 07-Mar-2020 03:01:41 Phake Nick :
> > [...] for such renderer to work, access restriction for public transit
> vehicle need to be complete, which is rather difficult not just because of
> the work it take or the current incompleteness of the amount of keys in OSM
> that can be used to represent multiple localized types of transportation,
> but also because of things like mechanical restrictions of bus models that
> would not be available in any public document and cannot be verified
> outside of the public transit company.
> I feel that this information can largely be approximated from road
> classifications. PT Assistant already complains if a bus route is using a
> road lower than a certain classification. As and when turn restriction data
> is added, routers can adapt the route automatically.

It is not the question of grade but it is related to turn diameter and
obstacles and emission regulation and such on different roads, and they
differ according to specific bus models used by each routes.

> > [...] how can editors know when it is necessary to add a waypoint to
> show a route correctly?
> I think it will always need mapper testing, as it already does. But PTv3
> does remove a lot of moving parts, and makes creation and maintenance of
> routes easier.

In PTv2 one can simply select all the ways and then add them into relation,
unlike this proposal where I woild need to try and see where I needs to add
waypoint, and identify if there are any way that can be rendered
differently on different renderer despite it might coincidentally appear as
expected on editor's software.

> > If a new road is being built next to existing road which doesn't affect
> existing public transit routes, how to preemptively make sure routing
> engines won't automatically redirected a route to the new road?
> In this case, since the platforms being served haven't changed, I think
> you'll find that
> 1. The likelihood of the route changing is very low. Even hail and ride
> routes shouldn't be likely to change much, since the via points used to
> define them would probably keep the routers on track.
> 2. Even if it does change, the platforms are the same and the router is
> still preferring the fastest path between them - users are unlikely to be
> greatly affected. At worst, accuracy of ETAs could be affected.

1. Yes, the chance of route changes are very low, and that's why I ask how
to fixate a route against such changes which would affect how routing
engines route a route.
2. As I have mentioned previously, my greatest use of PT mapping is the
geometry of the routes. So even if stops are the same that'd still affect
my intended use of those routes.

> What I have in mind is the case of Delhi's NH9, in which a road was
> changed from two to four carriageways. In such a situation, with the
> constraint of the existing stops, routers would have to ignore the new
> inner carriageways and stick to the outer carriageways, which is exactly
> what happened on the ground 😄 If you have some other examples in mind, it
> would help us all to discuss their specifics.

For example, routes like route E11 in Hong Kong which continues to
use Cheung Tsing Tunnel instead of Nam Wan Tunnel after the latter finish

> > Third, way points are more transient than ways. It's more easy for a
> node to be deleted or replaced when editing geometry than ways. How to
> maintain integrity of a route geometry when others edit road geometry?
> To verify this, I tried deleting a stop position which was part of a route
> relation. Both JOSM and Vespucci warn you about the relation, and ask for
> confirmation. iD does not, but fortunately someone's already made an issue
> about it and they're considering it -
> https://github.com/openstreetmap/iD/issues/5846
> I've added FAQ entries for all these, thanks for the feedback! I hope I'm
> able to address your concerns about our proposal.
> _______________________________________________
> 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/20200309/8c580978/attachment-0001.htm>

More information about the Tagging mailing list