[gdal-dev] Issues in Raster Resampling

2022-04-22 Thread Chao Li
Dear Gdal Developer, Thank you for reading my email. I used gdal.Wrap() to resample from a high resolution to a lower. However, my raster has no value (nan). So, when I set resampleAlg, the larger grids with nan(s) will become nan. Here is my reprex in Python: from osgeo import gdal ### resamp

[gdal-dev] default for RelativeToVRT field

2022-04-22 Thread Michael Sumner
I would like to control the relativeToVRT field by setting it to 0/false, it seems the only way to do that is to give a non-local or absolute path to the *output* file, or give an absolute path for the input. . intif=autotest/gdrivers/data/gtiff/byte_signed.tif abtif="$(pwd)"/$intif gdal_translate

Re: [gdal-dev] BAG CRS

2022-04-22 Thread INT
Yeah, I agree with your assessment. I hadn’t realized that you could set the option externally when I started the thread. I agree with you that the user likely set it themselves given what you have shown thus far, so I’ll sort it out with them. Apologies for taking some of your time. Thanks aga

Re: [gdal-dev] BAG CRS

2022-04-22 Thread Even Rouault
André, hum ok. it might perhaps be possible that WKT2 could come when extract the vertical part but I still can't reproduce that trying: $ gdal_translate autotest/gcore/data/byte.tif byte.bag -a_srs 'COMPOUNDCRS["foo",PROJCRS["NAD27 / UTM zone 11N",BASEGEOGCRS["NAD27",DATUM["North American D

Re: [gdal-dev] BAG CRS

2022-04-22 Thread INT
Sorry Even, I should have done more research on my end up front before sending this. A client told us his WKT 2.0 BAG was created with GDAL. Looking at it some more, it was the vertical CRS that was WKT 2.0. Their vertical CRS looked as follows: VERTCRS["ellipse",VDATUM["NAD83(2011) / UTM zone

Re: [gdal-dev] BAG CRS

2022-04-22 Thread Eric Younkin - NOAA Federal via gdal-dev
Just to be clear, I believe we are talking about the vertical wkt string provided through the VAR_VERT_WKT creation option. Not the horizontal coordinate system. On Fri, Apr 22, 2022 at 12:01 PM Vautour, André (INT) < andre.vaut...@teledyne.com> wrote: > Hi all, > > > > It has just come to my at

Re: [gdal-dev] BAG CRS

2022-04-22 Thread Even Rouault
André, I don't confirm this trying: $ gdal_translate autotest/gcore/data/byte.tif byte.bag $ gdalinfo byte.bag -mdd xml:BAG | grep PROJCS     PROJCS["NAD27 / UTM zone 11N",GEOGCS["NAD27",DATUM["North_American_Datum_1927",SPHEROID["Clarke 1866",6378206.4,294.978698213898,AUTHORITY["EPS

[gdal-dev] BAG CRS

2022-04-22 Thread INT
Hi all, It has just come to my attention that the BAG driver in GDAL is writing the CRS with a WKT codeSpace and a WKT 2.0 string as the code. While I am fairly sure we started that incorrect practice here at CARIS with a WKT 1.0 string, this is the first time I've seen a WKT 2.0 string written

[gdal-dev] GDAL 3.4.3 RC2 available (Re: GDAL 3.4.3 RC1 available)

2022-04-22 Thread Even Rouault
I've tagged an RC2 whose only change is in the gdal-grass plugin (backport of https://github.com/OSGeo/gdal/pull/5503) Hence only its corresponding archive is updated: https://download.osgeo.org/gdal/3.4.3/gdal-grass-3.4.3rc2.tar.gz Even Le 22/04/2022 à 11:32, Even Rouault a écrit : Hi, I h

[gdal-dev] GDAL 3.4.3 RC1 available

2022-04-22 Thread Even Rouault
Hi, I have prepared a GDAL/OGR 3.4.3 release candidate. Pick up an archive among the following ones (by ascending size):   https://download.osgeo.org/gdal/3.4.3/gdal-3.4.3rc1.tar.xz   https://download.osgeo.org/gdal/3.4.3/gdal-3.4.3rc1.tar.gz   https://download.osgeo.org/gdal/3.4.3/gdal343rc1.z