Find location field requires long-lat sequence

[beamblitz]

in order to correctly navigate to the desired location, i find i have to input the longitude prior to the latitude.

using the coordinates 48.284086, 38.023027 as an example, this is the desired location:

https://www.google.com/maps/place/48%C2%B017'02.7%22N+38%C2%B001'22.9%22E/@48.2840833,38.0230278,17z/data=!3m1!4b1!4m4!3m3!8m2!3d48.2840833!4d38.0230278?entry=ttu

however, this is the location i end up being served:

https://www.google.com/maps/place/38%C2%B001'22.9%22N+48%C2%B017'02.7%22E/@38.023027,48.2815111,17z/data=!3m1!4b1!4m4!3m3!8m2!3d38.023027!4d48.284086?entry=ttu

here's a screenshot (kinda) showing the issue. obviously the coords aren't preserved in the input field after searching, but i pasted the ones i used there for demonstration purposes: https://i.imgur.com/m9FhBd3.png

i'm not familiar with node.js, so i can't say for sure where the issue is, let alone confidently open a PR, but based on the lng, lat order, i suspect the issue might lie here:

osm-search/frontend/src/components/SearchResults.vue

Line 69 in 9b387c3

coordinates: [f.lng, f.lat],

[GalenReich]

Thanks for your issue @beamblitz and for doing some initial investigation, it was helpful for duplicating the behaviour and finding the cause.

Firstly, I can confirm that the 'Find location' field expects Long/Lat if you use coordinates to search (you can also use full place names/addresses).

This comes about because many mapping services use Long/Lat format. The line of code you point to is respecting that format when generating a KML file for export. This tool uses Mapbox under the hood, which also uses Long/Lat format.

The client queries mapbox directly with the search_text as a parameter:

osm-search/frontend/src/store/index.js

Line 215 in 9b387c3

`https://api.mapbox.com/geocoding/v5/mapbox.places/${search_text}.json?access_token=${process.env.VUE_APP_MAPBOX_TOKEN}`

This is a usability issue for people when copying Lat/Long from Google Maps (and others?), perhaps the solution would be to add a separate location search field that is specifically for Lat/Long, which transposes the fields before hitting the Mapbox API.

@loganwilliams do you have any thoughts?

[loganwilliams]

It seems the Mapbox geocoder doesn't handle raw coordinates well (it's meant more for addresses.) In general there isn't really a standard for lat,lng or lng,lat -- most software uses lng,lat because it follows x,y conventions, but lat,lng is common for communication. It's ambiguous unless you specify northing/easting/etc. However, Mapbox doesn't like these either.

Most coordinates that people would be copying and pasting are in lat,lng order -- so I could add something to detect if it's two numbers with a comma in between and if so skip the Mapbox geocoder and just use those coordinates.

[beamblitz]

Yeah, if that isn't too much trouble, that would be great! Or reordering the lat-long array, or something. That said, if it's a heavy lift and it's a rare type of search, it's not the end of the world to keep what I'm doing and flip the lat-long order to conduct a search, and it's probably relatively easy to figure out what's going on for other users. I didn't realize that long-lat was in common use in software contexts.