date:20221011

sent from a phone

> On 10 Oct 2022, at 12:07, Michael Brandtner  wrote:
> 
> The proposal includes advice to only use this tag in shops that don't accept 
> all denominations

in Italy, one and two cent coins have been abolished, they are not accepted any 
more in shops, and while prices are still ending mostly with 9, the sum gets 
rounded.

I guess this should not be mapped because the default?

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

Re: [Tagging] RFC - More sensible values for fountain=*

I do not like very much at all the key 
"new_key_describing_fountain_style" — if that is really a literal key 
you (Davidoskky) are proposing here. If it is a place-holder for what 
we eventually decide upon FOR the semantics of that key, then OK, I'm 
nodding my head and continue to listen / read. 


Of course, this is not the key I'm actually proposing. I just don't want 
to get in another discussion about semantics and thus I would like to 
simply discuss the need of such a key without defining the actual name.


If people agree that such key is required I will then try to find, 
together with you, an appropriate name for such key.



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

Re: [Tagging] RFC - More sensible values for fountain=*




Of course, this is not the key I'm actually proposing. I just don't 
want to get in another discussion about semantics and thus I would 
like to simply discuss the need of such a key without defining the 
actual name.


If people agree that such key is required I will then try to find, 
together with you, an appropriate name for such key.


Scouring the wiki I found a key that might be perfect for this: model=* 
https://wiki.openstreetmap.org/wiki/Key:model


It has over 32,000 uses and it is used to define the model of several 
different features.


I will prepare a proposal for this now; since this key is already 
affirmed and approved we just need to approve that it should be used for 
fountains as well.


Some use the main_feature:model namespace, but in this case it shouldn't 
be required since we are describing the model of the primary feature 
(the fountain). Counting those tags as well the count of uses is over 
43,000.



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

Re: [Tagging] RFC - More sensible values for fountain=*


On 10/10/22 10:45, Marc_marc wrote:
it's vague and overlap drinking at least 


Sorry, I didn't notice this and thus didn't reply to you before.

I want this to be a more generic value than drinking: thus if you're 
unsure whether a fountain is a drinking fountain you can tag it as utility.


If you want to tag a fountain, which is not decorative and for which no 
specific value exists you can tag it as utility. In this way I make sure 
that any fountain can be tagged.


For example, there is currently no value available for fountains whose 
intended use is washing your hands. Rather than introducing all 
plausible values, I'd rather introduce a generic one and then see if the 
need for specific ones develops.



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

Re: [Tagging] RFC - More sensible values for fountain=*

Am Mo., 10. Okt. 2022 um 09:53 Uhr schrieb Davidoskky via Tagging <
tagging@openstreetmap.org>:

> I do not believe
> anymore that man_made=water_tap should be deprecated but rather
> redefined to only describe the tap of a fountain and not the whole
> fountain.
>


this is not a redefinition, it is already like this. man_made=water_tap
describes a water tap.



> *Proposal summary*
>
> amenity=fountain describes both decorative fountains and utility
> fountains, such as drinking fountains, small fountains for washing
> clothes, fountains to clean people or provide water to animals; this
> would not include large facilities with one single scope in mind: for
> example a building where people go to wash clothes would not fall under
> this tag.
>


a feature for washing clothes for me is not a "fountain", it is a lavoir, a
laundry sink, or something similar.
I do not understand what "fountains to clean people" are, could you give an
example?



>
> Introduction of the key fountain:style=* that accepts as values all the
> ones currently listed in the wiki as "Specific types of drinking water
> fountains"; translation of the definition of all those fountains to
> fountain=drinking, fountain:style=*.
>


the word "style", if used in opposition to "type", suggests something like
"fashion" to me, or art/architectural epoche style (e.g. art deco, modern,
post-modern, renaissance, barocco, etc.)




>
> Introduction of the key tap=yes, used to describe if the flow of a
> fountain can be controlled by the user.
>


is already introduced



>
> Introduction of the generic value fountain=decorative, that ensures the
> fountain is decorative.
>


it is already introduced, 953 instances as of now, but actually it may
create problems for example in the case of a "decorative drinking
fountain", and because "decorative" is not clearly defined. Maybe this
situation could be improved.




>
> Introduction of the generic value fountain=utility, that describes the
> fountain as non-decorative.
>


yet another generic type, even more generic then "drinking"?



>
> Deprecation of fountain=drinking_fountain in favour of fountain=drinking.
>


this alternative tagging is just a temporary hickup which will wash out
automatically I guess, but we could try to speed it up.



>
> The idea is that fountains not covered by the current values can still
> be tagged as either decorative or utility even if a specific tag does
> not exist.
>


my suggestion would be to have other generic values, but slightly more
specific than "utility", to cover the cases that are not yet covered by the
documented values.




>
> You can propose other values for fountain=* but I guess those will come
> with time anyway, since the idea is to make this easily extensible.
>


the benefit of documenting key/values is that the chance is bigger that
everybody uses the same or similar definitions for the same key. Keep in
mind that having 2 tags for the exactly same thing is not a big deal, it is
almost no problem at all, it can be interpreted without problems and the
effort to deal with both is almost not existent (and automatic retagging
could be performed without problems). On the other hand, people using the
same tag for (also only slightly) different things, is a huge problem and
leads to ambiguity and cannot be solved automatically, all instances have
to looked at again




>
>
> I would propose the deprecation of the value fountain=stone_block since
> it could be tagged as fountain=driking, material=stone.



no it cannot. There are many fountains made of stone, but not all them are
instances of "stone block".



> This tag impedes
> tagging the fountain with a specific value in order to describe its
> material.
>
>
> I'm unsure whether fountain=bottle_refill should be kept.
>
> In the wiki it is decribed by this image:
>
> https://wiki.openstreetmap.org/wiki/File:Fairmont_Sonoma_Mission_Inn_August_2019_-_Sarah_Stierch_09.jpg
>
> The water does not come through pipes, but from a nearby water
> container. I'd rather tag it as its own amenity.
>


I agree with this. These machines are no "fountains" for me, neither the
indoor versions, nor their rugged outdoor sisters.

Regarding the proposal: I would not make a big proposal package which aims
at changing all the things you mention, rather I would suggest to make
distinct proposals for each of these changes.

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

Re: [Tagging] RFC - More sensible values for fountain=*




Oct 11, 2022, 09:48 by tagging@openstreetmap.org:

>> Of course, this is not the key I'm actually proposing. I just don't want to 
>> get in another discussion about semantics and thus I would like to simply 
>> discuss the need of such a key without defining the actual name.
>>
>> If people agree that such key is required I will then try to find, together 
>> with you, an appropriate name for such key.
>>
>
> Scouring the wiki I found a key that might be perfect for this: model=* 
> https://wiki.openstreetmap.org/wiki/Key:model
>
> It has over 32,000 uses and it is used to define the model of several 
> different features.
>
> I will prepare a proposal for this now; since this key is already affirmed 
> and approved we just need to approve that it should be used for fountains as 
> well.
>
Is it possible that drinking fountain in a given style has multiple models?

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

Re: [Tagging] RFC - More sensible values for fountain=*


Le 11.10.22 à 09:48, Davidoskky via Tagging a écrit :

we just need to approve that it should be used for fountains as well. 


you do not need to have the use of a key "approved for fountains" that 
would respect the meaning of the approved tag.
however it would be useful to discuss/approve the most relevant values 
to describe the known cases


Some use the main_feature:model namespace, but in this case it shouldn't 
be required since we are describing the model of the primary feature 
(the fountain).


the namespace isn't needed, it's just a bad pratice due to a missing 
feature in iD (another editor uses taginfo combinations to propose the 
most relevant values, iD on the other hand proposes everything often 
without filter, but as I said, it is not a reason to invent shop:brand 
or shop:name, it is a point which must be improved in iD and not by the 
abuse of namespace)




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

Re: [Tagging] RFC - More sensible values for fountain=*

Am Di., 11. Okt. 2022 um 10:24 Uhr schrieb Mateusz Konieczny via Tagging <
tagging@openstreetmap.org>:

>
> Is it possible that drinking fountain in a given style has multiple models?
>


absolutely yes.

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

Re: [Tagging] Feature Proposal - RFC - Water outlet

Am Mo., 10. Okt. 2022 um 17:33 Uhr schrieb Illia Marchenko <
illiamarchenk...@gmail.com>:

> Unification of tags allows more simple usage source data, e.g leisure =
> pitch allows rendering of all pitches, but lots of tags as
> leisure=tennis_court, leisure = baseball_playground, leisure =
> football_ground is more difficult to use.
>


yes, all pitches, and also things that aren't pitches, they only get this
same tag in OSM for some reason ;-)
On the other hand, if you are looking for places to do sports, it is not
sufficient to look at leisure=pitch if you want to find all of them.

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

Re: [Tagging] RFC - More sensible values for fountain=*


Le 11.10.22 à 10:19, Martin Koppenhoefer a écrit :


Am Mo., 10. Okt. 2022 um 09:53 Uhr schrieb Davidoskky :
I would propose the deprecation of the value fountain=stone_block 
since it could be tagged as fountain=driking, material=stone.


There are many fountains made of stone, but not all them 
are instances of "stone block".


a better improvement is material=stone_block
or stone:block (like we did with concrete:plate)



https://wiki.openstreetmap.org/wiki/File:Fairmont_Sonoma_Mission_Inn_August_2019_-_Sarah_Stierch_09.jpg

I agree with this. These machines are no "fountains" for me,  
neither the indoor versions


to add a mess to the mess, in french, it's a called "fountaine à eau" 
(yes it's a bit funny)

I don't really see the functional difference with other objects
of the same kind made of metal or pirate

Regards,
Marc



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

Re: [Tagging] RFC - More sensible values for fountain=*


On 11/10/22 10:22, Marc_marc wrote:
you do not need to have the use of a key "approved for fountains" that 
would respect the meaning of the approved tag.
however it would be useful to discuss/approve the most relevant values 
to describe the known cases 
We would need to approve that certain keys are moved from fountain=* to 
model=* and that model=* should be documented in the amenity=fountain 
and fountain=* wiki pages.


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

Re: [Tagging] RFC - More sensible values for fountain=*



On 11/10/22 10:25, Martin Koppenhoefer wrote:


Is it possible that drinking fountain in a given style has
multiple models?

absolutely yes.


Would this be a problem at the current state of things?

Nobody is tagging the specific model type, such as distinguishing nasone 
from the 1960s and nasone from the 1990s.


Should we introduce another key for the style and then tag the specific 
model of the fountain style as new_key=nasone, new_key:model=model_1960?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Water outlet

2022-10-11 Thread Illia Marchenko

вт, 11 окт. 2022 г., 11:48 Martin Koppenhoefer :

> On the other hand, if you are looking for places to do sports, it is not
> sufficient to look at leisure=pitch if you want to find all of them.
>

Of course. Hierarchical tagging. leisure = pitch & sport = *.

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

Re: [Tagging] RFC - More sensible values for fountain=*

On 11/10/22 10:19, Martin Koppenhoefer wrote:
this is not a redefinition, it is already like this.
man_made=water_tap describes a water tap.

man_made=water_tap is de facto being used to describe larger structures
that contain a water tap. This wouldn't be a problem if there was a way
to actually describe those features.

a feature for washing clothes for me is not a "fountain", it is a
lavoir, a laundry sink, or something similar.
Some are indistinguishable from drinking fountains, some have drinking
water and can be used to wash clothes as well.

I do not understand what "fountains to clean people" are, could you
give an example?

I had a walk the other day, you may look at these two pictures I took.

https://commons.wikimedia.org/wiki/File:Water_fountain_with_water_basin_near_Santiago_de_Compostela.jpg

https://commons.wikimedia.org/wiki/File:Water_fountain_without_tap_near_Santiago_de_Compostela.jpg

the word "style", if used in opposition to "type", suggests something
like "fashion" to me, or art/architectural epoche style (e.g. art
deco, modern, post-modern, renaissance, barocco, etc.)

Agreed, style is not a good name for such key.

Introduction of the key tap=yes, used to describe if the flow of a
fountain can be controlled by the user.

is already introduced
Not really, tap=yes has 347 uses and it's used only regionally in
Dominican Republic to tag the presence of taps in a building.

- It is not used to mark the presence of a tap in a fountain

- It is not approved

- It is not documented on the wiki.

Refer here:
https://lists.openstreetmap.org/pipermail/tagging/2022-October/065939.html

it is already introduced, 953 instances as of now, but actually it may
create problems for example in the case of a "decorative drinking
fountain", and because "decorative" is not clearly defined. Maybe this
situation could be improved.
Sure, I meant documenting it in the wiki and finding solutions for these
edge cases. If my idea was already a perfect full blown proposal I would
have published the proposal already.

yet another generic type, even more generic then "drinking"?
fountain=drinking is not generic enough, since there are types of non
decorative fountains that cannot be tagged in any way.

Refer here:
https://lists.openstreetmap.org/pipermail/tagging/2022-October/065936.html

my suggestion would be to have other generic values, but slightly more
specific than "utility", to cover the cases that are not yet covered
by the documented values.
I do agree, and that is also my objective; but I do like the idea of
having a very generic value you can fall back to when no other value
applies.

this alternative tagging is just a temporary hickup which will wash
out automatically I guess, but we could try to speed it up.

Sure, but I see no reason for showing it on the wiki.

On the other hand, people using the same tag for (also only slightly)
different things, is a huge problem and leads to ambiguity and cannot
be solved automatically, all instances have to looked at again
I understand the problem, but I do not wish to start looking at all
possible existing fountain types in the world to make an exhaustive
list. Especially when people here start fighting about the specific name
of a fountain meant for drinking.

no it cannot. There are many fountains made of stone, but not all them
are instances of "stone block".
The value is ambiguous: it is described as any fountain that consists
mostly of a stone block. It may be a decorative fountain or a drinking
fountain or another type of fountain.

As you said:

using the same tag for (also only slightly) different things, is a
huge problem

Regarding the proposal: I would not make a big proposal package which
aims at changing all the things you mention, rather I would suggest to
make distinct proposals for each of these changes.
I think I will follow your advice. I'm currently thinking of two
separate proposals: one for introducing the fountains model (or whatever
new key we decide to introduce) and another one to introduce tap=* as a
way to describe the presence of a tap in a fountain. (Please, discuss
about these things in the thread wherever it is and not here)

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

Re: [Tagging] RFC - More sensible values for fountain=*

sent from a phone

> On 11 Oct 2022, at 11:30, Davidoskky via Tagging  
> wrote:
> 
> Nobody is tagging the specific model type, such as distinguishing nasone from 
> the 1960s and nasone from the 1990s.
> 
> Should we introduce another key for the style and then tag the specific model 
> of the fountain style as new_key=nasone, new_key:model=model_1960?
> 

I still haven’t discovered the problem with fountain=nasone. If you are not in 
Rome you will hardly ever come in contact with it, if you are in Rome, you will 
easily find out what it is about. If you don’t evaluate fountain=nasone in your 
app, it will gracefully degrade to amenity=drinking_water.

When we tag a “model” it will sooner or later become a geek tag which would 
indeed distinguish a 60ies from a 90ies nasone :D

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

Re: [Tagging] RFC - More sensible values for fountain=*

sent from a phone

> On 11 Oct 2022, at 12:06, Davidoskky  wrote:
> 
> Some are indistinguishable from drinking fountains, some have drinking water 
> and can be used to wash clothes as well.

all drinking fountains can be used to wash clothes, although it may not be 
legal in some instances, especially the bottle refill, or effective (mist), ok, 
nearly all.

Anyway, I would not mix the possibility to wash clothes into the fountain type, 
rather use a new property for this, and maybe a new feature as well (usually 
these are not fountains, but if they are it can be expressed by tagging them 
also as fountains), if lavoir does not cover it (not sure there is a size limit 
for lavoir, the description seems merely functional).

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

Re: [Tagging] RFC - More sensible values for fountain=*

sent from a phone

> On 11 Oct 2022, at 12:06, Davidoskky  wrote:
> 
> I do agree, and that is also my objective; but I do like the idea of having a 
> very generic value you can fall back to when no other value applies.

I don’t like the idea, because it will only slow down development of 
significant tags. Either the fountain you want to tag fits into an existing 
category, or you invent a new one, or you simply don’t put this detail. Filling 
in a generic placeholder is not helpful.

> 
> 
>> this alternative tagging is just a temporary hickup which will wash out 
>> automatically I guess, but we could try to speed it up.
> Sure, but I see no reason for showing it on the wiki.

reason is that people use it. 

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

Re: [Tagging] RFC - More sensible values for fountain=*


Le 11.10.22 à 12:27, Martin Koppenhoefer a écrit :
When we tag a “model” it will sooner or later become a geek tag which 
would indeed distinguish a 60ies from a 90ies nasone :D


model=nasone as a 1st step
if ppl want, model=nasone_1960 or model=nasone:1960 or :date isn't
an issue



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

[Tagging] camp sites in Haiti

2022-10-11 Thread Anne-Karoline Distel


Hello,

I noticed that many of the refugee camps in Haiti are tagged as
tourism=camp_site which made me uneasy. Turns out there is the tag
amenity=refugee_site. Would it be possible to re-tag those refugee camps
in an automated edit? There are about 60 or 70 mapped. I'm not even sure
if they all still exist 12 years later.

Anne


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

Re: [Tagging] RFC - More sensible values for fountain=*




Oct 11, 2022, 12:27 by dieterdre...@gmail.com:

>
>
> sent from a phone
>
>
>> On 11 Oct 2022, at 11:30, Davidoskky via Tagging  
>> wrote:
>>
>>
>> Nobody is tagging the specific model type, such as distinguishing  
>> nasone from the 1960s and nasone from the 1990s.
>>
>>
>> Should we introduce another key for the style and then tag the  specific 
>> model of the fountain style as new_key=nasone,  new_key:model=model_1960?
>>
>>
>
>
> I still haven’t discovered the problem with fountain=nasone. If you are not 
> in Rome you will hardly ever come in contact with it, if you are in Rome, you 
> will easily find out what it is about. If you don’t evaluate fountain=nasone 
> in your app, it will gracefully degrade to amenity=drinking_water.
>
> When we tag a “model” it will sooner or later become a geek tag which would 
> indeed distinguish a 60ies from a 90ies nasone :D
>
main problems are that either

- editor will need to handle specific models as values
- this values will be not supported by editors and mappers will use less 
specific values
(this is not a problem if mappers using model values will never, ever complain
to mappers using only generic values and will never, ever complain to 
authors of editing software and noone will suggest adding support for model 
values in editing software

what is impossible to achieve)

And also
- there is no graceful degradation to "it is drinking fountain"
- wiki documentation pages are more confusing as result
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC - More sensible values for fountain=*


On 11/10/22 12:43, Martin Koppenhoefer wrote:
or you simply don’t put this detail. 


This is problematic, since if you only tag amenity=fountain it will fall 
back to a decorative fountain since amenity=fountain appears to be 
defined in that way.


I'll repeat the problems with the current tagging scheme that I already 
listed elsewhere.


If I have a fountain that is not decorative, doesn't have a tap and 
doesn't provide drinking water, this fountain cannot be tagged.


Because no main key applies to it.

- Not a decorative fountain, thus not an amenity=fountain

- Doesn't provide drinking water, thus not an amenity=drinking_water

- Does not have a tap, thus not a man_made=water_tap


How would you tag this fountain I photographed the other day?

The water is not potable, the stream of water cannot be interrupted and 
definitely is not a decorative fountain.


https://commons.wikimedia.org/wiki/File:Water_fountain_without_tap_near_Santiago_de_Compostela.jpg


Using amenity=fountain, fountain=utility will allow tagging this fountain.

As I said, the alternative would be to introduce another main tag under 
which to tag these features, but that was harshly criticized.



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

[Tagging] offlist Re: RFC - More sensible values for fountain=*


Le 11.10.22 à 13:25, Davidoskky via Tagging a écrit :
If I have a fountain that is not decorative, doesn't have a tap and 
doesn't provide drinking water, this fountain cannot be tagged.


Because no main key applies to it.

- Not a decorative fountain, thus not an amenity=fountain

- Doesn't provide drinking water, thus not an amenity=drinking_water

- Does not have a tap, thus not a man_made=water_tap


off list : in my opinion, the decorative aspect ((especially as it is 
very subjective, stone_block and half of the values are not decorative 
for me) should be put aside for the moment, as in BE, decorative 
fountains are not called fountain and fountain is not decorative




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

Re: [Tagging] RFC - More sensible values for fountain=*


Le 11.10.22 à 11:23, Davidoskky via Tagging a écrit :

On 11/10/22 10:22, Marc_marc wrote:
you do not need to have the use of a key "approved for fountains" that 
would respect the meaning of the approved tag.
however it would be useful to discuss/approve the most relevant values 
to describe the known cases 
We would need to approve that certain keys are moved from fountain=* to 
model=*  


on this point: yes
and I think this should be a fairly simple proposal and likely to be 
accepted since it avoids multiple meanings of fountain=* (function <> 
style <> ...)




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

[Tagging] offlist about for


Le 10.10.22 à 11:14, Davidoskky via Tagging a écrit :
for=drinking/bottle/dog/... to describe how it can be used 
I'm quite unsure about this idea... a fountain that spouts water 
downwards can be used to fill bottles, to drink and to let dogs (and 
other animals?) drink.


for=bottle;drinking;dog :)

I'll open soon a thread about inaccuracies between
https://wiki.openstreetmap.org/wiki/Any_tags_you_like#Syntactic_conventions_for_new_values
Properties can have a large number of possible values

and
https://wiki.openstreetmap.org/wiki/Good_practice#Don't_over-use_semi-colon_separated_values
poorly supported by data consumers for top-level tags

and
https://wiki.openstreetmap.org/wiki/Semi-colon_value_separator
On important "top-level" tags that define what an element is avoid ; 
separated values *whenever possible* (when it'sn't possible ?)
Don't use them in your mapping, and don't propose them on the wiki if 
there are better ways of representing things (what's a better ways that 
doesn't conflict with the previous rule "Properties can have a large 
number of possible values" = key=yes/no value aren't a propertie, it's 
the value for another key


Regards,
Marc



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

Re: [Tagging] offlist about for


bad thread, sorry :(



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

[Tagging] advices about multiple values have inaccuracies , between several pages


Hello,

I find that advices about multiple values have inaccuracies
between several pages :

https://wiki.openstreetmap.org/wiki/Any_tags_you_like#Syntactic_conventions_for_new_values
Properties can have a large number of possible values
my reading : key=yes/no value aren't a propertie, it's the value for 
another key (for ex asia=yes/no is not a good idea, it's a value for 
cuisine=asia


and
https://wiki.openstreetmap.org/wiki/Good_practice#Don't_over-use_semi-colon_separated_values
poorly supported by data consumers for top-level tags
my reading : I agree for top-level tag and I would even tend to say
that I don't know of any tool that manages multiple values in a 
top-level tag


and
https://wiki.openstreetmap.org/wiki/Semi-colon_value_separator
On important "top-level" tags that define what an element is avoid ; 
separated values *whenever possible*
Don't use them in your mapping, and don't propose them on the wiki if 
there are better ways of representing things
my reading : when it'sn't possible ? what's a better ways that doesn't 
conflict with the previous rule "Properties can have a large number of 
possible values" = key=yes/no value aren't a propertie, it's the value 
for another key


*suggestion*: bring the content of the 3 pages together to have
a coherent argumentation which seems to me to be :

1) never use multiple values in a main key, no tool manages it and it is 
not a good idea to describe an object with multiple "features


2) Properties can have a large number of possible values
key with only =yes/no value aren't a propertie, it's the value
for another key

3) refine *if there are better ways of representing things"
and this brings us back to the somewhat conflicting subject
of informing what doesn't exist, e.g. this restaurant doesn't
do such and such a type of cooking when you would expect it to, etc
Shouldn't a special character be defined to indicate a negation ?
For example, if we were to use the word cuisine=-asia, it would
be more consistent than hearing regularly that we should create
a cuisine:asia=no

Regards,
Marc



___
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] RFC - More sensible values for fountain=*

sent from a phone

> On 11 Oct 2022, at 13:30, Davidoskky via Tagging  
> wrote:
> 
> This is problematic, since if you only tag amenity=fountain it will fall back 
> to a decorative fountain since amenity=fountain appears to be defined in that 
> way.

those fountains that supply drinking water have the drinking_water=yes tag.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC - More sensible values for fountain=*

sent from a phone

> On 11 Oct 2022, at 13:30, Davidoskky via Tagging  
> wrote:
> 
> If I have a fountain that is not decorative, doesn't have a tap and doesn't 
> provide drinking water, this fountain cannot be tagged.

why are you sure it is a fountain? And what has it to do with it having a tap? 
if it isn’t a tap it will not help if it had one.

What is the purpose of the fountain? What is the definition of “decorative”?

If this is still about laundry sinks, I suggest to not see them as fountains.

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

Re: [Tagging] advices about multiple values have inaccuracies , between several pages




Oct 11, 2022, 14:17 by marc_m...@mailo.com:

> Hello,
>
> I find that advices about multiple values have inaccuracies
> between several pages :
>
> https://wiki.openstreetmap.org/wiki/Any_tags_you_like#Syntactic_conventions_for_new_values
> Properties can have a large number of possible values
> my reading : key=yes/no value aren't a propertie, it's the value for another 
> key (for ex asia=yes/no is not a good idea, it's a value for cuisine=asia
>
that refers to various values across different objects, see examples given
(width, name), and is not referring to many values in a given object

though https://taginfo.openstreetmap.org/keys/crossing%3Aisland
is still a property

> 1) never use multiple values in a main key, no tool manages it and it is not 
> a good idea to describe an object with multiple "features
>
there are some tools supporting this

tagging object with two different actually applying features without
;-delimited tags is more likely to work

> 2) Properties can have a large number of possible values
> key with only =yes/no value aren't a propertie, it's the value
> for another key
>
both are properties, ATYL page is just confusing and should be fixed

I added "or can have short list of valid values" there
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC - More sensible values for fountain=*

sent from a phone

> On 11 Oct 2022, at 13:30, Davidoskky via Tagging  
> wrote:
> 
> How would you tag this fountain I photographed the other day?
> 
> The water is not potable, the stream of water cannot be interrupted and 
> definitely is not a decorative fountain.
> 
> https://commons.wikimedia.org/wiki/File:Water_fountain_without_tap_near_Santiago_de_Compostela.jpg

it is a historic fountain that IMHO clearly is decorative, that stuff in the 
background doesn’t seem to be there by incident. Maybe it is also a historic 
watering place (seems small for this)? Not knowing the context I cannot tell 
you for sure what it is. amenity=fountain doesn’t seem off. Many “decorative” 
fountains also had utility.

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

Re: [Tagging] advices about multiple values have inaccuracies , between several pages


Le 11.10.22 à 14:31, Mateusz Konieczny via Tagging a écrit :
though https://taginfo.openstreetmap.org/keys/crossing%3Aisland 
is still a property


To caricature your example:
red=yes/no is a technically property
this is not a good idea though,
the hidden characteristic is color and the value is red


1) never use multiple values in a main key, no tool manages it and
it is not a good idea to describe an object with multiple "features

there are some tools supporting this


witch one for ex ?


2) Properties can have a large number of possible values
key with only =yes/no value aren't a propertie, it's the value
for another key

both are properties, ATYL page is just confusing and should be fixed

I added "or can have short list of valid values" there


I find it very strange to reverse the meaning of a sentence on the wiki 
to promote your vision when I have just opened the discussion

it's unfair

Regards,
Marc



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

[Tagging] RFC: Proposed features/Deprecate man made=drinking fountain

I created
https://wiki.openstreetmap.org/wiki/Proposed_features/Deprecate_man_made%3Ddrinking_fountain#Examples

I believe there is consensus to deprecate, but it is not unaminous
so I created a proposal to confirm consensus.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC: Proposed features/Deprecate man made=drinking fountain


Hello,

Le 11.10.22 à 14:46, Mateusz Konieczny via Tagging a écrit :
https://wiki.openstreetmap.org/wiki/Proposed_features/Deprecate_man_made%3Ddrinking_fountain#Examples 


I fully approve, especially the fact that it does not approve of the mix 
of other tags but only solves the issue with this overlapping tag


Regards,
Marc



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

[Tagging] Feature Proposal - RFC - Historic


Hello.

I’m proposing to approve the historic=* key together with a number of tags:

https://wiki.openstreetmap.org/wiki/Proposed_features/Historic

historic=* is in widespread use and currently documented as de facto.

Please comment wherever you feel most comfortable:
- Here
- On the wiki talk page
- In the forum

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

[Tagging] Proposal - RFC - Use model to describe fountains


Use model=* to describe fountains

https://wiki.openstreetmap.org/wiki/Use_Model_To_Describe_fountains_proposal

Please discuss this proposal on its Wiki Talk page.

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

Re: [Tagging] advices about multiple values have inaccuracies , between several pages




Oct 11, 2022, 14:44 by marc_m...@mailo.com:

> Le 11.10.22 à 14:31, Mateusz Konieczny via Tagging a écrit :
>
>> though https://taginfo.openstreetmap.org/keys/crossing%3Aisland is still a 
>> property
>>
>
> To caricature your example:
> red=yes/no is a technically property
> this is not a good idea though,
> the hidden characteristic is color and the value is red
>
well, yes. Tagging red=yes would be tagging property
(this would be a poor tagging scheme and boolean key is not fitting well here,
but it would be tagging property of feature rather than being main key)

>> 1) never use multiple values in a main key, no tool manages it and
>>  it is not a good idea to describe an object with multiple "features
>>
>> there are some tools supporting this
>>
>
> witch one for ex ?
>
someone mentioned some Mapbox rendering
but in general, anyone can write tool processing OSM data so
claims like "no tool exists using XYZ" are easy to change

>> 2) Properties can have a large number of possible values
>>  key with only =yes/no value aren't a propertie, it's the value
>>  for another key
>>
>> both are properties, ATYL page is just confusing and should be fixed
>>
>> I added "or can have short list of valid values" there
>>
>
> I find it very strange to reverse the meaning of a sentence on the wiki to 
> promote your vision when I have just opened the discussion
> it's unfair
>
it was quite obviously wrong/incomplete

it was giving following options for all tags

- tag is property with many values (like width=*)
- tag is main key (like highway=motorway)

It was in effect claiming that properties with small number of values
are not existing which is not true, there are many limited to yes/no values.

if anyone disagrees with this edit - feel free to revert it

I did it because I know from my experience that otherwise typical
outcome is long discussion and nothing being changed on wiki.
My request to people in general: after discussion ends, please
make update at OSM Wiki - either to describe consensus or
to describe that something is unclear, in both cases ideally
with link to the discussion.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Proposal - RFC - Use model to describe fountains

again: it seems to be tagging style, not specific model

what happens when Rome start using new model of fountain in a given style?

but in general I support this idea, just key seems wrong.

Oct 11, 2022, 15:17 by tagging@openstreetmap.org:

> Use model=* to describe fountains
>
> https://wiki.openstreetmap.org/wiki/Use_Model_To_Describe_fountains_proposal
>
> Please discuss this proposal on its Wiki Talk page.
>
> ___
> 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 - Historic

I see no value in approving de facto key.

Maybe there would be value in deapproving historic=battlefield

Also, is "are of historic interest" mismatches how
historic=wayside_shrine
historic=memorial
many historic=wayside_cross
are used.

Oct 11, 2022, 15:15 by martianfreeloa...@posteo.net:

> Hello.
>
> I’m proposing to approve the historic=* key together with a number of tags:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Historic
>
> historic=* is in widespread use and currently documented as de facto.
>
> Please comment wherever you feel most comfortable:
> - Here
> - On the wiki talk page
> - In the forum
>
> ___
> 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 - Historic


Thanks. Do you see a problem with approving a de facto key?



On 11/10/2022 15:25, Mateusz Konieczny via Tagging wrote:

I see no value in approving de facto key.

Maybe there would be value in deapproving historic=battlefield

Also, is "are of historic interest" mismatches how
historic=wayside_shrine
historic=memorial
many historic=wayside_cross
are used.

Oct 11, 2022, 15:15 by martianfreeloa...@posteo.net:

Hello.

I’m proposing to approve the historic=* key together with a number
of tags:

https://wiki.openstreetmap.org/wiki/Proposed_features/Historic

historic=* is in widespread use and currently documented as de facto.

Please comment wherever you feel most comfortable:
- Here
- On the wiki talk page
- In the forum

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





On 11/10/2022 15:25, Mateusz Konieczny via Tagging wrote:


Maybe there would be value in deapproving historic=battlefield

This is not in the scope of this proposal. Feel free to start a proposal 
do deapprove battlefield.


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

Re: [Tagging] Feature Proposal - RFC - Historic





On 11/10/2022 15:25, Mateusz Konieczny via Tagging wrote:


Also, is "are of historic interest" mismatches how
historic=wayside_shrine
historic=memorial
many historic=wayside_cross
are used.


Do you have a suggestion how to fix this?

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

Re: [Tagging] Proposal - RFC - Use model to describe fountains




On 11/10/22 15:22, Mateusz Konieczny via Tagging wrote:

what happens when Rome start using new model of fountain in a given style?


You would tag that as a new model.

Style has many problems, because you could very well tag baroque 
fountains as a style or baroque fountains made by this particular artist 
between 1924 and 1926 as a style.


Model is easier to define, and as far as I've seen if they develop a new 
model of fountains, those have a new style.




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

Re: [Tagging] Proposal - RFC - Use model to describe fountains


On 11/10/22 15:22, Mateusz Konieczny via Tagging wrote:

but in general I support this idea, just key seems wrong.


If you can advise better keys, please do that in the wiki discussion 
page so that good ideas are documented there and not lost in the mailing 
list.


It might be good to have such ideas if this proposal turns out not to be 
good enough.



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

Re: [Tagging] Feature Proposal - RFC - Historic


Le 11.10.22 à 15:25, Mateusz Konieczny via Tagging a écrit :

I see no value in approving de facto key.

Maybe there would be value in deapproving historic=battlefield

Also, is "are of historic interest" mismatches how
historic=wayside_shrine
historic=memorial
many historic=wayside_cross
are used.


so the value to approved a facto key is "don't approve
those problematic keys"

but imho a memorial "are of historic interest" for sure !



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

[Tagging] Proposal - RFC - parking:position

2022-10-11 Thread Alex


|Hello list,|

|I would like to simplify the tagging of parking lane positions (e.g. 
"on street" or "on kerb"). We have an established tagging for parking 
lanes (parking:lane=*), which allows to map the orientation and position 
of parked vehicles on the road. The proposal aims to change the position 
tagging by using the key "parking:lane::position" instead of the 
current ||unnecessarily complicated notation 
"parking:lane::. This could be a next step to further 
improve the existing parking:lane scheme and make it more applicable.

|

|In addition, for separately mapped street parking areas 
(amenity=parking + parking=street_side/lane), an equivalent tagging for 
the position of the parking area is proposed (parking:position=*).

|

|See the proposal here: 
https://wiki.openstreetmap.org/wiki/Proposed_features/parking:position

|

|Please discuss this proposal on its Wiki Talk page.|

|Best, Alex
|
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Historic

2022-10-11 Thread Anne-Karoline Distel


Obviously, I support this. It has its own preset scheme in the iD
editor, its own icons etc.

The following are missing (of the top of my head, because I proposed
them) from the list and were approved already:

creamery 

ogham stone 

Anne
On 11/10/2022 14:15, martianfreeloader wrote:

Hello.

I’m proposing to approve the historic=* key together with a number of
tags:

https://wiki.openstreetmap.org/wiki/Proposed_features/Historic

historic=* is in widespread use and currently documented as de facto.

Please comment wherever you feel most comfortable:
- Here
- On the wiki talk page
- In the forum

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


Thanks. I've just added ogham stone to the "already approved" list.

On 11/10/2022 15:54, Anne-Karoline Distel wrote:
Obviously, I support this. It has its own preset scheme in the iD 
editor, its own icons etc.


The following are missing (of the top of my head, because I proposed 
them) from the list and were approved already:


creamery 

ogham stone 

Anne
On 11/10/2022 14:15, martianfreeloader wrote:

Hello.

I’m proposing to approve the historic=* key together with a number of 
tags:


https://wiki.openstreetmap.org/wiki/Proposed_features/Historic

historic=* is in widespread use and currently documented as de facto.

Please comment wherever you feel most comfortable:
- Here
- On the wiki talk page
- In the forum

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

2022-10-11 Thread Peter Neale via Tagging

IMHO "historic" should not be a primary key at all.  Many ruins and memorials 
are "of historic interest" it is true, but that could be tagged as a property 
("historic=yes") of the object "man_made=" .
What about a modern memorial?  Can that be "of historic interest", if it is 
only 2 years old?  it might still be of interest in 100 years time, but it 
might be forgotten by then.
What about a house?  Mine (built in 2000) is almost certainly NOT "of historic 
interest", but what about older houses, still occupied as residences, which 
were previously occupied by some famous person?  They probably ARE "of historic 
initerest", but they are still a  "building=house".
However, I fear that the (mis) use of "historic=" is so endemic that I am 
 pi**ing into the wind  if I try to change it.
Regards,Peter
(PeterPan99) 

On Tuesday, 11 October 2022 at 14:43:09 BST, Marc_marc 
 wrote:  

 Le 11.10.22 à 15:25, Mateusz Konieczny via Tagging a écrit :
> I see no value in approving de facto key.
> 
> Maybe there would be value in deapproving historic=battlefield
> 
> Also, is "are of historic interest" mismatches how
> historic=wayside_shrine
> historic=memorial
> many historic=wayside_cross
> are used.

so the value to approved a facto key is "don't approve
those problematic keys"

but imho a memorial "are of historic interest" for sure !

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




Oct 11, 2022, 15:39 by marc_m...@mailo.com:

> Le 11.10.22 à 15:25, Mateusz Konieczny via Tagging a écrit :
>
>> I see no value in approving de facto key.
>>
>> Maybe there would be value in deapproving historic=battlefield
>>
>> Also, is "are of historic interest" mismatches how
>> historic=wayside_shrine
>> historic=memorial
>> many historic=wayside_cross
>> are used.
>>
>
> so the value to approved a facto key is "don't approve
> those problematic keys"
>
> but imho a memorial "are of historic interest" for sure !
>
many, but not all

for example my city has political memorial  (not that I disagree with politics 
here)
dedicated to victims of notoriously poor air quality

I have seen public memorials that someone setup as memorial to
some person or even their pet
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Historic




Oct 11, 2022, 15:31 by martianfreeloa...@posteo.net:

>
>
> On 11/10/2022 15:25, Mateusz Konieczny via Tagging wrote:
>
>> Also, is "are of historic interest" mismatches how
>> historic=wayside_shrine
>> historic=memorial
>> many historic=wayside_cross
>> are used.
>>
>
> Do you have a suggestion how to fix this?
>
1)
not really

I pushed for man_made=cross at some point and it kind of worked,
one may try man_made=wayside_shrine or man_made=shrine or
similar but it may be too late for them

2)
do not attempt to have nice definition for all keys (see amenity=prison,
landuse=grass or other from
https://wiki.openstreetmap.org/wiki/Counterintuitive_keys_and_values )
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Historic

No, as long as meaning is not being changed.

Oct 11, 2022, 15:29 by martianfreeloa...@posteo.net:

> Thanks. Do you see a problem with approving a de facto key?
>
>
>
> On 11/10/2022 15:25, Mateusz Konieczny via Tagging wrote:
>
>> I see no value in approving de facto key.
>>
>> Maybe there would be value in deapproving historic=battlefield
>>
>> Also, is "are of historic interest" mismatches how
>> historic=wayside_shrine
>> historic=memorial
>> many historic=wayside_cross
>> are used.
>>
>> Oct 11, 2022, 15:15 by martianfreeloa...@posteo.net:
>>
>>  Hello.
>>
>>  I’m proposing to approve the historic=* key together with a number
>>  of tags:
>>
>>  https://wiki.openstreetmap.org/wiki/Proposed_features/Historic
>>
>>  historic=* is in widespread use and currently documented as de facto.
>>
>>  Please comment wherever you feel most comfortable:
>>  - Here
>>  - On the wiki talk page
>>  - In the forum
>>
>>  ___
>>  Tagging mailing list
>>  Tagging@openstreetmap.org
>>  https://lists.openstreetmap.org/listinfo/tagging
>>
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

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

Re: [Tagging] Feature Proposal - RFC - Historic

2022-10-11 Thread Andy Townsend


On 11/10/2022 14:54, Anne-Karoline Distel wrote:


Obviously, I support this. It has its own preset scheme in the iD 
editor, its own icons etc.


The following are missing (of the top of my head, because I proposed 
them) from the list and were approved already:


creamery 

ogham stone 



Anne



I suspect that most editors' preset schemes aren't driven entirely by 
what tags are "approved" and what aren't.  iD has historically used 
previous usage, so for example values suggested for the key "building" 
match https://taginfo.openstreetmap.org/keys/building#values .  JOSM 
uses a different list of curated values, but defaults to what the 
current mapper has used most recently.


For a new "historic" node, JOSM out of the box doesn't offer "creamery" 
or "ogham_stone", and it wouldn't really make sense for it to do so, 
since there are relatively few of either (even unmapped) around the 
world compared to the other historical suggestions already on JOSM's list.


Best Regards,

Andy


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

[Tagging] Feature Proposal - Rejected - Refine departures board tagging

2022-10-11 Thread Dimitar

I'm withdrawing the proposal from voting due to some mistakes that need 
fixing and the apparent need of more discussion on some points.


On 10/10/2022 20:58, Dimitar wrote:
|Voting has started for Refine departures board tagging. 
https://wiki.openstreetmap.org/wiki/Proposed_features/Refine_departures_board_tagging| 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Historic

2022-10-11 Thread Casper Kersten

As I mentioned on the community forum, the historic=* key is full of tags
that should really need to be revisited, changed or redefined before they
can be voted on. I strongly advise against approving all historic=* tags en
masse.

Elaboration on the community forum:
https://community.openstreetmap.org/t/feature-proposal-rfc-historic/3910

Op di 11 okt. 2022 om 16:23 schreef Andy Townsend :

> On 11/10/2022 14:54, Anne-Karoline Distel wrote:
>
> Obviously, I support this. It has its own preset scheme in the iD editor,
> its own icons etc.
>
> The following are missing (of the top of my head, because I proposed them)
> from the list and were approved already:
>
> creamery 
>
> ogham stone
> 
> Anne
>
>
> I suspect that most editors' preset schemes aren't driven entirely by what
> tags are "approved" and what aren't.  iD has historically used previous
> usage, so for example values suggested for the key "building" match
> https://taginfo.openstreetmap.org/keys/building#values .  JOSM uses a
> different list of curated values, but defaults to what the current mapper
> has used most recently.
>
> For a new "historic" node, JOSM out of the box doesn't offer "creamery" or
> "ogham_stone", and it wouldn't really make sense for it to do so, since
> there are relatively few of either (even unmapped) around the world
> compared to the other historical suggestions already on JOSM's list.
>
> Best Regards,
>
> Andy
>
>
>
> ___
> 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 - Historic


Le 11.10.22 à 16:01, Peter Neale via Tagging a écrit :
Many ruins and memorials are "of historic interest" it is true, but that 
could be tagged as a property ("historic=yes") of the object 
"man_made=" .


witch main tag for aa ruins with historic interest ?
it's not a building=* anymore

and for a historic=archaeological_site ?

but I agree that several values don't add any information
historic=building on building=* is the same as historic=yes



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

Re: [Tagging] Feature Proposal - RFC - Historic


Le 11.10.22 à 16:16, Mateusz Konieczny via Tagging a écrit :

do not attempt to have nice definition for all keys
https://wiki.openstreetmap.org/wiki/Counterintuitive_keys_and_values 



I find the advice very strange
on the contrary let's try to have a nice definition for all keys and
not approve new counter-intuitive keys, even if the museum of horrors 
has its wiki page




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

Re: [Tagging] camp sites in Haiti

> Would it be possible to re-tag those refugee camps in an automated edit?
… I'm not even sure if they all still exist 12 years later.

It would not be possible, because we do not know if they still exist.

However a local mapper or someone who has visited the area could re-tag
them, after confirming that they still exist and are in fact refugee sites

-Joseph Eisenberg

On Tue, Oct 11, 2022 at 4:20 AM Anne-Karoline Distel 
wrote:

> Hello,
>
> I noticed that many of the refugee camps in Haiti are tagged as
> tourism=camp_site which made me uneasy. Turns out there is the tag
> amenity=refugee_site. Would it be possible to re-tag those refugee camps
> in an automated edit? There are about 60 or 70 mapped. I'm not even sure
> if they all still exist 12 years later.
>
> Anne
>
>
> ___
> 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 - Historic

I've reduced the proposal to the historic=* key itself. No values 
included anymore.


On 11/10/2022 17:03, Marc_marc wrote:

Le 11.10.22 à 16:01, Peter Neale via Tagging a écrit :
Many ruins and memorials are "of historic interest" it is true, but 
that could be tagged as a property ("historic=yes") of the object 
"man_made=" .


witch main tag for aa ruins with historic interest ?
it's not a building=* anymore

and for a historic=archaeological_site ?

but I agree that several values don't add any information
historic=building on building=* is the same as historic=yes



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

2022-10-11 Thread Simon Poole

I would propose that it might be a good idea to reduce the number of 
inflight proposals per person to one.


As it is there is a flood of proposals that only the most diehard 
tagging proposal commenters can and will take the time to look at and 
consider with all the negative consequences that has.


Simon

Am 11.10.2022 um 15:15 schrieb martianfreeloader:

Hello.

I’m proposing to approve the historic=* key together with a number of 
tags:


https://wiki.openstreetmap.org/wiki/Proposed_features/Historic

historic=* is in widespread use and currently documented as de facto.

Please comment wherever you feel most comfortable:
- Here
- On the wiki talk page
- In the forum

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


OpenPGP_signature
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Historic


Yeah, sorry.

I'm doing this out of courtesy for B-unicycling.

They had started the Crannog proposal: 
https://wiki.openstreetmap.org/wiki/Proposed_features/crannog


Nobody commented during RFC and then everybody voted against; which is 
not nice. I was one of them.


I'm happy to hand over the historic proposal to maintained by someone 
else! Anyone interested?






On 11/10/2022 17:16, Simon Poole wrote:
I would propose that it might be a good idea to reduce the number of 
inflight proposals per person to one.


As it is there is a flood of proposals that only the most diehard 
tagging proposal commenters can and will take the time to look at and 
consider with all the negative consequences that has.


Simon

Am 11.10.2022 um 15:15 schrieb martianfreeloader:

Hello.

I’m proposing to approve the historic=* key together with a number of 
tags:


https://wiki.openstreetmap.org/wiki/Proposed_features/Historic

historic=* is in widespread use and currently documented as de facto.

Please comment wherever you feel most comfortable:
- Here
- On the wiki talk page
- In the forum

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

2022-10-11 Thread Peter Elderson

Keeping the status as de facto, avoids confusion about approval status of the 
values.
I think it's best to pick another battle.

Peter Elderson

> Op 11 okt. 2022 om 17:14 heeft martianfreeloader 
>  het volgende geschreven:
> 
> I've reduced the proposal to the historic=* key itself. No values included 
> anymore.
> 
>> On 11/10/2022 17:03, Marc_marc wrote:
>>> Le 11.10.22 à 16:01, Peter Neale via Tagging a écrit :
>>> Many ruins and memorials are "of historic interest" it is true, but that 
>>> could be tagged as a property ("historic=yes") of the object 
>>> "man_made=" .
>> witch main tag for aa ruins with historic interest ?
>> it's not a building=* anymore
>> and for a historic=archaeological_site ?
>> but I agree that several values don't add any information
>> historic=building on building=* is the same as historic=yes
>> ___
>> 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 - Historic

2022-10-11 Thread Brian M. Sperlongano

I appreciate the effort here, but I think it's too broad.  I would rather
have a more focused look at individual keys that considers what the tagging
alternatives are to each, and to assess whether there is duplication and/or
debates surrounding them that are worth investigating.  There is really no
profound need to "approve" the historic key as a whole.

On Tue, Oct 11, 2022 at 9:18 AM martianfreeloader <
martianfreeloa...@posteo.net> wrote:

> Hello.
>
> I’m proposing to approve the historic=* key together with a number of tags:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Historic
>
> historic=* is in widespread use and currently documented as de facto.
>
> Please comment wherever you feel most comfortable:
> - Here
> - On the wiki talk page
> - In the forum
>
> ___
> 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 - Historic




Oct 11, 2022, 17:05 by marc_m...@mailo.com:

> Le 11.10.22 à 16:16, Mateusz Konieczny via Tagging a écrit :
>
>> do not attempt to have nice definition for all keys
>>
> https://wiki.openstreetmap.org/wiki/Counterintuitive_keys_and_values 
>
> I find the advice very strange
> on the contrary let's try to have a nice definition for all keys and
> not approve new counter-intuitive keys, even if the museum of horrors has its 
> wiki page
>
I entirely agree! But trying to deprecate/redefine tags used millions of times
is not worth doing just to have a shorter description on key page on OSM Wiki.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Lyft and nameless sectioning in OSM

Lyft has been adding thousands of Polygons around Houston for Retail and
Residential and Industrial Areas. I'm just wondering what the motivation
here is for Lyft's behavior, especially in Texas. It seems like a lot of
bloat on OSM. IMHO, these polygons don't add any value: they're not
describing  what things are, and they're frequently incorrect. Houston
doesn't have zoning: stating what something is today as if it was a zone is
problematic anywhere (as at best it's only ever administrative where there
is zoning) but even more so in Houston where with enough money you can buy
the property and put an industrial plant there (assuming the property has
no bylaws). Sure that's just routine maintenance but what is the value with
that maintenance?

If we know what every individual building is (which is the ideal), what
information is conveyed by telling me that 80% or some unquantified
inexplicit percentage of buildings in a grouping are of type Industrial?

And a lot of these polygons cover _only_ one property. Which it seems isn't
permitted by the wiki, but that also doesn't add any utility over the
building itself.

Some examples of these nameless sections are,

* w1101484647 by A_Prokopova_lyft

Across the street from that one is three identical polygons by Emey_lyft in
the same place

* w1101205150
* w1101204670
* w1101392713

In case you think that's unique, right below it Emey_lyft did it again with
three identical polygons.

* w1101205149
* w1101204669
* w1101392712

I'm assuming the triplicating is an innocent mistake, and not an attempt to
inflate a quota. But, I just want to understand what is the use case for
highlighting *everything on the border of every major highway and primary
road* with "Retail Area" even without triplicating.

Moreover, with polygons like w1096234140, how is that useful when you lump
in one motel and three buildings which OSM has *no information about* as a
"Commercial Area"? Likewise, how is w1096234140 a "Retail Area" it covers
12 buildings and we only know one is a Post Office, the other is a Dunken
Donuts, and "Houston Skate and Dance" exists somewhere inside it?

None of this is relevant to any areas WITH names: I'm all for these. IE,
"Braeswood Squre", or "Meyer Park". Those "Areas" have a name which is
useful to the community and the sign is visible for the retail campus, but
seems most of Lyft's contributions are nameless (all of the ones I've seen)
.They seem to be outsourcing what could otherwise be done more correctly
with better data, automatically: if we know what each business is inside
the polygon, we can create effective "Areas" using spatial clustering.

Should we better define when these areas should be used and not used? Can
Lyft tell us what the business case is for funding these contributions to
OSM? How are they used to create value to our users?

(This is not a call out, and I want no part of any corrective action on the
two people mentioned. I'm only looking to provide concrete examples so we
can better draft policy.)

-- 
In the event this email pertains to Real Estate, Texas law

requires all license holders provide to prospective clients the following
forms: Information About Brokerage Services
, Consumer Protection
Notice
.
My TREC
license number is 610570

and my sponsoring broker is NB Elite Realty LLC.

--
Evan Carroll - m...@evancarroll.com
System Lord of the Internets
web: http://www.evancarroll.com
ph: 281.901.0011 <+1-281-901-0011>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Lyft and nameless sectioning in OSM

2022-10-11 Thread Andy Townsend


On 11/10/2022 19:34, Evan Carroll wrote:


Some examples of these nameless sections are,

* w1101484647 by A_Prokopova_lyft

That was added in https://www.openstreetmap.org/changeset/127101982 , 
which was that user's first edit in OSM.


I'd suggest asking them in the changeset about that edit, including 
where they got the data from.  I'd also be perfectly reasonable to ask 
them what the "proprietary sources" were that they used, and why 
https://www.openstreetmap.org/way/1101484647 doesn't include the vet's 
to the west, for example.


Best Regards,

Andy




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

Re: [Tagging] Lyft and nameless sectioning in OSM

For the purposes of steering the convo, I think a better question as it
relates to this list is the more general:

* If there is one Commercial Building in an unnamed Commercial Zone: what
value is there for a user?
* If there are two Commercial Buildings in an unnamed Commercial Zone: what
value is there for a user?
* If there are 20 Commercial Buildings in an unnamed Commercial Zone: what
value is there for a user?

For all of these cases, when "Zone" isn't established by law I see no
value. I think this would be a good place to start. But I'm also interested
in knowing Lyft's motivations behinds these Zones and I assume they're on
the list or someone can answer for it. If unnamed, this seems like a more
error-prone way to do Spatial Clustering, and clustering is usually done
for a reason, which I don't see in the wiki (unless I'm missing something).

-- 
In the event this email pertains to Real Estate, Texas law

requires all license holders provide to prospective clients the following
forms: Information About Brokerage Services
, Consumer Protection
Notice
.
My TREC
license number is 610570

and my sponsoring broker is NB Elite Realty LLC.

--
Evan Carroll - m...@evancarroll.com
System Lord of the Internets
web: http://www.evancarroll.com
ph: 281.901.0011 <+1-281-901-0011>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - Payment denominations

2022-10-11 Thread Mark Wagner

On Sun, 9 Oct 2022 17:08:46 -0700
stevea  wrote:

> At least in the USA, using currency (required to be accepted) isn't
> like barter (doesn't have to be accepted):  we even have a notation
> on each and every "Federal Reserve Note" (the debt instruments used
> in the USA as paper currency, often called "cash") which states:
> "This note is legal tender, for all debts, public and private."

There's a subtle point you're glossing over here: that wording only
applies to *debts*.

What counts as a debt has a fair bit of grey area.  Paying off a loan?
Indisputably a debt, they're required to take it.  Purchasing a soda
from a vending machine?  Indisputably not a debt, they can place
whatever restrictions they want.  In between is the fuzzy area.  For
example, is paying for your restaurant meal settling a debt?

-- 
Mark

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

Re: [Tagging] Lyft and nameless sectioning in OSM


Oct 11, 2022, 20:34 by m...@evancarroll.com:

> these polygons don't add any value: they're not describing  what things are, 
> and they're frequently incorrect
>
You mentioned https://www.openstreetmap.org/way/1101484647

Why it is supposed to be wrong? Are there additional objects not mapped in OSM 
there?
Because what I see seems self-consistent.

> Houston doesn't have zoning: stating what something is today as if it was a 
> zone is problematic anywhere
>
landuse=retail is not for legal zoning. For example farmland zoned for retail 
is not landuse=retail.

landuse=retail is exactly for area used right now predominantly for retail

and yes, many landuse=retail/residential/commercial/railway areas are not named

> If we know what every individual building is (which is the ideal), what 
> information is conveyed by telling me that 80% or some unquantified 
> inexplicit percentage of buildings in a grouping are of type Industrial?
>
Even if it is useless, this does not make this edits bad.

Can you explain why you think this specific object is invalid?
As far as I see it matches how landuse=retail is supposed to be used.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Lyft and nameless sectioning in OSM

2022-10-11 Thread Clifford Snow

On Tue, Oct 11, 2022 at 12:05 PM Evan Carroll  wrote:

>
> For all of these cases, when "Zone" isn't established by law I see no
> value. I think this would be a good place to start. But I'm also interested
> in knowing Lyft's motivations behinds these Zones and I assume they're on
> the list or someone can answer for it. If unnamed, this seems like a more
> error-prone way to do Spatial Clustering, and clustering is usually done
> for a reason, which I don't see in the wiki (unless I'm missing something).
>

Houston has hundreds of landuse polygons already.  According to the wiki
[1], landuse describes what area is being used for. It does not say
anywhere that we should map city zones. For example, landuse=farmland
describes an area used for farming where a county landuse zone might
include the buildings on the property, in OSM we usually don't.  Areas with
houses are tagged as landuse-residential. Houston has many of these areas.

[1]  https://wiki.openstreetmap.org/wiki/Land_use

As Andy suggested, contact the mapper with your concerns. I've have had
good luck dealing with Lyft in the past and appreciate their edits in my
area.

Best,
Clifford

-- 
@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] Lyft and nameless sectioning in OSM


I agree with Mateusz.

* landuse=retail,residential,industrial, etc. are not bound to the North 
American concept of zoning.


* landuse=retail does correctly not encompass the veterinarian, because 
a vet mostly sells services, not goods. It is thus correct that the vet 
is in a landuse=commercial area.


I'm not making a statement on whether Lyft's edit are accurate or useful 
in general.


---

On the matter of usefulness:

If usefulness would need to be proven for any edit, then 99% of my edits 
would lack legitimacy.


- I think it is totally fine to map for esthetic reasons, as long as the 
editing is correct and adheres to OSM guidelines.


- Also, in many cases, the future use of a data set cannot be foreseen 
in the present. Many things that are extremely useful today appeared 
completely useless at the time they were 
created/invented/studied/discovered.



On 11/10/2022 21:13, Mateusz Konieczny via Tagging wrote:


Oct 11, 2022, 20:34 by m...@evancarroll.com:

these polygons don't add any value: they're not describing  what
things are, and they're frequently incorrect

You mentioned https://www.openstreetmap.org/way/1101484647 



Why it is supposed to be wrong? Are there additional objects not mapped 
in OSM there?

Because what I see seems self-consistent.

Houston doesn't have zoning: stating what something is today as if
it was a zone is problematic anywhere

landuse=retail is not for legal zoning. For example farmland zoned for 
retail

is not landuse=retail.

landuse=retail is exactly for area used right now predominantly for retail

and yes, many landuse=retail/residential/commercial/railway areas are 
not named


If we know what every individual building is (which is the ideal),
what information is conveyed by telling me that 80% or some
unquantified inexplicit percentage of buildings in a grouping are of
type Industrial?

Even if it is useless, this does not make this edits bad.

Can you explain why you think this specific object is invalid?
As far as I see it matches how landuse=retail is supposed to be used.

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

>
> While building=carport would combine well with
> amenity=pickup_point,that obviously  doesn't work with amenity=parking.

I guess the reserved parking spots could be mapped as an area tagged
> with amenity=pickup_point on top of a larger area tagged with
> amenity=parking. How does that sound? I am open to other ideas.
>

On first glance, I don't like "point" because I think it's confusing
especially if we're talking about a way.

But, generally, I don't like the "amenity" thing because it forces
everything into one _type_. Which is impossible for the reasons here, so
I'm for breaking away from that at every opportunity. While I'm new to OSM,
I feel like a lot of others have the same opinion on it. For example,
amenity=ice_cream has been called "historic" and it's now suggested to use
to cuisine=ice_cream instead, because you can have more than one cuisine,
like an ice cream shop that serves bubble tea or makes chocolate (both of
which we have in Houston).

Another method is

* key:pickup=dedicated
* key:pickup=yes
* key:pickup=no

This would work for carports, and parking spots, as we've spoken about. But
I can think of other use cases here, like drive-through windows: this
McDonalds w526153446 takes payment at the first window and you pick up the
order at the second window. We could map these onto the building polygon
explicitly if you moved to use key instead of amenity:

The second window would be key:drive_through_window=yes,
key:pickup=dedicated
The first window would be key:drive_through_window, key:payment=yes.

This allows a uniform key:pickup everywhere like dive-through windows,
carports, and parking spaces. Just my 2c.

-- 
In the event this email pertains to Real Estate, Texas law

requires all license holders provide to prospective clients the following
forms: Information About Brokerage Services
, Consumer Protection
Notice
.
My TREC
license number is 610570

and my sponsoring broker is NB Elite Realty LLC.

--
Evan Carroll - m...@evancarroll.com
System Lord of the Internets
web: http://www.evancarroll.com
ph: 281.901.0011 <+1-281-901-0011>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Lyft and nameless sectioning in OSM

On Tue, Oct 11, 2022 at 2:17 PM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
> Oct 11, 2022, 20:34 by m...@evancarroll.com:
>
> these polygons don't add any value: they're not describing  what things
> are, and they're frequently incorrect
>
> You mentioned https://www.openstreetmap.org/way/1101484647
>
> Why it is supposed to be wrong? Are there additional objects not mapped in
> OSM there?
> Because what I see seems self-consistent.
>

 No value. There is no reason to call neighboring w1101484649 "Commercial
Zone". Why is a car wash and a vet commercial, and the gas station is
retail? And why is the polygon under it a different "Commercial Zone" it's
more retail then any of them.

But I mean the question isn't about the wrongness or rightness of any of
these, they can all be human mistakes. Humans make mistakes and can always
do something better.. I just don't see the value even if everything was
done right. If this continues, every major road in every major city will be
covered with a Commercial Zone or a Retail Zone. *If there is no name, what
is the value?*

-- 
In the event this email pertains to Real Estate, Texas law

requires all license holders provide to prospective clients the following
forms: Information About Brokerage Services
, Consumer Protection
Notice
.
My TREC
license number is 610570

and my sponsoring broker is NB Elite Realty LLC.

--
Evan Carroll - m...@evancarroll.com
System Lord of the Internets
web: http://www.evancarroll.com
ph: 281.901.0011 <+1-281-901-0011>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Lyft and nameless sectioning in OSM

Oct 11, 2022, 21:42 by m...@evancarroll.com:

> I just don't see the value even if everything was done right. 
>
That is simply utterly irrelevant. Even if you do not see value of mapping
area:highway=* or shops or detail of individual trees or opening hours
or bicycle parkings or landuse or glaciers or anything else, then it is still 
not
a valid reason to ask others to justify themself.

Also "but it is useful for XYZ" is not an automatic defence and is not
guaranteeing that data will be kept.

> If this continues, every major road in every major city will be covered with 
> a Commercial Zone or a Retail Zone. 
>
or industrial or residential

though some advocated mapping landuse=highway or not mapping landuse 
in road corridor of major roads

> If there is no name, what is the value?
>
1) value recognized by you is not necessary
2) may be useful for example for map rendering at city scale
And numerous data consumers use this data.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Lyft and nameless sectioning in OSM

That they exist isn't the question. I acknowledged this. It doesn't make
sense why they should. The reason farmland exists is,

* The presence of land alone is not mappable, IE., farmland unlike
Commercial and Retail Zones can not be inferred by buildings.
* Farmland gives you the ability to add name=*; barrier=*; crop=*, IE., it
carries other useful information. You need something to carry a tag.

* In the case of landuse=retail it can carry name=*; operator=* -- when it
does my objection is dropped entirely. In fact, you make OSM better by
putting polgyons together that say the name of the shopping centre you're
in. However, when there is no key on the zone what does the zone convey?
The wiki is entirely silent on this. It satisfied some highly subjective
mapping of 0 or more buildings which have an unspecified variable percent
of compliance with the landuse?
* In the case of landuse=retail it can be inferred and recreated with _more
precision_ automatically by the buildings it contains. That is to say, in
the best case when it's 100% correct, it's 100% redundant.

On Tue, Oct 11, 2022 at 2:30 PM Clifford Snow 
wrote:

>
>
> On Tue, Oct 11, 2022 at 12:05 PM Evan Carroll  wrote:
>
>>
>> For all of these cases, when "Zone" isn't established by law I see no
>> value. I think this would be a good place to start. But I'm also interested
>> in knowing Lyft's motivations behinds these Zones and I assume they're on
>> the list or someone can answer for it. If unnamed, this seems like a more
>> error-prone way to do Spatial Clustering, and clustering is usually done
>> for a reason, which I don't see in the wiki (unless I'm missing something).
>>
>
> Houston has hundreds of landuse polygons already.  According to the wiki
> [1], landuse describes what area is being used for. It does not say
> anywhere that we should map city zones. For example, landuse=farmland
> describes an area used for farming where a county landuse zone might
> include the buildings on the property, in OSM we usually don't.  Areas with
> houses are tagged as landuse-residential. Houston has many of these areas.
>
> [1]  https://wiki.openstreetmap.org/wiki/Land_use
>
> As Andy suggested, contact the mapper with your concerns. I've have had
> good luck dealing with Lyft in the past and appreciate their edits in my
> area.
>
> Best,
> Clifford
>
> --
> @osm_washington
> www.snowandsnow.us
> OpenStreetMap: Maps with a human touch
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

-- 
In the event this email pertains to Real Estate, Texas law

requires all license holders provide to prospective clients the following
forms: Information About Brokerage Services
, Consumer Protection
Notice
.
My TREC
license number is 610570

and my sponsoring broker is NB Elite Realty LLC.

--
Evan Carroll - m...@evancarroll.com
System Lord of the Internets
web: http://www.evancarroll.com
ph: 281.901.0011 <+1-281-901-0011>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Lyft and nameless sectioning in OSM


Oct 11, 2022, 21:28 by cliff...@snowandsnow.us:

> As Andy suggested, contact the mapper with your concerns. I've have had good 
> luck dealing with Lyft in the past and appreciate their edits in my area.
>

Though note that it appears that this Lyft mapping is 100% fine and done as 
expected.
I would also recommend linking this mailing list thread if you would be talking 
with them
about this mapping.

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

Re: [Tagging] Feature Proposal - Voting - Payment denominations

Right. According to the Federal Reserve:
https://www.federalreserve.gov/faqs/currency_12772.htm

"Is it legal for a business in the United States to refuse cash as a form
of payment?

"There is no federal statute mandating that a private business, a person,
or an organization must accept currency or coins as payment for goods or
services. Private businesses are free to develop their own policies on
whether to accept cash unless there is a state law that says otherwise."

This is discussed more generally in the article on "Legal Tender" -
https://en.wikipedia.org/wiki/Legal_tender

"Legal tender is a form of money that courts of law are required to
recognize as satisfactory payment for any monetary debt. Each jurisdiction
determines what is legal tender, but essentially it is anything which when
offered ("tendered") in payment of a debt extinguishes the debt. ... Some
jurisdictions allow contract law to overrule the status of legal tender,
allowing (for example) merchants to specify that they will not accept cash
payments.  The right, in many jurisdictions, of a trader to refuse to
do business with any person means that a would-be purchaser may not force a
purchase merely by presenting legal tender, as legal tender must only be
accepted for debts already incurred."

Also see this discussion about the USA legal situation:
https://www.expertlaw.com/library/consumer-protection/it-legal-refuse-cash-payment

- Joseph Eisenberg

On Tue, Oct 11, 2022 at 12:11 PM Mark Wagner  wrote:
>
> On Sun, 9 Oct 2022 17:08:46 -0700
> stevea  wrote:
>
> > At least in the USA, using currency (required to be accepted) isn't
> > like barter (doesn't have to be accepted):  we even have a notation
> > on each and every "Federal Reserve Note" (the debt instruments used
> > in the USA as paper currency, often called "cash") which states:
> > "This note is legal tender, for all debts, public and private."
>
> There's a subtle point you're glossing over here: that wording only
> applies to *debts*.
>
> What counts as a debt has a fair bit of grey area.  Paying off a loan?
> Indisputably a debt, they're required to take it.  Purchasing a soda
> from a vending machine?  Indisputably not a debt, they can place
> whatever restrictions they want.  In between is the fuzzy area.  For
> example, is paying for your restaurant meal settling a debt?
>
> --
> Mark
>
> ___
> 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] Lyft and nameless sectioning in OSM

" when there is no key on the zone what does the zone convey?"

It conveys that the area of land is primarily used for selling goods
(landuse=retail).

This is useful because retail areas, which include shops and restaurants,
are high-traffic destinations, which many map users will be interested in
visiting.

This is used by many database users to render the area differently, e.g.
openstreetmap-carto - Note that many commercial map services also highlight
retail areas in a different color.

Commercial land use is also likely to include businesses which are
sometimes destinations, so they are of greater interest to a general map
user than an area of residential land, industrial land, or farmland.

Database users can also eventually use this data to compare the amount of
land used for retail, industrial and residential land vs other uses, once
it is fully mapped.

On Tue, Oct 11, 2022 at 12:56 PM Evan Carroll  wrote:

> That they exist isn't the question. I acknowledged this. It doesn't make
> sense why they should. The reason farmland exists is,
>
> * The presence of land alone is not mappable, IE., farmland unlike
> Commercial and Retail Zones can not be inferred by buildings.
> * Farmland gives you the ability to add name=*; barrier=*; crop=*, IE., it
> carries other useful information. You need something to carry a tag.
>
> * In the case of landuse=retail it can carry name=*; operator=* -- when it
> does my objection is dropped entirely. In fact, you make OSM better by
> putting polgyons together that say the name of the shopping centre you're
> in. However, when there is no key on the zone what does the zone convey?
> The wiki is entirely silent on this. It satisfied some highly subjective
> mapping of 0 or more buildings which have an unspecified variable percent
> of compliance with the landuse?
> * In the case of landuse=retail it can be inferred and recreated with
> _more precision_ automatically by the buildings it contains. That is to
> say, in the best case when it's 100% correct, it's 100% redundant.
>
>
> On Tue, Oct 11, 2022 at 2:30 PM Clifford Snow 
> wrote:
>
>>
>>
>> On Tue, Oct 11, 2022 at 12:05 PM Evan Carroll  wrote:
>>
>>>
>>> For all of these cases, when "Zone" isn't established by law I see no
>>> value. I think this would be a good place to start. But I'm also interested
>>> in knowing Lyft's motivations behinds these Zones and I assume they're on
>>> the list or someone can answer for it. If unnamed, this seems like a more
>>> error-prone way to do Spatial Clustering, and clustering is usually done
>>> for a reason, which I don't see in the wiki (unless I'm missing something).
>>>
>>
>> Houston has hundreds of landuse polygons already.  According to the wiki
>> [1], landuse describes what area is being used for. It does not say
>> anywhere that we should map city zones. For example, landuse=farmland
>> describes an area used for farming where a county landuse zone might
>> include the buildings on the property, in OSM we usually don't.  Areas with
>> houses are tagged as landuse-residential. Houston has many of these areas.
>>
>> [1]  https://wiki.openstreetmap.org/wiki/Land_use
>>
>> As Andy suggested, contact the mapper with your concerns. I've have had
>> good luck dealing with Lyft in the past and appreciate their edits in my
>> area.
>>
>> Best,
>> Clifford
>>
>> --
>> @osm_washington
>> www.snowandsnow.us
>> OpenStreetMap: Maps with a human touch
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> --
> In the event this email pertains to Real Estate, Texas law
> 
> requires all license holders provide to prospective clients the following
> forms: Information About Brokerage Services
> , Consumer Protection
> Notice
> .
> My TREC license number is 610570
> 
> and my sponsoring broker is NB Elite Realty LLC.
>
> --
> Evan Carroll - m...@evancarroll.com
> System Lord of the Internets
> web: http://www.evancarroll.com
> ph: 281.901.0011 <+1-281-901-0011>
>
>
> ___
> 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] Lyft and nameless sectioning in OSM

>
> I just don't see the value even if everything was done right.
>
> That is simply utterly irrelevant. Even if you do not see value of mapping
> area:highway=* or shops or detail of individual trees or opening hours
> or bicycle parkings or landuse or glaciers or anything else, then it is
> still not
> a valid reason to ask others to justify themself.
>

Wait, why? What's wrong with asking what value is there in doing this? This
is supposed to be where the conversation starts: "[this list] is for tag
discussion, strategy and related tools." Is it strategic to have a Zone
which does not convey information or have value in OSM? Is this a place to
ask what value people are currently getting from these zones? While I value
your contributions on the wiki, I feel like you're talking past me: what
value is there in Commercial, Residential, and Industrial zones? To direct
quote what I said earlier,

* If there is one Commercial Building in an unnamed Commercial Zone: what
value is there for a user?
* If there are two Commercial Buildings in an unnamed Commercial Zone: what
value is there for a user?
* If there are 20 Commercial Buildings in an unnamed Commercial Zone: what
value is there for a user?

Likewise, if there are violations inside the zone and they're not
homogenous how does that affect the value?

> For example, a post office would have the landuse
=commercial
 tag, because
they offer a service, rather than a good. However, if the post office is in
a shopping centre with 8 other shops, this tag would be used.

So it's permitted to have a "Commercial" Post Office in a retail zone, and
it's permitted to make the zones infinitely small. So a retail zone may
include a neighboring post office, or you could voluntarily break the post
office off into a zone by itself? I just don't understand how people intend
to use these. But feel free to talk about _any_ of the ways listed in my OT
and tell me how they benefit OSM. I just want to know why they're valuable.

Likewise,

>  For "Mixed-Use" areas where more than half of the land is residential,
tag as residential.

How is knowing "more than half" of the land is residential useful to a user
when without the zone they would otherwise know _exactly_ what is
residential, commercial, and industrial.


-- 
In the event this email pertains to Real Estate, Texas law

requires all license holders provide to prospective clients the following
forms: Information About Brokerage Services
, Consumer Protection
Notice
.
My TREC
license number is 610570

and my sponsoring broker is NB Elite Realty LLC.

--
Evan Carroll - m...@evancarroll.com
System Lord of the Internets
web: http://www.evancarroll.com
ph: 281.901.0011 <+1-281-901-0011>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Lyft and nameless sectioning in OSM




Oct 11, 2022, 22:12 by m...@evancarroll.com:

>>> I just don't see the value even if everything was done right. 
>>>
>> That is simply utterly irrelevant. Even if you do not see value of mapping
>> area:highway=* or shops or detail of individual trees or opening hours
>> or bicycle parkings or landuse or glaciers or anything else, then it is 
>> still not
>> a valid reason to ask others to justify themself.
>>
>
> Wait, why? What's wrong with asking what value is there in doing this? 
>
to clarify: I meant that it is irrelevant as far as allowing mapping

Initial posting read like claim that Lyft mapper did something wrong or 
incorrectly
and they should not be doing this.

> * In the case of landuse=retail it can be inferred and recreated with 
> _more precision_ automatically by the buildings it contains. That is to say, 
> in the best case when it's 100% correct, it's 100% redundant.

I am not aware about such code. Can you share code capable of doing this
without human intervention and with reasonable cost?

In other words, this claim seems incorrect to me.

Also, it is rarity to find area where such data is fully mapped.

> what value is there in Commercial, Residential, and Industrial zones?

For displaying and analysing dominant land use.

> So a retail zone may include a neighboring post office, or you could 
> voluntarily break the post office off into a zone by itself?
>
Depends on their size and yes, partially on subjective local mapping practice.

Borderline cases end being sort-of-randomly but overall many people are 
interested
in distinction between residential and industrial and retail (and so on) areas.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Lyft and nameless sectioning in OSM

2022-10-11 Thread Tobias Knerr


On 11.10.22 21:51 Mateusz Konieczny wrote:

Oct 11, 2022, 21:42 by m...@evancarroll.com:

I just don't see the value even if everything was done right.

That is simply utterly irrelevant.


I disagree. People may not always agree about the relative usefulness of 
some types of data, but someone advocating for some data to be added to 
OSM should really be able to explain why they find it useful.


That's all I plan to say on this side remark because it's not really 
applicable to the main discussion: There are uses for polygons tagged as 
landuse=retail/commercial/..., after all, even though I consider their 
usefulness quite low now that mapping of individual buildings is common. 
They were more useful when these tags where originally invented. I also 
feel that these tags are not truly verifiable because the "predominant 
usage" definition allows considerable flexibility in drawing them.


Anyway, nameless landuse polygons have been around for over a decade. So 
while I'm sympathetic with mappers who aren't enthuiastic about their 
addition in an area where they were previously not mapped, it's hard to 
fault Lyft for following established tagging practices.


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

Re: [Tagging] Lyft and nameless sectioning in OSM

sent from a phone

> On 11 Oct 2022, at 21:45, Evan Carroll  wrote:
> 
> No value. There is no reason to call neighboring w1101484649 "Commercial 
> Zone". Why is a car wash and a vet commercial, and the gas station is retail?

this seems completely in line with what I would expect for “landuse” (current 
use of land).

Actually I do not believe “commercial zone” is a good description of 
landuse=commercial because it implies zoning (prescription, also planning i.e. 
permissible future landuse as opposed to de facto use of land) and because it 
implies a certain scale.

Cheers Martin 

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

Re: [Tagging] Lyft and nameless sectioning in OSM

sent from a phone

> On 11 Oct 2022, at 21:45, Evan Carroll  wrote:
> 
> If there is no name, what is the value?

it is a property that helps understanding how an area is structured. If there 
is a name you should use “place”

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

Re: [Tagging] Lyft and nameless sectioning in OSM

Thanks Joseph Eisenberg! That's exactly what I'm looking for. Good answer.
So basically the primary use case of an **unnamed** residential,
commercial, industrial, and retail "Zones" is not to convey (additional)
information but to serve as a good-enough styling solution about what the
zone conveys? As I suspected, it is solving a spatial clustering problem
manually to achieve a good-enough different visual style. I guess you can
see here in the landcover.

https://github.com/gravitystorm/openstreetmap-carto/blob/cae2309efd4ee0338fcdf9f201e92f20b338426c/style/landcover.mss#L16

The next question is can this be defined such that this can be automated?
It would seem to me like if we,

1. Take a bounding box.
2. From that, subtract out the landuse polygons for named zones, LEAVING
ONLY "unnamed zones, and land not in a zone."
3. From that, subtract out the landuse polygons for zones NOT of type
"common landuse key values - developed land", per the wiki
https://wiki.openstreetmap.org/wiki/Key:landuse LEAVING ONLY "unnamed zones
of developed land, and land not in a zone."
4. Subtract out by key:highway lines LEAVING ONLY "unnamed zones of
developed land and land not in a zone that does NOT intersect a highway."
5. Extract "unnamed zones of developed land and land not in a zone that
does NOT intersect a highway" into a zone set.
6. Infer from the contents of the polygon what type of developed land the
zone is.

This would allow us to be precise and objective and determine what kind of
"developed land" an unnamed zone was, as well as to provide a gauge of the
accuracy of the zone.

If this was done, do you think this would satisfy all use cases of unnamed
landuse zones for developed land like commercial, retail,
residential, educational?

(I said in the above "unnamed zone" for simplicity, and unnamed zone can
still have an operator, and in every case when I said unnamed zone, I meant
a zone without a name or an operator).

--
In the event this email pertains to Real Estate, Texas law

requires all license holders provide to prospective clients the following
forms: Information About Brokerage Services
, Consumer Protection
Notice
.
My TREC
license number is 610570

and my sponsoring broker is NB Elite Realty LLC.

--
Evan Carroll - m...@evancarroll.com
System Lord of the Internets
web: http://www.evancarroll.com
ph: 281.901.0011 <+1-281-901-0011>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Lyft and nameless sectioning in OSM

>
>
> I disagree. People may not always agree about the relative usefulness of
> some types of data, but someone advocating for some data to be added to
> OSM should really be able to explain why they find it useful.
>
> That's all I plan to say on this side remark because it's not really
> applicable to the main discussion: There are uses for polygons tagged as
> landuse=retail/commercial/..., after all, even though I consider their
> usefulness quite low now that mapping of individual buildings is common.
> They were more useful when these tags where originally invented. I also
> feel that these tags are not truly verifiable because the "predominant
> usage" definition allows considerable flexibility in drawing them.
>
> Anyway, nameless landuse polygons have been around for over a decade. So
> while I'm sympathetic with mappers who aren't enthuiastic about their
> addition in an area where they were previously not mapped, it's hard to
> fault Lyft for following established tagging practices.
>

This is also really well said, and we should not overlook that I'm new to
OSM and don't know of the time when buildings were not mapped. I see all
buildings mapped, and wonder why I need a container to tell me that all
things in it are that which it contains to some arbitrary subjective
precision. I can't imagine making a technology that would use this as-is. I
can imagine answering the problem differently, with a technical solution.
It sounds like your opinion is _they're less useful now then ever_. If so,
is the community hostile to deprecation? Is there no precedent for saying
"this is no longer useful" let's ditch it, or automate it.

For a potential technical solution, see my response to Joseph Eisenberg
below. Would that have value to OSM?


-- 
In the event this email pertains to Real Estate, Texas law

requires all license holders provide to prospective clients the following
forms: Information About Brokerage Services
, Consumer Protection
Notice
.
My TREC
license number is 610570

and my sponsoring broker is NB Elite Realty LLC.

--
Evan Carroll - m...@evancarroll.com
System Lord of the Internets
web: http://www.evancarroll.com
ph: 281.901.0011 <+1-281-901-0011>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - pickup


Le 11.10.22 à 21:33, Evan Carroll a écrit :

We could map these onto the building polygon explicitly


please : one element = one object
building <> the user of the building.
so imho it's best to have one object for the buildinng,
another for the shop or the pickup or whatever.
ex of issue : name on a object building+shop : it's the name
of the building or the name of the shop ?



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

Re: [Tagging] Lyft and nameless sectioning in OSM

Re: "not to convey (additional) information"

No, it is useful information.

A human who knows the local area can pretty easily determine which blocks
or streets are retail or industrial. This can be done even if you do not
know the exact names of the buildings or businesses - sometimes in an
industrial area, or a commercial area with offices, it might not be clear
the exact names of each business, if certain areas are not open to the
public. But you can often map the area just based on passing by on public
streets, and then looking at aerial imaging.

In a retail area, if every shop is mapped precisely then the landuse=retail
tag could possibly be inferred, in the same way that Google maps "area of
interest" - but looking at Google you can often see mistakes due to missing
or miscategorized shops and homes. Adding the landuse provides a different
level of information, which is not exactly the same as mapping each shop or
office.

Also, we do not map individual houses or apartments in any way other than
as part of a larger landuse=retail area, and as buildings. While
building=house can usually be inferred to be residential, this is not
always, true, there are many houses that have been converted into offices
for lawyers or dentists along busy streets, but these are still
appropriately mapped as building=house in many cases. So
landuse=residential is helpful to confirm that an area is predominantly
covered by residences and their gardens or yards and other related
features.

While I would agree that urban landuse mapping is not the most important
thing to add to Openstreetmap, it is still worth adding after buildings,
streets, shops and other amenities have been added, just as it is useful to
map the areas of farmland, farmyards, allotments, quarries and other areas,
both to allow maps to be rendered and to allow landcover to be analyzed.

In an area where all landcover has been mapped fairly accurately you can
make some interesting analysis of the use of urban, rural and semi-natural
lands.

- Joseph Eisenberg

On Tue, Oct 11, 2022 at 1:55 PM Evan Carroll  wrote:

> Thanks  Joseph Eisenberg! That's exactly what I'm looking for. Good
> answer. So basically the primary use case of an **unnamed** residential,
> commercial, industrial, and retail "Zones" is not to convey (additional)
> information but to serve as a good-enough styling solution about what the
> zone conveys? As I suspected, it is solving a spatial clustering problem
> manually to achieve a good-enough different visual style. I guess you can
> see here in the landcover.
>
>
> https://github.com/gravitystorm/openstreetmap-carto/blob/cae2309efd4ee0338fcdf9f201e92f20b338426c/style/landcover.mss#L16
>
> The next question is can this be defined such that this can be automated?
> It would seem to me like if we,
>
> 1. Take a bounding box.
> 2. From that, subtract out the landuse polygons for named zones, LEAVING
> ONLY "unnamed zones, and land not in a zone."
> 3. From that, subtract out the landuse polygons for zones NOT of type
> "common landuse key values - developed land", per the wiki
> https://wiki.openstreetmap.org/wiki/Key:landuse LEAVING ONLY "unnamed
> zones of developed land, and land not in a zone."
> 4. Subtract out by key:highway lines LEAVING ONLY "unnamed zones of
> developed land and land not in a zone that does NOT intersect a highway."
> 5. Extract "unnamed zones of developed land and land not in a zone that
> does NOT intersect a highway" into a zone set.
> 6. Infer from the contents of the polygon what type of developed land the
> zone is.
>
> This would allow us to be precise and objective and determine what kind of
> "developed land" an unnamed zone was, as well as to provide a gauge of the
> accuracy of the zone.
>
> If this was done, do you think this would satisfy all use cases of unnamed
> landuse zones for developed land like commercial, retail,
> residential, educational?
>
> (I said in the above "unnamed zone" for simplicity, and unnamed zone can
> still have an operator, and in every case when I said unnamed zone, I meant
> a zone without a name or an operator).
>
> --
> In the event this email pertains to Real Estate, Texas law
> 
> requires all license holders provide to prospective clients the following
> forms: Information About Brokerage Services
> , Consumer Protection
> Notice
> .
> My TREC license number is 610570
> 
> and my sponsoring broker is NB Elite Realty LLC.
>
> --
> Evan Carroll - m...@evancarroll.com
> System Lord of the Internets
> web: http://www.evancarroll.com
> ph: 281.901.0011 <+1-281-901-0011>
>
>
> ___
> Tagging mailing lis

Re: [Tagging] RFC - More sensible values for fountain=*

2022-10-11 Thread Minh Nguyen


Vào lúc 01:22 2022-10-11, Marc_marc đã viết:
the namespace isn't needed, it's just a bad pratice due to a missing 
feature in iD (another editor uses taginfo combinations to propose the 
most relevant values, iD on the other hand proposes everything often 
without filter, but as I said, it is not a reason to invent shop:brand 
or shop:name, it is a point which must be improved in iD and not by the 
abuse of namespace)


I wouldn't pin the blame on iD for the development of namespaces. The 
main reason iD uses some namespaced keys is because they're 
well-established, for example crossing:light. Another reason is to avoid 
homonymous keys [1] in some cases where the consequence is more severe 
than just some irrelevant suggestions in the taginfo-powered suggestion 
list.


The need to filter taginfo values has often helped to make a decision 
between two reasonable alternatives in the absence of some other 
deciding factor. But if iD were as contrarian as you describe, then it 
would insist on iteratively refining e.g. religion=christian with 
christian=* rather than presenting the user with an unfiltered 
denomination=* field to keep Buddhist denominations from showing up.


The idea of namespacing keys comes up all the time by mappers uninvolved 
with the iD project (see contact:*). The most salient one in my opinion 
is that sometimes the manufacturer or model only applies to part of a 
mapped feature, especially in the case of a dual-tagged feature. For 
example:


* man_made=flagpole is tagged with flag:name=* rather than name=* 
because the name of the flagpole, if there is one, would differ from the 
name of the flag flying on it.


* siren:model=* was probably coined because it emergency=siren is often 
dual-tagged on a man_made=utility_pole node, the pole having a different 
make and model than the siren.


* The recently approved crossing:markings proposal encourages the use of 
surface:colour=* as a less ambiguous alternative to colour=*.


These keys came from the database, or the wiki, but not originally from 
iD. In any case, there's a draft proposal to consolidate the various 
make and model-related keys. [2]


[1] https://wiki.openstreetmap.org/wiki/Homonymous_keys
[2] 
https://wiki.openstreetmap.org/wiki/Proposed_features/Manufacturer_and_Model


--
m...@nguyen.cincinnati.oh.us




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

Re: [Tagging] Feature Proposal - Voting - Payment denominations

2022-10-11 Thread Volker Schmidt

On Tue, 11 Oct 2022, 09:16 Martin Koppenhoefer, 
wrote:

> in Italy, one and two cent coins have been abolished, they are not
> accepted any more in shops, and while prices are still ending mostly with
> 9, the sum gets rounded.
>

OT for this discussion:  Where I live in Italy, one and two €cent coins are
certainly still in use.

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

Re: [Tagging] Lyft and nameless sectioning in OSM

2022-10-11 Thread Greg Troxel


You are  using "zone" and that confuses me, because in the US zone is
like zoning.

Are we talking about landuse, or regulations for what land can be used
for?

I think it's reasonable to draw landuse=retail if

  it's actually true

  it's named and the boundary is more or less the property lines that go
  with that name

or

  the retail polygon is in some sense maximal in that there are
  generally not adjacent retail areas that could be merged in


I draw such polygons fairly often, but I'm doing it for areas I'm
familiar with and manually, not as a semi-automated edit.And they
line up with parcels, or they cut off parts of them on purpose when I
can see "retail use" on one part, and "conservation use" on wetlands in
the back.


signature.asc
Description: PGP signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Lyft and nameless sectioning in OSM

2022-10-11 Thread Greg Troxel

Martin Koppenhoefer  writes:

> Actually I do not believe “commercial zone” is a good description of
> landuse=commercial because it implies zoning (prescription, also
> planning i.e. permissible future landuse as opposed to de facto use of
> land) and because it implies a certain scale.

I think we should stay away from zoning.  Around me, there can be a
landuse=retail within an area that is largely in fact
landuse=residential and is also zoned residential.   The magic words are
"pre-existing non-conforming use".

If people want to map zoning, that seems not normal in OSM and another
discussion, but please do not blur zoning into actual landuse.

signature.asc
Description: PGP signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Lyft and nameless sectioning in OSM

2022-10-11 Thread Greg Troxel

Andy Townsend  writes:

> I'd suggest asking them in the changeset about that edit, including
> where they got the data from.  I'd also be perfectly reasonable to ask
> them what the "proprietary sources" were that they used,

Agreed.  It would be more  than reasonable to ask them about the
proprietary source and licensing, and why they haven't  put up a wiki
page with an explanation, paid editing guidelines, if this is
effectively an import, etc.  Those aspects of this at first glance  seem
not ok, to the point where I would not be surprised  if DWG were
throwing a block to get the licensing issues clarified.

signature.asc
Description: PGP signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Lyft and nameless sectioning in OSM

2022-10-11 Thread Minh Nguyen


Vào lúc 14:06 2022-10-11, Evan Carroll đã viết:
This is also really well said, and we should not overlook that I'm new 
to OSM and don't know of the time when buildings were not mapped. I see 
all buildings mapped, and wonder why I need a container to tell me that 
all things in it are that which it contains to some arbitrary subjective 
precision. I can't imagine making a technology that would use this 
as-is. I can imagine answering the problem differently, with a technical 
solution. It sounds like your opinion is _they're less useful now then 
ever_. If so, is the community hostile to deprecation? Is there no 
precedent for saying "this is no longer useful" let's ditch it, or 
automate it.


If you find manually mapped, unnamed landuse=* areas to be superfluous, 
you'll just love abutters=*, a key that as of 2008 was just as common as 
landuse=*. It remains for when there isn't even enough available 
information to map a proper unnamed landuse=* area manually, let alone 
algorithmically.


Even where buildings have been thoroughly classified, lots of urban 
neighborhoods are dominated by apartment blocks with ground-floor retail 
along major thoroughfares. As the multi-landuse proposal was rejected 
[1], I suspect people are making different judgment calls based on what 
they perceive to be the more prominent of the two uses.


None of this is particularly relevant to Houston, but I don't think 
there's any precedent or mechanism for formally deprecating a broadly 
defined tag in only the places that satisfy certain criteria. Some local 
communities try to dissuade mappers from using certain tags or mapping 
addresses in a certain manner, but it doesn't involve proscribing a 
practice as well-known as unnamed landuse. The closest thing I can think 
of was the situation around population=* in China, now resolved. [2][3]


If, like me, you want to see fewer unnamed landuse areas in your 
backyard, map more named landuse areas corresponding to retail and 
residential developments. These areas not only reduce the pressure to 
"fill in" the map visually but also add information about the shape of 
these developments that's often difficult to obtain from other map services.


[1] https://wiki.openstreetmap.org/wiki/Proposed_features/Multiple_landuse
[2] https://lists.openstreetmap.org/pipermail/tagging/2021-May/061449.html
[3] https://wiki.openstreetmap.org/wiki/Proposed_features/china_population

--
m...@nguyen.cincinnati.oh.us




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

Re: [Tagging] Lyft and nameless sectioning in OSM

2022-10-11 Thread Shawn K. Quinn


On 10/11/22 19:45, Minh Nguyen wrote:

None of this is particularly relevant to Houston, but I don't think
there's any precedent or mechanism for formally deprecating a broadly
defined tag in only the places that satisfy certain criteria.


Houston has no zoning (the largest city in the US to not be zoned). Deed 
restrictions are used to get some of the same results accomplished by 
zoning in other cities. Note this applies only to Houston proper, not 
suburbs (Tiki Island, Pleak, and Jersey Village are known by me to be 
zoned, and there are probably others.)


That said, many areas will still qualify as a de facto residential, 
commercial, retail, or industrial area, and so I avoid deleting 
landuse=* unless it is clearly wrong/outdated.


If, like me, you want to see fewer unnamed landuse areas in your 
backyard, map more named landuse areas corresponding to retail and 
residential developments. These areas not only reduce the pressure to

"fill in" the map visually but also add information about the shape
of these developments that's often difficult to obtain from other map
services.


What I'd like to see less of is the use of dubious tag combinations like 
this:


landuse=retail
amenity=fuel
shop=convenience
name=Exxon

or whatever the brand might be. First, the convenience store and fuel 
should be separately tagged; I tag the fuel canopy (or an area near the 
pumps if no canopy)  as being the fuel station, and the building as the 
convenience store (which also gets the address data if  known). 
Convenience stores may be inside a landuse area, but shouldn't be tagged 
on the same way as a landuse area as I understand it.


--
Shawn K. Quinn 
http://www.rantroulette.com
http://www.skqrecordquest.com

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

Re: [Tagging] Lyft and nameless sectioning in OSM

2022-10-11 Thread stevea

Shawn has it right as I see it, too, so I think he says it for all of us.

Let's all say "there are regionalisms" and leave it at that (for now).  Tags 
can (and do) express those.  It's complicated, not terribly too much.

And we tighten it up across stores (convenience or otherwise) as nodes and 
landuse as polygons.  Yes.  As we see it, as necessary.

A lot going on here.

> On Oct 11, 2022, at 6:27 PM, Shawn K. Quinn  wrote:
> 
> On 10/11/22 19:45, Minh Nguyen wrote:
>> None of this is particularly relevant to Houston, but I don't think
>> there's any precedent or mechanism for formally deprecating a broadly
>> defined tag in only the places that satisfy certain criteria.
> 
> Houston has no zoning (the largest city in the US to not be zoned). Deed 
> restrictions are used to get some of the same results accomplished by zoning 
> in other cities. Note this applies only to Houston proper, not suburbs (Tiki 
> Island, Pleak, and Jersey Village are known by me to be zoned, and there are 
> probably others.)
> 
> That said, many areas will still qualify as a de facto residential, 
> commercial, retail, or industrial area, and so I avoid deleting landuse=* 
> unless it is clearly wrong/outdated.
> 
>> If, like me, you want to see fewer unnamed landuse areas in your backyard, 
>> map more named landuse areas corresponding to retail and residential 
>> developments. These areas not only reduce the pressure to
>> "fill in" the map visually but also add information about the shape
>> of these developments that's often difficult to obtain from other map
>> services.
> 
> What I'd like to see less of is the use of dubious tag combinations like this:
> 
> landuse=retail
> amenity=fuel
> shop=convenience
> name=Exxon
> 
> or whatever the brand might be. First, the convenience store and fuel should 
> be separately tagged; I tag the fuel canopy (or an area near the pumps if no 
> canopy)  as being the fuel station, and the building as the convenience store 
> (which also gets the address data if  known). Convenience stores may be 
> inside a landuse area, but shouldn't be tagged on the same way as a landuse 
> area as I understand it.

Yup; +1.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Historic

2022-10-11 Thread Graeme Fitzpatrick

On Tue, 11 Oct 2022 at 23:28, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
> Maybe there would be value in deapproving historic=battlefield
>

I would love to be able to move the vast majority of military= to
historic=military, as they are no longer military installations.

Yes, they certainly were, but they aren't any more.

On Wed, 12 Oct 2022 at 00:07, Peter Neale via Tagging <
tagging@openstreetmap.org> wrote:

> Many ruins and memorials are "of historic interest" it is true, but that
> could be tagged as a property ("historic=yes") of the object
> "man_made=" .
>

That could also be an option, but would that stop them rendering as current
military features?

Thanks

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

Re: [Tagging] Lyft and nameless sectioning in OSM