On 19.12.2012 08:34, Nikola Smolenski wrote:
Why would it
make sense to have both? What is the altitude in the
geolocation good for? Is there an example in Wikipedia where it is or
would be used, and where a property of its own would not be better?
While at it, why not separate longitude and latitude? There are items that only
have one, f.e.
http://en.wikipedia.org/wiki/Prime_meridian#
I'd argue that the prime meridian does not have a location. And I think it would
be bad to make longitude or latitude optional in a geo-coordinate data type.
There is however nothing that would keep you from defining "longitude" and
"latitude" as separate properties, and assigning them a 1D scalar value. But
that's unrelated to the geo-coordinate data type.
Internally we
would translate it, yes, otherwise the numbers would not
be comparable. But for editing we need to keep the unit of the source /
of the editor, or else we will loose precision.
What I wanted to say. Additionally, in some cases historical units are not
accurate or accurately known, so possibly we won't even be able to make the
conversion.
I don't think we can sensibly support historical units with unknown conversions,
because they cannot be compared directly to SI units. So, they couldn't be used
to answer queries, can't be converted for display, etc - they arn't units in any
sense the software can understand. This is a solvable problem, but would add a
tremendous amount of complexity.
I think we should always store a values accuracy (which, if not given
explicitly, can be derived from the input's unit and number of digits). I think
it would be a bad idea to store the original input unit, though. In order to
make values comparable (and thus usable in queries), they need to be converted
to internal units, with very good precision; for output, they need to be
converted to whatever the user prefers. I see no useful place for the original
input units.
-- daniel
--
Daniel Kinzler, Softwarearchitekt
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.