User:Kaitu/IT:Overpass API/Beispielsammlung
La Overpass API offre molteplici possibilità di ricerca. Tutte queste possibilità si possono usare visualizzare su una carta geografica oppure usare per interrogare il database. In questa sede ci concentriamo sulla visualizzazione su una carta geografica. In questo caso le query sottoriportate si possono ricopiare nel form Overpass API Convert Form sul sito di prova.
Ricerca di un Tag non frequente
Un tag non frequente su un nodo, ad esempio name=Gielgen, si può cercare come segue:
node["name"="Gielgen"];
out skel;
Per provare, selezionare l'opzione to OpenLayers auto-centered overlay a fare partire la ricerca con il pulsante Convert. Con questa scelta otteniamo una carta geografica centrata automaticamente sugli oggetti trovati.
La prima riga della pagina di risposta mostra lo stato: se mostra Searching ... significa che il server non ha ancora trovato alcun dato. Se mostra No results found. significa il risultato della interrogazione non ha fornito alcun nodo (e senza nodi OpenLayers non visualizza nulla). Se mostra Found ... features, significa che sono stati trovati altrattanti nodi o way.
Affinchè OpenLayers possa mostrare una way, dobbiamo richiedere anche i nodi che la compongono, e per tale scopo usiamo l'operatore ">":
(way["name"="Gielgenstraße"];>;);
out skel;
Stessa cosa per i membri delle relazioni:
(rel["ref"="A 555"];>;);
out skel;
Notare che l'alto numero di oggetti trovati non si riferisce alla relazione, ma al numero di way membri della relazione.
Ricerca di un Tag frequente
Anche quando il tag non descrive un oggetto specifico, ma piuttosto una categoria di oggetti, come per esempio le cassette postali, possiamo mostrarli come strato di una mappa geografica:
[timeout:5];
node["amenity"="post_box"];
out skel;
A tal fine selezionare l'opzione to OpenLayers slippy overlay e premere Convert per cominciare la interrogazione. Ora la carta geografica inizialmente mostra sempre l'Europa centrale, e comincia a caricare gli oggetti solo dopo che abbiamo ingrandito un'area più ristretta.
Dalla riga di stato si capisce se abbiamo zoomato a sufficienza: Please zoom in to view data. significa che a questo livello di zoom i dati non vengono caricati, i dati già scaricati in precedenza non vengono però cancellati. Il testo Loading... compare appena, con un livello di zoom sufficiente, il browser comincia a caricare i dati, mentre Displaying ... features indica che altrettanti oggetti sono stati trovati.
La profondità di zoom consentita dipende dal parametro [timeout:5]: La Slippy Map cerca per un massimo di 5 secondi di ottenere dati dalla Overpass API. Se settiamo un valore alto il sistema reagisce e richiede più spazio al Client, così può già con livelli di zoom più bassi mostrare gli oggetti. Per contro, un valore più piccolo rende la Slippy Map più reattiva, ma richiede livelli di zoom più alti.
Per le piste da sci:
[timeout:5];
(way["piste:type"="nordic"];>;);
out skel;
E per le relazioni, in questo esempio di tutte le autostrade tedesche:
[timeout:5];
(rel["network"="BAB"];>;);
out skel;
Ricerca di un tag frequente all'interno di una Bounding Box
Se vogliamo restringere la ricerca di un tag frequente ad una Bounding Box, di nuovo lo possiamo fare agevolmente con to OpenLayers auto-centered overlay. A tal fine aggiungiamo alla richiesta un parametro Bounding-Box:
node["amenity"="post_box"](50.6,7.0,50.8,7.3);
out skel;
mostra sulla mappa tutte le buche delle lettere nei dintorni di Bonn (latitudine compresa tra 50.6 e50.8, longitudine compresa tra 7.0 e 7.3).
Per le scuole è leggermente più complicato, perchè possono essere sia nodi che way:
(
way["amenity"="school"](50.6,7.0,50.8,7.3);
>;
node["amenity"="school"](50.6,7.0,50.8,7.3);
);
out skel;
Questa query contiene tre distinte ricerche: 1 tutte le way taggate con amenity=school; 2 tutti in nodi che costituiscono tali way; 3 tutti i nodi taggati con amenity=school.
OpenLayers usa i layer 1 e 2 per tracciare le way.
La stessa cosa funziona anche per le relazioni:
rel[ref=16](50.6,7.0,50.8,7.3);>;
out skel;
trova la linea ferroviaria suburbana S16 che passa per Bonn. Si noti che viene resituita la linea completa, compresi i tratti fuori da Bonn, perchè la query dapprima cerca le relazioni che intersecano la Bounding Box, e poi cerca tutti gli elementi che le compongono. Con
(
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;
restringiamo la ricerca alle way comprese entro la Bounding Box (cerchiamo separatamente i sottoelementi e restringiamo esplicitamente la ricerca alla Bounding Box per i nodi e le way).
Stradario
La ricerca che segue è adatta a ricavare una lista completa di tutte le strade dotate di nome in una città, qui Troisdorf:
area[name="Troisdorf"];way(area)[highway][name];out;
La query restituisce tutte le way all'interno del comune (e anche le way che tagliano il confine comunale; con questa logica è inevitabile, ma capita comunque di rado), senza i nodi che le compondono. Con il comando:
grep '<tag k="name"' <troisdorf.osm | sort | uniq | awk '{ s=substr($0,22); print substr(s,1,index(s,"\"")-1); }' >straszenliste.txt
ne possiamo poi estrarre uno stradario.
Talvolta il confine comunale non si chiama semplicemente come la città, e la ricerca non fornisce risultati. Per esempio nel caso di Eckernförde compare la parola aggiuntiva "Landmasse". Tuttavia ci si può aiutare con l'uso di una espressione regolare:
area[name~"Eckernförde"];way(area)[highway][name];out;
Ricerca di relazioni relative ai confini con boundary=administrative e admin_level=9 ede:amtlicher_gemeindeschluessel=XXXXXXXX
... una combinazione di admin_level=9 e AGS è logicamente errata. Relazioni di confini con una propria chiave del comune devono almeno essere di livello admim_level=8 o inferiore.
- ho omesso "boundary=administrative", perchè chi assegna un admin-level sbagliato forse inoltre non assegna questa chiave.
rel[admin_level=9]["de:amtlicher_gemeindeschluessel"];out;
oppure
rel[boundary=administrative][admin_level=9]["de:amtlicher_gemeindeschluessel"];out;
Tag addr:postcode=XXXXX anomali all'interno di una relazione di confini avente codice di avviamento postale postal_code=XXXXX
... come eseguire una ricerca che restituisce tutti i nodi o le way aventi addr:postcode DIVERSO da XXXXX e giacenti all'INTERNO di una relazione di confini con il tag postal_code=XXXXX?
- Il comando che segue funziona solo CAP per CAP, ad esempio per il "42103":
area[postal_code="42103"]->.a;(node(area.a)["addr:postcode"]["addr:postcode"!="42103"];way(area.a)["addr:postcode"]["addr:postcode"!="42103"];);out;
più in generale con uno script bash:
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
Usando al posto di "out;" un "out meta;" è possibile aprire i file risultanti "false_XXXXX.osm" in JOSM e lavorarci .
Usando una opportuna Bounding Box le ricerche diventano anche sensibilmente più rapide:
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
Ricerca di strade mappate come aree
... cerchiamo tutte le strade taggate con highway=* E area=yes ... Così possiamo cercare dei posti, anche quando sono stati mappati solo come (piccole) aree, come per esempio le aree del mercato o gli spiazzi di manovra nelle strade senza uscita.
Qui un primo tentativo, ancora con overpass-turbo.eu:
Ricerca di oggetti che hanno una particolare caratteristica, ma cui manca un'altra particolare caratteristica
Esempio: mostrare tutti i nodi e le way di un'area aventi un addr:city, ma a cui manca addr:postcode: 
<union>
<query type="node">
<has-kv k="addr:city"/>
<has-kv k="addr:postcode" modv="not" regv="."/>
<bbox-query {{bbox}}/>
</query>
...
</union>
<print/>
Edifici attraversati da un percorso che non è taggato come covered o tunnel
Ricerca approssimata di edifici attraversati da un percorso senza covered e senza tunnel. Poichè con il comando around viene considerato anche il perimetro dell'edificio, potrebbero verificarsidei falsi positivi se una strada è collegata direttamente all'edificio.
Nota Questa analisi è ancora molto lenta, pertanto è necessario innanzitutto zoomare vicino all'obbiettivo.
Importante: la seguente query è concepita per Overpass Turbo.
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;
Strade che fanno parte di una strada federale ma sono prive del tag ref
Di solito le caratteristiche di una relazione dovrebbero essere ereditate anche dalle strade che vi appartengono, pertanto teoricamente non sarebbe necessario taggare esplicitamente le strade con ref. Nella pratica invece ogni strada viene taggata con ref. Questa query per Turbo trova nel riquadro corrente le trade a cui manca il tag ref.
rel({{bbox}})[type=route][route=road][ref~"^B."]; foreach(way(r)["ref"!~"."];out;>;out;);
Non funziona senza foreach (perchè?), ma anche usandolo in alcuni casi non funziona correttamente: http://www.openstreetmap.org/browse/way/35027431 Bug?
- Ja, ein Bug ist da auf jeden Fall. (si, è certamente un bug) --Roland
- Bug behoben und auf overpass-api.de installiert. Rambler folgt, wenn keine Regressionen auftreten. (bug rimosso e installato su overpass-api. Rambler segue se non si verifica alcuna regressione.)--Roland
Editing di categorie di dati selezionate
Quando i dati di OSM in un'area hanno raggiunto una elevata densità, è talvolta una pena condurre delle semplici modifiche. L'interazione tra JOSM e Overpass API fornisce un rimedio: il Plugin mirrored_download semplifica il download corretto. Il metodo di lavoro assomiglia così molto al concetto di "Layer" nei sistemi GIS classici. Attenzione: editare in questo modo richiede più attenzione del solito. Vedi il prossimo passaggio.
Come esempio vogliamo verificare quali negozi in Bonn hanno già un tag Wheelmap, e se necessario dotarceli.
A tal fine installiamo in JOSM il Plugin "mirrored_download", come sfondo scegliamo la mappa OSM standard in bianco e nero, e scarichiamo una selezione di dati.
Avvertimento
Questo modo di editare richiede più attenzione del solito, perchè modificando una geometria si potrebbe coinvolgere un oggetto non visibile. Anche i nodi potrebbero appartenere anche a way adiacenti; questo problema si verifica di solito solo sul bordo della bounding box di JOSM. Pertanto non bisogna cancellare nodi e neppure spostarli. Per contro è possibile sia modificare i tag, sia spezzare le way, il che abbraccia molti casi di editing.
Installazione del Plugin mirrored_download
Questo passo, come il seguente, va eseguito solo una volta, poichè JOSM mantiene i settaggi e salva localmente i plugin scaricati.
Dopo l'avvio di JOSM selezionare "Modifica > Preferenze...".
Selezionare la presa di corrente nella lista a sinistra.
Selezionare poi "Scarica lista ...".
Digitare in Cerca le lettere "mirr" e selezionare l'unica voce rimasta "mirrored_download".
"OK". "Riavvia" ed attendere il riavvio.
Den Hintergrund installieren
Rufe "Bearbeiten > Einstellungen ..." auf.
Wähle "TMS/WMS", den untersten Eintrag in der Leiste links.
Wähle unter "Verfügbare Standardeinträge" den Eintrag "OpenStreetMap (schwarz/weiß)" aus und klicke auf die Schaltfläche "Aktivieren" unter der Liste, dann "OK".
Wähle dann "Hintergrund > OpenStreetMap (Mapnik schwarz/weiß)". Es erscheint ein helleres Grau im Hintergrund. Die eigentliche Karte erscheint, sobald wir im nächsten Schritt Koordinaten gewählt haben.
Daten herunterladen
Rufe "Datei > Mittels Overpass-API laden" auf.
Wähle in der "Interaktive Karte" das gewünschte Gebiet aus. Das Mausrad zoomt heraus und hinein, und mit gedrückter rechter Maustaste kann die Karte bewegt werden. Mit gedrückter linker Maustaste wird ein Bereich markiert.
Gib unter "Overpass-Abfrage" eine Abfrage ein. In unserem Beispiel verwenden wir:
( node[shop];
way[shop];>;
rel[shop];>;);
(._;rel(bn););
(._;rel(bw););
(._;rel(br););
out meta;
Die Syntax wird weiter unten erklärt. Die Bounding Box wird automatisch bei allen Abfragen ergänzt. Wichtig ist, dass wir insbesondere Relationen mit herunterladen, damit JOSM diese beim Editieren anpassen kann.
Klicke "Daten herunterladen" an und warte ab, bis der Download abgeschlossen ist. Bei Testen hat dies für Bonn etwa 5-15 Sekunden gedauert.
Denke beim Editieren an die Warnhinweise. Oder benutze es als bequeme, benutzerdefinierte Ansicht für OSM-Objekte ausgewählter Kategorien.
Mehr nützliche Abfragen
Das gesamte Straßennetz:
( way[highway];>;);
(._;rel(bn););
(._;rel(bw););
(._;rel(br););
out meta;
Alle ÖPNV-relevanten Daten:
( way[highway];>;
way[railway];>;
node[public_transport];
node[highway=bus_stop];);
(._;rel(bn););
(._;rel(bw););
(._;rel(br););
out meta;
Die Technik dahinter
Benutzt wird das neue Feature der Global Bbox für die Overpass API: dies ermöglicht, die von JOSM gelieferte Bounding Box automatisch auf alle Teilabfragen innerhalb der Abfrage auszudehnen.
Der OSM-Hintergrund kommt tatsächlich direkt vom OSM-Tile-Server, so dass kein Bildversatz auftreten kann.
Der hintere Teil aller Abfragen
(._;rel(bn););
(._;rel(bw););
(._;rel(br););
stellt sicher, dass auch alle Relationen gefunden werden, die auf die gewählten Objekte verweisen. Das verringert das Konfliktpotential. Es bleiben die unter Warnhinweise aufgezählten Punkte. Die Abfragen würden auch ohne diese Zeilen funktionieren, solange man nicht editiert.
Es muss osm meta gewählt werden, da JOSM zur Konfliktvermeidung darauf besteht, zu den Objekten auch die Versionsdaten herunterzuladen.
Reproduzierbarkeit
Getestet ist das Beispiel mit der derzeit aktuellen JOSM-Tested-Version 6060 und Plugin-Version 29753.