Repository navigation
Missing admin_level=2 boundaries for some countries (US, France) — no country_code returned #53
Description
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
preparescript, then a single
import --memory 14g --threads 6run 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, CAActual 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.
Activity
dgraf-gh commentedon Aug 5, 2026
Hi @altmarksch,
Thank you for the detailed report. I will check that out.
Did you try them against geo.dedicatedcode.com? Just out of curiosity, could be related how the country pbf exports are handled. I normally only import the planet.pbf file.I tested it against
https://geo.dedicatedcode.com/api/v1/reverse?lat=45.5152&lon=-122.6784&limit=1As you wrote:
My theory is that during the import (maybe of the multi polygon nature) the admin_level 2 relation is not successfully matched against the poi. Or the other way around, we try to find all containing relations for a poi to connect them together.
Having prepared exports somewhere hosted would be nice but I have no place right now. I already used up my cloudflare storage for the upcoming spatial coverage feature for reitti. Then there is the need to run multiple exports at once somewhere. Right now I do the planet (roughly once per month) on my home server and upload it. This takes around 12h plus 2h downloading and uploading the files.
bugfix(#53): improve hierarchy handling in ImportService and add deta…
bugfix(#53): improve hierarchy handling in ImportService and add deta…
dgraf-gh commentedon Aug 5, 2026
Hi @altmarksch,
I believe I fixed the issue. At least I could reproduce this with the monaco.pbf export. What happened during the monaco import was the following:
I changed the code to strip out the boundaries. If you want to test that alongside with me, you can switch to the
developdocker tag. I am currently started a new planet import, as soon as this is done and looks good, I will create a new version.dgraf-gh commentedon Aug 6, 2026
This did not help in resolving that issue. In parallel I fixed #55 maybe that could have been another reason why it did not find the hierarchy. Unfortunately I was to fast with my planet import so this did not made it in the build.
I will verify if that helped, else I need to look further
altmarksch commentedon Aug 6, 2026
dgraf-gh commentedon Aug 9, 2026
So, the import with the fixed boundaries finished but did not help with the resolution of the admin level 2.
On my way to find the smallest region possible to reproduce this, these are the results by manually checking the latest import.
So, from the first look:
New Zealand:
dgraf-gh commentedon Aug 9, 2026
So, the current working theory of the failure is that if affects every country which crosses the anitmeridian (180°E/W)
The HierarchyCache breaks when calculating the boundaries of that.
dgraf-gh commentedon Aug 11, 2026
Hi @altmarksch,
that was the actual reason and is now fixed. I will issue a new version today.