[gdal-dev] Merging Multi-Band Drone Imagery

I have individual TIFS from the different sensors on the drone. Currently, I have the R, G, NIR, and Redge bands. Is the correct method to merge these into a multi-band image that I can then view as NDVI or apply other algorithms against just to use: gdal_merge.py -separate R.TIF G.TIF NIR.TI

Re: [gdal-dev] Block cache and VRT sources

Thanks, Even. I think I've got my head around it. Since I've never written a driver, I've never fully learned the difference between IReadBlock and IRasterIO or where one is used instead of the other. But I'm learning that now. On Fri, Apr 19, 2024 at 9:35 AM Even Rouault wrote: > > Le 19/04/202

Re: [gdal-dev] Block cache and VRT sources

Le 19/04/2024 à 17:28, Sean Gillies a écrit : Even, Does the shared attribute of a VRT sourceFilename element not affect caching at all? If shared is set to 0, then one GDALDataset per VRTSource will be opened. This has little benefit. The scope of sharing was initially greater since it e

Re: [gdal-dev] Block cache and VRT sources

Even, Does the shared attribute of a VRT sourceFilename element not affect caching at all? Is the cache avoided so that potentially stale data isn't propagated, or for other reasons? On Fri, Apr 19, 2024 at 9:09 AM Even Rouault wrote: > Sean, > > Within a given GDALDataset opened on a VRT, if t

Re: [gdal-dev] Block cache and VRT sources

Sean, Within a given GDALDataset opened on a VRT, if the VRT references several times the same source, only one GDALDataset will be opened for it, so you may benefit from the block cache mechanism (if it is triggered. VRTSource::IRasterIO() calls IRasterIO() on the source band, which doesn't

[gdal-dev] Block cache and VRT sources

Happy Friday, folks! Are the source rasters of a VRT added to the block cache such that different VRTs using the same source can avoid reads from disk or the network? Or is it intended that the VSI cache covers this need instead? Thanks, -- Sean Gillies _

Re: [gdal-dev] gdal_contour: min value unexpected

Thanks Even, I create a ticket: https://github.com/OSGeo/gdal/issues/9705 With regards, Paul Op vr 19 apr 2024 om 11:46 schreef Even Rouault : > Hi, > > > I can't imagine this is a bug that was never noticed before. > > Why? If everybody followed that reasoning nobody will report and hardly >

Re: [gdal-dev] gdal_contour: min value unexpected

Hi, I can't imagine this is a bug that was never noticed before. Why? If everybody followed that reasoning nobody will report and hardly any bug would be fixed. (and there are a number of known bugs that nobody has had time to fix either) So I assume I'm doing something wrong. But I can't fig

Re: [gdal-dev] Export PG to GPKG with foreign keys

Le 19/04/2024 à 10:25, Matteo Ghetta via gdal-dev a écrit : Hi all, I'm trying to export a PG table with several foreign keys to a geopackage. What I tried so far are the native QGIS export and the QGIS Processing algorithm "Package layer" with the "Export related layers following..." opti

[gdal-dev] Export PG to GPKG with foreign keys

Hi all, I'm trying to export a PG table with several foreign keys to a geopackage. What I tried so far are the native QGIS export and the QGIS Processing algorithm "Package layer" with the "Export related layers following..." option activated. I'm checking ogr2ogr but I cannot see any option

Re: [gdal-dev] gdal_contour: min value unexpected

Hi List, I tried my command on GDAL 3.8.4, released 2024/02/08. And the results are the same. The lowest value is still incorrect. I can't imagine this is a bug that was never noticed before. So I assume I'm doing something wrong. But I can't figure it out. Please give me some advice. Regards,