Geocode millions of addresses without sending one outside your infrastructure.

August 2026 pre-release

Two measurements, kept apart on purpose. The first compares three services on one 1,200-row hybrid corpus; the second is a separate, smaller corpus whose coordinates are established as independent of OSM and of the registries we index. Same metric in both: hit@1 within 300 m, empty answers counted as misses.

Hybrid run — 2026-08-04, 1,200 rows

Result SHA-256 4158865253d072f40bc1f2cacfe1c7f3380d11e84c54356b527ab12ad7851ac9, corpus SHA-256 d62033a60c434fe1d9a8937681cb014e8d2f75bccb934df465a791dda227433f. All three services measured in one run, on the sheets this release ships. Read it split by where the answer key came from — the two halves do not say the same thing.

On the OSM half we are 10.4 points behind Photon and 7.3 behind Nominatim. On the Overture half we are 19.0 points ahead of Photon and 12.0 ahead of Nominatim. Both halves are descriptive: no cell here is eligible for a headline, and five sixths of the corpus is the first row, which is why the mixed 1,200-row total often quoted as “the” number — GridPin 85.500%, Photon 91.000%, Nominatim 89.583% — mostly measures the first row. Per country the picture is: Photon leads the mixed total, France and Italy; in the Netherlands Photon and Nominatim tie at the top; in Serbia we are above Photon but below Nominatim. No country row has GridPin ahead of both.

Strict POI run — 2026-08-05, 230 rows (a different corpus)

A separate measurement, not a third row of the run above: another corpus, another day, 230 rows instead of 1,200. It exists because the hybrid corpus is five sixths OSM-derived, so no cell there is eligible for a headline. This one is built from the single coordinate provider whose independence from OSM and from the registries we index is established — Foursquare-sourced Overture Places rows. That is the claim the evidence supports; independence from everything is not. All 230 rows are outside_chain — FR 43, IT 129, NL 17, RS 41 — and this is the cap-respecting maximum available. Result SHA-256: 03a227a79967c1f41bb49a9f4c2c5228e69e1b8c15e1d80c2f9a2f70ee040d28, generated 2026-08-05.

The two comparisons do not carry the same weight, and we do not blur the difference. Against Photon the lead is significant at the conventional 5% level. Against Nominatim it is not: p = 0.0652 means the direction favours GridPin while the evidence remains insufficient, so we make no claim of superiority over Nominatim from this run. The corpus comes from a single provider and its rows are places, not street addresses: this measures an adjacent capability, not general address accuracy. Italy contributes 129 of the 230 rows, so the total leans on our weakest country.

Exact GridPin sheet identity

Result SHA-256: 4158865253d072f40bc1f2cacfe1c7f3380d11e84c54356b527ab12ad7851ac9, generated 2026-08-04. These are the sheets this release ships — the hashes above match the published files byte for byte, so the run can be repeated on exactly the measured data. Photon 1.2.0 (git c6dc628a) was self-hosted, not the public demo, imported from the published planet dump with -country-codes fr,it,nl,rs and languages en,fr,it,nl,sr; its sealed response cache SHA-256 is 83b99805cddd0aabafe4847830bf430b9cc5ee7e478068ffb087a5fd6b994d83. Nominatim 5.3.0 (database 5.3.99-1, data_updated 2026-08-04) was queried once through the public endpoint at a 1.5 s sequential pause with an identifying User-Agent; its sealed cache SHA-256 is 9a071a3e12c45e2f9d550b2a35db2d7ac4fca07b075f38f49983af959b19789c. Both competitors hold newer data than the compared sheets (2026-06-12/2026-06-17.0); this was not corrected for.

Public benchmark by disclosed lineage

outside_chain means a directly evidenced coordinate source outside the known sheet chain; common_upstream names a known shared ancestor; unknown_lineage is deliberately fail-closed. Empty class slices are reported as null, never as zero.

Lineage is disclosure, not a blanket independence badge. The known common ancestors are BAN for France; ANNCSU or OpenAddresses for Italy; BAG/Kadaster or OpenAddresses for the Netherlands; and RGZ or OpenAddresses for Serbia. OSM-derived rows remain unknown and also favour the OSM-backed comparators. Alsace, Isole, and Drenthe are regional rather than national OSM extracts (Serbia is country-wide); both source and geography limits must stay beside the numbers.

geocoder-tester interoperability

geocoder-tester is an external compatibility fixture suite, not a geocoder, address database, or accuracy oracle. Tested upstream identity: 5384d1534bc3c59e8d280be3d951a92356ce470b.

This is not a full-suite pass. The one-case smoke proves that the forward response is consumable and house-number output is no longer the universal blocker. The remaining 55 mismatches prove that full component compatibility is still incomplete. Accuracy comes from the separate coordinate benchmark above, not from geocoder-tester.
Reproducibility: hybrid run 2026-08-07 (230/285), tested binary SHA-256 47a6ecf2cee6835dec7c7dd2fb331ebb5c8708f084e3b02f6bb5239b6e2103b8; adapter-only baseline 208/285; historical 173/285 (2026-08-02) and 0/285 (2026-08-01). Full JUnit/report hashes in docs-public/BENCHMARK.md.

Registry-reference benchmark (Tier 1, France)

Truth: national BAN registry. Recall@1 on clean and typo-mangled queries; median coordinate error on hits.

Read this before quoting the gap. Most of the difference is data, not algorithms. Photon geocodes OpenStreetMap; GridPin ships the BAN registry itself. An evaluation whose ground truth is the registry inherently favors registry-backed data. This table shows what you get when the registry is the truth you care about — it does not show that GridPin's matching is 55 points smarter than Photon's.

POI queries pilot (France)

Queries: place name + city. Truth: Wikidata coordinates. GridPin uses the optional POI layer (231 MB, Overture places).

Photon is stronger on POI queries today. The GridPin POI layer is opt-in and young; 49% within 500 m is where it stands, not where it claims to be. We publish this number for the same reason we publish the one above: per-release, on a fixed set.

How fast, honestly

Single arm64 laptop core, one thread, France sheet, warm mmap. Speed depends entirely on query shape: an exact match is an FST lookup, while a typo is answered by exploring edit-distance variants — hundreds of times more work.

Fuzzy matching is the slow path, and it is our headline feature — so we say so. Feed messy input through geocode_many() or the batch command, which spread work across every core. Making the fuzzy path itself faster is on the roadmap; until it lands we would rather you size for tens of fuzzy queries per second per core than be surprised in production.

What we measure, and against what truth

A geocoder benchmark is defined by two choices: what counts as the ground truth, and how messy the queries are. We keep those choices explicit and report two tiers.

Reproduce it yourself

The offline contract does not depend on private sets or network services. It tests the observer and failure modes, not product accuracy. Repeating the pre-release comparison additionally needs the retained schema-v4 truth corpus, the four exact candidate release sheets, and a selected competitor with retained identity evidence and raw responses.

$ git clone https://github.com/gridpin/gridpin
$ cd gridpin
$ make public-bench-contract

The corpus recipe, supplied-sheet command, license review and exact post-release route are in docs-public/BENCHMARK.md. This measurement is bound to local sheet SHA-256 values and embedded source releases. The clean-clone route is documented in docs-public/BENCHMARK.md, and the sheet builds named in the identity table above are the ones v0.1.0 ships: the four SHA-256 values match byte for byte, so the published sheets reproduce these numbers exactly. The existing make smoke target still builds Monaco and runs the end-to-end engine checks used by CI.

What this page will grow to include

Questions about the methodology: contact@gridpin.dev.