[Tagging] Feature Proposal - RFC - Public Transport v3

Paul Allen pla16021 at gmail.com
Tue Mar 10 14:24:06 UTC 2020

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

> >
> > Given that iD still seems to scramble sorted routes in some
> circumstances, one should not assume that editors will correctly handle any
> changes we make. I might be being unfair to iD here, I didn't check the
> route was still sorted before I added a spur, so maybe somebody else doing
> something that didn't directly affect the route using another editor
> scrambled it.
> >
> Could you please try to replicate that and report it to the iD developers?
> Sounds like a pretty serious bug, if it is that.

To replicate it I'd have to remove the spur, then sort the route (very,
very slow
and tedious) then add the spur back.  And then get nowhere because I appear
to be on the iD developer ignore list (I know others are on such a list
iD developers proudly stated it).  It was only a year or two ago that iD
developers stated that it was impossible to keep the order of ways in a
relation when retrieving it from the server, at a time when JOSM had no
problem doing so.  Now iD protects route relations if you try to break the
relation and doesn't scramble them as much as it used to.  Maybe in
another couple of years...

> While many others have, in the process of this proposal, questioned the
> need to map exact routes at all (given the presence of platforms), I have
> always wanted to map canonical routes as closely as I can.

The fact that this scheme relies upon the decisions made by an arbitrary
using algorithms that could change and weighting factors that could change,
seems impossible to guarantee even a close approximation to canonical
even with plentiful vias.

> 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?

As somebody else mentioned, bus routes in towns deliberately pass through
residential areas along highway=residential.  I think a problem here is
that you're
more familiar with long-distance routes than urban routes.  What makes sense
for long-distance routes doesn't make much sense for urban routes.

> 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.

Yeah, but the editor will need its own router (not a trivial addition)
which will
almost certainly differ in the algorithm and weightings from the router
used by the
renderer.  It's likely that what the editor shows will not be what the

2. Hail and ride routes longer than last-mile services really do suffer
> under this schema.

Urban routes suffer under this scheme, whether hail and ride or not.  It's
just that
not having the canonical route when there are hail and ride sections is a
serious problem.  Being on an urban bus that isn't following the route the
says it does is not as serious, but still a problem.

> > 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.

I'll support the scheme if it is an alternative way to map.  I probably
won't use it
as the few longer routes around this mostly rural county are mainly hail
and ride
outside the downs and often hail and ride within the towns.  If it is
proposed as
a replacement scheme I'll have to vote against it.

Which gives me the following idea - would it help you if only routes with
> hail_and_ride=yes were permitted to have ways?

Nope.  Because that is still undesirable for urban routes in general.  If I
get on a
bus for the first time and compare where it is to the route shown on a map
I get seriously worried if the two do not match and start wondering if I'm
on the
wrong bus.  Actually, I'd be just as worried if I were on a long-distance
but have to live with the fact that those are said to be hard to map with

> 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.

For urban routes, vias ARE the nuisance.  Because you force me to think like
a router.  In fact, not just one router but several routers, each using
algorithms and weightings.  I have to anticipate where any of those routers
MIGHT get it wrong and insert vias to prevent that.  Until somebody adds a
housing estate with a through road, or the speed limit changes on an
road, or something else changes that causes the router to decide on a

> (Routes with hail_and_ride=yes could still opt to omit ways and use
> points, which would be better for shorter routes.)

Nope.  Points aren't (in my opinion) better for short routes.  Ways are
easier for me to add (it's slow, and tedious, but I don't have to think
like a router
and anticipate where things might go wrong if I don't insert a via).

> 1. "long-distance [interstate?], few official stops, only stops at
> official stops" - this proposal doesn't merely 'work' for them, it is
> absolutely essential for them - one only has to try creating a route
> relation for a national train to know why 😄 I agree with you that
> passengers in those situations don't care about the intricacies of the
> route as long as the stops are being served and the ETAs are more or less
> accurate.

Actually, some passengers DO care about the intricacies of a long-distance
  If the map shows a route from a stop at A to a stop at E, passing through
(but not
stopping at) B then I get damned worried if the bus avoids B and instead
through C.  Am I on the wrong bus?  Has the route changed and, if so, does
still stop at E?  From my perspective, having the wrong (non-canonical)
on a map is worse than not having the route on the map.

2. This also works well for "intra-city, many official stops, only stop at
> official stops". The stops are so frequent that you probably won't need to
> add any via points in most cases.

That sounds like the confident opinion of somebody who has never mapped
such a
route.  One who has never encountered two towns which have two routes
them: one shorter and one faster.  One who has supreme confidence that a
is going to guess right.

Here's a thought for you, since editors would have to build in a routeing
for verifiability.  Don't adopt this new proposal.  Instead, come up with
modules that can be fed a series of stops and vias, propose a route
them and, if the mapper agrees, automatically add all the necessary ways to
a PTV2 relation.  In some cases ways would need to be split (as is the case
now) but the editor could flag up a "This route cannot be defined unless a
split is placed here" error.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20200310/5e77cd73/attachment.htm>

More information about the Tagging mailing list