|
I want to set up a simple reverse geocoding system and was thinking of using osm2pgsql to import the data (possibly of the whole planet). I noticed that the data is very large and slow to import. Is it possible to import just the street data required to perform reverse geocoding? If yes how do I go about it, and how do I go about maintaining the database up to date (with osmosis or any alternative) without importing buildings or POIs which are not needed for reverse geocoding? My intention of course is to keep the database size down to only the data I need. |
|
The main OpenStreetMap geocoder, Nominatim, is relatively complex and uses much more than just street data. You will likely re-invent the wheel when you build your own (reverse) geocoder, and you'll make a couple mistakes that Nominatim has made and learnt from in the past. But if you really want to set up your own:
Note however that this approach will not give you house numbers or an admin hierarchy, i.e. you will be able to find out that a given location is in "Main Street" but not which city, county, country (or post code for that matter). If you want the admin hierarchy, you have to import Thanks for your reply. In actual fact I would like to use Nominatim, but I was wondering if I can remove stuff which is not needed, like building information, points of interest etc. to reduce the database size. I only need reverse geocoding (not geocoding). I had a look at Nominatim's reverse geocoder and it seems to be just an sql query, enlarging the diameter iteratively if the initial query doesn't return any results from the My application is related to transportation movement tracking, so going down to the granularity of house number is not really needed (at least not at this point). I will need village, city, country etc. of course. Would Nominatim still work if I only import highways, administrative boundaries and maybe the special land use residential boundaries?
(02 Feb '17, 10:24)
jbx1
1
I agree with Frederick's approach. By default Nominatim also fills search index tables only used for forward search (think: word => list of places). The logic is too deep in the import and data update steps that it can't be easily disabled. And while deleting the (for reverse unused) tables after the initial update would work the updates would fail. As Richard points out have a look at Photon, I think there's monthly data dumps to import now. Takes 60GB disc space.
(02 Feb '17, 11:16)
mtmail
|
|
You may find it easiest to set up a local instance of Photon (https://github.com/komoot/photon), which has reverse geocoding capabilities and for which you can download pre-made data dumps. Note however that Photon development appears to be rather in abeyance. |
