[GRASS-dev] [grass-code P][372] scritps for converting raster maps into GRASS 7 format, and back

Hamish hamish_nospam at yahoo.com
Thu Apr 19 02:02:29 EDT 2007

Paul Kelly wrote:
> Could it be written in C so it is more cross-platform? There is a new 
> function G_copy_file() in CVS that can copy files on disk. There is
> also the C rename() function.

I am sure it could, I'm just a lot more comfortable moving files around
in the shell. (mostly just ignorance of how to do it safely in C)

Perhaps Python would be a better compromise? (assuming it will be
required dependency for the GUI+1 anyway)

> Although I still don't think I like the idea of changing the internal 
> raster format as I expect it will break lots of 3rd-party software
> that reads GRASS raster files directly, and could make GRASS look bad
> for changing things. E.g. thinking of the detailed discussion of the
> raster format a year or two ago for JavaGrass which reads it directly
> I think. Also even GDAL must be passed the path to the cellhd
> directory to read a GRASS raster I think? Also might it not be worth
> taking the opportunity to modernise the raster format further than
> just re-arranging the files, and perhaps providing some kind of LGPL
> library for developers of 3rd-party software to use to read GRASS
> rasters (actually that already exists I think - isn't it what GDAL
> uses? http://freegis.org/cgi-bin/viewcvs.cgi/libgrass/ but don't think
> its used much.)

Of course we should try to minimize the change. My beef with the current
format is that it is hard to archive and copy maps easily, and is
generally not cosmetically pleasing. As it is only dir structure
changing it wouldn't so bad an update for the 3rd party authors to deal

Sure we can and should help package a LGPL or MIT/X licensed reference
implementation data reader for 3rd parties. Probably aim for GDAL/OGR
first/only. I don't know enough about the nuts and bolts of the formats
to know if this could be done cleanly without having to use any GPL
code. Presumably the raster format could be done from CERL code (what
about FP and NULL, is that pre-GPL grass?) but the vector format is
surely GPL encumbered. Maybe Radim could be convinced to relicense any
needed parts written by him as LGPL?

If we contribute something new to GDAL I guess it should be MIT/X.
But that is more of an issue for a whole new binary format, not just
an internal rearrangement?

see also gdal-1.4.1/frmts/grass/

[I should revisit r.(un)pack to be more like this r.convert script +
.tar.gz instead of using r.*.mat. Shrug, I don't use that much- instead
I just make a new mapset, g.copy map at other,map then tar.gz the new

> Sorry, just a few thoughts I've had for a while; wanted to get them
> out on the list.

Don't apologize -- I wrote the script to help get the ball rolling and
garner discussion. But if it is to happen, the format change should
happen as the first task of the GRASS 7 branch, IMO.

> Has the grass7 format already been agreed upon?

No. Just ideas. see:


More information about the grass-dev mailing list