Page MenuHomePhabricator

Wrong coordinate display in wikidata page
Open, MediumPublic

Description

I have found at least one page where wikidata displays the wrong coordinates, although it has the right value. Check this page. If you read the coordinates, the API returns 42.1206, 2.76944. This is (42∘ 7'14.1600", 2∘46'9.9840"). However, the page displays 42°7'19"N, 2°46'24"E. This can't be a rounding error.

If you click the link on the right, it takes you to the GeoHack page, which shows the right conversion on top of the page.

Another example: Sant Pere del Burgal. There's a mismatch between what the page shows, and what's actually there.

So, it really looks like a conversion problem in the wikidata page.

Event Timeline

Joutbis created this task.Nov 5 2016, 1:29 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptNov 5 2016, 1:29 PM
Joutbis updated the task description. (Show Details)Nov 6 2016, 6:23 PM
Esc3300 added a subscriber: Esc3300.Nov 6 2016, 6:34 PM

A rounding for display issue?

A rounding for display issue?

It's off by a few seconds. Can't be.

Storage is in decimals and there is a precision percentage involved.

You have a point here. Probably the number shown is within the given precision, I hadn't realised that.

But why show this arbitrary number, instead of the one that's been entered? Everybody else does it (geohack, the wikipedia pages, ...). Why should wikidata show it differently?

thiemowmde triaged this task as Medium priority.Dec 22 2016, 10:58 AM
thiemowmde moved this task from incoming to needs discussion or investigation on the Wikidata board.

I added test cases for this in https://github.com/DataValues/Geo/pull/92. I can understand the confusion, but the behavior is (currently) expected. The internally stored decimal value is 42.1206, 2.76944 with the precision being 0.012111004438894 degrees, which happens to be roughly 0.7 minutes, or 44 seconds. How would you format this? The precision is less than a minute, so we can not round to minutes. The only option we have is to show seconds. At the same time we must respect the precision and round accordingly:

42.1206 / 0.012111004438894 = 3477.878338871
3477.878338871 ≈ 3478 when rounded
3478 * 0.012111004438894 = 42.122073438
42.122073438 = 42° 7' 19" when formatted

I agree that 42° 7' 19" is not better than 42° 7' 14". The 19" doesn't help you understand that the value was stored with a precision that's much closer to a minute that to a second. A much better solution would be to render this as 42° 7' 10", which makes it much more obvious that the precision is close to 10 seconds, but not 1 second.

I understand now. The value given is well within the precision, not even very far off. The problem then is that it is misleading. Someone who reads the wikidata page to program a GPS will end up 356 m from that building.

I think the problem is that, in order to find out that there is a non-negligible precision involved, you need to actually try to edit the value; that's something most people will never do. It would be a lot more helpful to display both the central value and the precision, side by side.

Incidentally, the question is who entered four decimals of coordinates and then gave a precision of a hundredth of a degree? Looking at the history, it was a bot importing from the English Wikipedia. Nothing in the article suggests that figure for the precision, so it's probably a bug in the bot, which "invented" a precision for those coordinates.

Restricted Application added a subscriber: PokestarFan. · View Herald TranscriptAug 10 2017, 2:19 AM
Jarekt added a subscriber: Jarekt.Oct 9 2017, 3:25 PM

I just come to report very similar issue. See Laos (Q819 ) item. the latitude stored is (19.366667, 102.566667) or 19° 22′ 0.001200″ N, 102° 34′ 0.001200″ E. The display should have been 19°22'0.00"N, 102°34'0.00"E, but it is incorrectly displayed as 19°22'0.01"N, 102°34'0.01"E.

The seconds are calculated (102.566667 - 102 - 34/60)*3600 = 0.001200.