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 <sophietheopos...@yandex.com <mailto:sophietheopos...@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@openstreetmap.org  <mailto:Tagging@openstreetmap.org>
    https://lists.openstreetmap.org/listinfo/tagging
    _______________________________________________
    Tagging mailing list
    Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
    https://lists.openstreetmap.org/listinfo/tagging


_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Reply via email to