Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DMS rounding errors, display truncation; expand DMS syntax #5144

Closed
skylerbunny opened this issue Jul 14, 2018 · 4 comments · Fixed by #10066
Closed

DMS rounding errors, display truncation; expand DMS syntax #5144

skylerbunny opened this issue Jul 14, 2018 · 4 comments · Fixed by #10066
Labels
help wanted For intermediate contributors, requires investigation or knowledge of iD code new-feature A new feature for iD

Comments

@skylerbunny
Copy link

Much to my (pleasant) surprise, I discovered that it is in fact possible to paste a DMS lat/lon into the iD search box, because I dug deep enough to find this change, 702e3d2 .

The trouble is as it is now, it seems to accept exactly one (undocumemted) format for such a cut/paste. It is:

[D]DD°MM'SS.[S]"[NS],[D]DD°MM'SS.[S]"[EW]

There are a few issues I've identified:

  1. If you enter a location with a negative rather than NSEW, it is actually converted and centered incorrectly:

45°,-90°0'0.5" (to be 45,89°59'59.? W, so it's subtracting wrong somewhere)

  1. Location display rounding is performed around certain cases that shouldn't be, as implied by the above:
    45°,90°0'0.9" shows as 45°N,90° (seems that < 1 second is just dropped from the display)
    45°,90°0'1" shows as 45°N,90°0'1" (that's actually correct!)
    45°,90°0'1.1" still autocompletes as 45°,90°0'1" (display not correct because decimals are dropped, but I think the centering is right)

(1) and (2) make it difficult to assume that the entry of a dms style coordinate pair 'works' correctly, either because it's displayed with bad rounding, or it actually centers on the wrong place.

  1. I guess this is technically an RFE, but I'll toss it in if people are working on the above as defects anyway:
    It would be really awesome if one could paste a dms that looks like this, because it's really common to see done like this:
    45 0 18.229944, -90 19 0.4445 (or) 45 0 18.229944 N, 90 19 0.4445 W
@skylerbunny
Copy link
Author

I mentioned (3) above because otherwise, the only viable way of putting in a DMS location into the search box is by using the extended character '°', which might not be easily guessed. If a pair of decimals can be discerned by the engine to be a decimal coordinate pair, I'm assuming 'three whitespace separated numbers within the constrants of -90/90, 0-60, 0.60,-180/180, 0-60, 0.60 might also be without too much trouble.

@bhousel bhousel added the new-feature A new feature for iD label Jul 14, 2018
@bhousel
Copy link
Member

bhousel commented Aug 25, 2018

Good suggestions, this relates to #5214

@bhousel bhousel added the help wanted For intermediate contributors, requires investigation or knowledge of iD code label Aug 25, 2018
@1ec5
Copy link
Collaborator

1ec5 commented Aug 28, 2018

In #4672 I was only trying to use DMS format for display, but it’s a happy coincidence that it works at all as input, hence the requirement to use proper typographic characters ° ′ ″ rather than o ' ".

@skylerbunny
Copy link
Author

Oh, no worries, I'm absolutely with you on that statement, and you have nothing to defend! The reason I opened this is, "because it IS possible to use DMS as an input to the search box", I've identified bugs with doing so translating between the input and what the system browses to as the actual point.

It's kind of an accidental feature, but knowing this, it's a good idea to either fix bugs relating to using it, or disable it in the search to avoid that, IMO.

Generalizing the input allowed for a valid DMS search would be nice as well, of course. But I had no expectation that it should or does "just work that way" on day one or anything.

laigyu added a commit to laigyu/iD that referenced this issue Jan 13, 2024
re:openstreetmap#5144

Sec 15.56 -> 15.6 , 15.55-> 15.5

Most DMS format parsed by @mapbox/sexagesimal,
add a expandable matcher and two new format to cover some
@1ec5 1ec5 linked a pull request Jan 13, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted For intermediate contributors, requires investigation or knowledge of iD code new-feature A new feature for iD
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants