[Tagging] Superroutes - good, bad or ugly?

seirra blake sophietheopossum at yandex.com
Fri Mar 15 17:01:46 UTC 2019

oh the idea is that [G] has type=route, but no route=* because it may be 
used in any form of route (with some 'common sense' of course); route 
does not apply until [C] so route=road would not get reused. there is 
actually a small error, [D/E] is the same and stays exclusively within 
public transport. unless you actively map an island I would hope you are 
joking. in case you weren't the context is that someone made a whole 
fake settlement on an actual island so it would render on the main page 
and someone had to revert a whole load of changesets. I can't imagine 
much friction from the local community if I make an example relation 
alongside the current one and add a note that until further notice 
although based on real data it's a proof of concept though. I'll reply 
to my own email and add a slightly more updated version (just of the 
example) addressing some of this, just to make sure it's clear what I 
meant. if you feel an example would help somewhat I'll make one too; it 
could be useful to see how renderers handle it now. let me know if you'd 
like a 'physical' example.

On 3/15/19 3:00 PM, Jo wrote:
> Good analysis Seirra,
> I would not "reuse" route=road in other route=* relations though. 
> route=bicycle might share segments with route=foot/walking/hiking, but 
> I'd keep everything related to bus/trolley_bus and coach together in 
> terms of sharing of subroutes not mix it with other route types.
> For public transport the biggest benefit will be ease of maintenance.
> The way I see it route=bus relation should describe a single variation 
> in itinerary, and thus include all the stops for that variation. So in 
> my view the subroutes only contain ways.
> I would create subroutes for each direction of travel, so no 
> forward/backward roles need to become involved. If the subroute would 
> only contain a single way, a subroute relation probably wasn't needed.
> Paul Allen, I did read your objections to this, but that bus route is 
> wildly exceptional, whereas buses travelling along 'corridors', 
> reusing the same roads as the rest of the lines is very common (as 
> that is where the stops are, obviously).
> Maybe I should try to create an example somewhere. Preferably a small 
> island....
> Polyglot
> On Fri, Mar 15, 2019 at 3:38 PM seirra blake 
> <sophietheopossum at yandex.com <mailto:sophietheopossum at yandex.com>> wrote:
>     I can see *a lot* of shared routes in my area because most of the
>     buses heavily use a star topography (everything must take you to a
>     central station) as opposed to a hybrid mesh/star topography
>     (everywhere has access to a service to a central station, but
>     there are circular routes to allow quicker travel in some
>     circumstances). for example my local service has one incredibly
>     early train station detour (presumably for long distance
>     commuters), the two main routes (incoming/outgoing) and a route
>     that stops at the bus depot. all 4 of these routes share a large
>     part of it and that's just one route number! such route segments
>     could help shrink and simplify maintaining the relations a lot.
>     for example if there's a detour due to roadworks, you don't have
>     to edit the very large number of relations individually, (our bus
>     station has around 20 bays, each taking multiple services...) just
>     the shared child relations. I don't think we need a  specially
>     labelled super route relation, but perhaps we do need a way to
>     tell the data user that a segment is shared. these are the
>     problems I see:
>      1. where do the tags go?
>      2. do you need a separate one for each direction?
>      3. is type=super_route or similar the best idea?
>      4. how far can they nest?
>      5. a shared route is being used for public transport, should the
>         stop positions and bus stops be included with all the ways?
>     so... what do we do? this is what I see as a solution:
>      1. if a route is shared, tags should be minimal and only related
>         to the physical route itself perhaps not even including the
>         usual route tag (AFAIK wouldn't just about any route relation
>         in existence define the route tag? so this would just be
>         another pointer to the software that this isn't your regular
>         route. but maybe it still is best to tag it, in which case....
>         maybe route=shared?), rather than things such as what bus
>         routes it is part or anything, this can easily be seen simply
>         by looking at parent relations
>      2. maybe use the roles forward/backward? I don't think these are
>         used for much any more
>      3. what do we gain? I think this can more easily be solved by
>         simply adding another tag such as shared=yes which can tell
>         the software that there are route relations that are intended
>         to be treated as just one big way. see below for a more
>         detailed explanation.
>      4. I don't see a reason to limit the nesting, I imagine in most
>         use cases, the benefit of sharing duplicate relation data
>         probably outweighs any impact from processing nesting
>      5. if a shared route is used for both a numbered road route and
>         public transport it's probably unfair on the road user that
>         doesn't need them if they are included. also this would make
>         it difficult to work out where to place it in a public
>         transport V2 relation.. as they have stops at the top, ways at
>         the bottom but this has both!
>     so here's an indented, somewhat simplified example of how it
>     roughly would nest based on the idea of a public transport route,
>     a cycle route and a road relation that share the same set of ways
>     (_underlined_=can be shared in parent nesting level, *bold*=can be
>     shared in nesting levels outside of the parent one, italic=the
>     level at which main tagging should occur. for easier referencing
>     each equivalent level of nesting has been assigned a letter):
>     _______________________________________________________________________________
>     /bus network///[A]/
>     /
>         /route_master=bus /[B]
>             /route variant/ [C]
>                 _*route segments*_ [D]
>                     _combined bus stop/way relation suitable for
>                     public transport v2_ [E]
>                         _shared bus stop relation_ [F]_
>                         _
>                         _*shared way relation*_ [G]
>     /road network///[A]/
>     /
>         /road /[C]
>                 _*shared way relation*_ [G]*
>                 *
>     /cycle network//**/[A]/*
>     */
>         /cycle route /[C]
>             __
>                 __
>                 *_shared way relation_* [G]
>     _____________________________________________________________________________
>     potential new tags that may be required:
>     [C]: shared=yes (defaults to no)
>     [E/F/G]: route=shared (this is questionable in terms of benefits
>     though)
>     _____________________________________________________________________________
>     notes:
>     [G] may be infinitely nested as required to prevent duplicate sets
>     of ways (although this should rarely be required)
>     as you can see, this allows a lot of the data to be shared between
>     the various types of relations, whilst also allowing current
>     relation structure to remain the same, this is just an extra
>     higher level of detail, where required. due to the way public
>     transport relations are handled it may be required to even have
>     every segment in [D] contained in a relation, however as cycle and
>     road relations are purely made up of ways they may not need the
>     same kind of treatment and be able to mix items from [G] with
>     directly referenced ways. the separation of bus stop and way data
>     allows public transport relations to still correctly identify the
>     different bus stops in each direction but not have to duplicate
>     the way data. the naming of parts is solved, as this can be
>     applied to [G] level relations. the use of [G] and [C] would help
>     solve where routes need to be split up to keep maintenance
>     possible. [E], [F] and [G] theoretically shouldn't need to be
>     tagged as the fact they include any child relations at all should
>     be enough to indicate what they are, however if not route=shared
>     would certainly make it obvious. I hope this theory on how we
>     could solve it was helpful, if any further clarification is
>     required or there's a notable mistake/error please let me know and
>     I'll try to respond as best as I can to that. I have thought about
>     perhaps making an example of this, if it would help please let me
>     know.
>     **
>     On 3/15/19 12:07 PM, marc marc wrote:
>>     Le 15.03.19 à 12:27, Hufkratzer a écrit :
>>>     is that a good/sufficient reason to define a new relation type?
>>     imho nearly no routing tools (nor foot nor bus) is currently able
>>     to use a relation type=route with relations as child.
>>     so that's a good reason to create/improve a doc if superrelation is
>>     needed for ex for routing (of course maybe some mapper need superroute
>>     only for the fun of having a relation that collect all other).
>>     for ex how a "data user" can detect "it 's a superroute" <> "it's 2
>>     route with a shared segment" ?
>>     for the moment, the trick is to notice that the name of the main
>>     relationship is close to the name of the children's relationships
>>     and to know that the names of all these children's relationships
>>     are fake names (which should therefore be removed/corrected).
>>     there is for ex nothing called "European long distance path E4 - part
>>     France". it's an artificial name to descript how the relation is splited
>>     maybe the tag network should be the same and/or the name (the country
>>     XYZ may move the a scope tag)
>>     the main relation must/should/mustn't/shouldn't have all/some same tag
>>     as the child ?
>>     all/a lot of child tag must move to the main relation only ? (that's
>>     what we do with MP : we don't duplicate alls tags to way + relation)
>>     etc...
>>     _______________________________________________
>>     Tagging mailing list
>>     Tagging at openstreetmap.org  <mailto:Tagging at openstreetmap.org>
>>     https://lists.openstreetmap.org/listinfo/tagging
>     _______________________________________________
>     Tagging mailing list
>     Tagging at openstreetmap.org <mailto:Tagging at openstreetmap.org>
>     https://lists.openstreetmap.org/listinfo/tagging
> _______________________________________________
> 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/20190315/d9500f67/attachment-0001.html>

More information about the Tagging mailing list