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
On 3/15/19 3:22 PM, Peter Elderson wrote:
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.
You would need to allow all types of route relations to contain ways
and shared segment relations.
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?
Fr gr Peter Elderson
Op vr 15 mrt. 2019 om 15:38 schreef seirra blake
<sophietheopos...@yandex.com <mailto:sophietheopos...@yandex.com>>:
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 <mailto:Tagging@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org <mailto: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
