Talk:Proposed features/Extending kneipp water cure

From OpenStreetMap Wiki
Jump to: navigation, search

IMHO using both amenity and leisure keys with the same value should be avoided. Looking over to leisure=schwimming_pool: there was migration from amenity to leisure. Both mean the water area.

The usage of this key is still small enough and limited to german speaking countries that already tagged feature could be changed with a mechanical edit. So imho this should be designed better.--Jojo4u (talk) 22:40, 19 May 2016 (UTC)

using both amenity and leisure keys with the same value I also think this is confusing.--Klumbumbus (talk) 21:40, 20 May 2016 (UTC)
I'm myself not completely happy with that but it was a compromise to keep backward compatibility. Imho a mechanical edit would not be possible: if for example kneipp water cure are redefined more like petrol stations, then instead of entering the outline of a kneipp basin, you would need to entre the outline of the wohle site of the kneipp facility. This can not be changed automatically. --JIDB (talk) 08:58, 31 May 2016 (UTC)
Could it be, that you meant more something like using a mechanical edit to rename all amenity=kneipp_water_cure in something like amenity=kneipp_basin so that amenity=kneipp_water_cure could be used for the whole site of a kneipp facility? I'm thinking about it... but I'm not sure, if I really want to have anything to do with a mechanical edit. --JIDB (talk) 09:21, 31 May 2016 (UTC)
I have just simplified the proposal to avoid both amenity and leisure keys with the same value --JIDB (talk) 21:51, 8 June 2016 (UTC)

Area vs. single basin

Hi, if the meaning of <amentiy=kneipp_water_cure> is changed to signify the whole area with one or more basins instead of just a single basin, I think that this would result in a lot of work to review and update all existing objects. How about defining a new tag like <amenity=kneipp_water_cure_area> to identify the area? The existing tag <amenity=kneipp_water_cure> could be kept unchanged and indicate each single basin. Of course, additional tags like <kneipp_water_cure=arm> (or <kneipp_water_cure:arm=yes>, if you prefer) could be used to identify the types of basins. --Biff (talk) 22:28, 8 June 2016 (UTC)

My idea is that it won't be necessary to update the existing objects. In the new meaning <amenity=kneipp_water_cure> is used for a Kneipp facility instead of for just a foot basin. But just a foot basin is also a Kneipp facility. Among the existing objects there are currently two main kinds of geometries and very few exceptions. The first main kind is just a node at the place of the foot basin. To tag the whole facility with a node, one would anyway place the node at the center of the basin, so that it is exactly the same geometry. The second kind of geometry is the outline of the foot basin. In this case the area for the whole facility would be a little bit bigger, but not much if there is just a foot basin. So that the existing objects can remain as they are and the proposal allows it explicitly. The few exceptions are where several basins where already drawn. These are mostly facilites I entered myself to test the proposal. There are easy to find using overpass and I could update them easily.
Introducing a new tag <amenity=kneipp_water_cure_area> would actually be more work: Until it is used by most objects, you wouldn't be able to use it to reliably search for Kneipp facilites. And there would be a risk that new facilities would use only one of those, so that a reliable search would have to always search for both --JIDB (talk) 19:14, 9 June 2016 (UTC)

Use more generic term than kneipp_water_cure?

Yet another idea: How about using a more generic term for the area where kneipp water cure is possible? For example, <amenity=hydrotherapy_area> might also be useful in countries where some other variety of hydrotherapy (see is used. --Biff (talk) 22:40, 8 June 2016 (UTC)

As a logical consequence, the existing kneipp basins could be retagged with <amenity=hydrotherapy> + <hydrotherapy=kneipp_water_cure>. --Biff (talk) 22:50, 8 June 2016 (UTC)
Nice idea. If my proposal would require a mechanical edit, then it would be a good thing to think about it. But as my proposal don't require a mechanical edit, I prefer not to go so far. One would need to know, how are the hydrotherapy facilities in other countries. Or else it would be difficult to make a good proposal. I have no knowledge about that; Moreover I could imagine that most aren't facilites on their own but probably part of an hospital or a wellness center, so that it could be quite complicated. --JIDB (talk) 19:28, 9 June 2016 (UTC)

healthcare rather than amenity?

did you consider changing the namespace to healthcare rather than amenity? -- (Question from Martin on the tagging mailing list)

Even if Kneipp facilities are used to improve the health (it's the original use), nowadays there are also used for personal enjoyment. So I think that amenity is a appropriate namespace. Actually there is a similar question on the discussion page of the current tag (see but about why not use a leisure tag. Do it's definitively not only for the health. --JIDB (talk) 18:18, 10 June 2016 (UTC)

In Example: name=* used for description

The first example shows the tag name=Kneippanlage. This is contrary to, because it uses the name=* tag for a description. Rather description=* should be used ... but as amenity=kneipp_water_cure holds already the full meaning of the word Kneippanlage, the tag should rather be removed, I think. (The further examples have specific names, thus they are okay.) In my eyes, I would be good to show best tagging practice in proposal examples. --Meillo (talk) 04:57, 20 June 2016 (UTC)

I prefer not to change the proposal during voting, but anyway the name isn't something new, so it isn't really part of the proposal so that it shouldn't influence the vote. Of course if we can improve the examples, we should. Here we could do it afterwards in the normal description of the feature. But in my opinion the name in the first example isn't contrary to the good practice for 2 reasons: First if you want to find the facility, you could ask someone "where is the Kneippanlage?" and you don't need to add anything (In comparison to find the track in the example in the good practice you can't simply ask "where is the track?"). So in my opinion "Kneippanlage" is both a name and a description. Secondly there are other possible names like "Wassertretstelle", "Kneipp-Gesundheitsanlage"... You can quite often find this name on a sign near the facility or on direction signs. All the signs for a specific facility will usually show the same name, and I think it is interesting to know, how the facility is named locally. --JIDB (talk) 07:46, 20 June 2016 (UTC)

Double-tagging basins

When mapping basins as area the proposal recommends to them two : as a property kneipp_water_cure:foot=yes on amenity=kneipp_water_cure and as an area kneipp_water_cure=foot+natural=water. IMHO it is established practise to let the data customers look into the amenity=kneipp_water_cure area and search for foot basins instead of double-tagging the presence and location. This is redundant from a data perspective and will lead to incosistencies. Of course there are exceptions (i.e. bridge=yes -> renderer issues). What are the reasons for the proposed tagging? "More difficult data extraction" should not count but "near impossible with today's tools" could be an argument.--Jojo4u (talk) 08:34, 20 June 2016 (UTC)

You are right, there is risk of inconsistencies but I decide to make the proposal like that for 2 reasons: First to have a way to indicate the available kinds of basin, even when tagging the facility as a node (instead as an area). Second because I had a look at the possibilities of the overpass API and currently it would not be possible to for example search for all kneipp_water_cure=arm within a amenity=kneipp_water_cure, it would only works for facilities with a name (using the function map_to_area). --JIDB (talk) 20:05, 20 June 2016 (UTC)