[gdal-dev] Getting the following error while building GDAL 2.0.2 from source

2016-07-20 Thread sablok
I am trying to build GDAL 2.0.2 from source and while building it I am getting the following make error, I am not too sure why is this happening, any help is appreciated -: /home/sablok/workspace/sablok/BuildDev/env/GCC-4.9.x/runtime/bin/ld: error: cannot find ./ogr/.libs/ogrgeometryfactory.o /hom

Re: [gdal-dev] Error in GDALWarp to NWT_GRD

2016-07-20 Thread James Ramm
doh! for me - yes you have. I will double check this. On 20 July 2016 at 14:58, Even Rouault wrote: > Le mercredi 20 juillet 2016 15:55:37, James Ramm a écrit : > > I may very well be computing the file size wrong, my calculation is: > > > > 1024 + nXSize * nYSize * 2 > > This might perhaps be n

Re: [gdal-dev] Error in GDALWarp to NWT_GRD

2016-07-20 Thread Even Rouault
Le mercredi 20 juillet 2016 15:55:37, James Ramm a écrit : > I may very well be computing the file size wrong, my calculation is: > > 1024 + nXSize * nYSize * 2 This might perhaps be not the issue in your case, but I warned you before about the potential int32 overflow. You should cast one of nX

Re: [gdal-dev] Error in GDALWarp to NWT_GRD

2016-07-20 Thread James Ramm
I may very well be computing the file size wrong, my calculation is: 1024 + nXSize * nYSize * 2 1024 is the size of the header. Data on disk is written as an unsigned short hence * 2. I think this is correct when comparing with calculation to seek to a given block offset in IReadBlock/IWriteBloc

Re: [gdal-dev] Error in GDALWarp to NWT_GRD

2016-07-20 Thread Even Rouault
Le mercredi 20 juillet 2016 15:29:37, James Ramm a écrit : > The only 'fix' I can get working is to return a zero-filled array if the > call to VSIFReadL fails in IReadBlock. > > Given that ReadBlock checks whether the block index is valid, I think it is > safe to assume that if IReadBlock is call

Re: [gdal-dev] Error in GDALWarp to NWT_GRD

2016-07-20 Thread James Ramm
The only 'fix' I can get working is to return a zero-filled array if the call to VSIFReadL fails in IReadBlock. Given that ReadBlock checks whether the block index is valid, I think it is safe to assume that if IReadBlock is called, the data is expected to be retrievable (i.e. VSIFReadL in IReadBl

Re: [gdal-dev] Memory increase in postgis raster driver

2016-07-20 Thread Even Rouault
Le mercredi 20 juillet 2016 12:12:59, jramm a écrit : > I am seeing a continuous, linear memory increase when reading sequential > windows of a large postgis dataset. This is the same regardless of my > GDAL_CACHEMAX settings > If I run he same code on an equivalent GTiff dataset, I do not see the

Re: [gdal-dev] Amplitude virtual bands for complex datasets ?

2016-07-20 Thread Bugbuster
Hi Even, thanks a lot for your quick correction and the easy workaround. Cheers Philippe -- View this message in context: http://osgeo-org.1560.x6.nabble.com/gdal-dev-Amplitude-virtual-bands-for-complex-datasets-tp5273713p5277290.html Sent from the GDAL - Dev mailing list archive at Nabble.com

[gdal-dev] Memory increase in postgis raster driver

2016-07-20 Thread jramm
I am seeing a continuous, linear memory increase when reading sequential windows of a large postgis dataset. This is the same regardless of my GDAL_CACHEMAX settings If I run he same code on an equivalent GTiff dataset, I do not see the same increase in memory. I can see that the postgis dataset

Re: [gdal-dev] Amplitude virtual bands for complex datasets ?

2016-07-20 Thread Even Rouault
Le mardi 05 juillet 2016 09:34:31, Bugbuster a écrit : > Dear Even, > > Sorry for my late answer, I was onto something different yesterday. > > I agree with you, and I did change all function declarations in order to > "export" them in the DLL. > Thus, all functions in both pixfunplugin.c and pix