[Tagging] Feature Proposal - RFC - Public Transport v3

[Paul Allen]

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
because
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
router
using algorithms that could change and weighting factors that could change,
it
seems impossible to guarantee even a close approximation to canonical
routes,
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
renderer
shows.

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
map
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
then
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
route,
but have to live with the fact that those are said to be hard to map with
existing
schemes.


> 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
different
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
existing
road, or something else changes that causes the router to decide on a
different
route.

>
> (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
actually
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
route.
  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
passes
through C.  Am I on the wrong bus?  Has the route changed and, if so, does
it
still stop at E?  From my perspective, having the wrong (non-canonical)
route
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
between
them: one shorter and one faster.  One who has supreme confidence that a
router
is going to guess right.

Here's a thought for you, since editors would have to build in a routeing
module
for verifiability.  Don't adopt this new proposal.  Instead, come up with
editor
modules that can be fed a series of stops and vias, propose a route
connecting
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.

-- 
Paul


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