[GRASS-dev] [grass-code P] scritps for converting raster maps into GRASS 7 format, and back
glynn at gclements.plus.com
Wed Apr 18 14:04:10 EDT 2007
Soeren Gebbert wrote:
> > 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.
> That is an interesting approach. But we already have a very sophisticated
> library in grass, which can be used for raster data management.
> Im talking about the g3d library. IMHO this lib can be extended to support
> raster maps.
THe key point is that we need to preserve the G_get_raster_row() etc
Also, when downscaling, you ideally want to completely skip any rows
which aren't actually requested, rather than doing most of the work
then discarding unused data at the end.
The idea behind r.external is that it would require relatively modest
changes to the lowest levels of the raster I/O code (i.e. the parts
that read/write raw data to/from the cell/fcell files). The rest of
the I/O stack (and, most importantly, the API) would remain
BTW, one of the main priorities for the the G3D library should be to
enable LFS. I didn't touch it in my recent round of LFS changes
because the issues were too pervasive (e.g. the various offsets in the
Glynn Clements <glynn at gclements.plus.com>
More information about the grass-dev