Page MenuHomePhabricator
Create Task
Maniphest T159824

GeoCoordinates lose precision while editing
Open, MediumPublic
Actions

Description

When editing geo-coordinates via the Web-UI, rounding (according to the precision given) is applied to the value pre-filled in the edit field.
If the precision of the geo-coordinate is too low, this causes digits to be removed from the coordinates as originally entered. Example:

  • the coordinate is entered as 36.1234N 17.567W with precision +/-1
  • the coordinate is correctly displayed as 36N 18W
  • when clicking edit, the input field is set to 36N 18W
  • when clicking save (without changing the value), the new value is 36N 18W.

This way, the original value of 36.1234N 17.567W is lost. There is not even an obvious way to ever see it in the user interface.

Expected behavior: when clicking edit, the input field is set to the value as originally entered, 36.1234N 17.567W. This would however require the value to be represented as decimal degrees, instead of the more commonly understood DMS format.

Proposal: when formatting for use in the input field, ignore the precision stored in the value, and derive it solely from the number of digits given. This should retain the original precision regardless of format.

Related Objects

Event Timeline

daniel created this task.Mar 7 2017, 12:51 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 7 2017, 12:51 PM
thiemowmde triaged this task as Medium priority.Mar 13 2017, 5:50 PM
thiemowmde removed a project: Wikidata-Former-Sprint-Board.
thiemowmde moved this task from incoming to needs discussion or investigation on the Wikidata board.
thiemowmde added subscribers: Lydia_Pintscher, • Aleksey_WMDE, Addshore, aude.
  • This issue is not new. For coordinates it always was like this.
  • We had the same issue with quantities, and fixed it as described above. When editing a quantity, the raw value is shown with no rounding applied.
  • We can not apply the exact same fix here, because unlike quantities we do not store what the user entered. In almost all cases the user entered a degree-minute-second (DMS) format. We convert it to decimal in the parser, store that, and convert back to DMS in the formatter.
    • If we let the user edit the internal decimal format with all decimal places we have, this would be very confusing.
    • If we stick to DMS formatting, but disable rounding, stuff like 1°30'00.000016666667" will appear in the edit window.
    • A possible solution I can think of is a formatter that tries to cut of as many decimal places as it can, but enough so that the value survives a full roundtrip. For example, if it turns out that 1°30'00.00002" (instead of 1°30'00.000016666667") is enough to get the exact same internal decimal format as before (possibly plus-minus an epsilon), this is what will be shown in the edit window. The precision is not taken into account by this formatter.
      • Note that there will be cases where an iterative algorithm will get stuck in an endless loop. For example, it may find a DMS representation that converts back to 1.0000002 and an other one that converts back to 1.0000004, but can not find one that converts back to 1.0000003. That's why an epsilon is important.
      • Such an algorithm should also have an absolute limit, e.g. never output decimal places that represent less than a millimeter on the earths surface.
      • I also think a limit relative to the value's precision may be sensible, e.g. the value can only be 100 times more precise than it's precision.
Addshore unsubscribed.Mar 14 2017, 1:37 PM
thiemowmde mentioned this in T106928: [Story] auto precision may lead to unintended effects.Mar 15 2017, 1:08 PM
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL