Overpass query zu subarea members von boundary Relationen

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!:)
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:

Ausschnitt Query Ergebnis wrote:

Manjeswaram Puthige Urumi 6 12498787
Manjeswaram Puthige Kannur 9 12498806
Manjeswaram Puthige Edanadu 10 12498805
Manjeswaram Puthige Seethamgoli 8 12498807
Manjeswaram Puthige Mugu 5 12498788
Manjeswaram Puthige Badoor 4 12498789
Manjeswaram Puthige Chennikodi 1 12498792
Manjeswaram Puthige Arngadi Mugar 14 12498801
Manjeswaram Puthige Kathib Nagar 13 12498802
Manjeswaram Puthige Puthige 12 12498803
Manjeswaram Puthige Mukarikkanda 11 12498804
Manjeswaram Puthige Ujjampadavu 7 12498808
Manjeswaram Puthige Deradukka 3 12498790
Manjeswaram Puthige Dharmathadukka 2 12498791

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.