Overpass query zu subarea members von boundary Relationen

Ich versuche vergeblich für folgende Aufgabe eine overpass query zu basteln:
In area[name=“Kasaragod”] ->.district;
Dort gibt es eine Relation mit admin_level=5 (=Kasaragod District).
Weiter gibt es darin die folgenden Verwaltungsebenen:
admin_level=6 : subdistrict
admin_level=8 : panchayat
admin_level=10 : ward
Alles ist mit boundary-Relationen gemappt.
Die Relationen mit admin_level=5,6,8 haben jeweils die Relationen der nächsttieferen Ebene als subarea members.
Ich hätte gerne eine CSV-Liste mit je Zeile
name des subdistricts
name des panchayats
name des wards
Relation-ID des wards

Ich hoffe die Erläuterung ist genau genug und jemand kann mir helfen.

http://overpass-turbo.eu/s/17jw liefert die Informationen, aber nicht in einer Zeile.
Mit einem kleinen python/perl Skript ist das aber hinzukriegen, wahrscheinlich auch in Excel.

Danke
Habe es ausprobiert und bekomme folgende Fehlermeldung:

Request rejected. (e.g. server not found, request blocked by browser addon, request redirected, internal server errors, etc.)

Error-Code: error (0)

Was mag das bedeuten?

Hab es gerade noch 2xausprobiert (1x meine original-Version, 1x den Link), bei mir läuft es (Firefox, Win10).
Die Fehlermeldungen sagen mir nichts.

Jetzt läufts auch bei mir!:slight_smile:
Warum auch immer
Du verwendest aber nicht die subarea member Angaben.

Sie wünschen, wir spielen: http://overpass-turbo.eu/s/17jG
Ist aber nicht so vollständig wie zuvor.

Nachtrag: in obiger Abfrage ist noch ein out zu viel drin,
hier die korrigierte Version: http://overpass-turbo.eu/s/17jH

Ich habe es nun mit der folgenden Abfrage probiert:
https://overpass-turbo.eu/s/18qx

Das müsste so funktionieren, aber ich erhalte stets einen Abbruch (dauert wohl zu lange).
Im benannten boundaryarea haben alle level=5,6,8 Relationen die entsprechenden subarea-Relationen als members. Es wäre doch vorteilhaft, diese Informationen abzufragen.
Nur ich schaffe es nicht, eine entsprechende Abfrage zu erstellen.

Also einen Abbruch sehe ich da nicht, die Query liefert einfach keine Daten. Das scheitert offenbar schon an: rel(area.lev6)[admin_level=8];

Ohne lev10.set(t[“::ID”]); am Schluss habe ich durchaus 775 Zeilen Output gehabt. Jetzt geht nichts mehr. Ich soll meinem IP-Status prüfen!!

fx99 hatte übrigens in Beitrag #6 schon gezeigt, wie das mit den subarea members funktioniert. Ich kenne die Datenkonstallation gerade nicht gut genug, vom Ansatz her sollte das aber so funktionieren.

/ Ich soll meinem IP-Status prüfen!!

Das bedeutet nichts anderes als dass das Quota für deine Anfrage gerade ausgeschöpft ist. Einfach etwas warten oder zu einem anderen Server wechseln.

In dem genannten District sind alle Relationen fehlerfrei. Ich habe die Abfrage von f99 probiert. Die Ausgabe ist fehlerhaft.

Also das lev10.set(t[“::ID”]) wird so nicht funktionieren, da es nach einem Tag mit dem key “::ID” sucht, was es aber nicht gibt. Richtig wäre hier: lev10.set(id())

Als Abfrage mit den subareas empfehle ich: http://overpass-turbo.eu/s/18ri

Bitte genau beschreiben, was funktioniert oder nicht funktioniert. “Die Ausgabe ist fehlerhaft” ist für die Fehlersuche denkbar ungünstig.

Fehlerbeschreibung:

  1. die level10-Namen existieren in Kasaragod und ihre Relation-ID sind richtig
  2. die level8 und level6 Namen existieren in Kasaragod
  3. ich habe erwartet, dass der level10 Bereich in dem level8-Bereich der Zeile liegt und genauso level8 in level6; leider sind die zugeordneten level8 und level6-Namen alle komplett falsch

Ich kann auch kein System in dieser seltsamen Ergebnisausgabe sehen.

Trotzdem : Vielen Dank für die versuchte Hilfe.

Danke für die schnelle Rückmeldung. Da ist also offenbar noch irgendwo ein Bug drin, mal schauen…

Verständnisfrage:

https://www.openstreetmap.org/relation/2018248 enthält Manjeswaram (https://www.openstreetmap.org/relation/11299739) als Admin Level 6
Manjeswaram enthält Puthige (https://www.openstreetmap.org/relation/11299816) als Admin Level 8
Puthige enhält Urumi (https://www.openstreetmap.org/relation/12498787) als Admin Level 10

Genau das steht so oben in der Ausgabe der Query in der ersten Zeile.

Wir betrachten momentan nur die Zuordnungen über die Relations-Member mit der Rolle “subarea”, sonst nichts.

Hosdurg (https://www.openstreetmap.org/relation/10121280) dagegen taucht in der Liste nicht auf, da hier keine subareas-Member in der Relation enthalten sind. Gleiches dürfte auch für alle anderen Relationen gelten, wo nicht durchgängig alle Admin-Level vorhanden sind. Die Existenz von Admin Level 6, 8 und 10 sind aber zwingend erforderlich für die Ausgabe in der Query.