amenity=kneipp_water_cure feiner modellieren

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

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.

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.

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ß