Merge pull request #2027 from lonvia/remove-duplicate-admin-boundaries

Handle duplicated admin boundaries

use highest admin boundary for duplicated ones

disable admin level 5 in Russia

They either interfere with cities or refer to historical boundaries.

minor fixes for geometry compuation during boundary ranking

Go back to using centroid when determining if one admin level
is within another. There are cases where boundaries are slightly
misaligned due to mapping errors (not using the same ways in the
relations).

Only declare boundaries the same when they have the same wikidata
tag _and_ have exactly the same geometry. This works around tagging
errors with the wikidata tag, which happen because of automated
edits to the wikidata tag.

detect and remove admin boundary duplicates

The Polish community maps admin boundaries that span multiple
levels by duplicating the boundary relations. Detect this situation
by looking out for matching wikidata tags. The higher ranked
duplicates are then thrown out from the address pool by setting
their address rank to 0.

Merge pull request #2029 from lonvia/master

Switch CI to github actions

switch CI badge to github actions

switch CI to github acitons

Merge pull request #2025 from lonvia/fix-secondary-importance-for-countries

Improve secondary result ordering for administrative boundaries

adjust secondary order when no addressimportance available

In cases of countries and remote places without an address
it is possible that 'addressimportance' comes back empty.
Adjust the 'foundorder' to the places importance instead
in such cases.

Fixes #2023.

readd boundary:administrative to class importance

Merge pull request #2022 from lonvia/populate-rank-25

reorganize ranks of high-level place types

reorganize ranks of high-level place types

Rank 25 is now available for places that should appear in addresses
but not when a street is present. Use this for som block-like
place types. Also document the particularity of rank 25.

subdevisions and allotments are now at the same level as landuse
which they are frequently used together with.

Merge pull request #2019 from lonvia/find-pgconfig-inpostgresql-repo

Add support for finding pg_config in Postgresql repos

add support for finding pg_config in Postgresql repos

It uses the same PostgreSQL_ADDITIONAL_VERSIONS variable as
osm2pgsql so that setting that should be sufficient to make
it work.

Merge pull request #2018 from lonvia/update-osm2pgsql

Update to latest osm2pgsql

update to latest osm2pgsql

Important changes:

* fix disabling of JIT in Postgresql
* support for finding latests Postgresql from their repos
* no longer create nodes table with flatnodes

add explicit bbox contains check

Now that the containment check uses ST_Relate, we need to add
a separate bbox contains check to ensure that Postgis does the
efficient check first. Note that we still cannot get rid of the
overlap(&&) check because then Postgis will use the wrong indexes.

Merge pull request #2016 from lonvia/locale-address-russia

add country-specific address ranks for Russia

Merge pull request #2015 from lonvia/cleanup-address-computation

Rework collection of address parts

add country-specific address ranks for Russia

Removes admin level 7, which should not exist and promotes
admin level 8 to municipality level.

place=municipality is only used for boroughs of St. Petersburg,
so demote to level 18.

Fixes #926.

add tests for rank computation

add tests for address computation

revert to && comparison for geometries

Postgis 3 picks the wrong index when using ~ or @.

use computed centroid for location_area_large

The new address computation assumes that the centroid is inside
the area. Therefore we cannot use the centroid function. Use the
pre-computed centroid instead which has already been corrected to
be inside the area.

correctly set from area column in place_addressline

This was always set to true which brings us to the question
if it is even still needed.

fix use of geometry operators

@ is contained by while ~ is contains.

demote admin boundaries for place areas

Also demote the address rank of an admin boundary when there
is a place area of higher rank that completely contains the
area. This catches the case where city boundaries do not exactly
align with administrative units (see for example Moscow).

exclude rank 25 when computing addresses of streets

Address rank 25 is used for squares which are address-wise on the
same level as streets.

overhaul address computation

This is a complete rewrite of the selection of address parts to
be inserted into the place_addressline table.

The new algorithm selects for each rank:
* the boundary overlapping with the addressee and contained
  in the already selected boundaries of lower rank, or failing that
* the place node closest to the addressee that is contained in
  the already selected boundaries and in the influence radius
  of already selected place nodes of lower rank

Place nodes that are not contained in already selected boundaries
of lower rank are completely thrown away. All other candidates are
added as non-address parts.

move ordering out of getNearFeatures

The two places where the function is called have different ordering
requirement.

Merge pull request #2012 from lonvia/format-reverse-debug-output

use Debug class for formatting reverse debug output

use Debug class for formatting reverse debug output

Merge pull request #2011 from lonvia/increase-city-radius

Increase radius of influence around city nodes

increase radius of influence around city nodes

The current radius does not cover cities with more than a
million inhabitants well.

Merge pull request #2004 from lonvia/demote-place-nodes-in-admin-areas

demote place nodes in admin areas

when linking always check against original address rank

make housenumber interpolation tests more lenient

demote place nodes in admin areas

If a place node of city rank and above finds itself in an
administrative boundary of the same address rank, then
increase the address rank by 2. This catches the rather
frequent case where city suburbs are tagged for historical
reasons as towns or villages.

Merge pull request #2008 from lonvia/docs-missing-index-migration

docs: migration to new wikipedia needs new index

docs: migration to new wikipedia needs new index

Fixes #1998.

Merge pull request #2006 from mtmail/ubuntu-20-postgresql-contrib

Ubuntu 20: use postgresql-contrib-12 so no version higher gets installed

Merge pull request #2003 from lonvia/admin-levels-indonesia

Adapt address levels for admin boundaries in Indonesia

Ubuntu 20: use postgresql-contrib-12 so no version higher gets installed

adapt address levels for admin boundaries in Indonesia

Merge pull request #2002 from lonvia/analyse-indexing-script

Add script for detailed explaing of indexing trigger

add script for detailed explaing of indexing trigger

Merge pull request #1996 from lonvia/remove-postcode-search-structured

Restrict postcode searches to postcode in first token

restrict postcode searches to postcode in first token

In structured queries we should only assume that it is
a postcode search when only the postcode and optionally
the country is given. If any other term is present, it
is better to avoid the search for postcode as it yields
too many bad searches. Given that the terms in a structured
query are ordered, this means that the postcode must be
the first token just like in the unstructured query.

Fixes #1988.

Revert "adapt tests to rank_search removal"

This reverts commit 2a717da8508ed697bfe6f5eded4e397054570a7a.

Merge pull request #1995 from lonvia/update-osm2pgsql

update to latest osm2pgsql version

update to latest osm2pgsql version

The latest version of osm2pgsql no longer creates indexes on
the members of planet_osm_rels. So we do that ourselves.
Given that we only need to access associated street relations,
the index can become quite a bit smaller.

Merge pull request #1986 from mtmail/document-drop-idx_placex_geometry_reverse_lookupPoint

migration guide: idx_placex_geometry_reverse_lookupPoint can be dropped

Merge pull request #1993 from mtmail/country-name-eSwatini

country names: Swaziland => eSwatini

country names: Swaziland => eSwatini

migration guide: idx_placex_geometry_reverse_lookupPoint can be dropped

Merge pull request #1984 from lonvia/remove-reverse-index

Remove unused idx_placex_geometry_reverse_lookupPoint

remove removed index from database check

remove unused idx_placex_geometry_reverse_lookupPoint

The index has been unused ever since the query using it was
changed two years ago. Given that it has not been missed much,
drop it completely here.

Merge pull request #1982 from lonvia/more-rank-search-removal

More rank search removal

adapt tests to rank_search removal

Remove more rank_search usage from address computation

Fixes #1904.

Merge pull request #1980 from lonvia/add-descriptive-term-for-address-rank-24

add descriptive term for address rank 24

add descriptive term for address rank 24

With that term we have terms for all ranks, so that no generic
'administrative' term will show up in the address details anymore.

Merge pull request #1975 from lonvia/simplify-parent-assignment-for-unlisted-places

Use closest containing place area for parent of unlisted addr:place

Merge pull request #1970 from lonvia/remove-duplicate-geometry-check

Switch recursive updates to using rank_search

use rank_address when invalidating containing objects

Only rank_address is now relevant for determining if a place
could be part of an address.

remove ST_Covers check when also testing for ST_Intersects

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.

use closest containing place for unlisted addr:place

We can't use getNearFeatures() to determine the parent of a
place with an unlisted addr:place because this function
returns place nodes that are potentially outside the area
of interest. Doing the complete address computation is too
expensive, so simply use the area with the largest rank that
contains the feature instead.

Merge pull request #1974 from lonvia/show-unknown-addr-place

add unknown addr:place to address output

add unknown addr:place to address output

When a POI has no addr:street but an addr:place that is not
contained in the name list of the parent place, then remember
this situation and merge the content of addr:place into the
address output.

We don't need to care about translations in this case because
it is obvious that no object with translations exists if the
parent isn't the object named in addr:place.

Merge pull request #1971 from lonvia/drop-support-for-isin

Drop support for is_in tag

Merge pull request #1972 from lonvia/exclude-unnamed-highway-areas

Exclude unnamed highway areas

exclude unnamed highway areas

These are used to mark large paved areas. Sometimes they exists
together with named regular streets. In such cases the unnamed
area may overshadow the actual street when computing the address
parent. As unnamed highways are not very useful anyway, we
simply remove them from the database.

remove test for is_in

drop suport for is_in tag

Merge pull request #1965 from lonvia/make-addr-tags-searchable

Make addresses searchable by their addr: tags

Merge pull request #1966 from lonvia/remove-dead-code

remove dead code

remove dead code

The SQL query has moved into the addTokensFromDB() funtion.

always bind addr:place to place instead of street

If an addr:place is given but no addr:street tag, then bind
the rank 30 object always to a <=25 object, even when there
is none found with the same name.

merge addr tags into search_name table

When a place of rank 30 has addr tags that are not covered by the
search terms of the parent, add a separate entry for the POI in
the search_name table that includes the addr tags. We can only
do that with named places. For POIs without a name the housenumber
is used as name. If that is not available either, searching still
won't work.

Merge pull request #1964 from lonvia/remove-postcodes-with-colon

ignore postcodes with colons

ignore postcodes with colons

Colons are used as a delimiter in tiger:left and tiger:right tags
when multiple postcodes are given. Ignore those. This was already
done in the postcode update script. This changes just makes the
two places consistent where postcodes are added.

Update broken links in documentation

Merge pull request #1963 from lonvia/remove-postcodes-from-search-index

Remove postcodes from search index

remove special casing for rank 25 postcodes

They can be computed like any other place.

use same label for all types of postcode in address

remove postcodes entirely from indexing

place=postcode places are artificial places that collect addr:postcode
points for aggration. They should neither show up in the address nor
be searchable. That means that there is no need to index them at all.
Only let boundary=postal_code through which define correct areas for
postcodes.

postal boundary may be imported without name

Postal boundaries usually just have the postcode tag set and are
therefore officially 'nameless'. We want to have them as
boundary=postal_code anyways in order to distiguish them from postcode
points inherited from addr: tags.

Merge pull request #1961 from lonvia/set-place-type-for-result-in-address

Use place type of for result object in address parts

Merge pull request #1960 from lonvia/fix-postcodes-duplicated-by-normalization

Make sure that all postcodes have an entry in the word table

Merge pull request #1957 from lonvia/docs-separate-out-deployment

Restructure vagrant scripts and installation documentation

Merge pull request #1962 from mtmail/travis-ci-without-webserver

travis-ci: we dont need Apache installed

travis-ci: we dont need Apache installed

use place type of for result object in address parts

Boundaries shound derive the address part type from the
linked place if possible. This was already implemented
for the address objects but not for the address information
from the address itself.

Fixes #1949.

make sure that all postcodes have an entry in word

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.

Merge pull request #1945 from mtmail/travis-ubuntu-20

Upgrade Travis-CI from Ubuntu 18 to 20

docs: fix formatting

restructure developer's manual

Add a section on setting up the development environment which now
also includes the former chapter on recreating the documentation.
Move the README from test/ into the manual as the new Testing
chapter.

make CentOS 8 the default vagrant script

This puts it in line with the Ubunutu scripts.