Looks good. Vr gr Peter Elderson
Op vr 15 mrt. 2019 om 21:05 schreef seirra blake < sophietheopos...@yandex.com>: > key: *almost all tagging should occur here* | *data may be reused in > parent* | *data may be reused in parent and any 'adjacent' (with the same > letter) parent* > > *public transport network* [A] > > *route_master=public transport *[B] > > *route variant* [C] > > *combined stop/way relation suitable for public transport v2* [E] > > *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 use of tags that may be required: > > [E/G]: type=route + route=part > > > _____________________________________________________________________________ > > notes: > > - [G] may be infinitely nested as required to prevent duplicate sets > of ways (although this should rarely be required) > - [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) > - [G] should almost always not be used for a single way unless it will > assist in maintainability. if a > - I don't believe route_master=public transport actually exists, but > the same concept should work for any public transport > - 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 > - 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. > - 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 > - I may consider adding a rough idea on perceived pros/cons, depending > on demand > - I may add a more visual version, depending on demand > - 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) > > > _____________________________________________________________________________ > > changelog: > > #2 > > - fix mistake in key > - add missing formatting to key > - remove redundant reference to [F] > - specify when example should be live > - update potentially needed tags following discussion > - remove mention of shared=yes, this does not need to be used in the > newest version > - reorder changelog so it's newest first > > #1 > > - removed [D] and [F]. [D] was meant to be removed prior to sending, > [F] is not required. > - added a few more notes so it may be referred to on its own > - the bus example applies to any public transport really, adjust > language accordingly > - warned against damaging existing relations' usability/the creation > of fictional data > - added extra details on a request if needed basis > - added this changelog and relevant versioning to help people keep > track. this should be traceable to the (unlabelled) version 0 > > #0 > > - initial concept > > special thanks: > > - 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) > > On 3/15/19 5:54 PM, seirra blake wrote: > > 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 > > *public transport network* [A] > > *route_master=public transport *[B] > > *route variant* [C] > > *combined stop/way relation suitable for public transport v2* [E] > > *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 (to tell the software there is use of shared ways, but the > software probably should be able to work that out) > > [E/F/G]: route=shared (this is considered in case type=route explicitly > requires a route=* key) > > > _____________________________________________________________________________ > > notes: > > - [G] may be infinitely nested as required to prevent duplicate sets > of ways (although this should rarely be required) > - [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) > - [G] should almost always not be used for a single way unless it will > assist in maintainability. if a > - I don't believe route_master=public transport actually exists, but > the same concept should work for any public transport > - 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 > - 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. > - 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 > - I may consider adding a rough idea on perceived pros/cons, depending > on demand > - I may add a more visual version, depending on demand > - 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) > > > _____________________________________________________________________________ > > changelog: > > #0 > > - initial concept > > #1 > > - removed [D] and [F]. [D] was meant to be removed prior to sending, > [F] is not required. > - added a few more notes so it may be referred to on its own > - the bus example applies to any public transport really, adjust > language accordingly > - warned against damaging existing relations' usability/the creation > of fictional data > - added extra details on a request if needed basis > - added this changelog and relevant versioning to help people keep > track. this should be traceable to the (unlabelled) version 0 > > special thanks: > > - 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) > > On 3/15/19 2:37 PM, seirra blake 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 > listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging > > > _______________________________________________ > Tagging mailing > listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging > > > _______________________________________________ > Tagging mailing > listTagging@openstreetmap.orghttps://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
