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

[Soeren Gebbert]

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

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;
  G3d_Region region3d;
  ...

  G3d_getWindow (&region3d);
  G_get_set_window(&region2d);

  G3d_regionFromToCellHead(&region2d, &region3d); 
  region3d.depths = 1;
  region3d.top = 1;
  region3d.bottom = 0;
  region3d.tb_res = 1;  

  return G3d_openCellNewParam(name, RASTER_MAP_TYPE, G3D_NO_CACHE, &region3d, 
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 
data_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
> unaffected.
>
> 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. :(

Best regards
Soeren