Overpass API OR-Operator

Hallo zusammen,

ich würde in der Overpass-API gerne eine Abfrage mit OR-Operator machen, also etwa

[amenity=bus_station||highway=bus_stop||public_transport=*]

Leider führt diese Abfrage in der URL aber nicht zum gewünschten Ergebnis. Nötig ist die Abfrage, da nicht alle Haltestellen mit “public_transport” getaggt sind, sondern z.T. nur durch andere Tags erkennbar sind.

In der Dokumentation habe ich schon geschaut, aber nur den AND-Operator gefunden (durch einfaches aneinanderreihen “[amenity=…][public_transport=…]” …).

Vielen Dank schonmal

Johannes

Hallo!

ein “oder” gibt es so nicht, allerdings lässt sich das gleiche Ergebnis über ein union-Konstrukt erreichen: http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#union

Edit 19.1.2014: **Inzwischen gibt es dafür die Wizard in overpass turbo, dort lassen sich auch “oder”-Ausdrücke angeben, die automatisch in ein “union” übersetzt werden. **

Doku: http://wiki.openstreetmap.org/wiki/Overpass_turbo/Wizard

Wo wir gerade beim Thema Overpass-API sind, gibt es die Möglichkeit per Overpass-API zu zählen? Hintergrund ist die Frage, wieviel Gebäude gibt es in einem Bereich und wieviele davon haben Adressen / Hausnummern?

Edbert (EvanE)

Zumindest dreistufig sollte das klappen: also zunächst die Ergebnisdaten laden und dann lokal darauf z.B. zwei “grep” (nach building bzw. housenumber) anwenden.

Gruß Klaus

grep filtert allerdings zeilenweise, nicht OSM-Objekt-weise, ein einfaches … | grep building | grep housenumber wird also nicht reichen. Schon besser: mit z.B. osmfilter nach buildings filtern, dann im Filtrat die Gebäude und Hausnummern zählen - im einfachsten Fall tatsächlich mit (f)grep -c.

Ansonsten läßt sich ein “schlauer” Zähler (d.h. einer, der sich nicht von XML-Zeilen irreführen läßt, konfigurierbar und nebenbei auch noch deutlich schneller ist) natürlich mit Osmium in wenigen Zeilen C++ implementieren.

Dieser Ansatz ist zum scheitern verurteilte, wenn die Adressen nicht am Umriss erfasst sidn.

Wenn man OSM-Objekte zählen möchte, kommt man vielleicht mit http://wiki.openstreetmap.org/wiki/Osmconvert weiter.

Da kann man eine OSM-Datei als CSV-Datei ausgeben lassen. Hilft das?

Warum? In der XML-Fassung sucht du nach (addr:)housenumber und kümmerst dich nicht darum, ob die Adresse am Gebäude-Weg, an einem Eingangsknoten oder als freistehender Knoten erfasst ist.

Erst wenn man diese Dinge unterscheiden will, muss man mehr Aufwand reinstecken. Ebenso wenn man bestimmte Dinge (z.B. Garagen, Gartenhäuser, …) bei der Gebäude-Zählung nicht berücksichtigen will.
In dem Fall greift man wohl eher zu etwas wie sed, awk, Perl oder Phyton bis hin zu einer GIS-fähigen Datenbank.

Edbert (EvanE)

Ich biete mal dies (mit OR / Union um den Threadbezug wieder herzustellen):

perl opaQuery.pl “(way [‘building’] (51.8, 7.4, 52.1, 7.8); rel [‘building’] (51.8, 7.4, 52.1, 7.8)); out meta;”

grep -c “"building"” opaQuery.Response.xml
29283

grep -c “addr:housenumber” opaQuery.Response.xml
6967

Besser wäre jedoch diese Map-Query:

perl opaQuery.pl “[timeout:720]; (node (51.8, 7.4, 52.1, 7.8); <;); out meta;”

grep -c “"building"” opaQuery.Response.xml
29860

grep -c “addr:housenumber” opaQuery.Response.xml
11962

Gruß Klaus

in der turbo overpass vieleicht so:

//[amenity=bus_station||highway=bus_stop||public_transport=*]

(node({{bbox}})[“amenity”=“bus_station”]);
(.;node({{bbox}})[“highway”=“bus_stop”]);
(.
;node({{bbox}})[“public_transport”]);
out meta;

Hmmm, ich hätte vielleicht eher sowas erwartet:

(node({{bbox}})[“amenity”=“bus_station”];
node({{bbox}})[“highway”=“bus_stop”];
node({{bbox}})[“public_transport”];
);
out meta;

Den Unterschied zwischen beiden Varianten erkennt man ganz gut, wenn man beide Queries hiermit nach pretty url konvertiert. Das Beispiel oben erzeugt 1 Union bestehend aus 3 Statements, das von geodreieck4711 aus dem vorhergehenden Post 3 Unions, jeweils mit Zusammführen der bisherigen Ergebnismenge mit dem aktuellen Statement. Was besser ist weiß ich auch nicht.

Einsteigerfrage :confused:
Ich will mir alle turn:lanes*=* einer Gegend anschauen, um zu sehen, wo welche erfasst sind oder noch nicht.
Das:

zeigt mir nur ein Ergebnis für key=turn:lanes. Wie bekomme ich die Mehrfachabfrage hin?

Kurzform nur für Ways und mit “1” und “2” als Key, den Rest kriegst du vmtl selbst hin:

<osm-script output="json">
  <union>
    <query type="way">
      <has-kv k="1"/>
      <bbox-query {{bbox}}/>
    </query>
    <query type="way">
      <has-kv k="2"/>
      <bbox-query {{bbox}}/>
    </query>
  </union>
  <print mode="body"/>
  <recurse type="down"/>
  <print mode="skeleton"/>
</osm-script>

Funzt. :sunglasses: Danke. :slight_smile:

wenn Dir ein paar Tage alte Daten reichen
http://roads.osm4people.org/?zoom=9&lat=51.35754&lon=13.2702&layers=B0FFTFF

destination:lanes gehen noch nicht. Hatte ein Tippfehler beim filtern :confused:

Danke für das Angebot. Den QA kenne ich.
Wollte aber mal mit Over(s)pass aktuell probieren, damit ich sehe, was bei mir (oder da, wo ich mich rumtreibe) erledigt ist. Das Teil bietet ja sehr variable Möglichkeiten, weshalb ich mich da einschaffen will.

Siehe http://overpass-turbo.eu/s/1ew
dann keine Reparatur, rechts auf “Daten” schalten. Ich garantiere, dass im Hauptblock genau eine Id pro Zeile geschrieben wird.

Zeilen 6 bis 46 sind Nodes. Also gibt es 41 Punkte in Bonn, die die Tags “building” und “addr:housenumber” besitzen.

Zeilen 47 bis 23057 sind Ways. Also gibt es 23011 Wege in Bonn, die die Tags “building” und “addr:housenumber” besitzen.

Jetzt können wir noch “building”=“no” rauswerfen: http://overpass-turbo.eu/s/1ex
Dies ändert allerdings die Zahlen nicht.

Hey Danke.
Knoten mit building=* gibt es nur noch relative wenige, seit building=entrance durch entrance=main/yes ersetzt wurde. Eventuell kämen noch ein paar Relationen (MP für Gebäude) dazu, eine Erweiterung, die recht offensichtlich ist.

“out ids;” ist wohl das Stichwort, das die Auflistung zum einfachen Zählen ergibt. Vielen Dank, fürs austüfteln und ausprobieren.

Edbert (EvanE)

Hola,

Turbo zeigt das sogar unten rechts auf der Karte an:

geladen – Nodes: 40, Ways: 23013, Relations: 0
angezeigt – POIs: 0, Linien: 0, Polygone: 0