Detecting the precision seems to be broken horribly in the formatter which is likely a problem of rounding since DMS values are converted to floats.

Another example: 10°1'1"N, 10°1'1"W - setting precision manually to 10° will result in the formatted value 10°1'0.9999999984"N, 10°1'0.9999999984"W.

Query string parameters:
action:wbformatvalue
format:json
datavalue:{"value":{"latitude":1.0169444444444,"longitude":-1.0169444444444,"globe":"http://www.wikidata.org/entity/Q2","precision":1},"type":"globecoordinate"}
options:{"precision":10}
datatype:globe-coordinate

Response:
{"result":"1\u00b01'0.9999999998\"N, 1\u00b01'0.9999999998\"W"}

https://github.com/DataValues/Geo/pull/19#

Fixed in the DataValues/Geo component.

• Bug 66653 has been marked as a duplicate of this bug. ***

Needs a release of DataValue/Geo.

Should be included in https://github.com/DataValues/Geo/releases/tag/1.1.0 already (according to the readme)

Not working: https://www.wikidata.org/w/index.php?title=Q1912804&diff=170553993&oldid=170551126
The cause is that the precision is 0.01667 instead of 0.01666666666666667 when manually set to arcminute. Auto precision is good for nothing. Once it was good. Please restore the old function.

(In reply to tobias.gritschacher from comment #5)

Should be included in https://github.com/DataValues/Geo/releases/tag/1.1.0
already (according to the readme)

(In reply to JulesWinnfield-hu from comment #6)

Not working:
https://www.wikidata.org/w/index.
php?title=Q1912804&diff=170553993&oldid=170551126

Well, https://www.wikidata.org/wiki/Special:Version says
"DataValues Geo 1.0", not 1.1.0, so it *IS* fixed in the codebase I guess.

(In reply to Andre Klapper from comment #7)

Special:Version says "DataValues Geo 1.0"

I'm afraid this is actually a bug, but in an other component, see https://github.com/wmde/ValueView/pull/126

Unfortunately Jules' description is very unclear. (Steps to reproduce? Actual and expected behavior? Did he used the API? Or UI? What "old function" is he referring to?) Please provide mor information if the bug I guessed is not the one you meant. Thanks.

(In reply to Thiemo Mättig from comment #8)
I'm afraid you do not use the Wikidata UI. The coordinates gadget has many issues. Once, before it was ported to backend I think, it worked perfectly fine.
I provided you a link where you can see that display value isn't good, nor the precision.
Expected behavior:

1. Right display value, consistent with precision
2. Auto precision match input precision
3. Displayed precision match stored precision when starting input

Please restore the old function.

(In reply to JulesWinnfield-hu from comment #9)

I'm afraid you do not use the Wikidata UI.

Are you aware I'm a Wikibase frontend developer? Please don't talk to me like this. This is not helpful.

Right display value, consistent with precision

What "display" are you talking about? Consistent with which precision? There are multiple precisions in your example URL.

Auto precision match input precision

What does this mean?

As I said I think the issue you are describing is exactly what my patch above will fix. Would be very much appreciated if you could wait for the deployment on test.wikidata.org (in some days, hopefully) and check if this fixed the issue.

(In reply to Thiemo Mättig from comment #10)
Right now the UI is broken. You can see it at the supplied link. Just two things, 44°38'60"N, 25°19'60"E and 0.01667 Is anybody there who understands auto precision match input precision? Didn't you use the UI when it worked well? What does auto precision mean to you? Please excuse my language because I feel very helpless and frustrated.
Please notify us when you think the UI is working well.

Questions still unanswered: Did you use the API? Or UI? What "old function" - do you imply there was no such issue a while ago? If so, when was that?

(And if you're frustrated, you may want to consider commenting later when you're less frustrated?)

(In reply to Andre Klapper from comment #12)
I used the UI.
The UI worked well in January 2014 https://www.wikidata.org/w/index.php?title=Q516668&diff=97804713&oldid=92709157 Notice that the display value is broken since then.
Why are you asking me these questions as if everything were fine? This is what disturbs me. This is not some kind of hidden bug, it just doesn't work. You can find many examples out there and is not since yesterday.

Questions are asked when something is unclear, for example steps to reproduce, expected outcome, actual outcome.

Let's take it easy folks. No need to be upset :) I will talk the bug through with Thiemo tomorrow. I think I know what's going on.

The patch from https://github.com/DataValues/Geo/pull/19 is contained in the 1.1.0 version of data-values/geo. We are not using this version in Wikibase yet. So this cannot be fixed in production. Wikibase needs to be updated to use the new version and then verified that this actually fixes the problem. Until then, let's calm down.

More patches:
https://github.com/DataValues/Geo/pull/29
https://github.com/wmde/DataValuesJavascript/pull/53

This bug can be closed when:

• https://github.com/DataValues/Geo/pull/29 got merged.
• A new version of data-values/geo has been tagged.
• It has been verified on wikidata.beta.wmflabs.org, that the issues are gone.

(In reply to tobias.gritschacher from comment #18)

This bug can be closed when:

• https://github.com/DataValues/Geo/pull/29 got merged.
• A new version of data-values/geo has been tagged.
• It has been verified on wikidata.beta.wmflabs.org, that the issues are

gone.

1 done. 2 and 3 still to do.

(In reply to tobias.gritschacher from comment #19)

(In reply to tobias.gritschacher from comment #18)

This bug can be closed when:

• https://github.com/DataValues/Geo/pull/29 got merged.
• A new version of data-values/geo has been tagged.
• It has been verified on wikidata.beta.wmflabs.org, that the issues are

gone.

1 done. 2 and 3 still to do.

1 done. 2 done. And deployed to http://wikidata.beta.wmflabs.org.
Can someone please verify that this has been fixed?
Especially @JulesWinnfield-hu.

Closing this as it seems to me it works on e.g. http://wikidata.beta.wmflabs.org/wiki/Q29510. Please note that this will be deployed to test.wikidata.org next week and deployed to wikidata.org in two weeks. So, if you want to test/confirm it, please do so on wikidata.beta.wmflabs.org.

(In reply to tobias.gritschacher from comment #20)

Thank you. It is almost fine. If you set a higher precision (lower value) than the precision of the input value, it breakes the display value.
http://wikidata.beta.wmflabs.org/wiki/Q29510

What does "break" mean? A line break? An unexpected value? Which change (diff) is the relevant one? Can you please, please explain what exactly you did, what the actual result is and what your expected result is?

We think you are referring to the additional zeros at the end of the numbers. This is expected if you set a higher precision. Therefor I'm closing this for now. Feel free to reopen if that's not what you meant. But as I said, please, please provide enough information to help us understand and reproduce the error.

(In reply to Thiemo Mättig from comment #23)

Displays incorrect value. See the history and see the 60s in the place of seconds.

This is not helpful. What does "incorrect" mean? What part of the history? Which diffs are teh relevant ones? What "place of seconds"? In the name of the god you believe on please, please copy and paste the actual output over here and show us what the expected output should be in your opinion.

Jules: https://www.mediawiki.org/wiki/How_to_report_a_bug might have hints how to provide sufficient information for developers. Also note that you can also add comments without changing the status of a bug report.

(In reply to Thiemo Mättig from comment #25)

http://wikidata.beta.wmflabs.org/w/index.php?title=Q29510&action=history
Instead of 44°38'0.000"N, 25°20'0.000"E it is 44°37'60.000"N, 25°19'60.000"E
Instead of 47°42'0.00"N, 15°27'0.00"E it is 47°41'60.00"N, 15°27'0.00"E
Is someone there who sees these things?

Ok, 60 minutes or seconds is clearly wrong. But this is completely unrelated to precision detection. (But to be honest I have no idea what this bug was about originally, seems it became a precision detection bug with the second comment.) Let's continue in bug 73613, please. This "something is wrong with coordinates" report here is not helpful. Closing this as invalid now. Please open specific bugs for specific issues.

If I enter 47°42'0.00"N, 15°27'0.00"E, detected precision is arcsecond. Shouldn't it be 1/100 of an arcsecond?

(In reply to JulesWinnfield-hu from comment #29)

If I enter 47°42'0.00"N, 15°27'0.00"E, detected precision is arcsecond.
Shouldn't it be 1/100 of an arcsecond?

No, not in that case. If you enter e.g. 47°42'0.01"N, 15°27'0.00"E it switches to 1/100 of an arcsecond correctly.

(In reply to tobias.gritschacher from comment #30)

(In reply to JulesWinnfield-hu from comment #29)

If I enter 47°42'0.00"N, 15°27'0.00"E, detected precision is arcsecond.
Shouldn't it be 1/100 of an arcsecond?

No, not in that case. If you enter e.g. 47°42'0.01"N, 15°27'0.00"E it
switches to 1/100 of an arcsecond correctly.

But then why not minute? What is the difference?

(In reply to JulesWinnfield-hu from comment #31)

why not minute?

I'm afraid there is no single perfect solution. Currently I see three ways to parse 47°42'0.00"N, 15°27'0.00"E:

1.) Parse as a number, not a string, ignore all trailing zeros and set the precision to 1/60 (minute).

2.) Parse as a string, not a number, respect all trailing zeros and set the precision to 1/360000 (1/100 of an arcsecond).

3.) This is what's currently happening: First, check the format. It's D°M'S". We know the precision must be 1/3600 or higher for DMS. Now check the seconds. There is no higher precision needed for zero seconds. Ok, stick with 1/3600.

Personally I think method 1 would be bad. We may think about switching from method 3 to 2. I'm not sure. I think method 3 is ok. Again, if you think this is an issue that should be resolved then please open a new bug report. Thanks.

(In reply to Thiemo Mättig from comment #32)

I think there is no reason for 3. We can justify only 1 and 2. If the point is to respect what the user enters, then it should be 2.
3 would be an incorrect 2.