Postpass

From OpenStreetMap Wiki
Jump to navigation Jump to search
  • Postpass
  • In other languages
Postpass
v · d 
Author: woodpeck/postpass/graphs/contributors GitHub
License: GNU GPL v3 (free of charge)
Platform: Linux
Status: Active
Version: 0.2 (2025-04-04)
Website: postpass.geofabrik.de
Source code: woodpeck/postpass GitHub
Programming language: Go

A publicly queryable PostGIS database containing the OSM data

Features
Feature Value
Map Display
?
Routing
?
Navigating
?
Tracking
?
Monitoring
?
Editing
?
Rendering
?
Accessibility
?

Postpass is a thin wrapper around a PostGIS/PostgreSQL database with the OpenStreetMap data. You can send queries over the Internet and receive back the results as GeoJSON document.

This is inspired by and a similar concept to Overpass API. Postpass is intended to do approximately the same things that Overpass API does, just based on a PostGIS database.


Quick Start (60 seconds): Interactive UI

Click on the icon, then press " ▶ Run " in the new tab.

Otherwise you can also open https://overpass-turbo.eu/. Delete any text in the text box. Copy and paste the following into the text box, then press “ ▶ Run ”.

try it yourself in overpass-turbo
try it yourself in overpass-turbo
{{data:sql,server=https://postpass.geofabrik.de/api/}}
SELECT osm_id, tags, geom 
FROM postpass_pointpolygon
WHERE tags->>'amenity'='fast_food' 
AND geom && {{bbox}}

Click on the magnifying glass icon 🔍 to zoom to the results on the map.

Check out Postpass/QL Overview to get a feeling for the query language. Check out Postpass/Examples for interesting applications of Postpass

Quick Start (60 seconds): Developers

Run the following command: 

curl https://postpass.geofabrik.de/api/interpreter --data-urlencode "data=
  SELECT osm_id, tags, geom 
  FROM postpass_pointpolygon
  WHERE tags->>'amenity'='fast_food' 
  AND geom && ST_SetSRID(ST_MakeBox2D(ST_MakePoint(8.34,48.97), ST_MakePoint(8.46,49.03)), 4326)
"


Query Language

Postpass uses SQL, a language which is widely used to query databases of all kinds.

A quick overview of the query language is provided on Postpass/QL Overview. It is assuming Geofabrik's postpass server schema.

Overpass Turbo integration

Overpass turbo has support for Postpass. Put this into the first line: 

{{data:sql,server=https://postpass.geofabrik.de/api/}}

Then put your query below it.

There is a shortcut {{bbox}} which gets replaced with st_setsrid(st_makebox2d(st_makepoint(‹x_min›,‹y_min›), st_makepoint(‹x_max›,‹y_max›)), 4326) where x_min, y_min, x_max, y_max are the corner coordinates of the current map view.

That means if you are looking for features in the map view you can use the shorthand WHERE geom && {{bbox}}.

Overpass-Turbo also supports Ultra's {{wsen}}. See #Ultra_integration.


Ultra integration

Ultra has support for Postpass as well. Add type: postpass to the YAML front matter.

There is a shortcut {{wsen}} which gets replaced with ‹x_min›,‹y_min›‹x_max›,‹y_max› where x_min, y_min, x_max, y_max are the corner coordinates of the current map view. } That means if you are looking for features in the map view you can use the shorthand WHERE geom && ST_MakeEnvelope({{wsen}}, 4326).


Ultra example

▶ Run on Ultra 

---
title: Postpass
description: Query OpenStreetMap using [Postpass](https://github.com/woodpeck/postpass)
options:
  center: [-122.6847, 45.5112]
  zoom: 15
type: postpass
---
SELECT osm_id, osm_type, tags, geom
FROM postpass_point
WHERE tags->>'amenity'='fast_food'
  AND geom && ST_MakeEnvelope({{wsen}},4326)


Technical Background

Refer to the official documentation.

Postpass is powered by a PostGIS database containing all the OSM data. It’s using a read-only access to the database, so only queries reading the data are possible. Requests to modify or delete data are denied.

The database is imported from OSM raw data using Osm2pgsql. It is updated every 5 minutes.

The database schema is described in postpass-ops/SCHEMA.md.

You can send complex queries which need a lot of computation, or which return a lot of data. Requests are sorted into 3 queues: small, medium and large. Before actually executing the query, the computational cost is estimated and the query is assigned to one of the queues. There are limits how many requests can run in parallel for each queue. Large requests may have to wait in the queue, while small, quick requests are allowed to bypass them.

Performance

Database Index

A database, such as PostgreSQL, can only respond fast if the query makes use of an index. If the database cannot utilise an index to answer a query, it must do an expensive full table scan, meaning it has to look at every single thing in the table to find out if it matches a search condition.

Usually, a spatial filter (geom && YOUR_BOUNDING_BOX_GOES_HERE) makes the database utilise a spatial index. If you query data worldwide only by its tags, you should use the @> operator. On `postpass.geofabrik.de` there is a GIN index on `tags`, and PostgreSQL can only use this index for some JSONB operations, (documented here).

You can replace tags->>'key'='value' with tags @> '{"key":"value"}'::jsonb and it should use the tags index.

Materialized Views

If you use a WHERE condition that first applies a function to the geometry, like WHERE ST_Centroid(geom) ... or WHERE ST_X(geom) ... or so, then PostGIS will not be able to use the geometry index and your queries will be slow. In such a case, think about whether you can supply an additional restriction (... AND geom && ...) to limit the query to an area of interest.

PostgreSQL is not a “sequential programming language”, but this can be simulated with WITH Queries (Common Table Expressions), e.g. WITH table1 AS (SELECT ...), table2 AS (SELECT ... FROM table2 ...) select * from table2. Include MATERIALIZED for this table to “saved” (for the duration of the query). e.g WITH table1 AS MATERIALIZED (… This can speed up your query by forcing PG to calculate intermediate steps. (cf. pg docs)

Distance and area calculations

While the Postpass software itself is projection-agnostic, the particular instance hosted on postpass.geofabrik.de stores geometries in EPSG:4326 (i.e. unprojected latitude/longitude values). This means that any length, area, or distance calculations will be in degrees (or square degrees). At the equator, one degree has exactly 60 nautical miles (approx. 100km). Degrees of longitude correspond to fewer km the more you go away from the equator.

For rough calculations, unless you're very close to the poles, you can work with the "1 degree = 100km" assumptions, e.g. to find stuff within 100 metres, use ST_DWITHIN with a value of 0.001. If you need more precise distances, pre-filter with a too large degree value and then compute the exact length, area, or distance with ST_LENGTH, ST_AREA, or ST_DISTANCE while casting the geometry to a Geography data type (e.g. ST_LENGTH(geom::geography)). This yields precise values in (square) metres.

See also

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Postpass&oldid=3063945"