DE:Overpass API/Beispielsammlung
Servers status · Versions · Development · Technical design · Installation · XAPI compatibility layer · Public transport sketch lines · Anwendungen · Source code and issuesOverpass turbo · Wizard · Overpass turbo shortcuts · MapCSS stylesheets · Export to GeoJSON · mehr (Deutsch) · Development · Source code and issues · Web siteOverpass Ultra · Overpass Ultra extensions · MapLibre stylesheets ·mehr (Deutsch) · Source code and issues · Web site
Die Overpass API bietet vielfältige Suchmöglichkeiten. Alle diese Suchmöglichkeiten können sowohl auf einer Landkarte visualisiert werden als auch die Daten selbst abgefragt werden. Wir konzentrieren uns an dieser Stelle auf Beispiele zur die Visualisierung im Rahmen einer Landkarte. In diesem Fall können die unten angegebenen Abfragen in den Codeeditor von Overpass turbo eingetragen, ausgeführt und auf der Karte dargestellt werden werden.
Einführende Beispiele
Abfrage nach einem seltenen Tag
Nach einem einzelnen Tag z.B. name=Gielgen auf einer Node kann wie folgt gesucht werden:
node["name"="Gielgen"];
out skel;
Bitte zum Ausprobieren bei den Radiobuttons to OpenLayers auto-centered overlay auswählen und mit Convert die Abfrage starten. Durch diese Auswahl erhalten wir eine Landkarte, die automatisch um die gefundenen Objekte zentriert.
Die erste Zeile der Antwortseite zeigt den Status: steht dort Searching ..., so hat der Server noch keine Daten zurückgeliefert. Steht dort No results found., so enthält die Abfrage keine Nodes im Ergebnis (und ohne Nodes wird von OpenLayers nicht angezeigt). Steht dort Found ... features, so sind entsprechend viele Nodes und Ways gefunden worden.
Auf einem Way müssen wir, damit OpenLayers diesen anzeigen kann, auch die Nodes mitabfragen und verwenden dafür den Operator ">":
(way["name"="Gielgenstraße"];>;);
out skel;
Ebenso auf Relationen:
(rel["ref"="A 555"];>;);
out skel;
Man beachte, dass die hohe Zahl der Fundstellen sich nicht auf die Relation bezieht, sondern auf die Anzahl der im Rahmen der Relation gefundenen Ways.
Abfrage nach einem häufigen Tag
Falls das Tag nicht nur ein bestimmtes Objekt, sondern eine ganze Kategorie von Objekten beschreibt wie z.B. Briefkästen, so können wir diese auch als Layer einer Landkarte anzeigen lassen:
[timeout:5];
node["amenity"="post_box"];
out skel;
Dazu bitte bei den Radiobuttons to OpenLayers slippy overlay auswählen und mit Convert die Abfrage starten. Nun zeigt die Landkarte stets zunächst Mitteleuropa und lädt Objekte erst beim Hineinzoomen.
Ob man weit genug hereingezoomt hat, verrät wiederum die Statuszeile: Please zoom in to view data. bedeutet, dass in dieser Zoomstufe keine Daten geladen werden, bereits geladene Daten werden aber auch nicht gelöscht. Loading... erscheint, sobald der Browser in einer näheren Zoomstufe zu laden beginnt, und Displaying ... features zeigt an, das entsprechend viele Objekte gefunden worden sind.
Dabei spielt die erlaubte Zoom-Tiefe mit dem Parameter [timeout:5] zusammen: Die Slippy Map versucht maximal 5 Sekunden lang, Daten von der Overpass API zu bekommen. Setzt man den Wert größer, so reagiert das System träger und braucht mehr Speicher im Client, kann dafür aber schon weiter herausgezoomt die Features darstellen. Umgekehrt macht ein kleinerer Wert die Slippy Map noch dynamischer, erfordert aber weiteres Hineinzoomen.
Für die Skipisten:
[timeout:5];
(way["piste:type"="nordic"];>;);
out skel;
Und für Relationen, hier alle Autobahn-Routen:
[timeout:5];
(rel["network"="BAB"];>;);
out skel;
Abfrage nach einem häufigen Tag in einer Bounding Box
Möchte man sich bei der Suche nach einem häufigen Tag sowieso auf eine Bounding Box beschränken, so kann man dies wiederum bequemer mit to OpenLayers auto-centered overlay tun: man ergänzt dazu die Abfrage um einen Bounding-Box-Parameter:
node["amenity"="post_box"](50.6,7.0,50.8,7.3);
out skel;
trägt alle Briefkästen etwa in Bonn (Breitengrad zwischen 50.6 und 50.8, Längengrad zwischen 7.0 und 7.3) auf der Karte ein.
Etwas aufwendiger wird es für Schulen, weil diese sowohl Nodes als auch Ways sein können:
(
way["amenity"="school"](50.6,7.0,50.8,7.3);
>;
node["amenity"="school"](50.6,7.0,50.8,7.3);
);
out skel;
Wir sammeln hier drei verschiedene Suchen ein: 1. alle Wege, die das Tag amenity=school tragen. 2. alle von diesen Wegen referenzierten Nodes 3. alle Nodes, die das Tag amenity=school tragen.
OpenLayers sortiert beim Zusammensetzen des Layers 1. und 2. wieder zusammen, damit es die Wege zeichnen kann.
Das Ganze funktioniert auch für Relationen:
rel[ref=16](50.6,7.0,50.8,7.3);>;
out skel;
liefert die durch Bonn fahrende Stadtbahnlinie 16. Man erkennt hier auch gut, dass die Linie komplett geliefert wird, da zwar ein Teil der zugehörigen Wege außerhalb Bonns liegt, aber die Abfrage erst nach Relationen fragt, die die Bounding Box berühren und erst dann alle dazugehörigen Elemente anfordert. Mit
(
rel[ref=16](50.6,7.0,50.8,7.3);
node(r)(50.6,7.0,50.8,7.3)->.foo;
way(r)(50.6,7.0,50.8,7.3);
node(w);
);
out skel;
lässt sich das auch auf nur Wege aus der Bounding Box einschränken (wir fordert hier alle Subelemente einzeln an und beschränken die Bounding Box explizit für einzelne Nodes und für Ways).
Suche nach Objekten, die ein bestimmtes Merkmal haben, denen aber ein bestimmtes anderes Merkmal fehlt
Beispiel: zeige mir alle Nodes oder Wege oder areas, bei denen addr:city gesetzt ist, bei denen aber addr:postcode fehlt:
[out:json][timeout:25];
(
node["addr:street"][!"addr:postcode"]({{bbox}});
way["addr:street"][!"addr:postcode"]({{bbox}});
);
out skel;
Stand der OSM-Daten zu einem Stichtag
Folgende Abfrage zeigt die Daten (im Beispiel nur Nodes) in einem bestimmten Gebiet mit dem Stand 6. Mai 2014, 00:00 Uhr.
[date:"2014-05-06T00:00:00Z"];
( node({{bbox}}); <; >; );
out meta;
Beispiel:
[date:"2014-05-06T00:00:00Z"];
( node(40.02256072746494,32.924433499574654,40.023499404617674,32.92612597346305); <; >; );
out meta;
Straßenliste
Die folgende Abfrage eignet sich, um eine komplette Liste aller Straßennamen in einer Stadt, hier Troisdorf zusammenzustellen:
area[name="Troisdorf"];
way(area)[highway][name];
out;
Dies liefert alle Ways innerhalb dieser Gemeinde (sowie Ways, die die Gemeindegrenze schneiden - das lässt sich logisch nicht vermeiden, kommt aber selten vor) ohne zugehörige Nodes. Mit einem Kommando wie
grep '<tag k="name"' <troisdorf.osm | sort | uniq | awk '{ s=substr($0,22); print substr(s,1,index(s,"\"")-1); }' >straszenliste.txt
lässt sich daraus eine Straßenliste extrahieren.
Manchmal heißt die Stadtgrenze allerdings nicht einfach nur wie die Stadt, und das Ergebnis bleibt leer. So taucht z.B. bei Eckernförde der Zusatz "Landmasse" auf. Dagegen hilft es, einen regulären Ausdruck zu verwenden:
area[name~"Eckernförde"];
way(area)[highway][name];
out;
Noch einfacher gestaltet sich die Verarbeitung mit CSV als Ausgabeformat:
[out:csv(name;false)];
area[name="Troisdorf"];
way(area)[highway][name];
out;
Das Ergebnis dieser Abfrage muss nur noch mit sort liste.csv | uniq von Duplikaten befreit werden.
Suche nach Grenzrelationen mit boundary=administrative und admin_level=9 und de:amtlicher_gemeindeschluessel=XXXXXXXX
... denn eine Kombination mit admin_level=9 und AGS ist logisch falsch. Grenzrelationen für Gemeinden mit einem eigenen Gemeindeschlüssel müssen mindestens admim_level=8 oder niedriger haben.
- Ich habe "boundary=administrative" noch weggelassen, da wer den falschen Admin-Level setzt, vielleicht auch diesen Key nicht setzt.
rel[admin_level=9]["de:amtlicher_gemeindeschluessel"];out;
oder
rel[boundary=administrative][admin_level=9]["de:amtlicher_gemeindeschluessel"];out;
Abweichende addr:postcode=XXXXX Tags innerhalb einer Grenzrelation mit postalcode<>XXXXX
... wie müsste eine Abfrage aussehen, die alle Nodes oder Wege mit addr:postcode UNGLEICH XXXXX liefert, die INNERHALB einer Grenzrelation mit den Tags postal_code=XXXXX liegen?
- Das geht nur PLZ für PLZ. Z.B. für "42103":
area[postal_code="42103"]->.a;(node(area.a)["addr:postcode"]["addr:postcode"!="42103"];way(area.a)["addr:postcode"]["addr:postcode"!="42103"];);out;
oder allgemeiner mit einem bash-Skript:
i=42103; while [[ $i -le 42119 ]]; do { wget -O false_$i.osm "http://overpass-api.de/api/interpreter?data=area[postal_code=\"$i\"]->.a;(node(area.a)[\"addr:postcode\"][\"addr:postcode\"!=\"$i\"];way(area.a)[\"addr:postcode\"][\"addr:postcode\"!=\"$i\"];>;);out;"; i=$(($i + 1)); }; done
Verwendet man statt "out;" ein "out meta;", so kann man die entstehenden Dateien "false_XXXXX.osm" in JOSM zum Bearbeiten öffnen.
Mit einer geeigneten Bounding Box werden zudem die Abfragen deutlich schneller:
i=42103; while [[ $i -le 42119 ]]; do { wget -O false_$i.osm "http://overpass-api.de/api/interpreter?data=area[postal_code=\"$i\"]->.a;(node(51,7,51.5,7.5)(area.a)[\"addr:postcode\"][\"addr:postcode\"!=\"$i\"];way(51,7,51.5,7.5)(area.a)[\"addr:postcode\"][\"addr:postcode\"!=\"$i\"];>;);out meta;"; i=$(($i + 1)); }; done
Gebäude, durch die ein Weg führt, der nicht als tunnel oder covered getaggt wurde
Approximierte Abfrage von Gebäuden, durch die ein Weg ohne tunnel oder covered Tag führt. Da beim around Statement auch der Gebäudeumriss betrachtet wird, können false positives auftreten, wenn eine Straße direkt mit dem Gebäuderand verbunden ist.
Hinweis Diese Auswertung ist noch recht langsam, daher unbedingt zunächst nahe ans Zielgebiet heranzoomen.
way[!covered][!tunnel]
["highway"~"primary|secondary|tertiary|trunk|service|residential|primary_link|secondary_link|tertiary_link|unclassified"]["access"!~"no|private"][!area]
({{bbox}});
(way(around:0)["building"~"."];
node(w););
out meta;
Highway in der Nähe von Schulen mit unangemessenem maxspeed (seit 0.7.54)
// siehe: http://blattspinat.com/index.php/posts/tempo-50-vor-schulen
[out:json][timeout:800];
// Get all schools in current bounding box
( way[amenity=school]({{bbox}});
node[amenity=school]({{bbox}});
rel[amenity=school]({{bbox}});
)->.schools;
// find highway=* around schools with radius 50m, ignoring
// footway and paths. In addition, highways are relevant if they
// either
// (1) have no maxspeed tag at all
// (2) maxspeed tag indicates a value larger than 30 km/h
way(around.schools:50)[highway][highway!~"^(footway|path)$"]
(if: (is_number(t[maxspeed]) && t[maxspeed] > 30) ||
!is_tag(maxspeed) )->.streets;
// get schools in 50m distance for all identified relevant streets
( node.schools(around.streets:50);
way.schools(around.streets:50);
rel.schools(around.streets:50);
)->.matchingSchools;
// return results, schools and streets
(.matchingSchools; .streets;);
(._;>;);
out meta;
Bushaltestellen, die nicht in Relation enthalten sind
Zeige alle Bushaltestellennodes an, die nicht in einer bestimmten Relation sind.
// Selektiere das Stadtgebiet Bonn als Fläche
area[name="Bonn"];
// Selektiere alle Bushaltestellen in Bonn in die Variable 'alle'
node(area)[highway=bus_stop]->.alle;
// Selektiere alle Relationen, die eine dieser Nodes als Member haben,
// dann wieder alle deren Node-Mitglieder
rel(bn.alle);
node(r);
// Bilde aus beiden Mengen die Differenz
( .alle; - ._; );
// Gib das Resultat aus
out meta;
// Variante für Zeile 9 / 10:
// Nur Relationen, die ein bestimmtes Tagging haben
// rel[route=bus](bn.alle);
(via talk-de, Dank an Roland)
Bus-Relationen, die nicht Teil einer Master-Relation sind
Frage: Ich möchte herausfinden, welche Bus-Relationen (route=bus) in einem Gebiet nicht Mitglied einer Master-Relation (route_master=bus) sind. Wie bekomme ich mit overpass heraus, ob eine Relation (nicht) Kind einer Master-Relation ist?
rel({{bbox}})[route=bus]->.all;
rel[route_master=bus](br.all);
rel[route=bus](r);
( .all; - ._; );
out;
Erklärung je Zeile:
- Ermittle alle Relationen im aktuellen Kartenfenster, die vom Typ route=bus sind, speichere das Ergebnis nach .all
- Ermittle alle Parent-Relationen von .all, die vom Typ route_master=bus sind
- Ermittle aus dieser Liste von route_master-Relationen wieder alle Child-Relationen vom Typ route=bus. Dies sind nun alles Routen, die Teil eines Masters sind.
- Bilde die Differenz aus .all und dem Ergebnis aus 3. (ermittelt also alle Routen, die nicht Teil der Menge aller Routen, die einen Master-Parent haben, sind)
n angrenzende Wege
Das folgende Beispiel zeigt, wie man zum OSM Weg 111435507 die nächsten 5 angrezenden Wege ermitteln kann. Da around mit Radius 0 nur nicht nur verbundene, sondern auch schneidende Wege ermittelt, müssen letztere in einem Nachbearbeitungsschritt wieder herausgefiltert werden.
[bbox:{{bbox}}];
way(111435507);
(way(around:0)[highway~"."][highway!~"path|track|cycleway|footway"];(._;>;))->.a;
(way(around:0)[highway~"."][highway!~"path|track|cycleway|footway"];(._;>;))->.b;
(way(around:0)[highway~"."][highway!~"path|track|cycleway|footway"];(._;>;))->.c;
(way(around:0)[highway~"."][highway!~"path|track|cycleway|footway"];(._;>;))->.d;
(way(around:0)[highway~"."][highway!~"path|track|cycleway|footway"];(._;>;))->.e;
(.a;.b;.c;.d;.e;);out;
Im Beispiel werden nur Ways mit einem highway Tag (ohne path, track, cycleway und footway) berücksichtigt. [bbox:...] schränkt das Ergebnis global auf einen bestimmten Suchbereich ein. Anderenfalls könnten sehr lange Wege dafür sorgen, dass unkontrolliert Daten von weit entfernten Bereichen mit in die Ergebnismenge aufgenommen würden. Mmd (talk) 18:31, 2 May 2014 (UTC)
Ausgewählte Datenkategorien editieren
Diese Anleitung ist inzwischen unter der eigenen Seite für Sparse Editing zu finden.
Finde Knoten/Wege mit einer bestimmten Rolle in Relation
Ermittle alle Nodes mit Rolle "label" oder "admin_centre":
rel({{bbox}})->.relations;
( node(r.relations:"label");
node(r.relations:"admin_centre");
);
out;
Ermittle alle "inner" Wege, also Wege, die in einer Relation die Rolle "inner" haben:
rel({{bbox}});(way(r:"inner");>;);out;
Ermittle alle Knoten und Wege mit Rolle "via":
rel({{bbox}})->.relations;
(
node(r.relations:"via");
way(r.relations:"via");>;
);out;
Geocoding Informationen zu POIs hinzufügen
Ziel der folgenden Overpass API-Abfrage ist es, zu bestimmten Informationstafeln in Tschechien jeweils die zugehörigen Admin-Level herauszufinden, d.h. in welchen Kreisen/Städten diese Infotafeln stehen.
area[name="Česko"];
node[information="guidepost"][ele~"^2..$"](area)->.posts;
// Die Einschränkung auf "ele"-Tags dient nur der Begrenzung der
// Ergebnismenge für diesen Test, kann aber entfernt werden
foreach.posts(
out;
is_in;
area._[admin_level~"[46]"];
// Admin-Level 4 bzw. 6 sind willkürlich gewählt und können
// durch eigene Kriterien ersetzt werden.
out ids;
);
// Area-Details ausgeben
.posts is_in;
area._[admin_level~"[46]"];
out;
Im Ergebnis wird jeweils ein Knoten (POI) ausgegeben, gefolgt von einer Liste an "Area-Ids", in denen dieser Knoten vorkommt. Dabei wird aus Performancegründen darauf verzichtet, die vollständingen Details zu einer Area pro Knoten auszugeben. Stattdessen wird nur die ID der Area ausgegeben. Erst nachdem alle POIs ausgegeben wurden, werden auch die vollständingen Area-Details innerhalb derselben Ausgabe zurückgeliefert.
Folgende Ausgabe zeigt beispielhaft das Format. Zunächst werden Details zu einem POI (Knoten 691566183) ausgegeben. Anschließend folgen zwei Area-Ids in denen dieser POI vorkommt. Anschließend wird der nächste POI (Knoten 691566191) ausgegeben, wiederum gefolgt von zwei Area-Ids (3600435511 bzw. 3600442466) als Verweis auf die nachfolgenden Area-Details.
<?xml version="1.0" encoding="UTF-8"?>
<osm version="0.6" generator="Overpass API">
<node id="691566183" lat="49.7982193" lon="13.4686623">
<tag k="ele" v="295"/>
<tag k="information" v="guidepost"/>
<tag k="name" v="Dolanský most (pravý břeh)"/>
<tag k="tourism" v="information"/>
</node>
<area id="3600435511"/>
<area id="3600442466"/>
<node id="691566191" lat="49.8003120" lon="13.4679726">
<tag k="ele" v="295"/>
<tag k="information" v="guidepost"/>
<tag k="name" v="Dolanský most (levý břeh)"/>
<tag k="tourism" v="information"/>
</node>
<area id="3600435511"/>
<area id="3600442466"/>
[...]
<area id="3600435511">
<tag k="admin_level" v="4"/>
<tag k="boundary" v="administrative"/>
<tag k="name" v="Jihozápad"/>
<tag k="name:cs" v="Jihozápad"/>
<tag k="name:de" v="Südwesten"/>
<tag k="population" v="1209298"/>
<tag k="ref" v="CZ03"/>
<tag k="ref:NUTS" v="CZ03"/>
<tag k="source" v="cuzk:ruian"/>
<tag k="source:population" v="csu:uir-zsj"/>
<tag k="type" v="boundary"/>
<tag k="wikipedia" v="cs:NUTS Jihozápad"/>
</area>
<area id="3600442466">
<tag k="ISO3166-2" v="CZ-PL"/>
<tag k="admin_level" v="6"/>
<tag k="boundary" v="administrative"/>
<tag k="name" v="Plzeňský kraj"/>
<tag k="name:cs" v="Plzeňský kraj"/>
<tag k="name:de" v="Region Pilsen"/>
<tag k="name:ru" v="Пльзенский край"/>
<tag k="population" v="572687"/>
<tag k="ref" v="PL"/>
<tag k="ref:NUTS" v="CZ032"/>
<tag k="source" v="cuzk:ruian"/>
<tag k="source:population" v="csu:uir-zsj"/>
<tag k="type" v="boundary"/>
<tag k="wikipedia" v="cs:Plzeňský kraj"/>
</area>
Quelle, Dank an Roland
Georeference details zu village nodes hinzufügen (seit 0.7.54)
Since 0.7.54, it is also possible to generate is_in details for place=village nodes in the current bbox on-the-fly:
node({{bbox}})[place=village];
foreach(
is_in->.a;
area.a[name][boundary=administrative][admin_level~"^[2-8]$"] -> .a;
convert node ::=::,
::id = id(),
is_in=a.set("{" + t[admin_level] + ":" + t[name] + "}");
out;
);
The resulting XML includes a new is_in tag, which lists all boundary=administrative with admin_level from 2..8 and a name, sorted by increasing admin_level:
<node id="1724711941">
<tag k="name" v="Steinklingen"/>
<tag k="place" v="village"/>
<tag k="is_in" v="{2:Deutschland};{4:Baden-Württemberg};{5:Regierungsbezirk Karlsruhe};{6:Rhein-Neckar-Kreis};{8:Weinheim}"/>
</node>
Unfortunately, any nodes which have been enhanced via convert don't include any lat/lon details at this time.
POIs mit Webseite aber fehlenden Öffnungszeiten
Die folgenden Abfrage ermitteln Einrichtungen und Geschäfte, bei denen eine Webseite eingetragen wurde, jedoch die Öffnungszeiten fehlen. Es sollte zuerst die erste Abfrage probiert werden, da diese eine höhere Erfolgswahrscheinlichkeit für das vorfinden von Öffnungszeiten auf der Webseite hat. Falls diese keine Ergebnisse liefert, kann die zweite Anfrage probiert werden.
/* See:
* https://www.openstreetmap.org/user/ypid/diary/23719
* https://wiki.openstreetmap.org/wiki/DE:Overpass_API/Beispielsammlung#POIs_mit_Webseite_aber_fehlenden_.C3.96ffnungszeiten
* Red circle: No opening_hours and no website available.
* Yellow circle: No opening_hours but with website available.
* Roter Kreis: Keine Öffnungszeiten und keine Webseite vorhanden.
* Gelber Kreis: Keine Öffnungszeiten aber eine Webseite vorhanden.
*/
[out:xml][bbox:{{bbox}}];
way/*[~"^(.*website.*|opening_hours:url)$"~"."]*/["opening_hours"!~"."] ->.w;
node/*[~"^(.*website.*|opening_hours:url)$"~"."]*/["opening_hours"!~"."] ->.n;
(
way.w[~"^(amenity)$"~"(bar|cafe|biergarten|pub|car_rental|car_sharing|car_wash|dentist|dentist|pharmacy|doctors|bank|atm|fuel|ice_cream|restaurant|fast_food|brothel|stripclub|swingerclub|casino|theatre|nightclub|planetarium|gym|post_office|register_office|sauna)"] ->.a; .a >;
way.w[~"^(shop)$"~"."];
node.n[~"^(amenity)$"~"(bar|cafe|biergarten|pub|car_rental|car_sharing|car_wash|dentist|dentist|pharmacy|doctors|bank|atm|fuel|ice_cream|restaurant|fast_food|brothel|stripclub|swingerclub|casino|theatre|nightclub|planetarium|gym|post_office|register_office|sauna)"];
node.n[~"^(shop)$"~"."];
);
out meta center;
/* Don‘t show entrance=yes as circle. */
{{style:
node[amenity][opening_hours!=.],
node[shop][opening_hours!=.],
way[amenity][opening_hours!=.],
way[shop][opening_hours!=.]
{ color:yellow; fill-color:yellow }
node[amenity][opening_hours!=.][!opening_hours:url][!website][!contact:website],
node[shop][opening_hours!=.][!opening_hours:url][!website][!contact:website],
way[amenity][opening_hours!=.][!opening_hours:url][!website][!contact:website],
way[shop][opening_hours!=.][!opening_hours:url][!website][!contact:website]
{ color:red; fill-color:red }
/* Don’t query for all opening_hours … Would be too much */
/*
node[opening_hours],
way[opening_hours]
{ color:green; fill-color:green; }
*/
}}
/* See: https://www.openstreetmap.org/user/ypid/diary/23719 */
[out:xml][bbox:{{bbox}}];
(
way[~"^(.*website.*|opening_hours:url)$"~"."]
[~"^(amenity|shop)$"~"."]
["opening_hours"!~"."]
["amenity"!~"^(social_facility|bus_station|grit_bin|clock|hunting_stand|telephone|vending_machine|waste_disposal|fire_station|school|college|kindergarten|parking|place_of_worship|bbq|bench)$"]
[".*fixme.*"!~"."];
>;
node[~"^(.*website.*|opening_hours:url)$"~"."]
[~"^(amenity|shop)$"~"."]
["opening_hours"!~"."]
["amenity"!~"^(social_facility|bus_station|grit_bin|clock|hunting_stand|telephone|vending_machine|waste_disposal|fire_station|school|college|kindergarten|parking|place_of_worship|bbq|bench)$"]
[".*fixme.*"!~"."];
);
out meta;
Kreise ohne fire station anzeigen
Die folgende Query zeigt alle Kreise in Schleswig-Holstein an, in denen kein amenity=fire_station gemappt wurde. Siehe Forum Thread für Details.
Verwendet einen etwas kruden workaround für "area in area" (siehe Github Issue #45): in der "boundaryarea" Schleswig-Holstein werden alle Knoten ermittelt, die mindestens 1 Tag besitzen und nicht Teil eines Weges sind. Für diese Knoten werden alle 'areas' mit admin_level = 8 ermittelt. Auf der anderen Seite werden auch für alle amenity=fire_station alle areas mit admin_level = 8 ermittelt. Die Differenz dieser beiden Mengen ergibt die Areas, in denen keine fire_station gemappt wurde. Für die Ausgabe werden für alle ermittelten Areas die zugehörige Relation mit Weg/Knoten aufbereitet.
[timeout:3600];
// just working on level 4
area[admin_level=4]["name"="Schleswig-Holstein"]->.boundaryarea;
// get all fire_stations
( node(area.boundaryarea)["amenity"="fire_station"];
way(area.boundaryarea)["amenity"="fire_station"];>;) ->.a;
// >>> Also show existing fire stations? uncomment the following line! <<<
//.a out;
// <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
// get all areas that contain fire_stations and
// select only areas with admin_level=8
.a is_in -> .b;
area.b[admin_level=8] -> .bf;
// get all areas with admin_level=8,
// assuming there's at least one node with any tags
node(area.boundaryarea)[~"."~"."] ->.all;
// now find out all nodes with any tags that are not part of any way
way(bn.all);node(w)[~"."~"."]->.partofway;
(.all - .partofway) -> .single_nodes;
.single_nodes is_in -> .bll;
area.bll[admin_level=8] -> .bllf;
// calculate difference
(.bllf - .bf ) ;
// show areas as relation on map
rel(pivot); (._;>;); out;
Dank an fx99
Nachfolgende Alternative gibt Kreise in Schleswig-Holstein ohne amenity=fire_station aus. Dabei ist zu beachten, dass die Umwandlung von Relationen zu Areas (uns damit Area in Area) in Overpass API 0.7.51 noch experimentell ist, d.h. Bugs und spätere Änderungen an der Funktion sind möglich. Die Ausgabe erfolgt im CSV-Format mit der OSM ID der Relation, dem amtlichen Gemeindeschlüssel und dem Namen der Relation.
// Ausgabe im CSV Format
[out:csv(::id, "de:amtlicher_gemeindeschluessel", name)];
area[admin_level=4]["name"="Schleswig-Holstein"][boundary=administrative]->.boundaryarea;
// Alle bounding areas mit level 8 in Schleswig-Holstein
rel(area.boundaryarea)[admin_level=8];
// aus den Relationen wieder Areas machen (noch experimentell in 0.7.51)
map_to_area -> .all_level_8_areas;
// Alle amenity=fire_station in Schleswig-Holstein suchen
( node(area.boundaryarea)["amenity"="fire_station"];
way(area.boundaryarea)["amenity"="fire_station"];>;);
// In welchen boundary areas mit level 8 kommen die vor?
is_in;
area._[admin_level=8] -> .level_8_areas_with_firestation;
// Alle level 8 bounding areas ohne die
// Areas mit fire station ermitteln
(.all_level_8_areas - .level_8_areas_with_firestation ) ;
// Relation ermitteln und ausgeben
rel(pivot);
out geom;
Ermittle Knoten, die zu 2 verschiedenen Ways gehören
Frage: wie kann man mit Overpass Turbo nodes finden, die Teil von zwei ways mit bestimmten Eigenschaften sind?
Zum Beispiel:
way["building"="yes"]({{bbox}});
node(w);
liefert Nodes, die teil eines Gebäudes sind.
way["highway"="tertiary"]({{bbox}});
node(w);
Und das findet nodes in tertiary-Straßen.
Wie kann ich jetzt das kombinieren, dass die Nodes die beide Bedingungen erfüllen ausgegeben werden?
Einfache Variante
way["building"="yes"]({{bbox}});
node(w)->.b;
way["highway"="tertiary"]({{bbox}});
node(w)->.t;
node.b.t; // bildet die Schnittmenge der beiden Mengen .b und .t
out;
Komplizierte Variante
Folgender Ansatz ermittelt A ∩ B als (A ∪ B) \ (A \ B) \ (B \ A)
way["building"="yes"]({{bbox}});
node(w)->.b;
way["highway"="tertiary"]({{bbox}});
node(w)->.t;
(.b; .t;)->.alles;
(.b; - .t;)->.b_ohne_t;
(.t; - .b;)->.t_ohne_b;
((.alles; - .b_ohne_t;); - .t_ohne_b;);
out;
Ermittle nur Knoten, die nicht zu einem Way gehören
Ausgangsfrage: Ermittle alle "Ortseingangsschilder", welche alleinstehend gemappt wurden, also nicht Teil bzw. Knoten einer Straße sind.
[bbox:{{bbox}}];
// zunächst alle Punkte (Nodes) mit traffic_sign=city_limit ermitteln
node["traffic_sign"="city_limit"] -> .allnodes;
// zu diesen Punkten alle Straßen (Ways mit highway) ermitteln
way[highway](bn.allnodes);
// zu diesen Punkten alle Straßen (Ways mit highway) ermitteln
node(w)["traffic_sign"="city_limit"] -> .waynodes;
// und aus diesem Ergebnis wieder nur Punkte (Nodes) mit traffic_sign=city_limit filtern
(.allnodes; - .waynodes;);
// um diese von allen Punkten abzuziehen, übrig bleiben nur Punkte, die nicht Teil einer Straße waren
out;
Erweiterung: In manchen Gegenden wurde traffic_sign=city_limit als Knoten in der Straße und zusätzlich noch neben der Straße gemappt. Um diese false/positives annähernd zu filtern, musste die Abfrage noch um ein around (Suchradius frei wählbar) ergänzt werden:
[bbox:{{bbox}}];
node["traffic_sign"="city_limit"] -> .allnodes;
way[highway](bn.allnodes);
node(w)["traffic_sign"="city_limit"];
node(around:15)["traffic_sign"="city_limit"] -> .waynodesandfriends;
(.allnodes; - .waynodesandfriends;);
out;
PS: Danke an mmd
Straßenkreuzung ermitteln
Die folgende Query ermittelt die Straßenkreuzeug der 6th Avenue und West 23rd Street (z.B. in New York):
[bbox:{{bbox}}];
way[highway][name="6th Avenue"];node(w)->.n1;
way[highway][name="West 23rd Street"];node(w)->.n2;
node.n1.n2;
out meta;
Vorausgesetzt wird, dass beide Straßen über einen gemeinsamen Knoten miteinander verbunden sind.
Gebäude mit entrance-Knoten
Ich suche in einem bestimmten Gebiet, definiert durch die Bounding Box, nach Gebäuden, auf deren Nodes Attribute eingetragen wurden, z.B. Gebäudeeingänge.
way[building]({{bbox}}) -> .buildings;
node(w.buildings)[entrance] -> .entrances;
way(bn.entrances)[building];
(._;>;);
out;
Ermittelt zunächst alle Gebäude in der aktuellen bbox, sucht danach in den Knoten der Gebäude nach einem Tag "entrance" und ermittelt für die gefundenden Knoten nochmals die Gebäude, in denen diese Knoten vorkommen.
Beliebige Tags auf dem Gebäudeumring finden mit Darstellung der Gebäude sowie der getaggten Knoten:
[bbox:{{bbox}}];
way[building];
(node(w)[~"."~"."];
way(bn)[building];);
out geom;
Apotheken je Kreis zählen
Das folgende Beispiel gibt die Zahl der Apotheken jeweils pro Area mit Regionalschlüssel 057* aus. Die Ausgabe erfolgt im CSV-Format.
/*
CSV-Format: in Overpass Turbo unter Export -> Rohdaten direkt von Overpass API öffnen: lädt Daten in LibreOffice, Felder sind durch "Tab" getrennt
*/
// CSV-Output: siehe http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#Output_Format_.28out.29
[out:csv(::type, "de:regionalschluessel", name,
::count, ::"count:nodes", ::"count:ways", ::"count:relations")];
//Alle areas mit Regionalschlüssel beginnend mit 057
area["de:regionalschluessel"~"^057.*"];
// In jeder Area Apotheken zählen
foreach->.regio(
// zunächst Details zur aktuellen Area ausgeben
.regio out;
// Alle Knoten, Wege und Relationen mit amenity=pharmacy in aktueller Area sammeln
( node(area.regio)[amenity=pharmacy];
way(area.regio)[amenity=pharmacy];
rel(area.regio)[amenity=pharmacy]);
// Elemente in aktueller Area zählen, noch experimentell in 0.7.51!
out count;
);
Doppelte Knoten finden
siehe https://help.openstreetmap.org/questions/39745/show-duplicated-nodes-via-overpass
Doppelte Knoten in der Nähe mit gleichem Tag finden
Findet nah beieinanderliegende Gipfel mit dem gleichen Namen:
node["natural"="peak"]({{bbox}})->.a;
foreach.a->.elem(
node.a(around.elem:50)
(if:is_tag("name")&&t["name"]==elem.u(t["name"]));
(._; - .elem;);
out meta;
);
Overpass Turbo Link (mit "date" zur Demo) Quelle
(Bahn-)Steige finden, die keiner Haltestellen-Relation angehören
Diese Relation findet alle Steige (public_transport=platform) in Deutschland, die sich nicht in einer Haltestellenrelation (public_transport=stop_area) befinden.
Da diese Abfrage für Maproulette erstellt wurde, ist eine zusätzliche Herausforderung, nur die wirklichen Steige ausgeben zu lassen, aber nicht die Knoten und sonstige Kinder, damit diese nicht auch als Tasks gewertet werden.
// Wähle eine Fläche mit dem namen und lege sie in "a" ab
area[name="Deutschland"]->.a;
// Wähle alle nodes, ways und relations innerhalb der Fläche von a
// die public_transport=platform haben und lege sie in "platforms" ab
nwr(area.a)[public_transport=platform]->.platforms;
// Wähle alle relationen innerhalb der Fläche von a, die public_transport=stop_area haben
rel(area.a)[public_transport=stop_area];
// Wähle alle nodes, ways und relations, die Mitglieder von den relationen sind, die gerade
// gewählt wurden und lege sie in "stop_rels_members" ab
nwr(r)->.stop_rels_members;
// subtrahiere von allen Steigen diejenigen, die in einer stop_area relation sind
(.platforms; - .stop_rels_members;);
// gib das gewählte aus, aber nur die Objekt-IDs und Tags, nicht die Mitglieder, sonst werden sie
// auch als Ergebnisse gewertet
out body center;
Overpass Turbo Link (liefert eine große Datenmenge zurück!)
Leere Relationen finden
Das folgende Beispiel ermittelt alle Admin-Relationen, d.h. mit type=multipolygon und admin_level=*, die keine Way-Mitglieder besitzen.
[timeout:900];
rel[type=multipolygon][admin_level]->.a;
way(r.a)->.b;
(.a-rel(bw.b););
out;
Admin-Relationen ohne Member vom Typ Node, Way oder Relation lassen sich so ermitteln:
[timeout:900];
rel[type=multipolygon][admin_level]->.a;
node(r.a)->.nodes;
way(r.a)->.ways;
rel(r.a)->.rels;
(.a; - (rel(bw.ways);rel(bn.nodes);rel(br.rels);););
out;
Nach Häufigkeit von Tags
Wege ohne Tags finden
OSM Inspector zeigt auf dem Tagging Layer u.a. Wege ohne Tags.
Diese Analyse lässt sich auch mit Overpass Turbo durchführen und die Ergebnisse gleich in JOSM weiterverarbeiten:
(way({{bbox}}); - way({{bbox}})[~"."~"."];)->.w1;
rel(bw.w1);way(r)->.w2;
(.w1; - .w2;);
(._; >;);
out meta;
Nodes mit mindestens 1 Tag finden
Die folgende Overpass QL-Abfrage liefert alle Knoten in der BBOX zurück, die mindestens ein Tag haben:
[bbox:{{bbox}}];node[~"."~"."];out meta;
Nodes mit genau einem Tag finden
Verbindet man den Differenz-Operator ("-") mit regulären Ausdrücken für Keys lassen sich Nodes ermitteln, die genau ein bestimmtes Tag haben. Leider unterstützt die Overpass API keine Perl kompatiblen regularäen Ausdrücke (PCRE), wodurch die richtige Abfrage doch recht komplex wird. Auf stackoverflow wird beschrieben, wie prinzipiell ein solcher regulärer Ausdruck aussehen kann.
Für dieses Beispiel wird daher ein vereinfachter Ansatz gewählt: es zunächst alle Buildings in der aktuellen BBOX ermittelt und von dieser Menge diejenigen Buildings ausgeschlossen, die ein Tag haben, das nicht mit dem Buchstaben "b" beginnt.
[bbox:{{bbox}}];
((
// Ermittelte alle Buildings
way[building=yes];
// und erferne davon...
-
// alle buildings, die ein Tag haben, welches nicht mit dem Buchstaben "b" beginnt
way[building=yes][~"^[^b].*$"~"."];
); >; );
out;
Mit PCRE-Unterstützung wäre die folgende Abfrage möglich, die nur Gebäude mit einem building-Tag und keinerlei weiteren Tags zurückliefert. Wird aktuell nicht von Overpass API unterstützt!
[bbox:{{bbox}}];
(
(way[building]; -
way[building][~"^(?!building).*$"~"."]; // noch nicht unterstützt, liefert Syntax-Fehler auf overpass-api.de
); -
way[building][~"^building.+$"~"."]; // Sonderlocke für building:use Tags
);
out geom;
Ab Overpass-Version 0.7.54 ist ein Zählen von tags möglich
way({{bbox}})[name](if:count_tags()==1);
out geom;
bestimmte Tag-Kombination zählen
für speziellere tag-Kombinationen reicht taginfo manchmal nicht aus. Dann kann man sich folgender Overpass-turbo-Abfrage bedienen. Ausgegeben werden: die Gesamtzahl, Zahl der Punkte, Zahl der Linien, Zahl de Relationen.
[out:csv(::count, ::"count:nodes", ::"count:ways", ::"count:relations")][timeout:45];
(
node["man_made"="pipeline"]["substance"];
way["man_made"="pipeline"]["substance"];
relation["man_made"="pipeline"]["substance"];
);
out count;
User für bestimmte Tag-Kombination ausgeben
Diese Abfrage dient dazu zu überprüfen, welcher User Objekte mit einer bestimmten tag-Kombination zuletzt bearbeitet hat. Es wird eine Tabelle ausgegeben. Im Beispiel mit den Spalten Type (Punkte, Linie, Relation), den Wert des Schlüssels "substance" und den Usernamen. Die Daten können mittels Export -> Rohdaten direkt von Overpass API heruntergeladen werden (tabulatorgetrennte Daten). Dateiendung (z.b. .txt) ergänzen und im Tabellenprogramm importieren um die Daten weiter zu untersuchen. Z.B. nach user sortieren.
[out:csv(::type,substance,::user)][timeout:45];
(
node["man_made"="pipeline"]["substance"];
way["man_made"="pipeline"]["substance"];
relation["man_made"="pipeline"]["substance"];
);
out meta;
QA rund um Straßen, Adressen und Hausnummern
Unnütze associatedStreet-Relationen ermitteln
Mit dem JOSM-Plugin "terracer" kann man Gebäude aufteilen um daraus Reihenhäuser zu erzeugen. In der Voreinstellung erzeugt dieses Plugin immer eine associatedStreet-Relation. Aber die so erzeugten Relationen sind Müll. Ein vorhandener Straßenname am zu trennenden Gebäude wird jedenfalls ignoriert, nur der im Dialog eingetragene Straßenname wird als name der Relation gesetzt. Der obligatorische Eintrag "street" fehlt bei dieser Relation. Heraus kommt eine Relation mit type=associatedStreet und ein paar Membern mit role "house".
Nun wäre es doch gut, diese Relationen herauszufinden und zu löschen.
— brogo, im dt. OSM Forum
Die Standardeinstellung wurde inzwischen geändert, es existieren jedoch immer noch viele dieser unnützen Relationen.
http://overpass-turbo.eu/s/7eV
/* Hier zunächst die Stadt/Region/etc. festlegen */
{{nominatimArea:Berlin}}
(._; )->.area;
/* Alle associatedStreet-Relationen in dieser Stadt ermitteln */
rel[type=associatedStreet]
[name!~"."]
["addr:street"!~"."]
(area.area)->.allASRelations;
/* Ermittle alle associatedStreet-Relationen, in denen ways mit Rolle "street" vorkommen */
way(r.allASRelations:"street");
rel(bw:"street")[type=associatedStreet]->.relationsWithRoleStreet;
/* Wege mit leerer Rolle in aS-Relation */
way(r.allASRelations:"");
rel(bw:"")[type=associatedStreet]->.relationsWithEmptyRole;
/* alle rels mit nodes */
node(r.allASRelations);
rel(bn)[type=associatedStreet]->.relationsWithNode;
/* hinter rolle house steckt kein building */
way(r.allASRelations:"house")[building!~"."];
rel(bn)[type=associatedStreet]->.relationsWoHouseBuilding;
/* Von Gesamtmenge aller aS-Relationen die Ausschlüsse entfernen */
( ( ( (.allASRelations; - .relationsWithRoleStreet;);
- .relationsWithEmptyRole; );
- .relationsWithNode; );
- .relationsWoHouseBuilding; );
/* Wege und Nodes dazu und raus damit*/
(._; );
out meta;
Hausnummern ohne Straße finden
Die folgende Overpass API Abfrage ermittelt alle Nodes, Ways und Relationen mit addr:housenumber jedoch ohne addr:street bzw. addr:place. Aus dieser Menge werden anschließend alle Relationen/Wege/Knoten herausgelöscht, die in einer associatedStreet-Relation in der Rolle "house" eingetragen wurden.
Hinweise:
- Die Query geht davon aus, dass associatedStreet-Relationen wiki-konform sind, also mindestens ein Member mit der Rolle street besitzen, aus dem sich die Straße ableiten lässt. Diese Eigenschaft wird in den Queries nicht gesondert abgefragt!
- associatedStreet-Relationen ohne street-Rolle können mit der Query "unnütze associatedStreet-Relationen ermitteln" herausgefunden werden. Diese Probleme sollten zunächst behoben werden, da sonst die Abfrage Hausnummern ohne Straße möglicherweise nicht die gewünschten Ergebnisse zurückliefert.
- Auch das Vorhandensein des Tags name in der Relation spielt für diese Auswertung keine Rolle. Achtung: In der Auswertung von User:Gehrke zu #osmwa3334 wird dagegen zwingend ein name-Tag an der associatedStreet-Relation vorausgesetzt, Member mit der Rolle street bleiben dagegen unberücksichtigt.[1]
Das Suchgebiet kann in jeweils der ersten Zeile angepasst werden. Weitere Details im Forum Thread.
area[type=boundary]["de:amtlicher_gemeindeschluessel"="08115003"]->.boundaryarea;
rel(area.boundaryarea)[type=associatedStreet]->.associatedStreet;
way(area.boundaryarea)["addr:housenumber"]["addr:street"!~"."]["addr:place"!~"."]->.allHousesWay;
way(r.associatedStreet:"house")->.asHouseWay;
((.allHousesWay; - .asHouseWay); >; );out meta;
node(area.boundaryarea)["addr:housenumber"]["addr:street"!~"."]["addr:place"!~"."]->.allHousesNode;
node(r.associatedStreet:"house")->.asHouseNode;
((.allHousesNode; - .asHouseNode););out meta;
rel(area.boundaryarea)["addr:housenumber"]["addr:street"!~"."]["addr:place"!~"."]->.allHousesRel;
rel(r.associatedStreet:"house")->.asHouseRel;
((.allHousesRel; - .asHouseRel); >>; );out meta;
Alternativ ist auch eine Suche über Nominatim möglich:
{{nominatimArea:"Regionalverband Saarbrücken"}}
(._; )->.boundaryarea;
/* Als zusätzliche Kontrolle die boundaryarea anzeigen - kann bei Bedarf aktiviert werden */
/* rel(pivot.boundaryarea);(way(r);>;);out; */
rel(area.boundaryarea)[type=associatedStreet]->.associatedStreet;
way(area.boundaryarea)["addr:housenumber"]["addr:street"!~"."]["addr:place"!~"."]->.allHousesWay;
way(r.associatedStreet:"house")->.asHouseWay;
((.allHousesWay; - .asHouseWay); >; );out meta;
node(area.boundaryarea)["addr:housenumber"]["addr:street"!~"."]["addr:place"!~"."]->.allHousesNode;
node(r.associatedStreet:"house")->.asHouseNode;
((.allHousesNode; - .asHouseNode););out meta;
rel(area.boundaryarea)["addr:housenumber"]["addr:street"!~"."]["addr:place"!~"."]->.allHousesRel;
rel(r.associatedStreet:"house")->.asHouseRel;
((.allHousesRel; - .asHouseRel); >>; );out meta;
Edit: addr:place ergänzt lt. Rückmeldung[2] von User:Gehrke bezogen auf die 'Wochenaufgabe KW33/34 Adressen ohne Strasse':
Edit: Ausgabe der boundaryarea zur Gebietskontrolle
Nehme entweder "addr:street", "addr:place" oder "name" von associatedStreet. Trifft nichts zu, ist die Straße "null". Ich zähle nun alle Fälle (nur nodes und ways), wo es zwar eine Hausnummer gibt, aber die Straße "null"
Anzahl von Adressen in einem Gebiet zählen
Die folgende Abfrage zählt die Anzahl von addr:housenumber=* in einem Gebiet. Adressduplikate (mehrfach vorhandene gleiche Adresse) werden dabei mitgezählt. Es wird zunächst die Gesamtzahl ausgegeben, dann die Anzahl der Punkte, dann Linien und schließlich Relationen. (Die Summe aus Punkte, Linien und Relationen ergibt die Gesamtzahl.)
[out:csv(::count, ::"count:nodes", ::"count:ways", ::"count:relations")][timeout:25];
{{geocodeArea:Chemnitz}}->.searchArea;
(
node["addr:housenumber"](area.searchArea);
way["addr:housenumber"](area.searchArea);
relation["addr:housenumber"](area.searchArea);
);
out count;
Wege, die Teil einer Bundesstraßenrelation sind, aber kein ref Tag tragen
Normalerweise sollten die Eigenschaften einer Relation auch auf die Wege vererbt werden, so dass ein explizites Setzen von ref am Weg theoretisch nicht notwendig ist. In der Praxis wird aber durchaus an jedem Weg ein ref gesetzt. Die Abfrage für Turbo findet Wege im aktuellen Ausschnitt, bei denen dieses ref Tag fehlt.
rel({{bbox}})[type=route][route=road][ref~"^B."];
way(r)["ref"!~"."];
(._;>;);
out meta;
Auch der umgekehrte Fall ist möglich:
area[name="Saarland"][type=boundary]->.a;
(
way(area.a)[highway][ref~"^B.*"]; -
(rel(area.a)[ref~"^B.*"][route=road][type=route];>;);
);
(._;>;);out;
Für ein bestimmtes Gebiet (hier im Beispiel Saarland) werden zunächst alle Wege ermittelt, deren 'ref'-Tag mit einem "B" beginnt. Aus dieser Menge werden alle Wege entfernt, die in einer Relation mit type=route, route=road und einem ref mit "B" beginnend enthalten sind. Die verbleibenden Bundesstraßen ohne Zuordnung zu einer Relation werden anschließend inkl. ihrer Nodes als Ergebnis zurückgeliefert.
living_streets mit maxspeed finden
way
["highway"~"living_street"]
["maxspeed"~"."]
({{bbox}});
(._;>;);
out;
potentiell fehlerhafte layer-Werte finden
[out:json][timeout:25];
(
node["layer"]["layer"!~"^(-5|-4|-3|-2|-1|0|1|2|3|4|5)$"]({{bbox}});
way["layer"]["layer"!~"^(-5|-4|-3|-2|-1|0|1|2|3|4|5)$"]({{bbox}});
relation["layer"]["layer"!~"^(-5|-4|-3|-2|-1|0|1|2|3|4|5)$"]({{bbox}});
);
out body;
>;
out skel qt;
Bei Bedarf kann man noch die 0 entfernen, um auch Objekte mit layer=0 zu finden. Overpass Turbo Link
Beispiele für Styles in overpass turbo (MapCSS)
Wanderwege
Die folgende Abfrage für Overpass Turbo zeigt Wanderweg-Relationen im aktuellen Ausschnitt an (route=hiking und network=?wn), ähnlich dem Lonvia-Stil. Farbgebung der Wege wird von der Relation abgeleitet.
[bbox:{{bbox}}];
(relation[route=hiking][network~".wn"];way(r)({{bbox}});>;);out;
{{style:
way
{ color:green; fill-color:green; }
relation[network=lwn] way
{ color:blue; fill-color:cyan; }
relation[network=iwn] way
{ color:red; fill-color:red; }
relation[network=nwn] way
{ color:green; fill-color:green; }
relation[network=rwn] way
{ color:yellow; fill-color:yellow; }
}}
Evtl. noch nicht 100% ok, bitte testen und ggfs. korrigieren.
(via osm-dev, MapCSS korrigiert, Query vereinfacht)
Surface einfärben
surface=* farbig anzeigen, am Beispiel des Rennsteig-Wanderweges
Ways ohne surface=* werden fett-rot dargestellt und in normalen rot die allgemeinen Tags paved/unpaved. Ist ein surface-Tag in der Liste nicht angegeben, wird der Way blau dargestellt.
/*
display surface-tag [1] in different colours
[1] https://wiki.openstreetmap.org/wiki/Key:surface
*/
[out:json][timeout:30];
relation(398874);way(r);out;>;out skel;
/* mapcss */
{{style:
/* without surface */
way
{ color:blue; width:8; }
/* with surface, but not listed above */
way[surface]
{ color:red; width:8; }
/* paved - dashed lines */
/* should be precised */
way[surface=paved]
{ color:red; opacity:1; }
way[surface=asphalt]
{ color:black; }
way[surface=cobblestone],
way[surface=paving_stones],
way[surface=paving_stones:30],
way[surface=paving_stones:20]
{ color:gray }
way[surface=concrete],
way[surface=concrete:lanes]
{ color:lightgray; }
way[surface=wood]
{ color:yellow }
/* unpaved - dashed lines */
/* should be precised */
way[surface=unpaved]
{ color:red; dashes:3,9; opacity:1; }
way[surface=compacted]
{ color:darkgray; dashes:4,12; }
way[surface=gravel]
{ color:grey; dashes:4,12; }
way[surface=fine_gravel]
{ color:white; dashes:4,12; }
way[surface=grass_paver]
{ color:lightgray; dashes:4,12; }
way[surface=ground],
way[surface=earth]
{ color:brown; dashes:4,12; }
way[surface=dirt],
way[surface=mud]
{ color:saddlebrown; dashes:4,12; }
way[surface=grass]
{ color:green; dashes:4,12; }
way[surface=sand],
way[surface=salt]
{ color:wheat; dashes:4,12; }
}}
Briefkästen
Dieses Thema kann auf unterschiedlichste Weisen analysiert warden.
Briefkästen, eingefärbt nach vorhandener Leerungszeit
(
node
["amenity"="post_box"]
//["collection_times"!~"."]
({{bbox}});
>;
);
{{style:
node
{ color:red; fill-color: red;}
node[collection_times]
{ color:green; fill-color:green; }
}}
out;
alternative mit Überprüfung der Leerungszeiten
{{key1=amenity}}
{{value1=post_box}}
<osm-script output="json">
<union>
<query type="node">
<has-kv k="{{key1}}" v="{{value1}}"/>
<bbox-query {{bbox}}/>
</query>
</union>
<print mode="body"/>
<recurse type="down"/>
<print mode="skeleton"/>
</osm-script>
{{style:
node{
color: #ffffff;
fill-color: #ff0000;
fill-opacity: 0.8;
}
node[operator]{
color: #0000ff;
fill-color: #ff0000;
fill-opacity: 0.8;
}
node[collection_times:lastcheck],
node[last_checked],
node[lastcheck]{
color: #ffff00;
fill-color: #ffff00;
fill-opacity: 0.8;
}
node[collection_times:lastcheck][operator],
node[last_checked][operator],
node[lastcheck][operator] {
color: #0000ff;
fill-color: #ffff00;
fill-opacity: 0.8;
}
node[collection_times:lastcheck=~/2024-*./],
node[last_checked=~/2024-*./],
node[lastcheck=~/2024-*./]{
color: #ffff00;
fill-color: #00ff00;
fill-opacity: 0.8;
}
node[collection_times:lastcheck=~/2024-*./][operator],
node[last_checked=~/2024-*./][operator],
node[lastcheck=~/2024-*./][operator]{
color: #0000ff;
fill-color: #00ff00;
fill-opacity: 0.8;
}
node[collection_times:lastcheck=~/2023-*./],
node[last_checked=~/2023-*./],
node[lastcheck=~/2023-*./]{
color: #ffff00;
fill-color: #55aa00;
fill-opacity: 0.8;
}
node[collection_times:lastcheck=~/2023-*./][operator],
node[last_checked=~/2023-*./][operator],
node[lastcheck=~/2023-*./][operator]{
color: #0000ff;
fill-color: #55aa00;
fill-opacity: 0.8;
}
node[collection_times:lastcheck=~/2022-*./],
node[last_checked=~/2022-*./],
node[lastcheck=~/2022-*./]{
color: #ffff00;
fill-color: #aa5500;
fill-opacity: 0.8;
}
node[collection_times:lastcheck=~/2022-*./][operator],
node[last_checked=~/2022-*./][operator],
node[lastcheck=~/2022-*./][operator]{
color: #0000ff;
fill-color: #aa5500;
fill-opacity: 0.8;
}
}}
Overpass Turbo Link - gültig für 2024
Newbies finden, die Eisenbahnsignale mappen
Aufgabe: Finde alle unbekannten User (Newbies) in einer Gegend, die nach einem bestimmten Zeitpunkt ein Eisenbahnsignal railway=signal editiert haben. Diese User kann man dann an die Hand nehmen und ihnen z.B. den Umstieg auf JOSM nahelegen.
node
[railway=signal](newer:"2015-05-01T07:00:00Z") // Datum ggf. anpassen
({{bbox}})->.newnodes;
// Liste aller User, die man schon kennt und nicht in den Ergebnissen haben möchte
// i.d.R. sind das "Poweruser"
(.newnodes; - node.newnodes(user:Nakaner, "Nakaner-repair", bigbug21, mapper999);)->.newnodes;
// Ausgabe
.newnodes out meta;
Die Abfrage hat zwei Nachteile:
1. Es wird nur auf last-modified in OSM geachtet. Wenn ein Nicht-Bahn-Mapper ein Signal leicht verschiebt, wird der Zeitstempel aktualisiert und man erhält ein False Positive.
2. Man muss von Hand eine Liste der "Poweruser" pflegen und iterativ die Abfrage optimieren, bis die Zahl der False Positives gering genug ist.
Baustellen finden
Aufgabe: finde alles, das irgendwie als "construction" getaggt ist. Baustellen sind temporär und bedürfen immer mal wieder einer Überprüfung.
[out:json][timeout:25];
(
node[~".*"~"construction"]({{bbox}});
way[~".*"~"construction"]({{bbox}});
relation[~".*"~"construction"]({{bbox}});
);
out body;
>;
out skel qt;
Overpass turbo: http://overpass-turbo.eu/s/edt