Wrong state for adresses from Bremen (Germany)

openrouteservice
1

Dear support and community,

we use the ORS Api in one of our business applications to find coordinates to addresses (Geocode Search). Since last week (calendar week 22), in addition to slightly changed coordinates of some test addresses, the following problem has occurred:

The Geocode Search for Bremen addresses currently no longer returns Bremen as the state and the specific district, but e.g. {“region_a” : “NI”, “county” : “Diepholz”} for the postal code 28217.

This poses a problem because it causes some validation checks to fail in our backend. Is this a temporary phenomenon or is there more info if the data sources are currently being switched/updated?

German text:

Lieber Support und liebe Community,

wir nutzen die ORS Api in einer unserer Business-Anwendungen, um unter anderem Koordinaten zu Adressen herauszufinden (Geocode Search).
Seit letzter Woche (Kalenderwoche 22) ist neben leicht geänderten Koordinaten einiger Testadressen folgendes Problem aufgetreten:

Die Geocode-Suche nach Bremer Adressen gibt momentan nicht mehr Bremen als Bundesland und den spezifischen Stadtteil zurück, sondern z.B. {“region_a” : “NI”, “county” : “Diepholz”} für die PLZ 28217.

Das stellt ein Problem dar, weil dadurch einige Validierungsprüfungen in unserem Backend fehlschlagen. Ist das ein vorübergehendes Phänomen oder gibt es nähere Infos, ob die Datenquellen momentan umgestellt/geupdatet werden?

2

Hi @Drizzel,

in the last week the geocoder moved to a different server, updating the datasets in the process.
However, the results should be more up-to-date and better in general.

This is a permanent change, so you should update your validation checks.

But it seems strange, that a request would give a completely different result. Maybe there is some corrupted or missing data…

Could you provide a full request (endpoint + full query - api_key) and if possible also both responses to
ease the investigation of the issue?

Best regards

3

Hi @amandus,

thanks for your quick reply and interesting info! The problem occurs for example with an GET-Request on this route:

https://api.openrouteservice.org/geocode/search?api_key=API_KEY&text=An der Reeperbahn 10 28217 Bremen&boundary.country=DE

The response then is:

{
“geocoding”:{
“version”:“0.2”,
“attribution”:“Terms of Service | Openrouteservice”,
“query”:{
“text”:“An der Reeperbahn 10 28217 Bremen”,
“size”:10,
“private”:false,
“boundary.country”:[
“DEU”
],
“lang”:{
“name”:“English”,
“iso6391”:“en”,
“iso6393”:“eng”,
“via”:“header”,
“defaulted”:false
},
“querySize”:20,
“parser”:“libpostal”,
“parsed_text”:{
“street”:“an der reeperbahn”,
“housenumber”:“10”,
“postalcode”:“28217”,
“city”:“bremen”
}
},
“engine”:{
“name”:“Pelias”,
“author”:“Mapzen”,
“version”:“1.0”
},
“timestamp”:1623077410011
},
“type”:“FeatureCollection”,
“features”:[
{
“type”:“Feature”,
“geometry”:{
“type”:“Point”,
“coordinates”:[
8.782592,
53.085065
]
},
“properties”:{
“id”:“node/6262826216”,
“gid”:“openstreetmap:address:node/6262826216”,
“layer”:“address”,
“source”:“openstreetmap”,
“source_id”:“node/6262826216”,
“name”:“An der Reeperbahn 10”,
“housenumber”:“10”,
“street”:“An der Reeperbahn”,
“postalcode”:“28217”,
“confidence”:1,
“match_type”:“exact”,
“accuracy”:“point”,
“country”:“Germany”,
“country_gid”:“whosonfirst:country:85633111”,
“country_a”:“DEU”,
“region”:“Lower Saxony”,
“region_gid”:“whosonfirst:region:85682555”,
“region_a”:“NI”,
“county”:“Diepholz”,
“county_gid”:“whosonfirst:county:102063967”,
“county_a”:“DE”,
“localadmin”:“Stuhr”,
“localadmin_gid”:“whosonfirst:localadmin:1377686459”,
“locality”:“Bremen”,
“locality_gid”:“whosonfirst:locality:101913887”,
“continent”:“Europe”,
“continent_gid”:“whosonfirst:continent:102191581”,
“label”:“An der Reeperbahn 10, Bremen, NI, Germany”
}
}
],
“bbox”:[
8.782592,
53.085065,
8.782592,
53.085065
]
}

Here you can see that the response contains {“region_a”:“NI”, “county”:“Diepholz”} which is the state of Lower Saxony and not Bremen.

Thanks for your efforts.

Sincerely
Drizzel

4

Hello @amandus

did my answer about the exact request help you? Or is there any new information?

Best Regards
Drizzel

1 Like
5

Hi @Drizzel ,

regarding data basis, we usually work with open data, which we don’t adjust ourselves.
In this case it seems the hierarchy of the Bremen locality is messed up:

The data is this way since over 2 Years. So probably it’s rather a change in how the Pelias engine resolves properties for found adresses.

Anyway i would suggest you correct the whosonfirst entry:
https://github.com/whosonfirst-data/whosonfirst-data-admin-de/blame/cbae015988bae139c3982758bfb167f082c0ebc5/data/101/913/887/101913887.geojson
or open an issue in the repository.

Best regards

1 Like
6

Hi @amandus ,

thank you very much for your feedback. Something must have really changed in Pelias’ search, because the correct whosonfirst entry for Bremen also exists with an other type (but is never found):

How do you correct such an entry? By forking the repository, changing it and then creating a pull request to the original repo?

Best regards
Drizzel

7

Probably, i’m not sure myself, but the maintainers should be able to help.
I don’t know if it’s sufficient to only change the hierarchy in that one file, or if some additional processing needs to be done afterwards.

If you are unsure best open an issue and discuss there.

Best regards

8

Okay. I will see what I can do and create an issue.

Thanks for your efforts so far.

1 Like
9

Dear @amandus

The problem has been fixed by this issue on github.

Thank you for your efforts.

All the best for the future!

Many greetings
Drizzel

1 Like
10

i have a similar issue with Algiers Algeria