Re: [gdal-dev] tps - gdalwarp vs ogr2ogr

[Andrew C Aitchison via gdal-dev]

https://raw.githubusercontent.com/craigshelley/QuickChart/master/Specification/The%20Quick%20Chart%20File%20Format%20Specification%201.03.pdf
describes a file format which includes polynomials describing forward
*and reverse* tranforms for this.
I don't know how common, or accurate, such reverse transforms are.

Would it be useful or much effort to add the ability to use the 
reverse transform when it is offered ?


[ I have a gdal driver which can read some
 but not all of these files. ]

On Tue, 7 Nov 2023, Even Rouault via gdal-dev wrote:


Hi,

I've ticketed your issue as https://github.com/OSGeo/gdal/issues/8672 . What 
you could try to reduce the execution time is to enable multithreading by 
adding -wo NUM_THREADS=ALL_CPUS to your gdalwarp command line


And yes the previous implementation of the raster TPS transformation was 
"wrong", at least not consistent with the forward direction of the TPS 
transformer as used by ogr2ogr. Both matched on the exact location of ground 
control points, but the result could be substantially different in-between. 
The new implementation solves that, but it implies substantial more 
computation cost as you found out...


Even

Le 07/11/2023 à 08:29, Stijn Tallir via gdal-dev a écrit :

Hi Jukka,

The transformation lasted 3h20min vs 9min (before the fix)!

The results for raster and vector tps transformation are very similar now 
and nothing changed for the vector result. Do I have to conclude the 
previous rasters tps transformation method was faulty then?


Stijn

Op ma 6 nov 2023 om 16:32 schreef Stijn Tallir >:


Hi,

Does that mean the old raster tps transformation was "wrong" or
the old vector transformation?

I'm doing a test and trying to transform my raster image with the
latest dev version in osgeo4W but it takes forever to process now.
Don't know in how many days I will see the result :(

The vector transformation with the latest dev version was the same
(time and result).

Stijn

Op ma 6 nov 2023 om 14:48 schreef Rahkonen Jukka
:

Hi,

See the issue https://github.com/OSGeo/gdal/issues/8572
. Maybe your
problem is also resolved by
https://github.com/OSGeo/gdal/pull/8573. The fix is included
in the GDAL 3.8 RC1 version that was released 3 hour ago. Do
you have an option to make a test?

-Jukka Rahkonen-

*Lähettäjä:* Stijn Tallir 
*Lähetetty:* maanantai 6. marraskuuta 2023 14.47
*Vastaanottaja:* Rahkonen Jukka

*Kopio:* gdal-dev@lists.osgeo.org
*Aihe:* Re: [gdal-dev] tps - gdalwarp vs ogr2ogr

Hi Jukka,

I finally found the time to produce a test set.

You can download it here:

https://drive.google.com/file/d/1Y08Q-tIm5dxyKFKNdVqilvAO3H7FFFbx/view?usp=sharing

I started from an unreferenced raster file (raster2tps.tif)
with gcp's (gcp4tps.gcp) and transformed it with tps
(tpsraster.tif).

Then polygonized the unreferenced raster file (vector2tps.shp)
and transformed the result with  the same gcp's (gcp4tps.gcp)
and with tps (tpsvector.shp).

The vector2tps.shp polygons are "flipped" because of the
different Y-origin for rasters and vectors but this way both
datasets can use the exact same gcp's.

When you lay the tpsvector-result on top of the
tpsraster-result (in QGis for instance) you'll see the
differences in how both are transformed.

Kind regards,

Stijn

Op wo 16 aug 2023 om 13:16 schreef Stijn Tallir
mailto:stijn%2bgdal-...@strict.be>>:

Yes, I checked them visually for both raster and vector.

I compared the results also visually. The rasters are
transformed in a way that the end ponts of the gcp's align
exactly with the result so that is why I referred to it as
"right". The vector data result is in the neighbourhood of
the end points (sometimes a rather significant distance).

The result is different from order 1-3 transformations so
I presume the tps option isn't ignored.

Stijn

Op wo 16 aug 2023 om 11:52 schreef Rahkonen Jukka
:

Hi,

Did you check the ground control points? What is your
reference when you say that one result is right, and
another wrong? Have you used some other software for
comparison? Or do you only know that the results are
different?

-Jukka-

*Lähettäjä:* Stijn Tallir 
*Lähetetty:* keskiviikko 16. elokuuta 2023 12.27
*Vastaanottaja:* Rahkonen Jukka

*Kopio:* gdal-dev@lists.osgeo.org
*Aihe:* Re: [gd

Re: [gdal-dev] Un-vendoring a number of third-party libraries?

[Andrew C Aitchison via gdal-dev]

On Fri, 15 Dec 2023, Even Rouault via gdal-dev wrote:

If the scope of this were to unvendor just these four (libjpeg, libpng, 
zlib, giflib), I think it is enough to start, but it brings up the question 
of whether or not JPEG, PNG, and GIF support are hard dependencies in GDAL 
afterward. They're always available no matter how you build  now, so would 
we make them hard dependencies or relax them to optional after unvendoring? 
I assume zlib would move to a hard dependency of GDAL.


I would let libjpeg, libpng, giflib, liblerc as optional dependencies. Our 
CMake scripts already handle them as optional. Someone doing a GDAL build 
only for vector might want to skip them.


But strongly recommended at least for libjpeg and libpng, since beyond being 
standalone formats, they are also used for example for GeoPackage, MBTiles, 
MRF, OGCAPI/WMS/WMTS, etc.


Yes zlib would move to a hard dependency, like PROJ (and if you build PROJ 
with libtiff or libcurl support, you must certainly already have zlib as it 
is a canonical dependency of those). There are lots of places in the code 
base where we assume deflate compression/decompression to be available.


I don't see a problem but libpng also uses zlib. Do we need to
do anything to ensure that gdal uses the same zlib as libpng ?

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Under what (if any) conditions would GDALWriteBlock modify data buffer?

[Andrew C Aitchison via gdal-dev]

On Mon, 18 Dec 2023, Even Rouault via gdal-dev wrote:


Hi,

interesting question. No easy answer as it is highly driver dependent. I 
believe that all drivers make sure that the content of the buffer before and 
after the call is the same, but some drivers might temporarily modify it, to 
do byte swapping. For example the HFA driver does that when run on big-endian 
hosts for non-Byte data type. I wouldn't exclude that for formats with 
MSB-byte ordering, a similar situation would happen for little endian hosts. 
So it is definitely not safe to use WriteBlock() with a buffer that would 
come from a read-only section of the calling program. Doc updated to reflect 
that in 
https://github.com/OSGeo/gdal/commit/ea321723dfc69ef3a422b1e3fe4dc9ee0832861d


Did you mean to say
  Note that even with eRWFlag==GF_Write, the content of the buffer
  might be temporarily modified during the execution of this method
  (and eventually restored back to its original content), so it is not
  safe to use a buffer stored in a read-only section of the calling
  program.

or
Note that even with eRWFlag==GF_Read,  ...

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Under what (if any) conditions would GDALWriteBlock modify data buffer?

[Andrew C Aitchison via gdal-dev]

On Mon, 18 Dec 2023, Even Rouault via gdal-dev wrote:



Le 18/12/2023 à 16:18, Andrew C Aitchison via gdal-dev a écrit :

On Mon, 18 Dec 2023, Even Rouault via gdal-dev wrote:


Hi,

interesting question. No easy answer as it is highly driver dependent. I 
believe that all drivers make sure that the content of the buffer before 
and after the call is the same, but some drivers might temporarily modify 
it, to do byte swapping. For example the HFA driver does that when run on 
big-endian hosts for non-Byte data type. I wouldn't exclude that for 
formats with MSB-byte ordering, a similar situation would happen for 
little endian hosts. So it is definitely not safe to use WriteBlock() with 
a buffer that would come from a read-only section of the calling program. 
Doc updated to reflect that in 
https://github.com/OSGeo/gdal/commit/ea321723dfc69ef3a422b1e3fe4dc9ee0832861d


Did you mean to say
  Note that even with eRWFlag==GF_Write, the content of the buffer
  might be temporarily modified during the execution of this method
  (and eventually restored back to its original content), so it is not
  safe to use a buffer stored in a read-only section of the calling
  program.


Yes I meant that. I've less evidence in the RasterIO(GF_Write, ...) case than 
in the WriteBlock() case, but without checking all drivers, it is more 
prudent to assume that the buffer might be touched during RasterIO(GF_Write) 
by some drivers.


In that case I don't understand
   Note that even with eRWFlag==GF_Write...
It suggests to me that the buffer may be modified for eRWFlag==GF_Write
*as well as* for eRWFlag==GF_Read (which implies that it is *more* likely
to happen for GF_Read) ?

Sorry to be confused.

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Under what (if any) conditions would GDALWriteBlock modify data buffer?

[Andrew C Aitchison via gdal-dev]

On Mon, 18 Dec 2023, Even Rouault wrote:



Le 18/12/2023 à 21:15, Andrew C Aitchison a écrit :

On Mon, 18 Dec 2023, Even Rouault via gdal-dev wrote:



Le 18/12/2023 à 16:18, Andrew C Aitchison via gdal-dev a écrit :

On Mon, 18 Dec 2023, Even Rouault via gdal-dev wrote:


Hi,

interesting question. No easy answer as it is highly driver dependent. I 
believe that all drivers make sure that the content of the buffer before 
and after the call is the same, but some drivers might temporarily 
modify it, to do byte swapping. For example the HFA driver does that 
when run on big-endian hosts for non-Byte data type. I wouldn't exclude 
that for formats with MSB-byte ordering, a similar situation would 
happen for little endian hosts. So it is definitely not safe to use 
WriteBlock() with a buffer that would come from a read-only section of 
the calling program. Doc updated to reflect that in 
https://github.com/OSGeo/gdal/commit/ea321723dfc69ef3a422b1e3fe4dc9ee0832861d


Did you mean to say
  Note that even with eRWFlag==GF_Write, the content of the buffer
  might be temporarily modified during the execution of this method
  (and eventually restored back to its original content), so it is not
  safe to use a buffer stored in a read-only section of the calling
  program.


Yes I meant that. I've less evidence in the RasterIO(GF_Write, ...) case 
than in the WriteBlock() case, but without checking all drivers, it is 
more prudent to assume that the buffer might be touched during 
RasterIO(GF_Write) by some drivers.


In that case I don't understand
   Note that even with eRWFlag==GF_Write...
It suggests to me that the buffer may be modified for eRWFlag==GF_Write
*as well as* for eRWFlag==GF_Read (which implies that it is *more* likely
to happen for GF_Read) ?


Ah, perhaps non-idiomatic wording from mine. I struggle to make that clearer: 
if you've better wording to suggest, that's welcome


Ah. I had misunderstood.
I thought we were reading to or writing from *the buffer* not the raster.
The text is fine.

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Virtual Raster Tile Index (VRTTI) driver, and associated gdaltindex improvements

[Andrew C Aitchison via gdal-dev]

On Wed, 20 Dec 2023, Even Rouault via gdal-dev wrote:


Hi,

For those not actively following github tickets & PR, I just 
want to point to a new pending major functionality to improve 
management of virtual mosaics with a very large number of 
tiles/sources (> tens of thousands of tiles), by referencing 
them as features of a vector layer (typically created by 
gdaltindex), instead of a XML file as in traditional VRT, 
augmented with additional metadata.


More details in https://github.com/OSGeo/gdal/pull/8983 (and in 
initial ticket in https://github.com/OSGeo/gdal/issues/8861)


Am I right in thinking that all the tiles must have the same
bit-depth and colour interpretation and for paletted tiles
the same colour table ?

I am aware of a vendor whose products had different colour tables,
and even different bit-depths, for each tile - a sort of adaptive
compression.

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] gdal_merge -of format

[Andrew C Aitchison via gdal-dev]

On Wed, 10 Jan 2024, ni hao via gdal-dev wrote:


Hi list,



question about: gdal_merge -of format

 besides GTiff, what other formats can I specify? May I specify USGS DEM format?


Look in the output of
gdalinfo --formats
any raster format with rw for read-write can be used.

# gdalinfo --formats | egrep USGSDEM
  USGSDEM -raster- (rwv): USGS Optional ASCII DEM (and CDED)

- so, yes you can use USGSDEM.

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Testing the driver

[Andrew C Aitchison via gdal-dev]

On Sat, 10 Feb 2024, Even Rouault via gdal-dev wrote:



To test your own development, you may have a more pleasant experience by 
directly running just the tests for your driver with something like "pytest 
autotest/ogr/ogr_miramon.py"  (be careful on Windows, the content of 
$build_dir/autotest is copied from $source_dir/autotest each time "cmake" 
is run, so if you edit your test .py file directly in the build directory, 
be super careful of not accidentally losing your work, and make sure to 
copy its content to the source directory first. That's admittedly an 
annoying point of the current test setup on Windows, compared to Unix where 
we use symbolic links)


Actually Dan figured out it was possible to run directly the tests against 
your test file from the source directory, and not the one that is copied. Cf 
https://github.com/OSGeo/gdal/pull/9224


So you can actually do from the build directory:

pytest -c autotest/pytest.ini ../autotest/ogr/ogr_gpx.py


Recent tarball releases have cmake/template/pytest.ini.in
but how do I genenerate autotest/pytest.ini ?

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Build question: GDAL with libwebp....

[Andrew C Aitchison via gdal-dev]

On Tue, 13 Feb 2024, Carl Godkin via gdal-dev wrote:


Hi,

Sorry if this is an elementary cmake question but I am curious if there is
a cleaner solution than I came up with.

I'm trying to build GDAL 3.8.3 with WEBP support.

I built libwebp 1.3.2 (the latest) without any problems, also using cmake.

However, when building GDAL, the link on the shared library fails since
WEBP seems to require TWO libraries (in the libwebp package), libwebp and
libsharpyuv.

My question is how can I persuade cmake to accept both libraries for
WEBP_LIBRARY?

I thought quotes would help.  What I think I ought to be able to do is
something like

  -DWEBP_LIBRARY="/usr/local/devlibs/libwebp-1.3.2/lib64/libwebp.a
/usr/local/devlibs/libwebp-1.3.2/lib64/libsharpyuv.a" \

or else

  "-DWEBP_LIBRARY=/usr/local/devlibs/libwebp-1.3.2/lib64/libwebp.a
/usr/local/devlibs/libwebp-1.3.2/lib64/libsharpyuv.a" \

but both options produce link lines that include the double quotes!  This
is an issue on Windows and Linux for me.


CMAKE is rather more verbose than that.

Compare
   gdal/frmts/webp/CMakeLists.txt
with
   gdal/frmts/png/CMakeLists.txt
for how the png driver uses libpng and zlib

You probably don't need the gdal_add_vendored_lib commands or the 
GDAL_USE_..._INTERNAL tests, since gdal is not bundling libwebp.



I have a couple of workarounds that I won't bore you with, but I was
wondering what the best practice is here (other than hand-editing the cmake
output of course).

I think that libwebp added the "sharpyuv" stuff at version 1.3.0 so perhaps
using an older version would also work, but that doesn't seem sustainable.

Thanks for suggestions,

carl



--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Testing the driver

[Andrew C Aitchison via gdal-dev]

On Sun, 18 Feb 2024, Even Rouault wrote:


Le 10/02/2024 à 18:34, Andrew C Aitchison via gdal-dev a écrit :

On Sat, 10 Feb 2024, Even Rouault via gdal-dev wrote:

To test your own development, you may have a more pleasant experience by 
directly running just the tests for your driver with something like 
"pytest autotest/ogr/ogr_miramon.py"  (be careful on Windows, the content 
of $build_dir/autotest is copied from $source_dir/autotest each time 
"cmake" is run, so if you edit your test .py file directly in the build 
directory, be super careful of not accidentally losing your work, and 
make sure to copy its content to the source directory first. That's 
admittedly an annoying point of the current test setup on Windows, 
compared to Unix where we use symbolic links)


Actually Dan figured out it was possible to run directly the tests against 
your test file from the source directory, and not the one that is copied. 
Cf https://github.com/OSGeo/gdal/pull/9224


So you can actually do from the build directory:

pytest -c autotest/pytest.ini ../autotest/ogr/ogr_gpx.py


Recent tarball releases have cmake/template/pytest.ini.in
but how do I genenerate autotest/pytest.ini ?

It is generated by cmake


Ah. If I do:
  tar Jxf gdal-3.8.4rc1.tar.xz
  tar zxf gdalautotest-3.8.4rc1.tar.gz
  ln -s ../gdalautotest-3.8.4 gdal-3.8.4/autotest
  cd gdal-3.8.4
  cmake -B build
build/autotest/pytest.ini is generated.

That link is not what I had expected -
  ln -s ../gdalautotest-3.8.4 gdal-3.8.4/gdalautotest
would have been more obvious to me, and I did try running cmake inside 
gdalautotest-3.8.4 first.


--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Testing the driver

[Andrew C Aitchison via gdal-dev]

On Wed, 6 Mar 2024, Daniel Evans via gdal-dev wrote:


Is it worth moving this in-depth discussion to a PR or similar for the new
driver?

My thinking is that a lengthy discussion on memory leak detection
techniques in C++, how to run tests in Python, etc., aren't topics relevant
to most GDAL mailing list subscribers.


Maybe so, but how to develop gdal is surely on-topic
for gdal-dev ?

I"m still following and learning.

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Using a "standard" argument parser for command line utilities?

[Andrew C Aitchison via gdal-dev]

On Fri, 8 Mar 2024, Even Rouault via gdal-dev wrote:


Hi,

Our command line C++ utilities use ad-hoc manual parsing, which means that:

-  the usage message must be manually composed,

-  you must take care to check that there are enough remaining arguments for 
the ones that take value to avoid out-of-bounds accesses (tests like argc + 1 
< argn)


- detection for duplicated arguments when only a single occurrence is allowed 
must be manually done, nd thus is often not done, confusing users, cf 
https://github.com/OSGeo/gdal/issues/9415


- etc.

I've come across https://github.com/p-ranav/argparse which fit all my 
requirements at first sight: compatible with our C++ requirements (C++17), 
MIT license, easily usable (single header), well documented, and enough 
feature-full. From a quick testing, it seems to work well. It looks also as 
it has taken some inspiration from the Python argparse module.


I'd be tempted to give that a try to retrofit our existing utilities 
(probably starting with the ones with the less options :-)). Opinions? I 
guess there must be a plethora of similar projects, due to the absence of a 
std::argparse module... At least I see it is in the list of (9) alternatives 
mentioned at 
https://en.cppreference.com/w/cpp/links/libs?source=post_page---#Configuration:Command_Line


Some options have related environment variables, eg --debug /CPL_DEBUG.
Options are also passed through to several drivers.
I assume that the implications for these are not significant ?

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Issue with using GDAL warp

[Andrew C Aitchison via gdal-dev]

On Sun, 24 Mar 2024, Ian Hannah via gdal-dev wrote:


Hi,

I am using 3.8.4  of GDAL .NET and running this code:

   string[] warpOptions =
   {
   "outputType", GdalConst.GDT_Byte.ToString(),
   "srcSRS", projectionWKT,
   "dstSRS", "EPSG:3857",
   "accessMode", "overwrite"
   };

   string geoTiffOutputFileName = Path.GetTempFileName();
   string pngOutputFileName = convertToImage ? 
Path.GetTempFileName() : null;

   try
   {
   GDALVectorTranslateOptions gdalWarpOptions = new 
GDALVectorTranslateOptions(warpOptions);

   using (Dataset outputDataset = 
Gdal.wrapper_GDALVectorTranslateDestName(geoTiffOutputFileName, dataset, 
gdalWarpOptions, null, null))
   {
   if (convertToImage)
   {
   string[] translateOptions = { "-of", "PNG" };
   using 
(Gdal.wrapper_GDALTranslate(pngOutputFileName, outputDataset, new 
GDALTranslateOptions(translateOptions), null, null)) { }
   }
   }
 }

And on the call to Gdal.wrapper_GDALVectorTranslateDestName I get the following 
error:

System.ApplicationException: 'Cannot guess driver for F:\Temp\2\tmp7A67.tmp'

This is in the generation of the geoTiffOutputFileName file.

Does anyone know why I am getting this error?


You are trying to overwrite the file, which often means to put new data
into an existing file. But since it is a tmp file I guess that it does not 
yet exist, so GDAL cannot read it to work out what format it is in.


Nowhere do you say what format outputDataset should have.

Maybe declaring the output file format would stop this error.

Unless you actual want a tiff and a png of the result,
maybe you don't actually need the call to Gdal.wrapper_GDALTranslate ?

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Incorrect geolocation information using newer gdal versions

[Andrew C Aitchison via gdal-dev]

On Tue, 26 Mar 2024, Cristhian Rivera via gdal-dev wrote:


Hi all,

I'm trying to debug an issue with a NetCDF file where in previous gdal
versions (up until 3.3.0) the geolocation was correctly identified by
gdalinfo, but in newer versions (>= 3.3.1) it is not.


I note that both versions output the warnings:

Warning 1: dimension #2 (Easting) is not a Longitude/X dimension.
Warning 1: dimension #1 (Northing) is not a Latitude/Y dimension.

gdalinfo --debug on 2024032100.nc
gives me more info:

Warning 1: dimension #2 (Easting) is not a Longitude/X dimension.
Warning 1: dimension #1 (Northing) is not a Latitude/Y dimension.
GDAL_netCDF:
=
SetProjectionFromVar( 65536, 4)
GDAL_netCDF: got grid_mapping crs
GDAL_netCDF: bIsGdalFile=0 bIsGdalCfFile=0 bSwitchedXY=0 bBottomUp=1
netCDF: Georeferencing ignored due to non-specific enough X axis name. Set 
GDAL_NETCDF_IGNORE_XY_AXIS_NAME_CHECKS=YES as configuration option to 
bypass this check
netCDF: Georeferencing ignored due to non-specific enough Y axis name. Set 
GDAL_NETCDF_IGNORE_XY_AXIS_NAME_CHECKS=YES as configuration option to 
bypass this check
GDAL_netCDF: bGotGeogCS=0 bGotCfSRS=0 bGotCfGT=0 bGotCfWktSRS=0 
bGotGdalSRS=0 bGotGdalGT=0

GDAL_netCDF: did not get geotransform from CF nor GDAL!
GDAL_netCDF: did not get projection from CF nor GDAL!
GDAL_netCDF: netcdf type=5 gdal type=6 signedByte=1
GDAL: GDALOpen(2024032100.nc, this=0x63c988f650a0) succeeds as netCDF.
GDAL: GDALDefaultOverviews::OverviewScan()
GDAL: GDALClose(2024032100.nc, this=0x63c988f650a0)



In the attachments are the outputs of gdalinfo from the versions mentioned,
but the difference in both outputs is that newer versions cannot find the
"Origin" and "Pixel size", and the Corner coordinates differ a lot:

*Gdal 3.3.0:*


Origin = (24500.000,465500.000)
Pixel Size = (1000.000,-1000.000)




Corner Coordinates:

Upper Left  (   24500.000,  465500.000)
Lower Left  (   24500.000,   14500.000)
Upper Right (  375500.000,  465500.000)
Lower Right (  375500.000,   14500.000)
Center  (  20.000,  24.000)




= *Gdal 3.3.1*



Corner Coordinates:
Upper Left  (0.0,0.0)
Lower Left  (0.0,  451.0)
Upper Right (  351.0,0.0)
Lower Right (  351.0,  451.0)
Center  (  175.5,  225.5)



The files can also be found in the following drive repo if they are not
available in the mail:
https://drive.google.com/drive/folders/1zqV3n2SYUhOjgwxpYpChwqdNTiHAgNHj?usp=sharing


I've tried checking the changelog of that version but it seems only like a
bug fix release.
Any ideas of what else I can test to identify the issue?



--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Expiring token during paging on the WFS

[Andrew C Aitchison via gdal-dev]

On Thu, 28 Mar 2024, Michael Otto via gdal-dev wrote:


Hello,

I have an important question about the use of a 'GDAL_HTTP_HEADER_FILE'.

If I request a WFS with "OGR_WFS_PAGING_ALLOWED=ON" and use a header file
for authentication, will the header file be read with every new page?

I am wondering how I should deal with an expiring bearer token (validity
5min) with a very long lasting query (>5min).


Is this for one WFS service, or many ?
Assuming you are consuming the data promptly and aren't overloaded,
I would discuss this with the WFS service; you probably aren't
the only one having this issue. If sending the data takes longer
than the life of the token, they need longer-lived tokens.

Sorry I can't help with your actual questions.


Questions:
Does ogr2ogr query the header file again for each new page?
Can I possibly set the authentication for every single requested page?
Is there another way to deal with expiring tokens?

Michael

PS:
I use Java and start the apps via the ProcessBuilder.
If the header file is re-read for each page, I could update it accordingly
(preferably without conflicts due to simultaneous reading and writing ;o)
).



--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Printing a size_t variable on all github platforms ?

[Andrew C Aitchison via gdal-dev]

I am trying to print a size_t variable* with CPLDebug, but
am struggling to find a format that works for all the guthub builds.

The main problem is that the "build-windows-msys2-mingw" build
does not support the format option %zu

../../../frmts/vrc/VRC.cpp:159:47: error: unknown conversion type character 'z' 
in format [-Werror=format=]
  159 |  "VRC_png_read_data_fn(%p %p %zu) reached end of data",
  |   ^
https://github.com/andrew-aitchison/gdal/actions/runs/8691997363/job/23835554972
lines 586-8.

Since size_t is usually an unsigned int on 64-bit systems and
an unsigned long on 32-bit systems ("build-windows-msys2-mingw"
and "Alpine, gcc 32-bit") I cannot use %u or %lu either,
without conditional compiling.
I don't see any helpful definition in  either

Am I missing a way of printing a size_t ?
I suppose I could cast it to an unsigned long (long?) and hope.

Thanks,

---  Pedantry

I'm ultimately trying to print "myVector.size()"
which is a "std::vector<...>::size_type", which
  https://stackoverflow.com/questions/918567/size-t-vs-containersize-type
says *may* be be different from a size_t ... but
  https://en.cppreference.com/w/cpp/types/size_t
says that std::size_t is big enough (or the type is ill-formed).

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Adding a CI "stale" workflow for pull requests without activity

[Andrew C Aitchison via gdal-dev]

On Thu, 18 Apr 2024, Even Rouault via gdal-dev wrote:

I'm proposing in https://github.com/OSGeo/gdal/pull/9693 that we add a CI 
"stale" workflow for pull requests without activity. It is mostly a 
copy&paste from QGIS similar workflow with the following changes:
- restrict the scope to pull requests only and not tickets (although we could 
potentially also do that for tickets that are in the "awaiting feedback" 
state)
- increase the period to tag a pull request as "stale" to 28 days without 
activity. The stale bot adds a message in the PR explaining that, and that 
they have an extra delay of 14 days to make it progress, otherwise it will be 
automatically closed. So basically a PR without activity for 6 weeks will be 
automatically closed. I think this is a fair delay.


The rationale for that is that it makes the cognitive load of PR reviewers 
lower by avoiding to have to read repeatedly a list of stale PRs, and it also 
encourages contributors to either make their work progress towards completion 
(or just make them realize that they don't have the bandwidth or motivation 
to make it further progress, which is also fine).


I assume this is for PRs awaiting response from the requester,
not PRs awaiting a response from a reviewer ?

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Question on building multi band composite and going back to RGB GeoTiff

[Andrew C Aitchison via gdal-dev]

On Mon, 22 Apr 2024, Raley, Nathan via gdal-dev wrote:


Hmm, good catch.  Looking at the stats for the red band:

Band 1 Block=128x128 Type=UInt16, ColorInterp=Gray
 Min=130.000 Max=36265.000
 Minimum=130.000, Maximum=36265.000, Mean=10415.962, StdDev=3502.933
 NoData Value=0
 Metadata:
   STATISTICS_MAXIMUM=36265
   STATISTICS_MEAN=10415.961859513
   STATISTICS_MINIMUM=130
   STATISTICS_STDDEV=3502.9325925887
   STATISTICS_VALID_PERCENT=49

So, is there no way to actually do this via command line, or am I going to have 
to write a python lib to actually read through these and determine what they 
should be scaled to?


There is gdal_transform -scale (and -scale_2 etc.)

What are you going to do with the resulting file ?
QGIS allows you to make these sorts of adjustments at view-time.

Remember that the max and min values present in an image may not represent
the full range and the next-door image may have a larger or smaller range
(or just a shifted range). Imagine a row of three tiles; the middle on on 
the edge of a glacier, the first entirely on the glacier and the last 
entirely off the glacier. You may wish to apply the same scaling to all 
three.



From: Daniel Evans 
Sent: Monday, April 22, 2024 9:29 AM
To: Raley, Nathan 
Cc: 'gdal-dev@lists.osgeo.org' (gdal-dev@lists.osgeo.org) 

Subject: [External] Re: [gdal-dev] Question on building multi band composite 
and going back to RGB GeoTiff

Hi Nathan, My initial suspicion might just be that the scaling the data 
provider did to go from the raw data to a human-eye-friendly RGB composite 
isn't the conversion you're assuming. I know that with the data I regularly 
work with,

Hi Nathan,

My initial suspicion might just be that the scaling the data provider did to go 
from the raw data to a human-eye-friendly RGB composite isn't the conversion 
you're assuming.

I know that with the data I regularly work with, it may be provided as Uint16, 
but the data range doesn't extend all the way to 65535.

If you compare the values in the separate R and G images to the RGB composite, 
do they appear to match the conversion you're assuming, or is there a different 
scaling (and possibly offset)?

Cheers,
Daniel

On Mon, 22 Apr 2024, 15:20 Raley, Nathan via gdal-dev, 
mailto:gdal-dev@lists.osgeo.org>> wrote:
I currently have a RGB geotiff composite image that has a Byte datatype.  I 
also have individual band images for R, G, Redge, and NIR that are UInt16 
datatypes.  Since I’m missing the Blue band from the individual bands, I was 
attempting to extract the blue band from the RGB composite image, scale it up 
to the UInt16 datatype, and build a composite VRT with R, G, B, NIR, RE bands 
included in it.  I was then attempting to extract the RGB bands from the 
multispec VRT in order to see if the process was working as intended, but I’m 
getting an extremely blue image.

Can anyone shed some light as to what I may be doing wrong here?

I started by building a VRT for each band:
gdal_translate source_RGB.tif b.vrt -ot UInt16 -of VRT -b 3 -scale 0 255 0 65535
gdalbuildvrt -b 1 r.vrt source_R.tif
gdalbuildvrt -b 1 g.vrt source_G.tif
gdalbuildvrt -b 1 nir.vrt source_NIR.tif
gdalbuildvrt -b 1 re.vrt source_RE.tif

I then merged the VRTs:
gdalbuildvrt -separate multispec.vrt r.vrt g.vrt b.vrt nir.vrt re.vrt

I now have a multispec.vrt with the R, G, B, NIR, and RE bands, all with a 
UInt16 datatype.

Now, I attempted to rebuild a RGB GeoTiff from the composite VRT with something 
like:
gdal_translate -ot Byte -of GTiff -b 1 -b 2 -b 3 -scale 0 65535 0 255 -co 
PHOTOMETRIC=RGB multispec.vrt multispec.tif

Viewing the result in QGIS appears overly blue.  What am I doing wrong here?

Thanks,
Nathan


This email transmission, including any attachments, is intended solely for the 
addressee named above, and may contain confidential or privileged information. 
If you are not the intended recipient, be aware that any disclosure, copying, 
distribution or use of the contents of this e-mail is prohibited. If you have 
received this e-mail in error, please notify the sender immediately by reply 
email and destroy the message and its attachments.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

This email transmission, including any attachments, is intended solely for the 
addressee named above, and may contain confidential or privileged information. 
If you are not the intended recipient, be aware that any disclosure, copying, 
distribution or use of the contents of this e-mail is prohibited. If you have 
received this e-mail in error, please notify the sender immediately by reply 
email and destroy the message and its attachmen

Re: [gdal-dev] Bumping TileDB minimum from 2.7 to 2.15 for GDAL 3.9?

[Andrew C Aitchison via gdal-dev]

On Wed, 24 Apr 2024, Even Rouault via gdal-dev wrote:

A future TileDB version will remove various deprecated API that the GDAL 
TileDB driver currently uses. https://github.com/OSGeo/gdal/pull/9725 
migrates away from those deprecated APIs, but that causes the minimum 
requirement from TileDB to go from 2.7 to 2.15. It would probably be wise 
to backport this cleanup in the 3.9 branch, so that it doesn't cause 
later packaging issues, typically with conda-forge builds as soon as they 
will package the future TileDB version removing the deprecated APIs, 
which might occur during the GDAL 3.9.x life cycle. Does anyone see an 
issue in doing this bump? The few distributions I'm aware of shipping 
TileDB meet the >= 2.15 requirement: Conda-forge already ships TileDB 
2.22, Alpine Linux is a 2.17.4.


https://docs.tiledb.com/main/how-to/installation/building-from-source
suggests that TileDB requires a C++20 compiler.

Is that an issue ?

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] clang-format variation - just for info

[Andrew C Aitchison via gdal-dev]

I don't think this affects any gdal code.

If you put a comment after an #else an #endif or "}"
(eg to aide finding the start of the block)
then clang-format v15 and v18 will rearrange the
whitespace differently.

Ubuntu Noble 24-04 ships v18.

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: Adopt GDAL 3.9.1RC1 as 3.9.1 release

[Andrew C Aitchison via gdal-dev]

On Thu, 20 Jun 2024, Even Rouault via gdal-dev wrote:


Motion:

Adopt GDAL 3.9.1RC1 as 3.9.1 release

Starting with my +1


As Greg said, 25 hours isn't long to test

I've managed to build and run some tests on Ubuntu 24-04/Noble
using clang compilers (v18 as shipped by Ubuntu and/or v19 from ...)

pytest complained that it could not find h5.py until I installed
   python3-h5py:amd64 (3.10.0-1ubuntu3)

Like several recent gdal versions on other recent Ubuntu releases,
it complains about setup.py
-   ...   ...  ...  ---
Install the project...
-- Install configuration: "debug"
Using numpy 1.26.4
running install
/usr/lib/python3/dist-packages/setuptools/_distutils/cmd.py:66: 
SetuptoolsDeprecationWarning: setup.py install is deprecated.

!!


Please avoid running ``setup.py`` directly.
Instead, use pypa/build, pypa/installer or other
standards-based tools.

See
https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html for
details.



!!  self.initialize_options()
running build
-   ...   ...  ...  ---

# cd /home/werdna/gdal/3.9.1/gdalautotest/gdrivers
# pytest
Test session starts (platform: linux, Python 3.12.3, pytest 7.4.4, 
pytest-sugar 1.0.0)
benchmark: 4.0.0 (defaults: timer=time.perf_counter disable_gc=False 
min_rounds=5 min_time=0.05 max_time=1.0 calibration_precision=10 
warmup=False warmup_iterations=10)

rootdir: /home/werdna/gdal/3.9.1/gdalautotest-3.9.1/gdrivers
plugins: env-0.8.2, flake8-1.1.1, benchmark-4.0.0, sugar-1.0.0
collecting 7 items
 ERROR collecting data/s104/generate_test.py 


import file mismatch:
imported module 'generate_test' has this __file__ attribute:

/home/werdna/gdal/3.9.1/gdalautotest-3.9.1/gdrivers/data/s102/generate_test.py
which is not the same as the test file we want to collect:

/home/werdna/gdal/3.9.1/gdalautotest-3.9.1/gdrivers/data/s104/generate_test.py
HINT: remove __pycache__ / .pyc files and/or use a unique basename for 
your test file modules


 ERROR collecting data/s111/generate_test.py 


import file mismatch:
imported module 'generate_test' has this __file__ attribute:

/home/werdna/gdal/3.9.1/gdalautotest-3.9.1/gdrivers/data/s102/generate_test.py
which is not the same as the test file we want to collect:

/home/werdna/gdal/3.9.1/gdalautotest-3.9.1/gdrivers/data/s111/generate_test.py
HINT: remove __pycache__ / .pyc files and/or use a unique basename for 
your test file modules

collected 7 items / 2 errors

= warnings summary 
==

test_validate_jp2.py:41

/home/werdna/gdal/3.9.1/gdalautotest-3.9.1/gdrivers/test_validate_jp2.py:41: 
PytestUnknownMarkWarning: Unknown pytest.mark.require_driver - is this a 
typo?  You can register custom marks to avoid this warning - for details, 
see https://docs.pytest.org/en/stable/how-to/mark.html

pytestmark = pytest.mark.require_driver("JP2OpenJPEG")

-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
== short test summary info 
==

FAILED data/s104/generate_test.py
FAILED data/s111/generate_test.py
!! Interrupted: 2 errors during collection 
!!


Results (0.76s):

I removed *all* the __pycache__ directories in the tree, reran the 
tests and got the same errors.




Attached (as ogr_basic_test.py.errout) is the output of
running the ogr test ogr_basic_test.py from directory
3.9.1/gdalautotest/ogr

I haven't really tried to run the test suite since the switch
to cmake, but the current errors suggest that the suite is
not ready for someone as inexperienced with it as me to use
it to pass or fail the latest release on this platform.

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk= test session starts ==
platform linux -- Python 3.12.3, pytest-7.4.4, pluggy-1.4.0
benchmark: 4.0.0 (defaults: timer=time.perf_counter disable_gc=False 
min_rounds=5 min_time=0.05 max_time=1.0 calibration_precision=10 
warmup=False warmup_iterations=10)
rootdir: /home/werdna/gdal/3.9.1/gdalautotest-3.9.1/ogr
plugins: env-0.8.2, flake8-1.1.1, benchmark-4.0.0, sugar-1.0.0
collected 68 items

ogr_basic_test.py .F...s...FF.F. [ 79%]
..EEE.   [100%]

 ERRORS 
_ ERROR at setup of test_geom_use_after_tr

[gdal-dev] testclosedondestroydm.test

[Andrew C Aitchison via gdal-dev]

This is not a new failure, so thre is no need for this to hold up 3.9.1.

System: Ubuntu 24-04/Noble on Intel x86-64.
# ctest --output-on-failure

  8<  8<  8<  8<  8<  8<  8< 

28/51 Test #28: test-closed-on-destroy-DM ***Failed0.19 sec
[==] Running 1 test from 1 test suite.
[--] Global test environment set-up.
[--] 1 test from testclosedondestroydm
[ RUN  ] testclosedondestroydm.test
ERROR 4: 
/home/werdna/gdal/3.9.1/gdal-3.9.1/autotest/gdrivers/data/dimap/rgbsmall.tif: 
No such file or directory
ERROR 3: Checksum value could not be computed due to I/O read error.
ERROR 4: 
/home/werdna/gdal/3.9.1/gdal-3.9.1/autotest/gdrivers/tmp/cache/file9_j2c.ntf: 
No such file or directory
Warning 1: byte3.tif: File open for read-only accessing, creating mask 
externally.
ERROR 4: `/home/werdna/gdal/3.9.1/gdal-3.9.1/autotest/gdrivers/data/sid/mercator.sid' 
not recognized as being in a supported file format.

unknown file: Failure
C++ exception with description "basic_string::_M_create" thrown in the test 
body.

[  FAILED  ] testclosedondestroydm.test (157 ms)
[--] 1 test from testclosedondestroydm (157 ms total)

[--] Global test environment tear-down
[==] 1 test from 1 test suite ran. (157 ms total)
[  PASSED  ] 0 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] testclosedondestroydm.test

 1 FAILED TEST

  8<  8<  8<  8<  8<  8<  8< 

Indeed
  /home/werdna/gdal/3.9.1/gdal-3.9.1/autotest/gdrivers/data/dimap/rgbsmall.tif
does not exist, but
  /home/werdna/gdal/3.9.1/gdal-3.9.1/autotest/gdrivers/data/rgbsmall.tif
does.
(I cannot find a file9_j2c with any extension anywhere, but I guess it is 
supposed to be built at test time.)

Full ctest log at:
https://www.aitchison.me.uk/gdal/ctest.391.gnu.errlog

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] testclosedondestroydm.test

[Andrew C Aitchison via gdal-dev]

On Tue, 25 Jun 2024, Even Rouault via gdal-dev wrote:

Can you run "gdb autotest/cpp/testclosedondestroydm" , "run" , and when it 
crashed "bt" so we have a backtrace of where it crashes  (all of that after 
running "source ../scripts/setdevenv.sh")


It doesn't crash:

(gdb) run
Starting program: 
/home/werdna/gdal/3.9.1/gdal-3.9.1.gnu/autotest/cpp/testclosedondestroydm

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[==] Running 1 test from 1 test suite.
[--] Global test environment set-up.
[--] 1 test from testclosedondestroydm
[ RUN  ] testclosedondestroydm.test
ERROR 4: 
/home/werdna/gdal/3.9.1/gdal-3.9.1/autotest/gdrivers/data/dimap/rgbsmall.tif: 
No such file or directory
ERROR 3: Checksum value could not be computed due to I/O read error.
ERROR 4: 
/home/werdna/gdal/3.9.1/gdal-3.9.1/autotest/gdrivers/tmp/cache/file9_j2c.ntf: 
No such file or directory Warning 1: byte3.tif: File open for read-only 
accessing, creating mask externally.
ERROR 4: 
`/home/werdna/gdal/3.9.1/gdal-3.9.1/autotest/gdrivers/data/sid/mercator.sid' 
not recognized as being in a supported file format.
unknown file: Failure
C++ exception with description "basic_string::_M_create" thrown in the test 
body.

[  FAILED  ] testclosedondestroydm.test (112 ms)
[--] 1 test from testclosedondestroydm (112 ms total)

[--] Global test environment tear-down
[==] 1 test from 1 test suite ran. (112 ms total)
[  PASSED  ] 0 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] testclosedondestroydm.test

 1 FAILED TEST
[Inferior 1 (process 889503) exited with code 01]
(gdb) bt
No stack.

--

ln -s ../rgbsmall.tif autotest/gdrivers/data/dimap/rgbsmall.tif
gets rid of the lines:
ERROR 4: 
/home/werdna/gdal/3.9.1/gdal-3.9.1/autotest/gdrivers/data/dimap/rgbsmall.tif: 
No such file or directory
ERROR 3: Checksum value could not be computed due to I/O read error.
but otherwise the same failures.

I do not have the MrSID SDK, so not recognizing mercator.sid is expected.

Would an strace be any use ? Any particular options ?



Le 25/06/2024 à 15:14, Andrew C Aitchison via gdal-dev a écrit :


This is not a new failure, so thre is no need for this to hold up 3.9.1.

System: Ubuntu 24-04/Noble on Intel x86-64.
# ctest --output-on-failure

  8<  8<  8<  8<  8<  8<  8< 

28/51 Test #28: test-closed-on-destroy-DM ***Failed 0.19 sec
[==] Running 1 test from 1 test suite.
[--] Global test environment set-up.
[--] 1 test from testclosedondestroydm
[ RUN  ] testclosedondestroydm.test
ERROR 4: 
/home/werdna/gdal/3.9.1/gdal-3.9.1/autotest/gdrivers/data/dimap/rgbsmall.tif: 
No such file or directory

ERROR 3: Checksum value could not be computed due to I/O read error.
ERROR 4: 
/home/werdna/gdal/3.9.1/gdal-3.9.1/autotest/gdrivers/tmp/cache/file9_j2c.ntf: 
No such file or directory
Warning 1: byte3.tif: File open for read-only accessing, creating mask 
externally.
ERROR 4: 
`/home/werdna/gdal/3.9.1/gdal-3.9.1/autotest/gdrivers/data/sid/mercator.sid' 
not recognized as being in a supported file format.

unknown file: Failure
C++ exception with description "basic_string::_M_create" thrown in the test 
body.


[  FAILED  ] testclosedondestroydm.test (157 ms)
[--] 1 test from testclosedondestroydm (157 ms total)

[--] Global test environment tear-down
[==] 1 test from 1 test suite ran. (157 ms total)
[  PASSED  ] 0 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] testclosedondestroydm.test

 1 FAILED TEST

  8<  8<  8<  8<  8<  8<  8< 

Indeed
/home/werdna/gdal/3.9.1/gdal-3.9.1/autotest/gdrivers/data/dimap/rgbsmall.tif
does not exist, but
/home/werdna/gdal/3.9.1/gdal-3.9.1/autotest/gdrivers/data/rgbsmall.tif
does.
(I cannot find a file9_j2c with any extension anywhere, but I guess it is 
supposed to be built at test time.)


Full ctest log at:
https://www.aitchison.me.uk/gdal/ctest.391.gnu.errlog



--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] testclosedondestroydm.test

[Andrew C Aitchison via gdal-dev]

On Tue, 25 Jun 2024, Even Rouault wrote:



Le 25/06/2024 à 16:25, Andrew C Aitchison a écrit :

On Tue, 25 Jun 2024, Even Rouault via gdal-dev wrote:

Can you run "gdb autotest/cpp/testclosedondestroydm" , "run" , and when it 
crashed "bt" so we have a backtrace of where it crashes  (all of that 
after running "source ../scripts/setdevenv.sh")


It doesn't crash:


Ah, the gtest framework must catch the exception. OK, so after starting gdb 
and before "run", type "catch throw", so that debugger stops when the 
exception is thrown, and then "bt"



#0  0x74ebb0f1 in __cxxabiv1::__cxa_throw (obj=0x5576b940,
tinfo=0x717bb348 ,
dest=0x715e2070 
)
at ../../../../src/libstdc++-v3/libsupc++/eh_throw.cc:81
#1  0x714b2c34 in osgeo::proj::operation::Conversion::_exportToPROJString 
(this=, formatter=0x5576b330)
at /usr/include/c++/13/bits/allocator.h:184
#2  0x715e357d in 
osgeo::proj::io::IPROJStringExportable::exportToPROJString[abi:cxx11](osgeo::proj::io::PROJStringFormatter*)
 const (this=0x557797d8, formatter=0x5576b330) at 
/usr/src/proj-9.4.0-1build2/src/iso19111/io.cpp:8306
#3  0x7165548c in pj_obj_create (ctx=0x556a0180, objIn=...) at 
/usr/src/proj-9.4.0-1build2/src/iso19111/c_api.cpp:201
#4  0x71662633 in proj_create_conversion (ctx=0x556a0180, name=0x0, 
auth_name=, code=0x0,
method_name=0x0, method_auth_name=0x0, method_code=0x0, param_count=0, 
params=0x0)
at /usr/include/c++/13/bits/shared_ptr_base.h:1068
#5  0x75f6585a in OGRSpatialReference::SetProjCS (this=0x7fffb750, 
pszName=0x55773320 "NAD27 / UTM zone 11N")
at /home/werdna/gdal/3.9.1/gdal-3.9.1/ogr/ogrspatialreference.cpp:5548
#6  0x7615c359 in GTIFGetOGISDefnAsOSR (hGTIF=0x55a063a0, 
psDefn=0x55772f80)
at /home/werdna/gdal/3.9.1/gdal-3.9.1/frmts/gtiff/gt_wkt_srs.cpp:856
#7  0x760ffabe in GTiffDataset::LookForProjectionFromGeoTIFF 
(this=0x5569f0e0)
at /home/werdna/gdal/3.9.1/gdal-3.9.1/frmts/gtiff/gtiffdataset_read.cpp:4149
#8  0x760ff8b3 in GTiffDataset::LookForProjection (this=0x5569f0e0)
at /home/werdna/gdal/3.9.1/gdal-3.9.1/frmts/gtiff/gtiffdataset_read.cpp:4096
#9  0x761074e2 in GTiffDataset::GetSpatialRef (this=0x5569f0e0)
at /home/werdna/gdal/3.9.1/gdal-3.9.1/frmts/gtiff/gtiffdataset_read.cpp:6179
#10 0x772569cb in GDALProxyPoolDataset::Create (
pszSourceDatasetDescription=0x55765d90 
"/home/werdna/gdal/3.9.1/gdal-3.9.1/autotest/gcore/data/byte.tif",
papszOpenOptionsIn=0x0, eAccessIn=GA_ReadOnly, bSharedIn=1, pszOwner=0x7fffcfb0 
"0x5569e798")
at /home/werdna/gdal/3.9.1/gdal-3.9.1/gcore/gdalproxypool.cpp:811
#11 0x761b6943 in VRTSimpleSource::OpenSource (this=0x55a27b70)
at /home/werdna/gdal/3.9.1/gdal-3.9.1/frmts/vrt/vrtsources.cpp:720
#12 0x761b6be5 in VRTSimpleSource::GetRasterBand (this=0x55a27b70)
at /home/werdna/gdal/3.9.1/gdal-3.9.1/frmts/vrt/vrtsources.cpp:774
#13 0x761af01b in VRTSourcedRasterBand::SkipBufferInitialization 
(this=0x556a0ff0)
at 
/home/werdna/gdal/3.9.1/gdal-3.9.1/frmts/vrt/vrtsourcedrasterband.cpp:1941
#14 0x761a8b14 in VRTSourcedRasterBand::IRasterIO (this=0x556a0ff0, 
eRWFlag=GF_Read, nXOff=0, nYOff=0, nXSize=20,
nYSize=20, pData=0x556e62c0, nBufXSize=20, nBufYSize=20, 
eBufType=GDT_Int32, nPixelSpace=4, nLineSpace=80,
psExtraArg=0x7fffd230) at 
/home/werdna/gdal/3.9.1/gdal-3.9.1/frmts/vrt/vrtsourcedrasterband.cpp:318
#15 0x771f09f5 in GDALRasterBand::RasterIO (this=0x556a0ff0, 
eRWFlag=GF_Read, nXOff=0, nYOff=0, nXSize=20, nYSize=20,
pData=0x556e62c0, nBufXSize=20, nBufYSize=20, eBufType=GDT_Int32, 
nPixelSpace=4, nLineSpace=80, psExtraArg=0x7fffd230)
at /home/werdna/gdal/3.9.1/gdal-3.9.1/gcore/gdalrasterband.cpp:426
#16 0x771f0ae0 in GDALRasterIO (hBand=0x556a0ff0, eRWFlag=GF_Read, 
nXOff=0, nYOff=0, nXSize=20, nYSize=20,
pData=0x556e62c0, nBufXSize=20, nBufYSize=20, eBufType=GDT_Int32, 
nPixelSpace=0, nLineSpace=0)
at /home/werdna/gdal/3.9.1/gdal-3.9.1/gcore/gdalrasterband.cpp:459
#17 0x75e09311 in GDALChecksumImage (hBand=0x556a0ff0, nXOff=0, 
nYOff=0, nXSize=20, nYSize=20)
at /home/werdna/gdal/3.9.1/gdal-3.9.1/alg/gdalchecksum.cpp:297
#18 0x55565454 in (anonymous 
namespace)::testclosedondestroydm_test_Test::TestBody (this=0x555d44e0)
at 
/home/werdna/gdal/3.9.1/gdal-3.9.1/autotest/cpp/testclosedondestroydm.cpp:108
#19 0x5559df0f in void 
testing::internal::HandleExceptionsInMethodIfSupported(testing::Test*, void (testing::Test::*)(), char const*) ()
#20 0x555847c6 in testing::Test::Run() ()
#21 0x55584985 in testing::TestInfo::Run() ()
#22 0x55584b6f in testing::TestSuite::Run() ()
#23 0x555929dc in testing::internal::UnitTestImpl::RunAllTests() ()
#24 0x5559e5e7 in bool 
testing::inte

Re: [gdal-dev] testclosedondestroydm.test

[Andrew C Aitchison via gdal-dev]

On Tue, 25 Jun 2024, Even Rouault via gdal-dev wrote:


Le 25/06/2024 à 16:52, Andrew C Aitchison a écrit :

On Tue, 25 Jun 2024, Even Rouault wrote:



Le 25/06/2024 à 16:25, Andrew C Aitchison a écrit :

On Tue, 25 Jun 2024, Even Rouault via gdal-dev wrote:

Can you run "gdb autotest/cpp/testclosedondestroydm" , "run" , and when 
it crashed "bt" so we have a backtrace of where it crashes (all of that 
after running "source ../scripts/setdevenv.sh")


It doesn't crash:


Ah, the gtest framework must catch the exception. OK, so after starting 
gdb and before "run", type "catch throw", so that debugger stops when the 
exception is thrown, and then "bt"


Ok, those that occur in PROJ are expected and not fatal. Go on with "cont" 
(you may need to skip another one occurring in proj_crs_get_coordoperation())


This is the exception after proj_crs_get_coordoperation()
(I also scripted backtraces after every exception until the run completes;
at https://www.aitchison.me.uk/gdal/gdb.testclosedondestroydm ):

(gdb) cont
Continuing.

Catchpoint 1 (exception thrown), 0x74ebb0f1 in __cxa_throw () from 
/lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) bt
#0  0x74ebb0f1 in __cxa_throw () from 
/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x714b2c34 in ?? () from /lib/x86_64-linux-gnu/libproj.so.25
#2  0x715e357d in 
osgeo::proj::io::IPROJStringExportable::exportToPROJString[abi:cxx11](osgeo::proj::io::PROJStringFormatter*)
 const ()
   from /lib/x86_64-linux-gnu/libproj.so.25
#3  0x7165548c in ?? () from /lib/x86_64-linux-gnu/libproj.so.25
#4  0x71662633 in proj_create_conversion () from 
/lib/x86_64-linux-gnu/libproj.so.25
#5  0x75f6585a in OGRSpatialReference::SetProjCS (this=0x7fffb800, 
pszName=0x55cfc180 "NAD27 / UTM zone 11N")
at /home/werdna/gdal/3.9.1/gdal-3.9.1/ogr/ogrspatialreference.cpp:5548
#6  0x7615c359 in GTIFGetOGISDefnAsOSR (hGTIF=0x55b84150, 
psDefn=0x55a34720) at 
/home/werdna/gdal/3.9.1/gdal-3.9.1/frmts/gtiff/gt_wkt_srs.cpp:856
#7  0x760ffabe in GTiffDataset::LookForProjectionFromGeoTIFF 
(this=0x55cfb190) at 
/home/werdna/gdal/3.9.1/gdal-3.9.1/frmts/gtiff/gtiffdataset_read.cpp:4149
#8  0x760ff8b3 in GTiffDataset::LookForProjection (this=0x55cfb190) 
at /home/werdna/gdal/3.9.1/gdal-3.9.1/frmts/gtiff/gtiffdataset_read.cpp:4096
#9  0x761074e2 in GTiffDataset::GetSpatialRef (this=0x55cfb190) at 
/home/werdna/gdal/3.9.1/gdal-3.9.1/frmts/gtiff/gtiffdataset_read.cpp:6179
#10 0x771d98a0 in GDALDataset::GetProjectionRef (this=0x55cfb190) 
at /home/werdna/gdal/3.9.1/gdal-3.9.1/gcore/gdaldataset.cpp:1148
#11 0x764151f2 in TILDataset::Open (poOpenInfo=0x7fffd310) at 
/home/werdna/gdal/3.9.1/gdal-3.9.1/frmts/til/tildataset.cpp:326
#12 0x771c45c1 in GDALDriver::Open (this=0x556259b0, 
poOpenInfo=0x7fffd310, bSetOpenOptions=false) at 
/home/werdna/gdal/3.9.1/gdal-3.9.1/gcore/gdaldriver.cpp:116
#13 0x771ddf25 in GDALOpenEx (pszFilename=0x555a02d8 
"/home/werdna/gdal/3.9.1/gdal-3.9.1/autotest/gdrivers/data/til/testtil.til", 
nOpenFlags=66,
papszAllowedDrivers=0x0, papszOpenOptions=0x0, papszSiblingFiles=0x0) at 
/home/werdna/gdal/3.9.1/gdal-3.9.1/gcore/gdaldataset.cpp:3780
#14 0x771dd2a2 in GDALOpen (pszFilename=0x555a02d8 
"/home/werdna/gdal/3.9.1/gdal-3.9.1/autotest/gdrivers/data/til/testtil.til", 
eAccess=GA_ReadOnly)
at /home/werdna/gdal/3.9.1/gdal-3.9.1/gcore/gdaldataset.cpp:3441
#15 0x55565548 in (anonymous 
namespace)::testclosedondestroydm_test_Test::TestBody (this=0x555d44e0)
at 
/home/werdna/gdal/3.9.1/gdal-3.9.1/autotest/cpp/testclosedondestroydm.cpp:125
#16 0x5559df0f in void 
testing::internal::HandleExceptionsInMethodIfSupported(testing::Test*, void (testing::Test::*)(), char const*) ()
#17 0x555847c6 in testing::Test::Run() ()
#18 0x55584985 in testing::TestInfo::Run() ()
#19 0x55584b6f in testing::TestSuite::Run() ()
#20 0x555929dc in testing::internal::UnitTestImpl::RunAllTests() ()
#21 0x5559e5e7 in bool 
testing::internal::HandleExceptionsInMethodIfSupported(testing::internal::UnitTestImpl*, bool 
(testing::internal::UnitTestImpl::*)(), char const*) ()
#22 0x55584d68 in testing::UnitTest::Run() ()
#23 0x55566ea4 in RUN_ALL_TESTS () at /usr/include/gtest/gtest.h:2317
#24 0x55566dac in main (argc=1, argv=0x556017b0) at 
/home/werdna/gdal/3.9.1/gdal-3.9.1/autotest/cpp/main_gtest.cpp:55


--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] testclosedondestroydm.test

[Andrew C Aitchison via gdal-dev]

On Tue, 25 Jun 2024, Even Rouault via gdal-dev wrote:

ok, so the exception occurs in the embedded copy of tinyxml inside the ECW 
SDK ?


You likely need to apply those community patches to your libecwjp2 3.3 
sources: 
https://github.com/rouault/libecwj2-3.3-builds/blob/main/libecwj2-3.3.patch


Thanks. That worked.

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Is it possible to create standalone DLL for OGR GML driver ?

[Andrew C Aitchison via gdal-dev]

On Thu, 29 Aug 2024, Even Rouault via gdal-dev wrote:





I was wondering if there exists a way to get standalone OGR GML Driver. 
Please suggest.


No, it must be built-in in core libgdal as part of its functionality is 
re-used by other drivers (NAS, WFS) through direct function calls


Would disabling NAS and WFS support make a difference ?

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev