Re: [Tagging] How to put a name tag on an area with more than one type?

[Anders Torger]

Why is the relation problematic (honest question)?

I was starting to think that some sort of naming relation could be the 
answer, ie you put both peaks in a relation with for example type=name; 
natural=mountain; name=Kebnekaise.


In addition one should write clearly that peak serves dual purpose both 
as naming peaks and mountains. Today on the wiki the peak is clearly 
defined as only the summit, but it's often used as naming mountains 
where the peak is nameless.


What we also could have is fuzzy naming areas, which we would need in 
some way or another at some point anyway, so you would have an area 
covering the mountain with name=Kebnekaise. I would have no problem with 
that, but it seems to that it must be in a separate database as it just 
too controversial to be in the main database.


/Anders

On 2020-12-13 21:12, Mateusz Konieczny via Tagging wrote:


Dec 13, 2020, 19:58 by and...@torger.se:

Do you have a suggestion of how to map Sweden's highest mountain, 
Kebnekaise?


The mountain is called Kebnekaise, it has two peaks, one is called 
"Sydtoppen" ("the south peak"), the other "Nordtoppen" ("the north 
peak").


I admit that I have no good idea, if I would run into such case and 
failed to find a better idea

(hopefully one will come) I would invent a new way to tag that.

natural=mountain? Main problem is where to put it - node at arbitrary 
position between peaks?
Node at location of highest peak? Area? Relation? All of that is sadly 
problematic.


(The mountain_range tag is a great tag, but I note that its status is 
just "in use", it's not an approved tag :-O.)


It is perfectly fine to use tags that never went through tagging 
proposal, though
I am not going to endorse this one. Tagging mountain ranges seems to 
poorly fit OSM
with multiple different opinions where mountain range starts/ends and 
inability to

verify it by survey.

All tags were in some stage rarely used before becoming heavily used,
only some cases went through a proposal process.
___
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] How to tag entire group of rentable holiday cottages?

[Martin Koppenhoefer]

sent from a phone

> On 14. Dec 2020, at 07:22, Mateusz Konieczny via Tagging 
>  wrote:
> 
> There are cases where there is group of multiple holiday cottages,
> 
> each rentable independently. I know about cases with just 2 and big groups, 
> 25 in one place.


leisure=resort?

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

Re: [Tagging] How to put a name tag on an area with more than one type?

[Anders Torger]

I'll gladly answer questions, but I think you need to rephrase. I 
suppose it is some hidden critique in there, but I honestly do not 
understand the question. It would be better for me if you put words on 
the critique instead of wrapping it in a question.


I think it's fairly obvious that if the common method to tie together 
several separate entities that has a single name is to make a single 
multipolygon-relation with several outers, there should also be a 
relation for a single named entity with multiple natural types. It can't 
be a multipolygon, so it must be something else.


Naming single entity natural features split into several sub-types is 
currently not a supported feature by OSM, although it is very hard to 
get people to actually say that (some do on this list, some don't). And 
after that it's very hard to get a statement if this missing feature is 
desirable to implement, or if OSM is not the place for this type of 
detailed geo data.


I find that you are one of those that are very mysterious about what you 
actually think ;-), but seems to strive for status quo, so I assume that 
you think that the thing I need here is already supported sufficiently 
well, but I don't know, as you haven't said.


/Anders

On 2020-12-13 20:37, Christoph Hormann wrote:

Anders Torger  hat am 13.12.2020 20:08 geschrieben:

[...] I think to actually have them all
tied together in a unit is still a good idea, [...]


That does not answer my question.


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

Re: [Tagging] How to put a name tag on an area with more than one type?

[Anders Torger]

Like every Swede I have climbed the mountain, so I do have some local 
knowledge :-). There is an arete there, that's correct, but it's not 
named. Kebnekaise is the name of the mountain. It's Sami lands, as far 
as I understand the names of the mountains came first, then the names of 
the peaks came much later when people got interested in mountaineering, 
hence often anonymous names like "the grand peak", "the south peak" etc. 
In the past noone had time to entertain themselves with climbing 
mountains for fun :-).


If we go to lower mountains in Sweden then peaks generally fit better as 
then people were closer around and hence say 90% of the time the 
mountain name is also the peak name. But sometimes there's a situation 
when the mountain has more than one peak, none of which is named, but 
the mountain is named. There's also situations where there are multiple 
nearby small peaks with separate names, and then the all have a group 
name, without really being a huge massif (the example I'm thinking about 
all small peaks are within 5 km on a single mountain).


/Anders

On 2020-12-13 21:30, Joseph Eisenberg wrote:

Currently the features with the tag "name=Kebnekaise" are 2 ways which 
extend north-south and to the west from these two peaks and are also 
tagged natural=arete (an arete is a knife-edged ridge formed between 2 
glaciers).


https://www.openstreetmap.org/way/123215393#map=13/67.8934/18.4509=C 
https://www.openstreetmap.org/way/407174801#map=14/67.8999/18.5215=C


Is this correct based on your local knowledge of the area?___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to tag entire group of rentable holiday cottages?

[Graeme Fitzpatrick]

On Mon, 14 Dec 2020 at 16:22, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
> Tagging 25 tourism=chalet independently is sill when they form
> single object, not 25 separate ones.
>

Are they cottages number 1 - 25 on the same camp site, or individual
chalets located close to each other?

Thanks

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

[Tagging] How to tag entire group of rentable holiday cottages?

[Mateusz Konieczny via Tagging]

There are cases where there is group of multiple holiday cottages,

each rentable independently. I know about cases with just 2 and big groups, 25 
in one place.

How it should be tagged?

I found https://wiki.openstreetmap.org/wiki/Tag:tourism%3Dchalet
that is for a single one.

Tagging 25 tourism=chalet independently is sill when they form
single object, not 25 separate ones.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature proposal - RFC 2 - Pumping proposal

[Volker Schmidt]

My main point got lost: the proposal should explain how the mapping of
pumps in pumping stations should be handled, short of using indoor mapping,
especially as your cover photo shows an indoors pump in an industrial
building.


On Mon, 14 Dec 2020, 00:40 Brian M. Sperlongano, 
wrote:

> François, thank you for your hard work on this proposal!  I will most
> likely support this version.  I have a few questions:
>
> 1. The proposal states "It is proposed to discourage the use of
> undocumented pump:type=* to state pump mechanisms in favour of new
> pump_mechanism=*."  It is not clear what is meant by "discourage" in this
> context.  Given the other threads today regarding reservoirs, it is
> important to communicate clearly what we mean when we propose to stop using
> a tag.  I would ask that instead of "discourage", that the proposal should
> explicitly say "deprecate" so that there is no confusion that you intend
> for us to stop using pump:type and document it as deprecated in the
> deprecated features list.  Otherwise, I would ask that you clearly and
> explicitly state what you mean by "discourage" and where those words of
> discouragement would go.
>
> 2.  You propose to deprecate man_made=pumping_rig and propose to replace
> it with the (far more popular) man_made=petroleum_well.  Both of these are
> combined with the substance=* key.  I would ask whether there are usages of
> pumping_rig that are being used with substance=* tags for non-petroleum
> products (i.e. not oil/natural gas) which would be lost by abandoning this
> pumping_rig?  If the answer is "yes", then I would support simply changing
> the description of pumping_rig to explicitly exclude petroleum products,
> and if the answer is "no" then I agree with deprecating it.
>
>
> On Sun, Dec 13, 2020 at 1:48 PM François Lacombe <
> fl.infosrese...@gmail.com> wrote:
>
>> Dear all,
>>
>> Following some rework to take care of comments received during the first
>> voting round of pumping proposal, here is a second proposed version
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Pumping_proposal
>>
>> IanVG and I spent time to improve wording and make rationale section
>> clearer.
>> Classification of pumps is now done with pump_mechanism and is still
>> equivalent to which available on Wikipedia. Numerous references are made
>> toward it.
>>
>> Additional examples and illustrating gifs have been added at the bottom
>> as well.
>>
>> This message opens a second RFC period and is expected to be shorter.
>> Vote could begin by next Saturday.
>>
>> Best regards
>>
>> François
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature proposal - RFC 2 - Pumping proposal

[Brian M. Sperlongano]

François, thank you for your hard work on this proposal!  I will most
likely support this version.  I have a few questions:

1. The proposal states "It is proposed to discourage the use of
undocumented pump:type=* to state pump mechanisms in favour of new
pump_mechanism=*."  It is not clear what is meant by "discourage" in this
context.  Given the other threads today regarding reservoirs, it is
important to communicate clearly what we mean when we propose to stop using
a tag.  I would ask that instead of "discourage", that the proposal should
explicitly say "deprecate" so that there is no confusion that you intend
for us to stop using pump:type and document it as deprecated in the
deprecated features list.  Otherwise, I would ask that you clearly and
explicitly state what you mean by "discourage" and where those words of
discouragement would go.

2.  You propose to deprecate man_made=pumping_rig and propose to replace it
with the (far more popular) man_made=petroleum_well.  Both of these are
combined with the substance=* key.  I would ask whether there are usages of
pumping_rig that are being used with substance=* tags for non-petroleum
products (i.e. not oil/natural gas) which would be lost by abandoning this
pumping_rig?  If the answer is "yes", then I would support simply changing
the description of pumping_rig to explicitly exclude petroleum products,
and if the answer is "no" then I agree with deprecating it.


On Sun, Dec 13, 2020 at 1:48 PM François Lacombe 
wrote:

> Dear all,
>
> Following some rework to take care of comments received during the first
> voting round of pumping proposal, here is a second proposed version
> https://wiki.openstreetmap.org/wiki/Proposed_features/Pumping_proposal
>
> IanVG and I spent time to improve wording and make rationale section
> clearer.
> Classification of pumps is now done with pump_mechanism and is still
> equivalent to which available on Wikipedia. Numerous references are made
> toward it.
>
> Additional examples and illustrating gifs have been added at the bottom as
> well.
>
> This message opens a second RFC period and is expected to be shorter. Vote
> could begin by next Saturday.
>
> Best regards
>
> François
> ___
> 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] Feature proposal - RFC 2 - Pumping proposal

[François Lacombe]

Hi Mateusz, Joseph,

You were right, it was mistakes and it's now fixed. Thank you for you
vigilance.

Le dim. 13 déc. 2020 à 23:17, Volker Schmidt  a écrit :

> Missing at first glance: what is the mapper expected to do with pumping
> stations.
>

Hi Volker
Anyone could map man_made=pumping_station only if he/she wants. It's okay.

As you mention, pumps can be added with enough knowledge or public
documentation but it's not mandatory at all.
Goal of proposal isn't to force to map every each pumps but only facilities
that are publicly accessible.
Sometimes, operators could post a tweet showing pumps inside the building
for instance.
https://twitter.com/KSBfrance/status/1337390441000538118?s=20

Anyway man_made=pumping_station won't be replaced by anything in this
proposal and will be used independently.

All the best

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

Re: [Tagging] Proposed feature - RFC - Military Bases

[Graeme Fitzpatrick]

On Sun, 13 Dec 2020 at 19:17, Martin Koppenhoefer 
wrote:

>
> fully spelt out
>

Noted.

Thanks

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

Re: [Tagging] Feature proposal - RFC 2 - Pumping proposal

[Volker Schmidt]

Missing at first glance: what is the mapper expected to do with pumping
stations.
We have around here in the Po valley, thousands of them for draining
purposes., and I presume that places like the Netherland have considerably
more of them. Many are housed in dedicated and locked buildings and they
often house several large pumps.
Normally you find the name of the operator posted somewhere.
Sometimes they have signs outside, giving the pumping capacity.
Sometimes, I can see the pipes, and that gives me an idea how many pumps
there are.
I also know that nowadays , apart from museums, pumps are operated by
electrical power.
The rest I don't know, and I would have to consult the web site of the
operator, as it may give some information.
But I think that goes far beyond what a normal mapper without specific
knowledge in pumps would ever do.
I am already happy if people map a man_mde=pumping_station and not only
building=industrial.







Virus-free.
www.avast.com

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

On Sun, 13 Dec 2020 at 21:08, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Pumping_proposal#Examples
>
> Looking at the first example - I see nothing clearly indicating that pump
> is operated
> by muscle power.
>
> Is it intentional to not include this distinction?
>
>
> Dec 13, 2020, 19:45 by fl.infosrese...@gmail.com:
>
> Dear all,
>
> Following some rework to take care of comments received during the first
> voting round of pumping proposal, here is a second proposed version
> https://wiki.openstreetmap.org/wiki/Proposed_features/Pumping_proposal
>
> IanVG and I spent time to improve wording and make rationale section
> clearer.
> Classification of pumps is now done with pump_mechanism and is still
> equivalent to which available on Wikipedia. Numerous references are made
> toward it.
>
> Additional examples and illustrating gifs have been added at the bottom as
> well.
>
> This message opens a second RFC period and is expected to be shorter. Vote
> could begin by next Saturday.
>
> Best regards
>
> François
>
>
> ___
> 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] Feature Proposal - RFC - crossing=priority

[Peter Elderson]

Colin Smale  het volgende geschreven:
> 
> 
>> 
>> On 2020-12-13 21:53, Peter Elderson wrote:
>> 
>> Just to clarify:
>>  
>> > crossing=priority Indicates that the node is a pedestrian crossing  
>> when applied to highway=cycleway, should this read bicycle crossing?  
>>  
>> when applied to a highway=cycleway, does the tag imply priority for 
>> cyclists, pedestrians, or both?
>>  
> And what happens if a cycleway crosses a footway, as happens commonly here in 
> the Netherlands?
>  
> We also have an analogous problem here where cycle tracks cross roads. In 
> many (but nowhere near all) cases the cycleway has priority

To be clear, traffic from the right has priority, unless signing indicates 
otherwise. Pedestrians have to give way, unless zebra marking indicate they 
have right of way. Dismounted cyclists count as pedestrians. Flashing bulbs 
have been banished a long time ago, in favor of (fluorescent or backlighted) 
"zebra ahead" warning signs.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - crossing=priority

[Graeme Fitzpatrick]

On Mon, 14 Dec 2020 at 06:37, stevea  wrote:

> This is problematic to my thinking.  In California (my state), at an
> UNCONTROLLED intersection (no traffic_signal, stop sign, other traffic
> control device...), for example where the sidewalk "would continue to
> another sidewalk on the other side of the roadway," pedestrians ALWAYS have
> the right-of-way (over all vehicles) when they indicate it.  How do they
> indicate it?  By lifting one foot to step towards / into the intersection
> (from the sidewalk).  Drivers must (by law) stop short of entering the
> intersection to allow the pedestrian to cross, once a pedestrian has so
> entered the crossing (even it if is unmarked or "invisible").
>

Australia goes even a bit further in that pedestrians always have
right-of-way, regardless of crossings (marked or unmarked) or not.

https://roadsafety.transport.nsw.gov.au/stayingsafe/pedestrians/needtoknow/index.html

" Drivers must give way to pedestrians crossing the road into which their
vehicles are turning. You must also give way to pedestrians if there is a
danger of colliding with them, even if there is no marked pedestrian
crossing.

Thanks

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

Re: [Tagging] Feature Proposal - RFC - crossing=priority

[Volker Schmidt]

In principle a good idea.
In the jurisdictions I am familiar with, any marked pedestrian crossing
gives priority to pedestrians over the traffic on the crossed road.
Unmarked crossing (no vertical sign, no horizontal sign) means no priority.
And each country has developed their own tagging on how to to map them in
OSM, and sometimes more than one,.
But the priority rules are more complex than you ay be aware of, when it
comes to cyclists crossing as well, which is a common situation.

Specifically in Italy we do have a strange situation, that cannot be
tackled with any tagging, unless you tag 0nly the the signage, but not
their meaning.
On normal pedestrian crossings cyclists riding their bike have no priority,
they need to dismount and push their bike, as pedestrians, to have the
priority.
On explicitly marked bicycle-only crossings or  bicycle-plus-foot crossings
they have the priority without dismounting.
So far so good
If a pedestrian-only crossing is painted and signposted to connect two
mixed foot-cycle-paths, cyclists have the priority even if the road signs
do not  show it (and it is ìonly based on some legal cases, but i tis not
written in the Highway Code.
The solution is to map what is on the ground, i.e. the signing, but leaving
the interpretation of the signing to the road user. .

In addition we have another area of uncertainty, i.e. the cases when
footways meet cycleways.As far as I know there are simply no rules for that
case.




Virus-free.
www.avast.com

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

On Sun, 13 Dec 2020 at 21:55, Peter Elderson  wrote:

> Just to clarify:
>
> > crossing=priority Indicates that the node is a pedestrian crossing  
> when applied to highway=cycleway, should this read bicycle crossing?
>
> when applied to a highway=cycleway, does the tag imply priority for
> cyclists, pedestrians, or both?
>
> > belisha_beacon=yes|no
> Is belisha beacon a generally known term outside the UK?
> Since only presence is significant,  the value no is useless
>
> > segregated=boolean (yes/no) (no default assumed)
>
> Since the proposal talks about pedestrians, cycleways and horses crossing:
> what exactly is segregated when segregated=yes is applied to a cycleway?
> And with segregated=no, do motorists get a warning that horses may cross on
> the cycleway?
>
>
> Peter Elderson
>
>
> Op zo 13 dec. 2020 om 21:08 schreef ipswichmapper--- via Tagging <
> tagging@openstreetmap.org>:
>
>> Yes, most likely this won't be required. However I have kept it there in
>> case it works differently in other countries. Maybe not all zebra crossings
>> in Singapore have belisha beacons (for example, I don't know if this is
>> true). That is why I am leaving it open for discussion for now, if after
>> the RFC it is decided that this is a bad idea I'll remove it.
>>
>> Thanks,
>> IpswichMapper
>>
>> --
>>
>>
>> 13 Dec 2020, 19:50 by tagging@openstreetmap.org:
>>
>> It seems to be proposing also belisha_beacon=yes that
>> is now unused
>> https://taginfo.openstreetmap.org//search?q=belisha_beacon%3Dyes
>>
>> At the same time it has
>> "However, in countries like the UK, where belisha beacons are used, every
>> single zebra crossing has belisha beacons installed, so there is no need
>> to tag them"
>>
>> There is also
>> "Indicates the presence of a "belisha beacon" at the crossing. (Most
>> likely unnecessary, discuss below)"
>>
>> Given there is no indication that it would be useful or needed I think
>> that it should be not proposed.
>>
>> If that it would be useful or needed it can be proposed separately.
>>
>> Note that having two proposals in one will result in people voting against
>> if there are against any of them, so splitting would be a good idea
>> anyway.
>>
>> Dec 13, 2020, 20:25 by tagging@openstreetmap.org:
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/crossing%3Dpriority
>> 
>>
>> Here is my first proposal for a tag to describe pedestrian crossings
>> where the pedestrian has right of way over all vehicles on the road from
>> the moment they have indicated their intent to cross. I created this
>> because "crossing=zebra" or "crossing=marked" aren't clear enough. Please
>> read the proposal for more details.
>>
>> Thanks,
>> IpswichMapper
>>
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - crossing=priority

[Colin Smale]

On 2020-12-13 21:53, Peter Elderson wrote:

> Just to clarify: 
>> crossing=priority Indicates that the node is a pedestrian crossing   
> when applied to highway=cycleway, should this read bicycle crossing?  
> 
> when applied to a highway=cycleway, does the tag imply priority for cyclists, 
> pedestrians, or both?

And what happens if a cycleway crosses a footway, as happens commonly
here in the Netherlands? 

We also have an analogous problem here where cycle tracks cross roads.
In many (but nowhere near all) cases the cycleway has priority.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - crossing=priority

[Peter Elderson]

Just to clarify:

> crossing=priority Indicates that the node is a pedestrian crossing  
when applied to highway=cycleway, should this read bicycle crossing?

when applied to a highway=cycleway, does the tag imply priority for
cyclists, pedestrians, or both?

> belisha_beacon=yes|no
Is belisha beacon a generally known term outside the UK?
Since only presence is significant,  the value no is useless

> segregated=boolean (yes/no) (no default assumed)

Since the proposal talks about pedestrians, cycleways and horses crossing:
what exactly is segregated when segregated=yes is applied to a cycleway?
And with segregated=no, do motorists get a warning that horses may cross on
the cycleway?


Peter Elderson


Op zo 13 dec. 2020 om 21:08 schreef ipswichmapper--- via Tagging <
tagging@openstreetmap.org>:

> Yes, most likely this won't be required. However I have kept it there in
> case it works differently in other countries. Maybe not all zebra crossings
> in Singapore have belisha beacons (for example, I don't know if this is
> true). That is why I am leaving it open for discussion for now, if after
> the RFC it is decided that this is a bad idea I'll remove it.
>
> Thanks,
> IpswichMapper
>
> --
>
>
> 13 Dec 2020, 19:50 by tagging@openstreetmap.org:
>
> It seems to be proposing also belisha_beacon=yes that
> is now unused
> https://taginfo.openstreetmap.org//search?q=belisha_beacon%3Dyes
>
> At the same time it has
> "However, in countries like the UK, where belisha beacons are used, every
> single zebra crossing has belisha beacons installed, so there is no need
> to tag them"
>
> There is also
> "Indicates the presence of a "belisha beacon" at the crossing. (Most
> likely unnecessary, discuss below)"
>
> Given there is no indication that it would be useful or needed I think
> that it should be not proposed.
>
> If that it would be useful or needed it can be proposed separately.
>
> Note that having two proposals in one will result in people voting against
> if there are against any of them, so splitting would be a good idea
> anyway.
>
> Dec 13, 2020, 20:25 by tagging@openstreetmap.org:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/crossing%3Dpriority
> 
>
> Here is my first proposal for a tag to describe pedestrian crossings where
> the pedestrian has right of way over all vehicles on the road from the
> moment they have indicated their intent to cross. I created this because
> "crossing=zebra" or "crossing=marked" aren't clear enough. Please read the
> proposal for more details.
>
> Thanks,
> IpswichMapper
>
>
>
> ___
> 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] Feature Proposal - RFC - crossing=priority

[Alex]

You could use "crossing:belisha_beacon" (like crossing:island etc.), but
I don't think it has to be part of the proposal. In my area we started
to use "crossing:kerb_extension" and "crossing:buffer_markings" this
year, see here:
https://wiki.openstreetmap.org/wiki/Berlin/Verkehrswende/Fu%C3%9Fwege#Gehwegvorstreckung
(still under development and unfortunately only in German language at
the moment)


Am 13.12.20 um 21:06 schrieb ipswichmapper--- via Tagging:
> Yes, most likely this won't be required. However I have kept it there in case 
> it works differently in other countries. Maybe not all zebra crossings in 
> Singapore have belisha beacons (for example, I don't know if this is true). 
> That is why I am leaving it open for discussion for now, if after the RFC it 
> is decided that this is a bad idea I'll remove it.
>
> Thanks,
> IpswichMapper
> -- 
>
> 13 Dec 2020, 19:50 by tagging@openstreetmap.org:
>
>> It seems to be proposing also belisha_beacon=yes that
>> is now unused
>> https://taginfo.openstreetmap.org//search?q=belisha_beacon%3Dyes
>>
>> At the same time it has 
>> "However, in countries like the UK, where belisha beacons are used, every 
>> single zebra crossing has belisha beacons installed, so there is no need to 
>> tag them"
>>
>> There is also
>> "Indicates the presence of a "belisha beacon" at the crossing. (Most likely 
>> unnecessary, discuss below)"
>>
>> Given there is no indication that it would be useful or needed I think
>> that it should be not proposed.
>>
>> If that it would be useful or needed it can be proposed separately.
>>
>> Note that having two proposals in one will result in people voting against
>> if there are against any of them, so splitting would be a good idea
>> anyway.
>>
>> Dec 13, 2020, 20:25 by tagging@openstreetmap.org:
>>
>>> https://wiki.openstreetmap.org/wiki/Proposed_features/crossing%3Dpriority 
>>> 
>>>
>>> Here is my first proposal for a tag to describe pedestrian crossings where 
>>> the pedestrian has right of way over all vehicles on the road from the 
>>> moment they have indicated their intent to cross. I created this because 
>>> "crossing=zebra" or "crossing=marked" aren't clear enough. Please read the 
>>> proposal for more details.
>>>
>>> Thanks,
>>> IpswichMapper
>>>
>>
>
>
> ___
> 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] Feature Proposal - RFC - crossing=priority

[Alex]

I have just commented on it in the Wiki: A crossing-proposal at the
current time should go a bit further and deprecate
crossing=uncontrolled. Fortunately, this value is very increasingly
being replaced by more distinctive terms, especially "unmarked" or
"marked" – that should be reflected in a new proposal (see chronologies
for different values like
https://taginfo.openstreetmap.org/tags/crossing=unmarked#chronology).

greetings
Alex


Am 13.12.20 um 20:25 schrieb ipswichmapper--- via Tagging:
> https://wiki.openstreetmap.org/wiki/Proposed_features/crossing%3Dpriority 
> 
>
> Here is my first proposal for a tag to describe pedestrian crossings where 
> the pedestrian has right of way over all vehicles on the road from the moment 
> they have indicated their intent to cross. I created this because 
> "crossing=zebra" or "crossing=marked" aren't clear enough. Please read the 
> proposal for more details.
>
> Thanks,
> IpswichMapper
>
>
> ___
> 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] Feature Proposal - RFC - crossing=priority

[Clifford Snow]

On Sun, Dec 13, 2020 at 11:26 AM ipswichmapper--- via Tagging <
tagging@openstreetmap.org> wrote:

> https://wiki.openstreetmap.org/wiki/Proposed_features/crossing%3Dpriority
> 
>
> Here is my first proposal for a tag to describe pedestrian crossings where
> the pedestrian has right of way over all vehicles on the road from the
> moment they have indicated their intent to cross. I created this because
> "crossing=zebra" or "crossing=marked" aren't clear enough. Please read the
> proposal for more details.
>

In a number of places that I've lived or visited, marked crossings (zebra
or others) indicate the pedestrian has the right-of-way.  For example,
where I live now, Washington State, it's the law that pedestrians have
righ-of-way in a marked crosswalk. In all those many places adding the tag
crossing=priority would be redundant. It would also effectively do away
with crossing=marked which has over 1M uses[1]. Many of us were very happy
when crossing=marked was added because zebra didn't exactly fit. What
crossing=marked does is give the ability to easily verify what's
literally on the ground, even visible from good aerial imagery.

If you believe that we need a priority tag, then I suggest creating one
that doesn't effectively depreciate crossing=marked. I'd also suggest
explaining how a mappers is expected to know if the pedestrian has
priority.

[1] https://taginfo.openstreetmap.org/keys/crossing#values

-- 
@osm_washington
www.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - crossing=priority

[stevea]

This is problematic to my thinking.  In California (my state), at an 
UNCONTROLLED intersection (no traffic_signal, stop sign, other traffic control 
device...), for example where the sidewalk "would continue to another sidewalk 
on the other side of the roadway," pedestrians ALWAYS have the right-of-way 
(over all vehicles) when they indicate it.  How do they indicate it?  By 
lifting one foot to step towards / into the intersection (from the sidewalk).  
Drivers must (by law) stop short of entering the intersection to allow the 
pedestrian to cross, once a pedestrian has so entered the crossing (even it if 
is unmarked or "invisible").

So, whatever proposal you come up with might properly need to be applied to 
every uncontrolled intersection (in California, and potentially many other 
places).  I ask you to keep this in mind as you craft the proposal.  As it is 
now, your proposal contradicts a fact now widespread here (and I expect more 
widely in the USA):  should it be approved, crossing=uncontrolled will describe 
crossings where VEHICLES have right-of-way.  That would break a lot of 
intersections so tagged today, making true exactly the opposite semantic on 
them, contradicting their existing meaning in our map.

Maybe I (we) should be discussing this in the proposal's Talk page rather than 
in this mail-list, I don't know.

SteveA

> On Dec 13, 2020, at 11:25 AM, ipswichmapper--- via Tagging 
>  wrote:
> 
> https://wiki.openstreetmap.org/wiki/Proposed_features/crossing%3Dpriority
> 
> Here is my first proposal for a tag to describe pedestrian crossings where 
> the pedestrian has right of way over all vehicles on the road from the moment 
> they have indicated their intent to cross. I created this because 
> "crossing=zebra" or "crossing=marked" aren't clear enough. Please read the 
> proposal for more details.
> 
> Thanks,
> IpswichMapper
> ___
> 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] The saga of landuse=reservoir vs water=reservoir

[Joseph Eisenberg]

Re: "if a reservoir was fenced off, I would tag the fenced area as
landuse=reservoir but only the actual water surface as water."

There is also a more specific tag for this:
https://taginfo.openstreetmap.org/tags/?key=landuse=reservoir_watershed#overview
- though most uses were added by an import in 2011
-  landuse=reservoir_watershed:
https://wiki.openstreetmap.org/wiki/Tag%3Alanduse%3Dreservoir_watershed

-- Joseph Eisenberg

On Sun, Dec 13, 2020 at 10:56 AM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> On 13. Dec 2020, at 18:49, Tomas Straupis  wrote:
>
>  Introducing duplicate and unused schema (especially as the only
> option) is not a good IT decision, basic analysis should have shown
> that. But in case of id it was technology leading functionality and
> thus leading users when in IT it must be the other way round -
> usage/requirements must lead technical decisions. That is IT BASICS.
> Lack of such understanding is the reason why I claim iD developers
> lacked basic IT knowledge
>
>
>
> it is indeed well documented that there was a period in iD development
> where the developers occasionally  (initially without actively
> communicating it and later openly and deliberately) dismissed the existing
> tagging wiki docs and mailing list and tag stats, but I think it should be
> mentioned that it was the former developer. Brian, maybe this was before
> you started to follow the lists. You can browse through older closed iD
> tickets to see some discussion, there’s also a wiki page about the topic:
> https://wiki.openstreetmap.org/wiki/ID/Controversial_Decisions
>
> regarding water=reservoir or landuse=reservoir, there might be some subtle
> differences. water=reservoir is for surface water areas. if a reservoir was
> fenced off, I would tag the fenced area as landuse=reservoir but only the
> actual water surface as water.
>
> 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] How to put a name tag on an area with more than one type?

[Joseph Eisenberg]

Currently the features with the tag "name=Kebnekaise" are 2 ways which
extend north-south and to the west from these two peaks and are also tagged
natural=arete (an arete is a knife-edged ridge formed between 2 glaciers).

https://www.openstreetmap.org/way/123215393#map=13/67.8934/18.4509=C
https://www.openstreetmap.org/way/407174801#map=14/67.8999/18.5215=C

Is this correct based on your local knowledge of the area?

If in fact Kebnekaise is the name of the ridges or aretes, then this is a
good way to represent the name of the "mountain" which in this case appears
to be a thin ridge between glaciers.

Note that Opentopomap handles this fairly well:
https://www.opentopomap.org/#map=14/67.90026/18.50553 and
https://www.opentopomap.org/#map=13/67.90113/18.46716

I believe OpenTopoMap also renders natural=mountain_range ways:
https://www.opentopomap.org/#map=12/38.4613/-4.1566

OpenTopoMap uses a special script to assign an isolation value to each
peak: that is, how far is it away from another natural=peak (or
natural=volcano) with a larger elevation value? If it is a long way, the
peak will be rendered even at low zoom levels (large scales), for example:
https://www.opentopomap.org/#map=7/67.900/18.479

This hasn't been implemented in the OpenStreetMap-Carto style because it is
somewhat complicated and might have performance problems and there are
issues with using more pre-processing of the raw data when it comes to
mapper feedback, but the code used by OpenTopoMap is here:
https://github.com/der-stefan/OpenTopoMap/pull/129 and
https://github.com/der-stefan/OpenTopoMap/pull/130  if anyone else wants to
implement this for their own maps.

-- Joseph

On Sun, Dec 13, 2020 at 12:14 PM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
>
>
> Dec 13, 2020, 19:58 by and...@torger.se:
>
> Do you have a suggestion of how to map Sweden's highest mountain,
> Kebnekaise?
>
> The mountain is called Kebnekaise, it has two peaks, one is called
> "Sydtoppen" ("the south peak"), the other "Nordtoppen" ("the north peak").
>
> I admit that I have no good idea, if I would run into such case and failed
> to find a better idea
> (hopefully one will come) I would invent a new way to tag that.
>
> natural=mountain? Main problem is where to put it - node at arbitrary
> position between peaks?
> Node at location of highest peak? Area? Relation? All of that is sadly
> problematic.
>
> (The mountain_range tag is a great tag, but I note that its status is just
> "in use", it's not an approved tag :-O.)
>
> It is perfectly fine to use tags that never went through tagging proposal,
> though
> I am not going to endorse this one. Tagging mountain ranges seems to
> poorly fit OSM
> with multiple different opinions where mountain range starts/ends and
> inability to
> verify it by survey.
>
> All tags were in some stage rarely used before becoming heavily used,
> only some cases went through a proposal process.
> ___
> 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] How to put a name tag on an area with more than one type?

[Mateusz Konieczny via Tagging]

Dec 13, 2020, 19:58 by and...@torger.se:

>
> Do you have a suggestion of how to map Sweden's highest mountain, Kebnekaise?
>
>
> The mountain is called Kebnekaise, it has two peaks, one is called 
> "Sydtoppen" ("the south peak"), the other "Nordtoppen" ("the north peak").
>
>
I admit that I have no good idea, if I would run into such case and failed to 
find a better idea
(hopefully one will come) I would invent a new way to tag that.

natural=mountain? Main problem is where to put it - node at arbitrary position 
between peaks?
Node at location of highest peak? Area? Relation? All of that is sadly 
problematic.

>
> (The mountain_range tag is a great tag, but I note that its status is just 
> "in use", it's not an approved tag :-O.)
>
>
It is perfectly fine to use tags that never went through tagging proposal, 
though
I am not going to endorse this one. Tagging mountain ranges seems to poorly fit 
OSM
with multiple different opinions where mountain range starts/ends and inability 
to
verify it by survey.

All tags were in some stage rarely used before becoming heavily used,
only some cases went through a proposal process.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature proposal - RFC 2 - Pumping proposal

[Mateusz Konieczny via Tagging]

https://wiki.openstreetmap.org/wiki/Proposed_features/Pumping_proposal#Examples

Looking at the first example - I see nothing clearly indicating that pump is 
operated
by muscle power.

Is it intentional to not include this distinction?


Dec 13, 2020, 19:45 by fl.infosrese...@gmail.com:

> Dear all,
>
> Following some rework to take care of comments received during the first 
> voting round of pumping proposal, here is a second proposed version
> https://wiki.openstreetmap.org/wiki/Proposed_features/Pumping_proposal
>
> IanVG and I spent time to improve wording and make rationale section clearer.
> Classification of pumps is now done with pump_mechanism and is still 
> equivalent to which available on Wikipedia. Numerous references are made 
> toward it.
>
> Additional examples and illustrating gifs have been added at the bottom as 
> well.
>
> This message opens a second RFC period and is expected to be shorter. Vote 
> could begin by next Saturday.
>
> Best regards
>
> François
>

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

Re: [Tagging] Feature Proposal - RFC - crossing=priority

[ipswichmapper--- via Tagging]

Yes, most likely this won't be required. However I have kept it there in case 
it works differently in other countries. Maybe not all zebra crossings in 
Singapore have belisha beacons (for example, I don't know if this is true). 
That is why I am leaving it open for discussion for now, if after the RFC it is 
decided that this is a bad idea I'll remove it.

Thanks,
IpswichMapper
-- 

13 Dec 2020, 19:50 by tagging@openstreetmap.org:

> It seems to be proposing also belisha_beacon=yes that
> is now unused
> https://taginfo.openstreetmap.org//search?q=belisha_beacon%3Dyes
>
> At the same time it has 
> "However, in countries like the UK, where belisha beacons are used, every 
> single zebra crossing has belisha beacons installed, so there is no need to 
> tag them"
>
> There is also
> "Indicates the presence of a "belisha beacon" at the crossing. (Most likely 
> unnecessary, discuss below)"
>
> Given there is no indication that it would be useful or needed I think
> that it should be not proposed.
>
> If that it would be useful or needed it can be proposed separately.
>
> Note that having two proposals in one will result in people voting against
> if there are against any of them, so splitting would be a good idea
> anyway.
>
> Dec 13, 2020, 20:25 by tagging@openstreetmap.org:
>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/crossing%3Dpriority 
>> 
>>
>> Here is my first proposal for a tag to describe pedestrian crossings where 
>> the pedestrian has right of way over all vehicles on the road from the 
>> moment they have indicated their intent to cross. I created this because 
>> "crossing=zebra" or "crossing=marked" aren't clear enough. Please read the 
>> proposal for more details.
>>
>> Thanks,
>> IpswichMapper
>>
>
>

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

Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

[Mateusz Konieczny via Tagging]

Dec 13, 2020, 19:53 by dieterdre...@gmail.com:

>
>
> sent from a phone
>
>
>> On 13. Dec 2020, at 18:49, Tomas Straupis  wrote:
>>
>>  Introducing duplicate and unused schema (especially as the only
>> option) is not a good IT decision, basic analysis should have shown
>> that. But in case of id it was technology leading functionality and
>> thus leading users when in IT it must be the other way round -
>> usage/requirements must lead technical decisions. That is IT BASICS.
>> Lack of such understanding is the reason why I claim iD developers
>> lacked basic IT knowledge
>>
>
>
> it is indeed well documented that there was a period in iD development where 
> the developers occasionally  (initially without actively communicating it and 
> later openly and deliberately) dismissed the existing tagging wiki docs and 
> mailing list and tag stats, but I think it should be mentioned that it was 
> the former developer. Brian, maybe this was before you started to follow the 
> lists. You can browse through older closed iD tickets to see some discussion, 
> there’s also a wiki page about the topic: > 
> https://wiki.openstreetmap.org/wiki/ID/Controversial_Decisions
>
Yes, it happened. I considered some decisions as problematic.

But it was not about IT basic, IT knowledge, IT decisions or anything like that.

If someone complains about IT knowledge while the actual complaint
is about tagging presets then people will be very confused.

BTW, iD presets were recently extracted into 
https://github.com/openstreetmap/id-tagging-schema
to 100% decouple preset decisions that are not 
programming related for programming tasks of making editor.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - crossing=priority

[Mateusz Konieczny via Tagging]

It seems to be proposing also belisha_beacon=yes that
is now unused
https://taginfo.openstreetmap.org//search?q=belisha_beacon%3Dyes

At the same time it has 
"However, in countries like the UK, where belisha beacons are used, every 
single zebra crossing has belisha beacons installed, so there is no need to tag 
them"

There is also
"Indicates the presence of a "belisha beacon" at the crossing. (Most likely 
unnecessary, discuss below)"

Given there is no indication that it would be useful or needed I think
that it should be not proposed.

If that it would be useful or needed it can be proposed separately.

Note that having two proposals in one will result in people voting against
if there are against any of them, so splitting would be a good idea
anyway.

Dec 13, 2020, 20:25 by tagging@openstreetmap.org:

> https://wiki.openstreetmap.org/wiki/Proposed_features/crossing%3Dpriority 
> 
>
> Here is my first proposal for a tag to describe pedestrian crossings where 
> the pedestrian has right of way over all vehicles on the road from the moment 
> they have indicated their intent to cross. I created this because 
> "crossing=zebra" or "crossing=marked" aren't clear enough. Please read the 
> proposal for more details.
>
> Thanks,
> IpswichMapper
>

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

Re: [Tagging] How to put a name tag on an area with more than one type?

[Christoph Hormann]

> Anders Torger  hat am 13.12.2020 20:08 geschrieben:
> 
> [...] I think to actually have them all 
> tied together in a unit is still a good idea, [...]

That does not answer my question.

-- 
Christoph Hormann 
https://www.imagico.de/

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

[Tagging] Feature Proposal - RFC - crossing=priority

[ipswichmapper--- via Tagging]

https://wiki.openstreetmap.org/wiki/Proposed_features/crossing%3Dpriority 


Here is my first proposal for a tag to describe pedestrian crossings where the 
pedestrian has right of way over all vehicles on the road from the moment they 
have indicated their intent to cross. I created this because "crossing=zebra" 
or "crossing=marked" aren't clear enough. Please read the proposal for more 
details.

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

Re: [Tagging] How to put a name tag on an area with more than one type?

[Anders Torger]

A common established method to name natural features with separated 
parts is as a multipolygon with several outers. There is one object that 
ties them all together.


In this case a multipolygon is not possible, since the member types 
differ and "outers" share segments. I think to actually have them all 
tied together in a unit is still a good idea, it is one entity, not 
multiple entities named the same. If this ever gets supported by a 
renderer the logical way would be to have the name only on the relation 
and no name on the separate parts.


/Anders

On 2020-12-13 16:15, Christoph Hormann wrote:

Anders Torger  hat am 13.12.2020 15:28 geschrieben:

So what I've settled for (for now) is as follows:
- same name on each part (the only way to get the data useful *today*)
- a new relation with all parts as members (role unset), type=natural, 
natural=wetland, name=


I am trying to understand what the issue is with the recommendation
for mapping you have received from multiple sides here.

So what exactly is the verifiable knowledge that is supposed to be
represented by your new relation type that is not already recorded in
the mapping of physical features?


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

Re: [Tagging] How to put a name tag on an area with more than one type?

[Anders Torger]

Do you have a suggestion of how to map Sweden's highest mountain, 
Kebnekaise?


The mountain is called Kebnekaise, it has two peaks, one is called 
"Sydtoppen" ("the south peak"), the other "Nordtoppen" ("the north 
peak").


Currently it's mapped with the two peaks where one is called "Kebnekaise 
Sydtoppen" and the other "Kebnekaise Nordtoppen". Not really correct, 
but perhaps the least bad way to do it? When zooming out, on a regular 
map you see the Kebnekaise name big over the mountain, but the names for 
Sydtoppen and Nordtoppen is removed. I'd love something like a 
possibility to put the peaks in a relation and put the mountain name in 
the relation in cases like this.


Kebnekaise is not the only example, it's quite common with Swedish 
mountain that the peaks themselves have quite anonymous names like those 
on Kebnekaise, "Stortoppen" (the great peak) is another common name of 
the highest peak on a Swedish mountain, where the mountain itself has a 
different (and unique) name. You don't want to see the anonymous 
"Stortoppen"-name when you zoom out the map. OSM-Carto has "solved" 
these name prominence issues by removing all names pretty much 
immediately, rendering overview maps useless.


One problem with the current peak tag is that the renderer has no 
information about the size of the mountain. A peak even if really high 
can be a small local peak on top of a large plateau.


(The mountain_range tag is a great tag, but I note that its status is 
just "in use", it's not an approved tag :-O.)


/Anders

On 2020-12-13 18:54, Joseph Eisenberg wrote:

1) To tag a named "Torp" it sounds like there are several different 
correct options, depending on what currently exists at the location.


If there is a single family home or a couple of homes used as 
residences, it would be a place=isolated_dwelling mapped as a node at 
the centre.


If it is still used as a farm, then place=farm can be used on a node 
instead. This is treated as similar to place=isolated_dwelling by many 
data users. It is also possible to map the area of the farmyard (around 
the buildings) as landuse=farmyard and add the name to this feature, if 
the name is only for the actual farm buildings and not for all the 
surrounding areas.


For a named settlement with more than 2 families (but smaller than a 
village), place=hamlet on a node would be appropriate. I'm not sure if 
a torp is every that large?


If the torp is no longer inhabited, you can use a lifecycle tag to show 
this: e.g. abandoned:place=farm or abandoned:place=isolated_dwelling or 
abandoned:place=hamlet show that a former farm or small settlement are 
now abandoned and no longer inhabited.


2) For a mountain:
Most mountains share a name with their highest peak, so natural=peak is 
a great way to tag these.


But it's true that some "mountain" names are not the name of a peak. In 
this case there are a couple other tags in use: natural=ridge is used 
with a linear way which is drawn along the ridgeline. This works for 
many named single ridges. 
https://wiki.openstreetmap.org/wiki/Tag:natural%3Dridge - example here: 
https://www.opentopomap.org/#map=15/41.76382/-123.18038 - 
https://www.openstreetmap.org/way/631166206/#map=13/41.7664/-123.1567=C


Sometimes a named "mountain" is not a single ridge but a whole range of 
connected ridges. In this case we usually call it a "mountain range" in 
English, and there is a somewhat uncommon tag for this 
natural=mountain_range which I've used to map some ranges in my area. 
This tag is harder to use. In some cases the best option is to use it 
on a node at the center of the mountain range, in others it is possible 
to use it on a linear way along the highest line of ridges at the 
center of the mountain range. 
https://wiki.openstreetmap.org/wiki/Tag%3Anatural%3Dmountain_range - 
example: 
https://www.openstreetmap.org/way/686647385#map=12/42.0515/-122.7575=C
While we can all disagree on how far down into the valley the mountain 
extends, everyone agrees that the highest peak is part of the mountain, 
so mapping peaks of a mountain as a node is 100% verifiably to be 
correct. In some cases a linear way is also verifiable for a ridge or a 
linear mountain range.


-- Joseph Eisenberg

On Sun, Dec 13, 2020 at 7:04 AM Ture Pålsson via Tagging 
 wrote:


13 dec. 2020 kl. 15:21 skrev Paul Allen :

I'm probably misunderstanding this, but torp doesn't seem to be a type 
of

building.  The tag building=torp says that this building IS a torp (as
opposed to a house, or a shop, or a garage, or a shed, or a barn).
If you feel a need to indicate that a building was once part of a torp,
building=torp isn't the way to do it.
You're right; I was extremely sloppy with terminology there. A torp is 
(or rather was) a small farm, usually either part of a bigger farm and 
farmed by a tenant, paying rent to the bigger farm in the form of work, 
or farmed by a soldier (paying rent by, well, being a soldier). Today, 
most of them are 

Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

[Tomas Straupis]

2020-12-13, sk, 20:41 Mateusz Konieczny via Tagging rašė:
> Following outcome of approved proposal that you dislike
> is not indicator of not following
> standard IT processes of product development.

  Following some wiki page (which states that landuse=reservoir is not
deprecated) written by one person and voted by few rather than de
facto situation in other editors and database is huge problem with
analysis.
  In case of iD it is even worse - it shows coders of iD did not want
to give a tool, but rather to make influence which they continue to do
quite openly, especially with a tactic of "upgrade tags". Compare that
to JOSM - which is democratic, follows OSM principle of freedom and
lets us - mappers - choose.

  Both schemas are mostly identical in what classes of object can be mapped.
  1. water=reservoir benefit could have been on coding side: having
natural=water as an "umbrella" tag but it did not work out that way
(so I do not know what is a perceived advantage now?)
  2. landuse=reservoir benefit is GIS/Cartographic: we must indicate
if it is a natural or man made waterbody.
  Now you decide which is more important to openstreetMAP.

-- 
Tomas

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

Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

[Martin Koppenhoefer]

sent from a phone

> On 13. Dec 2020, at 18:49, Tomas Straupis  wrote:
> 
>  Introducing duplicate and unused schema (especially as the only
> option) is not a good IT decision, basic analysis should have shown
> that. But in case of id it was technology leading functionality and
> thus leading users when in IT it must be the other way round -
> usage/requirements must lead technical decisions. That is IT BASICS.
> Lack of such understanding is the reason why I claim iD developers
> lacked basic IT knowledge


it is indeed well documented that there was a period in iD development where 
the developers occasionally  (initially without actively communicating it and 
later openly and deliberately) dismissed the existing tagging wiki docs and 
mailing list and tag stats, but I think it should be mentioned that it was the 
former developer. Brian, maybe this was before you started to follow the lists. 
You can browse through older closed iD tickets to see some discussion, there’s 
also a wiki page about the topic: 
https://wiki.openstreetmap.org/wiki/ID/Controversial_Decisions

regarding water=reservoir or landuse=reservoir, there might be some subtle 
differences. water=reservoir is for surface water areas. if a reservoir was 
fenced off, I would tag the fenced area as landuse=reservoir but only the 
actual water surface as water.

Cheers Martin 


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

[Tagging] Feature proposal - RFC 2 - Pumping proposal

[François Lacombe]

Dear all,

Following some rework to take care of comments received during the first
voting round of pumping proposal, here is a second proposed version
https://wiki.openstreetmap.org/wiki/Proposed_features/Pumping_proposal

IanVG and I spent time to improve wording and make rationale section
clearer.
Classification of pumps is now done with pump_mechanism and is still
equivalent to which available on Wikipedia. Numerous references are made
toward it.

Additional examples and illustrating gifs have been added at the bottom as
well.

This message opens a second RFC period and is expected to be shorter. Vote
could begin by next Saturday.

Best regards

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

Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

[Mateusz Konieczny via Tagging]

Dec 13, 2020, 19:33 by tomasstrau...@gmail.com:

> 2020-12-13, sk, 20:09 Mateusz Konieczny via Tagging rašė:
>
>> 2020-12-13, sk, 19:18 Mateusz Konieczny via Tagging rašė:
>> Mateusz, can you point out which of my claims is a lie?
>>
>> "iD coders decided to skip standard IT processes of product development
>> (or were not familiar with the basics of IT)"
>>
>
> Let's go back in time. It is 2012. iD developers are to add water
> tagging schema to their newly baked editor. The candidates are IN
> 2012:
>  1. landuse=reservoir - the only schema in activu use, widely used,
> 200K objects tagged, documentation written, tutorials written.
>  2. water=reservoir - unused (5K? 10K?).
>  iD developers decision: go with option 2. I do not see how such
> decision could be counted as "IT-wise sound"?
>
Following outcome of approved proposal that you dislike
is not indicator of not following
standard IT processes of product development.

Again, disagreeing with you does not mean that someone is
incompetent.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

[Tomas Straupis]

2020-12-13, sk, 20:09 Mateusz Konieczny via Tagging rašė:
> 2020-12-13, sk, 19:18 Mateusz Konieczny via Tagging rašė:
> Mateusz, can you point out which of my claims is a lie?
>
> "iD coders decided to skip standard IT processes of product development
> (or were not familiar with the basics of IT)"

  Let's go back in time. It is 2012. iD developers are to add water
tagging schema to their newly baked editor. The candidates are IN
2012:
  1. landuse=reservoir - the only schema in activu use, widely used,
200K objects tagged, documentation written, tutorials written.
  2. water=reservoir - unused (5K? 10K?).
  iD developers decision: go with option 2. I do not see how such
decision could be counted as "IT-wise sound"?
  (my suspicion is that the reason was iD's tag layout being
tag+subtag and there water=reservoir was better suitable, but this is
just my speculation, if true that would be one more proof of lack of
IT experience)

> 
> "coders of iD decided to lie to the users that landuse=reservoir is
> deprecated which it never was"
>
> It is deprecated by 2011 proposal, see 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Water_details#Deprecation

  Please read everything, not only the part you're interested. Zverik
agreed that it is NOT deprecated. And it was agreed in many many other
discussions that landuse=reservoir was NEVER deprecated.

> usage/requirements must lead technical decisions. That is IT BASICS.
>
> It was not an unused schema and it was proposed, approved and used before iD
> started using it and later aggressively promoting it.

  2012:
  landuse=reservoir - 200K,
  water=reservoir - 5K? 10K?

  Should we continue to argue in the dungeons of history without
thinking about the future?

  The problem is that it dragged for almost 10 years. Now ANY decision
will be bad. That is why decision is always postponed, but time will
not change anything. The hole is till there, there are no
rules/process to circumvent that. So the situation can repeat again.

-- 
Tomas

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

Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

[Mateusz Konieczny via Tagging]

Dec 13, 2020, 18:46 by tomasstrau...@gmail.com:

Please first stop quoting me in way that presents your
statements under my autorship

> 2020-12-13, sk, 19:18 Mateusz Konieczny via Tagging rašė:
> Mateusz, can you point out which of my claims is a lie?
>
"iD coders decided to skip standard IT processes of product development
 (or were not familiar with the basics of IT)"


"coders of iD decided to lie to the users that landuse=reservoir is
deprecated which it never was"

It is deprecated by 2011 proposal, 
seehttps://wiki.openstreetmap.org/wiki/Proposed_features/Water_details#Deprecation




>  I didn't say iD invented duplicate schema, I said that schema was
> lying dead until iD decided to introduce it as the only way to tag
> water, introduction "launched" new water schema adding any
> considerable usage (as it was the only option for iD mappers).
>
OK, this one was based on miscommunication.



>  Introducing duplicate and unused schema (especially as the only
> option) is not a good IT decision
>
It was not an unused schema.

> usage/requirements must lead technical decisions. That is IT BASICS.
>
It was not an unused schema and it was proposed, approved and used before iD
started using it and later aggressively promoting it.

>  and introduced
>
>> water=reservoir as the only way to tag, all this at the time when
>> water=reservoir usage was close to zero!
>>
>> See https://taginfo.openstreetmap.org/tags/water=reservoir#chronology
>>
>> Usage in January 2019 was about 200 000 already.
>>
>> "water=reservoir usage was close to zero" is untrue
>>
>
> Key word "introduced" so it is 2012, not 2019.
>  water=reservoir usage in 2012 is close to zero.
>
Then iD followed a fresh approved proposal, so relatively low
usage is not surprising.

Though it is a rare case when I encounter complaint about iD
developers following outcome of a proposal process.

>> It is deprecated by 2011 proposal, see
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Water_details#Deprecation
>>
>
> The author of this proposal agreed that standard water schema is NOT
> deprecated. 
>
It is not changing that this vote deprecated landuse=reservoir.
Maybe it is a bad decision that should be ignored, but
it is not changing that deprecation happened.

> And a few people voting in wiki cannot deprecate a tag.
>
That is one of methods to deprecate tag, even if you dislike it.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

[Joseph Eisenberg]

Re: "that schema was lying dead until iD decided to introduce it as the
only way to tag water"

That's not really correct when it comes to landuse=reservoir

In this case, landuse=reservoir growth slowed down in 2016 for reasons that
are unclear to me:

Compare the charts:
https://taghistory.raifer.tech/#***/landuse/reservoir&***/water/reservoir

Until mild 2016 landuse=reservoir was still increasing as fast or faster
than water=reservoir
But 5 years after the water proposal was approved, this changed:
water=reservoir continued increasing linearly, but landuse=reservoir slowed
down to half the prior rate.

It's fair to say that between mid 2016 and mid 2019, water=reservoir was
twice as popular as landuse=reservoir for adding new features

Then of course the change to the iD Editor in mid 2019 caused another
inflection and landuse=reservoir started decreasing, but the water=* schema
was not "lying dead" in this case, it was already more popular.

Perhaps you are instead remembering the situation with waterway=riverbank
vs water=river. In that case it appears that iD really did start the main
change, because waterway=riverbank continued to be equally popular or more
popular than water=river for new features until mild-2019 (except perhaps
during 2017 for some reason?):
https://taghistory.raifer.tech/#***/water/river&***/waterway/riverbank

I would be more irritated about an attempt to deprecate waterway=riverbank,
because in that case there is more risk of information loss: a reservoir
and natural=water are both historically defined as standing fresh water and
in most cases will be rendered the same (though having the information if a
lake is natural or artificial is still important). But a river is flowing
water and is often rendered differently, and tagging as natural=water risks
losing this information invisibly, if the water=river tag is accidentally
or intentionally deleted - this is partially the fault of
OpenStreetMap-Carto for not yet rendering any difference between rivers and
standing water.

-- Joseph Eisenberg

On Sun, Dec 13, 2020 at 9:49 AM Tomas Straupis 
wrote:

> 2020-12-13, sk, 19:18 Mateusz Konieczny via Tagging rašė:
> > New/duplicate schema with water=reservoir only launched because iD
> > coders decided to skip standard IT processes of product development
> > (or were not familiar with the basics of IT) and simply went for what
> > they personally liked, not what was better
> >
> > This is 100% untrue, and you insult people. Stop making such things.
> >
> > For start, iD authors (also ones that made decisions about tagging
> > presets that I consider to be mistakes and going against consensus)
> > had no problem with basics of IT and IT processes of product development.
> >
> > water=reservoir was launched (created) in 2011
> > see https://wiki.openstreetmap.org/wiki/Proposed_features/Water_details
> > iD started in 2012 ( https://wiki.openstreetmap.org/wiki/ID )
>
>   Mateusz, can you point out which of my claims is a lie?
>   I didn't say iD invented duplicate schema, I said that schema was
> lying dead until iD decided to introduce it as the only way to tag
> water, introduction "launched" new water schema adding any
> considerable usage (as it was the only option for iD mappers).
>
>   Introducing duplicate and unused schema (especially as the only
> option) is not a good IT decision, basic analysis should have shown
> that. But in case of id it was technology leading functionality and
> thus leading users when in IT it must be the other way round -
> usage/requirements must lead technical decisions. That is IT BASICS.
> Lack of such understanding is the reason why I claim iD developers
> lacked basic IT knowledge.
>
> > , and introduced
> > water=reservoir as the only way to tag, all this at the time when
> > water=reservoir usage was close to zero!
> >
> > See https://taginfo.openstreetmap.org/tags/water=reservoir#chronology
> >
> > Usage in January 2019 was about 200 000 already.
> >
> > "water=reservoir usage was close to zero" is untrue
>
>   Key word "introduced" so it is 2012, not 2019.
>   water=reservoir usage in 2012 is close to zero.
>
> > It is deprecated by 2011 proposal, see
> >
> https://wiki.openstreetmap.org/wiki/Proposed_features/Water_details#Deprecation
>
>   The author of this proposal agreed that standard water schema is NOT
> deprecated. And a few people voting in wiki cannot deprecate a tag.
> Only people actually mapping can do that.
>
> > BTW, you are AGAIN spreading false statements and claim that iD
> > invented water=reservoir. Please stop doing this.
>
>   Do not copy/paste my words in random order and you will not get such
> claims from me :-)
>
>   Anyways, there is no way I will be able to teach IT things people
> who do not want to learn. Let's not rewrite the history of this saga
> and lets move forward instead of repeating the same discussion again
> and again. Let's do what is possible so that this does not happen
> again:
>
>   * When tagging 

Re: [Tagging] How to put a name tag on an area with more than one type?

[Joseph Eisenberg]

1) To tag a named "Torp" it sounds like there are several different correct
options, depending on what currently exists at the location.

If there is a single family home or a couple of homes used as residences,
it would be a place=isolated_dwelling mapped as a node at the centre.

If it is still used as a farm, then place=farm can be used on a node
instead. This is treated as similar to place=isolated_dwelling by many data
users. It is also possible to map the area of the farmyard (around the
buildings) as landuse=farmyard and add the name to this feature, if the
name is only for the actual farm buildings and not for all the surrounding
areas.

For a named settlement with more than 2 families (but smaller than a
village), place=hamlet on a node would be appropriate. I'm not sure if a
torp is every that large?

If the torp is no longer inhabited, you can use a lifecycle tag to show
this: e.g. abandoned:place=farm or abandoned:place=isolated_dwelling or
abandoned:place=hamlet show that a former farm or small settlement are now
abandoned and no longer inhabited.

2) For a mountain:
Most mountains share a name with their highest peak, so natural=peak is a
great way to tag these.

But it's true that some "mountain" names are not the name of a peak. In
this case there are a couple other tags in use: natural=ridge is used with
a linear way which is drawn along the ridgeline. This works for many named
single ridges. https://wiki.openstreetmap.org/wiki/Tag:natural%3Dridge -
example here: https://www.opentopomap.org/#map=15/41.76382/-123.18038 -
https://www.openstreetmap.org/way/631166206/#map=13/41.7664/-123.1567=C

Sometimes a named "mountain" is not a single ridge but a whole range of
connected ridges. In this case we usually call it a "mountain range" in
English, and there is a somewhat uncommon tag for this
natural=mountain_range which I've used to map some ranges in my area. This
tag is harder to use. In some cases the best option is to use it on a node
at the center of the mountain range, in others it is possible to use it on
a linear way along the highest line of ridges at the center of the mountain
range. https://wiki.openstreetmap.org/wiki/Tag%3Anatural%3Dmountain_range -
example:
https://www.openstreetmap.org/way/686647385#map=12/42.0515/-122.7575=C

While we can all disagree on how far down into the valley the mountain
extends, everyone agrees that the highest peak is part of the mountain, so
mapping peaks of a mountain as a node is 100% verifiably to be correct. In
some cases a linear way is also verifiable for a ridge or a linear mountain
range.

-- Joseph Eisenberg


On Sun, Dec 13, 2020 at 7:04 AM Ture Pålsson via Tagging <
tagging@openstreetmap.org> wrote:

>
> 13 dec. 2020 kl. 15:21 skrev Paul Allen :
>
>  I'm probably misunderstanding this, but torp doesn't seem to be a type of
> building.  The tag building=torp says that this building IS a torp (as
> opposed to a house, or a shop, or a garage, or a shed, or a barn).
> If you feel a need to indicate that a building was once part of a torp,
> building=torp isn't the way to do it.
>
>
> You’re right; I was extremely sloppy with terminology there. A torp is (or
> rather was) a small farm, usually either part of a bigger farm and farmed
> by a tenant, paying rent to the bigger farm in the form of work, or farmed
> by a soldier (paying rent by, well, being a soldier). Today, most of them
> are either completely gone or used as summer houses, very probably not with
> the original building.
>
> I suppose what I wanted to say was:
>
> * place=locality is used about all sorts of things, both inhabited and
> uninhabited, and is pretty much useless.
>
> * There are many places around Sweden (and probably the rest of the world
> as well!) where there is just forest (or fields) today, that have a name
> because they were, at some time, a torp (or some other kind of settlement).
> To render these in ”swedish topo-map style” (i.e, italics), some sort of
> tagging is needed to say ”this place has a name because it used to be a
> farm/torp/whatever, but today there is nothing here”. (I suppose some would
> argue that these should not be in OSM at all, because they are very hard to
> verify on the ground).
>
> * There are also isolated dwellings, hamlets, villages, suburbs and
> airport car parks (comparing old and present-day maps around
> Stockholm-Arlanda airport is quite fun) whose names refer to long-gone
> torps, but those can be tagged according to their present-day usage.
>
> And I’d like to apologize to Anders for derailing this thread by bringing
> up the subject at all! It was intended as an illustration of the
> uselessness of locality, but I got a bit carried away. Trying to render
> consistent maps from inconsistent OSM data does that to you. =)
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___

Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

[Tomas Straupis]

2020-12-13, sk, 18:58 Brian M. Sperlongano rašė:
> Let's please assume good faith and be respectful while we discuss
> differences of opinion with an open mind - we are all here for the
> same reason - working together to create the best possible map for the world.

  I do agree that sometimes I get carried away, sorry I will try to reduce that.

  At the same time I ask to actually discuss the reasons why this saga
happened and ways to reduce the possibility of such harmful
duplications happening again. Bulldozing one opinion and ignoring the
other is not a good solution.

-- 
Tomas

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

Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

[Tomas Straupis]

2020-12-13, sk, 19:18 Mateusz Konieczny via Tagging rašė:
> New/duplicate schema with water=reservoir only launched because iD
> coders decided to skip standard IT processes of product development
> (or were not familiar with the basics of IT) and simply went for what
> they personally liked, not what was better
>
> This is 100% untrue, and you insult people. Stop making such things.
>
> For start, iD authors (also ones that made decisions about tagging
> presets that I consider to be mistakes and going against consensus)
> had no problem with basics of IT and IT processes of product development.
>
> water=reservoir was launched (created) in 2011
> see https://wiki.openstreetmap.org/wiki/Proposed_features/Water_details
> iD started in 2012 ( https://wiki.openstreetmap.org/wiki/ID )

  Mateusz, can you point out which of my claims is a lie?
  I didn't say iD invented duplicate schema, I said that schema was
lying dead until iD decided to introduce it as the only way to tag
water, introduction "launched" new water schema adding any
considerable usage (as it was the only option for iD mappers).

  Introducing duplicate and unused schema (especially as the only
option) is not a good IT decision, basic analysis should have shown
that. But in case of id it was technology leading functionality and
thus leading users when in IT it must be the other way round -
usage/requirements must lead technical decisions. That is IT BASICS.
Lack of such understanding is the reason why I claim iD developers
lacked basic IT knowledge.

> , and introduced
> water=reservoir as the only way to tag, all this at the time when
> water=reservoir usage was close to zero!
>
> See https://taginfo.openstreetmap.org/tags/water=reservoir#chronology
>
> Usage in January 2019 was about 200 000 already.
>
> "water=reservoir usage was close to zero" is untrue

  Key word "introduced" so it is 2012, not 2019.
  water=reservoir usage in 2012 is close to zero.

> It is deprecated by 2011 proposal, see
> https://wiki.openstreetmap.org/wiki/Proposed_features/Water_details#Deprecation

  The author of this proposal agreed that standard water schema is NOT
deprecated. And a few people voting in wiki cannot deprecate a tag.
Only people actually mapping can do that.

> BTW, you are AGAIN spreading false statements and claim that iD
> invented water=reservoir. Please stop doing this.

  Do not copy/paste my words in random order and you will not get such
claims from me :-)

  Anyways, there is no way I will be able to teach IT things people
who do not want to learn. Let's not rewrite the history of this saga
and lets move forward instead of repeating the same discussion again
and again. Let's do what is possible so that this does not happen
again:

  * When tagging schema CAN be changed and when it CAN NOT?
  * What ADVANTAGES are required to allow deprecating current schema?

-- 
Tomas

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

Re: [Tagging] Is landuse=conservation actually deprecated?

[Brian M. Sperlongano]

I will note that the Massachusetts, USA mapping community does believe that
there is a distinction between the two tags, as noted here:

https://wiki.openstreetmap.org/wiki/Massachusetts/Conservation

However, this usage and definition seems to be specific to that particular
community and is not a widely shared viewpoint.  I was under the impression
that landuse=conservation was deprecated, but if that was resulting from an
arbitrary wiki edit and not a formal proposal, perhaps it should not be
marked deprecated in the wiki.

As to the question of whether landuse=conservation and
boundary=protected_area mean exactly the same thing, I don't think we can
answer that easily, because boundary=protected_area lacks a formal
definition.  My prior, current, and hopefully future proposal(s) are in
part working towards developing that definition of boundary=protected_area,
and aligning its meaning to the way wikipedia defines[1] protected area.

My personal *opinion* is that boundary=protected_area should deprecate
landuse=conservation, but there are certainly multiple viewpoints out there.

[1] https://en.wikipedia.org/wiki/Protected_area



On Sun, Dec 13, 2020 at 12:26 PM Joseph Eisenberg <
joseph.eisenb...@gmail.com> wrote:

> Recently another wiki user marked landuse=conservation as "deprecated" on
> the Map Features page:
> https://wiki.openstreetmap.org/w/index.php?title=Template:Map_Features:landuse=11273=2071912=2068278
>
> This same user had marked the page itself as deprecated back in 2017:
> https://wiki.openstreetmap.org/w/index.php?title=Tag%3Alanduse%3Dconservation=revision=1498145=387459
>
> Previously the Tag:landuse=conservation page had been redirected to a
> proposal since 2009:
> https://wiki.openstreetmap.org/wiki/Proposed_features/conservation
>
> *"Conservation land is land protected from development.*
>
> *It is left in more or less a natural state.*
>
> *It is often maintained to a very limited extent, such as annual mowing to
> prevent forest growth, removal of invasive species, replanting, or dealing
> with or preventing erosion.*
>
> *The public typically, but not always, has access, as it is a valuable
> recreational resource. (Sometimes the public has no physical way of getting
> to it, or is not allowed for water protection reasons, safety, etc)."*
> Now boundary=protected_area is probably the more common way to tag this
> concept.
>
> Comparison:
>
> https://taginfo.openstreetmap.org/compare/boundary=protected_area/landuse=conservation
>
> landuse=conservation is declining since 2015:
> https://taginfo.openstreetmap.org/tags/landuse=conservation#chronology
>
> While boundary=protected area mostly increases, though there are some
> jumps up and down from imports I imagine:
> https://taginfo.openstreetmap.org/tags/boundary=protected_area#chronology
>
> Is it correct to say that landuse=conservation has been deprecated,
> practically, by boundary=protected_area
> , even
> though that tag has not been approved?
>
> -- Joseph Eisenberg
> ___
> 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] Is landuse=conservation actually deprecated?

[Joseph Eisenberg]

Recently another wiki user marked landuse=conservation as "deprecated" on
the Map Features page:
https://wiki.openstreetmap.org/w/index.php?title=Template:Map_Features:landuse=11273=2071912=2068278

This same user had marked the page itself as deprecated back in 2017:
https://wiki.openstreetmap.org/w/index.php?title=Tag%3Alanduse%3Dconservation=revision=1498145=387459

Previously the Tag:landuse=conservation page had been redirected to a
proposal since 2009:
https://wiki.openstreetmap.org/wiki/Proposed_features/conservation

*"Conservation land is land protected from development.*

*It is left in more or less a natural state.*

*It is often maintained to a very limited extent, such as annual mowing to
prevent forest growth, removal of invasive species, replanting, or dealing
with or preventing erosion.*

*The public typically, but not always, has access, as it is a valuable
recreational resource. (Sometimes the public has no physical way of getting
to it, or is not allowed for water protection reasons, safety, etc)."*
Now boundary=protected_area is probably the more common way to tag this
concept.

Comparison:
https://taginfo.openstreetmap.org/compare/boundary=protected_area/landuse=conservation

landuse=conservation is declining since 2015:
https://taginfo.openstreetmap.org/tags/landuse=conservation#chronology

While boundary=protected area mostly increases, though there are some jumps
up and down from imports I imagine:
https://taginfo.openstreetmap.org/tags/boundary=protected_area#chronology

Is it correct to say that landuse=conservation has been deprecated,
practically, by boundary=protected_area
, even
though that tag has not been approved?

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

Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

[Mateusz Konieczny via Tagging]

Dec 13, 2020, 16:35 by tomasstrau...@gmail.com:

> 2020-12-13, sk, 16:13 Brian M. Sperlongano rašė:
>
>> 2019 was a turning point, and over the last two years, landuse=reservoir has
>> been on a steady decline, while water=reservoir continued its rapid growth.
>>
>
> New/duplicate schema with water=reservoir only launched because iD
> coders decided to skip standard IT processes of product development
> (or were not familiar with the basics of IT) and simply went for what
> they personally liked, not what was better
>
This is 100% untrue, and you insult people. Stop making such things.

For start, iD authors (also ones that made decisions about tagging
presets that I consider to be mistakes and going against consensus)
had no problem with basics of IT and IT processes of product development.

water=reservoir was launched (created) in 2011
see https://wiki.openstreetmap.org/wiki/Proposed_features/Water_details
iD started in 2012 ( https://wiki.openstreetmap.org/wiki/ID )

> , and introduced
> water=reservoir as the only way to tag, all this at the time when
> water=reservoir usage was close to zero!
>
See https://taginfo.openstreetmap.org/tags/water=reservoir#chronology

Usage in January 2019 was about 200 000 already.

"water=reservoir usage was close to zero" is untrue
 

>  And the only reason for change of stat starting 2019 is because
> coders of iD decided to lie to the users that landuse=reservoir is
> deprecated
>
It is deprecated by 2011 proposal, see
https://wiki.openstreetmap.org/wiki/Proposed_features/Water_details#Deprecation


>  So the change of statistics is not the preference of mappers but
> preference of some nerds.
>
Well, tagging mailing list and community that is engaged in voting
on tagging proposals is not very representative.

But if you care about deprecation decisions you must rely on
people that are engaged in such discussions.

> I would propose to deprecate water=reservoir
>
Feel free to make a proposal that would
revert
https://wiki.openstreetmap.org/wiki/Proposed_features/Water_details 

proposal. 


BTW, you are AGAIN spreading false statements and claim that iD
invented water=reservoir. Please stop doing this.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping bicycle-only turn lanes

[Paul Johnson]

On Sat, Dec 12, 2020 at 5:04 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 12. Dec 2020, at 23:43, Paul Johnson  wrote:
> >
> > So what?  How are we going to improve if we're not willing to correct
> choices that are objectively bad in retrospect?  Especially when fixing the
> problem makes lane tagging more consistent for all lane types and easier
> for new people to understand and map in the long term
>
>
> use a different key for the different definition. Promote it and see if
> others join you.
>

This complicates things for new mappers, who are invariably going to come
to the same conclusion of "what do you mean "lanes" doesn't literally mean
lanes?"
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

[Brian M. Sperlongano]

Tomas,

Respectfully, I ask you to cease the pattern of name-calling, personal
attacks, and insulting language used in this forum, and on project bug
trackers[1][2].

Let's please assume good faith and be respectful while we discuss
differences of opinion with an open mind - we are all here for the same
reason - working together to create the best possible map for the world.


[1] https://josm.openstreetmap.de/ticket/17874
[2] https://github.com/openstreetmap/iD/issues/6589

On Sun, Dec 13, 2020 at 10:39 AM Tomas Straupis 
wrote:

> 2020-12-13, sk, 16:13 Brian M. Sperlongano rašė:
> > 2019 was a turning point, and over the last two years, landuse=reservoir
> has
> > been on a steady decline, while water=reservoir continued its rapid
> growth.
>
>   New/duplicate schema with water=reservoir only launched because iD
> coders decided to skip standard IT processes of product development
> (or were not familiar with the basics of IT) and simply went for what
> they personally liked, not what was better, and introduced
> water=reservoir as the only way to tag, all this at the time when
> water=reservoir usage was close to zero!
>
>   And the only reason for change of stat starting 2019 is because
> coders of iD decided to lie to the users that landuse=reservoir is
> deprecated which it never was and started replacing landuse=reservoir
> under their highly controversial disguise of "upgrade tags".
>
>   So the change of statistics is not the preference of mappers but
> preference of some nerds.
>
> > Is it time to more directly recommend that mappers favor natural=water +
> water=reservoir
> > *instead of* rather than *in addition to* landuse=reservoir?
>
>   I would propose to deprecate water=reservoir and even more - add
> guards so that such pointless/nerdy duplicate standards would not be
> introduced in the future.
>
>   Note that one of the main nerdy points of this schema was to have a
> possibility to write sql easier (somebody has problems with "and/or")
> and this would also require riverbanks to fall into this new water
> schema. And riverbank clearly does not fall into that even with iD
> lying about it too. Therefore the only point has failed and this
> stupidity is spreading havoc in tagging of such prominent water
> features for more than 10 years now.
>
> P.S. There is quite an easy solution to have a separate iD instance
> for beginners with correct tagging presets loaded.
>
> ___
> 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] The saga of landuse=reservoir vs water=reservoir

[Tomas Straupis]

But prudent way would probably be to come with some rules on change of
tagging schema. Like:
* When tagging schema is too widespread to be protected against changes
* What benefits should new schema add in order to deprecate existing schema

Because otherwise this plague of deprecating existing widespread
schemas (water is not the only impacted area here) in order to bring
some dubious "benefits" will continue. Some people simply do not have
experience and do not understand what is the value of stability and
what are the actual costs of changing something which is already
widespread (for this I like to give an example of highway tag which is
was correct when it was created but is incorrect now, but we do not
change it for the same reason of stability and total cost).

P.S. Stability does not necessarily prohibit freedom of tagging.

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

Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

[Tomas Straupis]

2020-12-13, sk, 16:13 Brian M. Sperlongano rašė:
> 2019 was a turning point, and over the last two years, landuse=reservoir has
> been on a steady decline, while water=reservoir continued its rapid growth.

  New/duplicate schema with water=reservoir only launched because iD
coders decided to skip standard IT processes of product development
(or were not familiar with the basics of IT) and simply went for what
they personally liked, not what was better, and introduced
water=reservoir as the only way to tag, all this at the time when
water=reservoir usage was close to zero!

  And the only reason for change of stat starting 2019 is because
coders of iD decided to lie to the users that landuse=reservoir is
deprecated which it never was and started replacing landuse=reservoir
under their highly controversial disguise of "upgrade tags".

  So the change of statistics is not the preference of mappers but
preference of some nerds.

> Is it time to more directly recommend that mappers favor natural=water + 
> water=reservoir
> *instead of* rather than *in addition to* landuse=reservoir?

  I would propose to deprecate water=reservoir and even more - add
guards so that such pointless/nerdy duplicate standards would not be
introduced in the future.

  Note that one of the main nerdy points of this schema was to have a
possibility to write sql easier (somebody has problems with "and/or")
and this would also require riverbanks to fall into this new water
schema. And riverbank clearly does not fall into that even with iD
lying about it too. Therefore the only point has failed and this
stupidity is spreading havoc in tagging of such prominent water
features for more than 10 years now.

P.S. There is quite an easy solution to have a separate iD instance
for beginners with correct tagging presets loaded.

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

Re: [Tagging] How to put a name tag on an area with more than one type?

[Christoph Hormann]

> Anders Torger  hat am 13.12.2020 15:28 geschrieben:
> 
> So what I've settled for (for now) is as follows:
> - same name on each part (the only way to get the data useful *today*)
> - a new relation with all parts as members (role unset), type=natural, 
> natural=wetland, name=

I am trying to understand what the issue is with the recommendation for mapping 
you have received from multiple sides here.

So what exactly is the verifiable knowledge that is supposed to be represented 
by your new relation type that is not already recorded in the mapping of 
physical features?

-- 
Christoph Hormann 
http://www.imagico.de/

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

Re: [Tagging] How to put a name tag on an area with more than one type?

[Ture Pålsson via Tagging]

> 13 dec. 2020 kl. 15:21 skrev Paul Allen :
> 
>  I'm probably misunderstanding this, but torp doesn't seem to be a type of
> building.  The tag building=torp says that this building IS a torp (as
> opposed to a house, or a shop, or a garage, or a shed, or a barn).
> If you feel a need to indicate that a building was once part of a torp,
> building=torp isn't the way to do it.
> 

You’re right; I was extremely sloppy with terminology there. A torp is (or 
rather was) a small farm, usually either part of a bigger farm and farmed by a 
tenant, paying rent to the bigger farm in the form of work, or farmed by a 
soldier (paying rent by, well, being a soldier). Today, most of them are either 
completely gone or used as summer houses, very probably not with the original 
building.

I suppose what I wanted to say was:

* place=locality is used about all sorts of things, both inhabited and 
uninhabited, and is pretty much useless.

* There are many places around Sweden (and probably the rest of the world as 
well!) where there is just forest (or fields) today, that have a name because 
they were, at some time, a torp (or some other kind of settlement). To render 
these in ”swedish topo-map style” (i.e, italics), some sort of tagging is 
needed to say ”this place has a name because it used to be a 
farm/torp/whatever, but today there is nothing here”. (I suppose some would 
argue that these should not be in OSM at all, because they are very hard to 
verify on the ground).

* There are also isolated dwellings, hamlets, villages, suburbs and airport car 
parks (comparing old and present-day maps around Stockholm-Arlanda airport is 
quite fun) whose names refer to long-gone torps, but those can be tagged 
according to their present-day usage.

And I’d like to apologize to Anders for derailing this thread by bringing up 
the subject at all! It was intended as an illustration of the uselessness of 
locality, but I got a bit carried away. Trying to render consistent maps from 
inconsistent OSM data does that to you. =)

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

Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

[Mateusz Konieczny via Tagging]

on topic of landuse=reservoir vs water=reservoir

I have strong preference toward version with natural=water,
but landuse=reservoir is clearly still in significant use

on topic of what is deciding for tag popularity


Dec 13, 2020, 15:31 by pla16...@gmail.com:

> On Sun, 13 Dec 2020 at 14:13, Brian M. Sperlongano <> zelonew...@gmail.com> > 
> wrote:
>
>>
>> Is it time to more directly recommend that mappers favor natural=water + 
>> water=reservoir *instead of* rather than *in addition to* landuse=reservoir?
>>
> The reality is that no matter what it says in the wiki and no matter what
> conclusions we reach on this list, tagging practise is largely determined
> by editor presets.
>
This statement ignores that editor presets are strongly influenced by this
things.

Yes, there were some cases where iD developers
completely or mostly ignored existing documentation 
(at least one ongoing), but this cases were rare and explosive.

> (a very small fraction of users tag
> manually, but most do not).
>
This "very small fraction" is much more active than other
mappers and they have very significant influence on tagging.

Tagging discussions (here and elsewhere), wiki docs,
mappers tagging tags directly have a very big influence
especially for establishing new tags.

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

Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

[Paul Allen]

On Sun, 13 Dec 2020 at 14:13, Brian M. Sperlongano 
wrote:

>
> Is it time to more directly recommend that mappers favor natural=water +
> water=reservoir *instead of* rather than *in addition to* landuse=reservoir?
>
> The reality is that no matter what it says in the wiki and no matter what
conclusions we reach on this list, tagging practise is largely determined
by editor presets.  If the user searches for reservoir then how it is
tagged depends on the editor (a very small fraction of users tag
manually, but most do not).

I just tried iD and it gives me natural=water + water=reservoir.  If
the other major editors do the same then the thre choices are:

1) Persuade all the major editors to revert (difficult)

2) Amend the wiki pages to reflect the new reality.

3) Ignore the issue.

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

Re: [Tagging] How to put a name tag on an area with more than one type?

[Anders Torger]

Thanks.

I also think that only having them tied by name is not a good concept.

So what I've settled for (for now) is as follows:

- same name on each part (the only way to get the data useful *today*)
- a new relation with all parts as members (role unset), type=natural, 
natural=wetland, name=


I don't intend this to be a final solution, but if that ever comes, 
having some sort of relation there makes it much easier to find and 
upgrade the tags.


I'm unfortunately not in capacity to work with a pilot project, so this 
have to be done by "someone else" :-/. I also think that a "pilot 
project" should not really just look at one particular problem like 
this. There's a family of problems around mapping nature with high 
detail, and providing data that can be used to generate maps at 
different zoom levels. These are not unique to Sweden, but it's just 
basic cartography. The reason I stumble into these is not because I'm 
mapping in Sweden, it's because I'm mapping with high detail and have 
good data sources with access to those names (and also personal 
experience of using them and maps with them as I engage in outdoor 
activities).


Norway has already come far with high detail land cover mapping here in 
rural north, much longer than we have in Sweden. They also have named 
nature, much of the naming is actually of the same type as this is part 
of Sami lands. How have our Norwegian friends solved the naming problem? 
Easy: by not putting any names in the map, except for lakes and stuff 
that is supported by OSM today.


And this is of course what happens, and it's so frustrating. The 
inability of the OSM community to identify, implement and document basic 
cartography features leaves the geo data of lower quality than it could 
have been if these features would have been readily available for 
mappers to use *now*.


It simply does not work that if a mapper needs a basic feature, he or 
she should then personally engage into OSM politics for many years(!) to 
*maybe* see it implemented. So instead most mappers just think "well, 
maybe I just skip that" and you don't get to hear about it and we can 
still pretend that noone actually needs the feature it's not 
realistic to think that OSM mappers in general should be persons deeply 
invested in how OSM community is organized and just jump right into the 
processes whenever needed. I think what mappers want to do is to map, 
and see their data on display *now*.


I'm not blaming anyone, it's just an observation. I'm myself part of the 
OSM community, and I just said that I don't have the capacity to pull 
any strings in this type of pilot project, so I'm just as much to blame 
as any other. But now I'm at least putting the data in, so if someone 
eventually fixes this, the tags can be upgraded accordingly if needed.


Before I did just like the typical mapper, I just skipped the names that 
couldn't be mapped properly, regardless of their importance. Now I try 
to put them in, in some way or another.


/Anders

On 2020-12-13 12:26, Peter Elderson wrote:


My answer only targets the question in the subject.

No matter whether you put the same name on all parts, or on or some 
kind of collective, you need a way for data users to know that all the 
parts together have a name.
Tagging the same name on all parts makes the name a free text id 
needing uniqueness - for me a bad choice.
Yet another polygon around the area, don't like that. I think we have 
too many of those already.
Tagging all parts with a truly unique Id in a special key could do the 
trick, but who issues/manages the unique ids?


Putting the parts as members in a relation achieves the same: a unique 
Id common to all the parts; the name tag and possible other common 
attributes go on the relation.
This gives renderers the exact extent of the total area, and the 
extents of the subareas, which can have names and other attributes of 
their own.
Since an MP does not cover all possible layouts, you would need a 
different type of relation. Maybe an existing type can be used, or a 
specialised type can be defined.


I would think a pilot project could test the concept for mappers, 
renderers and other data users. If succesful, showcase. If not, 
document and delete.


Peter Elderson

Op vr 11 dec. 2020 om 17:11 schreef Anders Torger :


Hello,

I was on this list a while back expressing some frustration over
limitations when tagging nature and thought about getting involved in 
a
process for change, but I came to realize that it's not feasible for 
me

in my current life situation, so I've decided to continue be a normal
mapper as before, doing what I can do with features that exist today.

Anyway, if to be a mapper at all, I still like to solve some of my
naming issues in the best/least bad ways possible today. I'm currently
mapping a national park in Sweden, Muddus. It's in Laponia and 
consists

of mighty wetlands and old forest. These wetlands are named, like is
common in Sweden 

Re: [Tagging] How to put a name tag on an area with more than one type?

[Paul Allen]

On Sun, 13 Dec 2020 at 12:56, Ture Pålsson via Tagging <
tagging@openstreetmap.org> wrote:

>
> In many cases, the buildings are long gone and just the name remains. I
> *thought* that those places were still labelled in upright letters in the
> ”official” maps, but it turns out that I was wrong — in the present-day
> online-only version of those maps, those names that have lost their
> buildings have turned italic.
>

If the places have lost their buildings, that is what place=locality is
for.  As for
the label being italic or upright depending upon national sensibilities,
that is
why many countries have their own carto.  Sweden has its own carto at
http://openstreetmap.se/ although that has been down every time I've tried
it
in the past couple of weeks.  I don't know if that's recent or is a
continuation of it going down in April.  It may be worth your while
trying to find out why it's down and what it would take to fix it.


> Which is good for us, because it means we could still map building=torp
> where there actually is a building, and something else (historic=torp?
> historic=farm, farm=torp?) where there isn’t. :)
>

 I'm probably misunderstanding this, but torp doesn't seem to be a type of
building.  The tag building=torp says that this building IS a torp (as
opposed to a house, or a shop, or a garage, or a shed, or a barn).
If you feel a need to indicate that a building was once part of a torp,
building=torp isn't the way to do it.

As for historic=farm, the tag historic doesn't mean old (use start_date=*)
or disused (use disused:landuse=farm or add disused=yes).  If the
building is under the protection of a recognized heritage
organization (in Sweden it's the Riksantikvarieämbetet) then add
heritage=* and associated tagging.

Note that one person will probably chime in with a view of historic=*
that makes it applicable to anything more than 1 second old and
therefore meaningless.  I prefer the wiki definition which means it
is for things that are notable rather than just old: historic, not
historical.

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

[Tagging] The saga of landuse=reservoir vs water=reservoir

[Brian M. Sperlongano]

This story is offered because I find it interesting, and as a possible
catalyst for updates to our tagging documentation.  I offer apologies to
those that are well aware of this controversy.

There are two competing ways to tag reservoirs: landuse=reservoir, or
natural=water + water=reservoir.  The reservoirs near me all used the
"landuse" version, and so I only recently became aware of the difference
when another mapper pointed it out.

landuse=reservoir was the original scheme (first documented on the wiki in
2008), while water=reservoir came about three years later, in an approved
2011 proposal[1] which added the key "water".  To read the voting
commentary, the proposal was mildly controversial: one user described the
vote as rushed, and another cited an issue we still discuss in 2020:
whether there is a difference between water=lake and water=pond!

The proposal noted among other things that "landuse=reservoir [is replaced]
by natural=water + water=reservoir".  It further went on to state:

"Until all renderers (which render those areas differently from
natural=water) support those new values, both schemes can be used together:
just add natural=water and water=* to already present tags."

And so, mappers began mappers began adding the new tags to the map.  In
mid-2011, landuse=reservoir sat at 180K usages while the newly-invented
water=reservoir had near-zero usages.  The proposal described that mappers
should use both tagging schemes until renderer support was achieved, after
which (presumably) landuse=reservoir could be safely removed from these
features (and we could finally stop tagging something that is in reality a
type of water as a type of land!)

Renderer support for natural=water is ubiquitous today.  However, there was
no trigger built in to declare that "renderer support has been achieved",
and the double-tagging went on for *eight years*.  By the end of 2018,
tagging of landuse=reservoir had peaked[2], having racked up 450K usages.
The upstart water=reservoir, while still far behind, had been experiencing
a near-exponential growth curve[3], with 180K usages.

2019 was a turning point, and over the last two years, landuse=reservoir
has been on a steady decline, while water=reservoir continued its rapid
growth.  As of today, landuse=reservoir is down to 384K usages, and
water=reservoir has reached 332K usages.  However -- if we exclude nodes
(as there are a large number of presumably imported landuse=reservoir nodes
still hanging out in the map), water=reservoir is slightly ahead - 331K vs
330K.

Now let's turn to what our wiki has to say about this:

"There was considerable confusion whether landuse=reservoir is deprecated,
but it turned out to be not deprecated and landuse=reservoir is used more
widely than "new" way natural=water + water=reservoir."

This is...an interesting lede for a tagging article to say the least!  The
real story behind this awkwardly-worded statement is in the
landuse=reservoir wiki article history, which documents a 9-year-long
low-grade edit war between pro-landuse and pro-water factions.  The comment
about "considerable confusion" was first added in 2014, and has stuck,
despite several attempts over the years to remove it.

This ends our tale.

Is it time to more directly recommend that mappers favor natural=water +
water=reservoir *instead of* rather than *in addition to* landuse=reservoir?


[1] https://wiki.openstreetmap.org/wiki/Proposed_features/Water_details
[2]
https://taginfo.openstreetmap.org/tags/?key=landuse=reservoir#chronology
[3]
https://taginfo.openstreetmap.org/tags/?key=water=reservoir#chronology
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to put a name tag on an area with more than one type?

[Anders Torger]

We have these in the north as well, often old soldier settlements. Many 
are are still inhabited today, but the original building most often long 
gone. We also have those that are abandoned with little sign of that 
there ever being a building there.


Strangely enough, sometimes the names for the abandoned places have more 
relevance today than those still inhabited. The inhabited places have 
modern addresses which are generally used instead, while the abandoned 
places can be used by hunters or other outdoor people for navigating in 
the landscape. But it varies place to place.


I have use place=locality for some of these as I've seen others use it, 
but I haven't had time to give it much thought. It seems like we're 
trying to move away from place=locality and try to be more specific, 
which probably is a good idea.


Currently I'm focusing mostly on nature.

/Anders

On 2020-12-13 11:10, Ture Pålsson via Tagging wrote:


12 dec. 2020 kl. 16:18 skrev Anders Torger :
Indeed, place=locality seems to be a dead end, it's been misused quite 
much and there's talks about removing it from OSM-Carto, and you can't 
render good maps from it, so it's technically a poor concept as well.


Around where I live (Stockholm), most place=locality seem to refer to 
old "torp" [1] and other (at least historically) inhabited places. At 
least the classic "Terrängkartan" (the "official" paper maps of Sweden, 
sadly no longer in production) rendered those differently from pure 
terrain names (upright vs. italic font).


Here in the lake Mälaren valley almost every square meter has been 
farmed at some point, so most names refer to settled places (or 
archaeological traces of them). Up north where I grew up, and where 
Anders seems to be mapping, you get a lot more names that refer to 
bogs, slopes, mountains and that sort of thing.


It would be nice to have that distinction in OSM, too.

[1] https://en.wikipedia.org/wiki/Torp_(architecture)

___
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] How to put a name tag on an area with more than one type?

[Martin Koppenhoefer]

sent from a phone

> On 13. Dec 2020, at 12:30, Peter Elderson  wrote:
> 
> Tagging all parts with a truly unique Id in a special key could do the trick, 
> but who issues/manages the unique ids? 


wikidata?
wikidata:part=Q123?


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

Re: [Tagging] How to put a name tag on an area with more than one type?

[Ture Pålsson via Tagging]

> 13 dec. 2020 kl. 11:40 skrev stevea :
> 
> Thank you, Ture:  an excellent example and a great brief overview.  From my 
> perspective (if I were more of an OSM beginner), I might ask about the 
> example of "torp:"  might creating a tag like building=torp seem like it's on 
> a good track?  Maybe not, as the value is a Swedish word, but there is an 
> historical cognate in British English (more OSM-like for tagging purposes) of 
> "thorpe" (maybe with an e at the end, maybe not) which came from, but doesn't 
> really mean the same thing all by itself in English, 

In many cases, the buildings are long gone and just the name remains. I 
*thought* that those places were still labelled in upright letters in the 
”official” maps, but it turns out that I was wrong — in the present-day 
online-only version of those maps, those names that have lost their buildings 
have turned italic. Which is good for us, because it means we could still map 
building=torp where there actually is a building, and something else 
(historic=torp? historic=farm, farm=torp?) where there isn’t. :)


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

Re: [Tagging] How to put a name tag on an area with more than one type?

[stevea]

Peter, I think (but am not 100% certain) that super-relations are the data 
structure you look for, the "different type of relation."  It isn't QUITE a 
"different type" but rather a method of gathering relations together that 
structures them "sensibly," so, for example, a renderer can make sense of them. 
 We do this with the distinction between "plain" multipolygon relations and 
boundary relations, for example.  (The latter have some additional members in 
the relation with distinct "roles" and that makes them act — display — with 
certain behavior in the renderer).

Pilot projects are a good idea, but they need to be exceedingly clear and 
concise in what they are testing or developing (or both, and really, both in a 
back-and-forth is what works best in the long term).  So, "it's time to be 
specific!"

If renderer authors / developers were to chime in here with their 
understandings / implementations of how "names of areas in super-relations" are 
understood and rendered, that would be helpful.  In fact, that seems like it is 
what is being "wished for," even if not explicitly:  a full explanation of how 
to best "name complex natural=* areas in multiple multipolygons."  If we don't 
get that dialog here, we can achieve the same results with experimentation and 
time.

This (the wondering how things get rendered, or thinking that developing 
something new could get rendered, and importantly HOW this happens) can be a 
difficult topic in OSM.  It often frustrates, confuses and doesn't seem (to me) 
like it is talked about frequently enough.  However, "mapping, then rendering" 
is part of the wondrous magic of OSM.  I understandable that so much "that's 
really amazing" could easily give rise to "other things should be realized as 
just as amazing, too."  However, that's not how it works:  no matter how 
wonderful technology is, we always wish it could be something better.  But it 
doesn't GET better until we develop a path to get us there.  That starts with 
clear explanations, good intentions, skilled people and time.  This project 
does amazing things as we give ourselves these simple ingredients.

SteveA

> On Dec 13, 2020, at 3:26 AM, Peter Elderson  wrote:
> 
> My answer only targets the question in the subject.
> 
> No matter whether you put the same name on all parts, or on or some kind of 
> collective, you need a way for data users to know that all the parts together 
> have a name. 
> Tagging the same name on all parts makes the name a free text id needing 
> uniqueness - for me a bad choice. 
> Yet another polygon around the area, don't like that. I think we have too 
> many of those already. 
> Tagging all parts with a truly unique Id in a special key could do the trick, 
> but who issues/manages the unique ids? 
> Putting the parts as members in a relation achieves the same: a unique Id 
> common to all the parts; the name tag and possible other common attributes go 
> on the relation. 
> This gives renderers the exact extent of the total area, and the extents of 
> the subareas, which can have names and other attributes of their own. 
> Since an MP does not cover all possible layouts, you would need a different 
> type of relation. Maybe an existing type can be used, or a specialised type 
> can be defined.
> 
> I would think a pilot project could test the concept for mappers, renderers 
> and other data users. If succesful, showcase. If not, document and delete.
> 
> Peter Elderson

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

Re: [Tagging] How to put a name tag on an area with more than one type?

[stevea]

Anders, once again, our posts crossed each other!

Thank you for the example – Nominatim helped me find their location 
immediately!  The rendering of swamp distinct from bog "happens to my eyes," 
quite nicely.  I only MIGHT see the problem with the naming being "repeated" — 
it might be correct, it might be incorrect, it might be "different from a 
preference you expect."

Using JOSM, I took a look at the underlying data.  A westerly object, 
relation/11998254 (a typical way of referring to an object in OSM in a realm 
like a mail-list) seems to make perfect sense:  a multipolygon relation tagged 
natural=wetland + wetland=bog + name=Rijmmoáhpe.  A smallish, center-oriented, 
similar relation (same tags), relation/11998257 also has apparently correct 
tagging, except that it also has name=Rijmmoáhpe.  Easterly, similar 
relation/11998253, too.

As I examine the topology (complexities of outers and inners that make the 
combination of all of these together in to one single relation difficult or 
impossible), I think I understand how this presents difficulties.

I might suggest that such topologically complex objects in OSM be handled with 
a super-relation (in this case, a relation of the three relations) where all 
three of the current relations might have their name=Rijmmoáhpe tag removed, 
but the super-relation includes the name and the natural=wetland + wetland=bog 
tags.  Other combinations (of tags on relations, relation objects, or the 
super-relation) might make more sense.  This either does or gets close to 
tagging for the renderer, and I feel I would have to experiment a bit to get 
the desired effect in Carto (I don't know exactly what you are trying to 
achieve along those lines that is different from how Carto renders now).

Regarding "hard to keep track of all parts big and small," I might recommend 
good facility with a quality editor.  When things ARE in a relation, it's hard 
to beat JOSM for keeping track of the parts, I feel its relation editor is 
excellent:  straightforward and visually understandable.  (Quietly, I will say 
I do NOT feel iD's relation editor is even close to this level of facility for 
relation editing; I seem to always be confused editing relations with iD, so I 
have stopped doing so).

You mention "naming problems for which there is no documented way to do."  I'd 
like to understand better what you mean by this, as I believe other readers on 
this list would, too.  Again, I am sorry you find this frustrating and 
apologize if you find you are repeating yourself.  It may be that "drawing out" 
(extracting) what you mean and mean to do (have OSM render) are still underway 
and we will eventually better understand what you believe is "wrong."

"Least bad" is appreciated.  However, I think you may be using "how this 
renders in Carto" for at least a PART of why you say that.  I think it is 
better to understand that the tagging that it takes for that to happen might 
not be the best for OSM, the best for Carto, or both.  This is why we say 
"don't tag for the renderer," because (largely speaking) OSM is a data project. 
 The renderers do their best, but the "feedback loop" that it takes for data 
and renderings to harmonize is a long-term, ongoing process.  It has its 
complexities, it has simultaneous new proposals and tagging happening.  It has 
good mappers trying to pay attention and learn new things and stop doing things 
old ways (which used to work, but are either being phased out or no longer 
work).

When you say "stumble into the same issues," again, I'm sorry if you feel you 
are repeating yourself, I don't know exactly what the issues are.  Or, rather, 
we (on this mail-list) are learning them (well) only now, in that "drawing out" 
process.  When you say "looks horrible," I honestly don't know what you mean.  
"Naming nature" in OSM seems possible to me. It could be that we have to be 
specific with complex topologies.  It could be that we need to fix something, 
but I'm not sure yet.  If you see how our relation:multipolygon wiki takes 
great pains to describe these mathematically complex topics in detail, I think 
you'll agree that this is fairly "tightly" defined:  for example, "valid 
multipolygon conditions" are strict.  When you strictly follow these 
definitions (including name=* tags), does Carto have "issues"?  If so, we want 
to know!

In the meantime, let us know what is "horrible" about these renderings, given 
the tagging.  I disagree with you that "mappers won't map things that don't 
show up on any renderer" because I do that all the time, knowing that OSM is a 
DATA project, not about a particular renderer looking a certain way.  Sure, it 
would be helpful if renderers "read your mind" and "didn't look horrible," but 
they don't, so they can't.  Instead, I'm asking you to be more descriptive, so 
we can both understand what might be done to assuage your sense that OSM is 
"broken."  In a broad sense, it isn't.  (It is broken in minor 

Re: [Tagging] How to put a name tag on an area with more than one type?

[Peter Elderson]

My answer only targets the question in the subject.

No matter whether you put the same name on all parts, or on or some kind of
collective, you need a way for data users to know that all the parts
together have a name.
Tagging the same name on all parts makes the name a free text id
needing uniqueness - for me a bad choice.
Yet another polygon around the area, don't like that. I think we have too
many of those already.
Tagging all parts with a truly unique Id in a special key could do the
trick, but who issues/manages the unique ids?
Putting the parts as members in a relation achieves the same: a unique Id
common to all the parts; the name tag and possible other common attributes
go on the relation.
This gives renderers the exact extent of the total area, and the extents of
the subareas, which can have names and other attributes of their own.
Since an MP does not cover all possible layouts, you would need a different
type of relation. Maybe an existing type can be used, or a specialised type
can be defined.

I would think a pilot project could test the concept for mappers, renderers
and other data users. If succesful, showcase. If not, document and delete.

Peter Elderson


Op vr 11 dec. 2020 om 17:11 schreef Anders Torger :

> Hello,
>
> I was on this list a while back expressing some frustration over
> limitations when tagging nature and thought about getting involved in a
> process for change, but I came to realize that it's not feasible for me
> in my current life situation, so I've decided to continue be a normal
> mapper as before, doing what I can do with features that exist today.
>
> Anyway, if to be a mapper at all, I still like to solve some of my
> naming issues in the best/least bad ways possible today. I'm currently
> mapping a national park in Sweden, Muddus. It's in Laponia and consists
> of mighty wetlands and old forest. These wetlands are named, like is
> common in Sweden and Sami lands. For us navigating in wildlife, names in
> nature are important.
>
> A wetland polygon can be named in OSM, so the situation is better than
> for example for named slopes (also common). However, a wetland here can
> consist of both bog and marsh (and it's important to make the
> difference, since one is easy to walk on, the other not so much). That's
> two different natural types and thus can't be in the same multipolygon
> (as outers).
>
> Asking on OSM Help website for a solution I got the answer to make a new
> containing multipolygon and set the name on that. That would be quite
> elegant for sure, but JOSM warns about that, can't have a name without a
> type, and if I set the type, say natural=wetland without any subtype, I
> get a JOSM warning that I have natural features on top of eachother. If
> I still upload it OSM-Carto does render out the name but you can see
> that the wetland pattern of the outer polygon is drawn on top of the
> contained polygons, so it does not seem to be the way to do it.
>
> The least bad way I've come up with is to just name all polygons
> belonging to the same wetlands the same, and hope for that in the future
> smart renderers will understand that polygons with shared borders and
> shared name is the same named entity.
>
> Any ideas or suggestions?
>
> /Anders
>
> ___
> 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] How to put a name tag on an area with more than one type?

[Anders Torger]

Thanks.

There are quite many abandoned tags for grouping things together, so 
site is in good company. It seems like site is mostly used for 
human-made features though, so I'm not sure it's suitable for natural 
features. For now I don't have the intention that the "natural" relation 
is going to be used by any renderer though, it's just to make it easy in 
JOSM to find all parts belonging to it. If some official method appears 
in the future it will be easy to do search and replace.


/Anders

On 2020-12-13 11:58, Hidde Wieringa wrote:

I just wanted to add `Relation:site` [1] to this topic. This is not an 
approved tag (proposal [2], seems abandoned), but it is used to group 
'things' together which cannot be grouped simply with a multipolygon. I 
do not expect this relation type to be rendered 'correctly' (whatever 
that may mean without a good proposal and definition) in many 
renderers, but the information will exist in OSM in a structured way 
for future renderers.


Example query for South-Sweden: https://overpass-turbo.eu/s/119b

Kind regards,
_Hidde Wieringa_

[1] https://wiki.openstreetmap.org/wiki/Relation:site
[2] https://wiki.openstreetmap.org/wiki/Relations/Proposed/Site

On 13-12-2020 11:28, Anders Torger wrote: Here's a real example of how 
this naming scheme ends up looking:


https://www.torger.se/anders/downloads/Screenshot_2020-12-13-OpenStreetMap.png

I have put the name on each part which is the enduring recommendation 
I've got. Some parts are multipolygons, some are just closed ways, as 
required.


I also added a relation on top. I've got advice against that as no 
renderer will ever care, but I found that when editing it's hard to 
keep track of all parts big and small if there is no relation, so I 
added it as a help for the mapper. I set type=natural (to indicate that 
it's a natural object) and natural=wetland (to indicate what type of 
natural it is, without having to deduce from its members) and name on 
that relation. Nothing official, but at least easy to filter out and 
find.


In Sweden the land cover mapping is heavily behind so I've started a 
mapping effort for natural areas and there are a bunch of naming 
problems to solve for which there is no documented way to do. So I do 
these reference areas and try to come up with the best methods (=least 
bad in some cases) so we in the local Swedish OSM community have 
something to refer to when new mappers want to help out and stumble 
into the same issues.


As seen on the screenshot, the result in OSM-Carto looks pretty 
horrible, and to my knowledge it will be as horrible in any other 
renderer out there as the feature of naming "complex" nature just don't 
exist. It's the usual problem: mappers won't map things that don't show 
up on any renderer (or displays horribly like this), and renderers 
won't implement functions for things that aren't mapped. The OSM way is 
that mappers should take the lead and renderers will eventually follow 
(maybe). I think that process works really poorly today (the main 
reason being that OSM is just too large and diverse now for the 
original processes to work, in global scope every feature becomes just 
a tiny special interest not worth considering). That we still lack 
these cartography features 14 years into the project is witness to 
that. We need a render engine to take the lead, and more well-defined 
standard of how to arrange the data. I've got 4 - 5 different 
suggestions of how to put a name on this wetland. Imagine if all those 
naming schemes gets used, what a mess to implement a renderer...


/Anders

On 2020-12-13 00:55, stevea wrote:
I don't approach this as getting solved in one multipolygon.  I might
use two multipolygons, one tagged wetland=bog, another tagged
wetland=marsh, both tagged natural=wetland.  Add name=* as
appropriate.  Closed ways (plus other things, with other tags) do
overlap (these two seem they should not).  Let renderers deal with
such issues.

Different than natural=* tagging, there is also a proposal that
includes an "unadorned" boundary=protected_area tag (on a closed way
or a relation), without a protect_class tag (one is not known or is
"less known").  This might, someday, render as a simple green line.
This conveys what is (an often legal) boundary, so it isn't natural=*.
See if this proposal
(https://wiki.osm.org/wiki/Proposed_features/Park_boundary) helps wrap
your logic (and OSM's syntax, a boundary=protected_area tag, or its
semantics, a perhaps-someday-drawn rendered green line) around this.
Untangling natural, leisure and boundary tagging is ahead in OSM,
things do get better.

How (the Carto, for example) renderers draw natural=* on top of one
another is actually a rich topic:  it can be said these behaviors are
renderer specific.  (Yes, Carto "drawing order" is not necessarily
perfectly defined).  These are complex topics, getting better as
proposals gain approval (a working strategy so far).  The example of
natural=* tagging below is 

Re: [Tagging] How to put a name tag on an area with more than one type?

[Anders Torger]

It was just an example. Peak is "close enough" for now, and you can 
argue that it works for both mountain and individual peaks. That would 
be okay, but the problem with that is that there is no information for 
the renderer which peaks that should be shown when zoomed out. Some 
renderers just filter out the highest peak (I think opentopomap does 
that), which does work in say 80% of the cases, but sometimes the 
highest peak has a specific name, and the whole mountain is named 
something else.


It's frustrating to see that many OSM folks seems to be "surprised" 
about these things, like it would be something super unique maybe only 
existing in Sweden. It's not. It's just basic cartography of natural 
features all over the world. I was for a while surprised that there's 
not more urgency to fix these type of issues, but once I've learnt about 
how the community works, I'm no longer as surprised, but it's still 
frustrating.


I'm not going to make a wiki entry. I'm just a mapping contributor 
within the current framework, not an OSM developer, and I don't intend 
to become one. I've done my due diligence of OSM and concluded that its 
more about politics than about solving technical problems, and those 
things leads to me burning out.


What I can do is contribute to the map. And I do. I'm a quite advanced 
mapper, including writing my own custom software tools to be able to map 
faster (not automated mapping, but aided manual mapping). When I stumble 
across things that I don't know how to map, I ask questions at OSM Help, 
and if the answer is not satisfactory there, I turn to here. I'm now 
actively involved in the small Swedish OSM community and we discuss how 
to best map things within the existing OSM feature set, and I try to 
come up with reference methods. I've lately been involved in following 
up vandalism. But my engagement ends there, I don't have the capacity to 
do more.


If the only way to cater mapper's needs is for those individual mappers 
to navigate and penetrate OSM politics to what it has grown to today, I 
think we're stuck. I takes a special type of effort and dedication which 
few people posses, and unfortunately I'm not one of them. You will 
probably hear some rumbling frustration from my mapping efforts from 
time to time, but that's it.


/Anders

On 2020-12-13 01:14, stevea wrote:

Anders, I didn't see this until after I sent my reply.

I believe this list here is interested in what you call "missing
features," as a list.  I look at them as challenges of ours or
frustrations of yours which can either be explained or solved.  You
might not like the explanations.

For example, if you were to expound upon differences between
"mountain" (as Anders, or Sweden understands it) and natural=peak (as
OSM understands it), we're listening.  You might be prompted to "make
a proposal for mountain" or "write a wiki for how your first
mountain=whatever or whatever=mountain tag you recently started to
enter (because it is well thought-out, defined, follows sensible rules
about 'what it is' and 'how it is tagged'...)" is now extant, and so
on.

To solve such frustrations doesn't necessarily include this or that
about mountaineering.  This is called reducing the map consumer's
perspective, as you simply "tag well and accurately using a syntax
expressing what you mean."  If there is no such tagging, we might
support it (as new tagging and/or a new proposal) and maybe someday it
will be rendered.  This is (partly) how our map data have grown, it is
how our map data continue to grow.

SteveA

___
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] How to put a name tag on an area with more than one type?

[Hidde Wieringa]

I just wanted to add `Relation:site` [1] to this topic. This is not an 
approved tag (proposal [2], seems abandoned), but it is used to group 
'things' together which cannot be grouped simply with a multipolygon. I 
do not expect this relation type to be rendered 'correctly' (whatever 
that may mean without a good proposal and definition) in many renderers, 
but the information will exist in OSM in a structured way for future 
renderers.


Example query for South-Sweden: https://overpass-turbo.eu/s/119b

Kind regards,
/Hidde Wieringa/

[1] https://wiki.openstreetmap.org/wiki/Relation:site
[2] https://wiki.openstreetmap.org/wiki/Relations/Proposed/Site


On 13-12-2020 11:28, Anders Torger wrote:

Here's a real example of how this naming scheme ends up looking:

https://www.torger.se/anders/downloads/Screenshot_2020-12-13-OpenStreetMap.png 



I have put the name on each part which is the enduring recommendation 
I've got. Some parts are multipolygons, some are just closed ways, as 
required.


I also added a relation on top. I've got advice against that as no 
renderer will ever care, but I found that when editing it's hard to 
keep track of all parts big and small if there is no relation, so I 
added it as a help for the mapper. I set type=natural (to indicate 
that it's a natural object) and natural=wetland (to indicate what type 
of natural it is, without having to deduce from its members) and name 
on that relation. Nothing official, but at least easy to filter out 
and find.


In Sweden the land cover mapping is heavily behind so I've started a 
mapping effort for natural areas and there are a bunch of naming 
problems to solve for which there is no documented way to do. So I do 
these reference areas and try to come up with the best methods (=least 
bad in some cases) so we in the local Swedish OSM community have 
something to refer to when new mappers want to help out and stumble 
into the same issues.


As seen on the screenshot, the result in OSM-Carto looks pretty 
horrible, and to my knowledge it will be as horrible in any other 
renderer out there as the feature of naming "complex" nature just 
don't exist. It's the usual problem: mappers won't map things that 
don't show up on any renderer (or displays horribly like this), and 
renderers won't implement functions for things that aren't mapped. The 
OSM way is that mappers should take the lead and renderers will 
eventually follow (maybe). I think that process works really poorly 
today (the main reason being that OSM is just too large and diverse 
now for the original processes to work, in global scope every feature 
becomes just a tiny special interest not worth considering). That we 
still lack these cartography features 14 years into the project is 
witness to that. We need a render engine to take the lead, and more 
well-defined standard of how to arrange the data. I've got 4 - 5 
different suggestions of how to put a name on this wetland. Imagine if 
all those naming schemes gets used, what a mess to implement a 
renderer...


/Anders

On 2020-12-13 00:55, stevea wrote:

I don't approach this as getting solved in one multipolygon.  I might
use two multipolygons, one tagged wetland=bog, another tagged
wetland=marsh, both tagged natural=wetland.  Add name=* as
appropriate.  Closed ways (plus other things, with other tags) do
overlap (these two seem they should not).  Let renderers deal with
such issues.

Different than natural=* tagging, there is also a proposal that
includes an "unadorned" boundary=protected_area tag (on a closed way
or a relation), without a protect_class tag (one is not known or is
"less known").  This might, someday, render as a simple green line.
This conveys what is (an often legal) boundary, so it isn't natural=*.
 See if this proposal
(https://wiki.osm.org/wiki/Proposed_features/Park_boundary) helps wrap
your logic (and OSM's syntax, a boundary=protected_area tag, or its
semantics, a perhaps-someday-drawn rendered green line) around this.
Untangling natural, leisure and boundary tagging is ahead in OSM,
things do get better.

How (the Carto, for example) renderers draw natural=* on top of one
another is actually a rich topic:  it can be said these behaviors are
renderer specific.  (Yes, Carto "drawing order" is not necessarily
perfectly defined).  These are complex topics, getting better as
proposals gain approval (a working strategy so far).  The example of
natural=* tagging below is a topic of some confusion among mappers.
For example, I don't believe Carto rendering is perfectly predictable
without first knowing "size of all overlapping polygons."  This can
make "accurate" (or pleasing) natural tagging challenging or
unpredictable in some circumstances.  I believe at least some of what
is rendered has to do with the size (and order entered?) of
overlapping polygons.

In short, I "tag the data I know" at the complexity I'm comfortable
tagging them, as accurately as I know how, using OSM's wiki to
describe tagging. 

Re: [Tagging] How to put a name tag on an area with more than one type?

[stevea]

Thank you, Ture:  an excellent example and a great brief overview.  From my 
perspective (if I were more of an OSM beginner), I might ask about the example 
of "torp:"  might creating a tag like building=torp seem like it's on a good 
track?  Maybe not, as the value is a Swedish word, but there is an historical 
cognate in British English (more OSM-like for tagging purposes) of "thorpe" 
(maybe with an e at the end, maybe not) which came from, but doesn't really 
mean the same thing all by itself in English, more of a suffix in a 
village-name (like Scunthorpe or Maplethorp).  Looking at a picture of a "torp" 
in Sweden, and as a native (US) English speaker, I imagine a new tag for this 
might look something like building=summer_house or building=swedish_cottage or 
something along those lines that identify it as a quite-specific thing (as a 
distinct value of the building key).  So, this can be done in OSM:  such things 
do happen.

Regarding "bogs, slopes, mountains..." I hear loud and clear that there are 
challenges with the latter two.  The first, "bog" seems straightforward:  
natural=wetland + wetland=bog (and this combination does seem to be rendered in 
Carto in a specific way, distinct from wetland=marsh; the wikis display these 
differences, even at different zoom levels).

For slopes, I have noticed that "natural=ridge" has begun to render in Carto 
recently, but that's not quite the same as slope, but might begin to help if 
you must use a tag that renders today.  For mountains, I understand that this 
is NOT the same as natural=peak, so I think this mail-list would be interested 
to hear how a natural=peak and a mountain (as understood in Sweden, or perhaps 
"meant" on a map that calls such a thing what it calls it in Swedish on a map 
like Terrängkartan).  It seems those distinctions could be made in the form of 
an (early) wiki (if such tagging began, because it was well-formed enough to 
quickly draw up a wiki for it) or a proposal, which also seems it could be 
straightforward to write and gain approval.  There was a tag for natural=arete 
("a thin, almost knife-like, ridge of rock which is typically formed when two 
glaciers erode parallel U-shaped valleys") which became approved and then began 
to render.  (I had never heard of this, but when I read the wiki, I thought 
"OK, that simply means I've never heard of this, but it's real, so let's define 
it, document it and tag it).  So, this process is established and can happen 
for "swedish_mountain" (I'm making up an obviously unreal tag, but calling it 
in Swedish or maybe an equivalent-to-British-English word if that's possible) 
can open up possibilities for OSM can be the map Anders dreams of.  I think it 
can.  With explanation, some process being followed and some time, it can.

Yes, it IS nice when OSM has distinctions where distinctions are actually 
distinctions in the real world.  Let's make them together as a community so we 
can all share them!

SteveA

> On Dec 13, 2020, at 2:10 AM, Ture Pålsson via Tagging 
>  wrote:
> 
> 
>> 12 dec. 2020 kl. 16:18 skrev Anders Torger :
>> 
>> Indeed, place=locality seems to be a dead end, it's been misused quite much 
>> and there's talks about removing it from OSM-Carto, and you can't render 
>> good maps from it, so it's technically a poor concept as well. 
> 
> Around where I live (Stockholm), most place=locality seem to refer to old 
> ”torp” [1] and other (at least historically) inhabited places. At least the 
> classic ”Terrängkartan” (the ”official” paper maps of Sweden, sadly no longer 
> in production) rendered those differently from pure terrain names (upright 
> vs. italic font).
> 
> Here in the lake Mälaren valley almost every square meter has been farmed at 
> some point, so most names refer to settled places (or archaeological traces 
> of them). Up north where I grew up, and where Anders seems to be mapping, you 
> get a lot more names that refer to bogs, slopes, mountains and that sort of 
> thing.
> 
> It would be nice to have that distinction in OSM, too.
> 
> [1] https://en.wikipedia.org/wiki/Torp_(architecture)
> 
> 
> ___
> 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] How to put a name tag on an area with more than one type?

[Anders Torger]

Here's a real example of how this naming scheme ends up looking:

https://www.torger.se/anders/downloads/Screenshot_2020-12-13-OpenStreetMap.png

I have put the name on each part which is the enduring recommendation 
I've got. Some parts are multipolygons, some are just closed ways, as 
required.


I also added a relation on top. I've got advice against that as no 
renderer will ever care, but I found that when editing it's hard to keep 
track of all parts big and small if there is no relation, so I added it 
as a help for the mapper. I set type=natural (to indicate that it's a 
natural object) and natural=wetland (to indicate what type of natural it 
is, without having to deduce from its members) and name on that 
relation. Nothing official, but at least easy to filter out and find.


In Sweden the land cover mapping is heavily behind so I've started a 
mapping effort for natural areas and there are a bunch of naming 
problems to solve for which there is no documented way to do. So I do 
these reference areas and try to come up with the best methods (=least 
bad in some cases) so we in the local Swedish OSM community have 
something to refer to when new mappers want to help out and stumble into 
the same issues.


As seen on the screenshot, the result in OSM-Carto looks pretty 
horrible, and to my knowledge it will be as horrible in any other 
renderer out there as the feature of naming "complex" nature just don't 
exist. It's the usual problem: mappers won't map things that don't show 
up on any renderer (or displays horribly like this), and renderers won't 
implement functions for things that aren't mapped. The OSM way is that 
mappers should take the lead and renderers will eventually follow 
(maybe). I think that process works really poorly today (the main reason 
being that OSM is just too large and diverse now for the original 
processes to work, in global scope every feature becomes just a tiny 
special interest not worth considering). That we still lack these 
cartography features 14 years into the project is witness to that. We 
need a render engine to take the lead, and more well-defined standard of 
how to arrange the data. I've got 4 - 5 different suggestions of how to 
put a name on this wetland. Imagine if all those naming schemes gets 
used, what a mess to implement a renderer...


/Anders

On 2020-12-13 00:55, stevea wrote:

I don't approach this as getting solved in one multipolygon.  I might
use two multipolygons, one tagged wetland=bog, another tagged
wetland=marsh, both tagged natural=wetland.  Add name=* as
appropriate.  Closed ways (plus other things, with other tags) do
overlap (these two seem they should not).  Let renderers deal with
such issues.

Different than natural=* tagging, there is also a proposal that
includes an "unadorned" boundary=protected_area tag (on a closed way
or a relation), without a protect_class tag (one is not known or is
"less known").  This might, someday, render as a simple green line.
This conveys what is (an often legal) boundary, so it isn't natural=*.
 See if this proposal
(https://wiki.osm.org/wiki/Proposed_features/Park_boundary) helps wrap
your logic (and OSM's syntax, a boundary=protected_area tag, or its
semantics, a perhaps-someday-drawn rendered green line) around this.
Untangling natural, leisure and boundary tagging is ahead in OSM,
things do get better.

How (the Carto, for example) renderers draw natural=* on top of one
another is actually a rich topic:  it can be said these behaviors are
renderer specific.  (Yes, Carto "drawing order" is not necessarily
perfectly defined).  These are complex topics, getting better as
proposals gain approval (a working strategy so far).  The example of
natural=* tagging below is a topic of some confusion among mappers.
For example, I don't believe Carto rendering is perfectly predictable
without first knowing "size of all overlapping polygons."  This can
make "accurate" (or pleasing) natural tagging challenging or
unpredictable in some circumstances.  I believe at least some of what
is rendered has to do with the size (and order entered?) of
overlapping polygons.

In short, I "tag the data I know" at the complexity I'm comfortable
tagging them, as accurately as I know how, using OSM's wiki to
describe tagging.  Multipolygons differ from relations like them which
aren't (like those tagged boundary=*), independently as far as
renderers are concerned.  It is easy to get confused, confusion exists
in the map:  semantics are blurry in some cases.  This gets better
with worldwide consensus, over years.  This (how we learn to best tag
and render) is an ongoing long-term OSM process.  As a mapper, "tag
accurately first," then let renderers interpret.

SteveA


On Dec 11, 2020, at 11:53 AM, Anders Torger  wrote:

Unfortunately I don't think that is possible.

Multipolygons may only contain ways that have either role as inner or 
as outer. It may not contain other relations (still possible to 
upload, but not 

Re: [Tagging] How to put a name tag on an area with more than one type?

[Ture Pålsson via Tagging]

> 12 dec. 2020 kl. 16:18 skrev Anders Torger :
> 
> Indeed, place=locality seems to be a dead end, it's been misused quite much 
> and there's talks about removing it from OSM-Carto, and you can't render good 
> maps from it, so it's technically a poor concept as well. 


Around where I live (Stockholm), most place=locality seem to refer to old 
”torp” [1] and other (at least historically) inhabited places. At least the 
classic ”Terrängkartan” (the ”official” paper maps of Sweden, sadly no longer 
in production) rendered those differently from pure terrain names (upright vs. 
italic font).

Here in the lake Mälaren valley almost every square meter has been farmed at 
some point, so most names refer to settled places (or archaeological traces of 
them). Up north where I grew up, and where Anders seems to be mapping, you get 
a lot more names that refer to bogs, slopes, mountains and that sort of thing.

It would be nice to have that distinction in OSM, too.

[1] https://en.wikipedia.org/wiki/Torp_(architecture)


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

Re: [Tagging] Proposed feature - RFC - Military Bases

[Martin Koppenhoefer]

sent from a phone

> On 13. Dec 2020, at 03:18, Graeme Fitzpatrick  wrote:
> 
> In regard to operators - "USMC" or "United States Marine Corps", & the same 
> for all the other names ie abbreviated or spelt if full ?


fully spelt out 

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

Re: [Tagging] Mapping bicycle-only turn lanes

[Mateusz Konieczny via Tagging]

Dec 12, 2020, 14:25 by ba...@ursamundi.org:

>
>
> On Sat, Dec 12, 2020 at 5:25 AM Jan Michel <> j...@mueschelsoft.de> > wrote:
>
>> Hi,
>>  where do you see a problem here? The current situation might not be 
>>  perfect, but it is usable as it is. The only thing to keep in mind is 
>>  that the number of "lanes" does not need to match the number of entries 
>>  in the "XY:lanes" tags.
>>
>
> That disagrees with literally every lane editing and validation tool in 
> existence at this time.
>
Can you give examples of validation tools and lane editing software that 
disagrees
with it?

The proper solution would be to make tag traffic_lanes or something that
would count also bicycle lanes, not redefine lane tag.

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

Re: [Tagging] Feature Proposal - RFC - wait

[Mateusz Konieczny via Tagging]

Seems well done to me.

I even know two places where it would be taggable.


Dec 13, 2020, 06:28 by antoniomade...@gmx.com:

> Greetings.
>
> As discussed here in the mailing list, me and L___I have created a
> proposal for the key "wait":
> https://wiki.openstreetmap.org/wiki/Proposed_features/wait
>
> Please, comment here in the list or in the wiki talk page.
>
>
> Previous discussions:
> https://lists.openstreetmap.org/pipermail/tagging/2020-May/052321.html
> https://forum.openstreetmap.org/viewtopic.php?id=69011
>
>
> Regards,
> António.
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

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