1/1
content-type: TEXT/PLAIN; charset=US-ASCII
organization: University of Illinois at Urbana
mime-version: 1.0
reply-to: ebuddington@wesleyan.edu
newsgroups: info.grass.user
originator: daemon@ux1.cso.uiuc.edu
I've been pondering the multitude of data formats and coordinate systems
available, and the difficulty of transformation from one to the other. In
writing programs that convert to GRASS format, I've begun to see that a
lot of data is lost in the translation. I suspect that this is generally
inevitable when one converts between formats. Additionally, GRASS doesn't
do very good compression, which is important for low-end (low disk space)
systems, like mine.
How about giving GRASS the ability to access a standard database that
could incorporate various kinds of information, and would be extensible as
needed? I'd guess that modern database programs are probably well-suited
for this sort of thing, as far as dealing with varied data types and
sometimes sparse data. If the interface were also standard (perhaps SQL?),
it would be portable and able to take advantage of future improvements in
database software. Also, we (as GRASS users) wouldn't have to maintain the
database code; we'd just need routines to dump existing data into the
database.
As a disclaimer, I don't know much about databases. After talking recently
to a friend who knows a litle, it seemes reasonable. Can someone with more
background comment?
-Eric
On Sat, 13 Apr 1996, Eric Buddington wrote:
I've been pondering the multitude of data formats and coordinate systems
available, and the difficulty of transformation from one to the other. In
writing programs that convert to GRASS format, I've begun to see that a
lot of data is lost in the translation. I suspect that this is generally
inevitable when one converts between formats. Additionally, GRASS doesn't
do very good compression, which is important for low-end (low disk space)
systems, like mine.
I believe that the run-length encoding used by GRASS to compress raster
files was chosen partly due to the speed at which it can be uncompressed,
an important consideration for reading raster layers. I assume that
you're not referring to the archiving of GRASS data. I don't doubt that
there are better algorithms out there, but RLE has served GRASS pretty
well. With the price of disk storage today, I think that processing speed
is more of a consideration than storage size. My $.02 :^)
How about giving GRASS the ability to access a standard database that
could incorporate various kinds of information, and would be extensible as
needed? I'd guess that modern database programs are probably well-suited
for this sort of thing, as far as dealing with varied data types and
sometimes sparse data. If the interface were also standard (perhaps SQL?),
it would be portable and able to take advantage of future improvements in
database software. Also, we (as GRASS users) wouldn't have to maintain the
database code; we'd just need routines to dump existing data into the
database.
Check out src.garden/grass.informix. These SQL tools have been ported to
one or two other databases by some other folks, as well; other people on
this list could probably tell you more.
As a disclaimer, I don't know much about databases. After talking recently
to a friend who knows a litle, it seemes reasonable. Can someone with more
background comment?
-Eric
-Malcolm
--
Malcolm D. Williamson - GIS Specialist E-mail: malcolm@cast.uark.edu
Center for Advanced Spatial Technologies Telephone: (501) 575-6159
Ozark Rm. 12 Fax: (501) 575-5218
University of Arkansas
Fayetteville, AR 72701