<div dir="ltr">When I start mapping a bus line, I have several route relations which contain all the stops for each variation in itinerary.<div><br></div><div>When I add the ways, it would be nice to reuse subroute relations for the parts where ways are shared between lines.</div><div><br></div><div>When I come back later and I want to compare whether the number of variations for a line is still the same, I want to compare against sequences of stops in the route relations, hence the reason why I would not add the stops to the subroute segments. (Compare against data from the operator or GTFS)</div><div><br></div><div>We also have 'express' lines that skip stops. if the stops are put in the subroute relations, then they can not be reused for those lines.</div><div><br></div><div>As far as I'm concerned, the sequence of stops is the 'signature' defining each variation in itinerary.</div><div><br></div><div>Polyglot</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 15, 2019 at 6:55 PM seirra blake <<a href="mailto:sophietheopossum@yandex.com">sophietheopossum@yandex.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<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>
<i></i></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="gmail-m_-482497287326138301moz-cite-prefix">On 3/15/19 2:37 PM, seirra blake wrote:<br>
</div>
<blockquote type="cite">
<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="gmail-m_-482497287326138301moz-cite-prefix">On 3/15/19 12:07 PM, marc marc wrote:<br>
</div>
<blockquote type="cite">
<pre class="gmail-m_-482497287326138301moz-quote-pre">Le 15.03.19 à 12:27, Hufkratzer a écrit :
</pre>
<blockquote type="cite">
<pre class="gmail-m_-482497287326138301moz-quote-pre">is that a good/sufficient reason to define a new relation type?
</pre>
</blockquote>
<pre class="gmail-m_-482497287326138301moz-quote-pre">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="gmail-m_-482497287326138301moz-txt-link-abbreviated" href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a>
<a class="gmail-m_-482497287326138301moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/tagging" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a>
</pre>
</blockquote>
<br>
<fieldset class="gmail-m_-482497287326138301mimeAttachmentHeader"></fieldset>
<pre class="gmail-m_-482497287326138301moz-quote-pre">_______________________________________________
Tagging mailing list
<a class="gmail-m_-482497287326138301moz-txt-link-abbreviated" href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a>
<a class="gmail-m_-482497287326138301moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/tagging" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
Tagging mailing list<br>
<a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
</blockquote></div>