[GRASS-dev] G3d library code review and raster lib tile approach

[Glynn Clements]

Soeren Gebbert wrote:

> > Many of the ideas came up before I implemented r.external and
> > r.external.out. That lead to an alternate possibility, that GRASS
> > itself wouldn't actually have /any/ particular raster format but just
> > deal with whatever GDAL supported.
> 
> Using a pure gdal approach leads me to many questions:
> 
> What would be the default format for reading and writing in a grass mapset?

Probably GRASS' native format, for compatibility.

> At which location will the files and the metadata be stored?

The metadata is stored in the mapset; only the actual raster data is
read and written via GDAL; linked maps still require metadata files. 
The actual data can be stored wherever you want, but I'd suggest a
"gdal" subdirectory in the mapset for non-GRASS (TIFF etc) files.

> Are there modules which need to be modified to use this approach?

Only those which perform low-level access, e.g. r.null.

> How is the performance of this approach compared to the native raster
> I/O in GRASS?

It depends entirely upon the format and the usage. E.g. compressed
formats such as PNG are likely to be inefficient if you try to skip
rows.

> Should such a strong external dependency really be considered?

GDAL is already almost mandatory.

> > The would require that GDAL had "native" GRASS raster I/O code (i.e.
> > not depending upon libgis/libraster). The main issue here is that the
> > code would probably need to be written from scratch due to licensing
> > issues: GRASS is GPL, GDAL is LGPL, and trying to track down everyone
> > who might have a copyright interest in the raster I/O code wouldn't be
> > practical.
> 
> Will the benefit of this approach justify this huge effort of writing
> the I/O code from scratch?

It's not a huge effort. Most of it is accounted for by four files:
open.c, get_row.c, put_row.c and close.c. And it's not even all of
those files; the higher-level stuff (e.g. resampling) would remain
within libraster.

It's probably less effort than trying to add yet another raster format
within the existing raster code.

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