amenity=kneipp_water_cure feiner modellieren

Hallo an alle,

auf Anreiz von ChristianSW poste ich hier was zum dem Thema Kneippanlage/Wassertretbecken. Es gibt schon einen “Tag” dafür (http://wiki.openstreetmap.org/wiki/DE:Tag:amenity%3Dkneipp_water_cure), was aber verfeinert werden könnte.

Ein erstes Thema wären die Armbecken. “amenity=kneipp_water_cure” gilt nämlich für den Fußbecken, manchmal haben Kneippanlagen aber dazu noch ein Armbecken, das entweder im Fußbecken integriert ist oder getrennt ein paar Meter weiter liegt.

Auf der Diskussion-Seite (http://wiki.openstreetmap.org/wiki/DE_talk:Tag:amenity%3Dkneipp_water_cure) habe ich schon erwähnt, dass ich Armbecken momentan mit einem zusätzlichen Wert “kneipp_water_cure:arm=no/built-in/nearby” modelliere. 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?

PS: Da Kneippanlage anscheinend nur im deutschsprachigen Raum existieren, scheint es mir passend, dass Thema auf der Germany-Liste zu diskutieren.

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 :wink:

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,

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!

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

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.

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

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:Tag:amenity%3Dkneipp_water_cure#Gel.C3.A4nde_um_einem_Kneippbecken_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!

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
Bild der Anlage

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…

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/Relations/Proposed/Tag:site%3Dpiste

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.

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

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

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;

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/questions/47548/overpass-ql-return-all-parks-with-playgrounds-within-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.

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/User:ChristianSW/Werkstatt