Re: [gdal-dev] gdal_retile not enough memory

just a shot in the dark, but maybe increasing GDAL_CACHEMAX would help? > You need to enlarge cache size (GDAL_CACHEMAX) so that it can fit the > uncompressed tiles of one single row (count tiles in the row, not pixels.) > > ceil(126015/128)*3*8*128*128 = 387 118 080 = half a gigabyte >From my

Re: [gdal-dev] Motion: RFC 78: gdal-utils package

Having been away from gdal-dev for some years, happily existing as an end of the line tool only user, and only recently re-engaging with the development community I have nothing to say on the strength and validity the RFC. I would like to comment though that it doesn't have a high altitude overvi

Re: [gdal-dev] interpreting gdalcompare results

Oohhh. A "doh!" moment. I did not see the word `overview` in "Band 1 overview count difference:" heading. Sheesh. Thanks Jukka! - -Matt -- Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html ___ gdal-dev mailing list gdal-dev@list

Re: [gdal-dev] nearblack on multi GB images very slow

mhw-at-yg wrote > I have a lot of multi GB images that are unfortunately jpeg-in-geotiff > encoded before nodata was properly defined. As a result they all suffer > from > the jagged edges problem. > <http://osgeo-org.1560.x6.nabble.com/file/t192661/WVpPW.png>; > >

Re: [gdal-dev] gdal_retile: output isn't georeferenced?

The source file is georeferenced, so from the docs it does sound like that is supposed to be passed through to the tiles. When I'm back in the office I'll try forcing the SRS and see what happens. -Matt - -Matt -- Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html ___

[gdal-dev] nearblack on multi GB images very slow

I have a lot of multi GB images that are unfortunately jpeg-in-geotiff encoded before nodata was properly defined. As a result they all suffer from the jagged edges problem. I've defined a method for adding a nodata mask side-car file t

[gdal-dev] gdal_retile: output isn't georeferenced?

Is it expected that `gdal_retile -of cog -ps 4096 4096 -t myoutdir infile.tif` creates files that are not georeferenced? Using Gdal from QGIS 3.16 on Win10. ~~~ $ gdalinfo --version GDAL 3.1.4, released 2020/10/20 $ gdalinfo u:.\SPOT6_321_BeaverRiver_08Sep2018_NAD83_YAlbers_01_01.tif.msk Driver:

Re: [gdal-dev] The proper way to call gdal "scripts" on Windows?

I have this bat file in a directory in PATH (For me this is C:\bin\osgeo-py3.bat). I run it in a command session after running Osgeo4W.bat. After this you don't need to use the `python path\to\file.py`invocation. ::: set PATH=%PATH%;%OSGEO4W_ROOT%\apps\Python37;%OSGEO4W_ROOT%\apps\Python37\Scripts

Re: [gdal-dev] Create cloud optimized geotiff without re-encoding?

On the Stack version of this question someone suggested "There should be an option -co COPY_SRC_TIFF_TILES=YES" to copy the source image. (A corollary to -co COPY_SRC_OVERVIEWS=YES.) I now have another use case for this suggestion: using nearblack to add a mask or alpha band to a jpeg-in-tiff imag

Re: [gdal-dev] Create cloud optimized geotiff without re-encoding?

Thank you for that extended comparison Jukka. It looks like there's no feasible way to get there from here, but that too is useful to know. For the gdalcompare results, are we confident that it is analyzing pixels at Row,Col coordinates (or spatial X,Y?) and not at byte offset or something? ---

[gdal-dev] Create cloud optimized geotiff without re-encoding?

Hi Folks, I have a lot of jpeg-in-geotiff imagery that I would like to convert to Cloud Optimized Geotiff. Is there any way to do that without re-encoding the pixel values? I'm trying to avoid paying the price of: * lossy + lossy compression that results from feeding a jpeg source to a jpeg

Re: [gdal-dev] vrt guidance: 31 band classified raster

> You could also potentially use a raster attribute table. See > GDALRasterAttributeTable in https://gdal.org/drivers/raster/vrt.html Yeah, loose is right. ;-) This is what I think I've puzzled out: wou

Re: [gdal-dev] vrt guidance: 31 band classified raster

> I don't see VRT cascading of any help here, from what I've understood of your > use case. I think you have no other choice than replicating and > in all Ok. Thanks for confirming my understanding. Next question: It appears that are order-of-index based. Meaning that: if "Evergreen" is fi

Re: [gdal-dev] vrt guidance: 31 band classified raster

> Have you tried create a cascading VRT, where the first VRT composites > all the GTiff files into a single virtual raster and then reference the > composite in another VRT that assigns colortable. Hmm, I hadn't thought about cascading; didn't know that was possible. I'd still need 31 vrt's thou