Likely unrelated: the above issue was specific to VRT pansharpening.

The warping kernel only supports one single working data type for all bands. The GDALWarpResolveWorkingDataType() function https://github.com/OSGeo/gdal/blob/c6f0ea7d8a4da08e0d633eb381677c23f3934be3/g

in-memory HDF4 or any /vsi virtual file system will not work with HDF4. The underlying library has no abstraction for I/O and uses plain C standard library API

Hi Sean regarding the change in web mercator, I guess this is due to a subtle change where we don't check anymore if latitude is close enough of PI/2 to decide the point doesn't project. Now we only t

Was left as an exercice for a contributor: https://github.com/OSGeo/gdal/pull/3181 Even

seem This had been discussed for PROJ in https://github.com/OSGeo/PROJ/issues/982 Summary: apparently technically doable, but for legal reasons for folks operating in China, cannot be included in PROJ

By default, the JP2OpenJPEG driver uses a lossy compression (my personal take on JPEG2000 is that it has very limited interested when used in its lossless profile. Better use more conventional algorit

If you have control on how the creation of the TIFF file, make sure it uses Band interleaving instead of Pixel interleaving For example, with gdal_translate can be done with -co INTERLEAVE=BAND If the

> ERROR 1: PROJ: proj_create_from_database: cannot build geodeticCRS 4326: > SQLite error on SELECT name, ellipsoid_auth_name, ellipsoid_code, > prime_meridian_auth_name, prime_meridian_code, area_of_

rio.read(): My understanding is that Transverse_Mercator_Complex corresponds to PROJ "etmerc" method, which is the default since PROJ 4.9.3 for UTM. PROJ just lacks a mapping for the Transverse_Mercat

You were responding to "userfaultfd support: yes" ? Hum, then I'm not sure. Are you running in a container ? Maybe there are some restrictions by default. Dunno. But you should see GDAL error messages

Can you check for the following too ? userfaultfd support: yes to check that you actually built against sufficiently recent kernel headers.

RTF(anstatic)M :-) https://gdal.org/drivers/raster/netcdf.html#vsi-virtual-file-system-api-support "Since GDAL 2.4, and with Linux kernel >=4.3 and libnetcdf >=4.5, read operations on /vsi file system

Indeed. You can play with the GTIFF specific PROFILE creation option (see https://gdal.org/drivers/raster/gtiff.html#creation-issues) PROFILE=BASELINE: .aux.xml only created if presence of georeferenc

Actually, this warning is GDAL specific, and has nothing to do with curl (but of course curl without SSL support is rather useless). The service account authentication method of Google OAuth2 requires

Sean, Your wheels use openjpeg for GDAL JPEG2000 capability, right ? There has been a change in GDAL ./configure in 2.3.0 related to openjpeg detection. It now requires pkg-config to be available to d