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

2020-11-18 Thread Peter Elderson
I see changeset source tags as the source(s) used for the work, not
necessarily the source of every change in the changeset.
Most of the source tags I see state the original source of the object, not
the latest source. The original source does not change when a tag or the
geometry is altered.

The history of objects tells me who has touched it, what has changed, but
not why and what the source was, and the associated changeset tags usually
only tell me why the object was affected, but nothing specific for the
object (unless the object happens to be the only thing changed in the
changeset).

I would rate this information: sometimes useful but not very reliable.
Technical improvements will not fix this.  What the mappers put there could
do with improvement. The challenge is how to get the mappers to do it.

Peter Elderson


Op wo 18 nov. 2020 om 19:09 schreef Martin Koppenhoefer <
dieterdre...@gmail.com>:

> Am Mi., 18. Nov. 2020 um 13:19 Uhr schrieb ael via Tagging <
> tagging@openstreetmap.org>:
>
>> On Wed, Nov 18, 2020 at 12:09:40AM +0100, Martin Koppenhoefer wrote:
>> We have tags like source:name and source:outline for more specific
>> tagging.
>>
>
>
> yes, every tag could get a source tag. It would mean a lot of additional
> work for mappers, and the benefit would probably be very small. Usually
> when you check an object for its correspondence with reality, you either
> find the tags accurate or wrong, for various reasons they could be wrong,
> most likely is a change of the thing in the real world. A source tag will
> not help you with this. To me, the most interesting information when
> looking at an edit is whether the person has been on the ground or not.
> source=Bing does not really tell you this, because many people use it when
> they are adding information and Bing is visible in the background, but it
> does not mean that every piece of information that they add actually comes
> from Bing.
>
>
>
>
>
>>
>> > From a practical point of view, I am mostly ignoring source tags,
>> because
>> > they are almost never accurate. Typically someone has added them some
>> > versions ago and nobody in between has bothered to remove or update the
>> > tag. To know this, you will have to dive into the object history anyway.
>>
>> Then  you are part of the problem :-) It is very annoying when the
>> source tag is accurate until someone, nearly always an armchair mapper,
>> who comes along and changes things without updating the source tag.
>>
>
>
> Most source tags I see are source=Bing and when I add information from a
> survey, I either do not change it, or sometimes I remove it because it is
> not valid any more at this point.
>
>
>>
>> Let's encourage people to use the source tag properly rather than cause
>> further decay. Or come up with a better solution, which is definitely
>> not a changeset comment.
>
>
>
> the changeset "comments" are actually structured tags, and from past
> discussions it is the preferred way over source tags on individual items.
> Source tags on items are the older method, they have already proven to fail
> in real world conditions in OSM ;-)
>
> 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] Tagging Cycle Route Relations vs. Ways

2020-11-18 Thread Martin Koppenhoefer
Am Mi., 18. Nov. 2020 um 13:19 Uhr schrieb ael via Tagging <
tagging@openstreetmap.org>:

> On Wed, Nov 18, 2020 at 12:09:40AM +0100, Martin Koppenhoefer wrote:
> We have tags like source:name and source:outline for more specific
> tagging.
>


yes, every tag could get a source tag. It would mean a lot of additional
work for mappers, and the benefit would probably be very small. Usually
when you check an object for its correspondence with reality, you either
find the tags accurate or wrong, for various reasons they could be wrong,
most likely is a change of the thing in the real world. A source tag will
not help you with this. To me, the most interesting information when
looking at an edit is whether the person has been on the ground or not.
source=Bing does not really tell you this, because many people use it when
they are adding information and Bing is visible in the background, but it
does not mean that every piece of information that they add actually comes
from Bing.





>
> > From a practical point of view, I am mostly ignoring source tags, because
> > they are almost never accurate. Typically someone has added them some
> > versions ago and nobody in between has bothered to remove or update the
> > tag. To know this, you will have to dive into the object history anyway.
>
> Then  you are part of the problem :-) It is very annoying when the
> source tag is accurate until someone, nearly always an armchair mapper,
> who comes along and changes things without updating the source tag.
>


Most source tags I see are source=Bing and when I add information from a
survey, I either do not change it, or sometimes I remove it because it is
not valid any more at this point.


>
> Let's encourage people to use the source tag properly rather than cause
> further decay. Or come up with a better solution, which is definitely
> not a changeset comment.



the changeset "comments" are actually structured tags, and from past
discussions it is the preferred way over source tags on individual items.
Source tags on items are the older method, they have already proven to fail
in real world conditions in OSM ;-)

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


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

2020-11-18 Thread Mateusz Konieczny via Tagging



Nov 18, 2020, 13:02 by tagging@openstreetmap.org:

> Let's encourage people to use the source tag properly rather than cause
> further decay. Or come up with a better solution, which is definitely
> not a changeset comment.
>
Source tag on the changeset.

Supported by all serious editors, if 
https://github.com/openstreetmap/iD/issues/7755
will be implemented it will be also encouraged by all serious editors.

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


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

2020-11-18 Thread Paul Johnson
On Wed, Nov 18, 2020 at 6:16 AM ael via Tagging 
wrote:

> Let's encourage people to use the source tag properly rather than cause
> further decay. Or come up with a better solution, which is definitely
> not a changeset comment.
>

source=* by itself on a way, relation or node is not useful.
source:keyname=* can help give hint on where something came from, but
ultimately, source=* works best as a changeset tag.  Every major editor
supports and encourages this.   The history browser in JOSM and osmcha.org
work well.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2020-11-18 Thread ael via Tagging
On Wed, Nov 18, 2020 at 12:09:40AM +0100, Martin Koppenhoefer wrote:
> Am Di., 17. Nov. 2020 um 20:04 Uhr schrieb stevea  >:
> 
> > I never said to NOT use source=* tags, they are correctly used on an
> > individual datum if / as it might diverge from a greater set of data that
> > otherwise has another source.  In short, if ALL of the data are from a
> > single source, use a changeset comment to note this.  If not, source=* tags
> > are appropriate.
> >
> 
> 
> I find the source tags in general problematic, most of all those "source"=*
> tags which do not relate to a specific tag. It may make sense for the
> creator of the object to add it, but what if someone changes something.
> E.g. you add a tag, or remove a tag, or change a value. What would you do
> with an existing source tag? Easy if you base your edit on the same source,
> otherwise, would you have to remove it? How much do you have to change in
> order to remove it? Or should you always be adding more values to the
> existing source string without ever removing anything, until you reach 255
> characters and then continue in a source2-tag?

We have tags like source:name and source:outline for more specific
tagging. And I have yet to see a source=one;two;three... which is
very long.

> From a practical point of view, I am mostly ignoring source tags, because
> they are almost never accurate. Typically someone has added them some
> versions ago and nobody in between has bothered to remove or update the
> tag. To know this, you will have to dive into the object history anyway.

Then  you are part of the problem :-) It is very annoying when the
source tag is accurate until someone, nearly always an armchair mapper,
who comes along and changes things without updating the source tag.

Let's encourage people to use the source tag properly rather than cause
further decay. Or come up with a better solution, which is definitely
not a changeset comment.

ael


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


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

2020-11-17 Thread Martin Koppenhoefer
Am Di., 17. Nov. 2020 um 20:04 Uhr schrieb stevea :

> I never said to NOT use source=* tags, they are correctly used on an
> individual datum if / as it might diverge from a greater set of data that
> otherwise has another source.  In short, if ALL of the data are from a
> single source, use a changeset comment to note this.  If not, source=* tags
> are appropriate.
>


I find the source tags in general problematic, most of all those "source"=*
tags which do not relate to a specific tag. It may make sense for the
creator of the object to add it, but what if someone changes something.
E.g. you add a tag, or remove a tag, or change a value. What would you do
with an existing source tag? Easy if you base your edit on the same source,
otherwise, would you have to remove it? How much do you have to change in
order to remove it? Or should you always be adding more values to the
existing source string without ever removing anything, until you reach 255
characters and then continue in a source2-tag?

>From a practical point of view, I am mostly ignoring source tags, because
they are almost never accurate. Typically someone has added them some
versions ago and nobody in between has bothered to remove or update the
tag. To know this, you will have to dive into the object history anyway.

I have been looking around (arbitrary examples I got by searching for
amenity=* and source=Bing with overpass, first hit, tried in 3 different
areas)  https://www.openstreetmap.org/way/145393264
source=Bing: which properties are from Bing, the address? The name? The
fact it is a kindergarten? Looking at the history, I can see that the tag
was already added in version 1 and that the node positions never changed.
The geometry fits reasonably well with Bing although it is far from
perfectly matching (I'd say it fits better with ESRI for instance). Likely
the Bing imagery has changed since 2012 when this was first drawn. IMHO in
this case there is no benefit from this tag.

Another arbitrary example, from another continent:
https://www.openstreetmap.org/node/2728286792
There is quite some detail information on this node, but I find it hard to
believe any of it came from Bing (imagery).

The third example is a post office:
https://www.openstreetmap.org/way/223059928
in this case it is also hardly anything from Bing, surely neither the name
nor the post office information.


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


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

2020-11-17 Thread stevea
DaveF:  I don’t wish to baffle, so I appreciate your clarifications.

I think we agree we don’t want “less correct” (out-of-date, etc.) data in OSM.  
We leave to the judgement of the Contributor whether data which are imported or 
curated from official sources IF those sources are of high enough quality 
(recent enough, accurate enough…) to enter into OSM.  If they are not, don’t 
import them.  That’s all I’m saying here.  I offer you my sincere apologies if 
I misinterpreted you.

SteveA


On Nov 17, 2020, at 11:31 AM, Dave F via Tagging  
wrote:
> On 17/11/2020 18:56, stevea wrote:
>> 
>>> I've found published data (from the authority
>>> authorised to amend the route) are often too inaccurate, out of date or
>>> lacking in detail to warrant transferring to OSM.
>> Then, don’t import, curate or transfer them to OSM.  I don’t believe we want 
>> "inaccurate, out-of-date or lacking in detail data" in OSM.
> 
> I'm baffled how you could completely misinterpret my comment about NOT 
> entering data which would reduce the quality of the OSM database.
> 
> DaveF

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


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

2020-11-17 Thread Dave F via Tagging

On 17/11/2020 18:56, stevea wrote:



I've found published data (from the authority
authorised to amend the route) are often too inaccurate, out of date or
lacking in detail to warrant transferring to OSM.

Then, don’t import, curate or transfer them to OSM.  I don’t believe we want 
"inaccurate, out-of-date or lacking in detail data" in OSM.


I'm baffled how you could completely misinterpret my comment about NOT 
entering data which would reduce the quality of the OSM database.


DaveF


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


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

2020-11-17 Thread stevea
On Nov 17, 2020, at 7:43 AM, Seth Deegan  wrote:
> A contributor can obtain data from many different sources within each
> changeset. Pushing the tag to the changeset meta data invalidates it's
> limited usefulness when added to individual objects.
> 
> Exactly.

I never said to NOT use source=* tags, they are correctly used on an individual 
datum if / as it might diverge from a greater set of data that otherwise has 
another source.  In short, if ALL of the data are from a single source, use a 
changeset comment to note this.  If not, source=* tags are appropriate.

> I've found published data (from the authority
> authorised to amend the route) are often too inaccurate, out of date or
> lacking in detail to warrant transferring to OSM.

Then, don’t import, curate or transfer them to OSM.  I don’t believe we want 
"inaccurate, out-of-date or lacking in detail data" in OSM.

> I find the opposite and I mostly map cycle routes that are local and I have 
> personally traveled on (I live in the Chicago metropolitan area). There are 
> just too many sources for trail names and data from forest preserve 
> districts/counties, cities, regional routes, etc. that I make routes from. I 
> can't just remember all of the trail names I come across (I don't survey).

It is good to enter source data when you know them.  However, it won’t be the 
downfall of OSM if you don’t.

> What I still don't understand is why you all are discouraging the use of 
> source=* tag (or maybe you're not?). Because it seems that it can still be of 
> use to some people. Why not let users know on the Wiki page that they can use 
> the tag if they might find a specific source helpful to other users, but that 
> they shouldn't tag imagery or other general sources per-element and instead 
> tag it on the changeset? Thank you for agreeing ael.

I don’t believe I did “discourage” the use of source=* although I regret if I 
gave the list that impression.  I believe I said changeset comments noting the 
source of the data “largely deprecates” using specific source=* tags on each 
specific datum, because I have gotten in the habit of (and think it a good 
idea) keeping my changes to those which derive from a specific source (whether 
“official” data or not, as I’ll enter “personal survey” or “my own GPX tracks” 
if true) in a single changeset.  However, knowing it is true that this isn’t 
always the case, OSM does reserve the flexibility to say “from County of Foobar 
GIS Department” in a changeset comment while SOME data in that same changeset 
might contain individual source=* tags of “personal survey” or “GPS wander, 
2020-11-17,” for example.  This isn’t a perfect system, I will not get 
sanctioned if I don’t enter the true source of every single datum I enter in 
OSM, but I do strive to identify my sources, less so individual-datum-at-a-time 
(though, I’ll still do that if there is the divergence I note here), moreso via 
a changeset comment that identifies that most or all of my data are from a 
single source (like one layer of satellite imagery, for example).

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


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

2020-11-17 Thread Seth Deegan
>
> 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).
>

Yes, the History button does do a good job. But I'm talking about this:

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.


In my opinion, the current changeset viewer UI is *useless*. Giving me a
list of elements that I can't even see what tags and geometries are changed
(when clicking on each element) is of no use to me. You can't even hover
over one of the elements in the list and see it's geometry outline in the
map viewbox (would).

If the interface displayed the kind of data like
https://osmlab.github.io/osm-deep-history/ did (Yves, you're right this is
the best one), or at least OSMcha, then it would be of use.

---

> A
> contributor can obtain data from many different sources within each
> changeset. Pushing the tag to the changeset meta data invalidates it's
> limited usefulness when added to individual objects.
>

Exactly.

I've found published data (from the authority
> authorised to amend the route) are often too inaccurate, out of date or
> lacking in detail to warrant transferring to OSM.
>

I find the opposite and I mostly map cycle routes that are local and I have
personally traveled on (I live in the Chicago metropolitan area). There are
just too many sources for trail names and data from forest preserve
districts/counties, cities, regional routes, etc. that I make routes from.
I can't just remember all of the trail names I come across (I don't survey).

---

What I still don't understand is why you all are *discouraging* the use of
source=* tag (or maybe you're not?). Because it seems that it can still be
of use to some people. Why not let users know on the Wiki page that they *can
*use the tag if they might find a *specific* source helpful to other users,
but that they shouldn't tag imagery or other general sources per-element
and instead tag it on the changeset? Thank you for agreeing ael.

On Tue, Nov 17, 2020 at 6:35 AM Martin Koppenhoefer 
wrote:

>
> sent from a phone
>
> > On 17. Nov 2020, at 06:23, stevea  wrote:
> >
> > to the degree they can be displayed in a narrow column on a web page
>
>
>
> yes, this is basically broken since the redesign (maybe 2012?), the
> history view used to provide a clearer overview on the full width, and this
> is something that could come back again? Or maybe invert the screen real
> estate division between map and history table.
> Josm has a decent history view integrated (ctrl+h) which let’s you compare
> between versions, links to changesets and shows for example position
> changes of nodes.
>
> Cheers Martin
> ___
> 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

2020-11-17 Thread Brian M. Sperlongano
The classic case for a "source" tag is for imports.  It's useful to know
that something came from a TIGER import, or from some public database or
wherever.  I think source=* makes sense when the data is literally coming
from some defined external place.

On Tue, Nov 17, 2020 at 10:36 AM Dave F via Tagging <
tagging@openstreetmap.org> wrote:

> On 17/11/2020 03:09, Seth Deegan wrote:
> > May I ask why not source=*?
>
> TBH. I'm not a fan of the tag. I don't think it adds much value. It's
> too subjective/variable, but...
>
> It relates to the individual contributor editing individual objects. A
> contributor can obtain data from many different sources within each
> changeset. Pushing the tag to the changeset meta data invalidates it's
> limited usefulness when added to individual objects.
>
> >  many times I find myself wondering where past mappers got the info
> > for a route (this happened just today).
>
> Anecdotal guesstimate: For cycle route - on the ground via signage for
> the vast majority. I've found published data (from the authority
> authorised to amend the route) are often too inaccurate, out of date or
> lacking in detail to warrant transferring to OSM.
>
> DaveF
>
>
> ___
> 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

2020-11-17 Thread Dave F via Tagging

On 17/11/2020 03:09, Seth Deegan wrote:

May I ask why not source=*?


TBH. I'm not a fan of the tag. I don't think it adds much value. It's 
too subjective/variable, but...


It relates to the individual contributor editing individual objects. A 
contributor can obtain data from many different sources within each 
changeset. Pushing the tag to the changeset meta data invalidates it's 
limited usefulness when added to individual objects.


 many times I find myself wondering where past mappers got the info 
for a route (this happened just today).


Anecdotal guesstimate: For cycle route - on the ground via signage for 
the vast majority. I've found published data (from the authority 
authorised to amend the route) are often too inaccurate, out of date or 
lacking in detail to warrant transferring to OSM.


DaveF


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


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

2020-11-17 Thread Martin Koppenhoefer

sent from a phone

> On 17. Nov 2020, at 06:23, stevea  wrote:
> 
> to the degree they can be displayed in a narrow column on a web page



yes, this is basically broken since the redesign (maybe 2012?), the history 
view used to provide a clearer overview on the full width, and this is 
something that could come back again? Or maybe invert the screen real estate 
division between map and history table.
Josm has a decent history view integrated (ctrl+h) which let’s you compare 
between versions, links to changesets and shows for example position changes of 
nodes.

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


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

2020-11-17 Thread ael via Tagging
On Mon, Nov 16, 2020 at 08:25:43PM -0800, stevea wrote:
> 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.

+1
> The source=* tag is largely deprecated by use of changeset comments 
> indicating the source of elements in that changeset.


The idea that changeset comments can in any way replace the source tag
is in MHO ridiculous. In even a small changeset, there are typically a
whole range of sources for different elements. It is just too
coarse-grained to be useful. Maybe for armchair mappers who only have
one source, updating data that has only ever been armchair mapped it
could be adequate.

ael


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


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

2020-11-16 Thread 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

2020-11-16 Thread 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

2020-11-16 Thread 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

2020-11-16 Thread 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

2020-11-16 Thread 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

2020-11-16 Thread 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

2020-11-16 Thread 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

2020-11-16 Thread 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

2020-11-16 Thread 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

2020-11-16 Thread 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

2020-11-16 Thread 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

2020-11-16 Thread 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

2020-11-16 Thread 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

2020-11-16 Thread 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

2020-11-16 Thread 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