Make jump to coordinates accept unsplit coordinates

[felagund]

CTRL+J opens a dialog that allows one to put in coordinates. It works but is inefficient:

1) Latitude and Longtitude are separate. However, I usually paste the coordinates from another program, so I have something like “-71.44939,-44.15408” in my clipboard. I need to manually split it, which takes time.

2) Unhelpfully on Linux, when either of the two fields gets focus, there is a prefilled value, which gets selected, causing the prefilled value to get to X clipboard (the one accessed by selecting text, not pressing CTRL+C), erasing the value I just wanted to paste.

It would be great if the dialog just accepted coordinates like "-71.44939,-44.15408" directly.

Also see discussion here, I am apparently not the only one trying to get around this: ​https://community.openstreetmap.org/t/efficient-way-to-jump-to-coordinates-in-josm/113228

[stoecker]

Your request is not as easy as it seems. JOSM already supports a bunch of formats in clipboard which have both values in one string, see trunk/src/org/openstreetmap/josm/tools/OsmUrlToBounds.java​. The most known ist the #map= from openstreetmap page.

Others are with bbox or min/max+lat/lon or geo: format.

The format you suggest is simply not usable, because it isn't defined enough. There are people using lat,lon and others are using lon,lat. There is no way for JOSM to reliable detect what's meant and we don't want to add heuristics that may guess, as this will only produce much more trouble.

If you can suggest another strictly defined format we can add this. Otherwise this is a WONTFIX.

[GerdP]

I also prefer to use Shift+D (Add node) since that dialog accepts many formats, but it requires a data layer.
I'll attach a small patch which tries to parse the place field in the same way as Shift+D in preference to the call of nominatim.

[GerdP]

try to interpret the place name as lat lon pair before asking Nominatim for a result (ignores Zoom field)

[GerdP]

Replying to stoecker:

The format you suggest is simply not usable, because it isn't defined enough. There are people using lat,lon and others are using lon,lat. There is no way for JOSM to reliable detect what's meant and we don't want to add heuristics that may guess, as this will only produce much more trouble.

The given format is accepted by LatLonParser.parse().

[GerdP]

Problem with -71.44939,-44.15408 is that it is not obvious whether this means lat=-71.44939 and lon=-44.15408 or vice versa.
With the patch JOSM jumps to a place in the ocean, not to this node ​https://www.osm.org/node/402088091.

[stoecker]

LatLonParser is currently only called in situations where the order is defined. You'd extend this to a place where it is not.

[GerdP]

Yes, that's true. Probably Shift+D only works for me because my lat/lon pairs are in the correct order.

[felagund]

TL;DR what about adding a radio button to choose either "lat/lon" or "lon/lat"? (ideally it would remember the last order selected). That would also be helpful for SHIFT+D.

Longer version:
Indeed, the Add Node/Shift+S dalog is much better for my needs. It would make sense to me if these two would reuse their component or were even combined into one dialog on different tabs (still activable with separate shorcuts for each tab, or possibly one could have "add node at coordinates" checked). However, that seems like a major undertaking.

A simpler thing, even for Add Node, it would make a lot of sense to me if the order of Lat/Lon was configurable. I guess an ideal situation would be that CTRL+J accepts what SHIFT+D accepts. Either merge Latitude and Longtitute into one field or add a third Lat/Lon field. Either solution could then have a radio button with either "Lat/Lon" or "Lon/Lat" which would govern how to interpret ambigious coordinates (about half of examples in the Shift+D dialog are ambigious). Such a button would also be helpful in the the SHIFT+D dialog.

I did some reading now and while Lat/Lon is the standard, this is not adhered to universally:
​https://docs.geotools.org/latest/userguide/library/referencing/order.html
​https://stackoverflow.com/questions/7309121/preferred-order-of-writing-latitude-longitude-tuples-in-gis-services

Specifically my coordinates come from a KML file which uses the reverse order (oddly enough, user output from Google Maps gives the correct order). And I guess KML si not going anywhere soon so there are always going to be times when the reverse order is used.

In any case, even without specifying the order, having one field that accepts both lon and lat would be very helpful on its own. I assume people often paste these values and they get them as a pair and splitting them manually is a lot of effort.

[stoecker]

We could extend the dialog a bit so that Lat and Lon fields are more intelligent.

• If you paste one of the accepted formats of LatLonParser into lon fields it's handled as lon/lat
• If you paste one of the accepted formats of LatLonParser into lat fields it's handled as lat/lon

Needs to ignore a leftover number in the other field or clear it when combined format is detected.

This could also extend lat/lon fields to more possible formats of LatLonParser, as currently it only accepts a number.

[felagund]

Yes, that would be an improvemet, but it would still not help with reversed coordinates (which are a fact of life, it seems).

Is there big value in having the lon/lat fields separate anyway? Especially since there is the other dialog (SHIFT+D) that has only one field, it seems inconsistent to me.

[stoecker]

Replying to felagund:

Yes, that would be an improvemet, but it would still not help with reversed coordinates (which are a fact of life, it seems).

Why not?

Is there big value in having the lon/lat fields separate anyway? Especially since there is the other dialog (SHIFT+D) that has only one field, it seems inconsistent to me.

Different methods are for different users. It's one of the JOSM philosophies that TIMTOWTDI. Everybody is happy with something else.

[felagund]

Replying to stoecker:

Replying to felagund:

Yes, that would be an improvemet, but it would still not help with reversed coordinates (which are a fact of life, it seems).

Why not?

Well, if I have the coordiantes in Lon/Lat, it will still disinterpret them, no? The more I think about it, a radio button letting the user select the order seems like the best solution.

Is there big value in having the lon/lat fields separate anyway? Especially since there is the other dialog (SHIFT+D) that has only one field, it seems inconsistent to me.

Different methods are for different users. It's one of the JOSM philosophies that TIMTOWTDI. Everybody is happy with something else.

I am ok with that. That is why I suggested creating a third combined field. Pasting it twice is ok, but not terribly discoverable. Also that brings me to the issue 2) I mentioned - when you paste from X Primary selection instead of clipboard, the value you want to paste get overwritten. That values are prepopulated does not seem very fortunate to me.

[stoecker]

Replying to felagund:

Well, if I have the coordiantes in Lon/Lat, it will still disinterpret them, no? The more I think about it, a radio button letting the user select the order seems like the best solution.

Quoting myself:

If you paste one of the accepted formats of LatLonParser into lon fields it's handled as lon/lat
If you paste one of the accepted formats of LatLonParser into lat fields it's handled as lat/lon

[felagund]

Aha, sorry, I did not read it thouroughly enough and misunderstood. So it would populate the other field. That would indeed be clever and useful.

However it is very unintuitive, I would never expect it to work that way. It would need to have some hint into the interface that the field behave like that (I really like that SHIFT+D has extensive documentation of what formats it accepts).

What do you think about the fields being prepopulated by the last searched-for-value? It is distinctly unhelpful to my usecase, under TIMTOWTDI, a checkbox "remember last used position" would solve that.

[katpatuka]

see also #6429 (opened 13 years ago - sigh!)

A solution concerning the problem with lat/lon and lon/lat could be accomplished similar to how wikimapia handles coordinate locations to search for:

Example: 27.4955, 11.0089

• Go to this location: 7839 km
  

11.0089 N, 27.4955. E (coord.)

• Go to this location: 8650 km
  

27.4955. N, 11.0089 E (coord.)