search

komoot / photon

an open source geocoder for openstreetmap data
Apache License 2.0
1.89k stars 280 forks source link

Nominatim postcodes missing in Photon #310

Open hbruch opened 6 years ago

hbruch commented 6 years ago

The following Photon UK postcode searches return better matches in Nominatim.

When I view the Nominatim result's html source, I see the search finds a place:postcode, e.g.

...
{
        "osm_type": "P",
        "osm_id": "82631",
        "class": "place",
        "type": "postcode",
        "admin_level": null,
        "rank_search": "25",
        "rank_address": "5",
        "place_id": "181154732",
        "parent_place_id": "179866619",
        "housenumber": null,
        "country_code": "gb",
        "langaddress": "South Gloucestershire, BS15 4TA, Vereinigtes K\u00f6nigreich",
        "placename": "BS15 4TA",
        "ref": "BS15 4TA",
        "lon": "-2.489309238268",
        "lat": "51.475183842419",
        "importance": 0.23125,
        "addressimportance": "8.83048074613031",
        "extra_place": null,
        "addresstype": "place",
        "aBoundingBox": [
            "51.475133842419",
            "51.475233842419",
            "-2.489359238268",
            "-2.489259238268"
        ],
        "label": "Postcode",
        "name": "South Gloucestershire, BS15 4TA, Vereinigtes K\u00f6nigreich",
        "foundorder": -0.85464807461303
    }
...

However, the details link for the above place_id=181154732 does not show the expected place:postcode but a boundary:administrative.

The reverse geocoding request in Photon neither returns the expected place.

Seems to me, that the Nominatim place_id is not unique (@lonvia, could you confirm this?).

Should this hold true, Photon will overwrite Nominatim places, as the ES document UId is deduced from the Nominatim place id and hence the place:postcode would not exist in the Photon index.

hbruch commented 6 years ago

Nominatim place_ids are unique, but Photon currently does not import places from Nominatim's location_postcode table.

lonvia commented 6 years ago

Postcodes are complicated. Usually there is no single object in OSM which describes a single postcode, so when Nominatim returns a postcode result, it is from the location_postcode tables of artificial postcode centroids. They do have a unique place id, but no separate details page, i.e. when you ask for details you get those of the parent boundary. You can think about importing location_postcode but you should consider de-duplicating the postcodes which do have an OSM object first.

As for the UK, it is treated a bit special because Nominatim can use an external postcode source for it to augment the location_postcode table with postcodes that are missing in OSM. Same is true for the US.

Note that the introduction of the location_postcode table means a bit of a regression for photon because the artificial postcodes used to be in the placex table and therefore be imported.

smithfred commented 3 years ago

Given that geolocation from post codes using open data is a now a solved problem, as demonstrated postcodes.io, which is itself is an open source (see #593), is there something blocking Photon from duplicating postcodes.io's approach, or otherwise implementing complete GB post code geolocation?

The current GB geolocation capabilities of Photon make for a very poor downstream experience in applications like GNOME Maps.

lonvia commented 3 years ago

As usually with these things: the main blocker is a lack of people willing to make PRs.