> be
>> helpful. Although its best to avoid relying on the cache (if possible) by
>> specifying an appropriate blocksize.
>>
>> Here are a few mini-benchmarks:
>> http://nbviewer.jupyter.org/gist/RutgerK/4faa43873ee6389873dd4de85d
K/4faa43873ee6389873dd4de85de7c450
>
> https://stackoverflow.com/questions/41742162/gdal-
> readasarray-for-vrt-extremely-slow/41853759#41853759
>
> Regards,
> Rutger
>
>
>
>
> --
> View this message in context: http://osgeo-org.1560.x6.
> nabble.com/gdal-dev-Raster-c
gerK/4faa43873ee6389873dd4de85de7c450
https://stackoverflow.com/questions/41742162/gdal-readasarray-for-vrt-extremely-slow/41853759#41853759
Regards,
Rutger
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/gdal-dev-Raster-calculation-optimalisation-tp5324014p5324120.html
Sent
Maybe it does not compile the formula but runs parser etc. as a kind of
interpreter at each function call.
Googled and saw http://beltoforion.de/article.php?a=muparsersse. Did not
try, so no recommendation, let alone guarantee ;)
You could check by defining a test function explicitly, if it is much
Hi Paul,
I can only do snippets in C++...
You can get the block size using:
poBand->GetBlockSize( &nBlockXSize, &nBlockYSize );
then do a read something like:
for(int band = 0; band AdviseRead(startX+xoffset,startY+yoffset,blockWidth,blockHeight,blockWidth,blockHeight,GDT_Int32,
NULL);
Hi Paul,
What is the time to run your code without applying the calculation to each
pixel?
It is usually better to process the pixels in a block rather than walking
across each row especially if you are processing a TIFF as these are
usually stored as tiles (blocks).
The crossing from C# to C++
I'm using GDAL v2.1.3 with the SWIG bindings in my custom C# application.
I've created a method to do some calculation of my raster file:
public bool GdalCalculate(string input, string output, string formula,
double? minValue = null)
{
if (!File.Exists(input))
throw new FileNotFoundEx
