Missing admin_level=2 boundaries for some countries (US, France) — no country_code returned
Repo: https://github.com/dedicatedcode/paikka/issues/new
Summary
After a successful self-hosted import, reverse geocoding returns an empty
country_code for places in some countries because the admin_level=2
(country) entry is absent from the returned hierarchy. Other countries in the
same import, from the same continental extract, resolve correctly.
Environment
- Paikka 1.1.7 (
dedicatedcode/paikka:latest), Docker
- Import completed 2026-08-05,
gridLevel: 12, ~100 GB datastore
- Source: 9 Geofabrik continental extracts —
europe, north-america, asia,
south-america, australia-oceania, central-america, plus
africa/south-africa, africa/mozambique, africa/swaziland
- Each filtered with the bundled
prepare script, then a single
import --memory 14g --threads 6 run over all nine files
Reproduction
curl 'http://localhost:8080/api/v1/reverse?lat=45.5152&lon=-122.6784&limit=1' # Portland, US
curl 'http://localhost:8080/api/v1/reverse?lat=48.8700&lon=2.3000&limit=1' # Paris, FR
curl 'http://localhost:8080/api/v1/reverse?lat=49.2827&lon=-123.1207&limit=1' # Vancouver, CA
Actual results
Portland, United States — hierarchy begins at level 4, no country entry:
level 4 Oregon cc=[]
level 6 Multnomah County cc=[]
level 8 Portland cc=[]
level 10 Downtown cc=[]
Paris, France — hierarchy begins at level 3, no country entry:
level 3 France métropolitaine cc=[]
level 4 Île-de-France cc=[]
level 6 Paris cc=[]
level 8 Paris cc=[]
level 10 Quartier des Champs-Élysées cc=[]
Vancouver, Canada — correct, level 2 present:
level 2 Canada cc=[CA]
level 4 British Columbia cc=[]
level 6 Metro Vancouver RD cc=[]
level 8 Vancouver cc=[]
Mexico (MX) and the United Kingdom (GB) also resolve correctly.
Note that Canada, Mexico and the United States all come from the same
north-america extract, so this is not a case of a country being absent from
the source data.
Expected
hierarchy should include an admin_level=2 entry with a populated
country_code for all countries present in the imported extracts.
Impact
In a dataset of 3,390 places spanning six continents, 2,448 (72%) have an empty
country_code — almost entirely US and French locations. Downstream consumers
such as Reitti store this field per place, so it stays blank there too.
Suspected cause
Both /usr/bin/prepare and /usr/bin/prepare-boundaries invoke:
osmium tags-filter "$INPUT_FILE" ... r/boundary=administrative -o "$OUTPUT_FILE"
without the -r / --add-referenced flag. Matching relations are retained, but
the member ways (and their nodes) that define the boundary geometry are not,
unless they happen to match another filter expression. Simple boundaries may
survive incidentally; large multipolygon relations such as the United States
(relation 148838) and France cannot be reassembled.
Adding -r would retain referenced members, at the cost of a larger
intermediate file.
Additional observation
The GeoJSON payload does contain a human-readable country name — e.g.
"country": "New Zealand / Aotearoa" — even where country_code is empty. If
the ISO code cannot always be derived, exposing that string consistently would
still let consumers fall back to something meaningful.
Related feature request
Publishing prepared exports for common region sets would help a lot of
self-hosters. The README notes that prepared data is designed to be portable to
lightweight machines, but building it currently requires a machine most people
don't have — this planet-scale import needed ~20 hours and 24 GB of RAM, and
took three attempts to get the heap and swap configuration right.
Missing admin_level=2 boundaries for some countries (US, France) — no country_code returned
Repo: https://github.com/dedicatedcode/paikka/issues/new
Summary
After a successful self-hosted import, reverse geocoding returns an empty
country_codefor places in some countries because theadmin_level=2(country) entry is absent from the returned
hierarchy. Other countries in thesame import, from the same continental extract, resolve correctly.
Environment
dedicatedcode/paikka:latest), DockergridLevel: 12, ~100 GB datastoreeurope,north-america,asia,south-america,australia-oceania,central-america, plusafrica/south-africa,africa/mozambique,africa/swazilandpreparescript, then a singleimport --memory 14g --threads 6run over all nine filesReproduction
Actual results
Portland, United States — hierarchy begins at level 4, no country entry:
Paris, France — hierarchy begins at level 3, no country entry:
Vancouver, Canada — correct, level 2 present:
Mexico (
MX) and the United Kingdom (GB) also resolve correctly.Note that Canada, Mexico and the United States all come from the same
north-americaextract, so this is not a case of a country being absent fromthe source data.
Expected
hierarchyshould include anadmin_level=2entry with a populatedcountry_codefor all countries present in the imported extracts.Impact
In a dataset of 3,390 places spanning six continents, 2,448 (72%) have an empty
country_code— almost entirely US and French locations. Downstream consumerssuch as Reitti store this field per place, so it stays blank there too.
Suspected cause
Both
/usr/bin/prepareand/usr/bin/prepare-boundariesinvoke:without the
-r/--add-referencedflag. Matching relations are retained, butthe member ways (and their nodes) that define the boundary geometry are not,
unless they happen to match another filter expression. Simple boundaries may
survive incidentally; large multipolygon relations such as the United States
(relation 148838) and France cannot be reassembled.
Adding
-rwould retain referenced members, at the cost of a largerintermediate file.
Additional observation
The GeoJSON payload does contain a human-readable country name — e.g.
"country": "New Zealand / Aotearoa"— even wherecountry_codeis empty. Ifthe ISO code cannot always be derived, exposing that string consistently would
still let consumers fall back to something meaningful.
Related feature request
Publishing prepared exports for common region sets would help a lot of
self-hosters. The README notes that prepared data is designed to be portable to
lightweight machines, but building it currently requires a machine most people
don't have — this planet-scale import needed ~20 hours and 24 GB of RAM, and
took three attempts to get the heap and swap configuration right.