You are not logged in.

#1 2015-12-15 23:01:59

JIDB
Member
Registered: 2015-12-15
Posts: 89

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:T … 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_t … 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.

Offline

#2 2015-12-16 10:06:23

ChristianSW
Member
Registered: 2015-02-23
Posts: 491

Re: 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 ;-)

Last edited by ChristianSW (2015-12-16 10:11:04)


Viele Grüße, Christian

Offline

#3 2015-12-16 23:25:06

JIDB
Member
Registered: 2015-12-15
Posts: 89

Re: amenity=kneipp_water_cure feiner modellieren

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.

Offline

#4 2015-12-17 09:41:18

ChristianSW
Member
Registered: 2015-02-23
Posts: 491

Re: amenity=kneipp_water_cure feiner modellieren

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.

Last edited by ChristianSW (2015-12-17 13:19:59)


Viele Grüße, Christian

Offline

#5 2015-12-19 18:13:11

JIDB
Member
Registered: 2015-12-15
Posts: 89

Re: amenity=kneipp_water_cure feiner modellieren

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.

Offline

#6 2015-12-20 09:28:13

ChristianSW
Member
Registered: 2015-02-23
Posts: 491

Re: amenity=kneipp_water_cure feiner modellieren

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.

Last edited by ChristianSW (2015-12-20 10:12:39)


Viele Grüße, Christian

Offline

#7 2015-12-30 23:20:19

JIDB
Member
Registered: 2015-12-15
Posts: 89

Re: amenity=kneipp_water_cure feiner modellieren

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

Offline

#8 2015-12-30 23:23:29

JIDB
Member
Registered: 2015-12-15
Posts: 89

Re: amenity=kneipp_water_cure feiner modellieren

Ü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.

Offline

#9 2016-01-06 11:47:34

ChristianSW
Member
Registered: 2015-02-23
Posts: 491

Re: amenity=kneipp_water_cure feiner modellieren

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.


Viele Grüße, Christian

Offline

#10 2016-01-09 18:58:31

JIDB
Member
Registered: 2015-12-15
Posts: 89

Re: amenity=kneipp_water_cure feiner modellieren

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)

Last edited by JIDB (2016-01-18 21:31:45)

Offline

#11 2016-01-11 22:37:42

JIDB
Member
Registered: 2015-12-15
Posts: 89

Re: amenity=kneipp_water_cure feiner modellieren

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)

Offline

#12 2016-01-11 22:43:06

JIDB
Member
Registered: 2015-12-15
Posts: 89

Re: amenity=kneipp_water_cure feiner modellieren

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
120px-Kneippanlage_mit_Armbecken.jpg

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

Last edited by JIDB (2016-01-11 23:02:47)

Offline

#13 2016-01-11 22:59:43

JIDB
Member
Registered: 2015-12-15
Posts: 89

Re: amenity=kneipp_water_cure feiner modellieren

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.

Last edited by JIDB (2016-01-11 23:01:11)

Offline

#14 2016-01-12 09:17:20

ChristianSW
Member
Registered: 2015-02-23
Posts: 491

Re: amenity=kneipp_water_cure feiner modellieren

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...

Last edited by ChristianSW (2016-01-12 09:19:00)


Viele Grüße, Christian

Offline

#15 2016-01-17 21:49:28

JIDB
Member
Registered: 2015-12-15
Posts: 89

Re: amenity=kneipp_water_cure feiner modellieren

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.

Last edited by JIDB (2016-01-17 21:50:42)

Offline

#16 2016-01-18 09:02:23

ChristianSW
Member
Registered: 2015-02-23
Posts: 491

Re: amenity=kneipp_water_cure feiner modellieren

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

Last edited by ChristianSW (2016-01-18 09:05:03)


Viele Grüße, Christian

Offline

#17 2016-01-18 21:29:58

JIDB
Member
Registered: 2015-12-15
Posts: 89

Re: amenity=kneipp_water_cure feiner modellieren

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;

Offline

#18 2016-01-19 10:39:34

mmd
Member
Registered: 2010-11-06
Posts: 1,961

Re: amenity=kneipp_water_cure feiner modellieren

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.

Last edited by mmd (2016-01-19 15:02:56)

Offline

#19 2016-01-20 23:50:52

JIDB
Member
Registered: 2015-12-15
Posts: 89

Re: amenity=kneipp_water_cure feiner modellieren

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.

Offline

#20 2016-01-23 06:36:52

ChristianSW
Member
Registered: 2015-02-23
Posts: 491

Re: amenity=kneipp_water_cure feiner modellieren

@mmd Danke für den Hinweis!

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


Viele Grüße, Christian

Offline

#21 2016-01-28 22:31:01

JIDB
Member
Registered: 2015-12-15
Posts: 89

Re: amenity=kneipp_water_cure feiner modellieren

ChristianSW wrote:

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

Last edited by JIDB (2016-01-28 22:31:20)

Offline

#22 2016-02-02 22:34:02

JIDB
Member
Registered: 2015-12-15
Posts: 89

Re: amenity=kneipp_water_cure feiner modellieren

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.

Offline

#23 2016-02-03 11:57:01

ChristianSW
Member
Registered: 2015-02-23
Posts: 491

Re: amenity=kneipp_water_cure feiner modellieren

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...


Viele Grüße, Christian

Offline

#24 2016-03-08 23:17:19

JIDB
Member
Registered: 2015-12-15
Posts: 89

Re: amenity=kneipp_water_cure feiner modellieren

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.

Offline

#25 2016-03-09 08:41:51

ChristianSW
Member
Registered: 2015-02-23
Posts: 491

Re: amenity=kneipp_water_cure feiner modellieren

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.


Viele Grüße, Christian

Offline

Board footer

Powered by FluxBB