And thanks for the use cases. This helps a lot with thinking about this.
On Thu, Aug 31, 2017, 16:31 Denny Vrandečić <vrandecic(a)gmail.com> wrote:
The reason why we save the actual value with more
digits than the
precision (and why we keep the precision as an explicit value at all) is
because the value could be entered and displayed either as decimal digits
or in minutes and seconds. So internally one would save 20' as 0.333333333,
but the precision is still just 2. This allows to roundtrip.
I hope that makes any sense?
Yes, that means that using the values for comparison without taking the
prevision into account will fail.
I don't think comparison and other operators were ever specified for the
datetypes. This has bitten us before, and I think it would be valuable to
do. And that would resolve these issues, and some others.
Would there be people interested in doing that? I sure would love to get
On Thu, Aug 31, 2017, 16:17 Stas Malyshev <smalyshev(a)wikimedia.org> wrote:
I am not sure I understand the issue and what the
suggestion is to solve
it. If we decide to arbitrarily reduce the possible range for the
Well, there are actually several issues right now.
1. Our RDF output produces coordinates with more digits that specified
precision of the actual value.
2. Our precision values as specified in wikibase:geoPrecision seem to
make little sense.
3. We may represent the same coordinates for objects located in the same
place as different ones because of precision values being kinda chaotic.
4. We may have different data from other databases because our
coordinate is over-precise.
(1) is probably easiest to fix. (2) is a bit harder, and I am still not
sure how wikibase:geoPrecision is used, if at all.
(3) and (4) are less important, but it would be nice to improve, and
maybe they will be mostly fixed once (1) and (2) are fixed. But before
approaching the fix, I wanted to understand what are expectations from
precision and if there can or should be some limits there. Technically,
it doesn't matter too much - except that some formulae for distances do
not work well for high precisions because of limited accuracy of 64-bit
double, but there are ways around it. So technically we can keep 9
digits or however many we need, if we wanted to. I just wanted to see if