When using an explicit cast to char(1) when refering to the
osm_type column postgres won't use the index in some cases.
Observed only on postgres 9.5 from the original Postgres
reporsitories.
Fixes#741.
Rank 30 has some very large geometries (peninsulas, time zones,
etc.) for which a near feature search for the full geometry is
too expensive, so do the search on the centroid only.
Derived columns are not needed because parent information is
always computed from scratch. So the columns are just duplicate
information.
Also get address information on nodes from address columns. The
other columns are not necessarily reliable when the node have not
been indexed yet.
When roads cross boundaries, both administrative entities should
be added to the address list, so that both entities can be used
for searching. Also allows in a second step to better sort out
addresses of POIs on such roads.
Fixes#121.
The interpolaton computation needs information from the osm2pgsql
slim tables which may not be available when the data is inserted.
Insertion now only adds a line with basic address information to
location_property_osmline. The line is then split during the
indexing, leading to more lines (which are complete in that case)
being inserted.
Fixes#598.
If a country boundary has a country_code that is unknown to
Nominatim, it would delete all names because the coalascing
with country_name would not yield any result.
On placex_update we stop the indexing to the first parent if the rank_search is above 27. We should do the same check in get_adressdata, because place with a rank_address != 30 and a search_rank > 27 will have only 1 parent.
https://github.com/twain47/Nominatim/issues/534
interpolation lines may be missing in osmline when the interpolation
is broken, so we cannot conclude that a way is not in place, just
because there are no entries in location_property_osmline.
It is perfectly valid that interpolated addresses refer to
something else than a street.
Also gets rid of the maximum interpolation size. As we don't
expand, arbitrary sizes are fine.
Introduces two new settings CONST_Use_US_Tiger_Data and
CONST_Use_Aux_Location_data, which are disabled by default.
When false the corresponding tables are ignored in queries
and updates.
Aux and tiger tables are no longer created by default. This
has to be done by the corresponding import scripts. The former
aux table creation can be found in sql/aux_tables.sql for
reference.
Get the version from the database where necessary or simply
probe for existence of features. Fake hstore_to_json when
necessary.
Bumps the minimum required versions fro postgres to 9.1 and
for postgis to 2.0.
When linked the place may not be in the search index,
so it must be reindexed when being unlinked. The status
change will only have an effect during the subsequent
update, so change tests to that effect.
Mainly there to avoid having many duplicated postcode entries
in place_addressline from nodes which have tags where only
addr:postcode is recognized by Nominatim (e.g. fire hydrants).
This allows address interpolations to work correctly when flatnode storage
is used for node coordinates.
To fix interpolations in an existing database, follow these steps:
* invalidate all interpolations (in psql):
`UPDATE placex SET indexed_status=2 WHERE rank_search = 28`
* disable updates:
./utils/setup.php --create-functions --create-partition-functions
* reindex the whole lot:
./utils/update.php --index --index-instances <number of your cpus>
* enable updates again:
./utils/setup.php --create-functions --enable-diff-updates --create-partition-functions
Avoids to a certain extent propagation of misassignment of
partitions when a country is expanded so far into another
that the centroid ends up in this other country.
Also added a sanity check to ensure that accidental removal of admin_level
tags on large areas doesn't cause huge reindexing load. That can be disabled
by setting CONST_Limit_Reindexing to false.
Name of function was changed in postgis 2.1 and now prints ugly
deprecation warnings. For older versions of postgis, function
will be renamed to the new name during the setup of the DB.
To update existing databases with postgis < 2.1 run:
ALTER FUNCTION st_line_interpolate_point(geometry, double precision) RENAME TO ST_LineInterpolatePoint
and then reinstall the SQL functions:
./utils/setup.php --create-functions --enable-diff-updates --create-partition-functions
This might happen for nameless landuse/natural objects that are added to place
during initial import but then dropped when being copied to placex.
If they later receive a name, thus becoming valid, then place_insert should
delete the orphan object in place and reinsert it. If they are large enough,
the place_delete trigger prevents them from being removed. The additional
update fools the delete trigger.
