Geocoding engine should omit or demote historic names

Consider a query for: Lausanne

Request URL:[YOUR_KEY]&q=Lausanne&debug=true

3rd result is Ancien district de Lausanne (English: “Former district of Lausanne”) with:

osm_id: 6205453
osm_key: "boundary"
osm_type: "R"
osm_value: "historic"

In my opinion, such result with osm_value: "historic" should not appear, or if it does, it should be ranked last, after all current (non historic) results.

By the way, is the GraphHopper internal geocoding engine open source? I didn’t find it on GitHub.

Thanks! Why do you think it should be ranked lower? Isn’t historic an important POI?

And yes it is open source, see here for a detailed comparison.

An historic POI, with the historic key (not value) (osm_key in the GraphHopper geocoder) as described on the Historic wiki article, is important and should indeed be returned by the geocoder. These are features that still exist today and with some historic interest.

I’m talking here about the historic value (not key) (osm_value in the GraphHopper geocoder), present with some keys. These are features that do not exist anymore in the real world, that will never be displayed on a map. It is very unlikely that a user is actually searching for them.

There exists various keys that can receive an historic value to mean that the entity does not exist any more. In my specific example, we have the boundary=historic tag. See the feature on OSM:

Also seen on this example, another way to detect an historic feature that does not exist any more is the presence of the end_date key, here end_date=2007.

The improvement I suggest is that the geocoder ignores such features that do not exist any more, or ranks them very low, after real world features.

Looking at the Photon documentation, I discovered that adding &osm_tag=:!historic in the URL of a Photon query will omit results with osm_value=historic, which is exactly what I want.

Adding the same parameter to the GraphHopper Geocoding API query does have same effect. Great. Example URL:[YOUR_KEY]&q=Lausanne&osm_tag=:!historic&debug=true

However, this is an undocumented feature. Is this intended, and can I rely on it in the future?

Some parameters are not identical in GraphHopper Geocoding API and Photon, like locale vs lang for the language, or point vs lat and lon for the location bias. Is the code from GraphHopper Geocoding API where Photon queries are created available?

1 Like

Thanks, this is useful!

Still I would like to have an improved version of it where one could also combine osm tags e.g. :city OR :hamlet. I’ll discuss if we should still include this in our public API.

BTW: We used the different API parameters to make them align with our other APIs where e.g. point and locale exists.