Yeah, I'm definitely not working in polar areas but I'm not sure I see what the issue is, at least from a conceptual perspective. The poles are just locations on the surface of the earth. Lat-long subtends less surface area there (if I'm remembering my geometry correctly) but I think that can be dealt with by using more significant digits (but I could be wrong about this).
Re gravitational center, I don't know enough the mechanics of the earth as a spheroid to know about how easy this is, but I guess the question is whether it is conceptually possible to identify a single reference point, along with characteristics of the shape of the earth, that would work for 'everyone.' Re computational speed, you may be right that current systems don't have enough horsepower to do this, but if the issue if planning for grass 7, then the issue is what is on the computational horizon. My casual reading of the IT press, is that quad cores will be in most new systems by the end of 2008, and ram prices will just keep going down and down. So any design features for grass 7 should keep this in mind. Maybe there are ways to parallelize grass to take advantage of this and make the computational burden not an issue. But I'm really way out of my depth here. I'm mainly hoping to see what the grass developers think about these issues. Regards, Jerry ---- Original message ---- >Date: Mon, 31 Dec 2007 01:29:22 -0800 >From: "Boris Avdeev" <[EMAIL PROTECTED]> >Subject: Re: [GRASS-dev] what is the ideal way to store spatial data >To: "Gerald Nelson" <[EMAIL PROTECTED]> >Cc: [email protected] > >Apparently you are not working often in polar areas, so such problem >of spherical coordinates as singularities is not obvious. >Gravitational center, to my understanding, is not an easily defined >point either. Also, from ArcGIS experience, on-the-fly reprojection is >quite slow process even using most powerful desktop. > >Boris > >On Dec 30, 2007 8:12 AM, Gerald Nelson <[EMAIL PROTECTED]> 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. >> >> Just some thoughts on a Sunday morning. >> >> Regards, >> JErry >> Gerald Nelson >> Professor, Dept. of Agricultural and Consumer Economics >> University of Illinois, Urbana-Champaign >> office: 217-333-6465 >> cell: 217-390-7888 >> 315 Mumford Hall >> 1301 W. Gregory >> Urbana, IL 61801 >> _______________________________________________ >> grass-dev mailing list >> [email protected] >> http://lists.osgeo.org/mailman/listinfo/grass-dev >> Gerald Nelson Professor, Dept. of Agricultural and Consumer Economics University of Illinois, Urbana-Champaign office: 217-333-6465 cell: 217-390-7888 315 Mumford Hall 1301 W. Gregory Urbana, IL 61801 _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
