Re: [Tagging] Feature Proposal - Voting - historic

2022-12-04 Thread Martin Koppenhoefer
sent from a phone

> On 4 Dec 2022, at 11:41, Martin Koppenhoefer  wrote:
> 
> only for features that are considered of historical significance.

intended to say, “of extraordinary historical significance” on the one end, and 
the opposing direction is more like “generally somehow related to history”
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - Voting - historic

2022-12-04 Thread Martin Koppenhoefer



sent from a phone

> On 4 Dec 2022, at 10:57, Frederik Ramm  wrote:
> 
> "This key can be used on every observable feature that has a historical 
> meaning, regardless of ... interest to the OSM community."


I believe this is in reply to some unilaterally writing on the key:historic 
page of the wiki that it should be used only for features that are considered 
of historical significance.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Door tag

2022-12-03 Thread Martin Koppenhoefer


sent from a phone

> On 3 Dec 2022, at 02:50, Kyle Hensel  wrote:
> 
> Can we change the wiki so that it says “An entrance tag” instead of “The 
> entrance=* tag”?
> 
>  
> 

ok, or maybe “door” could simply mean “the type of a door”? Do we even need 
this qualifier with “entrance” at all?

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


Re: [Tagging] Feature Proposal - RFC - Crossing cleanup and deprecation

2022-11-30 Thread Martin Koppenhoefer


sent from a phone

> On 30 Nov 2022, at 18:53, Mateusz Konieczny via Tagging 
>  wrote:
> 
> https://www.openstreetmap.org/node/3586404853
> (and not tagged with anything directly indicating that)


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


Re: [Tagging] Feature Proposal - RFC - Crossing cleanup and deprecation

2022-11-30 Thread Martin Koppenhoefer
Am Mi., 30. Nov. 2022 um 01:10 Uhr schrieb Mateusz Konieczny via Tagging <
tagging@openstreetmap.org>:

>
> 29 lis 2022, 22:55 od dieterdre...@gmail.com:
>
>
>
> sent from a phone
>
> On 29 Nov 2022, at 09:02, Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> wrote:
>
> "no traffic signals" applies also only in some jurisdictions
>
>
>
> If there are traffic signals the crossing in OpenStreetMap gets tagged
> crossing=traffic_signals, this is regardless of jurisdiction AFAIK.
>
> there are >38k crossing_ref=zebra in Poland
> https://overpass-turbo.eu/s/1onT
>


yes, also here, I already wrote that the "crossing_ref" tag is about
crossing markings and not about typology (around here, I know that the wiki
may not be so clear on this). The "no traffic signals" was referring to
crossing=zebra, not crossing_ref
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Crossing cleanup and deprecation

2022-11-29 Thread Martin Koppenhoefer


sent from a phone

> On 29 Nov 2022, at 11:06, Minh Nguyen  wrote:
> 
> What was the problem with crossing_ref=zebra again?


it’s applied to signal controlled crossings as well when they have zebra road 
markings.


> 
> What you seem to be suggesting is that the definition of crossing=zebra 
> should favor the regulations of some parties to the Vienna Convention over 
> other parties to the convention, let alone other countries that use the term 
> "zebra" to refer to something slightly different.


I don’t see a problem in either having slightly different implications with the 
same tag, depending on the jurisdiction where it is used, or use different tags 
for similar things (like zebra here and marked in the US).

Which would be equivalent tagging for crossing=zebra without  the crossing tag? 
I don’t see it in the proposal.

Cheers Martin 



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


Re: [Tagging] Feature Proposal - RFC - Crossing cleanup and deprecation

2022-11-29 Thread Martin Koppenhoefer



sent from a phone

> On 29 Nov 2022, at 09:02, Mateusz Konieczny via Tagging 
>  wrote:
> 
> "no traffic signals" applies also only in some jurisdictions


If there are traffic signals the crossing in OpenStreetMap gets tagged 
crossing=traffic_signals, this is regardless of jurisdiction AFAIK.

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


Re: [Tagging] Feature Proposal - RFC - Crossing cleanup and deprecation

2022-11-28 Thread Martin Koppenhoefer


sent from a phone

> On 29 Nov 2022, at 00:52, Minh Nguyen  wrote:
> 
> Even if it weren't for iD's long-gone preset, I don't think an ostensibly 
> global tag should be defined based on the narrow provisions of a specific 
> country's laws.


I don’t think this is about a specific country, although it is not about all 
countries there are many of them that apply the concept and that seem to have 
decided on the feature in 1949 in an international agreement.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Crossing cleanup and deprecation

2022-11-28 Thread Martin Koppenhoefer


sent from a phone

> On 28 Nov 2022, at 23:53, Minh Nguyen  wrote:
> 
> If we keep crossing=zebra around based on the argument [1] that it takes 
> fewer keystrokes or clicks than adding crossing_ref=zebra or 
> crossing:markings=zebra without using a preset, then this undermines the 
> arguments against railway=tram_crossing, railway=tram_level_crossing, and 
> probably some other contentious, de facto tags that are essentially shortcuts 
> for tagging combinations without additional semantic value.


crossing:markings is just about this, road markings, and while 
crossing_ref=zebra wasn’t documented for a long time, people that added it 
around here told me it was about the presence of road markings as well.

Crossing=zebra is about a zebra crossing, it implies also vertical signs- in 
some jurisdictions and some conditions at least - and it implies that there 
aren’t traffic signals. 
Neither crossing:markings nor crossing_ref (as it is applied here) say anything 
about traffic signals. Here you will usually have zebra markings on signal 
controlled crossings, but they aren’t zebra crossings of course, still 
crossing:markings=zebra applies. And many of them have the crossing_ref=zebra 
tag (I ignore this tag, it does not follow any consistent logics here, 
definitely not a tag I would want to base navigation decisions on). Maybe they 
are when the signals don’t work (not sure about it, the law here requires 
vertical signs for zebra crossings, unless at road intersections).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Crossing cleanup and deprecation

2022-11-28 Thread Martin Koppenhoefer
Am Mo., 28. Nov. 2022 um 13:13 Uhr schrieb riiga :

> With the approval of the crossing:markings=* proposal there is now a
> satisfactory way of tagging whether a crossing is marked or not
> regardless of the crossing being uncontrolled or having traffic signals.
> For signals, there is crossing:signals=* which fulfills the same role
> but has not been formally approved yet.
>
> As such, I propose to approve crossing:signals=* and additionally
> deprecate crossing=* (except crossing=no).
>


Just because there is a now a way to map crossing markings separate from
other properties, does not imply all the tagging we have is not needed any
more, rather I would see "crossing:markings" as implicit, for example on a
"crossing=zebra".
Cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Start moving proposal announcements to the new forum

2022-11-20 Thread Martin Koppenhoefer



sent from a phone

> On 20 Nov 2022, at 02:27, Matija Nalis  
> wrote:
> 
> Because, someone has to do that summarizing work for extra channels to make 
> sense, and it is IMHO only fair that would
> be proposal author (expecting that EVERYBODY will do that SAME task is both 
> extremely wasteful, hugely unrealistic,
> and likely to lead to few participating members willing to do that becoming 
> burned out prematurely).


the first and foremost reason for the tagging mailing list to exist was the 
desire to offload tagging discussions on a central place, off the other 
channels, because people there felt overwhelmed with the discussions needed to 
agree on tags to describe the whole world, and it seemed helpful to reduce the 
volume on the talk list to a size that can be followed with significantly less 
dedication of time. Moving back to discussing tagging everywhere will make 
these other channels less useful for some people, I guess. Maybe this is 
unfounded because it came out, tagging is relevant all over OpenStreetMap (i.e. 
tagging discussions already happen on all channels, lately even on osmf-talk) 
and you can hardly ignore it, and because the structure of the contributors has 
changed, or something like this.

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


Re: [Tagging] Feature Proposal - RFC - Power utility office

2022-11-19 Thread Martin Koppenhoefer


sent from a phone

> On 18 Nov 2022, at 22:56, Mike Thompson  wrote:
> 
>> Energy and power are used quite interchangeably and power is the better word 
>> for it.
>> 
> 
> What evidence do you have that is the case?  What is being provided is 
> energy, not power.


maybe we can agree they provide power and charge for energy?___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Power utility office

2022-11-19 Thread Martin Koppenhoefer



sent from a phone

> On 18 Nov 2022, at 22:35, Mike Thompson  wrote:
> 
> In a nearby city to where I live, the city owned utility provides 
> electricity, water, sewer, and internet.  


yes, it is also common in areas I know to have a single provider for water, 
sewer, waste disposal and even local public transport. Maybe we should have a 
generic term for these kinds of offices and specify with additional tags the 
kind of services?

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


Re: [Tagging] amentiy=donation_centre?

2022-11-14 Thread Martin Koppenhoefer
maybe these can be seen as
amenity=social_facility?

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


Re: [Tagging] Relations of type=site + tourism=camp_site

2022-11-10 Thread Martin Koppenhoefer


sent from a phone

> On 10 Nov 2022, at 21:24, Sven Geggus  wrote:
> 
> Which is just plain wrong as they are not _only_.


you could have the sports centre and the camp site overlap, this way it 
wouldn’t be _only_

A site relation doesn’t magically solve the uncertainty of exclusive vs. shared 
use.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Relations of type=site + tourism=camp_site

2022-11-10 Thread Martin Koppenhoefer



sent from a phone

> On 10 Nov 2022, at 21:21, Sven Geggus  wrote:
> All the sites in the above changeset would need one or more additional
> redundant tags like restaurant=yes on the main node or way if a site
> relation is no longer an option.


so a restaurant is part of the camp site, but is not on the site but somewhere 
near, right?

Or maybe you can give an example so we can better understand the problem? 



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


Re: [Tagging] Relations of type=site + tourism=camp_site

2022-11-10 Thread Martin Koppenhoefer



sent from a phone

> On 10 Nov 2022, at 12:31, Yves via Tagging  wrote:
> 
> Site relations are often used to models thing that aren't spatially joined, 
> like windfarms, universities...
> I can easily imagine it's reasonable to use them for campings in some corner 
> cases where a single area doesn't work.


multipolygons can solve any disjoint area problems, you only need a site 
relation if some members are nodes or linear ways or relations. 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - archaeological_site

2022-11-08 Thread Martin Koppenhoefer


sent from a phone

> On 7 Nov 2022, at 12:21, Mateusz Konieczny via Tagging 
>  wrote:
> 
> deprecating site_type has chance of being a good idea


I don’t think so, it is defacto one of the tags used to further specify 
historic=archaeological_site and moving away from it is on the same level as 
finding a common definition for highway=trunk or getting rid of the contact: 
prefix, unlikely to happen 

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


Re: [Tagging] Feature Proposal - RFC - Street vendors

2022-11-08 Thread Martin Koppenhoefer
old style:
https://www.scattidigusto.it/wp-content/uploads/2019/01/Yaluz-chiosco-mercato-Garbatella-Roma.jpg

even older but different structure (single building):

http://4.bp.blogspot.com/-J5az9ofXSIQ/UVgQRJwwenI/wu8/vFdrpK5JwC0/s1600/roma-farmers-market-testaccio.jpg

new style
radical chic (single structure)
https://www.theromanpost.com/wp-content/uploads/2019/04/banco50-marco09_mg_2959-38.jpg

new, common type:
https://ilcaffe.tv/wp-content/uploads/2019/12/10-120638-145-53.jpg___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Street vendors

2022-11-08 Thread Martin Koppenhoefer



sent from a phone

> On 8 Nov 2022, at 08:15, Mateusz Konieczny via Tagging 
>  wrote:
> 
> I mapped some of similar shop=greengrocer (assigned space on tables) with
> shop=greengrocer street_vendor=yes
> 
> Outside their operating hours you will just see empty tables with roofs over 
> them


situation is different here, it is a fenced area with permanent, light 
buildings, (huts), open Monday to Saturday all day, but when they close they 
close some blinds and it becomes a closed volume 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Possible merge of marine_rescue & lifeboat_station tags?

2022-11-08 Thread Martin Koppenhoefer



sent from a phone

> On 8 Nov 2022, at 08:17, Mateusz Konieczny via Tagging 
>  wrote:
> 
> Having tag name that clearly excludes freshwater water rescue and changing it
> in description is highly confusing and I would prefer to avoid it if at all 
> possible.


exactly, it does not work and would lead to problems in the future. While you 
can write in the wiki that black is green, people are going to ignore it or 
miss it and continue to expect that black should be black and green not be a 
part of the blacks.

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


Re: [Tagging] Feature Proposal - RFC - Street vendors

2022-11-07 Thread Martin Koppenhoefer



sent from a phone

> On 7 Nov 2022, at 20:57, Volker Schmidt  wrote:
> 
> If we really don't have one already, it might be worth looking at how to map 
> stalls in general as I cudl see a lot of similarities. 


I mapped some of them with shop tags, e.g. shop=butcher shop=greengrocer 
shop=florist shop=seafood
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Proposal process [was: healthcare]

2022-11-06 Thread Martin Koppenhoefer


sent from a phone

> On 6 Nov 2022, at 12:34, m...@marcos-martinez.net wrote:
> 
> Regarding standardization: First of all, I hope we all work on the basis that 
> we want to improve things. Can you move a ton of sand with a spoon?


thing is, we don’t have just a heap of sand, we have hundreds of thousands of 
people having contributed by adding small parts of a gigantic castle like 
structure made of sand, and these people expect following mappers to use spoons 
so that the initial work isn’t inadvertently destroyed, as would be the case 
when moving the castle with a caterpillar. 

They also object to people who propose changing the sand underneath the visible 
structure with sand of a different color, because they fear it could make the 
whole structure collapse and because it won’t be visible anyway. ;-)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - Voting - Healthcare 1.1

2022-11-05 Thread Martin Koppenhoefer


sent from a phone

> On 6 Nov 2022, at 01:13, Robin Burek  wrote:
> 
> And what do you say to the result of 41 : 9 ? That is not a "consensus"? Then 
> why is healtcare also considered approved? Ah well, maybe because it is an 
> approved proposal and therefore the "consensus" for OSM. We can just throw 
> away the approved status if it no longer has any effect. And it is just above 
> "defacto" in the hierarchy.


there is nothing above „de facto”, de facto is a status that actually means de 
facto.

“Approved” is a status referring to a vote in the wiki but clearly any actual 
defacto status is much more important than any of the votes we held up to now, 
with hardly ever 50-100 people participating, and never more than 150 (afaik).

There is nothing wrong with amenity=hospital, neither with doctors, dentist, 
etc.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - Voting - historic

2022-11-04 Thread Martin Koppenhoefer


sent from a phone

> On 4 Nov 2022, at 13:17, Marc_marc  wrote:
> 
> our "sister" project (wikipedia) has no problem defining what is an anecdote 
> and what is "relevance from a historic viewpoint",
> I don't see why we should have any issue doing it.


Mappers are working fundamentally different from wikipedia authors, because 
they are recording observations, first hand study, while wikipedia work means 
working with sources. Original research is explicitly frowned upon in wikipedia 
while it is at the basis of mapping. We do not have relevance criteria as a 
hurdle for inclusion of things, we only require them to exist. I do not say 
relevance does not exist, but it is less important for our mapping. We are 
creating “categories” of things by applying tags, and I do not believe it would 
be helpful to have different main categories for the same thing, depending on 
its historic relevance, hence I do not believe redefining the “historic” key in 
this direction would be helpful for the project.

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


Re: [Tagging] Feature Proposal - Voting - historic

2022-11-04 Thread Martin Koppenhoefer


sent from a phone

> On 4 Nov 2022, at 08:21, Warin <61sundow...@gmail.com> wrote:
> 
> Using a tag for things other than the common meaning of that word (or word 
> group) is simply confusing and should be avoided.


I may be misguided, but from reading dictionaries it seems to me that the terms 
“historic” and “historical” are often used interchangeably in “common use”, 
although formal use has distinctive criteria for both.

The question about age is not very helpful, something can have happened 
yesterday and have ended an era and be historic today, on the other hand, 
something older than x will always be interesting for historians (because few 
objects of this time have survived, where x is some hundreds or thousands of 
years).

Generally, the tag “historic” is about features that typically or frequently 
are historic, it isn’t a tag to exclude those features of the same kind that 
aren’t. 
It also integrates some religious features which are often neither old nor 
historic in another sense (unless you see religion as a whole as something of 
the past), wayside crosses and shrines for example, which are ranks 3 and 6 of 
all historic values, 260k objects (17%) alone. Memorials 313k (20%) may be new, 
but they are always referring to history. We do not judge memorials by their 
perceived significance, we consider all memorials historically significant 
enough for getting the tag.

It would open Pandora’s box if we were to make differences between objects 
important for history / connected to important historical events, and others 
that we consider “old but not of historic relevance”. This is mostly subjective 
and not really measurable or verifiable, and we would not gain anything by 
formalizing such rules. People would see different things important and we 
would have pointless discussions or edit wars about relevance.

What would we gain by restricting the use of the historic key more than it is 
now?

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


Re: [Tagging] Feature Proposal - Voting - historic

2022-11-03 Thread Martin Koppenhoefer



sent from a phone

> On 3 Nov 2022, at 14:39, Sarah Hoffmann via Tagging 
>  wrote:
> 
> Random example: historic=manor. About 77% of objects tagged with
> historic=manor have a building=* tag, which makes perfect sense. A manor
> is a building after all. So it looks like historic=manor is more of a
> property tag to a building. But what about the 23% other manors that are
> not tagged as building? Is a historic=manor without a builing=* tag
> meant to be used as a primary key?


you said manor is an example, and I agree, but we have still to look at all 
object types individually, because for a historic=castle only 58% have a 
building tag, and looking closer we might eventually find that some of them 
could be extended as well. A castle (defensive one, this tag is very generic 
compared to manor) typically is composed of several buildings, open space, 
defensive walls and more, so having a combination with building seems less 
likely unless the mapper has selected the main building and ignored the others. 
Similarly I could imagine a manor to be bigger than a single building, e.g. 
comprising ancillary buildings, a garden or similar.

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


[Tagging] escaping semicolons in tag values

2022-11-01 Thread Martin Koppenhoefer
Is there already a proposal and or established method for escaping semicolons 
in tag values? Like \; or ;;?

Cheers Martin 


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


Re: [Tagging] Apparently bubblers emitting jet of water on buton press are water taps

2022-10-28 Thread Martin Koppenhoefer


sent from a phone

> On 29 Oct 2022, at 00:42, Graeme Fitzpatrick  wrote:
> 
> Is the water in your "drinking fountains" chilled, or is it just the natural 
> temperature of the water coming out?


there are a few “machines” that distribute chilled and carbon dioxide enriched 
water for a few pennies and where you fill bottles you bring, but these are 
relatively rare and are not considered drinking fountains, they’re an 
alternative. Speaking of drinking fountains, these are either fed by a spring 
or from the public water network. 
Particularly in the summer, and if the fountain hasn’t been used for some time, 
you’ll have to let it flow until it gets to the network temperature, because 
the first water would be quite warm and unsafe to drink.

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


Re: [Tagging] Apparently bubblers emitting jet of water on buton press are water taps

2022-10-28 Thread Martin Koppenhoefer



sent from a phone

> On 28 Oct 2022, at 10:46, Davidoskky via Tagging  
> wrote:
> I do not like the aggressiveness in this comment of yours;


I am sorry I wrote it like this, and agree it was not nice. Please accept  my 
apologies.

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


Re: [Tagging] Apparently bubblers emitting jet of water on buton press are water taps

2022-10-28 Thread Martin Koppenhoefer


sent from a phone

> On 28 Oct 2022, at 09:58, Davidoskky via Tagging  
> wrote:
> 
> While I could be interested in whether the flow of a fountain might be 
> stopped or not, I'm not really interested in how I'd have to do that: I can 
> just go to the fountain and observe what I find.


I couldn’t agree less. The push button fountain variant is horrible, you can 
hardly drink from it, can not wash your hands, particularly the hand that you 
use to push the button, and even filling a bottle is harder than with the 
continuous flow.
In addition if the thing wasn’t used recently, you’ll have to wait a long time 
until the water becomes cold and can be drunken.
Lever operated taps will provide more comfort but for drinking, tapless 
continuous flow is definitely the best.

Please also reflect about what you wrote: “ I can just go to the fountain and 
observe what I find.” 
How is such a statement helpful in a tagging discussion? It can be said about 
everything, I don’t tag it because I can go there to find out. If you are not 
interested in tagging details, don’t engage in the discussion about these 
things.


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


Re: [Tagging] Apparently bubblers emitting jet of water on buton press are water taps

2022-10-28 Thread Martin Koppenhoefer


sent from a phone

> On 28 Oct 2022, at 09:58, Davidoskky via Tagging  
> wrote:
> Actuator definitely provides more information and implicitly defines tap=yes.


actuator was not proposed so far, handle was, and while it is documented, it 
doesn’t seem particularly helpful looking at the provided pictures and 
suggested values, nor is it actually used (only around 300 uses).

Cheers Martin 


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


Re: [Tagging] Apparently bubblers emitting jet of water on buton press are water taps

2022-10-27 Thread Martin Koppenhoefer



sent from a phone

> On 27 Oct 2022, at 18:50, Matija Nalis  
> wrote:
> 
> instead of ad-hoc inventing
> new undocumented key without discussion...


there was a discussion about this, tap was seen as a distinguishing property 
that is yet missing. Handle is similar but not the same (handle is the thing 
you touch, if it is there, e.g. it could also be sensor based)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Apparently bubblers emitting jet of water on buton press are water taps

2022-10-27 Thread Martin Koppenhoefer
sent from a phone

> On 27 Oct 2022, at 08:33, Warin <61sundow...@gmail.com> wrote:
> 
> Water is usually scarce in Australia, all blubbers/drinking_fountains are 
> controlled.


sure, I did understand this, that’s why we should not generalize, the situation 
is different in different places.

There are “bubblers” with buttons/taps and other drinking fountains without 
taps. Just map it and possibly the details, and do not assume too much, because 
it might lead to wrong assumptions by others 

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


Re: [Tagging] Apparently bubblers emitting jet of water on buton press are water taps

2022-10-26 Thread Martin Koppenhoefer
sent from a phone

> On 26 Oct 2022, at 21:29, Paul Johnson  wrote:
> 
> Drinking fountains are switch or knob operated and shoot at an angle.


these are assumptions based on your experiences that don’t hold true around 
here, most drinking fountains have continuous flow.

By the way, I started to add “tap”=yes/no to record whether there is a tap to 
control the flow 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - archaeological_site

2022-10-24 Thread Martin Koppenhoefer


sent from a phone

> On 23 Oct 2022, at 22:15, Mateusz Konieczny via Tagging 
>  wrote:
> 
> personally it seems to me that it has chance of being a good idea


which one, deprecating site_type or ignoring the „rejection“ of the voting?

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


Re: [Tagging] Tagging of community mailboxes (cluster maiboxes)

2022-10-23 Thread Martin Koppenhoefer



sent from a phone

> On 23 Oct 2022, at 02:03, wolfy1339 via Tagging  
> wrote:
> 
> Here's a picture for reference, 
> https://upload.wikimedia.org/wikipedia/commons/0/0d/CanadaPostCommunityMailboxes15.jpg


for this kind, informal=yes should not be added, obviously

This looks pretty official 

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


Re: [Tagging] Feature Proposal - RFC - archaeological_site

2022-10-22 Thread Martin Koppenhoefer



sent from a phone

> On 22 Oct 2022, at 12:47, Anne-Karoline Distel  wrote:
> 
> Following the rejection of the crannog proposal with the concern about
> the hierarchy above the proposed tag, I now propose to change the key
> from site_type to archaeological_type


such a retagging would be a waste of time, I would not pursue this idea, and 
given the high majority that is required nowadays it is also unlikely to 
succeed.

You could just continue mapping the settlement sites and crannogs as you please 
and have a wonderful time, document the tags, speak about it so that other 
people interested in mapping this kind of feature can join you. :-)

Cheers Martin 



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


Re: [Tagging] Tagging of community mailboxes (cluster maiboxes)

2022-10-22 Thread Martin Koppenhoefer



sent from a phone

> On 22 Oct 2022, at 14:16, Marc_marc  wrote:
> 
> it's also a real amenity=post_box ? as a tourist, I can find this box
> on the postal operator's website and put my letter there?
> or is it just a habit that people also put the outbound there ?



if it works reliably, it could get amenity=post_box and informal=yes

Cheers Martin 



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


Re: [Tagging] feature Proposal - Voting - settlement_type=crannog

2022-10-17 Thread Martin Koppenhoefer
today I noticed some minor historic ruins and wonder whether you would consider 
this an archaeological site?
https://twitter.com/dieterdreist/status/1582130246769610753?s=46=pMmPcybaZu9zOoWBrbE_Eg

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


Re: [Tagging] feature Proposal - Voting - settlement_type=crannog

2022-10-17 Thread Martin Koppenhoefer



sent from a phone

> On 17 Oct 2022, at 20:30, Anne-Karoline Distel  wrote:
> 
> Not in reply to this specific email, but I've done a bit of tidying
> amonst keys and values the last three days, and I've documented some of
> my findings which might give food for thought:
> 
> https://www.openstreetmap.org/user/b-unicycling/diary/400164

which alternative of the 3 available would you prefer?



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


Re: [Tagging] dinosaurs

2022-10-17 Thread Martin Koppenhoefer
Am Mo., 17. Okt. 2022 um 10:09 Uhr schrieb Mateusz Konieczny via Tagging <
tagging@openstreetmap.org>:

> Oct 16, 2022, 17:30 by annekadis...@web.de:Is there a way to
>
> implement a warning into the editors not to combine
> "archaeological_site" with dinosaurs? I will replace the few I found
> with geological=palaeontological_site
> (
> https://wiki.openstreetmap.org/wiki/Tag:geological%3Dpalaeontological_site
> ).
>
> which tag combinations are problematic?
>
> how many of them?
>
>

we cannot tell until everyone is checked ;-)
This is about a tag being applied to a feature where it doesn't apply, and
maybe some have additional tags, but many will probably just be wrong (if
this should be a common error, around here I never encountered it)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] dinosaurs

2022-10-16 Thread Martin Koppenhoefer


sent from a phone

> On 16 Oct 2022, at 18:05, Volker Schmidt  wrote:
> 
> Do you have a feeling how many "archeologic" sites in OSM are in reality 
> palaeontological? I fear this is a frequent error, but difficult to spot. 


It doesn’t seem a huge problem, but even if this was widespread my stance would 
be to fix these as errors rather than accepting them as consistent use

Cheers Martin 


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


Re: [Tagging] dinosaurs

2022-10-16 Thread Martin Koppenhoefer
Am So., 16. Okt. 2022 um 17:33 Uhr schrieb Anne-Karoline Distel <
annekadis...@web.de>:

> I've come across a few dinosaur footprints, but that is not archaeology,
> because archaeology is about man made structures. Is there a way to
> implement a warning into the editors not to combine
> "archaeological_site" with dinosaurs? I will replace the few I found
> with geological=palaeontological_site
> (
> https://wiki.openstreetmap.org/wiki/Tag:geological%3Dpalaeontological_site
> ).
>
>

hm, a single footprint makes it a palaeontological site? Maybe, still I'd
go for a footprint tag,
on a node or polygon: natural=fossil_track or "ichnite" if it should sound
scientific

On a way: natural=fossil_trackway or protichnites (a trace / sequencs of
tracks)

you could then add another tag to specify the kind of beeing that has left
the footprint,
e.g. with "ichnotaxon"/ichnospecie/ichnogenus or something understandable.



> Maybe this is the wrong mailing list for it...



all tagging questions are welcome, but you could have also asked on
osm-paleontology-talk, if you had created it before ;-)

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


Re: [Tagging] Apparently bubblers emitting jet of water on buton press are water taps

2022-10-15 Thread Martin Koppenhoefer


sent from a phone

> On 15 Oct 2022, at 10:08, Warin <61sundow...@gmail.com> wrote:
> 
> The flow of water is downwards making them difficult to drink from without an 
> aid e.g. a cup.


while it may be true, you have to acknowledge that there are many places in the 
world that are providing drinking fountains for a long time, sometimes for a 
very long time, and many of them have downward flow, so this should not be a 
criterion. 

For some examples have a look at the drinking water article in wp.

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


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

2022-10-14 Thread Martin Koppenhoefer
Am Fr., 14. Okt. 2022 um 12:10 Uhr schrieb Davidoskky via Tagging <
tagging@openstreetmap.org>:

> This other fountain doesn't have such wall, thus it is not decorative
> and it cannot be tagged as amenity=fountain (assuming we disregard the
> recreational utility mentioned in the wiki).
>
>
https://upload.wikimedia.org/wikipedia/commons/5/56/Water_fountain_with_water_basin_near_Santiago_de_Compostela.jpg
>
>

this other fountain happens to be decorated as well. Let's ignore this for
a moment, and assume it wasn't. It could still be a decorative fountain, if
it can be seen as street decor. Setting up a fountain requires some effort,
so there will usually be a purpose, even if it isn't necessary now as it
was when it was constructed. I would generally see amenity=fountain
applicable for any fountain that is not only a drinking fountain and that
is not set up as a watering place for animals only.




> The shape and use of these two fountains looks the same to me.
> Why would you tag them as different features?
>


I wouldn't



>
> I'm not necessarily saying they need to be tagged as amenity=fountain,
> but I would expect their main tagging to be the same and maybe differ in
> some secondary parameter.



maybe, if you come up with an idea about these secondary parameters, we can
discuss them.

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


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

2022-10-14 Thread Martin Koppenhoefer
Am Fr., 14. Okt. 2022 um 10:22 Uhr schrieb Warin <61sundow...@gmail.com>:

>
> On 14/10/22 06:27, Martin Koppenhoefer wrote:
> >
> >
> >
> >
> > It seems we are seeing different things, I can’t help if you cannot
> > recognize that the fountain is clearly decorated. It is not just an
> > utility, the wall is a part, isn’t it?
> >
>
> Yep.. there is the problem ... 'we' see different things even from the
> same photo.
>
>
> To me a 'fountain' is a decorative object... at that spout of water from
> a wall into a trough is utilitarian not decorative. And you disagree.
>


no, I see the wall behind the trough with the water spout as part of the
fountain, it is a rock carved decorated wall. Or do you believe it is there
just for coincidence?

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


Re: [Tagging] Lyft and nameless sectioning in OSM

2022-10-13 Thread Martin Koppenhoefer



sent from a phone

> On 13 Oct 2022, at 21:50, Mateusz Konieczny via Tagging 
>  wrote:
> 
> Field is landuse=farmland - also when zoned as industrial area or scheduled 
> for
> residential construction.


interestingly not. I never found this particularly logical, but this situation 
is landuse=greenfield. 

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


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

2022-10-13 Thread Martin Koppenhoefer


sent from a phone

> On 13 Oct 2022, at 18:35, Davidoskky  wrote:
> 
> It is currently tagged as natural=spring, which it clearly is not since it is 
> not a natural formation and it is way too low altitude to be a spring anyway.


ask the mapper who put it, maybe they have more information. If you don’t know 
for sure what it is, don’t change the tags. If something seems fishy, add a 
“fixme=problem description” tag.

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


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

2022-10-13 Thread Martin Koppenhoefer


sent from a phone

> On 13 Oct 2022, at 18:25, Davidoskky via Tagging  
> wrote:
> 
> It is an old fountain, maybe 100/200 years old, but I don't see how that 
> could be defined as historic since it has no historic importance, it's just 
> an old fountain.
> 

maybe I am using the word historic incorrectly or it has several meanings, 
there is no requirement for “historic importance” in the meaning I intended. If 
you prefer the word “old”, I can live with this, although old could apply to 
things that are much younger than those where historic applies. Something from 
a few years ago could be old, not likely historic (maybe in the computer 
industry).


> I don't think it is decorative, it's a fountain in a small village which was 
> probably used to refresh people, get water for cleaning and watering plants.
> 


It seems we are seeing different things, I can’t help if you cannot recognize 
that the fountain is clearly decorated. It is not just an utility, the wall is 
a part, isn’t it?

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


Re: [Tagging] RFC: Two new extensions for the wiki: Log in via openstreetmap.org and vote via a GUI

2022-10-13 Thread Martin Koppenhoefer
Am Do., 13. Okt. 2022 um 11:55 Uhr schrieb Martin Fischer :

> Sidenote: I am curious how many subscribers the mailing lists each have.
> I'd expect tagging@ to have more subscribers than talk@ but that's just
> a hunch.



I see the potential users less amongst those who already participate here,
but it can be a good way for those who cannot be bothered to set up a wiki
account or who feel it is too complicated to participate because they would
have to register at a different site (wiki).

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


Re: [Tagging] RFC: Two new extensions for the wiki: Log in via openstreetmap.org and vote via a GUI

2022-10-13 Thread Martin Koppenhoefer
Am Do., 13. Okt. 2022 um 10:52 Uhr schrieb Martin Fischer :

> Hi everybody,
>
> I wrote two small MediaWiki extensions for wiki.openstreetmap.org: one
> to let you log in via your OSM account and one to provide an easy to use
> in-wiki GUI for proposal voting.
>
> I also set up a small demo wiki so that you all can try both extensions
> out:
>
> https://demo-wiki.push-f.com/
>
> You can leave your feedback using both extensions on the demo wiki, or
> alternatively here on the mailing list.



Hi Martin,

this is great news, maybe offtopic on the tagging mailing list, I'd have it
expected on talk or dev, but sounds and looks very interesting.

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


Re: [Tagging] Lyft and nameless sectioning in OSM

2022-10-13 Thread Martin Koppenhoefer
Am Mi., 12. Okt. 2022 um 20:00 Uhr schrieb Evan Carroll :

>
> This is all 100% new to me.  Where is it documented that a "shop" in a
> detached house should be mapped as a detached house, and not a shop?
>


please do not try to create confusion bvy shortening things. There are 2
entities to be mapped: a building and a shop. The building has its own
tags, refering to the building, and the value of the key "building" is
about its architectural type. As an architect I can tell you that there is
not just one kind of "building type", it depends on the classification
system which type a building is seen as, but that in general there are
building types, from an architectural point of view, is not under
discussion. The kind of types we are discerning can be found in the wiki,
and you are also encouraged to introduce different types as you see missing.



> Where is the notion of "architectural origins" documented.
>


it is an interpretation / result of the typology classification. It means
that a building that was constructed with a certain typology, keeps being
in this "box" unless it get transformed to a different type of building.
Personally, as long as you can recognize the original building type, I tend
to use this for the building value.




> I thought we could treat the wiki as authoritative and everything else not
> in the wiki as a wrong or mistaken, or unsupported?
>


we don't do this. We treat the wiki as descriptive and the data base as
authoritative, as long as it isn't an error, in this case we fix it ;-)

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


Re: [Tagging] Lyft and nameless sectioning in OSM

2022-10-13 Thread Martin Koppenhoefer
Am Mi., 12. Okt. 2022 um 17:43 Uhr schrieb Evan Carroll :

> Some neighborhoods have signs with names, which is great
> because you can add value with the name.




use place=neighbourhood for these names if they are referring to something
bigger than a contiguos property. When you add names to landuse, it creates
problems because names like these mostly refer to more than one landuse,
foremost the public streets, alleys and footways, but also educational
institutions, small retail and commercial use (it depends on the area of
course), places of worship, etc., and it prevents others from refining the
landuse because it is now also relating to a toponym.
Often names refer to the whole part of the settlement, but there are also
named contiguos, single use developments where adding the name to the
landuse seems to "work" (not generally, only in some instances).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Lyft and nameless sectioning in OSM

2022-10-13 Thread Martin Koppenhoefer
Am Mi., 12. Okt. 2022 um 16:25 Uhr schrieb Greg Troxel :

> Part of the issue is that landuse should more or less follow property
> lines, unless there is some reason why not.



I would generally agree with this



>   a several-acre parcel with
> a house and some trees is still landuse=residential on all of it,



it depends, if this means a big residential garden or other use that is
clearly associable with the people living there, then yes, if there are
other significant uses (particularly commercially relevant uses) like
breeding animals, growing fruit or vegetables for sale (significantly more
than the residents use themselves), or some other workplace, the landuse
could be split, it is up to the discreetion of the mapper.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Lyft and nameless sectioning in OSM

2022-10-13 Thread Martin Koppenhoefer
Am Mi., 12. Okt. 2022 um 17:46 Uhr schrieb Evan Carroll :

> Landuse has nothing to do with local authorities or zoning.



+1


However, as-is unnamed
> developed landuse is a function of the buildings inside.
>


not necessarily, it is about the whole land that has the tag, it could also
be land without buildings on it.

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


Re: [Tagging] Feature Proposal - RFC - Historic

2022-10-13 Thread Martin Koppenhoefer
Am Mi., 12. Okt. 2022 um 16:19 Uhr schrieb Marc_marc :

> On 12/10/2022 09:34, Martin Koppenhoefer wrote:
>
> >> we do not need the historic key to be “approved”,
>
> you don't need please do not speak for others,



it was a way if saying; "the history key cannot be more approved as it is
now". If you believe it should be voted upon "approval" of the history key,
what would it mean if the vote didn't pass?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Historic

2022-10-13 Thread Martin Koppenhoefer
Am Mi., 12. Okt. 2022 um 12:03 Uhr schrieb martianfreeloader <
martianfreeloa...@posteo.net>:

> So then what's the point of approving tags anyways?




there is not much sense in the act of "approving", the meaningful part has
happened before, the main benefit lies in the process, improving the
poposal by discussing things on a global level, widening your view,
integrating different views and situations.

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


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

2022-10-13 Thread Martin Koppenhoefer



sent from a phone

> On 11 Oct 2022, at 11:39, Illia Marchenko  wrote:
> 
> Of course. Hierarchical tagging. leisure = pitch & sport = *. 


or leisure=swimming_pool, track, golf_course, fitness_centre, sports_centre, 
climbing, mtb routes, landuse=recreation_ground, piste=* etc 

The situation is similar to drinking water sources, some can be found under one 
tag, for others there is a different tag. It is a consequence of how people 
perceive things, ideally.

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


Re: [Tagging] Apparently bubblers emitting jet of water on buton press are water taps

2022-10-12 Thread Martin Koppenhoefer



sent from a phone

> On 10 Oct 2022, at 19:58, Davidoskky via Tagging  
> wrote:
> 
> tap=* and water_tap=* are currently being used to tag the presence of a water 
> tap in a building.
> 
> tap=* is used in Dominican Republic and the values used are "yes", "no" or 
> the number of water taps in the building.
> 
> water_tap=* is used in Venezuela to indicate if a fuel station has a water 
> tap available.
> 
> 
> Writing a proposal for tap=* becomes even more difficult if I have to keep 
> these uses in mind.


tap=* could mean the feature is equipped with a tap. If you deem this is 
incompatible with the usage on buildings (which it somehow is, or also not), 
maybe these could be retagged to water_tap=* or something even better, in 
accordance/cooperation  with the people who put them?

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


Re: [Tagging] Lyft and nameless sectioning in OSM

2022-10-12 Thread Martin Koppenhoefer



sent from a phone

> On 12 Oct 2022, at 07:11, Evan Carroll  wrote:
> 
> Let's say you're in an industrial zone: do you tag as such 
> (landuse=industrial) if half of the buildings have been converted to lofts?


I would see landuse=residential on the parcels where people live and 
landuse=industrial on parcels with industrial landuse. 


> It would go both ways. But only if it's automated can we get an indicator of 
> the agreement between the macro-level landuse and the buildings contained.


if there are industrial and residential buildings, they should not go into the 
same landuse. 

Cheers Martin 

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


Re: [Tagging] Feature Proposal - RFC - Historic

2022-10-12 Thread Martin Koppenhoefer


sent from a phone

> On 12 Oct 2022, at 04:39, Graeme Fitzpatrick  wrote:
> 
> 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.


are all military tags about current use by the military, or maybe they can also 
be used for military installations that aren’t used currently? Is a military 
base that is now abandoned still a military base? Or a bunker?What are the 
criteria? Surely there is some cutoff, we do not tag medieval castles as 
military, although they once were. Tagging some stuff as historic, even 
archaeological site in some case, makes sense (and is what we already do).

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


Re: [Tagging] Feature Proposal - RFC - Historic

2022-10-12 Thread Martin Koppenhoefer


sent from a phone

> On 11 Oct 2022, at 17:32, martianfreeloader  
> wrote:
> 
> Nobody commented during RFC and then everybody voted against; which is not 
> nice. I was one of them.


particularly because the no vote didn’t offer any meaningful contribution, the 
only reason given was a formality (because the “historic” key is not formally 
approved). 


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


we do not need the historic key to be “approved”, it is already there, any 
definition we put in the wiki should reflect how the tags are actually used. 
Approving a definition that would make current tagging an “error” if it is 
completely introduced with many established and undisputed values, is just 
wasting everybody’s time, even more if the result would lead to “deprecation” 
of these established tags https://taginfo.openstreetmap.org/keys/historic#values

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


Re: [Tagging] Feature Proposal - RFC - Historic

2022-10-12 Thread Martin Koppenhoefer



sent from a phone

> On 11 Oct 2022, at 15:37, martianfreeloader  
> wrote:
> 
> Do you have a suggestion how to fix this?


it is not broken, unless your proposal gets approved 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Lyft and nameless sectioning in OSM

2022-10-11 Thread Martin Koppenhoefer

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

2022-10-11 Thread Martin Koppenhoefer


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

2022-10-11 Thread Martin Koppenhoefer


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

2022-10-11 Thread Martin Koppenhoefer


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

2022-10-11 Thread Martin Koppenhoefer



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

2022-10-11 Thread Martin Koppenhoefer


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

2022-10-11 Thread Martin Koppenhoefer



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

2022-10-11 Thread Martin Koppenhoefer


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] Feature Proposal - RFC - Water outlet

2022-10-11 Thread Martin Koppenhoefer
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=*

2022-10-11 Thread Martin Koppenhoefer
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] RFC - More sensible values for fountain=*

2022-10-11 Thread Martin Koppenhoefer
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] Feature Proposal - Voting - Payment denominations

2022-10-11 Thread Martin Koppenhoefer



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] Apparently bubblers emitting jet of water on buton press are water taps

2022-10-10 Thread Martin Koppenhoefer



sent from a phone

> On 10 Oct 2022, at 15:34, Warin <61sundow...@gmail.com> wrote:
> 
> Do we tag
> 
> the waste receptacle
> 
> or
> 
> the tap
> 
> or
> 
> the drinking fountain
> 
> ?? Which is the feature primarily there for? To me that is the drinking 
> fountain. I'd leave out the tap and the waste receptacle


if you want to tag it all in one node, you could add tap=yes and bin=yes, the 
latter is often used for bus stops with a waste bin.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Apparently bubblers emitting jet of water on buton press are water taps

2022-10-10 Thread Martin Koppenhoefer


sent from a phone

> On 10 Oct 2022, at 09:12, Davidoskky via Tagging  
> wrote:
> 
> I like this, but I'd remove amenity=drinking_water rather than 
> drinking_water=yes, because you _should_ add the tag amenity=fountain.


this would be completely inconsistent with the usage of the amenity=fountain 
tag in OpenStreetMap as far as I have seen it in multiple countries. It is true 
that OpenStreetMap allows for any tag you like, but this isn’t meant to 
encourage you to devalue established tags by using them differently from how 
they are typically used. What would be the benefit you expect from such 
retagging?

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


[Tagging] relevance of water taps as opposed to fountains

2022-10-09 Thread Martin Koppenhoefer
I see the wiki yesterday has received some more question marks regarding 
distinction of water taps and drinking fountains, claiming that the drinking 
fountain tag has fewer usage as the water tap and “many fountains also qualify 
for the water tap tag”.

IMHO this is the result of loosing focus. Yes, many fountains have a water tap, 
many bubblers have a water tap, but this doesn’t mean it is the most sensible 
tag to represent the feature as a whole, nor is it a reason to dismiss the more 
pertinent tags with the argument that water tap has more usage.

We could say the same for toilets, they also regularly provide water taps.
We typically focus on the most significant aspect of a thing.

A water tap that isn’t part of a drinking fountain surely merits tagging, and 
as there may be no other established “main tag” in the case of non-potable 
water, it seems right there is a man_made tag for it. But if the tap is part of 
an amenity=toilets, it becomes much less significant and is usually only 
implied and not mapped explicitly at all.

Similarly the tap that is part of a drinking fountain cannot represent the 
whole fountain, hence it shouldn’t be in “competition” with the fountain tag, 
it could be added as a property like tap=* but adding it as man_made to the 
amenity (which is supposed to represent the whole feature) would just be a 
misrepresentation and misleading.

Cheers Martin 

sent from a phone
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Apparently bubblers emitting jet of water on buton press are water taps

2022-10-09 Thread Martin Koppenhoefer


sent from a phone

> On 9 Oct 2022, at 23:21, Mateusz Konieczny via Tagging 
>  wrote:
> 
> I started this thread to confirm/reject listing
> https://wiki.openstreetmap.org/wiki/File:Bubbler.jpg as
> man_made=water_tap
> fountain=bubbler
> drinking_water=yes
> amenity=drinking_water


replace man_made=water_tap with tap=yes and I subscribe. Also remove the 
redundant drinking_water=yes, it is implied by amenity=drinking_water

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


Re: [Tagging] Apparently bubblers emitting jet of water on buton press are water taps

2022-10-09 Thread Martin Koppenhoefer


sent from a phone

> On 9 Oct 2022, at 23:21, Mateusz Konieczny via Tagging 
>  wrote:
> 
> Which one?
> https://wiki.openstreetmap.org/wiki/File:Water_flowing_from_drinking_water_tap.jpg
>  ?


yes, this one is not very clear, although the sticker they added makes it clear 
it is fine for drinking, apparently you have to bring a glass or bottle in 
order to drink without too much hazzle (you could drink there if it was without 
alternatives, for sure, but with alternatives you’d probably avoid it, because 
push buttons are generally uncomfortable and in this instance there is also too 
few distance to the support). The picture is not clear because we do not get to 
see the whole thing, just the tap



> Then I have not added in edit mentioned in this thread and I am still 
> confused about it
> and asked some question that I hope will clarify situation (I am confused how 
> it
> differs from https://wiki.openstreetmap.org/wiki/File:Fontanella_Bolsena.jpg -

the Bolsena one is clearly a drinking fountain made for people and animals, and 
is also styled like one so it can be identified from a distance (if you know 
local habits), the other one is not so clear but I wouldn’t complain if it was 
tagged as fountain=drinking

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


Re: [Tagging] Is this a drinking fountain?

2022-10-09 Thread Martin Koppenhoefer


sent from a phone

> On 10 Oct 2022, at 01:31, stevea  wrote:
> 
>  I suppose somebody figured "well, the drainage is good" (or even improved, 
> as here with a grate to a wastewater system, apparently)



yes, these are always connected via a grate with the sewers


> and "well, it doesn't make (hydrological) sense for us to 'plug' this with a 
> 'tap' (spigot, faucet, valve...), so we'll simply allow it to remain 
> free-flowing."  OK.


I’ve learnt initially at least some of them were required in some areas to have 
sufficient water in the sewers in all conditions, but most of them are probably 
just a small contribution to the amount of wasted water through old and leaking 
supply systems (I once read London was loosing a quarter of the fresh water 
through leakage, it’s a common phenomenon in many big cities)

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


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

2022-10-09 Thread Martin Koppenhoefer


sent from a phone

> On 9 Oct 2022, at 23:26, Marc_marc  wrote:
> 
> but it's certainly not forbidden to pay for 500€ with a 500€ note,
> even though some shops refuse to let you do so


I heard it was forbidden in this case not to accept the 500 bill as it is legal 
tender 



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


Re: [Tagging] Is this a drinking fountain?

2022-10-09 Thread Martin Koppenhoefer


sent from a phone

> On 10 Oct 2022, at 00:15, stevea  wrote:
> 
> If this water is potable, it's amenity=drinking_water. 


yes, it is potable, and if you look closely you’ll notice that the tube has an 
upper hole, so when you tap the flow it will create a vertical spout in the 
curve, so somehow it does have an upward flow.

There is no tap, continuous flow, which is best from a hygienic and temperature 
aspect but wasting some water of course.

I have looked at the drinking fountain article in en.wikipedia and from 14 
examples, only 4 have an upward flow, so I would not expect this to be a 
universal requirement, although I can imagine in some areas all drinking 
fountains might work like this. In Rome they are very rare, have seen only 
those in the sapienza university, while the hundreds of others in the city 
almost always provide the hole so you can redirect the flow (but it is not 
generally the case in other places nearby)


> Is it a fountain? Long sigh...I suppose so, but "fountain" wouldn't be the 
> first word I think of for this.  I wouldn't call it a "drinking fountain," 
> though (downward flow), though you can fill a water bottle and you could wash 
> your hands.


I’ve mapped it with fountain=block, for me it is a modern fountain, with a 
reference to the historic type (type of tube) but mimicking the normal stone 
blocks around. By shape it is less fountain than the Bolsena example, and the 
absence of a water tap doesn’t offer this kind of “side tracking”, so I thought 
it could be interesting mentioning it.

Cheers Martin 



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


Re: [Tagging] Is this a drinking fountain?

2022-10-09 Thread Martin Koppenhoefer


sent from a phone

> On 9 Oct 2022, at 23:40, Joseph Eisenberg  wrote:
> 
> As an American, I would not consider "fontanella bolsena" 
> (https://wiki.openstreetmap.org/wiki/File:Fontanella_Bolsena.jpg) to be a 
> drinking fountain, it appears to be a public drinking water "tap" (though in 
> American English we would usually call it a faucet or spigot).


what about this?
https://commons.wikimedia.org/wiki/File%3AFountain_Largo_Samuele_Alatri,_Roma,_Italia_Sep_01,_2020_12-52-56_PM.jpeg___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Is this a drinking fountain?

2022-10-09 Thread Martin Koppenhoefer


sent from a phone

> On 9 Oct 2022, at 23:14, Mateusz Konieczny via Tagging 
>  wrote:
> 
> If yes - why 
> https://wiki.openstreetmap.org/wiki/File:Water_flowing_from_drinking_water_tap.jpg
> would not be a water fountain?


looking again at this, it really is a poor construction and will not work well 
for either application, maybe ok to attach a hose, or to fill a glass, but the 
flow seems to strong and not uniform and it is too close to the cylinder to 
wash your hands or drink comfortably.

I agree, depending on the exact design of the cylinder (if it is designed as a 
public furniture or just a water tube) it could be a fountain or a water tap.

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


Re: [Tagging] Is this a drinking fountain?

2022-10-09 Thread Martin Koppenhoefer


sent from a phone

> On 9 Oct 2022, at 23:14, Mateusz Konieczny via Tagging 
>  wrote:
> 
> Or lets take
> https://wiki.openstreetmap.org/wiki/File:Fontanella_Bolsena.jpg
> illustrating fountain=drinking and seemingly without upward flow:
> is it a drinking fountain?


IMHO yes, it is near a beach (of the lake) and its purpose is providing 
drinking water to visitors. I‘ll give you another example of a dedicated 
drinking fountain with downward flow:

https://commons.wikimedia.org/wiki/File%3ADrinking_fountain_in_Firenze,_Italia_Aug_19,_2022_10-32-23_PM.jpeg

This is clearly a drinking fountain, everybody agrees?

equating “drinking fountain” with the vertical subtype would not catch the 
whole picture. 


btw., here’s what I would call a bottle refill (although I never tagged one nor 
have I proposed the value nor do I believe this is a fountain)
https://commons.wikimedia.org/wiki/File%3APubliacqua_Piazza_della_Vittoria.jpg

node 7813712083 is a similar machine I have added as vending machine (because 
you pay the water, although it is quite cheap, like 0.05 eur and you bring your 
own bottle of course), with poor tagging (not distinguishable from machines 
selling water bottles).

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


Re: [Tagging] Apparently bubblers emitting jet of water on buton press are water taps

2022-10-09 Thread Martin Koppenhoefer


sent from a phone

> On 9 Oct 2022, at 22:56, Mateusz Konieczny via Tagging 
>  wrote:
> 
> Let me know if this edit was right or wrong (I am quite confused here,
> and this is why I want to document this to make situation less confusing).


IMHO saying it _is_ a water tap is confusing, I’d say it _has_ a water tap, 
i.e. tap=yes

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


Re: [Tagging] Apparently bubblers emitting jet of water on buton press are water taps

2022-10-09 Thread Martin Koppenhoefer


sent from a phone

> On 9 Oct 2022, at 22:56, Mateusz Konieczny via Tagging 
>  wrote:
> 
> As the next part of drinking water linguistic journey I documented at
> https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dwater_tap#Examples
> (bottom example) that bubblers are mostly water taps, despite that
> it may be highly confusing for some people which are not native
> speakers.


the cylinder shaped drinking water fountain/water tap you set as example for 
water tap, if I counted right, was seen by 2 people as not a drinking fountain 
(Warin and stevea), while I said it was one or could be seen as one and you and 
marcmarc haven‘t been explicit. Maybe I missed someone in the count? I wouldn’t 
use such “survey results” to back anything in the wiki, and would not make 
suggestions in the wiki for the tagging of such edge cases.

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


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

2022-10-09 Thread Martin Koppenhoefer



sent from a phone

> On 9 Oct 2022, at 22:01, m.brandt...@posteo.de wrote:
> 
> voting has started for the proposal Payment denominations.


question: is it legal in the EU not to accept certain types of Euronotes? 

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


Re: [Tagging] RFC - A broad look at fountains

2022-10-09 Thread Martin Koppenhoefer
Am So., 9. Okt. 2022 um 12:22 Uhr schrieb Minh Nguyen <
m...@nguyen.cincinnati.oh.us>:

> drinking_water=no is already approved for non-potable water, and there
> are non-Boolean values and drinking_water:legal=* if you'd like to split
> hairs.



+1



> I'd expect that a tag for fountains and a tag for drinking
> fountains would both imply a default value for drinking_water=* by
> default, but the default should be overridden when more is known about
> the water source.
>


a tag for drinking fountains should definitely imply drinking_water=yes,
but amenity=fountain should not imply any default value for
"drinking_water", it should be checked and tagged explicitly. Expectations
change around the globe and while it could be approached with national or
regional defaults, I think it is better to be explicit (because a missing
value is not clear, can be default or unknown, and potability of water is
super important in this context).




>
> With a tag for water taps in general, it isn't as clear. But as a data
> consumer or user, I wouldn't be eager to assume that an outdoor tap is
> potable without more context. I've been to cemeteries in swampy New
> Orleans that have taps signposted "Water for Flowers" and never once
> considered that they might be hooked up to the municipal water system
> and maintained to the standard of a public drinking fountain.
>


yes, water taps on cemeteries, as far as I recall, have been the initial
reason for introducing man_made=water_tap (some people had started mapping
amenity=drinking_water drinking_water=no ;-) )

Cheers,
Martin




>
> [1]
>
> https://www.waterboards.ca.gov/drinking_water/certlic/drinkingwater/documents/lawbook/rwstatutes_20170113.pdf#page=30
> [2] https://commons.wikimedia.org/wiki/File:MUTCD-CA_PS-013.svg
> [3] https://forms.iapmo.org/email_marketing/codespotlight/2017/Aug3.htm
>
> --
> m...@nguyen.cincinnati.oh.us
>
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Martin Koppenhoefer (Dipl-Ing. Arch.)
Via del Santuario Regina degli Apostoli, 18

00145 Roma

|I|I|I|I|I|I|I|I|

Italia
N41.851, E12.4824
8FHJVF5W+W5

tel1: +39 06.916508070
tel2: +49 30 868708638
mobil: +39 392 3114712
m...@koppenhoefer.com
http://www.koppenhoefer.com


Hinweis:
Diese Nachricht wurde manuell erstellt. Wir bemühen uns um fehlerfreie
Korrespondenz, dennoch kann es in Ausnahmefällen vorkommen, dass bei der
manuellen Übertragung von Informationen in elektronische Medien die
übertragenen Informationen Fehler aufweisen. Wir bitten Sie, dies zu
entschuldigen.

Any views or opinions are solely those of the author and do not necessarily
represent those of koppenhoefer.com unless specifically stated.
This email and any files attached are confidential and intended solely for
the use of the individual or entity to which they are addressed.
If you have received this email in error, please notify
postmas...@koppenhoefer.com

Please note that to ensure regulatory compliance and for the protection of
our clients and business, we may monitor and read messages sent to and from
our systems.

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


Re: [Tagging] RFC - A broad look at fountains

2022-10-09 Thread Martin Koppenhoefer


sent from a phone

> On 9 Oct 2022, at 08:43, stevea  wrote:
> 
> Tags must capture these differences, and more.


and ideally they should do it in a way to reduce confusion


Cheers Martin 

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


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

2022-10-09 Thread Martin Koppenhoefer


sent from a phone

> On 9 Oct 2022, at 08:50, Warin <61sundow...@gmail.com> wrote:
> 
> I'll be voting no.


me too, it is trying to deprecate a handful of tags I am using for fountain 
classification. Why do people have to “deprecate” other people’s tags when they 
introduce new ones with different semantics?

How can a “water outlet” tag replace a tag that represents the whole fountain?

I also don’t like unnecessarily convoluted tags of this kind:
water_supply:for=bottles

and usually a water outlet is not “for bottles” but compatible with filling 
bottles.

Cheers Martin 

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


Re: [Tagging] RFC - A broad look at fountains

2022-10-08 Thread Martin Koppenhoefer
Am Sa., 8. Okt. 2022 um 19:26 Uhr schrieb michael spreng (datendelphin) <
m...@osm.datendelphin.net>:

> - It seems we have more specific terms in German for fountains.
>Springbrunnen, Laufbrunnen, Brunnen... it confuses that in English,
>everything is mapped to the same term (I'm not a native speaker,
>please correct me if there are more).



Marktbrunnen, Dorfbrunnen, Ziehbrunnen (ok, that's not a fountain),
Zierbrunnen, Wandbrunnen,
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] RFC - A broad look at fountains

2022-10-08 Thread Martin Koppenhoefer
Am Sa., 8. Okt. 2022 um 16:04 Uhr schrieb Davidoskky :

> > That’s why we decided some years ago to record additional detail about
> the structure in the fountain tag.
> I wish to add more sense to how these structures are described. The
> current tagging scheme has a lot of problems with overlapping tags.
>


this is called "competing tagging schemes".



>
> > drinking_fountain (which is somehow a duplicate of fountain=drinking ...)
> man_made=drinking_fountain is an exact duplicate of fountain=bubbler;
>


right, fountain=drinking_fountain is just the same as fountain=drinking,
these 2 could be conflated.
man_made=drinking_fountain is not required, I agree.



> there is no reason for having two equivalent tags at all.
>

there are reasons, but if they are exactly the same, it is probably better
in the long run to concentrate on one. Still it happens frequently in OSM,
see for example contact:phone and phone (and similar).



> > All of these can already be described, although there could (should
> IMHO) be more properties for the details, for example:
> Agreed, what I'm most interested in, however, is making sense of the
> main tags used; not the specific descriptive values.
>


that's a pity, because this is where we will likely progress. These
properties often are interesting for a specific use case, e.g. the presence
of a trough is something dog keepers are interested in.



>
> > I give precedence to fountains over taps, for a drinking fountain you
> could add tap=yes or no, in case of a bigger fountain you would tag the tap
> as its own object.
> If you use man_made=water_tap both to describe single taps of a large
> fountain and the fountain as a whole, then the tag has a double meaning
> and it's unclear what it is describing when you see it on the map.
>


it would seem completely off to tag a large fountain as man_made=water_tap,
wouldn't it? Who on earth would believe this is an adequate description?
Maybe I do not understand what you are writing, but I do not see a double
meaning, a water tap is a water tap?



> > I believe our tagging scheme for drinking water is following general
> interest here.
> Yes, the main interest is knowing where to find drinking water, that
> works very well.
> What doesn't work is the description of what is delivering the water.
> The example from Enno cannot be described unequivocally in a single way,
> it can be described in many different ways each missing out on something.
>


this is because we are yet missing a fountain-value for this kind of
fountains (what's the specific, maybe that they serve people and animals?).



>
> I'm not saying that this tagging scheme has to become the norm for
> tagging drinking water, I'm saying that since the option is there to tag
> drinking water places in more detail, then this scheme should make sense
> and account for all (at least most) cases in a simple and understandable
> way.
>


no, this is not how it works. Usually, if you want to tag something that is
not yet covered, you either invent something ad hoc and use it or if you
are unsure, you ask and try to find a way or invent a new tag so that it
can be adequately represented. You cannot pretend a scheme must be usable
for everything, but it should ideally be extendable to cater for what is
still missing.




> These features are not so widespread; thus the change or deprecation of
> one of them shouldn't be a big problem.
>


which features or tags are you specifically relating to?



> You must also realize that this scheme is probably generating a lot of
> mistags, since I imagine a lot of people are tagging drinking fountains
> as amenity=fountain (that is what I would do and what would appear to me
> as most sensible before reading 10 different wiki pages).
>


I don't have this impression, I saw this in fewer than a handful of cases,
from hundreds and thousands of fountains. What happens is they use
amenity=drinking_water and so there is no way to tag amenity=fountain.
If they used amenity=fountain with drinking_water=yes it wouldn't
necessarily be wrong, maybe a little bit misleading because one expects a
bigger or more decorated fountain, but you could still find drinking water
if you were thirsty...

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


Re: [Tagging] RFC - A broad look at fountains

2022-10-08 Thread Martin Koppenhoefer


sent from a phone

> On 8 Oct 2022, at 14:23, Davidoskky via Tagging  
> wrote:
> 
> It feels strange to me that the same exact structure might belong to three 
> different primary tags according to whether the water provided is potable or 
> not or if animals can use it or not.


this is the result of focusing what apparently most people are interested in 
(drinking water), regardless of the physical details 
It started like this 14-15 years ago, is working well for dataconsumers and 
also for mappers, but it leaves some questions open for those with specific 
requirements.

That’s why we decided some years ago to record additional detail about the 
structure in the fountain tag.
As a parallel development, 2 tags have been created in “man_made”, water taps 
(motivated from the people that wanted to map sources of non-potable water) and 
drinking_fountain (which is somehow a duplicate of fountain=drinking, but could 
help a as lower level “catch-all” when a more specific fountain type is tagged 
which is not known to the data consumer/reader). While I don’t use the 
man_made=drinking_fountain tag, I don’t see a need for explicit deprecation 
either.

Parallel to “fountain” there are other sources of drinking water for different 
contexts, natural springs, water points to get bigger quantities, fountains 
which also provide drinking water, toilets where drinking water may be 
available, watering places, water taps, water wells, etc.

All of these can already be described, although there could (should IMHO) be 
more properties for the details, for example:
 direction of the water,
 presence of a bowl/trough,
 presence of a tap(valve),
 kind of tap (push button or permanent, maybe sensors),
 capacity (how many people can use it at the same time, in case of a drinking 
fountain). 
kind of connection fixture (in case of water point)

Additionally maybe even other properties like 
temperature 
flow quantity 
colour
odor 
or if available chemical composition 

Some of them might be seen implied from other tags (e.g. a water tap will have 
a tap)


> 
> Moreover, that same thing might have a tap, thus in that case you may wish to 
> tag it in even more ways; you may decide to tag it as a tap or as a watering 
> place or as a fountain.


I give precedence to fountains over taps, for a drinking fountain you could add 
tap=yes or no, in case of a bigger fountain you would tag the tap as its own 
object.



> 
> Either tagging will not provide complete information about the object, but 
> only partial according to which one you picked.



You have to combine several tags to get a detailed picture, while many people 
seem to be fine with amenity=drinking_water and stop there ;-)
I believe our tagging scheme for drinking water is following general interest 
here. It is clear that you can always see things from a different angle and 
come to a different tagging scheme, but to actually change (as opposed to 
amending) what has been built upon in many years by many people, there must be 
terrible flaws with the status quo or very convincing advantages with the new 
way.

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


Re: [Tagging] RFC - A broad look at fountains

2022-10-08 Thread Martin Koppenhoefer


sent from a phone

> On 8 Oct 2022, at 12:43, Enno Hermann  wrote:
> 
> It does not make sense to me to use different tags for the same kind of 
> feature, so I generally use amenity=fountain for these with appropriate 
> subtags.


it’s not the same kind of feature if the water is drinkable in one case and 
isn’t in the other. I don’t say we must use different main tags, but it could 
be justified if we did

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


Re: [Tagging] RFC - A broad look at fountains

2022-10-08 Thread Martin Koppenhoefer


sent from a phone

> On 8 Oct 2022, at 12:43, Enno Hermann  wrote:
> 
> One thing I keep wondering about on this topic is how to tag very simple 
> fountains that are widespread in Switzerland along hiking paths 
> (https://commons.wikimedia.org/wiki/File:Adlisberg_-_Gockhausen_IMG_4215.jpg) 
> or in villages 
> (https://commons.wikimedia.org/wiki/File:Brunnen1886BassersdorfI.jpg). 
> Apparently they are not decorative enough for some people and should be 
> tagged amenity=drinking_water. However, the same type of fountain could have 
> a sign saying the water is not potable 
> (https://commons.wikimedia.org/wiki/File:Brunnen_Waldweg.jpeg, 
> https://commons.wikimedia.org/wiki/File:2014-05-20-Yverdon_(Foto_Dietrich_Michael_Weidmann)_032.JPG);


yes, if the water is drinkable, I would go with amenity=drinking_water, if it 
isn’t, maybe watering_place with drinking_water=no? Or if animals can’t drink 
it either, amenity=fountain seems ok. 

In general I believe we should have a property like trough=yes for situations 
where the water is collected in a trough and accessible to animals.

Feel free to make up a generic fountain tag for this kind of fountain.

If the water comes from a spring in loco, natural=spring should also be added 

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


Re: [Tagging] Deprecation proposal: man_made=drinking_fountain

2022-10-08 Thread Martin Koppenhoefer

sent from a phone

> On 8 Oct 2022, at 07:55, Warin <61sundow...@gmail.com> wrote:
> 
> Example Tom Bass Wall Fountain, Sydney, Australia 1963. Nicknamed "The 
> Urinal" for obvious reasons!


according to a british mapper, this is not a fountain but a water feature 路‍♂️
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] feature Proposal - Voting - settlement_type=crannog

2022-10-08 Thread Martin Koppenhoefer



sent from a phone

> On 8 Oct 2022, at 06:43, Warin <61sundow...@gmail.com> wrote:
> 
> I note that settlements are already on the values for the key historic, e.g 
> farm, manor, monastery, castle ... all places where people lived.


none of these are necessarily settlements on their own though, some might be if 
isolated and could be, but the other would only be part of a settlement, not 
constitute one alone

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


  1   2   3   4   5   6   7   8   9   10   >