Hey there,
While testing I found that the notations of precision in the internal dumpfiles is not always what I expected:
My example is the item Zwickau (json and stacktrace attached):
The precision in the geolocation is denoted as an decimal value, while the implementation of GlobalCoordinatesValueImpl requires a long value encoding a precision.
How should this discrepancy be handled best?
Greetings, Fredo
PS: I am at the moment checking all the errors that occur while converting an earlier dumpfile, so I am likely to stumble upon more problems soon.
This should probably be directed at https://github.com/Wikidata/Wikidata-Toolkit/issues ?
Addshore
On 3 March 2014 15:45, Fredo Erxleben fredo.erxleben@tu-dresden.de wrote:
Hey there,
While testing I found that the notations of precision in the internal dumpfiles is not always what I expected:
My example is the item Zwickau (json and stacktrace attached):
The precision in the geolocation is denoted as an decimal value, while the implementation of GlobalCoordinatesValueImpl requires a long value encoding a precision.
How should this discrepancy be handled best?
Greetings, Fredo
PS: I am at the moment checking all the errors that occur while converting an earlier dumpfile, so I am likely to stumble upon more problems soon.
Wikidata-tech mailing list Wikidata-tech@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
On 03/03/14 15:50, addshorewiki wrote:
This should probably be directed at https://github.com/Wikidata/Wikidata-Toolkit/issues ?
Yes, details related to the ongoing development of Wikidata Toolkit should be discussed elsewhere. In this particular case, part of the problem can probably be solved by having a look at the documentation of the code [1].
Anyway, part of the question is also about the Wikibase data model for globe coordinates and the related JSON. I can say something about this:
* GlobeCoordinates store numbers for latitude, longitude, and precision. * The "precision" value is restricted: only a small number of values are allowed (the ones that one can enter through the UI). This probably needs more documentation [2]. * The accuracy of coordinates is inherently limited (you cannot meaningfully define locations beyond a certain precision). This is in contrast to the Quantity type where we have arbitrary precision decimals. * The exact format of the numbers is not completely fixed yet. The current proposal is to measure all values in degrees with a guaranteed accuracy of 9 digits (that means: "up to nanodegrees"). This should be enough for all practical purposes. (Note that I am talking about the accuracy of the decimal numbers here, not about the GlobeCoordinates' "precision" value, which is also a number of the same accuracy.) * Most programming languages do not have a "9 digit fixed precision decimal" datatype that could exactly capture this. To represent such a number you can store integer values that give the amount in nanodegrees (the degree value multiplied by 10^9); overflows are unlikely in 64bit integers since latitude and longitude cannot be very large numbers. With 9 decimal digits, one could also use double without significant errors. These two views can easily be converted back and forth. * The current JSON (internal and external) gives the numbers as serialisations of floating point values (in rare cases even using e notation). In the future, these should be decimal values (can still be read as floats but won't use e notation).
A definite clarification of this issue will be provided soon, but the above is the current status.
Markus
[1] https://github.com/Wikidata/Wikidata-Toolkit/blob/master/wdtk-datamodel/src/... [2] https://bugzilla.wikimedia.org/show_bug.cgi?id=62105
Addshore
On 3 March 2014 15:45, Fredo Erxleben <fredo.erxleben@tu-dresden.de mailto:fredo.erxleben@tu-dresden.de> wrote:
Hey there, While testing I found that the notations of precision in the internal dumpfiles is not always what I expected: My example is the item Zwickau (json and stacktrace attached): The precision in the geolocation is denoted as an decimal value, while the implementation of GlobalCoordinatesValueImpl requires a long value encoding a precision. How should this discrepancy be handled best? Greetings, Fredo PS: I am at the moment checking all the errors that occur while converting an earlier dumpfile, so I am likely to stumble upon more problems soon. _______________________________________________ Wikidata-tech mailing list Wikidata-tech@lists.wikimedia.org <mailto:Wikidata-tech@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
Wikidata-tech mailing list Wikidata-tech@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
wikidata-tech@lists.wikimedia.org