Re: [gdal-dev] VRT derived band pixel functions written in Python

l.Open()`, and get an error because your > environment's extension modules aren't available in the VRT script. This > could be tough to debug for a beginning to intermediate level Python > programmer. > > > On Thu, Sep 15, 2016 at 10:29 AM, James Ramm <jamessr...@gmail.com>

Re: [gdal-dev] VRT derived band pixel functions written in Python

, James Ramm <jamessr...@gmail.com> wrote: > Ah, that makes sense. I'll have to try the config option in the morning, > but it sounds like that could be it > > On 14 Sep 2016 8:06 p.m., "Even Rouault" <even.roua...@spatialys.com> > wrote: > >> Le mercredi

Re: [gdal-dev] VRT derived band pixel functions written in Python

Ah, that makes sense. I'll have to try the config option in the morning, but it sounds like that could be it On 14 Sep 2016 8:06 p.m., "Even Rouault" <even.roua...@spatialys.com> wrote: > Le mercredi 14 septembre 2016 20:50:04, James Ramm a écrit : > > Yes, it is l

Re: [gdal-dev] VRT derived band pixel functions written in Python

I think you can call SWIG with the -threads argument on the command line so it will always release the GIL. Could be an easy option if it works On Tuesday, 13 September 2016, Even Rouault wrote: > Le mardi 13 septembre 2016 11:07:39, Rutger a écrit : > > I overlooked

Re: [gdal-dev] VRT derived band pixel functions written in Python

Incredible Really cool initiative. I had a play around and wanted a way to be able to write the pixel function in a 'stand alone' python module and generate the VRT from it. This would allow independent testing and easier maintenance of the python code. It is fairly easy using lxml to build

Re: [gdal-dev] Arc File Geodatabase

Yes, there is some form 2d index - each raster has a corresponding .col_index.atx, .row_index.atx, _.blk_key_index.atx and .band_index.atx files. I've not looke at how they work together so far. On Sunday, 21 August 2016, Even Rouault wrote: > Hi Richard, > > > I

Re: [gdal-dev] GDAL raster processing: parallel computing

Hi, I wasn't talking about MapReduce per se (although this would also be very interesting), but rather the 'classic' functional programming functions of 'map' and 'reduce'. A 'map' function essentially takes some user defined function and applies it to every element of a list/vector or some other

Re: [gdal-dev] Motion: adopt RFC 63 : Sparse datasets improvements

Excellent! Really pleased this has g one through so quick On 4 Aug 2016 6:38 p.m., "Kurt Schwehr" wrote: > +1 for this change. > > This will be awesome! > > On Thu, Aug 4, 2016 at 3:12 AM, Even Rouault > wrote: > >> On Thursday 04 August 2016

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

doh! for me - yes you have. I will double check this. On 20 July 2016 at 14:58, Even Rouault <even.roua...@spatialys.com> 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: > > >

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

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

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

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

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

Yes I am finding it can be dependent on the input dataset dimensions - Im only reproducing with a large raster. It is perhaps a small problem anyway since apparently MapInfo will not handle files > 2GB anyway. I will try using VSIFTruncateL to initialize. On 13 July 2016 at 15:21, Even Rouault

Re: [gdal-dev] GDAL raster processing library?

l known because of other implementations ... > which also provide ready-made reference bases for the GDAL implementors ... > > Best wishes, > Peter > > On 12 July 2016 at 15:39, James Ramm <jamessr...@gmail.com> wrote: > >> Hi Even, >> >> The difference I s

Re: [gdal-dev] GDAL raster processing library?

Hi Even, The difference I see with pixel functions is that, as far as I understand, the pixel function is applied per pixel, so there is no possibility of e.g. the pixel buffer when have the function apply to 'blocks'. I may be way off, but many of the algorithms we deal with require some kind of

Re: [gdal-dev] Call for discussion on RFC 63 : Sparse datasets improvements

Definitely a welcome improvement! Especially useful where the read window does not match natural block size (so the current sparse functionality doesnt help much). It improved the efficiency of a blob extraction algorithm (which requires overlapping windows and thus cannot use natural blocks) we

Re: [gdal-dev] Compiling GDAL with Visual Studio 2015

I'm am compiling successfully with vs 2015, both the library and python 3 bindings. The only thing I would add is to make sure you run vcvarsall.bat amd64. I'm building from trunk. On 2 Jul 2016 4:02 a.m., "Christopher McGeorge" wrote: > Thank you for your help,

Re: [gdal-dev] Raster attribute tables in GDAL?

Scratch my last message, I should've read more carefully: Can be one of NULL for a simple .dbf file with no .shp file, On 21 May 2015 at 14:14, jramm jamessr...@gmail.com wrote: That sounds great. Does this driver allow you to only write the dbf file (and not the shp/shx etc files?) I can't