[Tagging] Superroutes - good, bad or ugly?

Paul Allen pla16021 at gmail.com
Wed Mar 13 23:29:36 UTC 2019

On Wed, 13 Mar 2019 at 22:42, Jo <winfixit at gmail.com> wrote:

> I think we should move to subrelations for bus routes at some point.
> Actually doing it is somewhat tricky. We'd definitely need editor support
> to show that a route which consists of subroutes is continuous or not.

Not a big problem.  Not compared with sorting the route I just had to sort
(again).  Dunno if I messed
up last time I sorted it or what, but it's a major pain.  Maybe I need a
different JOSM plugin, but I
already find JOSM confusing enough.

One problem I found with JOSM was zooming to a way in the relation when
that way appears more
than once.  I did that a lot so I could check the next way in the route was
even in the table or
had to be added.  But if a way appears more than once in a route (as
several do in the one
I was working on) then JOSM moves to the first occurrence of it in the
table of ways, rather than
the one I just selected.

If I could use a superroute then I would choose the subroutes so that no
way appears twice
in a subroute.  That's a problem with circulars that non-circulars don't
have (most of the time
a non-circular has two variants A->B and B->A and although most of the ways
are common to
both they're separate relations).  A truly circular wouldn't have that
problem either, but this one
has loops and repeats and side-branches that aren't loops.

> The biggest point of contention seems to be whether the stops should go
> into the subroute relations as well. I'd say no. Keep the stop sequences
> for a particular variation in itinerary together in a route relation per
> variation. And only use the subroutes to collect continuous sequences of
> ways.
> At the same time, some people would think it's more logical to have a
> sequence of ways, then a stop, then the next sequence, a stop, and so on.
> For that too, it would be nice to have editor support that shows that the
> way before and the way after actually connects, or not.

That's the other problem I have.  A stop which isn't a stop the first time
the bus passes along
a way but is a stop the second time.  Although the ordering of stops does
mean it's possible to
figure out if you inspect the relation closely, it's not obvious.  Allowing
stops to intersperse the
ways would make it slightly easier to figure out.  But using a superroute
makes it very clear:
it's not a stop on segment 1 but it is a stop on segment 2.  So I'd
definitely want stops on the
subroutes not the superroute.  I think it makes more sense that way
anyway.  It keeps the
stops with the associated ways.

If we go the way of subroutes for PT routes, I/we can probably coerce a
> GSoC student to create support for it in PT_Assistant over the summer.

All the tools I need to make life a LOT easier by splitting the route into
subroutes are there.
Breaking the route up manually is relatively simple (takes several steps
and some time, but
very little thought), and after that it just gets far, far easier to deal
with short segments than
one big, looping, wandering route.  If I choose the subroutes wisely I can
even let JOSM sort
them for me (it gets very confused with this route where several ways are
traversed more than

There are only three things stopping me doing that right now:

1) What the response to my post was.  So far nobody has said that it's a
really bad idea since
I posted details of the route.  Unless there are many howls of outrage,
I'll assume it's not
an outrageously bad idea.

2) How to differentiate between the different segments.  I can't use from
and to because those are
supposed to be terminal destinations (preferably as shown on the bus
itself).  So I need a new
tag (or two).  I could get by with something like segment="A to B",
segment="B to C" etc.  But
there's probably a better way of doing it.  And I'd like to do that both
for human readability when
mapping and to allow umap a way of distinguishing between subroutes with an

3) What else I haven't thought of.  What's show-stopper might turn up after
I've spent time
splitting the route.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20190313/e18c6187/attachment.html>

More information about the Tagging mailing list