Simon Will [Tue, 5 May 2020 21:10:35 +0000 (23:10 +0200)]
Add vagrant machine for Ubuntu 20.04
The instructions in
[`VAGRANT.md`](https://github.com/osm-search/Nominatim/blob/42c80893cb1038e21c05c2d0d30e3a7a20f0fa26/VAGRANT.md)
still work as before. The names of the Vagrant machines are updated so
that Ubuntu 18.04 (previously called `ubuntu`) is now called `ubuntu18`
and Ubuntu 20.04 is now called `ubuntu20`.
The version changes from Ubuntu 18.04 to Ubuntu 20.04 are:
- Python: 3.6 to 3.8
- Postgres: 10 to 12
- PHP: 7.2 to 7.4
In the `apt-get`, I changed `--force` to `--allow-downgrades --allow-remove-essential --allow-change-held-packages`, because the former is deprecated. Cf. the [manpage of apt-get](http://manpages.ubuntu.com/manpages/focal/man8/apt-get.8.html)
The php module `codesniffer` was previously installed via Composer, but it is available via the Ubuntu repository, so I installed it via `apt-get` now.
Sarah Hoffmann [Tue, 14 Apr 2020 15:14:20 +0000 (17:14 +0200)]
downgrade waterways
A lot of streams in OSM are of minor importance, they certainly
should show up lower in the list of results than villages. Those
rivers/streams that are well known have a wikipedia page and get
a higher importance from that.
The disadvantage with downgrading is that the address gets even
more useless but that's something that needs to be solved outside
the rank search.
Sarah Hoffmann [Wed, 8 Apr 2020 08:04:49 +0000 (10:04 +0200)]
address ranks must not invert admin_level hierarchy
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.
Sarah Hoffmann [Sat, 11 Apr 2020 07:20:13 +0000 (09:20 +0200)]
reset address and search ranks on update
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.
Sarah Hoffmann [Wed, 1 Apr 2020 09:12:52 +0000 (11:12 +0200)]
determine geocodejson address by rank instead of type
Using the address rank to set the address parts catches
a much wider variety of types like 'town' and 'suburb'.
With recent address ranking changes the rank ranges
are relatively reliable.
Sarah Hoffmann [Sun, 29 Mar 2020 18:49:35 +0000 (20:49 +0200)]
rather use new place_type in getAddressNames()
If for a boundary the place_type is defined, handle the address
part like a place node. This is the same behaviour as before
when class/type where patched earlier.
Sarah Hoffmann [Sun, 29 Mar 2020 15:40:56 +0000 (17:40 +0200)]
Fix address link for boundaries in details
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.
Sarah Hoffmann [Sat, 21 Mar 2020 21:43:28 +0000 (22:43 +0100)]
use wikidata tag for linking places
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.
Sarah Hoffmann [Sat, 21 Mar 2020 20:59:11 +0000 (21:59 +0100)]
remove linking via admin_centre role
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.
Sarah Hoffmann [Sat, 21 Mar 2020 20:57:04 +0000 (21:57 +0100)]
linking: better name matching for address-less places
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.
Sarah Hoffmann [Wed, 4 Mar 2020 08:59:57 +0000 (09:59 +0100)]
linked centroids must always be within geometry
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.