[Tagging] Superroutes - good, bad or ugly?
seirra blake
sophietheopossum at yandex.com
Fri Mar 15 17:01:46 UTC 2019
oh the idea is that [G] has type=route, but no route=* because it may be
used in any form of route (with some 'common sense' of course); route
does not apply until [C] so route=road would not get reused. there is
actually a small error, [D/E] is the same and stays exclusively within
public transport. unless you actively map an island I would hope you are
joking. in case you weren't the context is that someone made a whole
fake settlement on an actual island so it would render on the main page
and someone had to revert a whole load of changesets. I can't imagine
much friction from the local community if I make an example relation
alongside the current one and add a note that until further notice
although based on real data it's a proof of concept though. I'll reply
to my own email and add a slightly more updated version (just of the
example) addressing some of this, just to make sure it's clear what I
meant. if you feel an example would help somewhat I'll make one too; it
could be useful to see how renderers handle it now. let me know if you'd
like a 'physical' example.
On 3/15/19 3:00 PM, Jo wrote:
> Good analysis Seirra,
>
> I would not "reuse" route=road in other route=* relations though.
> route=bicycle might share segments with route=foot/walking/hiking, but
> I'd keep everything related to bus/trolley_bus and coach together in
> terms of sharing of subroutes not mix it with other route types.
>
> For public transport the biggest benefit will be ease of maintenance.
>
> The way I see it route=bus relation should describe a single variation
> in itinerary, and thus include all the stops for that variation. So in
> my view the subroutes only contain ways.
> I would create subroutes for each direction of travel, so no
> forward/backward roles need to become involved. If the subroute would
> only contain a single way, a subroute relation probably wasn't needed.
>
> Paul Allen, I did read your objections to this, but that bus route is
> wildly exceptional, whereas buses travelling along 'corridors',
> reusing the same roads as the rest of the lines is very common (as
> that is where the stops are, obviously).
>
> Maybe I should try to create an example somewhere. Preferably a small
> island....
>
> Polyglot
>
> On Fri, Mar 15, 2019 at 3:38 PM seirra blake
> <sophietheopossum at yandex.com <mailto:sophietheopossum at yandex.com>> 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 at openstreetmap.org <mailto:Tagging at openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/tagging
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org <mailto:Tagging at openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/tagging
>
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20190315/d9500f67/attachment-0001.html>
More information about the Tagging
mailing list