From howard at hobu.co Mon Dec 1 02:46:02 2025 From: howard at hobu.co (Howard Butler) Date: Mon, 1 Dec 2025 04:46:02 -0600 Subject: [gdal-dev] GDAL Maintainers Meeting Minutes Message-ID: <6DC73D08-F4D2-4B83-90DD-ED2D0EC7C570@hobu.co> Howard Butler, Dan Baston, Alessandro Pasotti, Michael Sumner, Even Rouault, and Javier Jimenez Shaw held the monthly GDAL Maintainers Meeting on 11/27/2025. The following items were discussed and reported upon: # Project News * [Planet](https://www.planet.com/) has renewed as a Gold sponsor for 2026. Thanks again Planet for your continued support of the GDAL Sponsorship Program! * The [2025 GDAL User Survey](https://gdal.org/survey/) is now active for the entire month of December! Visit https://gdal.org/survey/ and tell the project how you use it, where you get help, what it should do in the future, and how/if it should use LLMs going forward. If you (optionally) give us your email, we'll even enter you to win a GDAL t-shirt! * Support GDAL with a new t-shirt! Visit https://gdal.org/tshirt/ to purchase. Change your country preference on the bottom of the page. Profits from swag sales go directly to the GDAL Sponsorship Program via NumFOCUS! * RHEL 10.1 now includes GDAL packages with a limited set of drivers # Maintenance activities update ## Alessandro * PR review activity * `gdal raster resize` ? support for ratio-preservation by setting height or width as `0` https://github.com/OSGeo/gdal/pull/13442 ## Dan * PR reviews * Attended FOSS4GNA 2025 and recorded the Status of GDAL which is expected to be online soon * added `gdal vector sort` https://github.com/OSGeo/gdal/pull/13351 with hillbert or strtree * added grid subdivision algorithm to GEOS https://github.com/libgeos/geos/pull/1232 ## Even * GDAL 3.12.0 "Chicoutimi" release https://github.com/OSGeo/gdal/releases/tag/v3.12.0 * GDAL 3.11.5 release https://github.com/OSGeo/gdal/releases/tag/v3.11.5 * 80+ PRs and tickets * 5 EPSG updates ? fallout and churn from ETR89 activities in EU * geometry field support for gdal vector partition https://github.com/OSGeo/gdal/pull/13388 * South-up support for GTI driver * `gdal vector update` ? port of the ogrupdate.py script to new CLI https://github.com/OSGeo/gdal/pull/13412 * STAC GeoParquet profile for GDAL gdal raster tileindex output https://github.com/OSGeo/gdal/pull/13431 * LLVM-based JIT for raster expressions (RFC 110) https://gdal--13466.org.readthedocs.build/en/13466/development/rfc/rfc110_jit_compilation.html ## Javier * Working to support `projinfo` as a library function with a callback for WASM and browser execution. # Next Meeting The next GDAL Maintainers Meeting is canceled due to it occurring on Christmas Day. Maintainers will provide text bullet status updates for the month of December and they will be collated into minutes. The January GDAL Maintainers Meeting is 01/22/2026 at 13:00 UTC. Project contributors should contact Howard Butler for an invite. # Online Version https://gist.github.com/hobu/9081a65d7723d5541e40238fe7d5b2c4 # Financial Support * Buy a t-shirt https://gdal.org/tshirt/ * Make an individual or corporate donation online https://numfocus.org/donate-to-gdal * Organize a contribution to the GDAL Sponsorship Program https://gdal.org/en/latest/sponsors/index.html#sponsorship-program From even.rouault at spatialys.com Wed Dec 3 07:15:06 2025 From: even.rouault at spatialys.com (Even Rouault) Date: Wed, 3 Dec 2025 16:15:06 +0100 Subject: [gdal-dev] Call for review: RFC-110 Just-In-Time (JIT) compilation of expressions In-Reply-To: <809190cb-688a-49ab-92b3-ccdd2c6a6874@spatialys.com> References: <809190cb-688a-49ab-92b3-ccdd2c6a6874@spatialys.com> Message-ID: <87dad94e-f3dc-4cde-b256-9734e02ac578@spatialys.com> Hi, Any extra comments than those already submitted in the pull request ? Even Le 25/11/2025 ? 13:57, Even Rouault via gdal-dev a ?crit?: > Hi, > > I've submitted https://github.com/OSGeo/gdal/pull/13466 which > introduces the optional use of the CLang and LLVM embedded libraries > to provide Just-In-Time (JIT) / on-the-fly compilation of code, and > its use to speed-up evaluation of MuParser-compatible expressions, as > used in VRTDerivedBand and gdal raster calc. > > Even > -- http://www.spatialys.com My software is free, but my time generally not. From hugh.a.graham at gmail.com Wed Dec 3 11:57:57 2025 From: hugh.a.graham at gmail.com (Hugh Graham) Date: Wed, 3 Dec 2025 19:57:57 +0000 Subject: [gdal-dev] Using bitwise & with muparser VRT expressions Message-ID: Hi, I am using VRT muparser expressions for bitwise operations when creating masks and wanted to understand why I can't get the *bitwise & *operator working? My current solution is to use fmod which is fine (and I think equivalent) but using "&" would be convenient and a bit easier to read... To illustrate, the following file works: https://gist.github.com/h-a-graham/6db16e70e064ae8173f1052537c59761#file-fmask-fmodmask-vrt the expression used here is:"(fmod(Fmask, 16) >= 8) || (fmod(Fmask, 8) >= 4) ? 0 : 1" ``` gdal convert "/vsicurl/ https://gist.githubusercontent.com/h-a-graham/6db16e70e064ae8173f1052537c59761/raw/c48b15852bcc7c5252cae4b906c14b9a3205a33d/fmask-fmodmask.vrt" "test.tif" ``` However, the following file fails: https://gist.github.com/h-a-graham/6db16e70e064ae8173f1052537c59761#file-fmask-bitmask-vrt the expression parsed as: "((Fmask & 8) > 0 || (Fmask & 4) > 0) ? 0 : 1" in the XML but provided as (to my xml parser): "((Fmask & 8) > 0 || (Fmask & 4) > 0) ? 0 : 1" ``` gdal convert "/vsicurl/ https://gist.githubusercontent.com/h-a-graham/6db16e70e064ae8173f1052537c59761/raw/c48b15852bcc7c5252cae4b906c14b9a3205a33d/fmask-bitmask.vrt" "test.tif" 0...10...20..ERROR 1: Unexpected token "& 8) > 0 || (Fmask & 4) > 0) ? 0 : 1 " found at position 8. ``` So, is using "&" possible, or should I just stick with fmod and not worry about it? Any help would be much appreciated. Hugh -------------- next part -------------- An HTML attachment was scrubbed... URL: From public at postholer.com Wed Dec 3 12:01:30 2025 From: public at postholer.com (Scott) Date: Wed, 3 Dec 2025 12:01:30 -0800 Subject: [gdal-dev] Help with STACIT Message-ID: <8ce96ae0-3d11-464a-a01c-1c7d2c4d14a5@postholer.com> Greetings, I need some help with STACIT syntax. This does not work: gdal raster info "STACIT:\"/vsicurl/https://cmr.earthdata.nasa.gov/stac/LPCLOUD/search?collections=VIP01_004&bbox=-180,-90,180,90\"" ...it returns: ERROR 1: JSON parsing error: continue (at offset 0) Usage: gdal raster info [OPTIONS] Try 'gdal raster info --help' for help. If I open the link in a browser or use wget, I get the expected geojson output: wget 'https://cmr.earthdata.nasa.gov/stac/LPCLOUD/search?collections=VIP01_004&bbox=-180,-90,180,90' -O tst.geojson Debian 12, GDAL 3.12.0 Thanks! Scott -- www.postholer.com From dbaston at gmail.com Wed Dec 3 12:07:42 2025 From: dbaston at gmail.com (Daniel Baston) Date: Wed, 3 Dec 2025 15:07:42 -0500 Subject: [gdal-dev] Using bitwise & with muparser VRT expressions In-Reply-To: References: Message-ID: Hugh, My read of this discussion [1] is that bitwise operators are not supported and we would need to add them as a GDAL extension. This is pretty easy to do: see [2]. Alternatively, bitwise operators are probably supported by the ExprTk expression parser [3] (supported by GDAL) or this pull request [4]. Dan [1] https://github.com/beltoforion/muparser/discussions/154#discussioncomment-13104418 [2] https://github.com/OSGeo/gdal/pull/13187/files [3] https://www.partow.net/programming/exprtk/ [4] https://github.com/OSGeo/gdal/pull/13470 On Wed, Dec 3, 2025 at 2:58?PM Hugh Graham via gdal-dev < gdal-dev at lists.osgeo.org> wrote: > Hi, > > I am using VRT muparser expressions for bitwise operations when creating > masks and wanted to understand why I can't get the *bitwise & *operator > working? My current solution is to use fmod which is fine (and I think > equivalent) but using "&" would be convenient and a bit easier to read... > > To illustrate, the following file works: > > https://gist.github.com/h-a-graham/6db16e70e064ae8173f1052537c59761#file-fmask-fmodmask-vrt > > the expression used here is:"(fmod(Fmask, 16) >= 8) || (fmod(Fmask, 8) >= > 4) ? 0 : 1" > > ``` > gdal convert "/vsicurl/ > https://gist.githubusercontent.com/h-a-graham/6db16e70e064ae8173f1052537c59761/raw/c48b15852bcc7c5252cae4b906c14b9a3205a33d/fmask-fmodmask.vrt" > "test.tif" > ``` > > However, the following file fails: > > https://gist.github.com/h-a-graham/6db16e70e064ae8173f1052537c59761#file-fmask-bitmask-vrt > the expression parsed as: "((Fmask & 8) > 0 || (Fmask & 4) > > 0) ? 0 : 1" in the XML but provided as (to my xml parser): > > "((Fmask & 8) > 0 || (Fmask & 4) > 0) ? 0 : 1" > > ``` > gdal convert "/vsicurl/ > https://gist.githubusercontent.com/h-a-graham/6db16e70e064ae8173f1052537c59761/raw/c48b15852bcc7c5252cae4b906c14b9a3205a33d/fmask-bitmask.vrt" > "test.tif" > 0...10...20..ERROR 1: Unexpected token "& 8) > 0 || (Fmask & 4) > 0) ? 0 : > 1 " found at position 8. > ``` > > So, is using "&" possible, or should I just stick with fmod and not worry > about it? > > Any help would be much appreciated. > > Hugh > > > > > > > _______________________________________________ > gdal-dev mailing list > gdal-dev at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Wed Dec 3 12:14:18 2025 From: even.rouault at spatialys.com (Even Rouault) Date: Wed, 3 Dec 2025 21:14:18 +0100 Subject: [gdal-dev] Using bitwise & with muparser VRT expressions In-Reply-To: References: Message-ID: I see there's a mu::ParserInt class in https://github.com/beltoforion/muparser/blob/master/include/muParserInt.h , that we don't use in GDAL. A bit strange it wasn't mentionned in [1]. Perhaps because of this comment: "This version of the parser handles only integer numbers. It disables the built in operators thus it is?slower than muParser. Integer values are stored in the double value_type and converted if needed." Le 03/12/2025 ? 21:07, Daniel Baston via gdal-dev a ?crit?: > Hugh, > > My read of this discussion [1] is that bitwise operators are not > supported and we would need to add them as a GDAL extension. This is > pretty easy to do: see [2]. Alternatively, bitwise operators are > probably supported by the ExprTk expression parser [3] (supported by > GDAL) or this pull request [4]. > > Dan > > [1] > https://github.com/beltoforion/muparser/discussions/154#discussioncomment-13104418 > [2] https://github.com/OSGeo/gdal/pull/13187/files > [3] https://www.partow.net/programming/exprtk/ > [4] https://github.com/OSGeo/gdal/pull/13470 > > On Wed, Dec 3, 2025 at 2:58?PM Hugh Graham via gdal-dev > wrote: > > Hi, > > I am using VRT muparser expressions for bitwise operations when > creating masks and wanted to understand why I can't get the > /bitwise & /operator working? My current solution is to use fmod > which is fine (and I think equivalent) but using "&" would be > convenient and a bit easier to read... > > To illustrate, the following file works: > https://gist.github.com/h-a-graham/6db16e70e064ae8173f1052537c59761#file-fmask-fmodmask-vrt > > the expression used here is:"(fmod(Fmask, 16) >= 8) || > (fmod(Fmask, 8) >= 4) ? 0 : 1" > > ``` > gdal convert > "/vsicurl/https://gist.githubusercontent.com/h-a-graham/6db16e70e064ae8173f1052537c59761/raw/c48b15852bcc7c5252cae4b906c14b9a3205a33d/fmask-fmodmask.vrt" > "test.tif" > ``` > > However, the following file fails: > https://gist.github.com/h-a-graham/6db16e70e064ae8173f1052537c59761#file-fmask-bitmask-vrt > the expression parsed as:?"((Fmask & 8) > 0 || (Fmask & > 4) > 0) ? 0 : 1" in the XML but provided as (to my xml parser): > > "((Fmask & 8) > 0 || (Fmask & 4) > 0) ? 0 : 1" > > ``` > gdal convert > "/vsicurl/https://gist.githubusercontent.com/h-a-graham/6db16e70e064ae8173f1052537c59761/raw/c48b15852bcc7c5252cae4b906c14b9a3205a33d/fmask-bitmask.vrt" > "test.tif" > 0...10...20..ERROR 1: Unexpected token "& 8) > 0 || (Fmask & 4) > > 0) ? 0 : 1 " found at position 8. > ``` > > So, is using "&" possible, or should I just stick with fmod and > not worry about it? > > Any help would be much appreciated. > > Hugh > > > > > > > _______________________________________________ > gdal-dev mailing list > gdal-dev at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > > > _______________________________________________ > gdal-dev mailing list > gdal-dev at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev -- http://www.spatialys.com My software is free, but my time generally not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lnicola at dend.ro Wed Dec 3 12:19:29 2025 From: lnicola at dend.ro (=?UTF-8?Q?Lauren=C8=9Biu_Nicola?=) Date: Wed, 03 Dec 2025 22:19:29 +0200 Subject: [gdal-dev] Help with STACIT In-Reply-To: <8ce96ae0-3d11-464a-a01c-1c7d2c4d14a5@postholer.com> References: <8ce96ae0-3d11-464a-a01c-1c7d2c4d14a5@postholer.com> Message-ID: Hi Scott, It's a little strange: $ CPL_DEBUG=ON CURL_CPL_VERBOSE=YES gdal raster info --if STACIT "https://cmr.earthdata.nasa.gov/stac/LPCLOUD/search?collections=VIP01_004&bbox=-180,-90,180,90" HTTP: Fetch(https://cmr.earthdata.nasa.gov/stac/LPCLOUD/search?collections=VIP01_004&bbox=-180,-90,180,90) HTTP: libcurl/8.15.0 OpenSSL/3.5.4 zlib/1.3.1.zlib-ng libidn2/2.3.8 nghttp2/1.66.0 HTTP: These POSTFIELDS were sent:{} ERROR 1: HTTP error code : 403 This doesn't log as much as I expected, but it sounds like it's doing a POST, given https://github.com/OSGeo/gdal/blob/master/port/cpl_http.cpp#L2565-L2571. However, if I connect to a dummy server, I see: GET /stac/LPCLOUD/search?collections=VIP01_004&bbox=-180,-90,180,90 HTTP/1.1 Host: 127.0.0.1:7777 User-Agent: GDAL/3.11.5 Accept: */* Accept-Encoding: gzip Content-Type: application/json Content-Length: 2 {} That's a GET request with a body, which isn't really supported. You can reproduce this with cURL: $ curl -X GET --json '{}' "https://cmr.earthdata.nasa.gov/stac/LPCLOUD/search?collections=VIP01_004&bbox=-180,-90,180,90" [snipped CloudFront 403 error] Laurentiu On Wed, Dec 3, 2025, at 22:01, Scott via gdal-dev wrote: > Greetings, > > I need some help with STACIT syntax. This does not work: > > gdal raster info > "STACIT:\"/vsicurl/https://cmr.earthdata.nasa.gov/stac/LPCLOUD/search?collections=VIP01_004&bbox=-180,-90,180,90\"" > > ...it returns: > > ERROR 1: JSON parsing error: continue (at offset 0) > Usage: gdal raster info [OPTIONS] > Try 'gdal raster info --help' for help. > > If I open the link in a browser or use wget, I get the expected geojson > output: > > wget > 'https://cmr.earthdata.nasa.gov/stac/LPCLOUD/search?collections=VIP01_004&bbox=-180,-90,180,90' > -O tst.geojson > > Debian 12, GDAL 3.12.0 > > Thanks! > Scott > > -- > www.postholer.com > > _______________________________________________ > gdal-dev mailing list > gdal-dev at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev From even.rouault at spatialys.com Wed Dec 3 12:34:24 2025 From: even.rouault at spatialys.com (Even Rouault) Date: Wed, 3 Dec 2025 21:34:24 +0100 Subject: [gdal-dev] Help with STACIT In-Reply-To: References: <8ce96ae0-3d11-464a-a01c-1c7d2c4d14a5@postholer.com> Message-ID: <98c6f126-2259-48b9-a7ce-17f259be9ff5@spatialys.com> Hi, I concur with?Lauren?iu's analysis. I've just pushed a fix in https://github.com/OSGeo/gdal/commit/b4565edc5931d1111228fbbdada739e18ebd2bf6 . With that retrieving items work as well as pagination ... but that collection doesn't implement the Projection Extension Specification (https://github.com/stac-extensions/projection/) so ultimately the driver errors out. And you shouldn't use /vsicurl/ prefixing for STAC API servers, since they aren't serving static content but reply to requests, and so can't work with HTTP range requests Even Le 03/12/2025 ? 21:19, Lauren?iu Nicola via gdal-dev a ?crit?: > Hi Scott, > > It's a little strange: > > $ CPL_DEBUG=ON CURL_CPL_VERBOSE=YES gdal raster info --if STACIT "https://cmr.earthdata.nasa.gov/stac/LPCLOUD/search?collections=VIP01_004&bbox=-180,-90,180,90" > > HTTP: Fetch(https://cmr.earthdata.nasa.gov/stac/LPCLOUD/search?collections=VIP01_004&bbox=-180,-90,180,90) > HTTP: libcurl/8.15.0 OpenSSL/3.5.4 zlib/1.3.1.zlib-ng libidn2/2.3.8 nghttp2/1.66.0 > HTTP: These POSTFIELDS were sent:{} > ERROR 1: HTTP error code : 403 > > This doesn't log as much as I expected, but it sounds like it's doing a POST, given https://github.com/OSGeo/gdal/blob/master/port/cpl_http.cpp#L2565-L2571. However, if I connect to a dummy server, I see: > > GET /stac/LPCLOUD/search?collections=VIP01_004&bbox=-180,-90,180,90 HTTP/1.1 > Host: 127.0.0.1:7777 > User-Agent: GDAL/3.11.5 > Accept: */* > Accept-Encoding: gzip > Content-Type: application/json > Content-Length: 2 > > {} > > That's a GET request with a body, which isn't really supported. You can reproduce this with cURL: > > $ curl -X GET --json '{}' "https://cmr.earthdata.nasa.gov/stac/LPCLOUD/search?collections=VIP01_004&bbox=-180,-90,180,90" > > [snipped CloudFront 403 error] > > Laurentiu > > On Wed, Dec 3, 2025, at 22:01, Scott via gdal-dev wrote: >> Greetings, >> >> I need some help with STACIT syntax. This does not work: >> >> gdal raster info >> "STACIT:\"/vsicurl/https://cmr.earthdata.nasa.gov/stac/LPCLOUD/search?collections=VIP01_004&bbox=-180,-90,180,90\"" >> >> ...it returns: >> >> ERROR 1: JSON parsing error: continue (at offset 0) >> Usage: gdal raster info [OPTIONS] >> Try 'gdal raster info --help' for help. >> >> If I open the link in a browser or use wget, I get the expected geojson >> output: >> >> wget >> 'https://cmr.earthdata.nasa.gov/stac/LPCLOUD/search?collections=VIP01_004&bbox=-180,-90,180,90' >> -O tst.geojson >> >> Debian 12, GDAL 3.12.0 >> >> Thanks! >> Scott >> >> -- >> www.postholer.com >> >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev at lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/gdal-dev > _______________________________________________ > gdal-dev mailing list > gdal-dev at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev -- http://www.spatialys.com My software is free, but my time generally not. From public at postholer.com Wed Dec 3 12:46:16 2025 From: public at postholer.com (Scott) Date: Wed, 3 Dec 2025 12:46:16 -0800 Subject: [gdal-dev] Help with STACIT In-Reply-To: <98c6f126-2259-48b9-a7ce-17f259be9ff5@spatialys.com> References: <8ce96ae0-3d11-464a-a01c-1c7d2c4d14a5@postholer.com> <98c6f126-2259-48b9-a7ce-17f259be9ff5@spatialys.com> Message-ID: <502c1492-0433-4898-8e59-4294ba370d11@postholer.com> All noted! Thanks guys for looking into that. Scott On 12/3/25 12:34, Even Rouault via gdal-dev wrote: > Hi, > > I concur with?Lauren?iu's analysis. I've just pushed a fix in https:// > github.com/OSGeo/gdal/commit/b4565edc5931d1111228fbbdada739e18ebd2bf6 . > With that retrieving items work as well as pagination ... but that > collection doesn't implement the Projection Extension Specification > (https://github.com/stac-extensions/projection/) so ultimately the > driver errors out. > > And you shouldn't use /vsicurl/ prefixing for STAC API servers, since > they aren't serving static content but reply to requests, and so can't > work with HTTP range requests > > Even > > Le 03/12/2025 ? 21:19, Lauren?iu Nicola via gdal-dev a ?crit?: >> Hi Scott, >> >> It's a little strange: >> >> $ CPL_DEBUG=ON CURL_CPL_VERBOSE=YES gdal raster info --if STACIT >> "https://cmr.earthdata.nasa.gov/stac/LPCLOUD/search? >> collections=VIP01_004&bbox=-180,-90,180,90" >> >> HTTP: Fetch(https://cmr.earthdata.nasa.gov/stac/LPCLOUD/search? >> collections=VIP01_004&bbox=-180,-90,180,90) >> HTTP: libcurl/8.15.0 OpenSSL/3.5.4 zlib/1.3.1.zlib-ng libidn2/2.3.8 >> nghttp2/1.66.0 >> HTTP: These POSTFIELDS were sent:{} >> ERROR 1: HTTP error code : 403 >> >> This doesn't log as much as I expected, but it sounds like it's doing >> a POST, given https://github.com/OSGeo/gdal/blob/master/port/ >> cpl_http.cpp#L2565-L2571. However, if I connect to a dummy server, I see: >> >> GET /stac/LPCLOUD/search?collections=VIP01_004&bbox=-180,-90,180,90 >> HTTP/1.1 >> Host: 127.0.0.1:7777 >> User-Agent: GDAL/3.11.5 >> Accept: */* >> Accept-Encoding: gzip >> Content-Type: application/json >> Content-Length: 2 >> >> {} >> >> That's a GET request with a body, which isn't really supported. You >> can reproduce this with cURL: >> >> $ curl -X GET --json '{}' "https://cmr.earthdata.nasa.gov/stac/ >> LPCLOUD/search?collections=VIP01_004&bbox=-180,-90,180,90" >> >> [snipped CloudFront 403 error] >> >> Laurentiu >> >> On Wed, Dec 3, 2025, at 22:01, Scott via gdal-dev wrote: >>> Greetings, >>> >>> I need some help with STACIT syntax. This does not work: >>> >>> gdal raster info >>> "STACIT:\"/vsicurl/https://cmr.earthdata.nasa.gov/stac/LPCLOUD/ >>> search?collections=VIP01_004&bbox=-180,-90,180,90\"" >>> >>> ...it returns: >>> >>> ERROR 1: JSON parsing error: continue (at offset 0) >>> Usage: gdal raster info [OPTIONS] >>> Try 'gdal raster info --help' for help. >>> >>> If I open the link in a browser or use wget, I get the expected geojson >>> output: >>> >>> wget >>> 'https://cmr.earthdata.nasa.gov/stac/LPCLOUD/search? >>> collections=VIP01_004&bbox=-180,-90,180,90' >>> -O tst.geojson >>> >>> Debian 12, GDAL 3.12.0 >>> >>> Thanks! >>> Scott >>> >>> -- >>> www.postholer.com >>> >>> _______________________________________________ >>> gdal-dev mailing list >>> gdal-dev at lists.osgeo.org >>> https://lists.osgeo.org/mailman/listinfo/gdal-dev >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev at lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/gdal-dev > From jan.heckman at gmail.com Thu Dec 4 04:35:15 2025 From: jan.heckman at gmail.com (Jan Heckman) Date: Thu, 4 Dec 2025 13:35:15 +0100 Subject: [gdal-dev] Unwanted geometry dump in ogrinfo sql Message-ID: Dear list, The following command also outputs geometry: *ogrinfo -sql "select bu_code from buurt_minimaal limit 1" buurt_minimaal.dbf* Obviously, there is a buurt_minimaal.shp as well, see this link . The gdal version used is a bit old: GDAL 3.5.3. - should I do different to avoid geo dumps? - (if not,) will updating gdal help me avoid this behavior? Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Thu Dec 4 04:40:44 2025 From: even.rouault at spatialys.com (Even Rouault) Date: Thu, 4 Dec 2025 13:40:44 +0100 Subject: [gdal-dev] Unwanted geometry dump in ogrinfo sql In-Reply-To: References: Message-ID: Hi, Le 04/12/2025 ? 13:35, Jan Heckman via gdal-dev a ?crit?: > Dear list, > The following command also outputs geometry: > /ogrinfo -sql "select bu_code from buurt_minimaal limit 1" > buurt_minimaal.dbf/ > Obviously, there is a buurt_minimaal.shp as well, see this link > . > The gdal version used is a bit old: GDAL 3.5.3. > - should I do different to avoid geo dumps? Either delete the .shp :-)? (more seriously, opening explicitly the .dbf or the .shp results in the same behavior in the shapefile driver. both are used when present),? or add "-dialect SQLite" since the SQLite dialect doesn't implicitly? select geometries, contrary to the default OGRSQL dialect > - (if not,) will updating gdal help me avoid this behavior? No, the working of the OGRSQL dialect is unchanged -- http://www.spatialys.com My software is free, but my time generally not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From j1 at jimenezshaw.com Thu Dec 4 05:53:01 2025 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Thu, 4 Dec 2025 14:53:01 +0100 Subject: [gdal-dev] Using bitwise & with muparser VRT expressions In-Reply-To: References: Message-ID: If I remember correctly, the arithmetic is done with floating 64b numbers, right? Doing bitwise operations there sound a bit (pun intended) strange. I know a bit portion of images used are RGB (byte images), there bitwise operatios are fine. On Wed, 3 Dec 2025 at 21:14, Even Rouault via gdal-dev < gdal-dev at lists.osgeo.org> wrote: > I see there's a mu::ParserInt class in > https://github.com/beltoforion/muparser/blob/master/include/muParserInt.h > , that we don't use in GDAL. A bit strange it wasn't mentionned in [1]. > Perhaps because of this comment: "This version of the parser handles only > integer numbers. It disables the built in operators thus it is slower than > muParser. Integer values are stored in the double value_type and converted > if needed." > Le 03/12/2025 ? 21:07, Daniel Baston via gdal-dev a ?crit : > > Hugh, > > My read of this discussion [1] is that bitwise operators are not supported > and we would need to add them as a GDAL extension. This is pretty easy to > do: see [2]. Alternatively, bitwise operators are probably supported by the > ExprTk expression parser [3] (supported by GDAL) or this pull request [4]. > > Dan > > [1] > https://github.com/beltoforion/muparser/discussions/154#discussioncomment-13104418 > [2] https://github.com/OSGeo/gdal/pull/13187/files > [3] https://www.partow.net/programming/exprtk/ > [4] https://github.com/OSGeo/gdal/pull/13470 > > On Wed, Dec 3, 2025 at 2:58?PM Hugh Graham via gdal-dev < > gdal-dev at lists.osgeo.org> wrote: > >> Hi, >> >> I am using VRT muparser expressions for bitwise operations when creating >> masks and wanted to understand why I can't get the *bitwise & *operator >> working? My current solution is to use fmod which is fine (and I think >> equivalent) but using "&" would be convenient and a bit easier to read... >> >> To illustrate, the following file works: >> >> https://gist.github.com/h-a-graham/6db16e70e064ae8173f1052537c59761#file-fmask-fmodmask-vrt >> >> the expression used here is:"(fmod(Fmask, 16) >= 8) || (fmod(Fmask, 8) >= >> 4) ? 0 : 1" >> >> ``` >> gdal convert "/vsicurl/ >> https://gist.githubusercontent.com/h-a-graham/6db16e70e064ae8173f1052537c59761/raw/c48b15852bcc7c5252cae4b906c14b9a3205a33d/fmask-fmodmask.vrt" >> "test.tif" >> ``` >> >> However, the following file fails: >> >> https://gist.github.com/h-a-graham/6db16e70e064ae8173f1052537c59761#file-fmask-bitmask-vrt >> the expression parsed as: "((Fmask & 8) > 0 || (Fmask & 4) >> > 0) ? 0 : 1" in the XML but provided as (to my xml parser): >> >> "((Fmask & 8) > 0 || (Fmask & 4) > 0) ? 0 : 1" >> >> ``` >> gdal convert "/vsicurl/ >> https://gist.githubusercontent.com/h-a-graham/6db16e70e064ae8173f1052537c59761/raw/c48b15852bcc7c5252cae4b906c14b9a3205a33d/fmask-bitmask.vrt" >> "test.tif" >> 0...10...20..ERROR 1: Unexpected token "& 8) > 0 || (Fmask & 4) > 0) ? 0 >> : 1 " found at position 8. >> ``` >> >> So, is using "&" possible, or should I just stick with fmod and not worry >> about it? >> >> Any help would be much appreciated. >> >> Hugh >> >> >> >> >> >> >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev at lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/gdal-dev >> > > _______________________________________________ > gdal-dev mailing listgdal-dev at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev > > -- http://www.spatialys.com > My software is free, but my time generally not. > > _______________________________________________ > gdal-dev mailing list > gdal-dev at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hugh.a.graham at gmail.com Thu Dec 4 07:45:20 2025 From: hugh.a.graham at gmail.com (Hugh Graham) Date: Thu, 4 Dec 2025 15:45:20 +0000 Subject: [gdal-dev] Using bitwise & with muparser VRT expressions In-Reply-To: References: Message-ID: Many thanks to all - this is very helpful. Dan, I'll explore some of these other options you mention. In this new PR, is it the case that by switching to using theLLVM dialect these operators will automatically be recognised? I suppose if this is the case then explicitly adding the operator might not strictly be necessary... Also, I appreciate the clarification that values are always converted to float during the arithmetic, I agree, Javier, that in this case a bitwise operation is a bit strange... I suspect it will however be quite a valuable application of such expressions, given the popularity of bit masks in various imagery collections. I'll keep experimenting but again really appreciate the help and looking forward to testing out new related features. Hugh On Thu, 4 Dec 2025 at 13:53, Javier Jimenez Shaw wrote: > If I remember correctly, the arithmetic is done with floating 64b numbers, > right? Doing bitwise operations there sound a bit (pun intended) strange. > I know a bit portion of images used are RGB (byte images), there bitwise > operatios are fine. > > On Wed, 3 Dec 2025 at 21:14, Even Rouault via gdal-dev < > gdal-dev at lists.osgeo.org> wrote: > >> I see there's a mu::ParserInt class in >> https://github.com/beltoforion/muparser/blob/master/include/muParserInt.h >> , that we don't use in GDAL. A bit strange it wasn't mentionned in [1]. >> Perhaps because of this comment: "This version of the parser handles only >> integer numbers. It disables the built in operators thus it is slower than >> muParser. Integer values are stored in the double value_type and converted >> if needed." >> Le 03/12/2025 ? 21:07, Daniel Baston via gdal-dev a ?crit : >> >> Hugh, >> >> My read of this discussion [1] is that bitwise operators are not >> supported and we would need to add them as a GDAL extension. This is pretty >> easy to do: see [2]. Alternatively, bitwise operators are probably >> supported by the ExprTk expression parser [3] (supported by GDAL) or this >> pull request [4]. >> >> Dan >> >> [1] >> https://github.com/beltoforion/muparser/discussions/154#discussioncomment-13104418 >> [2] https://github.com/OSGeo/gdal/pull/13187/files >> [3] https://www.partow.net/programming/exprtk/ >> [4] https://github.com/OSGeo/gdal/pull/13470 >> >> On Wed, Dec 3, 2025 at 2:58?PM Hugh Graham via gdal-dev < >> gdal-dev at lists.osgeo.org> wrote: >> >>> Hi, >>> >>> I am using VRT muparser expressions for bitwise operations when creating >>> masks and wanted to understand why I can't get the *bitwise & *operator >>> working? My current solution is to use fmod which is fine (and I think >>> equivalent) but using "&" would be convenient and a bit easier to read... >>> >>> To illustrate, the following file works: >>> >>> https://gist.github.com/h-a-graham/6db16e70e064ae8173f1052537c59761#file-fmask-fmodmask-vrt >>> >>> the expression used here is:"(fmod(Fmask, 16) >= 8) || (fmod(Fmask, 8) >>> >= 4) ? 0 : 1" >>> >>> ``` >>> gdal convert "/vsicurl/ >>> https://gist.githubusercontent.com/h-a-graham/6db16e70e064ae8173f1052537c59761/raw/c48b15852bcc7c5252cae4b906c14b9a3205a33d/fmask-fmodmask.vrt" >>> "test.tif" >>> ``` >>> >>> However, the following file fails: >>> >>> https://gist.github.com/h-a-graham/6db16e70e064ae8173f1052537c59761#file-fmask-bitmask-vrt >>> the expression parsed as: "((Fmask & 8) > 0 || (Fmask & 4) >>> > 0) ? 0 : 1" in the XML but provided as (to my xml parser): >>> >>> "((Fmask & 8) > 0 || (Fmask & 4) > 0) ? 0 : 1" >>> >>> ``` >>> gdal convert "/vsicurl/ >>> https://gist.githubusercontent.com/h-a-graham/6db16e70e064ae8173f1052537c59761/raw/c48b15852bcc7c5252cae4b906c14b9a3205a33d/fmask-bitmask.vrt" >>> "test.tif" >>> 0...10...20..ERROR 1: Unexpected token "& 8) > 0 || (Fmask & 4) > 0) ? 0 >>> : 1 " found at position 8. >>> ``` >>> >>> So, is using "&" possible, or should I just stick with fmod and not >>> worry about it? >>> >>> Any help would be much appreciated. >>> >>> Hugh >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> gdal-dev mailing list >>> gdal-dev at lists.osgeo.org >>> https://lists.osgeo.org/mailman/listinfo/gdal-dev >>> >> >> _______________________________________________ >> gdal-dev mailing listgdal-dev at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev >> >> -- http://www.spatialys.com >> My software is free, but my time generally not. >> >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev at lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/gdal-dev >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Thu Dec 4 07:49:56 2025 From: even.rouault at spatialys.com (Even Rouault) Date: Thu, 4 Dec 2025 16:49:56 +0100 Subject: [gdal-dev] Using bitwise & with muparser VRT expressions In-Reply-To: References: Message-ID: <60de461f-d6e0-41d5-8da6-c4d40c344aaf@spatialys.com> Le 04/12/2025 ? 16:45, Hugh Graham a ?crit?: > Many thanks to all - this is very?helpful. > > Dan, I'll explore some of these other options you mention. In this new > PR, is it the case that by switching to using theLLVM dialect these > operators will automatically be recognised? I suppose if this is the > case then explicitly adding the operator might not strictly be > necessary... Yes,? with the LLVM dialect, if your input bands are of integer type and you specify an output integer type, bitwise and will be done in the integer domain. > > Also, I appreciate the clarification that values are always > converted?to float during the arithmetic, I agree, Javier, that in > this case a bitwise operation is a bit strange... When using muparser, yes they are converted to double, since its "official" API only exposes that data type. But if the absolute value of integer values is below 1 << 53, they are perfectly represented as a double, so this is generally not much of an issue. -- http://www.spatialys.com My software is free, but my time generally not. From even.rouault at spatialys.com Fri Dec 5 05:44:26 2025 From: even.rouault at spatialys.com (Even Rouault) Date: Fri, 5 Dec 2025 14:44:26 +0100 Subject: [gdal-dev] Call for review: RFC-110 Just-In-Time (JIT) compilation of expressions In-Reply-To: <809190cb-688a-49ab-92b3-ccdd2c6a6874@spatialys.com> References: <809190cb-688a-49ab-92b3-ccdd2c6a6874@spatialys.com> Message-ID: <5648aeab-4cd9-4426-8b43-7e6c8b147424@spatialys.com> Hi, Given feedback and doubts about its current usefulness vs added complexity, I'mchanging the status of the RFC to "on hold". We'll see if we need to re-activate it at a later point. Even Le 25/11/2025 ? 13:57, Even Rouault via gdal-dev a ?crit?: > Hi, > > I've submitted https://github.com/OSGeo/gdal/pull/13466 which > introduces the optional use of the CLang and LLVM embedded libraries > to provide Just-In-Time (JIT) / on-the-fly compilation of code, and > its use to speed-up evaluation of MuParser-compatible expressions, as > used in VRTDerivedBand and gdal raster calc. > > Even > -- http://www.spatialys.com My software is free, but my time generally not.