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