(1a) Wikibase will continue to support arbitrary
precision values for
coordinates, and the UI will be extended so people can actually
(1b) Wikibase will restrict the set of supported
precision values for
coordinates to those already supported in the UI. Other values
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
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
prefer to apply the auto-detection instead (so the answer is, again,
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.
Wikimedia Deutschland e.V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Tel. (030) 219 158 26-0
Stellen Sie sich eine Welt vor, in der jeder Mensch an der Menge allen
Wissens frei teilhaben kann. Helfen Sie uns dabei!
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.