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

[Glynn Clements]

Paul Kelly wrote:

> 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.

FWIW, I don't feel that the future of GRASS should be constrained by
whether or not third parties are willing to maintain compatibility.

> 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.)

Actually, I've been thinking about hiving off the base raster format
to a separate library, along with generalising the low-level I/O to
allow for an "r.external" command, i.e. allow GRASS raster I/O to
directly read external files through GDAL.

The higher level stuff (rescaling, format conversion, reclassing, MASK
etc) would remain in GRASS.

The main issue is that some modules perform random access (i.e. don't
read the rows in top-to-bottom order), and not all raster formats can
support this efficiently (uncompressed formats such as BMP or raw-PPM
can, but anything which uses compression needs an index).

A related problem is that modules don't have to explicitly request
non-linear access at open time, so there's no simple way to identify
which modules would be affected.

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