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

[Glynn Clements]

Soeren Gebbert wrote:

> >> 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.
> 
> Pleas excuse my little knowledge about GDAL but an important point to
> change the grass raster row approach was to enable random access for
> single values using tiles? Will the GDAL approach provide such
> capabilities? What kind of new function will be available with GDAL?

GRASS already supports the use of GDAL via r.external[.out]. The only
change would be to separate the existing raster I/O code from GRASS. 

This potentially makes it easier to add/change raster formats, as we
wouldn't need to support all of the legacy GRASS raster formats in
addition to any new format; access to the old formats would be via
GDAL.

But GRASS isn't going to "change" to a tiled format. There might be
the possibility of using a tiled format as an alternative to a
row-based format, but the row-by-row API will remain the norm, and
shouldn't suffer a perfomance hit for the sake of less common cases
(e.g. random access).

> >> Should such a strong external dependency really be considered?
> >
> > GDAL is already almost mandatory.
> 
> I know little about GDAl community but would the GDAL community accept
> that GRASS GIS core functionality will be part of GDAL?

The GRASS raster format is just another raster format. The fact that
it was specifically designed for GIS isn't really relevant.

> So GRASS
> developer/documenter who need to fix bugs or try to improve GRASS
> raster library need to have write access to the GDAL repository? Will
> GRASS depend on GDAL release cycles in case of stable version?

It depends. One option is for the GRASS raster I/O to be made into a
self-contained library, analogous to libpng or libjpeg. The GDAL
driver would then interface to this library.

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