DE:Overpass API/Beispielsammlung

From OpenStreetMap Wiki
Jump to: navigation, search
Verfügbare Sprachen — Overpass API/Beispielsammlung
· Afrikaans · Alemannisch · aragonés · asturianu · azərbaycanca · Bahasa Indonesia · Bahasa Melayu · Bân-lâm-gú · Basa Jawa · Baso Minangkabau · bosanski · brezhoneg · català · čeština · dansk · Deutsch · eesti · English · español · Esperanto · estremeñu · euskara · français · Frysk · Gaeilge · Gàidhlig · galego · Hausa · hrvatski · Igbo · interlingua · Interlingue · isiXhosa · isiZulu · íslenska · italiano · Kiswahili · Kreyòl ayisyen · kréyòl gwadloupéyen · Kurdî · latviešu · Lëtzebuergesch · lietuvių · magyar · Malagasy · Malti · Nederlands · Nedersaksies · norsk bokmål · norsk nynorsk · occitan · Oromoo · oʻzbekcha/ўзбекча · Plattdüütsch · polski · português · português do Brasil · română · shqip · slovenčina · slovenščina · Soomaaliga · suomi · svenska · Tiếng Việt · Türkçe · Vahcuengh · vèneto · Wolof · Yorùbá · Zazaki · српски / srpski · беларуская · български · қазақша · македонски · монгол · русский · тоҷикӣ · українська · Ελληνικά · Հայերեն · ქართული · नेपाली · मराठी · हिन्दी · অসমীয়া · বাংলা · ਪੰਜਾਬੀ · ગુજરાતી · ଓଡ଼ିଆ · தமிழ் · తెలుగు · ಕನ್ನಡ · മലയാളം · සිංහල · ไทย · မြန်မာဘာသာ · ລາວ · ភាសាខ្មែរ · ⵜⴰⵎⴰⵣⵉⵖⵜ · አማርኛ · 한국어 · 日本語 · 中文(简体)‎ · 吴语 · 粵語 · 中文(繁體)‎ · ייִדיש · עברית · اردو · العربية · پښتو · سنڌي · فارسی · ދިވެހިބަސް




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.

Contents

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: try it yourself in overpass-turbo

<union>
  <query type="node">
    <has-kv k="addr:city"/>
    <has-kv k="addr:postcode" modv="not" regv="."/>
    <bbox-query {{bbox}}/>
  </query>
  ...
</union>
<print/>


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;

Link zu Overpass Turbo, Overpass XML Variante

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

Gebäude ragt auf Straße

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.

Wichtig: Diese folgende Query ist für Overpass Turbo gedacht.

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;


Bushaltestellen, die nicht in Relation enthalten sind

Zeige alle Bushaltestellennodes an, die nicht in einer bestimmten Relation sind. try it yourself in overpass-turbo

// 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:

  1. Ermittle alle Relationen im aktuellen Kartenfenster, die vom Typ route=bus sind, speichere das Ergebnis nach .all
  2. Ermittle alle Parent-Relationen von .all, die vom Typ route_master=bus sind
  3. 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.
  4. 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)

Quelle

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. try it yourself in overpass-turbo

[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;

Quelle


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

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.

Erste Abfrage:

/* 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; }
*/
}}

Zweite Abfrage:

/* 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;

Quelle

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

Overpass Turbo Link

Quelle


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;

Overpass Turbo Link

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;

Overpass Turbo Link

Quelle

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.

Overpass Turbo Link Quelle

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;


talk-at overpass turbo Link


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; 
);

Overpass Turbo Link

Doppelte Knoten finden

siehe https://help.openstreetmap.org/questions/39745/show-duplicated-nodes-via-overpass

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;

overpass turbo Link Quelle

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;

Overpass Turbo Link

Quelle

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;

Beispiel

Quelle

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;

Beispiel

Quelle

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;

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.

Overpass Turbo Link

[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.

Overpass Turbo Link

[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;

Overpass Turbo Link

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;

Overpass Turbo Link

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=~/2015-*./], 
  node[last_checked=~/2015-*./], 
  node[lastcheck=~/2015-*./]{
    color: #ffff00;
    fill-color: #00ff00;
    fill-opacity: 0.8;
  }
  node[collection_times:lastcheck=~/2015-*./][operator],
  node[last_checked=~/2015-*./][operator],
  node[lastcheck=~/2015-*./][operator]{
    color: #0000ff;
    fill-color: #00ff00;
    fill-opacity: 0.8;
  }
  node[collection_times:lastcheck=~/2014-*./],
  node[last_checked=~/2014-*./],
  node[lastcheck=~/2014-*./]{
    color: #ffff00;
    fill-color: #55aa00;
    fill-opacity: 0.8;
  }
  node[collection_times:lastcheck=~/2014-*./][operator],
  node[last_checked=~/2014-*./][operator],
  node[lastcheck=~/2014-*./][operator]{
    color: #0000ff;
    fill-color: #55aa00;
    fill-opacity: 0.8;
  }
  node[collection_times:lastcheck=~/2013-*./],
  node[last_checked=~/2013-*./],
  node[lastcheck=~/2013-*./]{
    color: #ffff00;
    fill-color: #aa5500;
    fill-opacity: 0.8;
  }
  node[collection_times:lastcheck=~/2013-*./][operator],
  node[last_checked=~/2013-*./][operator],
  node[lastcheck=~/2013-*./][operator]{
    color: #0000ff;
    fill-color: #aa5500;
    fill-opacity: 0.8;
  }
}}

Overpass Turbo Link - gültig für 2015

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.

// Datum ggf. anpassen
node
  [railway=signal](newer:"2015-05-01T07:00:00Z")
  ({{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);)->.newnodes;
(.newnodes; - node.newnodes(user:"Nakaner-repair");)->.newnodes;
(.newnodes; - node.newnodes(user:bigbug21);)->.newnodes;
(.newnodes; - node.newnodes(user: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