[gdal-dev] VRT pixel functions on tiled vrt

[William Kyngesburye]

OK, it worked as vrt of a vrt.  Memory not an issue.

But I have a new problem.  One vrt I want to instead do > -29 (caspian sea, -29 in SRTM data).  The whole region evaluates to 1 (true).  It looks like the in_ar[] is getting truncated to an unsigned byte, 0-255, from its orignal Int16.  Testing some values, anything up to 254 gives me 0/1 areas matching the elevation values in the original DEM, but >255 returns 0 for the whole area (that is, everything >255 was truncated to 255, so nothing is >255).  Thus, > -29 is true for the whole area.

I tried using the python cmp() function, in case the () test was casting each value to Byte, but it complained that it's ambiguous for an array.  The error suggested to use a.any() or a.all(), but I don't know how to do that one.

Here is the script again:

import numpy
def land(in_ar, out_ar, xoff, yoff, xsize, ysize, raster_xsize, raster_ysize, buf_radius, gt, **kwargs):
	out_ar[:] = (in_ar[0] > -29)

> On Apr 26, 2018, at 1:07 PM, William Kyngesburye <woklist at kyngchaos.com> wrote:
> 
> So, if the gdal library queries for a region of the vrt (ie processing it in chunks), the numpy array will be just that region?  I'll give it a try.
> 
> What about something like viewing the whole vrt in QGIS - will it be read in chunks as well?  IOW, is it the GDAL library that breaks it into chunks at reading, or is it the responsibility of programs (gdal_translate, QGIS,...) to ask for chunks?
> 
>> On Apr 26, 2018, at 12:59 PM, Even Rouault <even.rouault at spatialys.com <mailto:even.rouault at spatialys.com>> wrote:
>> 
>> On jeudi 26 avril 2018 12:56:10 CEST William Kyngesburye wrote:
>> > So, a vrt of a vrt?
>>  
>> Yes
>>  
>> > 
>> > I wanted to avoid that, because as I understand the source, it reads each
>> > raster in the derived band as a single numpy array, which would be all the
>> > tiled rasters together.  
>>  
>> No, if you use gdal_translate, it will process the source by reasonable chunks, so you should be able to process arbitrarily large sources.
>>  
>> Even
>>  
>> -- 
>> Spatialys - Geospatial professional services
>> http://www.spatialys.com <http://www.spatialys.com/>_______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org <mailto:gdal-dev at lists.osgeo.org>
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev <https://lists.osgeo.org/mailman/listinfo/gdal-dev>
> -----
> William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
> http://www.kyngchaos.com/ <http://www.kyngchaos.com/>
> 
> "We can die but once, and that once we must die.  To be always fearing, then, would not avert it, and would make life miserable."
> 
> - Tarzan, on death
> 
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

First Pogril: Why is life like sticking your head in a bucket filled with hyena offal?
Second Pogril: I don't know.  Why IS life like sticking your head in a bucket filled with hyena offal?
First Pogril: I don't know either.  Wretched, isn't it?

-HitchHiker's Guide to the Galaxy


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20180427/f52d2e90/attachment.html>