[Tagging] Superroutes - good, bad or ugly?

Peter Elderson pelderson at gmail.com
Fri Mar 15 20:29:32 UTC 2019


Looks good.

Vr gr Peter Elderson


Op vr 15 mrt. 2019 om 21:05 schreef seirra blake <
sophietheopossum at yandex.com>:

> key: *almost all tagging should occur here* | *data may be reused in
> parent* | *data may be reused in parent and any 'adjacent' (with the same
> letter) parent*
>
> *public transport network* [A]
>
> *route_master=public transport *[B]
>
> *route variant* [C]
>
> *combined stop/way relation suitable for public transport v2* [E]
>
> *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 use of tags that may be required:
>
> [E/G]: type=route + route=part
>
>
> _____________________________________________________________________________
>
> notes:
>
>    - [G] may be infinitely nested as required to prevent duplicate sets
>    of ways (although this should rarely be required)
>    - [G] may require names in some cases and should always require
>    type=route, but should include no other tags unless it very specifically
>    relates to only the members of the relation and can't be included in any
>    parent relation (unicorns are probably more common)
>    - [G] should almost always not be used for a single way unless it will
>    assist in maintainability. if a
>    - I don't believe route_master=public transport actually exists, but
>    the same concept should work for any public transport
>    - the route=* tag should not be required until you move up to [C],
>    shared way relations and bus stop relations should be open to any route
>    type to increase re-usability
>    - as they are just a connected line of ways, shared way relations
>    should be usable in either direction, the direction to use could be
>    specified via a role. although reusable for routes going in the same
>    direction, [E] will rarely be reusable for both directions of a route
>    because it contains both platforms and stops, and platforms usually differ
>    depending on direction.
>    - if this becomes accepted it may become a good idea to specify a
>    members limit for relations (at which point it should be split up). such
>    ways should probably
>    - I may consider adding a rough idea on perceived pros/cons, depending
>    on demand
>    - I may add a more visual version, depending on demand
>    - example will be coming with version 4 (if you wish to add your own
>    as well, or an inspired version please base it heavily on reality if it is
>    on main OSM. do not make any existing route relations unusable)
>
>
> _____________________________________________________________________________
>
> changelog:
>
> #2
>
>    - fix mistake in key
>    - add missing formatting to key
>    - remove redundant reference to [F]
>    - specify when example should be live
>    - update potentially needed tags following discussion
>    - remove mention of shared=yes, this does not need to be used in the
>    newest version
>    - reorder changelog so it's newest first
>
> #1
>
>    - removed [D] and [F]. [D] was meant to be removed prior to sending,
>    [F] is not required.
>    - added a few more notes so it may be referred to on its own
>    - the bus example applies to any public transport really, adjust
>    language accordingly
>    - warned against damaging existing relations' usability/the creation
>    of fictional data
>    - added extra details on a request if needed basis
>    - added this changelog and relevant versioning to help people keep
>    track. this should be traceable to the (unlabelled) version 0
>
> #0
>
>    - initial concept
>
> special thanks:
>
>    - you may request your name here and optionally credits for ideas you
>    contributed (being kept in an opt in basis in case people don't want their
>    names shown)
>
> On 3/15/19 5:54 PM, seirra blake wrote:
>
> key: almost tagging should occur here | data may be reused in parent |
> data may be reused in parent and any 'adjacent' (with the same letter)
> parent
>
> *public transport network* [A]
>
> *route_master=public transport *[B]
>
> *route variant* [C]
>
> *combined stop/way relation suitable for public transport v2* [E]
>
> *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 (to tell the software there is use of shared ways, but the
> software probably should be able to work that out)
>
> [E/F/G]: route=shared (this is considered in case type=route explicitly
> requires a route=* key)
>
>
> _____________________________________________________________________________
>
> notes:
>
>    - [G] may be infinitely nested as required to prevent duplicate sets
>    of ways (although this should rarely be required)
>    - [G] may require names in some cases and should always require
>    type=route, but should include no other tags unless it very specifically
>    relates to only the members of the relation and can't be included in any
>    parent relation (unicorns are probably more common)
>    - [G] should almost always not be used for a single way unless it will
>    assist in maintainability. if a
>    - I don't believe route_master=public transport actually exists, but
>    the same concept should work for any public transport
>    - the route=* tag should not be required until you move up to [C],
>    shared way relations and bus stop relations should be open to any route
>    type to increase re-usability
>    - as they are just a connected line of ways, shared way relations
>    should be usable in either direction, the direction to use could be
>    specified via a role. although reusable for routes going in the same
>    direction, [E] will rarely be reusable for both directions of a route
>    because it contains both platforms and stops, and platforms usually differ
>    depending on direction.
>    - if this becomes accepted it may become a good idea to specify a
>    members limit for relations (at which point it should be split up). such
>    ways should probably
>    - I may consider adding a rough idea on perceived pros/cons, depending
>    on demand
>    - I may add a more visual version, depending on demand
>    - I may add an actual example, depending on demand (if you wish to add
>    your own as well, or an inspired version please base it heavily on reality
>    if it is on main OSM. do not make any existing route relations unusable)
>
>
> _____________________________________________________________________________
>
> changelog:
>
> #0
>
>    - initial concept
>
> #1
>
>    - removed [D] and [F]. [D] was meant to be removed prior to sending,
>    [F] is not required.
>    - added a few more notes so it may be referred to on its own
>    - the bus example applies to any public transport really, adjust
>    language accordingly
>    - warned against damaging existing relations' usability/the creation
>    of fictional data
>    - added extra details on a request if needed basis
>    - added this changelog and relevant versioning to help people keep
>    track. this should be traceable to the (unlabelled) version 0
>
> special thanks:
>
>    - you may request your name here and optionally credits for ideas you
>    contributed (being kept in an opt in basis in case people don't want their
>    names shown)
>
> On 3/15/19 2:37 PM, seirra blake 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 listTagging at openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>
>
> _______________________________________________
> Tagging mailing listTagging at openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>
>
> _______________________________________________
> Tagging mailing listTagging at openstreetmap.orghttps://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/1d82f1f4/attachment-0001.html>


More information about the Tagging mailing list