Hallo,
ich bastele an eine Abfrage zu zu Naturdenkmälern (klappt, ist nicht das Thema),
diese sind dem Lankreis, bzw. den einzelnen Städten und Gemeinden im Landkreis Kassel
http://www.openstreetmap.org/relation/62401
zugeordnet, daher möchte ich die Landkreis- und Gemeindegrenzen miteinblenden.
Im Prinzip klappt das, allerdings werden - nur an einigen Stellen(!) - weitere ways auf den Grenzen miteingeblendet.
Bei dieser Abfrage sind sie per MapCSS rot markiert. Per MapCSS könnte ich sie auch unsichtbar machen, ich würde aber lieber ganz auf diese ways verzichten:
http://overpass-turbo.eu/s/mLT
Meine Fragen:
a) Wie kann ich das erreichen - was mache ich falsch?
b) Was ist der Hintergrund für diese unterschiedlichen Datenstrukturen?
Moin,
im JOSM-Export ist auch bei den rot markierten Grenzen nur jeweils ein way enthalten.
Ich frage mich eher, warum die restlichen Gemeindegrenzen nicht auch rot maskiert werden, obwohl sie die Bedingung doch auch erfüllen - oder ?
Grüße, Georg
Um das Problem einzugrenzen habe ich die Abfrage mal vereinfacht auf die Binnengemeinde “Hofgeismar” im Landkreis:
http://www.openstreetmap.org/relation/1112226
Die Relation hat nur Außengrenzen mit admin_level=8 zu anderen admin_level=8 Gemeinden.
Die Abfrage zeigt Unterschiede (schwarz/rot):
http://overpass-turbo.eu/s/mMV
Wobei die Relation durchaus vollständig “da” ist, hier sind die “zusätzlichen ways” in der identischen Abfrage per “opacity: 0;” als unsichtbar maskiert:
http://overpass-turbo.eu/s/mMW
Schaut man sich das ganze mal rundherum an, stellt sich die Frage, warum
http://www.openstreetmap.org/way/52826453
anders behandelt wird als
http://www.openstreetmap.org/way/71138714
???
Bei den “zusätzlichen ways” gibt es zwei zusätzliche Tags:
FIXME=grober Eintrag
source=Wikipedea Landkreis .svg [sic]
Allerdings werden diese doch gar nicht abgefragt ???
Nur mal als Vergleich:
http://overpass-turbo.eu/s/mN8
holt sich alle enthaltenen Wege - wie ich es auch erwarten würde.
Aber Dein Problem bleibt ja trotzdem.
Edit:
Und so sieht es aus, wenn die nördliche und die südliche Grenze nur admin_level und boundary als Tag haben (sic!)
Nur das der südliche Grenzweg den admin_level=7 hat. 
Overpass behandelt die Wege tatsächlich abhängig von den Tag-Unterschieden zur Relation! 
@GeorgFausB: Du hast das Tagging eines der ways verändert (hätte ich auch als nächstes probiert)… und schon wird es uneinheitlich
@Harald Hartmann: Wenn ich das richtig verstehe löst Du die relation in ways auf - diese ways sind dann zwar einheitlich, für meinen Zweck aber nicht wirklich gut zu gebrauchen, ich habe das mal für mein Gebiet modifiziert:
http://overpass-turbo.eu/s/mNr
Probleme:
- Es ergibt sich ein Gewusel von clickbaren ways (Deren Informationen/Tags sind aber für meinen Zweck - als reinen Hintergrund - überflüssig)
- Kurze ways werden (je nach zoom-Level) per Kreis hervorgehoben (Gab es bei der Ausgabe als Relation nicht und kann ich auch gar nicht gebrauchen)
- Die Datenmenge scheint mir erheblich zugenommen zu haben (Daten, die ich nicht gebrauchen kann)
Deshalb wollte ich ja auf die einzelnen ways zugunsten der relation verzichten - und nicht umgekehrt.
Trotzdem Danke für Eure Bemühungen.
Hey Jo 
da die Admingrenzen ja wohl relativ stabil sind - oder sein sollten - möchte ich dir vorschlagen, die doch einfach aus meinen Boundaries Map z.B. als JSON zu exportiern. Lokale JSON-Dateien kann man ja auch jederzeit als Layer einbinden.
bei Fragen einfach melden.
Gruss
walter
Das ist nett,
aber Ziel der Übung war/ist es die Grenzen zusammen mit der eigentlichen Abfrage, als Orientierungshilfe, darzustellen.
Grüße
Für wen? Anwender sollte doch nur das Ergebniss (Übersichtkarte) interessieren.
Nun denn, war ja nur ein Angebot.
Gruss
walter
Ad 1: overpass turbo hat nur einen einzigen Layer, d.h. das Konzept “reiner Hintergrund” gibt es so nicht. Angezeigte Wege sind immer klickbar.
Ad 2: das kann man unter “Einstellungen → Karte → Kurze Wege als Knoten darstellen” anpassen
Ad 3: Mit out geom; ließe sich die Datenmenge halbieren: http://overpass-turbo.eu/s/mPA
Moin,
natürlich gibt es verschiedene Wege, wie man die Ausgabe vereinheitlichen kann.
Das Grundproblem bleibt aber:
Die Abfrage nach der Relation holt sich
- sowohl den Relationsumring mit allen nodes
- sowie zusätzlich alle ways, deren tags sich im admin_level der Relation unterscheiden oder andere zusätzliche tags enthalten
Mein ursprünglicher Gedanke war ja, dass die Relation nur auf die Wege verweist und deshalb alle ways holen müsste.
Und wenn alle ways nur den admin_level=8 und das boundary=administrative enthalten, dann wird ja auch nur der Relationsumring ohne zusätzliche ways geholt.
Und dieses unterschiedliche Verhalten von Overpass ist doch etwas fraglich - finde ich.
Grüße, Georg
Nein, die Abfrage nach der Relation liefert ausschließlich die Relation selbst, sowie Verweise auf die Member (ohne jedoch die Member selbst zurückzuliefern), sowie Tags:
<relation id="1115036">
<member type="way" ref="71390657" role="outer"/>
<member type="way" ref="71390662" role="outer"/>
<member type="way" ref="71390659" role="outer"/>
[...]
<member type="way" ref="252630719" role="outer"/>
<tag k="TMC:cid_58:tabcd_1:Class" v="Area"/>
<tag k="TMC:cid_58:tabcd_1:LCLversion" v="9.00"/>
<tag k="TMC:cid_58:tabcd_1:LocationCode" v="37236"/>
<tag k="admin_level" v="8"/>
<tag k="boundary" v="administrative"/>
[...]
</relation>
Siehe: http://overpass-turbo.eu/s/mQU
Erst durch das recurse wird die Relation aufgelöst und auch die Member selbst zurückgeliefert.
Alles in allem ist das aber eher ein Problem von MapCSS in overpass turbo - in eurer Style-Definition referenziert ihr ja ausschließlich die einzelnen Ways, ohne Bezug zu einer Relation. D.h. nur das Tagging der einzelnen Ways ist relevant für das Styling, die ursprüngliche Relation spielt keine Rolle.
Merkwürdig ist jedoch die folgende Darstellung: http://overpass-turbo.eu/s/mQX - vielleicht könnt ihr dafür mal ein Issue auf Github unter overpass turbo aufmachen?