#2428: r.external to accept gdal config options
-------------------------+--------------------------------------------------
Reporter: perrygeo | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.1.0
Component: Default | Version: svn-trunk
Keywords: | Platform: Unspecified
Cpu: x86-64 |
-------------------------+--------------------------------------------------
When linking to an external GDAL raster source, it would be useful to pass
GDAL configuration options (http://trac.osgeo.org/gdal/wiki/ConfigOptions)
Consider this scenario: I need to specify a GDAL config option to read an
NetCDF file correctly. I can specify `GDAL_NETCDF_BOTTOMUP=NO` as an
environment variable which works for most cases but when using a
multiprocessing approach to parallelization (as e.g. `t.aggregate` does)
the newly spawned processes don't inherit the same environment and will
fail.
The solution might be for `r.external` to accept GDAL config options that
can be applied regardless of the environment variables and can allow
externally linked rasters to function properly across processes.
Replying to [comment:1 neteler]:
> The request sounds reasonable but I didn't figure out how to pass
"papszOptions" to GDAL as used in r.external. The magic line in r.out.gdal
is this:
> but in r.external GDALOpen() is used. Perhaps a GDAL expert can tell us
the trick.
Note that r.external is the analogue of r.in.gdal, which doesn't accept
any configuration options.
The analogue of r.out.gdal is r.external.out, which has an options=
option.
If options are needed for reading, a similar option should be added to
both r.in.gdal and r.external, presumably using GDALOpenEx() instead of
GDALOpen(). The latter will require extending the GDAL "link" format
(lib/raster/gdal.c).
Replying to [comment:2 glynn]:
> Replying to [comment:1 neteler]:
> > The request sounds reasonable but I didn't figure out how to pass
"papszOptions" to GDAL as used in r.external. The magic line in r.out.gdal
is this:
>
> > but in r.external GDALOpen() is used. Perhaps a GDAL expert can tell
us the trick.
>
> Note that r.external is the analogue of r.in.gdal, which doesn't accept
any configuration options.
While it doesn't directly, I had added a larger cache some time ago by
setting GDALSetCacheMax() to 300MB rather than the tiny 40MB default GDAL
cache size. This speeds up import tremendously:
{{{
r.in.gdal ...
memory=integer
Maximum memory to be used (in MB)
Cache size for raster rows
Options: 0-2047
Default: 300
}}}
I wonder how to get that into r.external (I suppose that it would benefit
as well).
> If options are needed for reading, a similar option should be added to
both r.in.gdal and r.external, presumably using GDALOpenEx() instead of
GDALOpen(). The latter will require extending the GDAL "link" format
(lib/raster/gdal.c).