Hallo,
es kommt ja regelmäßig vor, dass hier irgendjemand fragt „wie kann ich dieses und jenes Feature aus OSM laden“, und dann gibt es oftmals hilfreiche Antworten mit Overpass oder sogar einem fertigen Overpass Turbo-Link.
Für manche Sachen ist Overpass die optimale Lösung. Aber manchmal denke ich auch, mensch, mit einem PostGIS-Query ginge das einfacher/besser. Nur hilft es den Leuten nicht so, wenn man schreibt „lade Dir das Extrakt runter, installiere PostGIS, nimm osm2pgsql, importiere die Daten, und dann kannst Du …“
Deshalb habe ich einen öffentlichen Dienst gebastelt, mit dem man – genau wie mit Overpass auch – die OSM-Daten abfragen kann, aber basierend auf einer PostGIS-Datenbank. Deswegen heisst das Ding auch “Postpass” In einem ersten Versuch hatte ich das mit dem Standard-OSM-Carto-Datenbankschema gemacht, aber in einer kleinen Runde am OSM-Samstag auf der FOSSGIS sind wir dann übereingekommen, dass man das Schema etwas verschlanken sollte. Es ist aber immer noch ein Datenschema mit osm2pgsql-Geometrien – das heisst, man schaut nicht (wie bei Overpass) auf die OSM-Rohdaten, sondern auf fertig zusammengebaute Geometrien. Die Ausgabe ist daher auch GeoJSON und nicht OSM-XML.
So kann man zum Beispiel Fast-Food-Restaurants in Karlsruhe finden:
curl -g http://postpass.geofabrik.de/api/0.2/interpreter --data-urlencode "data=
SELECT tags, geom
FROM postpass_point
WHERE tags->>'amenity'='fast_food'
AND geom && st_setsrid(st_makebox2d(st_makepoint(8.34,48.97),
st_makepoint(8.46,49.03)), 4326)"
Das mit dem curl
und der Boundingbox ist natürlich etwas nervig, daher kann man das ganze auch direkt in Overpass Turbo mit dem gewohnten {{bbox}}
nutzen, man muss nur eine magische Zeile voranstellen, die dem Overpass Turbo sagt, dass es meinen Server ansprechen soll:
{{data:sql,server=https://postpass.geofabrik.de/api/0.2/}}
SELECT tags, geom
FROM postpass_point
WHERE tags->>'amenity'='fast_food'
AND geom && {{bbox}}
Das sind jetzt nur ganz einfache Beispiele, mit dem SQL kann man natürlich beliebig komplizierte Sachen machen.
Es gibt die Tabellen postpass_point
, postpass_line
, postpass_polygon
, aber auch kombinierte Views namens postpass_pointpolygon
und so weiter, wenn man (was bei POIs ja oft der Fall ist) Punkte und Polygone kombinieren will.
Wichtig ist, dass Queries immer eine Geometrie zurückgeben müssen, sonst kann kein GeoJSON konstruiert werden. Aber man kann beliebige PostGIS-Geometrieoperationen nutzen, zum Beispiel hier ein Buffer von 0,01 Grad um Deutschland herum
{{data:sql,server=https://postpass.geofabrik.de/api/0.2/}}
SELECT st_buffer(geom,0.01)
FROM postpass_polygon
WHERE tags->>'boundary'='administrative'
AND tags->>'admin_level'='2'
AND tags->>'name'='Deutschland'
oder wenn man es wirklich exakt mit 1000 Metern berechnen will, durch eine kleine Reprojektions-Orgie:
{{data:sql,server=https://postpass.geofabrik.de/api/0.2/}}
SELECT st_buffer(geom::geography, 1000)::geometry
FROM postpass_polygon
WHERE tags->>'boundary'='administrative'
AND tags->>'admin_level'='2'
AND tags->>'name'='Deutschland'
Solche Queries sind dann nicht mehr superschnell, aber sie gehen. Hier ist ein Query, der in ganz Deutschland alle Punkte findet, die ein addr:postal_code
haben, der nicht zum umgebenden PLZ-Polygon passt:
SELECT
p.osm_id, p.geom,
p.tags->>'addr:postcode' as punkt_plz,
plz.tags->>'postal_code' as poly_plz
FROM postpass_point p, postpass_polygon plz
WHERE plz.geom && st_setsrid(st_makebox2d(
st_makepoint(5.53,47.23), st_makepoint(15.38,54.96)), 4326)
AND st_contains(plz.geom, p.geom)
AND p.tags->>'addr:postcode' <> plz.tags->>'postal_code'
AND plz.tags→>'boundary'='postal_code'
Auch Schnitt-Geometrien oder Vereiningungs-Geometrien kann man ausrechnen und zurückgeben lassen.
Wenn man mit einem speziellen Flag sagt, dass man keine Geometrie will, kann man auch SQL-Abfragen stellen, die z.B. irgendwas zählen, so zum Beispiel „was gibt es in Karlsruhe für verschiedene amenity-Werte“
curl -g https://postpass.geofabrik.de/api/0.2/interpreter \
--data-urlencode "options[geojson]=false" \
--data-urlencode "data=
SELECT count(*), tags->>'amenity' as amenity
FROM postpass_point
WHERE tags?'amenity'
AND geom && st_setsrid(st_makebox2d(
st_makepoint(8.34,48.97),
st_makepoint(8.46,49.03)), 4326)
GROUP BY amenity"
oder „wieviele Meter von den verschiedenen Highway-Klassen gibt es in Karlsruhe“
curl -g https://postpass.geofabrik.de/api/0.2/interpreter \
--data-urlencode "options[geojson]=false" \
--data-urlencode "data=
SELECT count(*), tags->>'amenity' as amenity
FROM postpass_point
WHERE tags?'amenity'
AND geom && st_setsrid(st_makebox2d(
st_makepoint(8.34,48.97),
st_makepoint(8.46,49.03)), 4326)
GROUP BY amenity"
Ihr könnt sogar für solche nicht-Geometrie-Abfragen Overpass Turbo benutzen, indem ihr der magischen {{data:sql}}
-Zeile noch ein geojson=false
hinzufügt:
{{data:sql,server=https://postpass.geofabrik.de/api/0.2/,geojson=false}}
SELECT count(*), tags->>'amenity' as amenity
FROM postpass_point
WHERE tags?'amenity'
AND geom && st_setsrid(st_makebox2d(
st_makepoint(8.34,48.97),
st_makepoint(8.46,49.03)), 4326)
GROUP BY amenity
Es gibt aber auch viele Sachen, die mit Overpass besser oder schneller gehen – insbesondere dann, wenn man stärker and den OSM-Daten arbeiten muss. Das „Postpass“ kann auch keine history.
Es gibt zwei GitHub-Repositories, in denen dieses Projekt beheimatet ist. Einmal GitHub - woodpeck/postpass: a simple API wrapper around PostGIS für die Software an sich (die kann prinzipiell mit jeder Art PostGIS-Datenbank eingesetzt werden) und einmal GitHub - woodpeck/postpass-ops: operational issues about the Postpass instance run on postpass.geofabrik.de für die konkrete Instanz, die ihr unter postpass.geofabrik.de erreicht. Dort habe ich auch eine Beispielsammlung angefangen, aber ich freue mich auch über Beispiele hier im Thread, oder wenn jemand eine Wikiseite im OSM-Wiki dazu machen will (das habe ich noch gar nicht angefangen).
Das ist jetzt alles noch ganz neu und bestimmt nicht perfekt. Was vorallem noch fehlt, ist eine Möglichkeit, von außen zu sehen, wie beschäftigt das System gerade ist. Das System arbeitet mit drei Warteschlangen für schnelle, mittlere, und langsame Requests. Wenn ihr einen Request schickt, der 5 Minuten rechnet, dann wird der auch bearbeitet, aber erst nachdem alle anderen gerade wartenden lang-dauernden Request bearbeitet sind; ein knackiger kleiner Request kann sich über eine der anderen Warteschlangen daran vorbeimogeln und wird schneller beantwortet.
Spielt doch mal ein wenig damit herum. Ich freue mich über Feedback. Besonders freue ich mich, dass Martin den Support so schnell in Overpass Turbo eingebaut hat, das macht die Sache wirklich viel bequemer zu nutzen
Meinen FOSSGIS-Vortrag dazu könnt ihr hier anschauen: Overpass Turbo goes PostGIS - media.ccc.de – allerdings sind die Beispiele darin noch für die erste Version der Datenbank mit den Tabellen planet_osm_point
und so weiter.
Bye
Frederik