Hi Glynn,
thanks for your answer.
* Can the G3d library be used as backend for tile storage in the
raster library (setting the z dimension to one)?
Potentially.
Just an implementation example which was in my mind using g3d as raster backend:
I think the Rast_put_row() and Rast_get_row() function can be
efficiently mapped using the g3d X-direction tile cache approach. The
X-direction cache can be automatically set when the mapped
Rast_open_*() functions are called.
Consider a tile size of 64x64 pixel. An allocated raster buffer will
be filled with
for col in cols:
buffer[col] = G3d_getValue(map, col, row, 0)
or its content will be written with
for col in cols:
G3d_putValue(map, col, row, 0, buff[col]).
In case the tile cache size is big enough reading/writing the first
raster row will result in reading/creating all tiles in a row in
memory caching 64 raster rows. In case of g3d raster maps with 10000
columns the cache size must be 157 tiles == 5,2 MB. In case of 100000
columns 52 MB. It would be interesting to compare the performance of
this approach with the current raster approach. IMHO the g3d approach
should not be much slower.
Additionally Rast_put_value() and Rast_get_value() can easily be
implemented allowing arbitrary single cell value access.
The drawback is that CELL values are not supported and must be
currently mapped using DCELL values ... well at least the g3d library
has the ability to reduce the mantissa to 32Bit to minimize the disk
space usage for compressed tiles.
IMHO the g3d tile approach should be considered as raster backend and
will result in minor to no changes in existing raster modules.
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?
At which location will the files and the metadata be stored?
Are there modules which need to be modified to use this approach?
How is the performance of this approach compared to the native raster
I/O in GRASS?
Should such a strong external dependency really be considered?
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?
Best regards
Soeren
