Re: [Tagging] Superroutes - good, bad or ugly?

[Peter Elderson]

For map display, I can see that. The ways are added to a higher level (if
one exist) and the symbol is ignored.

I am not sure about routing/navigating. especially network routing. I
imagine a network router has to create an instant route, so it has to
decide whether to use the segment or not. The higher relations may not
apply, but the segment may be useable for the instant route. I think the
routing algorithm would need a tag for that?

I also think in the course of time, many segments will not be part of any
relation any more. At first they might be shared, but they may be removed
from the higher relation(s), the mapper doesn't know that (s)he was the
last user, so will not modify the segent relation.

Fr gr Peter Elderson


Op za 16 mrt. 2019 om 08:25 schreef Sarah Hoffmann :

> On Fri, Mar 15, 2019 at 02:43:03PM +0100, Peter Elderson wrote:
> > I like Sarah's proposal too, especially for walking routes. I'm not sure
> it
> > would work for complex PT routes, where routability is involved.
> >
> > One issue: a route relation can be a route on it's own AND part of a
> longer
> > route (or node network), on any level of the hierarchy. segment=yes would
> > not cover that, I think?
>
> In that case, nothing would be needed. It is only important to know when
> a relation is not a route on its own. Because then that route can be
> ignored
> in lists or when adding markings to the map.
>
> Sarah
>
> > And when naming parts, you'll have to cover the case that a route can be
> > part of multiple longer routes, the route itself may contain smaller
> parts
> > that are also part of multiple routes.
> > Parts can have any of the network tags.
> >
> > This complication is not created by Sarah's idea, but I would like to see
> > that solved too.
> >
> > Fr gr Peter Elderson
> >
> >
> > Op vr 15 mrt. 2019 om 14:26 schreef Richard Fairhurst <
> rich...@systemed.net
> > >:
> >
> > > marc marc wrote:
> > > > imho nearly no routing tools (nor foot nor bus) is currently
> > > > able to use a relation type=route with relations as child.
> > >
> > > cycle.travel can.
> > >
> > > I don't particularly care what's decided, but I would like it to be
> > > consistent (which right now it certainly isn't), and personally I
> don't see
> > > the need for type=superroute when you can just have relations as
> children
> > > of
> > > type=route. I like Sarah's proposal for route_segment=yes.
> > >
> > > Richard
> > >
> > >
> > >
> > > --
> > > Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html
> > >
> > > ___
> > > Tagging mailing list
> > > 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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Sarah Hoffmann]

On Fri, Mar 15, 2019 at 02:43:03PM +0100, Peter Elderson wrote:
> I like Sarah's proposal too, especially for walking routes. I'm not sure it
> would work for complex PT routes, where routability is involved.
> 
> One issue: a route relation can be a route on it's own AND part of a longer
> route (or node network), on any level of the hierarchy. segment=yes would
> not cover that, I think?

In that case, nothing would be needed. It is only important to know when
a relation is not a route on its own. Because then that route can be ignored
in lists or when adding markings to the map.

Sarah

> And when naming parts, you'll have to cover the case that a route can be
> part of multiple longer routes, the route itself may contain smaller parts
> that are also part of multiple routes.
> Parts can have any of the network tags.
> 
> This complication is not created by Sarah's idea, but I would like to see
> that solved too.
> 
> Fr gr Peter Elderson
> 
> 
> Op vr 15 mrt. 2019 om 14:26 schreef Richard Fairhurst  >:
> 
> > marc marc wrote:
> > > imho nearly no routing tools (nor foot nor bus) is currently
> > > able to use a relation type=route with relations as child.
> >
> > cycle.travel can.
> >
> > I don't particularly care what's decided, but I would like it to be
> > consistent (which right now it certainly isn't), and personally I don't see
> > the need for type=superroute when you can just have relations as children
> > of
> > type=route. I like Sarah's proposal for route_segment=yes.
> >
> > Richard
> >
> >
> >
> > --
> > Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html
> >
> > ___
> > Tagging mailing list
> > 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

Re: [Tagging] Superroutes - good, bad or ugly?

[Peter Elderson]

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 

Re: [Tagging] Superroutes - good, bad or ugly?

[seirra blake]

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 

Re: [Tagging] Superroutes - good, bad or ugly?

[seirra blake]

hmm maybe. version 4 will include a detailed example, once that is 
available feel free what would be missing for that purpose


On 3/15/19 7:19 PM, Martin Koppenhoefer wrote:

maybe we can have roles to state whether the tags of the referenced object 
should apply to the relation or if only the geometry matters. These superroutes 
could be also useful for admin relations

Cheers, Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[seirra blake]

hmm... I'm not quite sure on what would be best. I do see your point in 
the case of just splitting very long ways there, they would not be 
'shared' at all. to the best of my knowledge type=* is intended to 
exclusively define the relation. in all circumstances that we have 
discussed, it still joins up to make a route, so perhaps its best not to 
change the relation type. the chain idea is a nice one, but that would 
make the smaller bits that join together... links. that may get 
confusing quite fast; or chain-links, which might sound a bit too much 
like we're talking about a physical chain.  part might be a good 
candidate, it's already there in the sense of building:part=*; so 
following similar convention we could have route:part=yes, that seems 
pretty intuitive; although we can probably go a step further and just do 
a combination of type=route and route=part, I'll probably use that in 
the example I make.


On 3/15/19 7:03 PM, Peter Elderson wrote:
The just-a-chain-of-ways relation doesn't have to be shared. It's 
shareable, but the sharing really is of no consequence.


I think software needs a tag to control the selection for the purpose 
it serves, OR allow any route relation without a type within all route 
types it supports.
I would indeed go for an explicit label, just not "shared". Maybe 
"general" or "chain" or "basic" or "segment", "fragment", 
"elementary", just not something that says how it's going to be used.


Editors can keep their check that there MUST be a supported type tag, 
and add that type=basic (or whatever word is chosen) can only have a 
single consecutive ordered collection of ways. Other routes of any 
type should be allowed to contain ways AND basic routes, apart from 
more complex checking for particular cases such as PT variants.


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Martin Koppenhoefer]

maybe we can have roles to state whether the tags of the referenced object 
should apply to the relation or if only the geometry matters. These superroutes 
could be also useful for admin relations 

Cheers, Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[seirra blake]

I can understand your concern. I did actually consider mentioning 
something about skipping stops.. but I forgot to, I spent a good few 
hours on the original, so I guess my thoughts got easily distracted. 
I'll make an example based on the real data to help illustrate the idea, 
but I'll also include an imaginary express version that only stops at a 
few major stops. provided everything goes as planned I'll link to a 
fairly realistic example in version 4 (I need version 3 to fix a mistake 
I made). I understand that you may not want to follow each version due 
to being busy or whatever, so until the example is ready any future 
version will be 3.x (so for example: 3.0,3.1,3.2...); this way you'll be 
able to Ctrl+f and search for '#4', if there's no #4 it isn't ready yet 
and so you won't waste your time reading through the changelog for it. 
as for seeing all the stops/being able to compare to official feeds, 
that may fall more under what the renderer is expected to do, as it 
should already be reading all the segments as one whole route.


On 3/15/19 6:30 PM, Jo wrote:
When I start mapping a bus line, I have several route relations which 
contain all the stops for each variation in itinerary.


When I add the ways, it would be nice to reuse subroute relations for 
the parts where ways are shared between lines.


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)


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.


As far as I'm concerned, the sequence of stops is the 'signature' 
defining each variation in itinerary.


Polyglot

On Fri, Mar 15, 2019 at 6:55 PM seirra blake 
mailto:sophietheopos...@yandex.com>> 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 

Re: [Tagging] Superroutes - good, bad or ugly?

[Peter Elderson]

The just-a-chain-of-ways relation doesn't have to be shared. It's
shareable, but the sharing really is of no consequence.

I think software needs a tag to control the selection for the purpose it
serves, OR allow any route relation without a type within all route types
it supports.

I would indeed go for an explicit label, just not "shared". Maybe "general"
or "chain" or "basic" or "segment", "fragment", "elementary", just not
something that says how it's going to be used.

Editors can keep their check that there MUST be a supported type tag, and
add that type=basic (or whatever word is chosen) can only have a single
consecutive ordered collection of ways. Other routes of any type should be
allowed to contain ways AND basic routes, apart from more complex checking
for particular cases such as PT variants.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Jo]

When I start mapping a bus line, I have several route relations which
contain all the stops for each variation in itinerary.

When I add the ways, it would be nice to reuse subroute relations for the
parts where ways are shared between lines.

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)

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.

As far as I'm concerned, the sequence of stops is the 'signature' defining
each variation in itinerary.

Polyglot

On Fri, Mar 15, 2019 at 6:55 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 

Re: [Tagging] Superroutes - good, bad or ugly?

[seirra blake]

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 

Re: [Tagging] Superroutes - good, bad or ugly?

[seirra blake]

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 
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 

Re: [Tagging] Superroutes - good, bad or ugly?

[Kevin Kenny]

On Fri, Mar 15, 2019 at 9:05 AM Sarah Hoffmann  wrote:
> The disadvantage of all these proposals is that it is impossible
> to figure out if a relation is a route or only part of a superroute
> without looking at the parent.

At the risk of beating a dead horse, mightn't this be an argument in
favour of having osm2pgsql (optionally) preserve relation information
at least for routes? If there were an easy place in PostGIS to look
for the information, then needing to look at the parent wouldn't have
to be a show-stopper. Otherwise, this sounds like an argument for
structuring the data around the limitations of downstream tools.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[seirra blake]

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 
mailto:sophietheopos...@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

Re: [Tagging] Superroutes - good, bad or ugly?

[Egil]

+1
Sarah would you be willing to write a proposal for this?
Cheers
pangoSE

Sarah Hoffmann  skrev: (15 mars 2019 14:03:28 CET)
>On Fri, Mar 15, 2019 at 12:07:50PM +, 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" ?
>
>waymarkedtrails uses the network tag as an indicator. With the
>same network tag, the child is considered a segment. If the network
>tag is different, then the child is considered a route on its own
>that happens to be used by the superroute.
>
>> 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...
>
>The disadvantage of all these proposals is that it is impossible
>to figure out if a relation is a route or only part of a superroute
>without looking at the parent. That information is much more
>valuable than the information that a route is a 'superroute' (that's 
>obvious anyway as soon as there is a relation member). So I'd
>prefer seeing a dedicated tag added to relations that are just a
>segment.
>'route_segment=yes', for example. Or even better, directly name the
>sections, e.g. 'part=German section' or 'part=2. Etappe'. Then we can
>get rid of the descriptive name tags.
>
>Kind regards
>
>Sarah
>
>___
>Tagging mailing list
>Tagging@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/tagging

-- 
Skickat från min Android-enhet med k9.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Peter Elderson]

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>:

> 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 

Re: [Tagging] Superroutes - good, bad or ugly?

[Martin Koppenhoefer]

Am Fr., 15. März 2019 um 16:01 Uhr schrieb Jo :

> For public transport the biggest benefit will be ease of maintenance.
>


+1, it will also be "lighter" in a way: the superroute relations = actual
bus routes, will have much slower increase of versions, it will only be the
segment relations who increase for every split of a highway.

Cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Jo]

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 
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]
>

Re: [Tagging] Superroutes - good, bad or ugly?

[Peter Elderson]

I have actually done that, a "stub" containing one nwn hiking path which
also acts as the NL part of an iwn route. It was the only way to get the
tagging of names, international names, colours and osmc:symbols right.

On waymarkedtrails it works like a charm, but I'm less sure about OsmAnd.

Fr gr Peter Elderson


Op vr 15 mrt. 2019 om 15:24 schreef Martin Koppenhoefer <
dieterdre...@gmail.com>:

>
>
> sent from a phone
>
> > On 15. Mar 2019, at 14:43, Peter Elderson  wrote:
> >
> > I like Sarah's proposal too, especially for walking routes. I'm not sure
> it would work for complex PT routes, where routability is involved.
>
>
> how can we state that a route is complete and also a segment of another
> route? Safest way would be a third relation with just the segment as only
> member for the “complete” route, but maybe it can be done more elegantly
> with 2 relations rather than 3?
>
> Cheers, Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[seirra blake]

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 

Re: [Tagging] Superroutes - good, bad or ugly?

[Martin Koppenhoefer]

sent from a phone

> On 15. Mar 2019, at 14:43, Peter Elderson  wrote:
> 
> I like Sarah's proposal too, especially for walking routes. I'm not sure it 
> would work for complex PT routes, where routability is involved. 


how can we state that a route is complete and also a segment of another route? 
Safest way would be a third relation with just the segment as only member for 
the “complete” route, but maybe it can be done more elegantly with 2 relations 
rather than 3?

Cheers, Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Peter Elderson]

I like Sarah's proposal too, especially for walking routes. I'm not sure it
would work for complex PT routes, where routability is involved.

One issue: a route relation can be a route on it's own AND part of a longer
route (or node network), on any level of the hierarchy. segment=yes would
not cover that, I think?
And when naming parts, you'll have to cover the case that a route can be
part of multiple longer routes, the route itself may contain smaller parts
that are also part of multiple routes.
Parts can have any of the network tags.

This complication is not created by Sarah's idea, but I would like to see
that solved too.

Fr gr Peter Elderson


Op vr 15 mrt. 2019 om 14:26 schreef Richard Fairhurst :

> marc marc wrote:
> > imho nearly no routing tools (nor foot nor bus) is currently
> > able to use a relation type=route with relations as child.
>
> cycle.travel can.
>
> I don't particularly care what's decided, but I would like it to be
> consistent (which right now it certainly isn't), and personally I don't see
> the need for type=superroute when you can just have relations as children
> of
> type=route. I like Sarah's proposal for route_segment=yes.
>
> Richard
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Richard Fairhurst]

marc marc wrote:
> imho nearly no routing tools (nor foot nor bus) is currently 
> able to use a relation type=route with relations as child.

cycle.travel can.

I don't particularly care what's decided, but I would like it to be
consistent (which right now it certainly isn't), and personally I don't see
the need for type=superroute when you can just have relations as children of
type=route. I like Sarah's proposal for route_segment=yes.

Richard



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Sarah Hoffmann]

On Fri, Mar 15, 2019 at 12:07:50PM +, 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" ?

waymarkedtrails uses the network tag as an indicator. With the
same network tag, the child is considered a segment. If the network
tag is different, then the child is considered a route on its own
that happens to be used by the superroute.

> 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...

The disadvantage of all these proposals is that it is impossible
to figure out if a relation is a route or only part of a superroute
without looking at the parent. That information is much more
valuable than the information that a route is a 'superroute' (that's 
obvious anyway as soon as there is a relation member). So I'd
prefer seeing a dedicated tag added to relations that are just a segment.
'route_segment=yes', for example. Or even better, directly name the
sections, e.g. 'part=German section' or 'part=2. Etappe'. Then we can
get rid of the descriptive name tags.

Kind regards

Sarah

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[marc marc]

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
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Hufkratzer]

I wonder why we need a separate type=superroute if everything what can 
be done with superroutes can also be done with normal routes. Example: 
http://hiking.waymarkedtrails.org/?l#route?id=371740 is a normal hiking 
route, more than 10k km long, with 7 child relations that have child 
relations again. What is the difference between relation type route and 
superroute except the name? You might say that a superroute is a route 
that does not contain ways or nodes but only relations. But is that a 
good/sufficient reason to define a new relation type? Is there any other 
difference?



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Phake Nick]

I mean, these route variants can probably be remapped as superroute if
superroute become more popular

2019年3月15日 06:34 於 "marc marc"  寫道：

a route_master isn't a superroute, isn't it ?
it's a collection off all variant of a "single" route
  and not several part of one route like superroute for E-network

route_master are well documented/used for bus route
but if someone want to convert a single type=route into a superroute (so
a type=route having relation as member), imho it's better to make a
propal with a good doc to allow app to add this case.
if not, currently valid route 'll become unusable in all app.
so sure that's the best/most need thing todo with PT version :(

Le 14.03.19 à 23:25, Phake Nick a écrit :

> It really depends on exactly how complex the route is, something like
> https://www.openstreetmap.org/relation/4776035 this bus route can
> definitely use it. (and I haven't mentioned other similar bus routes
> with different numbers in different relationship yet)
>
> 在 2019年3月15日週五 03:31，Paul Allen  > 寫道：

>
> On Thu, 14 Mar 2019 at 19:23, Peter Elderson  > wrote:
>
> Op do 14 mrt. 2019 om 18:17 schreef Paul Allen
> mailto:pla16...@gmail.com>>:

>
> On Thu, 14 Mar 2019 at 15:09, Jo  > wrote:
>
> I would definitely want routes to be composed of
> subroutes which are shared with other routes,
>
>
> I see that as less than useful for any route I know of.
>
>
> It's useful for longer routes through walking/cycling node
> networks, using the network signposting.
>
>
> Yeah, I can see it would be.  And for longer bus routes.  Just not
> for any of the bus routes I know
> around here and am likely to map.  You end up with the only common
> segments being very short
> around a central bus station, then they all diverge.  Once diverged,
> there is nothing to share.
>
> I'm not against such sharing in principle, where it makes sense.
> But if it comes at the price
> that all bus stops have to be in the aggregate relation and not in
> the subroutes then it becomes
> useless for my purposes.  And I freely admit that my purposes are a
> fairly rare case, but I'd
> still like to handle it.
>
> --
> Paul
>
> ___
> Tagging mailing list
> 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
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Warin]

On 15/03/19 04:39, Paul Allen wrote:
On Thu, 14 Mar 2019 at 16:44, Martin Koppenhoefer 
mailto:dieterdre...@gmail.com>> wrote:



> On 14. Mar 2019, at 16:49, Tony Shield mailto:tony.shield...@gmail.com>> wrote:
>
> Can they currently be edited with JOSM?


of course, you simply add a relation as member to another relation.


Can you?  It's not clear to me from the documentation that I can do 
that in a way that achieves what
I want to do and is compatible with accepted usage.  If you can tell 
me how to do that I'll be very

happy.

Let me be clear.  I want to decompose a route into segments and then 
construct some sort of
relation (ordinary, superroute or whatever) that assembles them in 
sequence.


Take a look at some that already exist.
Super relation 176684 in
https://hiking.waymarkedtrails.org/#route?id=176684=5!-27.1268!148.8261
You can see it is composed of 4 relations. Using the elevation profile 
you can follow the route from south to north so they are in sequence 
(there are a few out of order bits within the sub relations .. grr) and 
it finishes up with the alternative routes (very incomplete) that are a 
bit random along the length.  So it is possible to organise them into a 
sequence.



I want to do this
because I have a route which traverses some ways twice.  I want to do 
this because the same route
has ways which are traversed twice (A, B, C, D) but the first time the 
stop at C is ignored (you can
neither board nor alight there) and the second time the stop at C is 
usable (you can board or alight).
I want to do this because although the route is circular, it is 
"hairy" (in the mathematical sense), it's
not an "O" but an "O=".  The same way is traversed twice in opposite 
directions: in a non-circular
route that would be two variants of a route master but this is a 
circular route.


Being able to decompose the route solves several problems.  As a 
single route it is a real pain
to edit because the tools don't fully support the same way appearing 
twice (maybe there's a JOSM
plugin that does it better).  I still have a gap on the route 
according to JOSM validator but I
can't spot it.  It doesn't show as a red dot in the edit relation 
table, I can't see it by scrolling through
the list of ways and looking at them, when I go to the validator and 
try zooming to the problem
nothing happens.  It's in one of the ways that gets traversed twice 
and it's driving me crazy.  I think
that subroutes would make it a lot easier for me to zero in on the 
problem.


Route with the same way twice? These 2 have the same ways twice - in 
different directions

relation 3550083
relation 7258397

Both edited in JOSM - so it is possible to add the same way twice .. it 
does give a warning pop up that you click through.
That pop up has an option to permanently deny entering things twice... 
oh and are you in expert mode?





As a single route it's impossible to figure out by simple inspection 
of the query tool:

https://www.openstreetmap.org/relation/8592409#map=14/52.0860/-4.6644
You tell me where it goes in what sequence without delving deeply into 
the relation.  I'll give
you a hint: it starts and ends here: 
https://www.openstreetmap.org/node/3642998002
Want another hint?  It doesn't just start and end there, it also stops 
there in the middle of its
route.  Without looking at the details of the relation, tell me where 
it goes next after that
starting point.  Being able to decompose it into segments would allow 
people to see a
sequence of segments in order (such as via umap) and it would be 
obvious what the route
is.  Having segments would allow me to deal with the stop that is 
passed twice (in the same
direction) but is only used once - it would appear on one segment but 
not the other.


I don't see the query tool as being appropriate for routes. What you 
would probably like is something like the waymarked trails but for 
public transport... ???


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Paul Allen]

On Thu, 14 Mar 2019 at 22:34, marc marc  wrote:

> a route_master isn't a superroute, isn't it ?
> it's a collection off all variant of a "single" route
>   and not several part of one route like superroute for E-network
>

That's how I understand it.  But I may be wrong.

>
> route_master are well documented/used for bus route
> but if someone want to convert a single type=route into a superroute (so
> a type=route having relation as member), imho it's better to make a
> propal with a good doc to allow app to add this case.
>

Erm, why?  The documentation for superroute, such as it is, says that one
reason is to map
things like the E-network and the other reason is to avoid a route with
more than 300 elements.
Obviously, if you had a route with 301 elements you would be entitled to
divide it and end up
with two subroutes of around 150 elements.  Or a subroute with 295 elements
and a
subroute with 6elements if that led to a more "natural" division.  But that
300 isn't a hard number,
as I understand it, and it would be OK to split for 290, or 280.

I'd just like to use it on a route with even fewer elements and I don't see
anything in the
documentation to say I can't.  If routers can handle a superroute for the
E-network they can
handle it for smaller routes.


> if not, currently valid route 'll become unusable in all app.
> so sure that's the best/most need thing todo with PT version :(
>

Again, if superroutes don't work with some apps the E-network has problems
and we either
have to abolish superroutes completely or fix broken apps or live with the
fact that some apps
are broken.

Since the route I'm talking about doesn't connect two transport nexuses,
broken routeing isn't
as big an issue for me as for the E-network.  Much more important is that
any tourist or visitor
(or even locals who rarely use the bus and haven't used this one since it
came into service a few
months ago) wanting to use the bus can figure out where it goes.  That
isn't easy.  Not even
if you have the timetable
https://www.richardsbros.co.uk/wp-content/uploads/2018/08/408-sept-2018.pdf
and know the local geography well.

At the risk of people getting deja vu all over again (thanks, Yogi Berra) I
invite you to try to figure
out this bus route:
https://www.openstreetmap.org/relation/8592409#map=14/52.0860/-4.6644
You'd have to either open it in an editor (if you're a registered user) or
work your way down the
ways listed in the relation, opening each in a new tab or window (or you
could just click on it
and then use the browser's back button but that's slower).

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[marc marc]

a route_master isn't a superroute, isn't it ?
it's a collection off all variant of a "single" route
  and not several part of one route like superroute for E-network

route_master are well documented/used for bus route
but if someone want to convert a single type=route into a superroute (so 
a type=route having relation as member), imho it's better to make a 
propal with a good doc to allow app to add this case.
if not, currently valid route 'll become unusable in all app.
so sure that's the best/most need thing todo with PT version :(

Le 14.03.19 à 23:25, Phake Nick a écrit :
> It really depends on exactly how complex the route is, something like 
> https://www.openstreetmap.org/relation/4776035 this bus route can 
> definitely use it. (and I haven't mentioned other similar bus routes 
> with different numbers in different relationship yet)
> 
> 在 2019年3月15日週五 03:31，Paul Allen  > 寫道：
> 
> On Thu, 14 Mar 2019 at 19:23, Peter Elderson  > wrote:
> 
> Op do 14 mrt. 2019 om 18:17 schreef Paul Allen
> mailto:pla16...@gmail.com>>:
> 
> On Thu, 14 Mar 2019 at 15:09, Jo  > wrote:
> 
> I would definitely want routes to be composed of
> subroutes which are shared with other routes,
> 
> 
> I see that as less than useful for any route I know of. 
> 
> 
> It's useful for longer routes through walking/cycling node
> networks, using the network signposting.
> 
> 
> Yeah, I can see it would be.  And for longer bus routes.  Just not
> for any of the bus routes I know
> around here and am likely to map.  You end up with the only common
> segments being very short
> around a central bus station, then they all diverge.  Once diverged,
> there is nothing to share.
> 
> I'm not against such sharing in principle, where it makes sense. 
> But if it comes at the price
> that all bus stops have to be in the aggregate relation and not in
> the subroutes then it becomes
> useless for my purposes.  And I freely admit that my purposes are a
> fairly rare case, but I'd
> still like to handle it.
> 
> -- 
> Paul
> 
> ___
> Tagging mailing list
> 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

Re: [Tagging] Superroutes - good, bad or ugly?

[Phake Nick]

It really depends on exactly how complex the route is, something like
https://www.openstreetmap.org/relation/4776035 this bus route can
definitely use it. (and I haven't mentioned other similar bus routes with
different numbers in different relationship yet)

在 2019年3月15日週五 03:31，Paul Allen  寫道：

> On Thu, 14 Mar 2019 at 19:23, Peter Elderson  wrote:
>
>> Op do 14 mrt. 2019 om 18:17 schreef Paul Allen :
>>
>>> On Thu, 14 Mar 2019 at 15:09, Jo  wrote:
>>>
 I would definitely want routes to be composed of subroutes which are
 shared with other routes,

>>>
>>> I see that as less than useful for any route I know of.
>>>
>>
>> It's useful for longer routes through walking/cycling node networks,
>> using the network signposting.
>>
>
> Yeah, I can see it would be.  And for longer bus routes.  Just not for any
> of the bus routes I know
> around here and am likely to map.  You end up with the only common
> segments being very short
> around a central bus station, then they all diverge.  Once diverged, there
> is nothing to share.
>
> I'm not against such sharing in principle, where it makes sense.  But if
> it comes at the price
> that all bus stops have to be in the aggregate relation and not in the
> subroutes then it becomes
> useless for my purposes.  And I freely admit that my purposes are a fairly
> rare case, but I'd
> still like to handle it.
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Paul Allen]

On Thu, 14 Mar 2019 at 19:23, Peter Elderson  wrote:

> Op do 14 mrt. 2019 om 18:17 schreef Paul Allen :
>
>> On Thu, 14 Mar 2019 at 15:09, Jo  wrote:
>>
>>> I would definitely want routes to be composed of subroutes which are
>>> shared with other routes,
>>>
>>
>> I see that as less than useful for any route I know of.
>>
>
> It's useful for longer routes through walking/cycling node networks, using
> the network signposting.
>

Yeah, I can see it would be.  And for longer bus routes.  Just not for any
of the bus routes I know
around here and am likely to map.  You end up with the only common segments
being very short
around a central bus station, then they all diverge.  Once diverged, there
is nothing to share.

I'm not against such sharing in principle, where it makes sense.  But if it
comes at the price
that all bus stops have to be in the aggregate relation and not in the
subroutes then it becomes
useless for my purposes.  And I freely admit that my purposes are a fairly
rare case, but I'd
still like to handle it.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Peter Elderson]

Op do 14 mrt. 2019 om 18:17 schreef Paul Allen :

> On Thu, 14 Mar 2019 at 15:09, Jo  wrote:
>
>> I would definitely want routes to be composed of subroutes which are
>> shared with other routes,
>>
>
> I see that as less than useful for any route I know of.
>

It's useful for longer routes through walking/cycling node networks, using
the network signposting.

Fr gr Peter Elderson


Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Paul Allen]

On Thu, 14 Mar 2019 at 16:44, Martin Koppenhoefer 
wrote:

>
> > On 14. Mar 2019, at 16:49, Tony Shield  wrote:
> >
> > Can they currently be edited with JOSM?
>
>
> of course, you simply add a relation as member to another relation.
>

Can you?  It's not clear to me from the documentation that I can do that in
a way that achieves what
I want to do and is compatible with accepted usage.  If you can tell me how
to do that I'll be very
happy.

Let me be clear.  I want to decompose a route into segments and then
construct some sort of
relation (ordinary, superroute or whatever) that assembles them in
sequence.  I want to do this
because I have a route which traverses some ways twice.  I want to do this
because the same route
has ways which are traversed twice (A, B, C, D) but the first time the stop
at C is ignored (you can
neither board nor alight there) and the second time the stop at C is usable
(you can board or alight).
I want to do this because although the route is circular, it is "hairy" (in
the mathematical sense), it's
not an "O" but an "O=".  The same way is traversed twice in opposite
directions: in a non-circular
route that would be two variants of a route master but this is a circular
route.

Being able to decompose the route solves several problems.  As a single
route it is a real pain
to edit because the tools don't fully support the same way appearing twice
(maybe there's a JOSM
plugin that does it better).  I still have a gap on the route according to
JOSM validator but I
can't spot it.  It doesn't show as a red dot in the edit relation table, I
can't see it by scrolling through
the list of ways and looking at them, when I go to the validator and try
zooming to the problem
nothing happens.  It's in one of the ways that gets traversed twice and
it's driving me crazy.  I think
that subroutes would make it a lot easier for me to zero in on the problem.

As a single route it's impossible to figure out by simple inspection of the
query tool:
https://www.openstreetmap.org/relation/8592409#map=14/52.0860/-4.6644
You tell me where it goes in what sequence without delving deeply into the
relation.  I'll give
you a hint: it starts and ends here:
https://www.openstreetmap.org/node/3642998002
Want another hint?  It doesn't just start and end there, it also stops
there in the middle of its
route.  Without looking at the details of the relation, tell me where it
goes next after that
starting point.  Being able to decompose it into segments would allow
people to see a
sequence of segments in order (such as via umap) and it would be obvious
what the route
is.  Having segments would allow me to deal with the stop that is passed
twice (in the same
direction) but is only used once - it would appear on one segment but not
the other.

So I don't care if it's a superroute, a master relation (I'm not keen on
that because this route
has several variants so I'd end up with a master relation of variants that
are themselves master
relations of segments), or something else.  I'd just like to be able to do
it.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Paul Allen]

On Thu, 14 Mar 2019 at 15:09, Jo  wrote:

> I would definitely want routes to be composed of subroutes which are
> shared with other routes,
>

I see that as less than useful for any route I know of.  But I suppose it's
a matter of how short
a subroute you're willing to put up with.  I probably wouldn't do it myself
but would say that you
should not.  However, surely that means that the subroutes also have to be
anonymous (they
don't specify a ref or anything else specific to a particular route) and
would therefore be totally
unsuitable for me.  If that's the case then I'm not in favour of doing
things your way.


> hence the reasoning of keeping the stop sequences in the route relations.
>

That, as I understand it, goes against what is currently done in
superroutes, goes totally
against one of my main reasons for wanting to do this, and makes editing
far harder.  Keeping
the stops with the route segment makes sense for many reasons.  It means
subroutes can
be edited independently of one another.  It makes adding/removing stops
easier for the simple
reason that it's easier to figure out where a stop goes in a relatively
short subroute than on
a much longer superroute.  It means the standard carto query on a subroute
shows the stops
associated with that subroute whereas your way you'd have to query the
superroute to see
the entire route and all its stops in order to see the stops on a much
smaller subroute.

All in all, I think keeping stops in the superroute is a very bad way to
go, independent of it
achieving precisely the opposite of what I hope to do.

Your "enhancement" makes the whole idea useless for my purposes and, I
think, is impracticl
for any other purpose.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Martin Koppenhoefer]

sent from a phone

> On 14. Mar 2019, at 16:49, Tony Shield  wrote:
> 
> Can they currently be edited with JOSM?


of course, you simply add a relation as member to another relation.

Cheers, Martin 

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Tony Shield]

Hi

Is there a PTV2 example of route with ways and subroutes? Can they 
currently be edited with JOSM?


TonyS

On 14/03/2019 15:07, Jo wrote:
I would definitely want routes to be composed of subroutes which are 
shared with other routes, hence the reasoning of keeping the stop 
sequences in the route relations.


Polyglot

On Thu, Mar 14, 2019, 15:41 Paul Allen  wrote:


On Thu, 14 Mar 2019 at 11:21, Tony Shield
mailto:tony.shield...@gmail.com>> wrote:

Am I right in thinking that a superroute is a sequence of ways
and relations of ways?


I'm not 100% certain.  The documentation on the wiki isn't
entirely clear.  I suspect some of it
may have been scrubbed by those who dislike the concept of
superroutes for any purpose
whatsoever, but it may just never have been written in the first
place.

As I understand it (possibly entirely inccorectly) it would be
analogous (using a slightly
different mechanism) to having the Wales Coast Path be a relation
comprising the
route for the Pembrokeshire Coast Path, the Ceredigion Coast Path,
etc.  A relation of
relations.

The relation of ways could be called a route-segment or
similar. A I see it routes for most trains and buses are a
sequence of ways and route-segments, and a route-segment could
be used by many routes.


I wasn't intending to share segments between routes.  I'm not sure
if I could make that work for
some of my purposes (I haven't thought about it enough to be
sure).  It probably won't be
universally applicable anyway, there are going to be routes that
share a particular segment but
not all of the stops on that segment.  Also fan-out of routes is
going to result in a lot of very
tiny segments that are possibly more trouble than they're worth
and it's probably less work to
make them longer segments.

-- 
Paul


___
Tagging mailing list
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

Re: [Tagging] Superroutes - good, bad or ugly?

[Jo]

I would definitely want routes to be composed of subroutes which are shared
with other routes, hence the reasoning of keeping the stop sequences in the
route relations.

Polyglot

On Thu, Mar 14, 2019, 15:41 Paul Allen  On Thu, 14 Mar 2019 at 11:21, Tony Shield 
> wrote:
>
> Am I right in thinking that a superroute is a sequence of ways and
>> relations of ways?
>>
>
> I'm not 100% certain.  The documentation on the wiki isn't entirely
> clear.  I suspect some of it
> may have been scrubbed by those who dislike the concept of superroutes for
> any purpose
> whatsoever, but it may just never have been written in the first place.
>
> As I understand it (possibly entirely inccorectly) it would be analogous
> (using a slightly
> different mechanism) to having the Wales Coast Path be a relation
> comprising the
> route for the Pembrokeshire Coast Path, the Ceredigion Coast Path, etc.  A
> relation of
> relations.
>
>
>> The relation of ways could be called a route-segment or similar. A I see
>> it routes for most trains and buses are a sequence of ways and
>> route-segments, and a route-segment could be used by many routes.
>>
>
> I wasn't intending to share segments between routes.  I'm not sure if I
> could make that work for
> some of my purposes (I haven't thought about it enough to be sure).  It
> probably won't be
> universally applicable anyway, there are going to be routes that share a
> particular segment but
> not all of the stops on that segment.  Also fan-out of routes is going to
> result in a lot of very
> tiny segments that are possibly more trouble than they're worth and it's
> probably less work to
> make them longer segments.
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Paul Allen]

On Thu, 14 Mar 2019 at 11:21, Tony Shield  wrote:

Am I right in thinking that a superroute is a sequence of ways and
> relations of ways?
>

I'm not 100% certain.  The documentation on the wiki isn't entirely clear.
I suspect some of it
may have been scrubbed by those who dislike the concept of superroutes for
any purpose
whatsoever, but it may just never have been written in the first place.

As I understand it (possibly entirely inccorectly) it would be analogous
(using a slightly
different mechanism) to having the Wales Coast Path be a relation
comprising the
route for the Pembrokeshire Coast Path, the Ceredigion Coast Path, etc.  A
relation of
relations.


> The relation of ways could be called a route-segment or similar. A I see
> it routes for most trains and buses are a sequence of ways and
> route-segments, and a route-segment could be used by many routes.
>

I wasn't intending to share segments between routes.  I'm not sure if I
could make that work for
some of my purposes (I haven't thought about it enough to be sure).  It
probably won't be
universally applicable anyway, there are going to be routes that share a
particular segment but
not all of the stops on that segment.  Also fan-out of routes is going to
result in a lot of very
tiny segments that are possibly more trouble than they're worth and it's
probably less work to
make them longer segments.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Paul Allen]

On Thu, 14 Mar 2019 at 03:44, Warin <61sundow...@gmail.com> wrote:

> On 14/03/19 01:02, Paul Allen wrote:
>
>
>
> One problem that I don't see a solution for in PTV1, PTV2 or "we don't tag
> it PTV3" is a stop
> that is ignored on the first pass but comes into play on the second pass.
> The bus starts at
> the bus station A, passes through nodes B, C and D and turns right at D to
> E.  On this pass
> through C it ignores the bus stop there.  After it's gone through the
> alphabet back to A, it
> again goes through B, C and D but this time turns left to alpha, beta,
> etc.  On this pass it
> does stop at C.  Piling all the stops into the relation may lead the
> routers to conclude that
> you can wait at the stop C to get directly to E when you can't (but you
> can get on at C to take
> a detour through the greek alphabet and eventually get to E because it's a
> circular).
>
> IN PTV2 you list the stops in order .. so they would be listed as;
> A
> B
> D
> E
> etc
> A
> B
> C
> D
> E
> etc
>
> So it can be done in PTV2.
>

Yes, it can be done.  I said as much myself.  But it is hard to decipher.
There is nothing that
explicitly says that the bus does not  stop at C the first time the bus
passes it but does stop
the second time.  If you painfully trace out the ENTIRE route, correlating
stops and ways,
you can reach the correct conclusion.

Now consider somebody using the query tool for the bus stop at C.  Somebody
who isn't a
mapper, just a user.  Here's the route:
https://www.openstreetmap.org/relation/8592409#map=14/52.0860/-4.6644
and here's the stop: https://www.openstreetmap.org/node/5706768172 Note
that I haven't yet
included the stop on that route (although I have included it in an
incomplete variant route), but
if I had, and included it in the right order, how easy would it be for you
to figure out what is going on?
>From casual inspection, it's not easy.

However, take a look at the incomplete variant route:
https://www.openstreetmap.org/relation/8603360#map=14/52.0869/-4.6691
and imagine that were part of a superroute.  You could see, by inspecting
the subroutes in turn
(for example, on umap) that this stop is used on one route segment but not
another, even though
both segments pass along that way.

A segment end does not indicate a stop .. in PTV2. The segments need to be
> in sequential order and so do the stops.
>

A segment END?  Who's talking about segment ends?  I'm talking about a
segment which may
have more than one stop or no stops at all.  Who's talking about disordered
segments?  The whole
idea is to have the segments in order.  Who's talking about disordered
stops?  The whole idea is
to have ordered stops.

What I'm talking about is a segment of a route with its stops.  It may
share one or more ways
with a different segments of that route, and it may share one or more stops
(or none at all).  One
of us is missing what the other is saying, right now I don't know which one
of us that is.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Tony Shield]

Warin

Great description of PTV2.

Paul

Am I right in thinking that a superroute is a sequence of ways and 
relations of ways? The relation of ways could be called a route-segment 
or similar. A I see it routes for most trains and buses are a sequence 
of ways and route-segments, and a route-segment could be used by many 
routes.


TonyS

On 14/03/2019 03:43, Warin wrote:

On 14/03/19 01:02, Paul Allen wrote:



One problem that I don't see a solution for in PTV1, PTV2 or "we 
don't tag it PTV3" is a stop
that is ignored on the first pass but comes into play on the second 
pass.  The bus starts at
the bus station A, passes through nodes B, C and D and turns right at 
D to E.  On this pass
through C it ignores the bus stop there.  After it's gone through the 
alphabet back to A, it
again goes through B, C and D but this time turns left to alpha, 
beta, etc.  On this pass it
does stop at C.  Piling all the stops into the relation may lead the 
routers to conclude that
you can wait at the stop C to get directly to E when you can't (but 
you can get on at C to take
a detour through the greek alphabet and eventually get to E because 
it's a circular).

IN PTV2 you list the stops in order .. so they would be listed as;
A
B
D
E
etc
A
B
C
D
E
etc

So it can be done in PTV2.


Splitting it into route segments would fix the problem with the stop 
at C.  On one segment it isn't

a listed stop.  On another segment it is.


A segment end does not indicate a stop .. in PTV2. The segments need 
to be in sequential order and so do the stops.


I did a rough simpletons guide to PTV2 .. 
https://www.openstreetmap.org/user/Warin61/diary/45106




___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Warin]

On 14/03/19 01:02, Paul Allen wrote:



One problem that I don't see a solution for in PTV1, PTV2 or "we don't 
tag it PTV3" is a stop
that is ignored on the first pass but comes into play on the second 
pass.  The bus starts at
the bus station A, passes through nodes B, C and D and turns right at 
D to E.  On this pass
through C it ignores the bus stop there.  After it's gone through the 
alphabet back to A, it
again goes through B, C and D but this time turns left to alpha, beta, 
etc.  On this pass it
does stop at C.  Piling all the stops into the relation may lead the 
routers to conclude that
you can wait at the stop C to get directly to E when you can't (but 
you can get on at C to take
a detour through the greek alphabet and eventually get to E because 
it's a circular).

IN PTV2 you list the stops in order .. so they would be listed as;
A
B
D
E
etc
A
B
C
D
E
etc

So it can be done in PTV2.


Splitting it into route segments would fix the problem with the stop 
at C.  On one segment it isn't

a listed stop.  On another segment it is.


A segment end does not indicate a stop .. in PTV2. The segments need to 
be in sequential order and so do the stops.


I did a rough simpletons guide to PTV2 .. 
https://www.openstreetmap.org/user/Warin61/diary/45106



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Paul Johnson]

On Wed, Mar 13, 2019 at 8:19 AM Paul Allen  wrote:

> I've hesitated to ask this question for months now: what's the
> consensus on superroutes?
>

Coherently and cogently mapping large countries with long routes (such as
the United States) would be essentially impossible without them.  I think
the current relation member limit is arbitrarily set to what fits in an 8
bit value IIRC; throw in everything that can cause a break (bridges,
changes in weight, speed and length maximums and minimums, whether or not
something is toll, lane counts and placement, turn lane status, etc) and it
wouldn't surprise me if states like Texas or California might have to start
using county-by-county child relations within a superrelation in order to
keep it all under the member limit in the foreseeable future.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Paul Allen]

On Wed, 13 Mar 2019 at 22:42, Jo  wrote:

> I think we should move to subrelations for bus routes at some point.
> Actually doing it is somewhat tricky. We'd definitely need editor support
> to show that a route which consists of subroutes is continuous or not.
>

Not a big problem.  Not compared with sorting the route I just had to sort
(again).  Dunno if I messed
up last time I sorted it or what, but it's a major pain.  Maybe I need a
different JOSM plugin, but I
already find JOSM confusing enough.

One problem I found with JOSM was zooming to a way in the relation when
that way appears more
than once.  I did that a lot so I could check the next way in the route was
even in the table or
had to be added.  But if a way appears more than once in a route (as
several do in the one
I was working on) then JOSM moves to the first occurrence of it in the
table of ways, rather than
the one I just selected.

If I could use a superroute then I would choose the subroutes so that no
way appears twice
in a subroute.  That's a problem with circulars that non-circulars don't
have (most of the time
a non-circular has two variants A->B and B->A and although most of the ways
are common to
both they're separate relations).  A truly circular wouldn't have that
problem either, but this one
has loops and repeats and side-branches that aren't loops.


> The biggest point of contention seems to be whether the stops should go
> into the subroute relations as well. I'd say no. Keep the stop sequences
> for a particular variation in itinerary together in a route relation per
> variation. And only use the subroutes to collect continuous sequences of
> ways.
>
> At the same time, some people would think it's more logical to have a
> sequence of ways, then a stop, then the next sequence, a stop, and so on.
> For that too, it would be nice to have editor support that shows that the
> way before and the way after actually connects, or not.
>

That's the other problem I have.  A stop which isn't a stop the first time
the bus passes along
a way but is a stop the second time.  Although the ordering of stops does
mean it's possible to
figure out if you inspect the relation closely, it's not obvious.  Allowing
stops to intersperse the
ways would make it slightly easier to figure out.  But using a superroute
makes it very clear:
it's not a stop on segment 1 but it is a stop on segment 2.  So I'd
definitely want stops on the
subroutes not the superroute.  I think it makes more sense that way
anyway.  It keeps the
stops with the associated ways.

If we go the way of subroutes for PT routes, I/we can probably coerce a
> GSoC student to create support for it in PT_Assistant over the summer.
>

All the tools I need to make life a LOT easier by splitting the route into
subroutes are there.
Breaking the route up manually is relatively simple (takes several steps
and some time, but
very little thought), and after that it just gets far, far easier to deal
with short segments than
one big, looping, wandering route.  If I choose the subroutes wisely I can
even let JOSM sort
them for me (it gets very confused with this route where several ways are
traversed more than
once).

There are only three things stopping me doing that right now:

1) What the response to my post was.  So far nobody has said that it's a
really bad idea since
I posted details of the route.  Unless there are many howls of outrage,
I'll assume it's not
an outrageously bad idea.

2) How to differentiate between the different segments.  I can't use from
and to because those are
supposed to be terminal destinations (preferably as shown on the bus
itself).  So I need a new
tag (or two).  I could get by with something like segment="A to B",
segment="B to C" etc.  But
there's probably a better way of doing it.  And I'd like to do that both
for human readability when
mapping and to allow umap a way of distinguishing between subroutes with an
overpass
query.

3) What else I haven't thought of.  What's show-stopper might turn up after
I've spent time
splitting the route.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Warin]

On 14/03/19 00:36, Martin Koppenhoefer wrote:
Am Mi., 13. März 2019 um 14:31 Uhr schrieb Sergio Manzi >:


If a "/superroute/" has an official status (/like this one:
https://www.openstreetmap.org/relation/20773/), I'm all-in for that.

If instead it is something "/invented/" by the mapper, than I'm
all-against it.

Can you please provide more information/examples/context?



there are really long relations (e.g. Via Francigena / St. Francis 
Way, or European E-Routes, which cross half of Europe). Splitting them 
into smaller pieces helps reducing editing conflicts (2 people editing 
the same object at the same time). This is often done along 
administrative boundaries (regional, national).




Supper relation 176684 the Bicentennial National Trail is over 5,000 km 
long, split into 4 sub relations at present.



Many bus routes in cities follow the same route in small sections. It 
would be hand for them to share that part as a sub route - meaning any 
updating of that sub route (people adding turn restrictions, parking, 
curbing etc) only changes that sub route rather than 4 or more 
individual bus routes.



--

The splitting of a relation into sub relations is done for many reasons. 
Making it easier for the mapper is of primary importance. I did see on 
the wiki that relations are better with a maximum of 300 members .. 
weather that is true or not I don't know. But it doe make sense that 
with a lot of members the relation becomes harder to handle for both 
maintenance and rendering.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Jo]

I think we should move to subrelations for bus routes at some point.
Actually doing it is somewhat tricky. We'd definitely need editor support
to show that a route which consists of subroutes is continuous or not. The
biggest point of contention seems to be whether the stops should go into
the subroute relations as well. I'd say no. Keep the stop sequences for a
particular variation in itinerary together in a route relation per
variation. And only use the subroutes to collect continuous sequences of
ways.

At the same time, some people would think it's more logical to have a
sequence of ways, then a stop, then the next sequence, a stop, and so on.
For that too, it would be nice to have editor support that shows that the
way before and the way after actually connects, or not.

If we go the way of subroutes for PT routes, I/we can probably coerce a
GSoC student to create support for it in PT_Assistant over the summer.

Polyglot

On Wed, Mar 13, 2019 at 11:20 PM Graeme Fitzpatrick 
wrote:

>
>
> On Thu, 14 Mar 2019 at 00:05, Paul Allen  wrote:
>
>> or should I stick to eating babies as that would be more socially
>> acceptable?
>>
>
> I guess that sort of depends on whether or not they're Irish babies
> https://en.wikipedia.org/wiki/A_Modest_Proposal
>
> & we're having Roast Peasant under Glass for dinner tonight - feel like
> joining us? :-)
>
> & as for super-relations - ??? :-)
>
> Thanks
>
> Graeme
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Graeme Fitzpatrick]

On Thu, 14 Mar 2019 at 00:05, Paul Allen  wrote:

> or should I stick to eating babies as that would be more socially
> acceptable?
>

I guess that sort of depends on whether or not they're Irish babies
https://en.wikipedia.org/wiki/A_Modest_Proposal

& we're having Roast Peasant under Glass for dinner tonight - feel like
joining us? :-)

& as for super-relations - ??? :-)

Thanks

Graeme
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Kevin Kenny]

On Wed, Mar 13, 2019 at 11:03 AM Peter Elderson  wrote:
> I can't answer the question for busrelations.
(neither can I)

> For long hiking routes and walking node networks, relations containing 
> relations are very important.
> Without those, maintenance of long hiking routes becomes a p.i.t.b, sometimes 
> near impossible.

Exactly. What is 'long' kind of varies. When I mapped
https://www.openstreetmap.org/relation/4286650, I used a single
relation, because there were relatively few member ways and very few
natural points to break it into pieces.

For the work in progress,
https://www.openstreetmap.org/relation/919642, I found that trying to
maintain a single relation was totally unmanageable. In fact, I
tripped over a bug (since fixed) in JOSM with handling a relation that
big, and had to switch to Meerkartor while breaking it up. I decided
that the most natural break was on county lines, although I didn't
trouble with separating off the tiny segment that is on the streets of
Manhattan (New York County). That worked out well, and Waymarked
Trails is happy with it. (The remaining gaps have nothing to do with
tagging. I simply haven't mapped them yet, and won't until the weather
improves. I dislike mapping on snowshoes, because too often I discover
that the snowshoe track doesn't follow the actual treadway.)

> Rendering can be done without superroutes, just by rendering each piece 
> separately. But datausers need to resolve the hierarchy. Waymarkedtrails does 
> that nicely for long recreational routes: Just replace every member relation 
> with its content, recursively. Works nicely- if it's only ways in the lowest 
> level relations.

Most renderers and routers work that way, because that's how osm2pgsql
works. In fact, there is no non-deprecated way to access relation
information at the time of routing or rendering, if you use osm2pgsql;
all relations have been reduced to single ways and/or multipolygons.
(That's why I'm planning to investigate using imposm3 for my own
experimental stuff on route concurrences - I find myself needing the
route relations after osm2pgsql has thrown them away.)

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Peter Elderson]

I can't answer the question for busrelations.

For long hiking routes and walking node networks, relations containing
relations are very important.

Without those, maintenance of long hiking routes becomes a p.i.t.b,
sometimes near impossible.

Rendering can be done without superroutes, just by rendering each piece
separately. But datausers need to resolve the hierarchy. Waymarkedtrails
does that nicely for long recreational routes: Just replace every member
relation with its content, recursively. Works nicely- if it's only ways in
the lowest level relations.

I'm not sure if your case needs just rendering or also data
use/routing/navigation.

Vr gr Peter Elderson


Op wo 13 mrt. 2019 om 15:05 schreef Paul Allen :

> On Wed, 13 Mar 2019 at 13:29, Andy Townsend  wrote:
>
>> On 13/03/2019 13:18, Paul Allen wrote:
>> > I've hesitated to ask this question for months now: what's the
>> > consensus on superroutes?
>>
>> In what context are you asking the question?  I can think of examples
>> where the answer would be "a really bad idea" and others where the
>> answer would be "essential; there's really no other sensible way to have
>> that data in OSM".
>>
>
> That's more positive than I expected: they're not always on a par with
> eating babies but the use
> has to be justifiable.
>
> Can I get the data into OSM without a superroute?  Sure.  Is that data
> useful without a superroute?
> Not so much.  It is this bus route:
> https://www.openstreetmap.org/relation/8592409#map=14/52.0860/-4.6644
> That is incomplete and has some omissions and errors.  I really ought to
> fix it, but I had
> this thought about superroutes and realized if I fixed and then found out
> I could use a
> superroute I'd later have to rework a few things.
>
> It's a circular.  It starts at what can loosely be called the bus
> station.  It does what can loosely
> be called a hairy circular route to return to the bus station.  The route
> then continues on a side
> trip and eventually returns to the bus station, completing the "circle."
>
> There are places where the bus goes into a dead-end and gets out by
> reversing into a side
> junction.  This differs from similar manoeuvres at a terminus of a
> non-circular route because
> passengers are on board.  It does a loop-the-loop.  It appears to do a
> figure-8 but actually
> there are other side-trips that mean it really isn't.
>
> One problem that I don't see a solution for in PTV1, PTV2 or "we don't tag
> it PTV3" is a stop
> that is ignored on the first pass but comes into play on the second pass.
> The bus starts at
> the bus station A, passes through nodes B, C and D and turns right at D to
> E.  On this pass
> through C it ignores the bus stop there.  After it's gone through the
> alphabet back to A, it
> again goes through B, C and D but this time turns left to alpha, beta,
> etc.  On this pass it
> does stop at C.  Piling all the stops into the relation may lead the
> routers to conclude that
> you can wait at the stop C to get directly to E when you can't (but you
> can get on at C to take
> a detour through the greek alphabet and eventually get to E because it's a
> circular).
>
> Splitting it into route segments would fix the problem with the stop at
> C.  On one segment it isn't
> a listed stop.  On another segment it is.
>
> Splitting it into route segments would also make it clearer what happens
> in the loop-the-loop
> and the figure-of-8 in the town centre, if the splits are chosen
> judiciously.  If I'm really clever
> I can find splits that make the variant routes fit in nicely, too.  You
> think that route is insane?
> Wait until I add the variants.
>
> Best of all, I could pull these into umap.  It would then be possible to
> display route segments
> in turn to see where the bus goes rather than trying to puzzle it out from
> the overall route.  Yes,
> if you're very familiar with OSM you can puzzle it out from the relation,
> but most people can't do
> that (and I find it difficult, even with knowledge of how the route runs).
>
> So, good idea, bad idea, or should I stick to eating babies as that would
> be more socially
> acceptable?
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Paul Allen]

On Wed, 13 Mar 2019 at 13:29, Andy Townsend  wrote:

> On 13/03/2019 13:18, Paul Allen wrote:
> > I've hesitated to ask this question for months now: what's the
> > consensus on superroutes?
>
> In what context are you asking the question?  I can think of examples
> where the answer would be "a really bad idea" and others where the
> answer would be "essential; there's really no other sensible way to have
> that data in OSM".
>

That's more positive than I expected: they're not always on a par with
eating babies but the use
has to be justifiable.

Can I get the data into OSM without a superroute?  Sure.  Is that data
useful without a superroute?
Not so much.  It is this bus route:
https://www.openstreetmap.org/relation/8592409#map=14/52.0860/-4.6644
That is incomplete and has some omissions and errors.  I really ought to
fix it, but I had
this thought about superroutes and realized if I fixed and then found out I
could use a
superroute I'd later have to rework a few things.

It's a circular.  It starts at what can loosely be called the bus station.
It does what can loosely
be called a hairy circular route to return to the bus station.  The route
then continues on a side
trip and eventually returns to the bus station, completing the "circle."

There are places where the bus goes into a dead-end and gets out by
reversing into a side
junction.  This differs from similar manoeuvres at a terminus of a
non-circular route because
passengers are on board.  It does a loop-the-loop.  It appears to do a
figure-8 but actually
there are other side-trips that mean it really isn't.

One problem that I don't see a solution for in PTV1, PTV2 or "we don't tag
it PTV3" is a stop
that is ignored on the first pass but comes into play on the second pass.
The bus starts at
the bus station A, passes through nodes B, C and D and turns right at D to
E.  On this pass
through C it ignores the bus stop there.  After it's gone through the
alphabet back to A, it
again goes through B, C and D but this time turns left to alpha, beta,
etc.  On this pass it
does stop at C.  Piling all the stops into the relation may lead the
routers to conclude that
you can wait at the stop C to get directly to E when you can't (but you can
get on at C to take
a detour through the greek alphabet and eventually get to E because it's a
circular).

Splitting it into route segments would fix the problem with the stop at C.
On one segment it isn't
a listed stop.  On another segment it is.

Splitting it into route segments would also make it clearer what happens in
the loop-the-loop
and the figure-of-8 in the town centre, if the splits are chosen
judiciously.  If I'm really clever
I can find splits that make the variant routes fit in nicely, too.  You
think that route is insane?
Wait until I add the variants.

Best of all, I could pull these into umap.  It would then be possible to
display route segments
in turn to see where the bus goes rather than trying to puzzle it out from
the overall route.  Yes,
if you're very familiar with OSM you can puzzle it out from the relation,
but most people can't do
that (and I find it difficult, even with knowledge of how the route runs).

So, good idea, bad idea, or should I stick to eating babies as that would
be more socially
acceptable?

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Martin Koppenhoefer]

Am Mi., 13. März 2019 um 14:31 Uhr schrieb Sergio Manzi :

> If a "*superroute*" has an official status (*like this one:
> https://www.openstreetmap.org/relation/20773
> *), I'm all-in for that.
>
> If instead it is something "*invented*" by the mapper, than I'm
> all-against it.
>
> Can you please provide more information/examples/context?
>


there are really long relations (e.g. Via Francigena / St. Francis Way, or
European E-Routes, which cross half of Europe). Splitting them into smaller
pieces helps reducing editing conflicts (2 people editing the same object
at the same time). This is often done along administrative boundaries
(regional, national).

Cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Sergio Manzi]

If a "/superroute/" has an official status (/like this one: 
https://www.openstreetmap.org/relation/20773/), I'm all-in for that.

If instead it is something "/invented/" by the mapper, than I'm all-against it.

Can you please provide more information/examples/context?

Sergio


On 2019-03-13 14:18, Paul Allen wrote:
> I've hesitated to ask this question for months now: what's the
> consensus on superroutes?  Going by all I can find on the wiki,
> forums and past discussions, they're highly controversial.  One wiki
> page mentions them and says don't use them.  They were either
> never well documented on the wiki or some documentation has
> been scrubbed.  What I don't know is whether the intense dislike
> some people expressed when they were first proposed has faded
> or if they're still largely considered to be a very bad idea.
>
> One justification for them is that they simplify the mapping of
> trans-national routes or very long routes: individual sections can
> be mapped separately and then assembled into a coherent whole
> as a superroute.
>
> Another justification is that very long ways (the figure I've seen is
> 300 nodes) can be problematic and they should be split into
> a superroute of individual routes.
>
> An argument against them is that some routers may not be able
> to handle them.  Which would obviously have been true when they
> were first proposed and may still be true now.  Which is a problem
> with just about everything proposed here: we propose something
> new, it's argued against because editors/renderers/routers don't
> handle it, but the reason editors/renderers/routers don't handle it
> is because nobody uses it.
>
> The reason I ask is that I can see an application for them that is
> not explicitly mentioned in the documentation but might allow me
> to deal with an otherwise intractable problem.  If there is universal
> disdain here I'll have to abandon that idea.  But if there are enough
> people who are happy with them then I have some questions...
>
> Please don't let this degenerate into a flame war.  That can come when
> (if) I explain what I want to do with a superroute - even the people who
> support superroutes (if there are any) may be unhappy with that idea.
>
> -- 
> Paul
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Andy Townsend]

On 13/03/2019 13:18, Paul Allen wrote:

I've hesitated to ask this question for months now: what's the
consensus on superroutes?


In what context are you asking the question?  I can think of examples 
where the answer would be "a really bad idea" and others where the 
answer would be "essential; there's really no other sensible way to have 
that data in OSM".


Best Regards,

Andy



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging