amenity=kneipp_water_cure feiner modellieren

JIDB wrote:

Im Fall "nearby" ist die genau Position des Armbeckens dadurch nicht genau definiert. Da es aber eigentlich immer ganz in der Nähe liegt, schien es mir wichtiger, dass den Wert sich einfach eintragen lässt.

Hat jemand eine Meinung dazu oder kennt ähnliche Fälle, die als Modell gelten könnten?

Guten Morgen!

@JIDB Herzlich Willkommen im Forum!

Bei uns gibt es ein Armbecken direkt an der Außenwand des Kurhauses. Die Wassertretstellen wurden verlegt, also kommt man mit "nearby" nicht weiter. Daher wäre es meiner Meinung nach hilfreich, Wassertretstelle und Armbecken genau unterscheiden zu können. Bald gibt es dann eine Kneipp-App ;-)

ChristianSW wrote:

Bei uns gibt es ein Armbecken direkt an der Außenwand des Kurhauses. Die Wassertretstellen wurden verlegt, also kommt man mit "nearby" nicht weiter

Danke für die Antwort, das ist natürlich ein Argument. An so einem Fall hatte ich nicht gedacht.

Laut aktuelle Definition "amenity=kneipp_water_cure" ist ein Fußbecken.
Möglichkeiten:

• Neue "amenity" extra für ein Armbecken. Aber dann womöglich auch noch für weitere Becken, es soll z.B. (selten) Gesichtbecken geben.
• "amenity=kneipp_water_cure" umdefinieren, sodass es irgendein Kneippbecken kennzeichnen darf. Ohne Zusatzattribut wäre es weiterhin ein Fußbecken. Armbecken müssten aber dann immer getrennt modelliert werden, was ich etwas zu aufwändig finde.
• "amenity=kneipp_water_cure" umdefinieren, sodass es ein oder eine Gruppe von Kneippbecken kennzeichnet. Bei einer Gruppe sollen alle Becken in Sichtweite voneinander liegen und die amenity wird auf dem Hauptbecken eingetragen.

Bei der 3. Möglichkeit könnte man ein isoliertes Armbecken dann wie folgt modellieren:

• Zusatzattribut "kneipp_water_cure:arm=only". So bleibt es relativ einfach.
• Zusatzattribute "kneipp_water_cure:arm=yes" + "kneipp_water_cure:foot=no". Nachteil: man braucht 2 Zusatzattribute. Vorteil: Vielleicht leichter zu interpretieren?

Ich habe auch mal eine Anlage gesehen, die 2 Fußbecken hatte. Das könnte man dann mit nur 1 "amenity=kneipp_water_cure" auf dem großerem Fußbecken modellieren und mit ein Zusatzattribut "kneipp_water_cure:foot=2" den zweiten Becken erwähnen.

Guten Morgen,

vielleicht reicht folgende Kombination:

amenity=kneipp_water_cure
kneipp_water_cure=arm/foot

kneipp_water_cure=arm würde dann Oberkörper oder Gesicht implizieren.

Einzelne Becken können dann gemappt werden, besondere Anmerkungen können mit description=* hinzugefügt werden.

Edit: Du könntest dann zum Beispiel ein Fußbecken als Fläche eintragen und kleinere (Arm-)Becken daneben als Node.

Hallo,

ChristianSW wrote:

kneipp_water_cure=arm/foot

Schön ist, dass diese Syntax einfacher als in meinem Vorschlag ist!

Mit meinem Vorschlag habe ich eigentlich 2 Ziele erreichen wollen:
1. Eine einfache Eingabe.
2. Eine einfache Suche nach Kneipp-Anlagen.

Würden wir dann auch eine Auflistung machen dürfen (z.B. "kneipp_water_cure=foot;arm") oder ist es eher nicht empfehlenswert?
Mit "kneipp_water_cure=foot;arm" wäre meinen 1. Ziel besser bedient als in meinem eigenen Vorschlag. Das würde "kneipp_water_cure:arm=built-in" aus meinem Vorschlag entsprechen oder eigentlich auch "kneipp_water_cure:arm=nearby". Dass das Armbecken nicht integriert sondern in der Nähe liegt, könnte man eventuell in "description=" erwähnen.

Was meinem 2. Ziel angeht, muss ich vielleicht erklären, was ich genau meine: Würde ich eine Karte (oder eine App) machen wollen, die alle Kneippanlage anzeigt, dann ist es mir erstmal egal wie viele Becken dort stehen. Ich will zuerst eine Karte sehen, wo ich ein Icon je Kneippanlage sehe. Und erst wenn ich auf einem Icon klicke, möchte ich als Detailinformationen sehen, dass dort z.B. 2 Fußbecken und 1 Armbecken liegen. Deshalb habe ich am 16.12. auch den Vorschlag gemacht, "amenity=kneipp_water_cure" umzudefinieren, sodass es ein oder eine Gruppe von Kneippbecken kennzeichnet. Dann kann man einfach je "amenity=kneipp_water_cure" ein Icon auf der Karte zeichnen.
Für diesen 2. Ziel ist es aber nicht so schön, wenn alle Becken einzeln als "amenity=kneipp_water_cure" gekennzeichnet sind. Aber andersherum ist es irgendwie auch begrenzend, wenn alle Becken nicht einzeln modelliert werden können. Da bin ich selber noch unschlüssig.

Guten Morgen!

JIDB wrote:

Würden wir dann auch eine Auflistung machen dürfen (z.B. "kneipp_water_cure=foot;arm") oder ist es eher nicht empfehlenswert?

Mit dem Zusatz kneipp_water_cure=foot/arm wollte ich die Möglichkeit schaffen, einzelne Anlagen genauer zu erfassen. Grundlage bleibt ohnehin eine Fläche mit amenity=kneipp_water_cure.

Bei den wenigen Anlagen, die ich kenne, ist Deine Variante - mehrere Becken gemeinsam zu erfassen - nicht anwendbar: Die Anlagen liegen räumlich zu weit entfernt.

kneipp_water_cure:arm=nearby halte ich für zu ungenau in der Aussage

Deine anderen Vorschläge gefallen mir besser:

kneipp_water_cure=foot;arm
kneipp_water_cure:arm=built-in

JIDB wrote:

Würde ich eine Karte (oder eine App) machen wollen, die alle Kneippanlage anzeigt, dann ist es mir erstmal egal wie viele Becken dort stehen. Ich will zuerst eine Karte sehen, wo ich ein Icon je Kneippanlage sehe.

Dies löst man meiner Meinung nach nicht über die Eingabe, sondern über die Auswertung der Daten.

Schau mal: http://openbookcase.org/map

Hier werden die Objekte je nach Zoomlevel gruppiert angezeigt. Leider kann ich Dir da nicht weiterhelfen, aber hier im Forum gibt es genug KollegInnen, die Dir dabei helfen können!

Edit: Nachtrag: OpenBookCase.org besitzt eine eigene Datenbank für die Tauschprojekte, dies soll nur ein Beispiel für mögliche Kartendarstellungen sein.

Sorry für die späte Antwort.

Wir haben hier unterschiedliche Ziele:
- du willst die Beckenarten genauer erfassen.
- ich will mehrere Becken zu einer Anlage zusammenfassen.
Ich finde, dass beide Ziele ihre Berechtigung haben.

Ich kenne mehrere Kneippanlage, die aus 2 oder 3 Becken bestehen aber trotzdem eine Einheit bilden. Das Gruppieren der Objekte je nach Zoom-Stufe finde ich dafür unpassend. Wenn ich Kneippanlage mit Tankstellen vergleiche, so wäre für mich ein Becken wie eine Zapfsäule. Jede Tankstelle soll idealerweise durch ein einziges Objekt modelliert werden. Die einzelnen Zapfsäulen sind zwar auch interessant, aber als Details für das Tankstelle-Objekt.
Ich kenne deine Kneippanlage nicht. Könnte man sie so vergleichen, wie wenn es auf beiden Seiten einer Straße jeweils eine Tankstelle geben würde, die von gleichen Pächter verwaltet wären? In dem Fall würde ich auch 2 Objekte haben wollen, da sie zu weit auseinander entfernt sind, um noch als eine Einheit betrachtet zu werden.

Momentan ist "amenity=kneipp_water_cure" so definiert, dass es ein Fußbecken modelliert. Das deckt somit keine der 2 Ziele.
Lässt sich das umdefinieren?
- ja für dein Ziel und sogar ziemlich schön: ohne Zusatztag bleibt es einfach ein Fußbecken.
- für mein Ziel eigentlich nicht sauber: Würde man es wie bei amenity=fuel machen wollen, dann müsste bei einer Fläche nicht nur den Becken gezeichnet werden sondern auch den Bereich rund herum. Und so würde bis jetzt nicht bearbeitet.
Deshalb hatte ich die Idee das Fußbecken als Hauptbecken zu betrachten und Details über ein eventuelles Nebenbecken als Zusatztag hinzuzufügen. Und das kann durchaus mit deinem Ziel kompatible sein. Aber ich sehe jetzt ein, dass es bestimmt Fälle gibt, die sich damit nicht behandeln lassen (z.B. bei 2 Fußbecken).

Ich müsste mal schauen, ob sich leicht nach Objekte amenity=kneipp_water_cure filtern lässt, die Teil einer bestimmten Relation sind. Dann könnte man eine Relation definieren, um mehrere Becken zu einer Kneippanlage zusammenzuführen und trotzdem die Anlage als 1 Objekt betrachten können. Aber ich würde trotzdem eine einfache Modellierung mit etwas wie "kneipp_water_cure=foot;arm" erlauben. Deine Fälle wären davon sowieso nicht betroffen, weil sie als getrennte Kneippanlage eingetragen werden würden, oder?

Gruß und einen guten Rutsch

Übrigens zwischen "kneipp_water_cure=foot;arm" und "kneipp_water_cure:arm=yes" ist die zweite Lösung vielleicht besser. Als Mensch finde ich zwar die erste Lösung ansprechender, aber irgendwo im Wiki steht, dass durch ";" getrennte Werte eher vermeidet werden sollten, weil viele Programme sie nicht richtig interpretieren können.

JIDB wrote:

Sorry für die späte Antwort.

Alles Ok, ich war auch "nachlässig": frohes neues Jahr!

JIDB wrote:

Wir haben hier unterschiedliche Ziele:
- du willst die Beckenarten genauer erfassen.
- ich will mehrere Becken zu einer Anlage zusammenfassen.
Ich finde, dass beide Ziele ihre Berechtigung haben.

Ich denke da an den Hinweis im Wiki:

"Manchmal befindet sich das Kneippbecken auf einem kleinen Gelände zusammen mit einem Barfußpfad oder einem Picknickplatz. Das Gelände kann durchaus "Kneippanlage" heißen (wenn es dort wirklich so benannt wird), sollte aber nicht mit amenity=kneipp_water_cure markiert werden."
http://wiki.openstreetmap.org/wiki/DE:T … cken_herum

Bei uns liegen, als Antwort auf Deinen Tankstellen-Vergleich, die Einrichtungen tatsächlich räumlich sehr weit entfernt: ein verwaistes Armbecken und eine Tretstelle an einem Fluss.

Zur Tretstelle gehören eine Sitzecke und eine Informationstafel, alles zusammen bildet aber keine "Kneipp-Anlage", sondern gehört zu einem Kurpark mit verschiedenen Einrichtungen. Die übergeordnete Instanz ist also der Kurpark. Daher ist mir wichtig, drei Fälle mit dem Tag modellieren zu können: Wassertretstelle im Fluss / Fußbecken / Armbecken.

danke, auch ein frohes neues Jahr!

ChristianSW wrote:

Ich denke da an den Hinweis im Wiki:

"Manchmal befindet sich das Kneippbecken auf einem kleinen Gelände zusammen mit einem Barfußpfad oder einem Picknickplatz. Das Gelände kann durchaus "Kneippanlage" heißen (wenn es dort wirklich so benannt wird), sollte aber nicht mit amenity=kneipp_water_cure markiert werden."

Ja, den Satz habe ich selber im Wiki eingetragen, weil es eine logische Schlussfolgerung von der Definition von amenity=kneipp_water_cure war. Es gab aber Kneippanlagen, wo es für das Gelände benutzt wurde. Wenn ich jetzt selber was komplett neues definieren würde, würde ich wahrscheinlich etwas für das Gelände vorschlagen, ähnlich wie bei der Tankstellen. Aber anderseits bin ich auch froh, dass es schon eine Definition für amenity=kneipp_water_cure gab. So was zu definieren ist nicht leicht. Jetzt macht es mehr Sinn, sich was auszudenken, was mit der aktuellen Lösung kompatibel ist.

Ich habe inzwischen geschaut, ob man eine Overpass-Suche machen kann, die zusammengehörenden Kneippbecken nur ein mal auslistet, wenn sie über eine Relationen verbunden sind. Das geht und es würde so aussehen:

[out:json][timeout:25];

//␣Selektiere␣alle␣Kneippbecken␣(Node␣oder␣Way):
(
node[amenity=kneipp_water_cure]({{bbox}});
way[amenity=kneipp_water_cure]({{bbox}});
)->.kneippbecken;

//␣Selektiere␣alle␣Kneippanlage-Relationen,␣die␣ein␣dieser␣Kneippbecken␣als␣Member␣haben:
(
rel[amenity=kneipp_water_cure](bn.kneippbecken);
rel[amenity=kneipp_water_cure](bw.kneippbecken);
)->.kneipprelationen;

//␣Selektiere␣die␣Mitglieder␣der␣Relationen:
(
node(r.kneipprelationen);
way(r.kneipprelationen);
);

//␣Bilde␣die␣Differenz␣(=␣Kneippbecken␣ohne␣Kneipp-Relation):
(␣.kneippbecken;␣-␣._;␣);

//␣Kneippbecken␣ohne␣Relation␣+␣Relationen:
(
._;
rel[amenity=kneipp_water_cure]({{bbox}});
);

//␣Print␣results
out␣body;
>␣;
out␣skel␣qt;

von daher würde ich mal 3 Sachen vorschlagen:
1. Wir erweitern die Definition von amenity=kneipp_water_cure, um die Beckenart spezifizieren zu können. Damit sollten deine 3 Fälle modelliert werden können.
2. Für einfache Fälle mit mehreren Becken, z.B. ein Fußbecken mit integriertem Armbecken, dürfen auch mehrere Beckenarten auf einem Objekt eingetragen werden. Damit können viele Fälle weiterhin einfach ohne Relation eingetragen werden.
3. Für komplexere Fälle mit mehreren Becken, führen wir dazu noch eine Relation ein. Die einzelnen Becken werden dabei als Punkt oder Fläche als amenity=kneipp_water_cure eingetragen und dann mit der Relation verbunden. Die Relation könnte durchaus auch den "Tag" amenity=kneipp_water_cure tragen. Einfache Programme können die Relation ignorieren und sehen alle Becken einzeln. Schönere Programme benutzen die Relation, um zu erkennen, dass die Becken zusammengehören.

Ich werde mal versuchen eine paar Beispiele aus dem Vorschlag zu machen und hier zu posten, dann können wir sehen, ob es passt oder nicht.

(Edit am 18.01.2016: "{{" und "}}" bei bbox im Code-Beispiel hinzugefügt. Irgendwie waren sie verloren gegangen)

Beispiel für eine Kneippanlage mit nur 1 Fußbecken
Da ändert sich eigentlich nichts.

Vorzugweise wird der Umriss der Becken so getaggt:

amenity=kneipp_water_cure
natural=water
name=Kneippanlage

Alternativ kann man auch einen Punkt benutzen, aber dann ohne "natural=water".

Beispiel mit der Kneippanlage in natürlichem Bachlauf aus dem Wiki

Für den Biespiel schätze ich mal, dass der Bach 5 m breit ist. Die Kneippanlage benutzt hier nur die Hälfte vom Bach (da man nur auf einer Seite des Handlaufs gehen kann) auf einer Länge von vielleicht 8 m.

Zuerst würde man der Bach mit der richtigen Breite z.B. wie folgt modellieren:

waterway=stream
width=5

(oder alternativ mit einer Fläche als "waterway=riverbank")

Dann zeichnet man den Umriss des Fußbeckens als 2.5 x 8m Rechteck im Bach und taggt es so:

amenity=kneipp_water_cure
natural=water
name=Wassertretanlage␣Birkenwerder

(Diese Kneippanlage liegt hier http://www.openstreetmap.org/node/2933374712, die ist in der Realität etwas anders modelliert)

Beispiel mit nur 1 Armbecken

Man setzt einen Punkt da wo der Becken ist und taggt es so:

amenity=kneipp_water_cure
kneipp_water_cure:foot=no
kneipp_water_cure:arm=yes
name=...

Es ist hier wichtig, "kneipp_water_cure:foot=no" nicht zu vergessen, da der Default-Wert "yes" wäre.

Beispiel mit nur 1 Fußbecken + 1 integrieten Armbecken

Der Umriss des Fußbecken wir so getaggt:

amenity=kneipp_water_cure
natural=water
kneipp_water_cure:foot=yes
kneipp_water_cure:arm=yes
name=...

Beispiel mit einer Kneippanlage mit 1 Fußbecken + 1 getrennten Armbecken (in der Nähe)

Einfache Variante:
Ohne den Armbecken genau zu lokalisieren: einfach wie im Beispiel Beispiel mit nur 1 Fußbecken + 1 integrieten Armbecken. Eventuell kann man noch unter description beschreiben, wo der Armbecken liegt.

Genauere Variante:
Der Umriss der Fußbecken wird so getaggt:

amenity=kneipp_water_cure
natural=water
kneipp_water_cure:foot=yes

Für den Armbecken wird einen Punkt so getaggt:

amenity=kneipp_water_cure
kneipp_water_cure:foot=no
kneipp_water_cure:arm=yes

Beide Becken werden mit einer Relation verbunden. Dafür könnte man "type=site" verwenden und dazu noch auch als "amenity=kneipp_water_cure" kennzeichnen:

type=site
amenity=kneipp_water_cure
name=Kneippanlage
member1:␣der␣Fußbecken
member2:␣der␣Armbecken

"amenity=kneipp_water_cure" würde sowohl auf den Becken (als Punkt oder Fläche) als auch auf de Relation stehen. Einfache Anwendungen ignorieren die Relation und finden somit nur die einzelnen Becken. Bessere Anwendungen interpretieren auch die Relation und wissen dann, dass die Becken zusammengehören.

Wobei ich mich noch frage, ob die Relation vielleicht doch nicht was anderes als "amenity=kneipp_water_cure" tragen sollte. Momentan wäre ich aber eher dafür, bei der Benutzung von "amenity=kneipp_water_cure" zu bleiben.

Hi JIDB, danke für die fleißige Arbeit, mir gefallen Deine Vorschläge sehr gut!

Mit einer Relation lassen sich dann auch andere Objekte einbeziehen, eine Informationstafel, Handläufe etc...

ChristianSW wrote:

Mit einer Relation lassen sich dann auch andere Objekte einbeziehen, eine Informationstafel, Handläufe etc...

Stimmt.
Allerdings bin ich mit der Relation trotzdem immer noch etwas unzufrieden. Auf dem Wiki findet man an verschiedenen Plätzen Hinweise, dass Relationen kompliziert und fehleranfällig sind. Und noch schlimmer: dass sie leicht verloren gehen können.

Z.B. unten https://wiki.openstreetmap.org/wiki/Rel … te%3Dpiste

Stanton wrote:

Relations are difficult to maintain. When ading a new feature, the mapper must know which existing relations to add it to, with which role, and if order of relation members matters for that particular relation. This is a source of errors – I am speaking from my own experience with bus routes I had mapped some time ago: Over time, the route members gradually erode away as ways are replaced, ways are reversed without reflecting that in the forward/backward role and other things. This is a reason why relations should be kept to the necessary minimum and avoided when there is another way to sufficiently tag things. I have often heard site relations mentioned as examples of relations that can and should be avoided.

Ich würde noch gerne überlegen, ob es nicht Alternative dafür geben könnte.
Ideen?

• Vielleicht eine gemeinsame Referenz als zusätzlicher Tag zu allen Becken einer Anlage hinzufügen, etwas wie "kneipp_water_cure:ref=xxx". Nur wird sich eine Referenz nicht leicht finden lassen. Der Name der Kneippanalge bietet sich da leider nicht an, da viele Anlage keinen eindeutigen Namen besitzen.
• Vielleicht das Gelände doch kennzeichnen. Zwar nicht als "amenity=kneipp_water_cure" aber vielleicht könnte man da einen anderen Tag benutzen, vielleicht "landuse=kneipp_water_cure" oder "amenity=kneipp_water_place". Ich werde mal schauen, ob die Overpass-API damit klar kommt, vermutlich schon. Andere Objekte wie Informationstafel und Handläufe wären dann automatisch auch drin, da sie sich wohl auch auf dem Gelände befinden.

JIDB wrote:

• Vielleicht eine gemeinsame Referenz als zusätzlicher Tag zu allen Becken einer Anlage hinzufügen, etwas wie "kneipp_water_cure:ref=xxx". Nur wird sich eine Referenz nicht leicht finden lassen. Der Name der Kneippanalge bietet sich da leider nicht an, da viele Anlage keinen eindeutigen Namen besitzen.
• Vielleicht das Gelände doch kennzeichnen. Zwar nicht als "amenity=kneipp_water_cure" aber vielleicht könnte man da einen anderen Tag benutzen, vielleicht "landuse=kneipp_water_cure" oder "amenity=kneipp_water_place". Ich werde mal schauen, ob die Overpass-API damit klar kommt, vermutlich schon. Andere Objekte wie Informationstafel und Handläufe wären dann automatisch auch drin, da sie sich wohl auch auf dem Gelände befinden.

Dann denke ich, dass "landuse=kneipp_water_cure" am besten geeignet ist.

Wollen wir für Deine Vorschläge, die Du oben ausgearbeitet hast, eine Beispielsammlung im Wiki anlegen? als Unterseite zu Deiner/meiner Benutzerseite?

Edit: vielleicht "leisure=kneipp_water_cure"?
http://wiki.openstreetmap.org/wiki/DE:Key:leisure

ChristianSW wrote:

Wollen wir für Deine Vorschläge, die Du oben ausgearbeitet hast, eine Beispielsammlung im Wiki anlegen? als Unterseite zu Deiner/meiner Benutzerseite?

Gute Idee. Ich habe mich schon gefragt, wo man einen Draft speichern könnte.

ChristianSW wrote:

Edit: vielleicht "leisure=kneipp_water_cure"?
http://wiki.openstreetmap.org/wiki/DE:Key:leisure

Na ja, auch wenn Kneippanlage auch gerne als Freizeit-Anlage benutzt werden, sie würden ursprünglich erfunden, um die Gesundheit zu fördern. "landuse" ist da neutraler als "leisure". Ich habe nicht geschaut, ob es eventuell noch weitere Möglichkeit geben könnte.

Momentan ich noch dabei zu schauen, ob man damit eine Overpass-Suche machen kann. Momentan habe ich nur eine Eingeschränkte Lösung gefunden. Zum Testen habe ich nach Kneippanlage gesucht, die in einem Park liegen. Und das ging nur, wenn der Park einen Namen trug. Das scheint eine Begrenzung der Overpass-Funktion "map_to_area" zu sein:

[out:json]
[timeout:25];

//␣Parks␣selektieren:
way({{bbox}})["leisure"="park"];

//␣Daraus␣eine␣Overpass-"area"␣machen␣(das␣funktioniert␣leider␣nur,␣wenn␣der␣Park␣einen␣Namen␣trägt):
map_to_area␣->.area;

//␣Alle␣Kneippanlage,␣die␣nicht␣in␣einem␣Park␣liegen:
(
(
//␣Alle␣Kneipanlage␣in␣angezeigeten␣Bereicht:
node␣["amenity"="kneipp_water_cure"]({{bbox}});
way["amenity"="kneipp_water_cure"]({{bbox}});
);
-␣//␣Minus
(
//␣Alle␣Kneipanlage␣die␣in␣einem␣Park␣liegen:
node␣["amenity"="kneipp_water_cure"](area.area);
way["amenity"="kneipp_water_cure"](area.area);
);
);

//␣Man␣müsste␣dazu␣noch␣alle␣Parks␣hinzufügen,␣in␣den␣eine␣Kneippanlage␣liegt,␣dafür␣habe␣ich␣momentan␣keine␣Lösung.␣␣Wenn␣wir␣allerdings␣mit␣Kneipp-Geländen␣statt␣Parks␣arbeiten␣würden,␣könnten␣wir␣einfach␣alle␣Kneipp-Gelände␣dazunehmen,␣ohne␣prüfen␣zu␣müssen,␣ob␣sie␣wirklich␣ein␣Kneippbecken␣beinhalten.

out␣geom;

JIDB wrote:

Das scheint eine Begrenzung der Overpass-Funktion "map_to_area" zu sein

Nicht direkt, für diese Ways wurde einfach keine entsprechende Area generiert, da die hartcodierten Generierungsregeln auf dem Server das nicht hergeben. Wie schon korrekt angemerkt, ist ein name=* Tag eine notwendige Voraussetzung.

Auf dem Entwicklungsserver gibt es jedoch folgende Option, die ganz einfach angepasst werden kann:

https://help.openstreetmap.org/question … in-polygon

Konkret für kneipp_water_cure sieht die Query dann so aus: http://overpass-turbo.eu/s/dQd

Wenn ihr das nützlich findet, könnt ihr ja auf Help OSM voten oder einen Kommentar im Github-Ticket hinterlassen, als Hinweis an Roland, das Thema priorisiert zu behandeln.

mmd wrote:

Auf dem Entwicklungsserver gibt es jedoch folgende Option, die ganz einfach angepasst werden kann:

https://help.openstreetmap.org/question … in-polygon

Konkret für kneipp_water_cure sieht die Query dann so aus: http://overpass-turbo.eu/s/dQd

Danke für den Hinweis! Das werde ich mich anschauen.

@mmd Danke für den Hinweis!

@JIDB Werkstatt zum Basteln: https://wiki.openstreetmap.org/wiki/Use … /Werkstatt

ChristianSW wrote:

Werkstatt zum Basteln: https://wiki.openstreetmap.org/wiki/Use … /Werkstatt

Danke, ich habe gerade wenig Zeit, aber ich hoffe, dass ich nächste Wochen wieder etwas Zeit finde, um das Thema voranzubringen.

Ich habe schon mal in der "Werstatt" angefangen. Ich habe aber noch Formatierungsprobleme bei den Beispiele und das mit dem Verbinden von Becken habe ich aber noch nicht drin. Für heute reicht es mir aber.

JIDB wrote:

Ich habe schon mal in der "Werstatt" angefangen. Ich habe aber noch Formatierungsprobleme bei den Beispiele und das mit dem Verbinden von Becken habe ich aber noch nicht drin. Für heute reicht es mir aber.

Hoffentlich finde ich demnächst mal Zeit zum Basteln, das kommende Wochenende füllt sich schon wieder mit Verpflichtungen...

Ich habe inzwischen den Vorschlag in der "Werkstatt" ergänzt. Für die Zusammenfassung von mehreren Becken habe ich die Modellierung des Geländes über eine Relation bevorzügt. Auch wenn die automatisierte Bearbeitung dadurch etwas schwieriger ist, ist die Eingabe, die Überprüfung und die Darstellung viel einfacher.

Wie sollten wir danach weiter verfahren? Im Wiki habe ich oft Umfrage/Vorschläge zu neuen Tags gesehen, die unendlich als Umfrage bleiben. Der Vorschlag ist hier nur eine Ergänzung und wird schon seit einiger Zeit hier diskutiert. Von daher wäre ich eher dafür es direkt ins Wiki einzutragen (wenn wir es als fertig betrachten). Das Wiki ist ja auch nicht endgültig, es lässt sich immer noch ändern, falls bessere Vorschläge noch kommen.

Wenn es fertig ist, wäre es außerdem ganz gut die englische Seite zu aktualisieren.

Moin JIDB! In den kommenden Tagen habe ich etwas Zeit zum Basteln. Wenn wir den Vorschlag als fertig erachten, sollten wir ein Proposal erstellen. Aber ohne größere Abstimmung sollten wir solche größeren Änderungen nie direkt ins Wiki eintragen. Das löst nur Verwirrung bis Ärger aus.

Hallo Christian, danke für die klare Meinung. Dann machen wir es sauber. Ich habe mich gerade die Seite https://wiki.openstreetmap.org/wiki/Proposal_process mehr oder weniger durchgelesen. Für den neuen Tag landuse=kneipp_water_cure ist es eigentlich perfekt geeignet. Die Werkstatt brauchen dafür dann nicht mehr, da kann man einen Proposal mit Status "Draft" angelegen, um erstmal dran zu basteln, und später den Status auf "Proposed" wechseln.

Für die Erweiterung von amenity=kneipp_water_cure weiß ich noch nicht wie es gehen soll. Proposals sind für neue Tags gedacht. Aber vielleicht kann man einen Proposal machen und irgendwie hervorheben, was sich ändert.

Hallo,
ich habe heute etwas weiter gemacht: ich mache einfach einen Proposal für landuse=kneipp_water_cure, wo ich dazu noch die Erweiterungen für amenity=kneipp_water_cure erkläre. Das gefällt mir so ganz gut! Momentan ist es noch in der Werkstatt.

Dabei musste ich wieder über deinen Vorschlag nachdenken, leisure=... statt landuse=... zu benutzen. Es gibt z.B. auch leisure=fitness_station, Fitness macht man auch für die Gesundheit nicht nur als Freizeit. Der Fall der Kneippanlage ist dann sehr ähnlich. In der Art gibt es auch leisure=sauna.

JIDB wrote:

Es gibt z.B. auch leisure=fitness_station, Fitness macht man auch für die Gesundheit nicht nur als Freizeit. Der Fall der Kneippanlage ist dann sehr ähnlich.

Kaum habe ich es gepostet, schon sage ich mir, dass landuse doch besser ist: Eigentlich hat eher der Fall der Kneippbecken (und nicht der ganzen Kneippanlage) Ähnlichkeiten mit den Fittnessgeräte. Da wir haben das Gelände markieren wollen, ist wahrscheinlich besser bei landuse zu bleiben. Schon der Name macht es klar, dass es nur für eine Fläche benutzt werden sollte. Mit leisure=... wäre der Verwechlunggefahr mit amenity=... zu groß.

Hallo Christian (nochmal),
hättest du eventuell ein Foto der Kneippanlage, die aus nur 1 Armbecken besteht? Falls ja, könnte es als Illustration für den Proposal nützlich sein.
Gruß

M.M.:

leisure ist auch als Fläche möglich/richtig.

Wenn ich landuse verwende, ist ein Ausschneiden aus dem darunterliegenden landuse (Wiese/Wald) notwendig.

Guten Morgen,

ich halte leisure= auch für geeigneter.

Ein Foto des Armbeckens könnte ich ab der kommenden Woche anfertigen, leider macht das Becken aufgrund der Winterpause keinen schönen Eindruck.

Danke für die Rückmeldungen!
Wald oder Wiese würde ich eher als landcover als als landuse kennzeichnen, oder? Aber egal: wenn ich mich die vorhandenen Kategorien in landuse anschaue, muss ich schon zustimmen, dass es oft für was größeres benutzt wird und dass "leisure" für eine Kneippanlage eigentlich ganz gut wäre.

Meine Befürchtung ist nur, dass es dann leicht eine Verwechselung zwischen amenity=kneipp_water_cure (Kneippbecken) und leisure=kneipp_water_cure (was dann das Gelände einer Kneippanlage wäre) geben könnte.

So was wie leisure=kneipp_water_cure_pitch oder leisure=kneipp_water_cure_area wäre aber vielleicht etwas zu lang, oder?

Flächen:
landuse=residential
in diese eine Fläche
leisure=kneipp_water_cure (ähnlich wie Park oder Sportcenter)
in diesem ein node mit
amenity=kneipp_water_cure, description=Kneipp-Armbecken
und ein Wasserbecken als Fläche mit
amenity=kneipp_water_cure, natural=water, fee=*, openning_hours=*, description=Kneippbecken, gefliest, Wasserhöhe 30-50 cm, mit Handlauf

Nicht die Zäune, Eingang, Wege, Bänke, Papierkörbe, ... vergessen.

JIDB wrote:

Hallo Christian (nochmal),
hättest du eventuell ein Foto der Kneippanlage, die aus nur 1 Armbecken besteht? Falls ja, könnte es als Illustration für den Proposal nützlich sein.
Gruß

Hi JIDB,
das Foto habe ich nun in den Entwurf eingebettet und an den Formulierungen gearbeitet.
Viele Grüße!

ChristianSW wrote:

das Foto habe ich nun in den Entwurf eingebettet und an den Formulierungen gearbeitet.

danke, das ist immer gut.
Ich habe selber jetzt auch Fotos für den letzten Beispiel hinzugefügt.

geri-oc wrote:

Flächen:
landuse=residential
in diese eine Fläche
leisure=kneipp_water_cure (ähnlich wie Park oder Sportcenter)
in diesem ein node mit
amenity=kneipp_water_cure, description=Kneipp-Armbecken
und ein Wasserbecken als Fläche mit
amenity=kneipp_water_cure, natural=water, fee=*, openning_hours=*, description=Kneippbecken, gefliest, Wasserhöhe 30-50 cm, mit Handlauf

Das mit "description" ist ein gute Idee, das werde ich vielleicht in manchen Beispielen übernehmen.

Meine Befürchtung mit dem Verwechslungsgefahr zwischen amenity=kneipp_water_cure und leisure=kneipp_water_cure bleibt aber bestehen. Besonders falls z.B. die 2 Tags es irgendwann als Preset in JOSM schaffen, könnte es leicht passieren, dass man den falschen anklickt. Eine schöne Alternative finde ich aber momentan nicht. Vielleicht kommen in der "Request for comments"-Phase weitere Ideen für einen besseren Namen, blöd ist nur, dass die URL für den Proposal diesen Namen enthalten wird.

Hallo JIDB, warum stellst Du die Fotos nicht bei Wikimedia commons ein?

Dort gibt es eine eigene Kategorie für Kneipp-Anlagen:

https://commons.wikimedia.org/wiki/Cate … ipp-Anlage

ChristianSW wrote:

Hallo JIDB, warum stellst Du die Fotos nicht bei Wikimedia commons ein?

Dort gibt es eine eigene Kategorie für Kneipp-Anlagen:

https://commons.wikimedia.org/wiki/Cate … ipp-Anlage

Reneman hat es schon verschoben ...

ChristianSW wrote:

warum stellst Du die Fotos nicht bei Wikimedia commons ein?

danke für den Hinweis. Ich habe zwar gesehen, dass man auch Bilder von Wikimedia Commons benutzen kann, aber es war mir ehrlich gesagt zu viel Aufwand zu schauen, was Wikimedia Commons genau ist und was man dort beachten sollte. Außerdem befürchte ich, dass man sich da nicht mit dem OSM-Login anmelden kann, oder?

Wenn es eine Kneippanlage-Kategorien gibt, klingt es natürlich interessant. Ich habe nämlich noch weitere Fotos von weitere Kneippanlage. Erst am Sonntag habe ich bei einer Radtour sogar 3 Kneippanlage kartografiert (und fotografiert), die bis jetzt gar nicht in OSM standen.

Aber erstmal war es leichter, die Fotos direkt auf dem OSM-Wiki hochzuladen.

Registrieren mit gleichen Nick ist möglich:
http://commons.wikimedia.org/w/index.ph … uselang=de

Hochladen ist eigentlich einfach:
http://commons.wikimedia.org/w/index.ph … uselang=de

Bei den Kategorien hatte ich auch meine Schwierigkeiten, dort nutze ich meist den entsprechenden Ort. Du hättest ja schon eine

http://commons.wikimedia.org/wiki/Categ … ipp-Anlage

JIDB wrote:

Ich habe zwar gesehen, dass man auch Bilder von Wikimedia Commons benutzen kann, aber es war mir ehrlich gesagt zu viel Aufwand zu schauen, was Wikimedia Commons genau ist und was man dort beachten sollte.

Für Dich dürfte das alles kein Problem sein - und bei Fragen helfen wir Dir hier gerne weiter!

JIDB wrote:

Wenn es eine Kneippanlage-Kategorien gibt, klingt es natürlich interessant. Ich habe nämlich noch weitere Fotos von weitere Kneippanlage. Erst am Sonntag habe ich bei einer Radtour sogar 3 Kneippanlage kartografiert (und fotografiert), die bis jetzt gar nicht in OSM standen.

So macht OSM Spaß! Wenn Dich die fotografische Erkundung der Welt interessiert, schau mal in dieses Projekt: http://geo.hlipp.de/

Fotos von Kneipp-Anlagen gibt es dort auch.

danke für eure Antwort.

geri-oc wrote:

Registrieren mit gleichen Nick ist möglich

Das ich was ich vermutet hatte, ich muss mich erneut registrieren (auch wenn ich natürlich den gleichen Nick benutzen kann...). Das werde ich mich wahrscheinlich mal anschauen, aber vielleicht erst nachdem der Proposal voran gekommen ist, das wird nämlich bestimmt noch 2-3 Wochen dauern, bevor ich die Zeit habe, daraus einen echten "draft" zu machen...

ChristianSW wrote:

schau mal in dieses Projekt: http://geo.hlipp.de/

Klingt interessant, das werde ich mich bei Gelegenheit anschauen.

Ich habe noch eine Alternative für das Gelände einer Kneippanlage gefunden: eine neue Sportart sport=kneipp_water_cure definieren, was dann zusammen mit leisure=pitch verwendet wird. Kneippen ist ja eigentlich eine sanfte Sportart, die die Gesundheit fördert. Schön dabei finde ich:
* dass es etwas ist, was es schon gibt, sodass es leichter in Renderern oder Apps übernommen werden kann.
* Bei leisure=pitch ist es klar, dass es sich um das Gelände handelt.
Ihr könnt gerne eure Meinung dazu sagen.

Ich habe es momentan so im Proposal eingetragen, der jetzt hier liegt:
https://wiki.openstreetmap.org/wiki/DE: … water_cure

Bis auf vielleicht einen Darstellung-Vorschlag (vielleicht einen Fuß mit Wasser) wäre der Proposal sonst erstmal fertig. Für Korrekturen oder Ergänzungen bin dankbar. In der nächsten Zeit werde ich es dann auf Englisch übersetzen.

Nach wie vor gefällt mir die Kombination von

leisure=kneipp_water_cure und
amenity=kneipp_water_cure besser.

Besonders leisure=pitch halte ich für missverständlich.

Danke für die Antwort. Ich sehe aber nicht in wie weit leisure=pitch missverständlich sein kann. Kannst du vielleicht genauer erläutern, was dir daran stört?

JIDB wrote:

Danke für die Antwort. Ich sehe aber nicht in wie weit leisure=pitch missverständlich sein kann. Kannst du vielleicht genauer erläutern, was dir daran stört?

Bei genauer Betrachtung der mannigfaltigen Bedeutungen von pitch
http://www.dict.cc/englisch-deutsch/pitch.html
vermag ich keine zu finden, die nur annähernd auf so ein Wassertretbecken passt.

ChristianSW wrote:

Nach wie vor gefällt mir die Kombination von

leisure=kneipp_water_cure und
amenity=kneipp_water_cure besser.

Besonders leisure=pitch halte ich für missverständlich.

Finde ich auch. amenity kann doch auch innerhalb von leisure verwendet werden.

Mache doch einmal ein Beispiel deiner Kneippanlage mit den verschiedenen Becken und ...

Beispiele sind hier vorgestellt:

https://wiki.openstreetmap.org/wiki/DE: … e#Examples

Für die Installationen gefällt mir amenity=kneipp_water_cure besser, die Fläche um das Gelände würde ich nach Gerds Vorschlag als leisure=kneipp_water_cure kennzeichnen.

geri-oc wrote:

Mache doch einmal ein Beispiel deiner Kneippanlage mit den verschiedenen Becken und ...

Der letzte Beispiel im aktuellen Stand des Proposal entspricht die Kneippanlage in Pullach:
http://www.openstreetmap.org/way/173834479
Momentan ist sie teilweise anders modelliert. Selber habe ich sie nur genauer modelliert (Gelände genauer abgemessen, die 2 Becken eingetragen, ...) und momentan ist das Gelände als "landuse=recreation_ground" getaggt, weil es in der Urfassung so war und ich es nicht ändern wollte, so lange am Proposal gearbeitet wird.

Am Sonntag habe ich 2 fehlende Kneippanlage mit Fuß- und Armbecken eingetragen.
Eine mit getrenntem Armbecken:
http://www.openstreetmap.org/way/407534051
Und eine mit integriertem Armbecken:
http://www.openstreetmap.org/way/407535742
Das Gelände habe ich mit leisure=pitch + sport=kneipp_water_cure getaggt, um den Proposal mal zu testen. Das würde ich natürlich anpassen, wenn es im Proposal nicht dabei bleibt.

hurdygurdyman wrote:

Bei genauer Betrachtung der mannigfaltigen Bedeutungen von pitch
http://www.dict.cc/englisch-deutsch/pitch.html
vermag ich keine zu finden, die nur annähernd auf so ein Wassertretbecken passt.

Willkommen in der Diskussionsrunde! Hier ging es nicht um das Kneippbecken sondern um das ganze Gelände der Kneippanlage. Aber danke für das Argument, warum leisure=pitch missverständlich sei. Und eigentlich hast du recht: für die Benutzung von "pitch" im OSM scheint mir aus deiner Liste "Spielfeld" die treffende Übersetzung zu sein. Die englische Beschreibung im Wiki sagt auch "for the playing surface itself" (http://wiki.openstreetmap.org/wiki/Tag:leisure%3Dpitch). Dann ist leisure=pitch für das Gelände der Kneippanlage doch nicht so passend.

Wie wäre es mit landuse=recreation_ground mit recreation=kneipp_water_cure?

Yokr wrote:

Wie wäre es mit landuse=recreation_ground mit recreation=kneipp_water_cure?

Auf den ersten Blick schon. Aber wenn man im wiki http://wiki.openstreetmap.org/wiki/Tag: … ion_ground liest, dann doch nicht.

Ich habe eine weitere Anlage kartiert, http://www.openstreetmap.org/#map=19/49 … 1&layers=N und mich an https://wiki.openstreetmap.org/wiki/DE: … e#Examples gehalten.
Screenshot

Wobei leisure=pitch suboptimal ist.

Wegabschneider wrote:

Ich habe eine weitere Anlage kartiert,...

Danke, schön zu sehen!

recreation_ground = Grünfläche ist begrifflich unsauber. Außerdem denke ich, dass viele Kneipp-Anlagen von Grünflächen umgeben sind und daher in der Kartendarstellung untergehen.

Yokr wrote:

Wie wäre es mit landuse=recreation_ground mit recreation=kneipp_water_cure?

Ich finde eigentlich auch, das es sich schön anhört. Aber das Gelände einer Kneippanlage ist eben nicht immer eine Grünfläche. Für Kneippanlage, wo es zutrifft, lässt es sich eventuell immer noch mit leisure=kneipp_water_cure kombinieren.

Ich werde den Proposal jetzt auf leisure=kneipp_water_cure zurückstellen, dann bald auf Englisch übersetzen, sodass er dann in die offizielle "RFC"-Phase wechseln kann. In der Phase sind immer noch Änderungen möglich, falls neue Ideen oder Argumente auftauchen. Danke schon mal für eure Kommentaren noch vor der RFC-Phase!

Wegabschneider wrote:

Ich habe eine weitere Anlage kartiert, http://www.openstreetmap.org/#map=19/49 … 1&layers=N und mich an https://wiki.openstreetmap.org/wiki/DE: … e#Examples gehalten.
http://i.imgur.com/kX5ebLK.jpg Screenshot

Wobei leisure=pitch suboptimal ist.

Dass das Wasser innerhalb von leisure=pitch nicht mehr blau sondern grau erscheint, finde ich in dieser Darstellung ziemlich unschön. Aber das wäre kein Modellierungsproblem sondern ein Renderer-Problem und wir mappen ja nicht für den Renderer... Wenn es nur daran gelegen hätte, wäre ich bei leisure=pitch geblieben.

Der Proposal ist jetzt auf Deutsch und auf Englisch verfügbar und ich habe gerade eine Nachricht auf https://lists.openstreetmap.org/listinfo/tagging gepostet, um die RFC-Phase zu starten.

Proposal auf Deutsch: https://wiki.openstreetmap.org/wiki/DE: … water_cure
Proposal auf Englisch: https://wiki.openstreetmap.org/wiki/Pro … water_cure

Ich mache mal selber hier ein Kommentar zu dem Proposal. Mir ist nämlich noch eine Idee eingefallen, um das Gelände eine Kneippanlage zu taggen: warum nicht das existierende Tag "amenity=kneipp_water_cure" wieder verwenden? Natürlich nicht einfach so, sondern mit einem zusätzlichen Tag, vielleicht "kneipp_water_cure:facility=yes", was bedeuten würde, dass nicht ein Becken sondern das Gelände getaggt wird.

Die Kneippanlage mit Fuß- und Armbecken würde man dann so taggen/
Das Fußbecken als Fläche:

amenity=kneipp_water_cure
kneipp_water_cure:foot=yes
natural=water

Das Armbecken als Node:

amenity=kneipp_water_cure
kneipp_water_cure:foot=no
kneipp_water_cure:arm=yes

Und das Gelände als Fläche:

amenity=kneipp_water_cure
kneipp_water_cure:facility=yes
name=Kneippanlage

Und falls die Lage der einzelnen Becken nicht genau bekannt ist, könnte man das ganze auch vereinfacht wie folgt taggen:

amenity=kneipp_water_cure
kneipp_water_cure:facility=yes
kneipp_water_cure:foot=yes
kneipp_water_cure:arm=yes
name=Kneippanlage

Was haltet ihr davon?

Mir gefällt es so, wie es jetzt im Proposal steht: leisure=kneipp_water_cure für das Gelände, amenity=kneipp_water_cure für die einzelnen Installationen.

ChristianSW wrote:

Mir gefällt es so, wie es jetzt im Proposal steht: leisure=kneipp_water_cure für das Gelände, amenity=kneipp_water_cure für die einzelnen Installationen.

Danke für die Rückmeldung.

Die RFC-Phase hat sonst bis jetzt keine Kommentaren der Tagging-Mailing-Liste gebracht. Die Phase ist ja nicht zu Ende, aber irgendwie war es zu erwachten, da es Kneippanlage nur im deutschsprachigen Raum gibt...

Sonst noch eine Info: Der User #DWD* hat die Kneippbecken als POI in flosm.de integriert (siehe das Thread "Relaunch flosm.de"). Mir ist keine weitere Karte bekannt, wo man die Kneippbecken so einfach und so übersichtlich anzeigen kann:
http://www.flosm.de/html/POI-Karte.html … pwatercure

Nach einiger Zeit:

Es gab nur wenig Kommentaren auf dem Proposal aber immerhin. Allerdings scheint es mir, dass es schwierig sein wird, eine Einigkeit für einen neuen Tag für das Gelände einer Kneippanlege zu finden (Wenn überhaupt genug Leute sich an der Wahl beteiligen, damit man es als Einigung betrachten kann). Im Kommentar ging es darum, dass man vermeiden sollte, den gleichen Wert bei 2 Tags zu benutzen, und es stimmt eigentlich schon, ich finde es selber etwas verwirrend.

Vorgeschlagen wurde, die Modellierung der Kneippanlagen komplett neu zu machen und durch Mechanical Edits anzupassen. Von Mechanical Edits habe ich wenig Lust. Wenn ich die Kneippanlage komplett neu modellieren würde, würde ich sie ähnlich wie die Tankstellen modellieren, wo man das Gelände markiert und über Sub-Tags einträgt, was für Becken dort vorhanden sind. Eventuell können die Becken dazu gezeichnet werden, aber der Haupt-Tag ist dann das Gelände. Das ließe soweiso nicht so gut mit einem Mechanical Edit machen.

Aber wenn man amenity=kneipp_water_cure so umdefiniert, dass es eine Kneippanlage statt ein Kneippbecken darstellt und wie folgt eingetragen werden darf:
- als area für das Gelände einer Kneippanlage.
- als node für eine Kneippanlage (in diesem Fall ist es gleich, ob Becken oder ganze Anlage gemeint ist)
- als area für das Hauptbecken einer Anlage, aber nur wenn dort nur 1 Becken eingetragen wurde.

Damit bleibt man mit den existierenden Einträgen kompatibel (außer vielleicht die paar Sonderfälle, wo schon mehrere Becken eingetragen wurden. Davon gibt es aber nur wenige, das ließe sich manuell anpassen).

Und insgesamt ist die Modellierung doch einfacher. Ich werde demnächst versuchen, ein paar Beispiele nach dieser Idee hier zu beschreiben...

Tankstelle? Eher wie playground? Da gibt es leisure=playground als Fläche/Punkt für den gesamten Spielplatz und playground=* für die einzelnen Einrichtungen.

Dein Vorschlag klingt vernünftig, es sollte ein *=kneipp_water_cure Haupttag geben und es einfach das Gelände bezeichnen. Ob man das dann amenity belässt oder in leisure umtaggt lässt sich nach dieser Entscheidung noch diskutieren.

Danke für den Hinweis, das mit playground=* für die einzelne Einrichtungen kannte ich nicht. Bei den Tankstellen (amenity=fuel) ist es so, dass man die verfügbaren Zapfsäulen als Sub-Tags eintragen kann. Playground geht aber tatsächlich etwas weiter, es ist ein gutes Vorbild, wie man die einzelnen Becken modellieren könnte.

Hier ein Beispiel nach dieser Idee, ich finden, dass es gut aussieht:

Kneippanlage mit Fußbecken und in der Nähe gelegenem Armbecken

Bei der alten Modellierung wird der Umriss vom Fußbecken so getaggt:

amenity=kneipp_water_cure
name=Kneippanlage␣Pullach
natural=water

Da weiß man nur, dass es dort eine Kneippanlage mit Fußbecken gibt. Ob weitere Becken vorhanden sind, ist aus der Modellierung nicht bekannt.

Wird die Anlage von einem Mapper neu besucht, kann er die Modellierung wie folgt verfeinern:

Das Gelände wird so getaggt:

amenity=kneipp_water_cure
name=Kneippanlage␣Pullach
kneipp_water_cure:foot=yes
kneipp_water_cure:arm=yes

Und wenn der Mapper die Positionen der einzelnen Becken kennt, kann er dazu noch den Umriss des Fußbeckens so taggen:

kneipp_water_cure=foot
natural=water

Und für das Armbecken einen Punkt so taggen:

kneipp_water_cure=arm

Hier habe ich die weitere Beispiele dazu noch angepasst:

Kneippanlage mit einem Fußbecken

Vorzugsweise wird der Umriss des Geländes so getaggt:

amenity=kneipp_water_cure
name=Kneippanlage
kneipp_water_cure:foot=yes

und der Becken zusäztlich so:

kneipp_water_cure=foot
natural=water

Alternativ nur einen Punkt wie folgt:

amenity=kneipp_water_cure
kneipp_water_cure:foot=yes
name=Kneippanlage

Die alte Modellierung bleibt erlaubt (ist aber nicht mehr empfohlen), da wird de Umriß des Fußbeckens so getaggt:

amenity=kneipp_water_cure
natural=water
name=Kneippanlage

Kneippanlage in natürlichem Bachlauf

Man braucht die Tretstelle im Bach nicht mehr unbedingt zeichnen. Man zeichnet der Umriss eines Geländes um die Wassertretstelle (wenn z.B. Bänke dafür in der Nähe stehen, gehören dann wohl auch im Umriss) und taggt es so:

amenity=kneipp_water_cure
kneipp_water_cure:foot=yes
name=Wassertretanlage␣Birkenwerder

Die Wassertretstelle kann dazu noch als Punkt im Bach getaggt werden:

kneipp_water_cure=foot

Wenn man doch die Tretstelle als Fläche zeichnet, dann sollte die Breite vom Bach auch getaggt werden:

waterway=stream
width=5

(oder alternativ mit einer Fläche als "waterway=riverbank")

Kneippanlage bestehend aus einem Armbecken

Man setzt einen Punkt auf das Becken und taggt es so:

amenity=kneipp_water_cure
kneipp_water_cure:foot=no
kneipp_water_cure:arm=yes
name=...

"kneipp_water_cure:foot=no" habe ich gelassen, um klar zu machen, dass es nur einen Armbecken gibt. Vielleicht könnte man aber sogar drauf verzichten.

Kneippanlage aus einem Fußbecken mit integriertem Armbecken

Der Umriss des Geländes wird so getaggt:

amenity=kneipp_water_cure
kneipp_water_cure:foot=yes
kneipp_water_cure:arm=yes
name=...

Und wenn es genauer sein muss, wird den Umriss des Fußbeckens so getaggt:

kneipp_water_cure=foot
natural=water

Für den Armbecken tagt man einen Punkt des Fußbecken-Umrisses wie folgt:

kneipp_water_cure=arm

Die Lösung gefällt mir. Ich habe den Proposal dann dementsprechend angepasst. Ich werde auch mal eine neuen Ankündigung auf der Tagging-Mailinglist posten.

JIDB wrote:

Die Lösung gefällt mir. Ich habe den Proposal dann dementsprechend angepasst. Ich werde auch mal eine neuen Ankündigung auf der Tagging-Mailinglist posten.

Mir auch - viel Erfolg!!!

Die Wahl ist jetzt geöffnet! Bitte auf der englischen Version vom Proposal wählen:
https://wiki.openstreetmap.org/wiki/Pro … water_cure

Vielleicht könnte man noch fee=* ergänzen. Manchmal befinden sie sich innerhalb von Anlagen, wo man Eintritt bezahlt.

Stimmt, aber für die Wahl spielt es keine Rolle und fee ist schon im aktuellen Stand von kneipp_water_cure erwähnt. Wenn der Proposal angenommen wird, wird es dann mit dem aktuellen Stand zusammengefasst.

Das Proposal wurde angenommen! Herzlichen Glückwunsch!

Tatsächlich. Ich dachte, es bleibt knapp bei der Mindestanzahl an Stimmen, aber es ist in den letzten Tagen sogar etwas mehr geworden! Jetzt hoffe ich, dass ich noch die Zeit zum Aufräumen finde, bevor ich im Urlaub fahre. Mal sehen, sonst wird es halt noch etwas warten.