Reverse Geolocation for changeset not good enough, translation missing

[manfredbrandl]

After uploading a changeset in Leibnitz, Steiermark (Styria, part of Austria) I see:

The location is Leibnitz (County of Styria and main city there) in the Austrian state of Styria:
https://www.openstreetmap.org/changeset/58159266#map=14/46.7436/15.5616

Koglbauer is the name of a farm and a short road near Leibnitz:
https://www.openstreetmap.org/search?query=koglbauer#map=15/46.7605/15.5298

So Styria is not translated to Steiermark which would be nice and Koglbauer is not apropriate.

[bhousel]

The current code that puts together the location string is here:

iD/modules/modes/save.js

Lines 500 to 511 in 85ae00d

	services.geocoder.reverse(context.map().center(), function(err, result) {
	if (err || !result || !result.address) return;
	var parts = [];
	var addr = result.address;
	var city = addr && (addr.suburb || addr.city || addr.county);
	if (city) parts.push(city);
	var region = addr && (addr.state || addr.country);
	if (region) parts.push(region);
	_location = parts.join(', ');
	});

What the code does is ask Nominatim to reverse geocode the center of the map where the user is looking when they did the save (their edits might not necessarily be there, but this is the place that they are looking at).

We get a result from Nominatim and iD tries to piece it together into something like City, Region..

There are some things we can do to improve this.

1. Can you remember what you were looking at when you clicked save on that edit? If you can give me the lat/long coordinates, I can do the Nominatim lookup again and see what data is returned and maybe pick a better subset of the results, or maybe issue the query better? (BTW, the Location panel does the same lookup - so if you go to the same place and open that up, it should also say something about Koglbauer, Styria and a bunch more).

2. We could query based on the bounding box where the user's changes were, not necessarily the map where the user is looking at when they click Save. I'm not sure whether this would be more confusing to a new user though.

[manfredbrandl]

I tried again and the map contains nearly only "Leibnitz Bahnhof" (railstation):

See https://www.openstreetmap.org/edit#map=20/46.78047/15.54668

[manfredbrandl]

This is shown when i do "Objektabfrage" at the red cross:

Is this "Location Panel lookup"?

[bhousel]

Is this "Location Panel lookup"?

"Location Panel" is this feature in iD (for me it's Cmd+Shift+L to show):

[lakedistrictOSM]

The "thank you for improving the map in..." is a bit hit and miss so far. A changeset I did yesterday gave South Lakeland which is the local admin_level=8 district and is a good enough location to use. But today it incorrectly gave "Warriner Yeat" which is apparently an isolated dwelling 2.5 miles away from my changeset.

How accurate does the location lookup try to be? Using the enclosing admin_level=8 district or the nearest place=town/city would probably do.

[manfredbrandl]

Koglbauer is also an isolated_dwelling:

It would be better not to show isolated_dwellings unless they are very near to the map center.

[skylerbunny]

It would be better not to show isolated_dwellings unless they are very near to the map center.

We get a result from Nominatim and iD tries to piece it together into something...

Doesn't that mean that this is ultimately a problem for Nominatim to solve? All iD is doing is spitting out what Nominatim provides it. If reverse geolocation is finding an isolated dwelling 2.5 miles from where you're editing, that's an issue with them.

It seems like a Really Bad Idea to apply exceptions to what iD says a location "is" as Nominatim gives it, when the appropriate solution is to tell Nominatim to make their RG better. (In fact, an argument can be made that telling iD to make exceptions against Nominatim's RG would actually complicate bug reporting to that project.) Look at it this way: this is bringing visibility to Nominatim's reverse geolocation?

[skylerbunny]

To explain my position here: if you want to cut off what "near" means at a certain admin level, that's one thing. 'We will never show an admin_level lower than 8' in the output, because we'll just assume that 8 is close enough to be friendly to the user.'

It would be quite another to start throwing around 'Well, we'll use an isolated_dwelling with a lower admin level of 15, when you're really editing "close to it", EXCEPT if you're not.'

That second kind of "fix" would really make identifying Nominatim problems that come through that query difficult.

[bhousel]

To explain my position here: if you want to cut off what "near" means at a certain admin level, that's one thing. 'We will never show an admin_level lower than 8' in the output, because we'll just assume that 8 is close enough to be friendly to the user.'

Yes, what you said here is what I would do to fix this issue. I think we can construct our query to Nominatim in way that returns a more regional result.

[bhousel]

Ok, I swapped out suburb for town - this will probably display a more meaningful result on the post-save screen.

For info, here is the query and result. We are already requesting a result at zoom=13, which seems fine.

query:
https://nominatim.openstreetmap.org/reverse?addressdetails=1&format=json&lat=46.7804013&lon=15.5466538&zoom=13

result:

{"place_id":"42083160","licence":"Data © OpenStreetMap contributors, ODbL 1.0. https:\/\/osm.org\/copyright","osm_type":"node","osm_id":"3096751413","lat":"46.7706284","lon":"15.5160898","display_name":"Koglbauer, Leibnitz, Styria, 8430, Austria","address":{"suburb":"Koglbauer","town":"Leibnitz","county":"Leibnitz","state":"Styria","postcode":"8430","country":"Austria","country_code":"at"},"boundingbox":["46.7705284","46.7707284","15.5159898","15.5161898"]}