r.external speed-up

[metzm]

Use GDALComputeRasterMinMax() for faster range computation.
Add super-fast mode without range computation, and a warning for this mode.

r.info will not report the range if not existing. If the range is explicitly requested with -r or -s, the range and stats are computed on-the-fly if not existing.

r.support -s is now computing the correct range for FCELL /DCELL maps.

Tested with a tiled GeoTIFF with 7 billion cells, linking with r.external drops from 2:06 minutes to 46 seconds. In super-fast mode, linking takes only 0.05 seconds.

Regarding the super-fast mode without data range computation, a number of modules will not work correctly. If the range is needed, it can be computed for the linked map with r.support, but linking again with r.external would be faster, at least for large, tiled maps.

[metzm]

A case for the super-fast mode is raster reprojection with r.proj. That means r.import can in most cases be faster, if reprojection is needed, if r.in.gdal is replaced with r.external -r in r.import. However, there must be a reason why r.import uses r.in.gdal instead of r.external when the input raster needs to be reprojected. IIRC, there were some problems with r.external that did not occur with r.in.gdal.

[neteler]

However, there must be a reason why r.import uses r.in.gdal instead of r.external when the input raster needs to be reprojected. IIRC, there were some problems with r.external that did not occur with r.in.gdal.

I traced the snippet back to GRASS GIS addons, r.in.proj (commit from Jan 27, 2015):
OSGeo/grass-addons@59b6976#diff-d06b709384f210f1f01d068364921d06ba692c21040323997220dad9e1d9d0beR182

Already back then it was based on r.in.gdal.

(For those here not knowing the story: the r.in.proj addon was in OSGeo/grass-addons@d26fd4d renamed to r.import and later moved to GRASS-core)

[metzm]

However, there must be a reason why r.import uses r.in.gdal instead of r.external when the input raster needs to be reprojected. IIRC, there were some problems with r.external that did not occur with r.in.gdal.

I traced the snippet back to GRASS GIS addons, r.in.proj (commit from Jan 27, 2015):
OSGeo/grass-addons@59b6976#diff-d06b709384f210f1f01d068364921d06ba692c21040323997220dad9e1d9d0beR182

Already back then it was based on r.in.gdal.

r.import uses some options and flags with r.in.gdal that are not available in r.external, thus in r.import, r.in.gdal can not be simply replaced with r.external when it comes to the actual import of the data. Worth a separate issue/PR.

[neteler]

Due to the containing bugfix I suggest to backport this after a while