Hi Markus,

> (1a) Wikibase will continue to support arbitrary precision values for coordinates, and the UI will be extended so people can actually enter them.
> (1b) Wikibase will restrict the set of supported precision values for coordinates to those already supported in the UI. Other values are considered an error that will have to be fixed in the future.

In my opinion, possibly neither nor, with a tendency towards (a). Currently the API accepts any number (which makes sense in my opinion, how should the API provide a set of allowed precisions and why and how should it reject certain numbers?). The UI supports an auto-detection and a selection of predefined precisions, which is much easier to use. There may be an option to enter the precision as a number, if requested, but I don't think this is necessary at this point.

I recently introduced limits of 0.00000001° (8 decimal places) and 00°00'00.01" to the precision auto-detection to work around IEEE rounding issues (which happens both in- and externally). Both limits are equivalent to approximately 1 mm which "should be enough for anybody(tm)".

There are not really hard limits when using the API. What is entered is stored, which is how it should be in my opinion.

There is a hard limit of 1 in the formatters. Precisions bigger than 1 are ignored and default to 1.

Rounding errors and IEEE issues in the precision do not matter. The formatters calculate the number of significant decimal places from the precision (which is basically a type of rounding to either a fraction of a degree, minute or second smaller than the precision, depending on the output format). When parsing this formatted string the internal IEEE representation may change, but this possible "loss" is a one time thing, does not sum up and is irrelevant for the displayed string and equality checks (if they are done right).

> (2a) Null values for precision are an error that should be fixed in the data. Wikibase will reject such data in the future.
> (2b) Null values for precision have a meaning. It is as follows (please explain): ...

We currently have null values in the database. I tend to think of them as "not yet entered". I'm not sure if we should "reject" this at any point, I prefer to apply the auto-detection instead (so the answer is, again, neither nor).

> this was added only last November.

There always was a fall back to 1/3600° if no precision was given, but that code was incomplete. If a coordinate with no precision made it to the database you could not see, edit and fix it. This is possible now. Instead of applying the auto-detection in the formatter (which would be possible but may be confusing and inconsistent) the output defaults to the most common DD°MM'SS" (a.k.a. 1/3600°).

There are quite a lot of edge cases. I already fixed a lot of them (and added tests to make sure they never break) and will happily add and fix more. Just tell me if you find one.

Best

--
Thiemo Mättig
Software-Entwickler

Wikimedia Deutschland e.V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Tel. (030) 219 158 26-0
http://wikimedia.de

Stellen Sie sich eine Welt vor, in der jeder Mensch an der Menge allen Wissens frei teilhaben kann. Helfen Sie uns dabei!
http://spenden.wikimedia.de/

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.