False return of "district" for suburb in geocodejson

[bogatkaj]

Hey,

i found a problem with the definition of district in geocodejson and OSM.

In the geocodejson spec "district" means a district containing multiple cities (ref: https://github.com/geocoders/geocodejson-spec/tree/master/draft -> Feature Object), while in OSM it isn't fully clear as it seams that a suburb is classified as district.

Example:
Daverden in Lower Saxony, Germany is a suburb of Langwedel (german: Eingemeindete Ortschaft in den Flecken Langwedel im Rahmen der Gebietsreformen), when using this prompt:

https://nominatim.openstreetmap.org/search?q=Spiridonweg&accept-language=de%2Cde-DE%2Cen-US%2Cen&format=geocodejson&addressdetails=1

which searches for a street in Langwedel, it returns Daverden as district, which is a higher administrative level than Langwedel, what isn't correct.

I don't know if this is problem of Nominatim or OSM.
I already searched for an administrativ border of Daverden in OSM, but it doesn't seems to exist.
Also I don't have a map of the borders of Daverden, so I can't create it myself to correct this behavior.

Any ideas? Am I missing something?

[mtmail]

How the place is mapped in OSM looks alright.

That looks like the mapping of place type to field name (district) needs to be improved here. The configuration is in https://github.com/osm-search/Nominatim/blob/master/settings/address-levels.json but I don't see an obvious mistake. In the file district has the same rank as county (roughly: Nominatim uses rank 0 to 30, if you're familiar with OSM admin_level values, it's often admin_level multiplied by 2). Note that later in the file there's a section for overrides for Germany.

With suburbs as nodes Nominatim needs to guess to which suburb a street belongs (by distance).

I once used trash collecting street list (Müllabfuhrkalender) to figure out which street belongs to which suburb to create a boundary. The district issue here would be the same with a node or relation/boundary.

[bogatkaj]

Thanks for the fast reply, I've taken a look at the linked file and can't find a mistake either.

So do you have any idea where this problem can come from?
I'm currently looking for a feasible source of the boundaries and also wrote to the history club of Daverden if they may have a map.

[mtmail]

Based on geocoders/geocodejson-spec#10 Nominatim's 'district' field means 'city district'. I think the geocodejson spec needs to be updated. If I recall the specs were written after several geocoders already defined their output format. An official spec, for example from the OGC, would be more strict, the geocodejson one isn't used a lot. Nominatim uses it in a test suite for example.

also wrote to the history club of Daverden if they may have a map

Thanks for the initiative. I had some luck with a map of a golf course and a camping ground once. But unlucky with others who never replied.

[bogatkaj]

Yeah, that seems right, I also fond a bug in the way we parse the address in our program, which gave me somee extra headaches...

Thanks for your investigation and time!

P.S.: I also got no reply yet, maybe I'll find another way, also I have a direct line to the EMS-dispatch, maybe they have a map showing this border.

P.P.S:
I found the borders as WFS / WMS Layer for Lower Saxony at the LGLN as Verwaltungsgrenzen -> Gemarkungen if someone else will be searching this in the future.
Daverden is now added with commit 175090738.