<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>key: <i>almost all tagging should occur here</i> | <u>data may
be reused in parent</u> | <b>data may be reused in parent and
any 'adjacent' (with the same letter) parent</b><br>
</p>
<p><em>public transport network</em><em> </em>[A]</p>
<blockquote>
<p><em>route_master=public transport </em>[B]</p>
</blockquote>
<blockquote>
<blockquote>
<p><em>route variant</em> [C]</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<blockquote><u>combined stop/way relation suitable for public
transport v2</u> [E]</blockquote>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<blockquote>
<blockquote><u><strong>shared way relation</strong></u> [G]</blockquote>
</blockquote>
</blockquote>
</blockquote>
<em>road network</em><em> </em>[A]
<blockquote><em>road </em>[C]</blockquote>
<blockquote>
<blockquote>
<blockquote>
<p><u><strong>shared way relation</strong></u> [G]</p>
</blockquote>
</blockquote>
</blockquote>
<p><br>
<em>cycle network</em><em><strong> </strong></em>[A]</p>
<blockquote><em>cycle route </em>[C]</blockquote>
<blockquote>
<blockquote>
<blockquote>
<p><strong><u>shared way relation</u></strong> [G]</p>
</blockquote>
</blockquote>
</blockquote>
<p>_____________________________________________________________________________</p>
<p>potential new use of tags that may be required:</p>
<p>[E/G]: type=route + route=part</p>
<p>_____________________________________________________________________________</p>
<p>notes:</p>
<ul>
<li>[G] may be infinitely nested as required to prevent duplicate
sets of ways (although this should rarely be required)</li>
<li>[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)</li>
<li>[G] should almost always not be used for a single way unless
it will assist in maintainability. if a</li>
<li>I don't believe route_master=public transport actually exists,
but the same concept should work for any public transport</li>
<li>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</li>
<li>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.</li>
<li>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</li>
<li>I may consider adding a rough idea on perceived pros/cons,
depending on demand</li>
<li>I may add a more visual version, depending on demand</li>
<li>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)</li>
</ul>
<p>_____________________________________________________________________________</p>
<p>changelog:</p>
<p>#2</p>
<ul>
<li>fix mistake in key</li>
<li>add missing formatting to key</li>
<li>remove redundant reference to [F]</li>
<li>specify when example should be live</li>
<li>update potentially needed tags following discussion</li>
<li>remove mention of shared=yes, this does not need to be used in
the newest version</li>
<li>reorder changelog so it's newest first</li>
</ul>
<p>#1</p>
<ul>
<li>removed [D] and [F]. [D] was meant to be removed prior to
sending, [F] is not required.</li>
<li>added a few more notes so it may be referred to on its own</li>
<li>the bus example applies to any public transport really, adjust
language accordingly</li>
<li>warned against damaging existing relations' usability/the
creation of fictional data</li>
<li>added extra details on a request if needed basis</li>
<li>added this changelog and relevant versioning to help people
keep track. this should be traceable to the (unlabelled) version
0</li>
</ul>
<p>#0</p>
<ul>
<li>initial concept</li>
</ul>
<p>special thanks:</p>
<ul>
<li>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)</li>
</ul>
<div class="moz-cite-prefix">On 3/15/19 5:54 PM, seirra blake wrote:<br>
</div>
<blockquote type="cite"
cite="mid:cfb97a5f-9381-8df8-50ce-1aa8f8bf068e@yandex.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>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<br>
</p>
<p><i>public transport network</i><i> </i>[A]<i><br>
</i></p>
<blockquote>
<p><i>route_master=public transport </i>[B]<br>
</p>
</blockquote>
<blockquote>
<blockquote>
<p><i>route variant</i> [C]<br>
</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<blockquote><u>combined stop/way relation suitable for public
transport v2</u> [E]<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<blockquote> </blockquote>
<blockquote>
<blockquote><u><b>shared way relation</b></u> [G]<br>
</blockquote>
<blockquote> <br>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<i>road network</i><i> </i>[A]<i><br>
</i>
<blockquote><i>road </i>[C]<br>
</blockquote>
<blockquote>
<blockquote>
<blockquote>
<p><u><b>shared way relation</b></u> [G]<b><br>
</b></p>
</blockquote>
</blockquote>
</blockquote>
<p><br>
<i>cycle network</i><i><b> </b></i>[A]<i><b><br>
</b></i></p>
<blockquote><i>cycle route </i>[C]<br>
</blockquote>
<blockquote>
<blockquote> <u> </u>
<blockquote><u> </u>
<p><b><u>shared way relation</u></b> [G]</p>
</blockquote>
</blockquote>
</blockquote>
<p>_____________________________________________________________________________</p>
<p>potential new tags that may be required:</p>
<p>[C]: shared=yes (to tell the software there is use of shared
ways, but the software probably should be able to work that out)</p>
<p>[E/F/G]: route=shared (this is considered in case type=route
explicitly requires a route=* key)</p>
<p>_____________________________________________________________________________</p>
<p>notes:</p>
<ul>
<li>[G] may be infinitely nested as required to prevent
duplicate sets of ways (although this should rarely be
required)</li>
<li>[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)</li>
<li>[G] should almost always not be used for a single way unless
it will assist in maintainability. if a <br>
</li>
<li>I don't believe route_master=public transport actually
exists, but the same concept should work for any public
transport</li>
<li>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</li>
<li>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.</li>
<li>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 <br>
</li>
<li>I may consider adding a rough idea on perceived pros/cons,
depending on demand</li>
<li>I may add a more visual version, depending on demand<br>
</li>
<li>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)<br>
</li>
</ul>
<p>_____________________________________________________________________________</p>
<p>changelog:</p>
<p>#0</p>
<ul>
<li>initial concept</li>
</ul>
<p>#1<br>
</p>
<ul>
<li>removed [D] and [F]. [D] was meant to be removed prior to
sending, [F] is not required.</li>
<li>added a few more notes so it may be referred to on its own</li>
<li>the bus example applies to any public transport really,
adjust language accordingly</li>
<li>warned against damaging existing relations' usability/the
creation of fictional data</li>
<li>added extra details on a request if needed basis</li>
<li>added this changelog and relevant versioning to help people
keep track. this should be traceable to the (unlabelled)
version 0<br>
</li>
</ul>
<p>special thanks:</p>
<ul>
<li>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)<br>
</li>
</ul>
<div class="moz-cite-prefix">On 3/15/19 2:37 PM, seirra blake
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:fe23ed6b-c061-f097-6135-5058c54a9c5d@yandex.com">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<p>I can see <b>a lot</b> 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:</p>
<ol>
<li>where do the tags go?</li>
<li>do you need a separate one for each direction?</li>
<li>is type=super_route or similar the best idea?</li>
<li>how far can they nest?</li>
<li>a shared route is being used for public transport, should
the stop positions and bus stops be included with all the
ways?<br>
</li>
</ol>
<p>so... what do we do? this is what I see as a solution:</p>
<ol>
<li>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</li>
<li>maybe use the roles forward/backward? I don't think these
are used for much any more<br>
</li>
<li>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.<br>
</li>
<li>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</li>
<li>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!</li>
</ol>
<p>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 (<u>underlined</u>=can be shared in parent nesting
level, <b>bold</b>=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):</p>
<p>_______________________________________________________________________________<br>
</p>
<p><i>bus network</i><i> </i>[A]<i><br>
</i></p>
<blockquote>
<p><i>route_master=bus </i>[B]<br>
</p>
</blockquote>
<blockquote>
<blockquote>
<p><i>route variant</i> [C]<br>
</p>
</blockquote>
<blockquote>
<blockquote><u><b>route segments</b></u> [D]<br>
<blockquote><u>combined bus stop/way relation suitable for
public transport v2</u> [E]<br>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<blockquote><u>shared bus stop relation</u> [F]<u><br>
</u></blockquote>
</blockquote>
<blockquote>
<blockquote><u><b>shared way relation</b></u> [G]<br>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<i>road network</i><i> </i>[A]<i><br>
</i>
<blockquote><i>road </i>[C]<br>
</blockquote>
<blockquote>
<blockquote>
<blockquote>
<p><u><b>shared way relation</b></u> [G]<b><br>
</b></p>
</blockquote>
</blockquote>
</blockquote>
<p><br>
<i>cycle network</i><i><b> </b></i>[A]<i><b><br>
</b></i></p>
<blockquote><i>cycle route </i>[C]<br>
</blockquote>
<blockquote>
<blockquote> <u> </u>
<blockquote><u> </u>
<p><b><u>shared way relation</u></b> [G]</p>
</blockquote>
</blockquote>
</blockquote>
<p>_____________________________________________________________________________</p>
<p>potential new tags that may be required:</p>
<p>[C]: shared=yes (defaults to no)</p>
<p>[E/F/G]: route=shared (this is questionable in terms of
benefits though)</p>
<p>_____________________________________________________________________________</p>
<p>notes:</p>
<p>[G] may be infinitely nested as required to prevent duplicate
sets of ways (although this should rarely be required)<br>
</p>
<p>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.<br>
<b> </b></p>
<blockquote>
<blockquote>
<blockquote> </blockquote>
</blockquote>
</blockquote>
<div class="moz-cite-prefix">On 3/15/19 12:07 PM, marc marc
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:DB6P190MB0279E7C4A8E651B6048541B1B7440@DB6P190MB0279.EURP190.PROD.OUTLOOK.COM">
<pre class="moz-quote-pre" wrap="">Le 15.03.19 à 12:27, Hufkratzer a écrit :
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">is that a good/sufficient reason to define a new relation type?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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
<a class="moz-txt-link-abbreviated" href="mailto:Tagging@openstreetmap.org" moz-do-not-send="true">Tagging@openstreetmap.org</a>
<a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/tagging" moz-do-not-send="true">https://lists.openstreetmap.org/listinfo/tagging</a>
</pre>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Tagging mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Tagging@openstreetmap.org" moz-do-not-send="true">Tagging@openstreetmap.org</a>
<a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/tagging" moz-do-not-send="true">https://lists.openstreetmap.org/listinfo/tagging</a>
</pre>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Tagging mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Tagging@openstreetmap.org">Tagging@openstreetmap.org</a>
<a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/tagging">https://lists.openstreetmap.org/listinfo/tagging</a>
</pre>
</blockquote>
</body>
</html>