2021-10-27 21:59:45 +03:00
|
|
|
This chapter describes the various operations the Nominatim database administrator
|
|
|
|
may use to clean and maintain the database. None of these operations is mandatory
|
|
|
|
but they may help improve the performance and accuracy of results.
|
|
|
|
|
|
|
|
|
|
|
|
## Updating postcodes
|
|
|
|
|
|
|
|
Command: `nominatim refresh --postcodes`
|
|
|
|
|
|
|
|
Postcode centroids (aka 'calculated postcodes') are generated by looking at all
|
|
|
|
postcodes of a country, grouping them and calculating the geometric centroid.
|
|
|
|
There is currently no logic to deal with extreme outliers (typos or other
|
|
|
|
mistakes in OSM data). There is also no check if a postcodes adheres to a
|
|
|
|
country's format, e.g. if Swiss postcodes are 4 digits.
|
|
|
|
|
|
|
|
When running regular updates, postcodes results can be improved by running
|
|
|
|
this command on a regular basis. Note that only the postcode table and the
|
|
|
|
postcode search terms are updated. The postcode that is assigned to each place
|
|
|
|
is only updated when the place is updated.
|
|
|
|
|
|
|
|
The command takes around 70min to run on the planet and needs ca. 40GB of
|
|
|
|
temporary disk space.
|
|
|
|
|
|
|
|
|
|
|
|
## Updating word counts
|
|
|
|
|
|
|
|
Command: `nominatim refresh --word-counts`
|
|
|
|
|
|
|
|
Nominatim keeps frequency statistics about all search terms it indexes. These
|
|
|
|
statistics are currently used to optimise queries to the database. Thus better
|
|
|
|
statistics mean better performance. Word counts are created once after import
|
|
|
|
and are usually sufficient even when running regular updates. You might want
|
|
|
|
to rerun the statistics computation when adding larger amounts of new data,
|
|
|
|
for example, when adding an additional country via `nominatim add-data`.
|
|
|
|
|
|
|
|
|
2022-04-14 16:10:24 +03:00
|
|
|
## Forcing recomputation of places and areas
|
|
|
|
|
|
|
|
Command: `nominatim refresh --data-object [NWR]<id> --data-area [NWR]<id>`
|
|
|
|
|
|
|
|
When running replication updates, Nominatim tries to recompute the search
|
|
|
|
and address information for all places that are affected by a change. But it
|
|
|
|
needs to restrict the total number of changes to make sure it can keep up
|
|
|
|
with the minutely updates. Therefore it will refrain from propagating changes
|
|
|
|
that affect a lot of objects.
|
|
|
|
|
|
|
|
The administrator may force an update of places in the database.
|
|
|
|
`nominatim refresh --data-object` invalidates a single OSM object.
|
|
|
|
`nominatim refresh --data-area` invalidates an OSM object and all dependent
|
|
|
|
objects. That are usually the places that inside its area or around the
|
|
|
|
center of the object. Both commands expect the OSM object as an argument
|
|
|
|
of the form OSM type + OSM id. The type must be `N` (node), `W` (way) or
|
|
|
|
`R` (relation).
|
|
|
|
|
|
|
|
After invalidating the object, indexing must be run again. If continuous
|
|
|
|
update are running in the background, the objects will be recomputed together
|
|
|
|
with the next round of updates. Otherwise you need to run `nominatim index`
|
|
|
|
to finish the recomputation.
|
|
|
|
|
|
|
|
|
2021-10-27 21:59:45 +03:00
|
|
|
## Removing large deleted objects
|
|
|
|
|
2023-10-20 22:31:55 +03:00
|
|
|
Command: `nominatim admin --clean-deleted <PostgreSQL Time Interval>`
|
2023-10-18 09:03:17 +03:00
|
|
|
|
2021-10-27 21:59:45 +03:00
|
|
|
Nominatim refuses to delete very large areas because often these deletions are
|
|
|
|
accidental and are reverted within hours. Instead the deletions are logged in
|
|
|
|
the `import_polygon_delete` table and left to the administrator to clean up.
|
|
|
|
|
2023-10-20 22:31:55 +03:00
|
|
|
To run this command you will need to pass a PostgreSQL time interval. For example to
|
|
|
|
delete any objects that have been deleted more than a month ago you would run:
|
|
|
|
`nominatim admin --clean-deleted '1 month'`
|
2021-10-27 21:59:45 +03:00
|
|
|
|