nicklasaven
commented
9 years ago Very true.
You are right and I haven't considered the case with lon/lat and height in meters.
suggestions?
What I have sketched in my head but not written down is even higher dimensionality. I have some idea about a pointcloud type. Then it should be, in the beginning, 1 byte per dimension telling precision. That byte could maybe also hold some number-code about what type of dimension it is, if it is x, y or z or some measurement. 1 bit in that byte also could tell if the dimension handles absolute values or delta values. It would not tolerate text, only fixed precision numbers in varint.
I guess that is the most common usage of point clouds that all data is coded to numerical values to save space. Then that could be a very compressed pointcloud type. It will of course be very bad format to query compared to fixed length fields.
But 1 extra byte per dimension seems a little overkill for the ordinary types. But at the other hand it would give a lot of extra possibilities. Like defining per-dimmension, if it is absolute or delta-values (or maybe even just an offset origo in a tile)
pramsey
While X/Y commonly share a precision, the same is not true of Z and T (or M).
In a geographic coordinate, it might make sense for X/Y to have a precision of around 5 decimal places of longitude/latitude, or about 10cm on the ground. For the same point, the Z value (in meters above MSL, perhaps) might have a precision of 1 decimal place (also 10cm). And the T value could have a precision of 0 places (or one second, depending on the stored units).
The point of the example being, a single precision number will not serve for high dimensional data, except in the trivial but relatively rare X/Y/Z in a single projected cartesian system case. Even though, varieties of error mean that X/Y and Z often have different capture errors, and should thus be transported with differing precisions.