[GRASS-dev] [grass-code P] scritps for converting raster maps into GRASS 7 format, and back
soerengebbert at gmx.de
Wed Apr 18 15:45:02 EDT 2007
Am Mittwoch, 18. April 2007 20:04 schrieb Glynn Clements:
> 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
If we set the tile size to the size of one raster row, the tile functions
of the g3d library will show the behaviour of G_get_raster_row() without
skipping any kind of data. There is no need to skip existing API, we just need
to wrap the g3d lib calls:
First set the tile size when open a new map:
void *G_open_raster_new (const char *name, RASTER_MAP_TYPE type)
struct Cell_head region2d;
region3d.depths = 1;
region3d.top = 1;
region3d.bottom = 0;
region3d.tb_res = 1;
return G3d_openCellNewParam(name, RASTER_MAP_TYPE, G3D_NO_CACHE, ®ion3d,
type, doLzw, doRle, precision, rows, 1, 1);
Now we can access the tiles:
int G_put_raster_row (void *map, void *rast, RASTER_MAP_TYPE data_type)
return G3d_writeTile(map, row, rast, RASTER_MAP_TYPE );
int G_get_raster_row (void* map, void *rast, int row, RASTER_MAP_TYPE
return G3d_readTile(map, row, rast, RASTER_MAP_TYPE );
The API will change a bit because of the first argument of G_get_raster_row().
> 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
> G3D_Map structure).
That's too bad, i have no clue how to enable LFS support. :(
More information about the grass-dev