Using both is slightly problematic because they have different
ways to use the index. Newer versions of Postgis exhibit a
query planner issue when both functions appear together.
As ST_Intersects includes ST_Covers, simply remove the latter.
It may happen that two different postcodes normalize to exactly
the same token. In that case we still need two different entries
in the word table. Token lookup will then make sure that the correct
one is choosen.
Fixes#1953.
When computing the address parts for a geometry, we need to do
a ST_Relates lookup in the location_area_large_* tables. This is
potentially very expensive for geometries with many vertices.
There is already a funtion for splitting large areas to reduce the
impact. This commit reduces the minimum area of a split, effectively
increasing the number of splits.
The effect on database size is minimal (around 3% increase), while
the indexing speed for streets increases by a good 60%.
After 6cc6cf950c names and house numbers
of POIS got mingled into a single item when creating the display name.
Add the house number as extra information without place_id to avoid
later mangling.
There are a couple of places with a search rank < 25 which are
not addressable like waterways and islands. We don't want them
to function as parents for POI-level objects. So use the
address rank for finding parents, not the search rank.
See #1815.
When inheriting an address rank from a linked place we
must be careful not to destroy the hierarchy established
through boundary admin_level. Therefore, before assigning
an address rank from a linked place, find the next higher
boundary in the admin_level hierarchy, look up its address
rank and then only use the address rank from the linked
place if it is higher.
With ranks being dynamically changed through linking of places,
it is important to reset the ranks on update, so that changes
of the rank due to changes in linking are correctly taken into
account.
The order of preference is now:
1. a post code on the place itself
2. a post code area in the address
3. the computed postcode from the place
Fixes#1723.
Removes the special casing for boundaries with a place
type in get_addressdata(). Instead the place type is now
returned as an extra field, so that the caller has to
handle the situation.
This fixes the details link next to the address in the details
view, which previously would go to a place class instead of the
original boundary class.
Having the same wikidata is a strong indicator that the same place
is meant. There are some assignment errors where the wikidata does
not link to the object itself but to something that mentions the
place. To reduce errors there, prefer same name.
The admin_centre role is for the seat of government which is not
the same as the administrative entity. This is mostly used
correctly these days, so avoid matching by that role.
Administrative boundaries that do not figure in the address
should still be able to take part in the name matching.
Use the rank_search for comparison in this case.
This fixes a regression where the area of the lower ranking
area was not computed correctly.
Also excludes postcodes areas now as they have their own
hierarchy.
When using a linked place as centroid for a boundary, check
first that it is really within the area. If it is outside,
just keep the computed centroid because a centroid outside the
area just causes havok.
Fixes#1352.
If a boundary relation has no label member preferably
link against a place node with the same place type.
Also inherit the rank_address from the place node (only
has an effect when linking via lable member or place type).
The function only ever returns one result of which only the
place_id is used. So simplify it to return a single place_id
only (or NULL if none is found).
Also fix typo in function name.
The function only ever returns one result of which only the
place_id is used. So simplify it to return a single place_id
only (or NULL if none is found). Rename funciton to avoid
conflicts when updating an existing database.
Instead of unconditionally parenting them to a street, the
larger areas get a parent area that contains them. To keep
things computationally light-weight, only use the centroid and
bbox to determine if an area is contained.
Requires renaming of parenting functions because renaming
a parameter of the function causes issues when updating the
function (it requires a manual delete, which I'd like to
avoid).
Normally ST_Covers() should include a bbox index use,
so adding a bbox where clause is not really necessary.
However, the query planner messes up and uses a parallel
index search with a second index instead of exclusively
running on the geometry index, when the bbox part is
missing.
When --drop is given, we can remove all node geometry information
already after the import with osm2pgsql. Also drop all unnecessary
tables before creating the final indices.
