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