I tried: out_ar[:] = ((in_ar[0] + 29) > 0)
to try to remove the suspected truncation - bring -29 up to 0 before it's truncated - but then elevation 227 is false and everything else is true (<=226, >=228) > On Apr 27, 2018, at 12:42 PM, William Kyngesburye <[email protected]> > wrote: > > 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 <[email protected]> >> 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 <[email protected]> >>> 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 >>> _______________________________________________ >>> gdal-dev mailing list >>> [email protected] >>> https://lists.osgeo.org/mailman/listinfo/gdal-dev >> >> ----- >> William Kyngesburye <kyngchaos*at*kyngchaos*dot*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 >> [email protected] >> 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 > > > _______________________________________________ > gdal-dev mailing list > [email protected] > https://lists.osgeo.org/mailman/listinfo/gdal-dev ----- William Kyngesburye <kyngchaos*at*kyngchaos*dot*com> http://www.kyngchaos.com/ [Trillian] What are you supposed to do WITH a maniacally depressed robot? [Marvin] You think you have problems? What are you supposed to do if you ARE a maniacally depressed robot? No, don't try and answer, I'm 50,000 times more intelligent than you and even I don't know the answer... - HitchHiker's Guide to the Galaxy _______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
