Geocoder data needs improvement


OSM Geocoder data contains name of area and point, which gives inaccurate information. In cases where name of an Area is present (classified such as Borough, neighbourhood), please ignore a Point which is classified as same.

For example: 25.111187, 55.369215

Geocoder data: Access to Nad al Sheba Army Camp & Qeuepoint, Liwan, Nadd Al Sheba 4, Dubai, United Arab Emirates

Here are the details of the above data:

Street: Access to Nad al Sheba Army Camp & Qeuepoint
Point1: Liwan
Point2: Nadd Al Sheba 4
City: Dubai
Country: United Arab Emirates

Now, name of the Area that is saved as “Liwan Queue Point” is not displayed at all, which is much more important. Also, Point2 is not relevant here, and also it creates confusion, as name of this area is not as displayed.

There is another suggestion: geocoder data should mention “x Kms NW of Point1”, “y Kms from Point2” which removes such confusion or contradictory data.

It’s not clear whether you are talking about the data or the Nominatim algorithms. You control the data, although you must not change in in a way that loses information or misrepresents the real world, even if that would result in Nominatim producing better results. The data must be correct, even if rendered maps, routers, reverse geocoders, etc. produce unsatisfactory results.

Also the feature that Nominatim is finding has a very unlikely name. It looks like a description, and names should not be used to contain descriptions, only the official name. Quite likely it has no official name, but if it does, I would expect that to be in Arabic, as I would expect for the all the other features in this area. I suspect a destination tag would be more appropriate here.

It is also mainly outside the the area for the suburb, so it seems reasonable that it is not being associated with the suburb. Although I’m not sure how Nominatim handles administrative boundaries, typically if you want a feature to be definitely associated with some region, you need to use is_in tags, on the feature itself.

Also, there are two conflicting claims to be the name of the neighbourhood, the second being Liwan. Only local knowledge can resolve whether one is a duplicate of the other or whether one should be coded as a smaller type of unit than the other, so it not possible to say whether one should be removed, or simply re-tagged. If you don’t have sufficient local knowledge, the best option is to add a map note pointing out the conflict and asking for someone with local knowledge to resolve it.

My guess is that Nominatim has tried to find the nearest named road or POI to the position, then reported the containment information for that feature. As the feature is mainly outside the area, it has used the, more fuzzy, point as its way of matching it to a containing area.

“Pool Bar & Lounge” (together with most of the other features in its immediate area) and “Faculty and Student Parking” also look like they are descriptions being mi-used as a names.

Yes, I am talking about Nominatim algorithms. I have good local knowledge and as per the example that I provided, Point1 is accurate, as the coordinates are “Near” Point one. Why display Point2 which is not at all near the place?

Hence, would it be possible to display only ONE nearest Point (in my example, “Point1”) and omit “Point2”?

Also, as Point1 is nearby, mention as “‘Near’ Point1”?

How are you accessing Nominatim? Using the search facility on only returns your point 1. Using only returns the Liwan neighbourhood place node.

Using the API directly, with the the query string reverse?lat=25.111187&lon=55.369215 only produces your point 1. Specifying zoom=15, produces Liwan. zoom=13 produces your point 2. These all seem to represent a level of detail consistent with the zoom level. It looks to me as though you have done searches at two different zoom levels an got results appropriate to those two levels. I think, in all cases, once Nominatim has identified an object, the “address” information reflects that specific object.

Generally, though, I doubt that anyone familiar with the inner workings of Nominatim, reads this forum. There is a bug tracker, but I’m not sure that a bug report is going to be useful just based on anecdotal evidence. One really needs to understand the algorithm and propose a better one. The source code is available.