<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>yeah roughly so. in terms of mapping, no. as relations are on
somewhat of a 'meta' level though, I considered it mostly due to
the fact people seem to feel some sort of tag is needed. I
(personally) wondered whether the use of type=route would require
the use of a route tag no matter what (or I guess... should we
just use a new type=shared? people seemed to preferably not want
an entire new relation type though). but yeah the idea is
essentially that the shared segments may be used in place of the
identical set of ways independent of whatever the route wants to
use them for. as it defeats the purpose for public transport
somewhat if the bus stops/stop positions are still defined
uniquely for each route the idea is that you can also make shared
relations for those. the original idea was that you have a
relation connecting two separate bus stop and way relations but
after some thought... bus stops are always (unless there's a very
extreme earthquake maybe? but I think if it's strong enough to
physically switch bus stops we have more important things to worry
about) attached to the same ways. I will upload a slightly updated
version, just bear with me while I make sure I've checked all my
emails and update it. I will reply to myself with it<br>
</p>
<div class="moz-cite-prefix">On 3/15/19 3:22 PM, Peter Elderson
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAKf=P+v7DCSgLVCBQuAwVOQ6fuskMvkpGK7SLkjsFkfj9LsyqQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr"><br clear="all">
<div>
<div class="gmail_signature" data-smartmail="gmail_signature">This
seems to boil down to: You can put any sequence of connected
ways in a package (shared route segment) and use that
package in any route to replace these ways themselves. </div>
<div class="gmail_signature" data-smartmail="gmail_signature"><br>
</div>
<div class="gmail_signature" data-smartmail="gmail_signature">You
would need to allow all types of route relations to contain
ways and shared segment relations. </div>
<div dir="ltr" class="gmail_signature"
data-smartmail="gmail_signature"><br>
</div>
<div class="gmail_signature" data-smartmail="gmail_signature">I'm
not sure if you would need any special tag to indicate it's
shared. If it's used more than once, it's shared, right?</div>
<div dir="ltr" class="gmail_signature"
data-smartmail="gmail_signature"><br>
</div>
<div dir="ltr" class="gmail_signature"
data-smartmail="gmail_signature">Fr gr Peter Elderson</div>
</div>
<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Op vr 15 mrt. 2019 om 15:38
schreef seirra blake <<a
href="mailto:sophietheopossum@yandex.com"
moz-do-not-send="true">sophietheopossum@yandex.com</a>>:<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>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_-1536052313249312353moz-cite-prefix">On
3/15/19 12:07 PM, marc marc wrote:<br>
</div>
<blockquote type="cite">
<pre class="gmail-m_-1536052313249312353moz-quote-pre">Le 15.03.19 à 12:27, Hufkratzer a écrit :
</pre>
<blockquote type="cite">
<pre class="gmail-m_-1536052313249312353moz-quote-pre">is that a good/sufficient reason to define a new relation type?
</pre>
</blockquote>
<pre class="gmail-m_-1536052313249312353moz-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_-1536052313249312353moz-txt-link-abbreviated" href="mailto:Tagging@openstreetmap.org" target="_blank" moz-do-not-send="true">Tagging@openstreetmap.org</a>
<a class="gmail-m_-1536052313249312353moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/tagging" target="_blank" moz-do-not-send="true">https://lists.openstreetmap.org/listinfo/tagging</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
Tagging mailing list<br>
<a href="mailto:Tagging@openstreetmap.org" target="_blank"
moz-do-not-send="true">Tagging@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/tagging"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.openstreetmap.org/listinfo/tagging</a><br>
</blockquote>
</div>
<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>