Search by latitude & longitude succeeds inconsistently #2366
Comments
|
We do already accept a large number of versions as you can see from the large number of tests starting at https://github.com/openstreetmap/openstreetmap-website/blob/master/test/controllers/geocoder_controller_test.rb#L49 but there is a fairly large number of possibilities. Reasonable patches to extend what can be recognised would of course be welcome. |
|
I suspect your main problem may be putting the cardinal direction after the number rather than before judging by the tests? There are some with it after though so not entirely sure. |
|
Two of your examples (the second and third) actually work anyway! |
|
As noted in the report: this sometimes (often?) works, but occasionally does not, despite the format being so far as I can tell consistent across entries.
I'm usually copying lat/lon values from https://earth.nullschool.org/, a weather/climate/atmospheric conditions visualiser. so human error and inconsistency shoudn't be a factor.
I opened the issue after mentioning this earlier on Mastodon, at request. I'll update with specific examples which don't work. This may be a transient bug.
Thanks.
…-- Edward Morbius ([email protected]) Dr. Edward Morbius's Lair of the Id https://dredmorbius.reddit.com
Sent from ProtonMail mobile
|
|
Also mixing decimals degrees and then adding in minutes and seconds via sexagesimal notation seems a little odd... |
|
It's not going to be transient. |
|
I've not been able to identify any clear pattern to what does or doesn't work.
The examples are all specifications of latitude / longitude that I'd expect would work.
…-- Edward Morbius ([email protected]) Dr. Edward Morbius's Lair of the Id https://dredmorbius.reddit.com
Sent from ProtonMail mobile
-------- Original Message --------
On Sep 3, 2019, 04:42, Tom Hughes wrote:
I suspect your main problem may be putting the cardinal direction after the number rather than before judging by the tests?
—
You are receiving this because you authored the thread.
Reply to this email directly, [view it on GitHub](#2366?email_source=notifications&email_token=ABJRRYSQPT327S7XHVHQDQDQHYWP5A5CNFSM4ITD7VR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5XUHHI#issuecomment-527385501), or [mute the thread](https://github.com/notifications/unsubscribe-auth/ABJRRYRG35G7EXWFICO4PJDQHYWP5ANCNFSM4ITD7VRQ).
|
Wups. That was an error on my part, I've edited & corrected the issue. |
|
An example of a failed lookup:
|
|
The actual code is at https://github.com/openstreetmap/openstreetmap-website/blob/master/app/controllers/geocoder_controller.rb#L293 and as you can see the patterns we recognise are already pretty... complicated... I think the only two of your examples which don't work are the first one, because we don't allow a degree symbol when using decimal degrees, and the last one because we don't allow use of +/- when using sexagesimal notation - we expect N/S/E/W instead. |
|
Example of a successful lookup:
|
|
it seems you only get results if there are OSM objects close to the
coordinates you search for. Maybe nominatim could add the coordinate pair
as first result regardless of other results?
It also seems optimizable that you search with very low precision like
41.8° N, 12.5° E
and the only result you get is a living street:
https://nominatim.openstreetmap.org/search.php?q=41.8%C2%B0+N%2C+12.5%C2%B0+E&polygon_geojson=1&exclude_place_ids=105327361&accept-language=en-US%2Cen%3Bq%3D0.8%2Cde%3Bq%3D0.5%2Cit%3Bq%3D0.3
Doing more tests, there appears to be a bug in Nominatim, I never find
"more results" than 1 if I search for coordinates. And there's an issue
with priority and scope (precision of coordinates relating to importance of
objects), I tried to "find" Rome by adding the place coordinates, but only
got results of relatively minor pois:
Here's Rome in OSM:
https://www.openstreetmap.org/node/72959652
41.893° N, 12.483° E
https://nominatim.openstreetmap.org/search.php?q=41.893%C2%B0+N%2C+12.483%C2%B0+E&polygon_geojson=1&viewbox=
(finds a place=quarter, Nominatim admin level 15,
https://www.openstreetmap.org/relation/5454237 )
The almost same query, 41.895° N same lon, finds a public artwork:
https://nominatim.openstreetmap.org/search.php?q=41.895%C2%B0+N%2C+12.483%C2%B0+E&polygon_geojson=1&viewbox=
41.89° N, 12.48° E
https://nominatim.openstreetmap.org/search.php?q=41.89%C2%B0+N%2C+12.48%C2%B0+E&polygon_geojson=1&viewbox=
finds another place=quarter, https://www.openstreetmap.org/relation/5454276
)
41.90° N, 12.49° E
https://nominatim.openstreetmap.org/search.php?q=41.90%C2%B0+N%2C+12.49%C2%B0+E&polygon_geojson=1&viewbox=
Finds a museum (Palazzo delle Esposizioni
https://www.openstreetmap.org/way/51930840 )
although there is also a place=quarter relation for the containing area:
https://www.openstreetmap.org/relation/5451988
41.9° N, 12.5° E
https://nominatim.openstreetmap.org/search.php?q=41.9%C2%B0+N%2C+12.5%C2%B0+E&polygon_geojson=1&viewbox=
Finds again a place=quarter mapped as an area (Rione XVIII Castro Pretorio
(r5454327))
42° N, 13° E
https://nominatim.openstreetmap.org/details.php?place_id=61065000
finds a place=locality
|
|
Please don't confuse matters @dieterdreist. This is talking about coordinate searches, which are done internally by rails and have nothing to do with Nominatim. Yes Nominatim may also give results but the "internal" engine should return a position purely based on the coordinates, which is what we are discussing here. |
|
Not sure whether this is related closely enough, but from the usability perspective it would be great to be more permissive. Manually changing commas to dots works, but isn't something many users would figure out. |
I'll frequently search for a location by latitude and longitude, in either degrees/minutes/seconds, or decimal degrees.
Even using the same format, some queries succeed and display an appropriate map, others fail to find a location.
Search by latitude and longitude should accept reasonably configured inputs, and show the corresponding location on the map.
Examples of input which should be accepted (others may also apply):
Location corresponds to Lake Apopka, north of Winter Garden, FL, USA.
The text was updated successfully, but these errors were encountered: