Re: [gdal-dev] Build 3.6.0 for iOS fails - _sqlite3_progress_handler error

Hi again, I have now resolved this issue by rebuilding SQLite with the SQLITE_OMIT_PROGRESS_CALLBACK=OFF GDAL 3.6.0 will now build successfully with my updated buiild of SQLite. Sorry to have troubled you with this one. NB: This may still be worth pursuing within GDAL, since SQLite explicitly

Re: [gdal-dev] GDAL 3.6.0 patch for building on iOS (and Mac Catalyst)

Hi Even, This patch worked fine to resolve the ‘pread64’ error on iOS and Mac Catalyst. Thank you. -Nik > On 12 Nov 2022, at 12:12 pm, Even Rouault wrote: > > Nik, > > actually I've just modified it to the following that still tries to detect > pread(). Can you test and report? > > diff --g

Re: [gdal-dev] Build 3.6.0 for iOS fails - _sqlite3_progress_handler error

Hi Even, Sorry, I should have mentioned that I’m not using the standard iOS/macOS SQLite (because it does not include RTREE extension which seems to be required for GDAL). I’m using a CMAKE compatible SQLite from: https://github.com/azadkuh/sqlite-amalgamation (which was working fine with GD

Re: [gdal-dev] Build 3.6.0 for iOS fails - _sqlite3_progress_handler error

Weird. So it would seem the SQLite3 build on iOS lacks sqlite3_progress_handler() As this is not critical for operations, I've added a CMake configure check for the presence of this function to conditionally enable it. Can you try https://github.com/OSGeo/gdal/pull/6675 ? Even Le 12/11/2022

[gdal-dev] Build 3.6.0 for iOS fails - _sqlite3_progress_handler error

After patching GDAL 3.6.0 for ‘pread64’ issue when building for iOS (see previous email), the build now progresses to the 100% mark, but then fails with the _sqlite3_progress_handler error below. I’m afraid that I don’t even know where to start with this one. How should I proceed? Cheers, Nik

[gdal-dev] GDAL 3.6.0 patch for building on iOS (and Mac Catalyst)

Hi GDAL devs It appears as though ‘pread64’, introduced in 3.6.0, has broken building on iOS in the same way that other ‘…64’ errors used to occur on version 3.5.0 before being patched for 3.5.2. The attached patch (text content also pasted below) allows the build to continue past that point f

Re: [gdal-dev] GDAL 3.6.0 patch for building on iOS (and Mac Catalyst)

Nik, actually I've just modified it to the following that still tries to detect pread(). Can you test and report? diff --git a/cmake/helpers/configure.cmake b/cmake/helpers/configure.cmake index f52ea47db3..0939ffadda 100644 --- a/cmake/helpers/configure.cmake +++ b/cmake/helpers/configure.cma

Re: [gdal-dev] GDAL 3.6.0 patch for building on iOS (and Mac Catalyst)

Le 12/11/2022 à 02:00, Nik Sands a écrit : Hi GDAL devs It appears as though ‘pread64’, introduced in 3.6.0, has broken building on iOS in the same way that other ‘…64’ errors used to occur on version 3.5.0 before being patched for 3.5.2. The attached patch (text content also pasted below) a

Re: [gdal-dev] Save min/max values in TIFF

Le 11/11/2022 à 19:12, Javier Jimenez Shaw a écrit : Hi I am creating a GeoTIFF file with C++. It is a large DSM (one band of Float32). Because I am generating it, I already know the min and max values. I would like to store the min and max values directly in the TIFF, not in a sidecar file.

[gdal-dev] Save min/max values in TIFF

Hi I am creating a GeoTIFF file with C++. It is a large DSM (one band of Float32). Because I am generating it, I already know the min and max values. I would like to store the min and max values directly in the TIFF, not in a sidecar file. Is there any gdal metadata (stored in the TIFF) that can b

Re: [gdal-dev] openfilegdb export

Thanks Even, -nlt POLYGON did indeed work for me. Huge thanks as always for your (and every contributor’s) amazing work. Andy From: Even Rouault Sent: 11 November 2022 14:07 To: Andrew Terry ; gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] openfilegdb export Andrew, Can you paste the outp

Re: [gdal-dev] openfilegdb export

Andrew, Can you paste the output of ogrinfo -al -so PG:"dbname=dbname port=5432 host=dbhost user=dbusr" --optfile sql_filter.sql so we can see the layer geometry type. I presume it is unknown. GeoPackage supports geometry columns with unknown geometry type. Shapefile requires a precise geom

[gdal-dev] openfilegdb export

Hi, Trying out the export to OpenFileGDB, using GDAL 3.7.0dev-5a6f99a78b installed with OSGeo4W ogr2ogr -f "OpenFileGDB" test_filegdb.gdb PG:"dbname=dbname port=5432 host=dbhost user=dbusr" --optfile sql_filter.sql This works for SHP and GeoPackage and the output is a EPSG 27700 Polygon geome

[gdal-dev] GDAL 3.6.0 is released

Hi, On behalf of the GDAL/OGR development team and community, I am pleased to announce the release of GDAL/OGR 3.6.0. GDAL/OGR is a C++ geospatial data access library for raster and vector file formats, databases and web services. It includes bindings for several languages, and a variety of com

Re: [gdal-dev] Motion: Adopt GDAL 3.6.0RC2 as final 3.6.0 release

Hi, I declare this motion passed with +1 from PSC members HowardB, JukkaR and me. Even Le 09/11/2022 à 10:31, Even Rouault a écrit : Hi, Motion: Adopt GDAL 3.6.0RC2 as final 3.6.0 release Starting with my +1 Even -- http://www.spatialys.com My software is free, but my time generally no

Re: [gdal-dev] Bug/feature: OGR VSICURL does not handle gzip compression

Hi, On 11/11/22 04:59, Thomas Gratier wrote: Use the CURL option available through GDAL e.g https://trac.osgeo.org/gdal/wiki/ConfigOptions#CPL_CURL_GZIP (also documented at https://gdal.org/user/configoptions.html