LoginSign Up
← Back to all sparks
N

Nominatim

DEVOPS
Velocity0.0

Geocoding engine for searching OpenStreetMap data by name and address

nominatim.org ↗

The geocoder finished becoming a Python package, then got back to matching addresses

geocodingopenstreetmappython-packagepostcodesupdate-pipelinequery-parser
◆Current state
Nominatim releases a minor version every few months with fast hotfixes when an update path breaks. The 4.5-to-5.0 span was structural — becoming a pip-installable Python package, then removing the PHP frontend, bundled osm2pgsql and cmake scripts outright. Since then the work has returned to geocoding quality: a pattern-based postcode parser, building entrances in results, a restructured forward query parser, and separate processing tables for postcodes, interpolations and associatedStreet relations.
◆Where it's heading
With the packaging migration finished, the project is optimizing the two things operators actually feel — how fast a search resolves and whether continuous OSM updates keep flowing. The 5.3.0 split into dedicated processing tables was explicitly about making updates faster and more reliable, and the two hotfixes that followed within a fortnight show how tightly that path is watched. Query-side work is trending toward recognizing input that is not in the database at all, as the postcode parser does.
◆Prediction
Expect continued query-parser and update-pipeline optimization rather than new output types, since that is where every release since 5.0.0 has concentrated.

◆Recent moves

  1. 3mo ago

    5.3.2 fixes a non-null constraint error during updates

    A single-issue hotfix for a non-null constraint error that could halt updates on 5.3.x. No database reimport needed, which is the detail operators care about most.

    View source ↗
  2. 4mo ago

    5.3.1 restores usable update speed for associatedStreet relations

    Fixes associatedStreet relation updates being unusably slow in 5.3.0 — a regression severe enough that the notes tell 5.3.0 users to upgrade immediately. It is the cost of the processing-table restructuring that 5.3.0 introduced.

    View source ↗
  3. 4mo ago

    5.3.0 gives postcodes and interpolations their own processing tables

    Restructures how postcodes, interpolations and associatedStreet relations are computed, each getting a separate processing table to make updates faster and more reliable. Also supports addr:interpolation alongside addr:housenumber, and lets the CLI use the layer parameter and add TIGER data to a frozen database.

    View source ↗
  4. 9mo ago

    5.2.0 returns building entrances and cuts SQL round-trips

    Adds entrances of buildings and areas to results, giving routing engines a better start and end point than a building centroid. The forward query parser was also restructured to issue fewer SQL queries per request, with the largest gains on full address searches.

    View source ↗
  5. 1y ago

    5.1.0 recognizes postcodes that aren't in the OSM data

    A pattern-based postcode parser means postcodes no longer need to exist in the OSM database to be found — any string matching a country's postcode format is recognised, with US ZIP+4 the headline case. A meaningful widening of what the geocoder can resolve without more data.

    View source ↗
  6. 1y ago

    5.0.0 removes the PHP frontend, bundled osm2pgsql and cmake

    Completes the migration begun in 4.5.0: Nominatim is now purely a Python package, with the PHP frontend, bundled osm2pgsql and cmake build scripts deleted. The osm2pgsql import style configuration was also largely rewritten, which mainly affects operators maintaining custom styles.

    View source ↗