Re: [Tagging] Tagging Cycle Route Relations vs. Ways

[stevea]

On Nov 16, 2020, at 9:00 PM, Seth Deegan  wrote:
> And of course, I have got this response before. But now that I think about 
> it, the limiting factors seem to be:
>   • Editors (I use iD primarily) do not allow you to easily see the exact 
> past history of an element.

OSM is not its software editors, they are merely tools for manipulating OSM's 
data, the software editors are not the underlying data themselves.  If a tool 
doesn’t do what you need it to do, either find or develop another one (or 
method) that does, or file a ticket (defect report) with the original tool, if 
you really believe it should provide the functionality you seem to be missing.  
If those seem to frustrate, there are good places to look (wiki…) and ask (talk 
pages…) for more direct help from people who might already know how to do what 
you’d like to do.

> Nor does osm.org really (why does it give a list of changed elements and map 
> area and not even allow you to see what tags and elements' geography are 
> changed!?).

I’m not quite sure of what your exact complaint is here, but if what you mean 
by “osm.org” is our website, then my reply would be that it does an OK job of 
this:  click the History button to get a recent-around-here list of 20 edits 
(click the Load More button for 20 more…and again and again if you like).  
Clicking on one specific changeset will “drill down” to the specific data 
elements changed in that changeset (to the degree they can be displayed in a 
narrow column on a web page, though there are numbered “pages” you can scroll 
through for copious amounts of data).  These are grouped by data type (nodes, 
ways and relations), which in turn can have their “history” displayed, by 
“version number.”  It’s basic, workaday metadata, but it’s quite useful and 
user-friendly, requiring no more complicated skill than to click-navigate on a 
web page.

> OSMcha only does it on a per-changeset basis. https://osmhv.openstreetmap.de/ 
> does this perfectly. 
>   • What if the source is in a changeset 2+ changesets ago? I shouldn't 
> have to look back in the history to find a source.

Yes, sometimes you should.  I’ve been bitten quite a few times by assuming that 
the most recent author listed in a changeset is responsible for changing a 
particular datum IN that changeset, but actually, it was somebody else further 
back in history.  So, now I am much more careful to find out the REAL “most 
recent author of that particular datum,” meaning I DO have to go back two or 
even more versions to find out who that is.  (Then, of course, I politely 
contact them and ask “WTF WERE YOU THINKING?!” — um, I mean, “Hm, may I ask how 
you came about your edit on this particular element of OSM?”)

Good dialog here.

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

Re: [Tagging] Tagging Cycle Route Relations vs. Ways

[Yves via Tagging]

On the history of elements, this tool is particularly good I think :
https://osmlab.github.io/osm-deep-history/
Yves ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging Cycle Route Relations vs. Ways

[Seth Deegan]

And of course, I have got this response before. But now that I think about
it, the limiting factors seem to be:

   1. Editors (I use iD primarily) do not allow you to easily see the
   *exact* past history of an element. Nor does osm.org really (why does it
   give a list of changed elements and map area and not even allow you to see
   what tags and elements' geography are changed!?). OSMcha only does it on a
   per-changeset basis. https://osmhv.openstreetmap.de/ does this
   perfectly.
   2. What if the source is in a changeset 2+ changesets ago? I shouldn't
   have to look back in the history to find a source.


On Mon, Nov 16, 2020 at 9:09 PM Seth Deegan  wrote:

> May I ask why not source=*? I know it's basically depreciated, but many
> times I find myself wondering where past mappers got the info for a route
> (this happened just today). I would find it very helpful. It also doesn't
> require the tagging of all of the ways.
>
> On Mon, Nov 16, 2020 at 8:45 PM Kevin Kenny 
> wrote:
>
>> On Mon, Nov 16, 2020 at 9:20 PM Dave F via Tagging <
>> tagging@openstreetmap.org> wrote:
>>
>>> Be careful. This is where many contributors get confused. The name of
>>> the *path* is often not the name of the *route*. A route relation can, &
>>> often does, go along paths with different names. Multiple routes can go
>>> along a path.
>>>
>>
>> To give a more concrete example, there's a rail-trail in my neighborhood
>> called the Mohawk-Hudson Bike-Hike Trail.
>> It has a relation, for several reasons that I'll discuss below.  Most of
>> its member ways are also named 'Mohawk-Hudson Bike-Hike Trail'. There are a
>> few ways, however, that have the names of highways because freeways and
>> active rail lines interrupt the rail grade, and the trail follows some
>> lightly-trafficked streets for a short distance before rejoining the
>> grade.  Those ways have name='Dunsbach Ferry Road', name='Island View
>> Road', name='Scrafford Lane', name='Iroquois Street', etc, but remain
>> members of the route named 'Mohawk-Hudson Bike-Hike Trail'. (Actually,
>> there are two route relations: one for cycling and one for walking.)
>>
>> Large portions of the rail-trail are, in turn, used by two long-distance
>> routes: the Erie Canalway Trail and the Empire State Trail.  There are
>> separate relations for these two, and most of the members of the
>> Mohawk-Hudson Bike-Hike Trail are also members of these other relations.
>> (That does not affect the names of the member ways. The Mohawk-Hudson
>> signage is consistent, while the signage for the other two trails is still
>> something of a work in progress, although there's a lot more of it than
>> there used to be. The naming of the member ways follows the commonest
>> signage.)
>>
>> There are a great many member ways because of changes of the
>> characteristics of the way (bridge=yes, embankment=yes, bicycle=dismount,
>> surface changing from asphalt to wood on a bridge, and so on.)
>>
>>>
>> The Mohawk-Hudson relation exists (a) because not all the member ways
>> have its name (since it borrows roads for short segments) and (b) because
>> Waymarked Trails and other data consumers do better with a route relation
>> grouping all the ways, rather than trying to assemble a route from ways
>> with nothing in common other than being named alike.
>>
>>>
>>> I assume this is not prefered because a number of applications use the
>>> names in the Ways themselves and not the Route Relation, most notably
>>> osm-carto.
>>>
>>>
>>> It renders the names of the paths, not the routes.
>>>
>>>
>>> However, some benefits of doing this might be:
>>>
>>>- Takes up less space in the DB
>>>- More tags that apply to the whole coute could be added to the
>>>Relation like surface
>>>=* and source
>>>=* (like the
>>>official map of the route).
>>>
>>>
>>> Surface has no place in a route relation as it refers diectly to the
>>> path, not the multiple relations passing along it. Similar for the source
>>> tag.
>>>
>>> DaveF
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>>
>>
>> --
>> 73 de ke9tv/2, Kevin
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> --
> Thanks,
> Seth
>


-- 
Thanks,
Seth
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging Cycle Route Relations vs. Ways

[stevea]

On Nov 16, 2020, at 7:09 PM, Seth Deegan  wrote:
> May I ask why not source=*? I know it's basically depreciated, but many times 
> I find myself wondering where past mappers got the info for a route (this 
> happened just today). I would find it very helpful. It also doesn't require 
> the tagging of all of the ways.

The source=* tag is largely deprecated by use of changeset comments indicating 
the source of elements in that changeset.  Because every element in the OSM 
database (whether a node, way, closed way or relation) is associated with the 
changeset in which it was written to the database, it is easy to get from one 
to the other.  Much UI in OSM that indicates either a database identifying 
number (again, of node, way or relation) or a changeset identifying number will 
easily map (logically, from the database) from one to the other.  This also 
allows the “chain of history” and “datum version number” to happen.  JOSM’s 
“Get Info” show one-for-the-other, OSM’s web display allows you to “go from” 
one to another (click a changeset, get displayed the data associated with it, 
click a datum, get displayed the changeset associated with it), many tools in 
OSM make these associations easy.  OSM is a database, after all.  It’s good 
when we can leverage that with sensible methods.  Moving source=* to the 
changeset comment does this, in addition to encouraging sensible limiting of 
vast, many-data changesets to contain a limited (ideally, a single) source of 
those data.

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

Re: [Tagging] Tagging Cycle Route Relations vs. Ways

[Seth Deegan]

May I ask why not source=*? I know it's basically depreciated, but many
times I find myself wondering where past mappers got the info for a route
(this happened just today). I would find it very helpful. It also doesn't
require the tagging of all of the ways.

On Mon, Nov 16, 2020 at 8:45 PM Kevin Kenny  wrote:

> On Mon, Nov 16, 2020 at 9:20 PM Dave F via Tagging <
> tagging@openstreetmap.org> wrote:
>
>> Be careful. This is where many contributors get confused. The name of the
>> *path* is often not the name of the *route*. A route relation can, & often
>> does, go along paths with different names. Multiple routes can go along a
>> path.
>>
>
> To give a more concrete example, there's a rail-trail in my neighborhood
> called the Mohawk-Hudson Bike-Hike Trail.
> It has a relation, for several reasons that I'll discuss below.  Most of
> its member ways are also named 'Mohawk-Hudson Bike-Hike Trail'. There are a
> few ways, however, that have the names of highways because freeways and
> active rail lines interrupt the rail grade, and the trail follows some
> lightly-trafficked streets for a short distance before rejoining the
> grade.  Those ways have name='Dunsbach Ferry Road', name='Island View
> Road', name='Scrafford Lane', name='Iroquois Street', etc, but remain
> members of the route named 'Mohawk-Hudson Bike-Hike Trail'. (Actually,
> there are two route relations: one for cycling and one for walking.)
>
> Large portions of the rail-trail are, in turn, used by two long-distance
> routes: the Erie Canalway Trail and the Empire State Trail.  There are
> separate relations for these two, and most of the members of the
> Mohawk-Hudson Bike-Hike Trail are also members of these other relations.
> (That does not affect the names of the member ways. The Mohawk-Hudson
> signage is consistent, while the signage for the other two trails is still
> something of a work in progress, although there's a lot more of it than
> there used to be. The naming of the member ways follows the commonest
> signage.)
>
> There are a great many member ways because of changes of the
> characteristics of the way (bridge=yes, embankment=yes, bicycle=dismount,
> surface changing from asphalt to wood on a bridge, and so on.)
>
>>
> The Mohawk-Hudson relation exists (a) because not all the member ways have
> its name (since it borrows roads for short segments) and (b) because
> Waymarked Trails and other data consumers do better with a route relation
> grouping all the ways, rather than trying to assemble a route from ways
> with nothing in common other than being named alike.
>
>>
>> I assume this is not prefered because a number of applications use the
>> names in the Ways themselves and not the Route Relation, most notably
>> osm-carto.
>>
>>
>> It renders the names of the paths, not the routes.
>>
>>
>> However, some benefits of doing this might be:
>>
>>- Takes up less space in the DB
>>- More tags that apply to the whole coute could be added to the
>>Relation like surface
>>=* and source
>>=* (like the official
>>map of the route).
>>
>>
>> Surface has no place in a route relation as it refers diectly to the
>> path, not the multiple relations passing along it. Similar for the source
>> tag.
>>
>> DaveF
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> --
> 73 de ke9tv/2, Kevin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Thanks,
Seth
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging Cycle Route Relations vs. Ways

[Kevin Kenny]

On Mon, Nov 16, 2020 at 9:20 PM Dave F via Tagging <
tagging@openstreetmap.org> wrote:

> Be careful. This is where many contributors get confused. The name of the
> *path* is often not the name of the *route*. A route relation can, & often
> does, go along paths with different names. Multiple routes can go along a
> path.
>

To give a more concrete example, there's a rail-trail in my neighborhood
called the Mohawk-Hudson Bike-Hike Trail.
It has a relation, for several reasons that I'll discuss below.  Most of
its member ways are also named 'Mohawk-Hudson Bike-Hike Trail'. There are a
few ways, however, that have the names of highways because freeways and
active rail lines interrupt the rail grade, and the trail follows some
lightly-trafficked streets for a short distance before rejoining the
grade.  Those ways have name='Dunsbach Ferry Road', name='Island View
Road', name='Scrafford Lane', name='Iroquois Street', etc, but remain
members of the route named 'Mohawk-Hudson Bike-Hike Trail'. (Actually,
there are two route relations: one for cycling and one for walking.)

Large portions of the rail-trail are, in turn, used by two long-distance
routes: the Erie Canalway Trail and the Empire State Trail.  There are
separate relations for these two, and most of the members of the
Mohawk-Hudson Bike-Hike Trail are also members of these other relations.
(That does not affect the names of the member ways. The Mohawk-Hudson
signage is consistent, while the signage for the other two trails is still
something of a work in progress, although there's a lot more of it than
there used to be. The naming of the member ways follows the commonest
signage.)

There are a great many member ways because of changes of the
characteristics of the way (bridge=yes, embankment=yes, bicycle=dismount,
surface changing from asphalt to wood on a bridge, and so on.)

>
The Mohawk-Hudson relation exists (a) because not all the member ways have
its name (since it borrows roads for short segments) and (b) because
Waymarked Trails and other data consumers do better with a route relation
grouping all the ways, rather than trying to assemble a route from ways
with nothing in common other than being named alike.

>
> I assume this is not prefered because a number of applications use the
> names in the Ways themselves and not the Route Relation, most notably
> osm-carto.
>
>
> It renders the names of the paths, not the routes.
>
>
> However, some benefits of doing this might be:
>
>- Takes up less space in the DB
>- More tags that apply to the whole coute could be added to the
>Relation like surface 
>=* and source =* (like
>the official map of the route).
>
>
> Surface has no place in a route relation as it refers diectly to the path,
> not the multiple relations passing along it. Similar for the source tag.
>
> DaveF
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging Cycle Route Relations vs. Ways

[Dave F via Tagging]

On 16/11/2020 16:17, Seth Deegan wrote:


The Cycle Routes Wiki Page 
 
states:


"It is preferred to tag the cycle routes using relations instead
of tagging the ways."

If I come across a route that has the Ways already tagged with the 
name =* of the route, 
can I delete the name 
=*s in the Ways and just 
create a Route Relation with the name?




Be careful. This is where many contributors get confused. The name of 
the *path* is often not the name of the *route*. A route relation can, & 
often does, go along paths with different names. Multiple routes can go 
along a path.


I assume this is not prefered because a number of applications use the 
names in the Ways themselves and not the Route Relation, most notably 
osm-carto.




It renders the names of the paths, not the routes.



However, some benefits of doing this might be:

  * Takes up less space in the DB
  * More tags that apply to the whole coute could be added to the
Relation like surface
=* and source
=* (like the
official map of the route).



Surface has no place in a route relation as it refers diectly to the 
path, not the multiple relations passing along it. Similar for the 
source tag.


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

Re: [Tagging] Tagging Cycle Route Relations vs. Ways

[Brian M. Sperlongano]

I don't map cycle routes, but the issue sounds similar to hiking routes and
administrative boundaries.

Long-distance hiking trails often traverse regular roads in between
stretches of woods.  So the trail's route relation is named "Such and Such
long distance trail" or whatever, but the parts on the road would have the
ways named according to whatever the road's name is.  For sections of trail
that are dedicated to the long distance trail, it may or may not have the
long distance trail's name repeated on the way.

For administrative boundaries, it is common (but not universal) to
duplicate relation tagging on member ways.  Both the relation AND the
member ways might have boundary=administrative, admin_level=, place=, etc.
This is something I run into because I develop an application that consumes
boundary data.  The duplication is unnecessary and just contributes to
database bloat.  I've actually gone as far as drafting a proposal [1] to
change the documentation that currently suggests this duplication.

[1]
https://wiki.openstreetmap.org/wiki/User:ZeLonewolf/proposals/Boundary_relation_way_members


On Mon, Nov 16, 2020 at 11:50 AM Volker Schmidt  wrote:

> The ways making up a cycle route typically have names themselves, and the
> Route name normally is not the name of the way,
> Hence in many cases this would be a mapping error, i.e. the name of the
> way is not correctly tagged in the database.
>
> There may be exceptions to this general, abstract statement, so it would
> be useful if you could five pointers to specific examples.
> For example it is well possible that a local administration assigns the
> name of the Route as name to a specific way that is part of the Route, so
> certainly any corrections need either local knowledge or street level
> photos that show name signs (e.g. Mapillary)
>
>
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_4670866037759433494_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Mon, 16 Nov 2020 at 17:22, Seth Deegan  wrote:
>
>> The Cycle Routes Wiki Page
>> 
>> states:
>> "It is preferred to tag the cycle routes using relations instead of
>> tagging the ways."
>>
>> If I come across a route that has the Ways already tagged with the name
>> =* of the route, can I
>> delete the name =*s in the
>> Ways and just create a Route Relation with the name?
>>
>> I assume this is not prefered because a number of applications use the
>> names in the Ways themselves and not the Route Relation, most notably
>> osm-carto.
>>
>> However, some benefits of doing this might be:
>>
>>- Takes up less space in the DB
>>- More tags that apply to the whole coute could be added to the
>>Relation like surface
>>=* and source
>>=* (like the official
>>map of the route).
>>- Ways with two or more routes wouldn't be tagged name
>>=route 1 & route 2
>>
>> 
>>  and
>>instead have their respective Relations. This could help with preferred
>>routing/data usage in general.
>>
>>
>> I would propose that *all* routes and their names should be tagged in a
>> Relation and *never* the Ways, even if the Route Relation only has *one
>> member*.
>>
>> This way data consumers know that all Routes are going to be relations.
>> Also future Routes mapped that share the Way of a Route that does not have
>> Relation, won't require the mapper to shift all of the data stored in the
>> Way to a new Relation.
>>
>> Also, if Proposed features/Relation:street
>>  is
>> ever approved, this would help establish a consistent OSM-wide routing
>> standard.
>>
>>
>> *As for now*, I do not think that we should be deleting the name
>> =*s of Ways. However, I
>> think osm-carto *should* render and *prefer* to render Relation names
>> for Cycle routes over the names of the Ways. The Editors should also
>> somehow influence users to map Relations for Cycle routes instead of naming
>> them.
>>
>>
>> Thoughts?
>> Seth Deegan (lectrician1)
>> ___
>> 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] Tagging Cycle Route Relations vs. Ways

[Seth Deegan]

Hidde thank you for the resources. I am aware of them. Also thank you for
mentioning Osm2pgsql. I know what it is, but your comment about how it's
meant compile relational data vs. how the OSM DB isn't is very true.

Thank you for the clarification too Peter.

I guess I'm just obsessed with relational DB models.

On Mon, Nov 16, 2020 at 12:23 PM Peter Elderson  wrote:

> AFAIK, a relation is meant to represent an entity of its own, which can be
> observed and verified in the field.
> Its tags should be the tags of this entity, not the tags shared by the
> members. It's not a relational database model.
>
> If many streets are called "Polygon Alley" you tag each one with
> name=Polygon Alley. No normalization applies, just tag it.
> Best, Peter Elderson
>
>
> Op ma 16 nov. 2020 om 18:17 schreef Seth Deegan :
>
>> Honestly I think I'm just confused.
>> I guess ways *do have* official names, it's just that I keep on thinking
>> about the possible *conceptual* conflicts between two different Routes
>> under one way (this statement probably doesn't make sense).
>>
>> Also, I'm someone who loves relations and finds myself thinking about
>> putting all of the elements that share a tag under a relation constantly!
>> I guess just keeping them in their original Ways is the way to go.
>>
>> However, *if there was a way* to indicate the "primary" relation for a
>> Way, then I'd be all for it.
>> IDK. Save space wherever possible seems to be the common theme.
>> Problems with this though would be that renderers/data consumers would
>> have to go into the relation every time they want to find more tags for an
>> element.
>> There are pros and cons. I'm also aware relations aren't categories.
>>
>> Thank you for the clarification.
>>
>> On Mon, Nov 16, 2020 at 10:55 AM Hidde Wieringa 
>> wrote:
>>
>>> Hello,
>>>
>>> Route relations 'group' together the nodes/ways/relations that form a
>>> cycling route. The nodes/ways/relations themselves should not be tagged
>>> with the name of the route, like you quoted the wiki.
>>>
>>> The name of a way should be the official name of the way, not the name
>>> of the relation(s) that way is part of. I refer to Key:name [1] which
>>> states "The names should be restricted to the name of the item in question
>>> only and should not include additional information not contained in the
>>> official name such as categories, types, descriptions, addresses, refs, or
>>> notes."
>>>
>>> So the question remains for the ways you mention that are tagged with
>>> name of the cycling route. Are those ways officially named exactly as the
>>> relation name? If not, I would classify this situation as 'tagging for the
>>> renderer' (getting the renderer to show the name of the cycling route).
>>>
>>> On the subject of rendering: there are many renderers that show cycling
>>> route relations [2]. Some of them [3] are even advanced enough to grasp the
>>> concept of 'superroutes'/'parentroutes' [4] that are common when tagging
>>> gigantic routes that span Europe like the EuroVelo cycling routes [5].
>>>
>>> Kind regards,
>>> *Hidde Wieringa*
>>>
>>> [1] https://wiki.openstreetmap.org/wiki/Key:name
>>> [2] https://wiki.openstreetmap.org/wiki/Cycle_routes#Rendered_cycle_maps
>>> [3] https://cycling.waymarkedtrails.org
>>> [4] https://wiki.openstreetmap.org/wiki/Relation:superroute
>>> [5]
>>> https://cycling.waymarkedtrails.org/#route?id=2763798=4!57.9189!7.9873
>>>
>>>
>>> On 16-11-2020 17:17, Seth Deegan wrote:
>>>
>>> The Cycle Routes Wiki Page
>>> 
>>> states:
>>> "It is preferred to tag the cycle routes using relations instead of
>>> tagging the ways."
>>>
>>> If I come across a route that has the Ways already tagged with the name
>>> =* of the route, can I
>>> delete the name =*s in
>>> the Ways and just create a Route Relation with the name?
>>>
>>> I assume this is not prefered because a number of applications use the
>>> names in the Ways themselves and not the Route Relation, most notably
>>> osm-carto.
>>>
>>> However, some benefits of doing this might be:
>>>
>>>- Takes up less space in the DB
>>>- More tags that apply to the whole coute could be added to the
>>>Relation like surface
>>>=* and source
>>>=* (like the
>>>official map of the route).
>>>- Ways with two or more routes wouldn't be tagged name
>>>=route 1 & route 2
>>>
>>> 
>>>  and
>>>instead have their respective Relations. This could help with preferred
>>>routing/data usage in general.
>>>
>>>
>>> I would propose that *all* routes and their names should be tagged in a
>>> Relation and 

Re: [Tagging] Tagging Cycle Route Relations vs. Ways

[Peter Elderson]

AFAIK, a relation is meant to represent an entity of its own, which can be
observed and verified in the field.
Its tags should be the tags of this entity, not the tags shared by the
members. It's not a relational database model.

If many streets are called "Polygon Alley" you tag each one with
name=Polygon Alley. No normalization applies, just tag it.
Best, Peter Elderson


Op ma 16 nov. 2020 om 18:17 schreef Seth Deegan :

> Honestly I think I'm just confused.
> I guess ways *do have* official names, it's just that I keep on thinking
> about the possible *conceptual* conflicts between two different Routes
> under one way (this statement probably doesn't make sense).
>
> Also, I'm someone who loves relations and finds myself thinking about
> putting all of the elements that share a tag under a relation constantly!
> I guess just keeping them in their original Ways is the way to go.
>
> However, *if there was a way* to indicate the "primary" relation for a
> Way, then I'd be all for it.
> IDK. Save space wherever possible seems to be the common theme.
> Problems with this though would be that renderers/data consumers would
> have to go into the relation every time they want to find more tags for an
> element.
> There are pros and cons. I'm also aware relations aren't categories.
>
> Thank you for the clarification.
>
> On Mon, Nov 16, 2020 at 10:55 AM Hidde Wieringa 
> wrote:
>
>> Hello,
>>
>> Route relations 'group' together the nodes/ways/relations that form a
>> cycling route. The nodes/ways/relations themselves should not be tagged
>> with the name of the route, like you quoted the wiki.
>>
>> The name of a way should be the official name of the way, not the name of
>> the relation(s) that way is part of. I refer to Key:name [1] which states
>> "The names should be restricted to the name of the item in question only
>> and should not include additional information not contained in the official
>> name such as categories, types, descriptions, addresses, refs, or notes."
>>
>> So the question remains for the ways you mention that are tagged with
>> name of the cycling route. Are those ways officially named exactly as the
>> relation name? If not, I would classify this situation as 'tagging for the
>> renderer' (getting the renderer to show the name of the cycling route).
>>
>> On the subject of rendering: there are many renderers that show cycling
>> route relations [2]. Some of them [3] are even advanced enough to grasp the
>> concept of 'superroutes'/'parentroutes' [4] that are common when tagging
>> gigantic routes that span Europe like the EuroVelo cycling routes [5].
>>
>> Kind regards,
>> *Hidde Wieringa*
>>
>> [1] https://wiki.openstreetmap.org/wiki/Key:name
>> [2] https://wiki.openstreetmap.org/wiki/Cycle_routes#Rendered_cycle_maps
>> [3] https://cycling.waymarkedtrails.org
>> [4] https://wiki.openstreetmap.org/wiki/Relation:superroute
>> [5]
>> https://cycling.waymarkedtrails.org/#route?id=2763798=4!57.9189!7.9873
>>
>>
>> On 16-11-2020 17:17, Seth Deegan wrote:
>>
>> The Cycle Routes Wiki Page
>> 
>> states:
>> "It is preferred to tag the cycle routes using relations instead of
>> tagging the ways."
>>
>> If I come across a route that has the Ways already tagged with the name
>> =* of the route, can I
>> delete the name =*s in the
>> Ways and just create a Route Relation with the name?
>>
>> I assume this is not prefered because a number of applications use the
>> names in the Ways themselves and not the Route Relation, most notably
>> osm-carto.
>>
>> However, some benefits of doing this might be:
>>
>>- Takes up less space in the DB
>>- More tags that apply to the whole coute could be added to the
>>Relation like surface
>>=* and source
>>=* (like the official
>>map of the route).
>>- Ways with two or more routes wouldn't be tagged name
>>=route 1 & route 2
>>
>> 
>>  and
>>instead have their respective Relations. This could help with preferred
>>routing/data usage in general.
>>
>>
>> I would propose that *all* routes and their names should be tagged in a
>> Relation and *never* the Ways, even if the Route Relation only has *one
>> member*.
>>
>> This way data consumers know that all Routes are going to be relations.
>> Also future Routes mapped that share the Way of a Route that does not have
>> Relation, won't require the mapper to shift all of the data stored in the
>> Way to a new Relation.
>>
>> Also, if Proposed features/Relation:street
>>  is
>> ever approved, this would help 

Re: [Tagging] Tagging Cycle Route Relations vs. Ways

[Hidde Wieringa]

You indicate that you are aware that relations aren't categories [1]. So 
indeed, grouping elements which share a certain tag is not useful. 
Finding nodes/ways that contain a certain tag is easily possible with 
specialized query tooling such as the Overpass API [2]. Data duplication 
across elements is not really an issue, and simplicity and correctness 
are more important.


What do you mean by the "primary relation for a way"? Relations group 
elements together, and as such a way can be part of any number of 
relations. The way itself does not 'know' if it is part of any relations 
(although you could query such information).


I want to mention tools like Osm2pgsql [3] which transforms the OSM data 
model to a relational database such as PostgreSQL. You can import vast 
amounts of data and pre-process it for your specific application if you 
so desire. You could group certain information together if your use-case 
would benefit from it.


Kind regards,
/Hidde Wieringa/

[1] 
https://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories

[2] https://dev.overpass-api.de/overpass-doc/en/
[3] https://osm2pgsql.org/



On 16-11-2020 18:13, Seth Deegan wrote:


Honestly I think I'm just confused.
I guess ways /do have/ official names, it's just that I keep on 
thinking about the possible /conceptual/ conflicts between two 
different Routes under one way (this statement probably doesn't 
make sense).


Also, I'm someone who loves relations and finds myself thinking about 
putting all of the elements that share a tag under a relation constantly!

I guess just keeping them in their original Ways is the way to go.

However, /if there was a way/ to indicate the "primary" relation for a 
Way, then I'd be all for it.

IDK. Save space wherever possible seems to be the common theme.
Problems with this though would be that renderers/data consumers would 
have to go into the relation every time they want to find more tags 
for an element.

There are pros and cons. I'm also aware relations aren't categories.

Thank you for the clarification.

On Mon, Nov 16, 2020 at 10:55 AM Hidde Wieringa 
mailto:hi...@hiddewieringa.nl>> wrote:


Hello,

Route relations 'group' together the nodes/ways/relations that
form a cycling route. The nodes/ways/relations themselves should
not be tagged with the name of the route, like you quoted the wiki.

The name of a way should be the official name of the way, not the
name of the relation(s) that way is part of. I refer to Key:name
[1] which states "The names should be restricted to the name of
the item in question only and should not include additional
information not contained in the official name such as categories,
types, descriptions, addresses, refs, or notes."

So the question remains for the ways you mention that are tagged
with name of the cycling route. Are those ways officially named
exactly as the relation name? If not, I would classify this
situation as 'tagging for the renderer' (getting the renderer to
show the name of the cycling route).

On the subject of rendering: there are many renderers that show
cycling route relations [2]. Some of them [3] are even advanced
enough to grasp the concept of 'superroutes'/'parentroutes' [4]
that are common when tagging gigantic routes that span Europe like
the EuroVelo cycling routes [5].

Kind regards,
/Hidde Wieringa/

[1] https://wiki.openstreetmap.org/wiki/Key:name

[2]
https://wiki.openstreetmap.org/wiki/Cycle_routes#Rendered_cycle_maps

[3] https://cycling.waymarkedtrails.org

[4] https://wiki.openstreetmap.org/wiki/Relation:superroute

[5]
https://cycling.waymarkedtrails.org/#route?id=2763798=4!57.9189!7.9873




On 16-11-2020 17:17, Seth Deegan wrote:


The Cycle Routes Wiki Page


states:

"It is preferred to tag the cycle routes using relations
instead of tagging the ways."

If I come across a route that has the Ways already tagged with
the name =* of the
route, can I delete the name
=*s in the Ways and
just create a Route Relation with the name?

I assume this is not prefered because a number of applications
use the names in the Ways themselves and not the Route Relation,
most notably osm-carto.

However, some benefits of doing this might be:

  * Takes up less space in the DB
  * More tags that apply to the whole coute could be added to the
Relation 

Re: [Tagging] Tagging Cycle Route Relations vs. Ways

[Seth Deegan]

Honestly I think I'm just confused.
I guess ways *do have* official names, it's just that I keep on thinking
about the possible *conceptual* conflicts between two different Routes
under one way (this statement probably doesn't make sense).

Also, I'm someone who loves relations and finds myself thinking about
putting all of the elements that share a tag under a relation constantly!
I guess just keeping them in their original Ways is the way to go.

However, *if there was a way* to indicate the "primary" relation for a Way,
then I'd be all for it.
IDK. Save space wherever possible seems to be the common theme.
Problems with this though would be that renderers/data consumers would have
to go into the relation every time they want to find more tags for an
element.
There are pros and cons. I'm also aware relations aren't categories.

Thank you for the clarification.

On Mon, Nov 16, 2020 at 10:55 AM Hidde Wieringa 
wrote:

> Hello,
>
> Route relations 'group' together the nodes/ways/relations that form a
> cycling route. The nodes/ways/relations themselves should not be tagged
> with the name of the route, like you quoted the wiki.
>
> The name of a way should be the official name of the way, not the name of
> the relation(s) that way is part of. I refer to Key:name [1] which states
> "The names should be restricted to the name of the item in question only
> and should not include additional information not contained in the official
> name such as categories, types, descriptions, addresses, refs, or notes."
>
> So the question remains for the ways you mention that are tagged with name
> of the cycling route. Are those ways officially named exactly as the
> relation name? If not, I would classify this situation as 'tagging for the
> renderer' (getting the renderer to show the name of the cycling route).
>
> On the subject of rendering: there are many renderers that show cycling
> route relations [2]. Some of them [3] are even advanced enough to grasp the
> concept of 'superroutes'/'parentroutes' [4] that are common when tagging
> gigantic routes that span Europe like the EuroVelo cycling routes [5].
>
> Kind regards,
> *Hidde Wieringa*
>
> [1] https://wiki.openstreetmap.org/wiki/Key:name
> [2] https://wiki.openstreetmap.org/wiki/Cycle_routes#Rendered_cycle_maps
> [3] https://cycling.waymarkedtrails.org
> [4] https://wiki.openstreetmap.org/wiki/Relation:superroute
> [5]
> https://cycling.waymarkedtrails.org/#route?id=2763798=4!57.9189!7.9873
>
>
> On 16-11-2020 17:17, Seth Deegan wrote:
>
> The Cycle Routes Wiki Page
> 
> states:
> "It is preferred to tag the cycle routes using relations instead of
> tagging the ways."
>
> If I come across a route that has the Ways already tagged with the name
> =* of the route, can I
> delete the name =*s in the
> Ways and just create a Route Relation with the name?
>
> I assume this is not prefered because a number of applications use the
> names in the Ways themselves and not the Route Relation, most notably
> osm-carto.
>
> However, some benefits of doing this might be:
>
>- Takes up less space in the DB
>- More tags that apply to the whole coute could be added to the
>Relation like surface 
>=* and source =* (like
>the official map of the route).
>- Ways with two or more routes wouldn't be tagged name
>=route 1 & route 2
>
> 
>  and
>instead have their respective Relations. This could help with preferred
>routing/data usage in general.
>
>
> I would propose that *all* routes and their names should be tagged in a
> Relation and *never* the Ways, even if the Route Relation only has *one
> member*.
>
> This way data consumers know that all Routes are going to be relations.
> Also future Routes mapped that share the Way of a Route that does not have
> Relation, won't require the mapper to shift all of the data stored in the
> Way to a new Relation.
>
> Also, if Proposed features/Relation:street
>  is
> ever approved, this would help establish a consistent OSM-wide routing
> standard.
>
>
> *As for now*, I do not think that we should be deleting the name
> =*s of Ways. However, I
> think osm-carto *should* render and *prefer* to render Relation names for
> Cycle routes over the names of the Ways. The Editors should also somehow
> influence users to map Relations for Cycle routes instead of naming them.
>
>
> Thoughts?
> Seth Deegan (lectrician1)
>
> ___
> Tagging mailing 
> 

Re: [Tagging] Tagging Cycle Route Relations vs. Ways

[Hidde Wieringa]

Hello,

Route relations 'group' together the nodes/ways/relations that form a 
cycling route. The nodes/ways/relations themselves should not be tagged 
with the name of the route, like you quoted the wiki.


The name of a way should be the official name of the way, not the name 
of the relation(s) that way is part of. I refer to Key:name [1] which 
states "The names should be restricted to the name of the item in 
question only and should not include additional information not 
contained in the official name such as categories, types, descriptions, 
addresses, refs, or notes."


So the question remains for the ways you mention that are tagged with 
name of the cycling route. Are those ways officially named exactly as 
the relation name? If not, I would classify this situation as 'tagging 
for the renderer' (getting the renderer to show the name of the cycling 
route).


On the subject of rendering: there are many renderers that show cycling 
route relations [2]. Some of them [3] are even advanced enough to grasp 
the concept of 'superroutes'/'parentroutes' [4] that are common when 
tagging gigantic routes that span Europe like the EuroVelo cycling 
routes [5].


Kind regards,
/Hidde Wieringa/

[1] https://wiki.openstreetmap.org/wiki/Key:name
[2] https://wiki.openstreetmap.org/wiki/Cycle_routes#Rendered_cycle_maps
[3] https://cycling.waymarkedtrails.org
[4] https://wiki.openstreetmap.org/wiki/Relation:superroute
[5] 
https://cycling.waymarkedtrails.org/#route?id=2763798=4!57.9189!7.9873



On 16-11-2020 17:17, Seth Deegan wrote:


The Cycle Routes Wiki Page 
 
states:


"It is preferred to tag the cycle routes using relations instead
of tagging the ways."

If I come across a route that has the Ways already tagged with the 
name =* of the route, 
can I delete the name 
=*s in the Ways and just 
create a Route Relation with the name?


I assume this is not prefered because a number of applications use the 
names in the Ways themselves and not the Route Relation, most notably 
osm-carto.


However, some benefits of doing this might be:

  * Takes up less space in the DB
  * More tags that apply to the whole coute could be added to the
Relation like surface
=* and source
=* (like the
official map of the route).
  * Ways with two or more routes wouldn't be tagged name
=route 1 & route 2


 and
instead have their respective Relations. This could help with
preferred routing/data usage in general.


I would propose that /all/ routes and their names should be tagged in 
a Relation and /never/ the Ways, even if the Route Relation only has 
/one member/.


This way data consumers know that all Routes are going to be 
relations. Also future Routes mapped that share the Way of a Route 
that does not have Relation, won't require the mapper to shift all of 
the data stored in the Way to a new Relation.


Also, if Proposed features/Relation:street 
 is 
ever approved, this would help establish a consistent OSM-wide routing 
standard.


*
*

*As for now*, I do not think that we should be deleting the name 
=*s of Ways. However, I 
think osm-carto /should/ render and /prefer/ to render Relation names 
for Cycle routes over the names of the Ways. The Editors should also 
somehow influence users to map Relations for Cycle routes instead of 
naming them.



Thoughts?

Seth Deegan (lectrician1)

___
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] Tagging Cycle Route Relations vs. Ways

[Volker Schmidt]

The ways making up a cycle route typically have names themselves, and the
Route name normally is not the name of the way,
Hence in many cases this would be a mapping error, i.e. the name of the way
is not correctly tagged in the database.

There may be exceptions to this general, abstract statement, so it would be
useful if you could five pointers to specific examples.
For example it is well possible that a local administration assigns the
name of the Route as name to a specific way that is part of the Route, so
certainly any corrections need either local knowledge or street level
photos that show name signs (e.g. Mapillary)




Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Mon, 16 Nov 2020 at 17:22, Seth Deegan  wrote:

> The Cycle Routes Wiki Page
> 
> states:
> "It is preferred to tag the cycle routes using relations instead of
> tagging the ways."
>
> If I come across a route that has the Ways already tagged with the name
> =* of the route, can I
> delete the name =*s in the
> Ways and just create a Route Relation with the name?
>
> I assume this is not prefered because a number of applications use the
> names in the Ways themselves and not the Route Relation, most notably
> osm-carto.
>
> However, some benefits of doing this might be:
>
>- Takes up less space in the DB
>- More tags that apply to the whole coute could be added to the
>Relation like surface 
>=* and source =* (like
>the official map of the route).
>- Ways with two or more routes wouldn't be tagged name
>=route 1 & route 2
>
> 
>  and
>instead have their respective Relations. This could help with preferred
>routing/data usage in general.
>
>
> I would propose that *all* routes and their names should be tagged in a
> Relation and *never* the Ways, even if the Route Relation only has *one
> member*.
>
> This way data consumers know that all Routes are going to be relations.
> Also future Routes mapped that share the Way of a Route that does not have
> Relation, won't require the mapper to shift all of the data stored in the
> Way to a new Relation.
>
> Also, if Proposed features/Relation:street
>  is
> ever approved, this would help establish a consistent OSM-wide routing
> standard.
>
>
> *As for now*, I do not think that we should be deleting the name
> =*s of Ways. However, I
> think osm-carto *should* render and *prefer* to render Relation names for
> Cycle routes over the names of the Ways. The Editors should also somehow
> influence users to map Relations for Cycle routes instead of naming them.
>
>
> Thoughts?
> Seth Deegan (lectrician1)
> ___
> 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] Tagging Cycle Route Relations vs. Ways

[Seth Deegan]

The Cycle Routes Wiki Page

states:
"It is preferred to tag the cycle routes using relations instead of tagging
the ways."

If I come across a route that has the Ways already tagged with the name
=* of the route, can I delete
the name =*s in the Ways and
just create a Route Relation with the name?

I assume this is not prefered because a number of applications use the
names in the Ways themselves and not the Route Relation, most notably
osm-carto.

However, some benefits of doing this might be:

   - Takes up less space in the DB
   - More tags that apply to the whole coute could be added to the Relation
   like surface =* and
   source =* (like the
   official map of the route).
   - Ways with two or more routes wouldn't be tagged name
   =route 1 & route 2
   

and
   instead have their respective Relations. This could help with preferred
   routing/data usage in general.


I would propose that *all* routes and their names should be tagged in a
Relation and *never* the Ways, even if the Route Relation only has *one
member*.

This way data consumers know that all Routes are going to be relations.
Also future Routes mapped that share the Way of a Route that does not have
Relation, won't require the mapper to shift all of the data stored in the
Way to a new Relation.

Also, if Proposed features/Relation:street
 is
ever approved, this would help establish a consistent OSM-wide routing
standard.


*As for now*, I do not think that we should be deleting the name
=*s of Ways. However, I think
osm-carto *should* render and *prefer* to render Relation names for Cycle
routes over the names of the Ways. The Editors should also somehow
influence users to map Relations for Cycle routes instead of naming them.


Thoughts?
Seth Deegan (lectrician1)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging