[GRASS-dev] what is the ideal way to store spatial data

[Glynn Clements]

Gerald Nelson wrote:

> Since all spatial data are about describing a specific location on a
> specific planet, usually earth, it would seem that the best way
> conceptually to store data is with respect to a single easily defined
> reference point such as the gravitational center of the planet. Any
> location could then be measured with three values. x,y like latitude
> and longitude, and z a distance measure from the reference point along
> a ray.
> 
> Projections such as utm, etc, are about how to convert the 3-d data
> described above into 2-d with a minimum of distortion. Given the speed
> of modern computers this conversion process ought to be increasingly
> easy to do on the fly, as needed.
> 
> The reason I raise this question is to ask the experts whether it
> would make sense (for 7.x) to think of a single standard way of
> storing data in grass and then all operations would do the conversions
> as necessary? There are (at least) two advantages of this. One is
> standardization of data storage in a form that is closest to a true
> representation of the real world. A second is to reduce the potential
> for confusion/mistakes when data are shared and the metadata are not,
> or are inadequate. I am continually getting access to data where the
> units are not clearly defined. But even if they are defined say as
> some utm coordinate, there must be some error in measurement built in.

Apart from wasting CPU time, conversion introduces error. Applying a
non-affine transformation to a regular grid (i.e. raster) doesn't
result in a regular grid. Applying a non-affine transformation to a
straight line doesn't result in a straight line. Any spatial
measurement which is constant for the original data (e.g. maximum
spatial error) will cease to be constant if the data is projected.

All things considered, the optimum form in which to store the data is
the form in which the user chooses to store it. There will always be
factors of which the user is aware but the software isn't.

-- 
Glynn Clements <glynn at gclements.plus.com>