[Tagging] Superroutes - good, bad or ugly?

[seirra blake]

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
> https://lists.openstreetmap.org/listinfo/tagging
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20190315/45dbd0b2/attachment.html>