"Nominatim lite" for reverse geocoding only?

[lukehutch]

I need to implement reverse geocoding on my server, but I don't want to use a full Nominatim installation. I only need to be able to convert GPS coords into a hierarchy of place designations (continent, country, state/province, city, town).

Is there a way to extract just a set of hierarchically-nested place designation polygons, so that this sort of search can be implemented in a lightweight way? If standalone code doesn't exist to do this sort of simple reverse geocoding search, I can write the code, I just need to get the polygons exported first.

This is a common need for e.g. mobile apps, so it may be useful to create a "Nominatum lite" that supports only this functionality. (Reverse geocoding is much simpler than forward geocoding...)

[mtmail]

You can setup a reverse-only Nominatim and skip streets and housenumbers https://nominatim.org/release-docs/latest/admin/Import/#reverse-only-imports The database size will be significantly smaller.

[lonvia]

Also worth noting here are last years experiments to create an even more simpler-to-use SQLite database, see https://nominatim.org/2023/10/25/sqlite-reverse.html. The 'admin' database mentioned in the test would be exactly what you are looking for. I also gave a talk about it at Sotm EU.

To use the code on mobile, you likely need a Java reimplementation of the reverse search algorithm. It shoudn't be too hard to do. The entry point for it is at

Nominatim/nominatim/api/reverse.py

Line 552 in 7321e66

async def lookup(self, coord: AnyPoint) -> Optional[nres.ReverseResult]:

All code for this is available on the master branch, so feel free to experiment with it. I'm looking forward for feedback.

[lukehutch]

Thank you @lonvia for these links! This is pretty awesome. Although I'm surprised that the SQLite query performance is so much worse than that of Postgres. The spatial extension for SQLite must not be very efficient.

I spent all day looking into how to export the OSM boundaries for countries, administrative areas, and localities, because I was going to write my own lightweight reverse geocoder. In the end I couldn't get the data easily in the format I needed, so I gave up, and for now I'm using the platform geocoder built into Android and iOS. I may return to this project in the future. However I will share my idea for it here, since I think this could be a really fun project:

I was planning to find a multi-resolution geohash cover of every boundary polygon, i.e. subdivide the tree of geohashes when they overlap a boundary, at each one of the address levels (country, admin region, locality). At some finest geohash level, the point at the center of the geohash will be tested to see if it is inside or outside a region's boundary.

The leaves of the tree are now the geohashes at the largest possible size that fits fully within a boundary, for a given address level. These geohashes are stored as keys in the database, with the geographical region as values.

Now the process of looking up an address level consists of geohashing the target location at the finest geohash level, then running an IN SET query with all prefix substrings of that geohash, to find the leaf node for that address level (e.g. WHERE "geohash" IN SET ('q23zj', 'q23z', 'q23', 'q2', 'q')). Since the leaves of the trees are the largest fully-contained geohash area within a boundary for the given address level, that query will return just one result (or zero).

Repeat for all three address levels (or just look up the locality, and use relation data to get the containing admin region and country).

I suspect this will give a speed of thousands of QPS. Additionally, the raw data will be able to be exported to a simple CSV file. There is no spatial database needed, so this data can be directly imported into SQLite. Code to run reverse geoqueries in this way could easily be written for many programming languages.