From L.Kladivova at seznam.cz  Sun Jan  4 06:18:52 2026
From: L.Kladivova at seznam.cz (=?utf-8?q?Linda_Kladivov=C3=A1?=)
Date: Sun, 04 Jan 2026 15:18:52 +0100 (CET)
Subject: [gdal-dev] 
	=?utf-8?q?Decoding_feature_blobs_and_tracking_FIDs_in?=
	=?utf-8?q?_MVT_datasets?=
In-Reply-To: <280ce7c5-204e-4fdd-9662-650333ae7b7d@spatialys.com>
References: <6oI.IlON.odzi0Q7Vfj.1f8lUH@seznam.cz>
 <nA.Ilib.5alAPaRWMH7.1fIf9P@seznam.cz>
 <280ce7c5-204e-4fdd-9662-650333ae7b7d@spatialys.com>
Message-ID: <6{X.IlfT.2nzmPnhoeMs.1fMdRC@seznam.cz>


Hi Even,




you are completely right that having a SetFeature method would be nice, but 
it would require a much bigger intervention into the WriteFeature method. If
we were to do it properly, it shouldn?t be implemented as a simple Delete 
plus Create, but as a true update. That would mean checking which tiles the 
feature now intersects ? part of it may fall into new tiles, part may still 
be on the same tiles, and some parts may no longer be on tiles it previously
occupied. For my use case, honestly, the ideal would be even an 
UpdateFeature method :-) because very often the geometry doesn?t change at 
all, but one or more descriptive attributes do. However, that would imply an
even more significant change, especially since a feature is currently 
treated as a single binary entity.




Just to your question Even - yes,?I?d really like to get these changes 
upstream, so I have an official solution I can use for production delivery 
of Czech cadastral maps as vector tiles ? and, I?ll admit, also for my own 
dissertation work as one of outputs. So for now, the first step is just to 
make it possible to open a dataset in GDAL_OF_UPDATE mode and prepare it for
updates right from the dataset creation. Regarding DeleteFeature method,? I 
like the first approach you suggested - reporting a domain-level identifier 
as OGR_FID - I think it is quite clear although it would require longer 
documentation why OGR_FID is not OGR_FID anymore :-).?




I?ve put together a short document with the planned implementations [0]. 
Could you please take a look (or anyone else interested in this topic) and 
let me know if this seems okay to implement? Part of the work I have already
done, but I?d like to make sure it follows GDAL conventions all the way 
through.




Thanks a lot, and wishing you a happy new year!




Linda Karlovsk?




[0] https://docs.google.com/document/d/1KprkMH_YOGczrEWgXBsvubUpQWCu9_rXyG6
BQTv_RvM/edit?usp=sharing

---------- P?vodn? e-mail ----------
Od: Even Rouault via gdal-dev <gdal-dev at lists.osgeo.org>
Komu: gdal-dev at lists.osgeo.org
Datum: 23. 12. 2025 14:25:13
P?edm?t: Re: [gdal-dev] Decoding feature blobs and tracking FIDs in MVT 
datasets
" 
Hi Linda,

(Mailing lists have had issues lately)
" 
And internally I also have the full update pipeline implemented - when the 
dataset is opened in GDAL_OF_UPDATE mode, an instance of OGRMVTWriterDataset
is created, which allows me to call DeleteFeature (D) and CreateFeature (I),
or a combination of both when an existing feature needs to be updated (U).?
 " Updating an existing feature would normally be done through SetFeature(),
but Delete+Create may be OK for your use case "

Given this, I started thinking about an alternative solution based on a 
stable, domain-level identifier such as domain_id (in practice, e.g., parcel
_id), which is already known at write time. This would require storing such 
an identifier explicitly in the intermediate SQLite table (in addition to 
the internal idx, geometry, and tile coordinates). DeleteFeature could then 
be implemented by removing all rows associated with that domain-level 
identifier (that would be an input parameter).
" 
I'm not clear if you intend to submit the changes you mention upstream, but 
if so, using your domain-level identifier for DeleteFeature() wouldn't be 
appropriate given that DeleteFeature() is supposed to take the OGR FID as 
input parameter. So, either you would need to add logic into the driver to 
report a domain-level identifier as the OGR FID (for example through an open
option that would take the name of an attribute), or you would need to 
implement a pseudo-SQL command through ExecuteSQL(), like "DELETE_FEATURE_BY
_DOMAIN_ID {domain-level-identifier}"

Even

-- 
<a href='http://www.spatialys.com' class='-wm-moz-txt-link-freetext'>http://www.spatialys.com</a>
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: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260104/99bd0827/attachment.htm>

From gcpp.kalxas at gmail.com  Sun Jan  4 06:36:32 2026
From: gcpp.kalxas at gmail.com (Angelos Tzotsos)
Date: Sun, 4 Jan 2026 16:36:32 +0200
Subject: [gdal-dev] Fwd: OGC Compliance Renewal Notification - 30 Day
 Expiration Notice
In-Reply-To: <c2a46fb8-bca8-4c2b-aca1-0d5273c31bbb@gmail.com>
References: <1765361161.695827.236279.nullmailer@tic.ogc.org>
 <c2a46fb8-bca8-4c2b-aca1-0d5273c31bbb@gmail.com>
Message-ID: <963d3e39-9d57-4313-a1c9-fde32b47a8aa@gmail.com>

Happy New Year!

I have prepared the new compliance submission including CITE tests from 
pycsw, GeoServer and pygeoapi.
I have kept MapServer and GDAL listed, as last year.
Should I wait for new tests or should I continue with submission?

Best regards,
Angelos

On 12/10/25 14:57, Angelos Tzotsos wrote:
> Dear all,
>
> Please prepare your OGC CITE tests and let us know by the end of the 
> month so we can prepare the submission.
>
> Best regards,
> Angelos
>
>
> -------- Forwarded Message --------
> Subject:???? OGC Compliance Renewal Notification - 30 Day Expiration 
> Notice
> Date:???? Wed, 10 Dec 2025 10:06:01 +0000
> From:???? compliance at ogc.org
> Reply-To:???? compliance at ogc.org
> To:???? info at osgeo.org
> CC:???? Angelos Tzotsos <tzotsos at osgeo.org>, Michael Smith 
> <info at osgeo.org>, Even Roualt <even.rouault at spatialys.com>
>
>
>
> ?Open Source Geospatial Foundation (OSGeo)
>
> This is an automated email to inform you that your OGC-certified 
> compliance license(s) for the following products are due to be renewed 
> by *January 9th, 2026*. After that date, your products will no longer 
> be listed as certified OGC compliant and you may not claim that they 
> are compliant.
>
> Since you have reference implementations in your listings please be 
> aware of the following:
>
> ?* You need to retest if you want to continue being listed as a
> ?? reference implementation.
> ?* If you want to provide a new version as a reference implementation
> ?? you need to test that new version. The older version will no longer
> ?? hold the status of reference implementations.
> ?* If you want to continue displaying the certification for the older
> ?? version of your product, then you will be required to pay for the
> ?? certification.
>
> If you have already received an earlier notice and have started the 
> renewal process please ignore this message.
>
> We invite you to easily renew online in our implementation portal: 
> https://www.ogc.org/resource/products/registration
>
> As a reminder, the account used to manage your certification listings 
> is: *osgeo (info at osgeo.org)*
>
> If you have any questions please send an email to compliance at ogc.org. 
> The OGC compliance team will be more than glad to help you.
>
> ------------------------------------------------------------------------
>
>
> ?? Current OGC-Compliant Listings
>
>
> ???? GDAL/OGR 3.10
>
> Specification(s)???? Original Certification
> OGC GeoTIFF Standard 1.1
> (OGC Reference Implementation)???? 2025-01-10
> OGC KML 2.2.0
> (OGC Reference Implementation)???? 2025-01-10
> OGC KML (Level 2) 2.2.0
> (OGC Reference Implementation)???? 2025-01-10
> OGC KML (Level 3) 2.2.0
> (OGC Reference Implementation)???? 2025-01-10
> OGC? GeoPackage Encoding Standard 1.2
> (OGC Reference Implementation)???? 2025-01-10
> OGC? GeoPackage Encoding Standard: Extension Mechanism 1.2
> (OGC Reference Implementation)???? 2025-01-10
> OGC? GeoPackage Encoding Standard: Features 1.2
> (OGC Reference Implementation)???? 2025-01-10
> OGC? GeoPackage Encoding Standard: Metadata 1.2
> (OGC Reference Implementation)???? 2025-01-10
> OGC? GeoPackage Encoding Standard: RTree Spatial Indexes 1.2
> (OGC Reference Implementation)???? 2025-01-10
> OGC? GML in JPEG 2000 (GMLJP2) Encoding Standard Part 1: Core 2.0
> (OGC Reference Implementation)???? 2025-01-10
>
>
> ???? GeoServer 2.27
>
> Specification(s)???? Original Certification
> OGC API - Features - Part 1: Core 1.0???? 2025-07-10
> OGC API - Features - Part 2: Coordinate Reference Systems by Reference 
> 1.0???? 2025-07-10
> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard 1.0
> (OGC Reference Implementation)???? 2025-07-10
> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Acquisition 
> Information 1.0
> (OGC Reference Implementation)???? 2025-07-10
> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Acquisition 
> Parameters 1.0
> (OGC Reference Implementation)???? 2025-07-10
> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Data 
> Identification 1.0
> (OGC Reference Implementation)???? 2025-07-10
> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Earth 
> Observation 1.0
> (OGC Reference Implementation)???? 2025-07-10
> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Earth 
> Observation Collection 1.0
> (OGC Reference Implementation)???? 2025-07-10
> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Geometry 1.0
> (OGC Reference Implementation)???? 2025-07-10
> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Links 1.0
> (OGC Reference Implementation)???? 2025-07-10
> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Metadata 
> Information 1.0
> (OGC Reference Implementation)???? 2025-07-10
> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Offering 1.0
> (OGC Reference Implementation)???? 2025-07-10
> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Product 
> Information 1.0
> (OGC Reference Implementation)???? 2025-07-10
> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Properties 1.0
> (OGC Reference Implementation)???? 2025-07-10
> OGC GeoTIFF Standard 1.1
> (OGC Reference Implementation)???? 2025-07-10
> OGC? GeoPackage Encoding Standard 1.2
> (OGC Reference Implementation)???? 2025-07-10
> OGC? GeoPackage Encoding Standard: Extension Mechanism 1.2
> (OGC Reference Implementation)???? 2025-07-10
> OGC? GeoPackage Encoding Standard: Features 1.2
> (OGC Reference Implementation)???? 2025-07-10
> OGC? GeoPackage Encoding Standard: Metadata 1.2
> (OGC Reference Implementation)???? 2025-07-10
> OGC? GeoPackage Encoding Standard: RTree Spatial Indexes 1.2
> (OGC Reference Implementation)???? 2025-07-10
> OGC? GeoPackage Encoding Standard: Schema 1.2
> (OGC Reference Implementation)???? 2025-07-10
> OGC? WCS 2.0 Interface Standard- Core: Corrigendum 2.0.1
> (OGC Reference Implementation)???? 2025-07-10
> OGC? Web Coverage Service Interface Standard - Interpolation Extension 
> 1.0
> (OGC Reference Implementation)???? 2025-07-10
> OGC? Web Coverage Service Interface Standard - Scaling Extension 1.0
> (OGC Reference Implementation)???? 2025-07-10
> OGC? Web Coverage Service Interface Standard - CRS Extension 1.0
> (OGC Reference Implementation)???? 2025-07-10
> OGC? Web Coverage Service Interface Standard - Range Subsetting 
> Extension 1.0
> (OGC Reference Implementation)???? 2025-07-10
> OpenGIS Web Coverage Service (WCS) Implementation Specification 
> (Corrigendum) 1.0.0
> (OGC Reference Implementation)???? 2025-07-10
> OpenGIS Web Coverage Service (WCS) Implementation Specification 
> Corrigendum 1 1.1.1
> (OGC Reference Implementation)???? 2025-07-10
> OpenGIS Web Feature Service (WFS) Implementation Specification 1.1.0 
> 2025-07-10
> OpenGIS Web Feature Service (WFS) Implementation Specification (Basic) 
> 1.1.0???? 2025-07-10
> OpenGIS Web Feature Service (WFS) Implementation Specification 
> (Transactional) 1.1.0???? 2025-07-10
> OpenGIS Web Feature Service - Basic 2.0???? 2025-07-10
> OpenGIS Web Feature Service - Locking 2.0???? 2025-07-10
> OpenGIS Web Feature Service - Transactional 2.0???? 2025-07-10
> OpenGIS Web Feature Service 2.0 Interface Standard (also ISO 19142) 
> 2.0 2025-07-10
> OpenGIS Web Map Service (WMS) Implementation Specification 1.3.0 
> 2025-07-10
> OpenGIS Web Map Tile Service Implementation Standard 1.0.0 2025-07-10
> Web Feature Service 1.0.0
> (OGC Reference Implementation)???? 2025-07-10
> Web Feature Service (Transactional) 1.0.0
> (OGC Reference Implementation)???? 2025-07-10
> Web Map Service 1.1.1???? 2025-07-10
>
>
> ???? istSOS 2.3.1
>
> Specification(s)???? Original Certification
> OpenGIS Sensor Observation Service 1.0.0
> (OGC Reference Implementation)???? 2018-01-09
>
>
> ???? pycsw 2.6.0
>
> Specification(s)???? Original Certification
> OGC GeoRSS Encoding Standard 1.0
> (OGC Reference Implementation)???? 2022-04-28
> OGC? Catalogue Services 3.0 Specification - HTTP Protocol Binding 3.0
> (OGC Reference Implementation)???? 2021-01-09
> OGC? Catalogue Services 3.0 Specification - HTTP Protocol Binding 
> (OpenSearch) 3.0
> (OGC Reference Implementation)???? 2021-01-09
> OpenGIS Catalogue Service Implementation Specification 2.0.2
> (OGC Reference Implementation)???? 2021-01-09
> OpenGIS Catalogue Service Implementation Specification [Catalogue 
> Service for the Web] 2.0.2
> (OGC Reference Implementation)???? 2021-01-09
>
>
> ???? pygeoapi 0.19.0
>
> Specification(s)???? Original Certification
> OGC API - Environmental Data Retrieval Standard 1.0.1
> (OGC Reference Implementation)???? 2025-01-10
> OGC API - Environmental Data Retrieval Standard: Collections 1.0.1
> (OGC Reference Implementation)???? 2025-01-10
> OGC API - Environmental Data Retrieval Standard: CoverageJSON 1.0.1
> (OGC Reference Implementation)???? 2025-01-10
> OGC API - Environmental Data Retrieval Standard: EDRGeoJSON 1.0.1
> (OGC Reference Implementation)???? 2025-01-10
> OGC API - Environmental Data Retrieval Standard: GeoJSON 1.0.1
> (OGC Reference Implementation)???? 2025-01-10
> OGC API - Environmental Data Retrieval Standard: HTML 1.0.1
> (OGC Reference Implementation)???? 2025-01-10
> OGC API - Environmental Data Retrieval Standard: JSON 1.0.1
> (OGC Reference Implementation)???? 2025-01-10
> OGC API - Features - Part 1: Core 1.0
> (OGC Reference Implementation)???? 2025-01-10
> OGC API - Tiles - Part 1: Core 1.0
> (OGC Reference Implementation)???? 2025-01-10
> OGC API - Tiles - Part 1: DatasetTilesets 1.0
> (OGC Reference Implementation)???? 2025-01-10
> OGC API - Tiles - Part 1: GeoDataTilesets 1.0
> (OGC Reference Implementation)???? 2025-01-10
>
>
>

-- 
Angelos Tzotsos, PhD
President, Board of Directors
Open Source Geospatial Foundation
https://www.osgeo.org/member/angelos-tzotsos/



From lars at ahlzen.com  Mon Jan  5 06:15:50 2026
From: lars at ahlzen.com (Lars Ahlzen)
Date: Mon, 5 Jan 2026 14:15:50 +0000
Subject: [gdal-dev] Support for Terrain-RGB
Message-ID: <35be044e-0232-4cd0-90f8-a6a5394333c5@ahlzen.com>

Hi all,

For Open/WebGL-based client side map rendering libraries, like MapLibre 
or Mapbox GL, Terrain-RGB [1] (original spec by MapBox I believe) seems 
to be the elevation encoding of choice.

The encoding itself, meant for use with 8-bits per channel RGB raster 
formats such as PNG tiles, is straightforward:

 ?elevation (in meters) = -10000 + 0.1 * (R * 65536 + G * 256 + B)

As far as I know a separate tool is typically used for the encoding, 
such as rio-rgbify [2] from Mapbox. There's an example writeup of such 
workflow at [3]. Perhaps the same thing could also be achieved using the 
raster calculator (gdal_calc), but that seems far from trivial for most 
users.

It looks like it would be relatively easy to add native support for this 
in GDAL, perhaps as another mode in gdaldem. Would it make sense if I 
gave that a try?

- Lars

[1] https://blog.mapbox.com/global-elevation-data-6689f1d0ba65
[2] https://github.com/mapbox/rio-rgbify
[3] https://github.com/syncpoint/terrain-rgb/blob/master/README.md


From even.rouault at spatialys.com  Mon Jan  5 06:50:20 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Mon, 5 Jan 2026 15:50:20 +0100
Subject: [gdal-dev] Support for Terrain-RGB
In-Reply-To: <35be044e-0232-4cd0-90f8-a6a5394333c5@ahlzen.com>
References: <35be044e-0232-4cd0-90f8-a6a5394333c5@ahlzen.com>
Message-ID: <634f076d-441f-457e-aaca-7ebeb3f270be@spatialys.com>

Hi Lars,

I would rather see that as a standalone TerrainRGB raster driver, 
leveraging the PNG driver underneath.

For the read side, if one is desired (write-only drivers are possible), 
is there a way in metadata or file naming of distinguishing a regular 
RGB PNG file from a Terrain-RGB one? If not, the Identify() function 
should rely on users providing a "TerrainRGB:" prefix or specifying 
explicitly the driver in the GDALOpenInfo::papszAllowedDrivers member 
(testable with ?poOpenInfo->IsSingleAllowedDriver("TerrainRGB") )

Even

Le 05/01/2026 ? 15:15, Lars Ahlzen via gdal-dev a ?crit?:
> Hi all,
>
> For Open/WebGL-based client side map rendering libraries, like 
> MapLibre or Mapbox GL, Terrain-RGB [1] (original spec by MapBox I 
> believe) seems to be the elevation encoding of choice.
>
> The encoding itself, meant for use with 8-bits per channel RGB raster 
> formats such as PNG tiles, is straightforward:
>
> ?elevation (in meters) = -10000 + 0.1 * (R * 65536 + G * 256 + B)
>
> As far as I know a separate tool is typically used for the encoding, 
> such as rio-rgbify [2] from Mapbox. There's an example writeup of such 
> workflow at [3]. Perhaps the same thing could also be achieved using 
> the raster calculator (gdal_calc), but that seems far from trivial for 
> most users.
>
> It looks like it would be relatively easy to add native support for 
> this in GDAL, perhaps as another mode in gdaldem. Would it make sense 
> if I gave that a try?
>
> - Lars
>
> [1] https://blog.mapbox.com/global-elevation-data-6689f1d0ba65
> [2] https://github.com/mapbox/rio-rgbify
> [3] https://github.com/syncpoint/terrain-rgb/blob/master/README.md
>
> _______________________________________________
> 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 andrew.bell.ia at gmail.com  Mon Jan  5 09:25:14 2026
From: andrew.bell.ia at gmail.com (Andrew Bell)
Date: Mon, 5 Jan 2026 12:25:14 -0500
Subject: [gdal-dev] New build warning
Message-ID: <CACJ51z1T06xGRCYaXDcTQ6jpJXxA=C+TV41i1Rq2=hqKn-ZHCw@mail.gmail.com>

Hi,

I updated to the latest master and am now seeing the following warning
during compilation:

[156/1486] Building CXX object alg/CMakeFiles/alg.dir/thinplatespline.cpp.o
clang: warning: argument unused during compilation: '-Xclang -fopenmp'
[-Wunused-command-line-argument]

If anyone has some info on this, please let me know.

-- 
Andrew Bell
andrew.bell.ia at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260105/1f903d43/attachment.htm>

From even.rouault at spatialys.com  Mon Jan  5 09:32:01 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Mon, 5 Jan 2026 18:32:01 +0100
Subject: [gdal-dev] New build warning
In-Reply-To: <CACJ51z1T06xGRCYaXDcTQ6jpJXxA=C+TV41i1Rq2=hqKn-ZHCw@mail.gmail.com>
References: <CACJ51z1T06xGRCYaXDcTQ6jpJXxA=C+TV41i1Rq2=hqKn-ZHCw@mail.gmail.com>
Message-ID: <6dea3d02-51e5-4fe5-a6cb-7064a098a213@spatialys.com>

Hi Andrew,

openmp is enabled when available since 
https://github.com/OSGeo/gdal/commit/2a3f06b90f2d68da446451a44090aa38fd6f4b5a#diff-c6d7b93ff4bf010c2c6218c9329af9afb9a00aab7871175046a9b50f26826452R435 
.? What is your clang version ?? That warning are not shown on our clang 
based CI configurations up to now.

Even

Le 05/01/2026 ? 18:25, Andrew Bell via gdal-dev a ?crit?:
> Hi,
>
> I updated to the latest master and am now seeing the following warning 
> during compilation:
>
> [156/1486] Building CXX object 
> alg/CMakeFiles/alg.dir/thinplatespline.cpp.o
> clang: warning: argument unused during compilation: '-Xclang -fopenmp' 
> [-Wunused-command-line-argument]
>
> If anyone has some info on this, please let me know.
>
> -- 
> Andrew Bell
> andrew.bell.ia at gmail.com
>
> _______________________________________________
> 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: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260105/3f915c2a/attachment.htm>

From andrew.bell.ia at gmail.com  Mon Jan  5 09:41:54 2026
From: andrew.bell.ia at gmail.com (Andrew Bell)
Date: Mon, 5 Jan 2026 12:41:54 -0500
Subject: [gdal-dev] New build warning
In-Reply-To: <6dea3d02-51e5-4fe5-a6cb-7064a098a213@spatialys.com>
References: <CACJ51z1T06xGRCYaXDcTQ6jpJXxA=C+TV41i1Rq2=hqKn-ZHCw@mail.gmail.com>
 <6dea3d02-51e5-4fe5-a6cb-7064a098a213@spatialys.com>
Message-ID: <CACJ51z2_ScRCbKgmLNqzg4SS70xSZKzK9_mOaaj9-34CALFEWA@mail.gmail.com>

Hi,

It looks like CI is way ahead of my config. Are you using an Apple-provided
compiler or one from clang or elsewhere?

[sd-integration] (gdal) $ clang++ --version
Apple clang version 14.0.3 (clang-1403.0.22.14.1)
Target: x86_64-apple-darwin22.5.0
Thread model: posix
InstalledDir:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
On Mon, Jan 5, 2026 at 12:32?PM Even Rouault <even.rouault at spatialys.com>
wrote:

> Hi Andrew,
>
> openmp is enabled when available since
> https://github.com/OSGeo/gdal/commit/2a3f06b90f2d68da446451a44090aa38fd6f4b5a#diff-c6d7b93ff4bf010c2c6218c9329af9afb9a00aab7871175046a9b50f26826452R435
> .  What is your clang version ?  That warning are not shown on our clang
> based CI configurations up to now.
>
Even
> Le 05/01/2026 ? 18:25, Andrew Bell via gdal-dev a ?crit :
>
> Hi,
>
> I updated to the latest master and am now seeing the following warning
> during compilation:
>
> [156/1486] Building CXX object alg/CMakeFiles/alg.dir/thinplatespline.cpp.o
> clang: warning: argument unused during compilation: '-Xclang -fopenmp'
> [-Wunused-command-line-argument]
>
> If anyone has some info on this, please let me know.
>
> --
> Andrew Bell
> andrew.bell.ia at gmail.com
>
> _______________________________________________
> 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.
>
>

-- 
Andrew Bell
andrew.bell.ia at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260105/367d5006/attachment.htm>

From even.rouault at spatialys.com  Mon Jan  5 09:51:44 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Mon, 5 Jan 2026 18:51:44 +0100
Subject: [gdal-dev] New build warning
In-Reply-To: <CACJ51z2_ScRCbKgmLNqzg4SS70xSZKzK9_mOaaj9-34CALFEWA@mail.gmail.com>
References: <CACJ51z1T06xGRCYaXDcTQ6jpJXxA=C+TV41i1Rq2=hqKn-ZHCw@mail.gmail.com>
 <6dea3d02-51e5-4fe5-a6cb-7064a098a213@spatialys.com>
 <CACJ51z2_ScRCbKgmLNqzg4SS70xSZKzK9_mOaaj9-34CALFEWA@mail.gmail.com>
Message-ID: <be84642f-8065-48f6-81c4-b947af684d73@spatialys.com>

Our Mac instances must use the Apple-provided compiler I suppose. We 
also have a Linux CI config using a recent clang (from Fedora:rawhide, 
so cutting edge)

OpenMP detection is done through the CMake provided FindOpenMP module: 
https://cmake.org/cmake/help/latest/module/FindOpenMP.html

But I would expect your compiler to support it although it is not 
cutting edge.

You can explicitly disable it by setting -DGDAL_USE_OPENMP=OFF

Le 05/01/2026 ? 18:41, Andrew Bell a ?crit?:
> Hi,
>
> It looks like CI is way ahead of my config. Are you using an 
> Apple-provided compiler or one from clang or elsewhere?
>
> [sd-integration] (gdal) $ clang++ --version
> Apple clang version 14.0.3 (clang-1403.0.22.14.1)
> Target: x86_64-apple-darwin22.5.0
> Thread model: posix
> InstalledDir: 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
> On Mon, Jan 5, 2026 at 12:32?PM Even Rouault 
> <even.rouault at spatialys.com> wrote:
>
>     Hi Andrew,
>
>     openmp is enabled when available since
>     https://github.com/OSGeo/gdal/commit/2a3f06b90f2d68da446451a44090aa38fd6f4b5a#diff-c6d7b93ff4bf010c2c6218c9329af9afb9a00aab7871175046a9b50f26826452R435
>     .? What is your clang version ?? That warning are not shown on our
>     clang based CI configurations up to now.
>
>     Even
>
>     Le 05/01/2026 ? 18:25, Andrew Bell via gdal-dev a ?crit?:
>>     Hi,
>>
>>     I updated to the latest master and am now seeing the following
>>     warning during compilation:
>>
>>     [156/1486] Building CXX object
>>     alg/CMakeFiles/alg.dir/thinplatespline.cpp.o
>>     clang: warning: argument unused during compilation: '-Xclang
>>     -fopenmp' [-Wunused-command-line-argument]
>>
>>     If anyone has some info on this, please let me know.
>>
>>     -- 
>>     Andrew Bell
>>     andrew.bell.ia at gmail.com
>>
>>     _______________________________________________
>>     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.
>
>
>
> -- 
> Andrew Bell
> andrew.bell.ia at gmail.com

-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260105/c17a2295/attachment-0001.htm>

From andrew.bell.ia at gmail.com  Mon Jan  5 11:26:51 2026
From: andrew.bell.ia at gmail.com (Andrew Bell)
Date: Mon, 5 Jan 2026 14:26:51 -0500
Subject: [gdal-dev] New build warning
In-Reply-To: <be84642f-8065-48f6-81c4-b947af684d73@spatialys.com>
References: <CACJ51z1T06xGRCYaXDcTQ6jpJXxA=C+TV41i1Rq2=hqKn-ZHCw@mail.gmail.com>
 <6dea3d02-51e5-4fe5-a6cb-7064a098a213@spatialys.com>
 <CACJ51z2_ScRCbKgmLNqzg4SS70xSZKzK9_mOaaj9-34CALFEWA@mail.gmail.com>
 <be84642f-8065-48f6-81c4-b947af684d73@spatialys.com>
Message-ID: <CACJ51z2rskNthOwVaa-=vd+PGL97VwNmCyeC06Rn9myYQFb+0g@mail.gmail.com>

Thanks,

I upgraded cmake to the latest version thinking that perhaps the find
script was bad, but that made no difference, so I disabled OpenMP as
suggested.

On Mon, Jan 5, 2026 at 12:51?PM Even Rouault <even.rouault at spatialys.com>
wrote:

> Our Mac instances must use the Apple-provided compiler I suppose. We also
> have a Linux CI config using a recent clang (from Fedora:rawhide, so
> cutting edge)
>
> OpenMP detection is done through the CMake provided FindOpenMP module:
> https://cmake.org/cmake/help/latest/module/FindOpenMP.html
>
> But I would expect your compiler to support it although it is not cutting
> edge.
>
> You can explicitly disable it by setting -DGDAL_USE_OPENMP=OFF
> Le 05/01/2026 ? 18:41, Andrew Bell a ?crit :
>
> Hi,
>
> It looks like CI is way ahead of my config. Are you using an
> Apple-provided compiler or one from clang or elsewhere?
>
> [sd-integration] (gdal) $ clang++ --version
> Apple clang version 14.0.3 (clang-1403.0.22.14.1)
> Target: x86_64-apple-darwin22.5.0
> Thread model: posix
> InstalledDir:
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
> On Mon, Jan 5, 2026 at 12:32?PM Even Rouault <even.rouault at spatialys.com>
> wrote:
>
>> Hi Andrew,
>>
>> openmp is enabled when available since
>> https://github.com/OSGeo/gdal/commit/2a3f06b90f2d68da446451a44090aa38fd6f4b5a#diff-c6d7b93ff4bf010c2c6218c9329af9afb9a00aab7871175046a9b50f26826452R435
>> .  What is your clang version ?  That warning are not shown on our clang
>> based CI configurations up to now.
>>
> Even
>> Le 05/01/2026 ? 18:25, Andrew Bell via gdal-dev a ?crit :
>>
>> Hi,
>>
>> I updated to the latest master and am now seeing the following warning
>> during compilation:
>>
>> [156/1486] Building CXX object
>> alg/CMakeFiles/alg.dir/thinplatespline.cpp.o
>> clang: warning: argument unused during compilation: '-Xclang -fopenmp'
>> [-Wunused-command-line-argument]
>>
>> If anyone has some info on this, please let me know.
>>
>> --
>> Andrew Bell
>> andrew.bell.ia at gmail.com
>>
>> _______________________________________________
>> 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.
>>
>>
>
> --
> Andrew Bell
> andrew.bell.ia at gmail.com
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
>

-- 
Andrew Bell
andrew.bell.ia at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260105/788434cc/attachment.htm>

From rayg at daylongraphics.com  Mon Jan  5 11:47:13 2026
From: rayg at daylongraphics.com (rayg)
Date: Mon, 5 Jan 2026 19:47:13 +0000 (GMT)
Subject: [gdal-dev] Support for Terrain-RGB
In-Reply-To: <634f076d-441f-457e-aaca-7ebeb3f270be@spatialys.com>
References: <35be044e-0232-4cd0-90f8-a6a5394333c5@ahlzen.com>
 <634f076d-441f-457e-aaca-7ebeb3f270be@spatialys.com>
 <199025618490178560.0.v2@titan.email>
Message-ID: <199025618490178560.0.v2@titan.email>

An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260105/82322733/attachment.htm>

From gdt at lexort.com  Mon Jan  5 12:21:34 2026
From: gdt at lexort.com (Greg Troxel)
Date: Mon, 05 Jan 2026 15:21:34 -0500
Subject: [gdal-dev] Support for Terrain-RGB
In-Reply-To: <199025618490178560.0.v2@titan.email> (rayg via gdal-dev's
 message of "Mon, 5 Jan 2026 19:47:13 +0000 (GMT)")
References: <35be044e-0232-4cd0-90f8-a6a5394333c5@ahlzen.com>
 <634f076d-441f-457e-aaca-7ebeb3f270be@spatialys.com>
 <199025618490178560.0.v2@titan.email>
 <199025618490178560.0.v2@titan.email>
Message-ID: <rmildibn73l.fsf@s1.lexort.com>

rayg via gdal-dev <gdal-dev at lists.osgeo.org> writes:

> Strange encoding, -10000 meters isn't deep enough for the Marianas Trench. You could borrow another 10 km from the 1.6
> million meters still available on the positive side.
>
> Scaling by 0.1 also means a 10 cm vertical resolution., which is useless for some use cases. The 24 bits per pixel could
> be much better allocated.

There's a difference between "should gdal have support for this encoding
which people use and in which people might encounter data" and "how
should I design the best encoding".

I don't understand how your critique of Terrain-RGB bears on what gdal
should do about it.

From lars at ahlzen.com  Mon Jan  5 13:27:10 2026
From: lars at ahlzen.com (Lars Ahlzen)
Date: Mon, 5 Jan 2026 21:27:10 +0000
Subject: [gdal-dev] Support for Terrain-RGB
In-Reply-To: <634f076d-441f-457e-aaca-7ebeb3f270be@spatialys.com>
References: <35be044e-0232-4cd0-90f8-a6a5394333c5@ahlzen.com>
 <634f076d-441f-457e-aaca-7ebeb3f270be@spatialys.com>
Message-ID: <6dfa9ee1-2862-4482-8315-b08ee858404d@ahlzen.com>

Hi Even,

On 05/01/2026 14:50, Even Rouault wrote:
> I would rather see that as a standalone TerrainRGB raster driver, 
> leveraging the PNG driver underneath.

That was my original thought as well. Then, after thinking about 
different use cases I thought adding a gdaldem mode would allow for a 
wider range of workflows.

That said, you probably have a better idea of what would work best for 
GDAL as a whole, so I can look in that direction.

> For the read side, if one is desired (write-only drivers are 
> possible), is there a way in metadata or file naming of distinguishing 
> a regular RGB PNG file from a Terrain-RGB one? If not, the Identify() 
> function should rely on users providing a "TerrainRGB:" prefix or 
> specifying explicitly the driver in the 
> GDALOpenInfo::papszAllowedDrivers member (testable with 
> ?poOpenInfo->IsSingleAllowedDriver("TerrainRGB") ) 

I don't think there's any sort of indication of the encoding in the 
files themselves (please correct me if I'm wrong). I imagine the need to 
decode Terrain-RGB back into a single-band DEM would be rare anyway, so 
a write-only driver might be sufficient.

- Lars


From even.rouault at spatialys.com  Mon Jan  5 13:42:35 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Mon, 5 Jan 2026 22:42:35 +0100
Subject: [gdal-dev] Support for Terrain-RGB
In-Reply-To: <6dfa9ee1-2862-4482-8315-b08ee858404d@ahlzen.com>
References: <35be044e-0232-4cd0-90f8-a6a5394333c5@ahlzen.com>
 <634f076d-441f-457e-aaca-7ebeb3f270be@spatialys.com>
 <6dfa9ee1-2862-4482-8315-b08ee858404d@ahlzen.com>
Message-ID: <15546688-1caa-45fa-aa13-9d8835609057@spatialys.com>


Le 05/01/2026 ? 22:27, Lars Ahlzen a ?crit?:
> Hi Even,
>
> On 05/01/2026 14:50, Even Rouault wrote:
>> I would rather see that as a standalone TerrainRGB raster driver, 
>> leveraging the PNG driver underneath.
>
> That was my original thought as well. Then, after thinking about 
> different use cases I thought adding a gdaldem mode would allow for a 
> wider range of workflows.
>
> That said, you probably have a better idea of what would work best for 
> GDAL as a whole, so I can look in that direction.

The rationale behind suggesting a driver rather than a new mode to 
gdaldem is that gdaldem modes are agnostic of the output format. Here it 
is really a file format issue.

-- 
http://www.spatialys.com
My software is free, but my time generally not.


From lars at ahlzen.com  Mon Jan  5 13:46:43 2026
From: lars at ahlzen.com (Lars Ahlzen)
Date: Mon, 5 Jan 2026 21:46:43 +0000
Subject: [gdal-dev] Support for Terrain-RGB
In-Reply-To: <199025618490178560.0.v2@titan.email>
References: <35be044e-0232-4cd0-90f8-a6a5394333c5@ahlzen.com>
 <634f076d-441f-457e-aaca-7ebeb3f270be@spatialys.com>
 <199025618490178560.0.v2@titan.email> <199025618490178560.0.v2@titan.email>
Message-ID: <d9eee51e-328a-4472-90cf-542fb246f662@ahlzen.com>

On 05/01/2026 19:47, rayg wrote:
> Strange encoding, -10000 meters isn't deep enough for the Marianas 
> Trench. You could borrow another 10 km from the 1.6 million meters 
> still available on the positive side.
>
> Scaling by 0.1 also means a 10 cm vertical resolution., which is 
> useless for some use cases. The 24 bits per pixel could be much better 
> allocated.

I kind of agree with both points, but I guess the format is what it is.

I don't think it's supposed to be a general-purpose storage format. It's 
encoding just enough data to do good enough real-time visualization of 
elevation, like hillshading or hypsometric tints, client side.

Looks like at least rio-rgbify [1] allows setting a custom base value 
and interval. That might be something we want to emulate as well, 
perhaps as creation options (if a raster format driver) or command line 
options (if part of gdaldem).

- Lars

[1] https://github.com/mapbox/rio-rgbify


From andrey_vi at list.ru  Tue Jan  6 00:40:54 2026
From: andrey_vi at list.ru (=?UTF-8?B?QW5kcmV5IFZJ?=)
Date: Tue, 06 Jan 2026 11:40:54 +0300
Subject: [gdal-dev] =?utf-8?q?Support_for_Terrain-RGB?=
In-Reply-To: <d9eee51e-328a-4472-90cf-542fb246f662@ahlzen.com>
References: <35be044e-0232-4cd0-90f8-a6a5394333c5@ahlzen.com>
 <199025618490178560.0.v2@titan.email>
 <d9eee51e-328a-4472-90cf-542fb246f662@ahlzen.com>
Message-ID: <1767688854.62600921@f191.i.mail.ru>


Hi all.

It would be great to have RGB DEM support in GDAL.
?
Some considerations.
1.?It makes sense to add support not only for Mapbox Terrain?RGB, but also for Mapzen Terrarium RGB [1][2]?encoding. Mapbox and Maplibre support both encodings, the latter also supports custom encoding [3][4]. Therefore, support for custom encoding will also be useful.
?
2.? I don't quite understand why only PNG format is being discussed here.?It is possible to encode a DEM into any raster RGB image format.?Moreover, PNG isn't the most optimal of them [5]. In my opinion, the WEBP format is preferable. For example, Maptiler uses it for Terrain RGB and Ocean RGB datasets [6].
?
3. Ideally, the output should be not just an encoded image, but tiles ready for use in Mapbox/Maplibre/etc., including in the form of data sets (MBTiles, PMTiles).
?
?
[1]? https://www.mapzen.com/blog/terrain-tile-service/
[2]? https://github.com/tilezen/joerd/blob/master/docs/formats.md#terrarium
[3]? https://docs.mapbox.com/style-spec/reference/sources/#raster-dem-encoding
[4]? https://maplibre.org/maplibre-style-spec/sources/#encoding_1
[5]? https://medium.com/@frederic.rodrigo/optimization-of-rgb-dem-tiles-for-dynamic-hill-shading-with-mapbox-gl-or-maplibre-gl-55bef8eb3d86
[6]? https://www.maptiler.com/on-prem-datasets/dataset/terrain-rgb/
?
>Tuesday, January 6, 2026 0:46 AM +03:00 from Lars Ahlzen via gdal-dev < gdal-dev at lists.osgeo.org >:
>?
>On 05/01/2026 19:47, rayg wrote:
>> Strange encoding, -10000 meters isn't deep enough for the Marianas
>> Trench. You could borrow another 10 km from the 1.6 million meters
>> still available on the positive side.
>>
>> Scaling by 0.1 also means a 10 cm vertical resolution., which is
>> useless for some use cases. The 24 bits per pixel could be much better
>> allocated.
>
>I kind of agree with both points, but I guess the format is what it is.
>
>I don't think it's supposed to be a general-purpose storage format. It's
>encoding just enough data to do good enough real-time visualization of
>elevation, like hillshading or hypsometric tints, client side.
>
>Looks like at least rio-rgbify [1] allows setting a custom base value
>and interval. That might be something we want to emulate as well,
>perhaps as creation options (if a raster format driver) or command line
>options (if part of gdaldem).
>
>- Lars
>
>[1]  https://github.com/mapbox/rio-rgbify
>
>_______________________________________________
>gdal-dev mailing list
>gdal-dev at lists.osgeo.org
>https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Andrey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260106/fac68e8d/attachment.htm>

From lars at ahlzen.com  Tue Jan  6 02:27:42 2026
From: lars at ahlzen.com (Lars Ahlzen)
Date: Tue, 6 Jan 2026 10:27:42 +0000
Subject: [gdal-dev] Support for Terrain-RGB
In-Reply-To: <15546688-1caa-45fa-aa13-9d8835609057@spatialys.com>
References: <35be044e-0232-4cd0-90f8-a6a5394333c5@ahlzen.com>
 <634f076d-441f-457e-aaca-7ebeb3f270be@spatialys.com>
 <6dfa9ee1-2862-4482-8315-b08ee858404d@ahlzen.com>
 <15546688-1caa-45fa-aa13-9d8835609057@spatialys.com>
Message-ID: <b51d5179-34f5-417d-8103-1623b565f121@ahlzen.com>

On 05/01/2026 21:42, Even Rouault wrote:
>
> Le 05/01/2026 ? 22:27, Lars Ahlzen a ?crit?:
>> Hi Even,
>>
>> On 05/01/2026 14:50, Even Rouault wrote:
>>> I would rather see that as a standalone TerrainRGB raster driver, 
>>> leveraging the PNG driver underneath.
>>
>> That was my original thought as well. Then, after thinking about 
>> different use cases I thought adding a gdaldem mode would allow for a 
>> wider range of workflows.
>>
>> That said, you probably have a better idea of what would work best 
>> for GDAL as a whole, so I can look in that direction.
>
> The rationale behind suggesting a driver rather than a new mode to 
> gdaldem is that gdaldem modes are agnostic of the output format. Here 
> it is really a file format issue. 

Being format agnostic might actually be an advantage though. While the 
encoding is commonly used with PNG tiles, other RGB raster formats 
should work as well and may even be advantageous. For example, I've used 
a terrain-RGB encoded GeoTIFF as an intermediary format, from which 
tiles were later generated using gdal2tiles.

- Lars



From rayg at daylongraphics.com  Tue Jan  6 05:33:50 2026
From: rayg at daylongraphics.com (rayg)
Date: Tue, 6 Jan 2026 13:33:50 +0000 (UTC)
Subject: [gdal-dev] Support for Terrain-RGB
In-Reply-To: <b51d5179-34f5-417d-8103-1623b565f121@ahlzen.com>
References: <199025618490178560.0.v2@titan.email>
 <1767688854.62600921@f191.i.mail.ru>
 <b51d5179-34f5-417d-8103-1623b565f121@ahlzen.com>
 <199092723884965888.0.v2@titan.email>
Message-ID: <199092723884965888.0.v2@titan.email>

An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260106/fec8271f/attachment.htm>

From lars at ahlzen.com  Thu Jan  8 02:05:29 2026
From: lars at ahlzen.com (Lars Ahlzen)
Date: Thu, 8 Jan 2026 10:05:29 +0000
Subject: [gdal-dev] Support for Terrain-RGB
In-Reply-To: <1767688854.62600921@f191.i.mail.ru>
References: <35be044e-0232-4cd0-90f8-a6a5394333c5@ahlzen.com>
 <199025618490178560.0.v2@titan.email>
 <d9eee51e-328a-4472-90cf-542fb246f662@ahlzen.com>
 <1767688854.62600921@f191.i.mail.ru>
Message-ID: <7de562a8-97c2-4f36-922c-df105255f63f@ahlzen.com>

Good points.

Given these and other comments, it sounds to me like we should support 
different RGB raster formats, as the storage format really is 
independent from the encoding. Also, supporting Mapbox Terrain RGB, 
Terrarium RGB, and custom encodings would be desirable. I believe these 
are all variants of the same thing anyway, with a base (offset) and a 
scale for each of the R, G and B channels.

Even, you probably know GDAL internals quite well, what are your 
thoughts? If we were to support arbitrary RGB raster formats, would an 
implementation elsewhere (like gdaldem) be more suitable than a new 
raster driver, or could a raster driver support different actual file 
formats?

If the latter, could the existing MBTiles driver be used for direct DEM 
-> RGB tiles (.png/.webp/...) -> .mbtiles generation?

- Lars

On 06/01/2026 08:40, Andrey VI wrote:
> Hi all.
>
> It would be great to have RGB DEM support in GDAL.
> Some considerations.
> 1.?It makes sense to add support not only for Mapbox Terrain?RGB, but 
> also for Mapzen Terrarium RGB [1][2]?encoding. Mapbox and Maplibre 
> support both encodings, the latter also supports custom encoding 
> [3][4]. Therefore, support for custom encoding will also be useful.
> 2. I don't quite understand why only PNG format is being discussed 
> here.?It is possible to encode a DEM into any raster RGB image 
> format.?Moreover, PNG isn't the most optimal of them [5]. In my 
> opinion, the WEBP format is preferable. For example, Maptiler uses it 
> for Terrain RGB and Ocean RGB datasets [6].
> 3. Ideally, the output should be not just an encoded image, but tiles 
> ready for use in Mapbox/Maplibre/etc., including in the form of data 
> sets (MBTiles, PMTiles).
> [1] https://www.mapzen.com/blog/terrain-tile-service/
> [2] https://github.com/tilezen/joerd/blob/master/docs/formats.md#terrarium
> [3] 
> https://docs.mapbox.com/style-spec/reference/sources/#raster-dem-encoding
> [4] https://maplibre.org/maplibre-style-spec/sources/#encoding_1
> [5] 
> https://medium.com/@frederic.rodrigo/optimization-of-rgb-dem-tiles-for-dynamic-hill-shading-with-mapbox-gl-or-maplibre-gl-55bef8eb3d86
> [6] https://www.maptiler.com/on-prem-datasets/dataset/terrain-rgb/ 
> <https://www.maptiler.com/on-prem-datasets/dataset/terrain-rgb/#0.22/0/0>
>
>     Tuesday, January 6, 2026 0:46 AM +03:00 from Lars Ahlzen via
>     gdal-dev <gdal-dev at lists.osgeo.org>:
>     On 05/01/2026 19:47, rayg wrote:
>     > Strange encoding, -10000 meters isn't deep enough for the Marianas
>     > Trench. You could borrow another 10 km from the 1.6 million meters
>     > still available on the positive side.
>     >
>     > Scaling by 0.1 also means a 10 cm vertical resolution., which is
>     > useless for some use cases. The 24 bits per pixel could be much
>     better
>     > allocated.
>
>     I kind of agree with both points, but I guess the format is what
>     it is.
>
>     I don't think it's supposed to be a general-purpose storage
>     format. It's
>     encoding just enough data to do good enough real-time visualization of
>     elevation, like hillshading or hypsometric tints, client side.
>
>     Looks like at least rio-rgbify [1] allows setting a custom base value
>     and interval. That might be something we want to emulate as well,
>     perhaps as creation options (if a raster format driver) or command
>     line
>     options (if part of gdaldem).
>
>     - Lars
>
>     [1] https://github.com/mapbox/rio-rgbify
>
>     _______________________________________________
>     gdal-dev mailing list
>     gdal-dev at lists.osgeo.org
>     https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
> --
> Andrey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260108/87f80f7d/attachment-0001.htm>

From j1 at jimenezshaw.com  Thu Jan  8 02:20:25 2026
From: j1 at jimenezshaw.com (Javier Jimenez Shaw)
Date: Thu, 8 Jan 2026 11:20:25 +0100
Subject: [gdal-dev] Support for Terrain-RGB
In-Reply-To: <7de562a8-97c2-4f36-922c-df105255f63f@ahlzen.com>
References: <35be044e-0232-4cd0-90f8-a6a5394333c5@ahlzen.com>
 <199025618490178560.0.v2@titan.email>
 <d9eee51e-328a-4472-90cf-542fb246f662@ahlzen.com>
 <1767688854.62600921@f191.i.mail.ru>
 <7de562a8-97c2-4f36-922c-df105255f63f@ahlzen.com>
Message-ID: <CADRrdKsJzm03EceocVv271rEaXWxXueTHXtu9sN-6afeU8D-FA@mail.gmail.com>

Hi

Independently of the convenience of making a new driver or adding it to
gdaldem, I am curious about the initial question:

Perhaps the same thing could also be achieved using the
raster calculator (gdal_calc), but that seems far from trivial for most
users.

Is it easy to use a formula to read it? Via a virtual file? Or the new CLI
commands?

Thanks.

On Thu, 8 Jan 2026 at 11:05, Lars Ahlzen via gdal-dev <
gdal-dev at lists.osgeo.org> wrote:

> Good points.
>
> Given these and other comments, it sounds to me like we should support
> different RGB raster formats, as the storage format really is independent
> from the encoding. Also, supporting Mapbox Terrain RGB, Terrarium RGB, and
> custom encodings would be desirable. I believe these are all variants of
> the same thing anyway, with a base (offset) and a scale for each of the R,
> G and B channels.
>
> Even, you probably know GDAL internals quite well, what are your thoughts?
> If we were to support arbitrary RGB raster formats, would an implementation
> elsewhere (like gdaldem) be more suitable than a new raster driver, or
> could a raster driver support different actual file formats?
>
> If the latter, could the existing MBTiles driver be used for direct DEM ->
> RGB tiles (.png/.webp/...) -> .mbtiles generation?
>
> - Lars
> On 06/01/2026 08:40, Andrey VI wrote:
>
> Hi all.
>
> It would be great to have RGB DEM support in GDAL.
>
> Some considerations.
> 1. It makes sense to add support not only for Mapbox Terrain RGB, but also
> for Mapzen Terrarium RGB [1][2] encoding. Mapbox and Maplibre support both
> encodings, the latter also supports custom encoding [3][4]. Therefore,
> support for custom encoding will also be useful.
>
> 2. I don't quite understand why only PNG format is being discussed
> here. It is possible to encode a DEM into any raster RGB image
> format. Moreover, PNG isn't the most optimal of them [5]. In my opinion,
> the WEBP format is preferable. For example, Maptiler uses it for Terrain
> RGB and Ocean RGB datasets [6].
>
> 3. Ideally, the output should be not just an encoded image, but tiles
> ready for use in Mapbox/Maplibre/etc., including in the form of data sets
> (MBTiles, PMTiles).
>
>
> [1] https://www.mapzen.com/blog/terrain-tile-service/
> [2] https://github.com/tilezen/joerd/blob/master/docs/formats.md#terrarium
> [3]
> https://docs.mapbox.com/style-spec/reference/sources/#raster-dem-encoding
> [4] https://maplibre.org/maplibre-style-spec/sources/#encoding_1
> [5]
> https://medium.com/@frederic.rodrigo/optimization-of-rgb-dem-tiles-for-dynamic-hill-shading-with-mapbox-gl-or-maplibre-gl-55bef8eb3d86
> [6] https://www.maptiler.com/on-prem-datasets/dataset/terrain-rgb/
> <https://www.maptiler.com/on-prem-datasets/dataset/terrain-rgb/#0.22/0/0>
>
>
> Tuesday, January 6, 2026 0:46 AM +03:00 from Lars Ahlzen via gdal-dev <
> gdal-dev at lists.osgeo.org>:
>
> On 05/01/2026 19:47, rayg wrote:
> > Strange encoding, -10000 meters isn't deep enough for the Marianas
> > Trench. You could borrow another 10 km from the 1.6 million meters
> > still available on the positive side.
> >
> > Scaling by 0.1 also means a 10 cm vertical resolution., which is
> > useless for some use cases. The 24 bits per pixel could be much better
> > allocated.
>
> I kind of agree with both points, but I guess the format is what it is.
>
> I don't think it's supposed to be a general-purpose storage format. It's
> encoding just enough data to do good enough real-time visualization of
> elevation, like hillshading or hypsometric tints, client side.
>
> Looks like at least rio-rgbify [1] allows setting a custom base value
> and interval. That might be something we want to emulate as well,
> perhaps as creation options (if a raster format driver) or command line
> options (if part of gdaldem).
>
> - Lars
>
> [1] https://github.com/mapbox/rio-rgbify
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
> --
> Andrey
>
> _______________________________________________
> 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: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260108/7eba30a3/attachment.htm>

From jukka.rahkonen at maanmittauslaitos.fi  Thu Jan  8 03:50:25 2026
From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka)
Date: Thu, 8 Jan 2026 11:50:25 +0000
Subject: [gdal-dev] Support for Terrain-RGB
In-Reply-To: <CADRrdKsJzm03EceocVv271rEaXWxXueTHXtu9sN-6afeU8D-FA@mail.gmail.com>
References: <35be044e-0232-4cd0-90f8-a6a5394333c5@ahlzen.com>
 <199025618490178560.0.v2@titan.email>
 <d9eee51e-328a-4472-90cf-542fb246f662@ahlzen.com>
 <1767688854.62600921@f191.i.mail.ru>
 <7de562a8-97c2-4f36-922c-df105255f63f@ahlzen.com>
 <CADRrdKsJzm03EceocVv271rEaXWxXueTHXtu9sN-6afeU8D-FA@mail.gmail.com>
Message-ID: <PA3PR09MB82584FEED82C7F314D266B5DFD85A@PA3PR09MB8258.eurprd09.prod.outlook.com>

Hi Javier,

For me VRT with pixel functions  https://gdal.org/en/stable/drivers/raster/vrt.html#derived-bands-pixel-functions feels somehow natural. Now just waiting for someone to show a working example.

Reading the RGB encoded values back to meaningful values would require also metadata about the applied formula if people are willing to use several different/arbitrary  encoding schemas.

-Jukka Rahkonen-

________________________________________
L?hett?j?: gdal-dev <gdal-dev-bounces at lists.osgeo.org> k?ytt?j?n Javier Jimenez Shaw via gdal-dev <gdal-dev at lists.osgeo.org> puolesta
L?hetetty: Torstai 8. tammikuuta 2026 12.20
Vastaanottaja: Lars Ahlzen <lars at ahlzen.com>
Kopio: gdal-dev <gdal-dev at lists.osgeo.org>
Aihe: Re: [gdal-dev] Support for Terrain-RGB

HiIndependently of the convenience of making a new driver or adding it to gdaldem, I am curious about the initial question:Perhaps the same thing could also be achieved using the 
raster calculator (gdal_calc), but that seems far from trivial for most 
users.Is it easy to use a formula to read it? Via a virtual file? Or the new CLI commands?Thanks.On Thu, 8 Jan 2026 at 11:05, Lars Ahlzen via gdal-dev <gdal-dev at lists.osgeo.org> wrote:Good points.Given these and other comments, it sounds to me like we should support different RGB raster formats, as the storage format really is independent from the encoding. Also, supporting Mapbox Terrain RGB, Terrarium RGB, and custom encodings would be desirable. I believe these are all variants of the same thing anyway, with a base (offset) and a scale for each of the R, G and B channels.Even, you probably know GDAL internals quite well, what are your thoughts? If we were to support arbitrary RGB raster formats, would an implementation elsewhere (like gdaldem) be more suitable than a new raster driver, or could a raster driver support different actual file formats?If the latter, could the existing MBTiles driver be used for direct DEM -> RGB tiles (.png/.webp/...) -> .mbtiles generation?- LarsOn 06/01/2026 08:40, Andrey VI wrote:Hi all.It would be great to have RGB DEM support in GDAL.?Some considerations.1.?It makes sense to add support not only for Mapbox Terrain?RGB, but also for Mapzen Terrarium RGB [1][2]?encoding. Mapbox and Maplibre support both encodings, the latter also supports custom encoding [3][4]. Therefore, support for custom encoding will also be useful.?2.?I don't quite understand why only PNG format is being discussed here.?It is possible to encode a DEM into any raster RGB image format.?Moreover, PNG isn't the most optimal of them [5]. In my opinion, the WEBP format is preferable. For example, Maptiler uses it for Terrain RGB and Ocean RGB datasets [6].?3. Ideally, the output should be not just an encoded image, but tiles ready for use in Mapbox/Maplibre/etc., including in the form of data sets (MBTiles, PMTiles).??[1]?https://www.mapzen.com/blog/terrain-tile-service/[2]?https://github.com/tilezen/joerd/blob/master/docs/formats.md#terrarium[3]?https://docs.mapbox.com/style-spec/reference/sources/#raster-dem-encoding[4]?https://maplibre.org/maplibre-style-spec/sources/#encoding_1[5]?https://medium.com/@frederic.rodrigo/optimization-of-rgb-dem-tiles-for-dynamic-hill-shading-with-mapbox-gl-or-maplibre-gl-55bef8eb3d86[6]?https://www.maptiler.com/on-prem-datasets/dataset/terrain-rgb/?Tuesday, January 6, 2026 0:46 AM +03:00 from Lars Ahlzen via gdal-dev <gdal-dev at lists.osgeo.org>:? On 05/01/2026 19:47, rayg wrote:> Strange encoding, -10000 meters isn't deep enough for the Marianas> Trench. You could borrow another 10 km from the 1.6 million meters> still available on the positive side.>> Scaling by 0.1 also means a 10 cm vertical resolution., which is> useless for some use cases. The 24 bits per pixel could be much better> allocated.I kind of agree with both points, but I guess the format is what it is.I don't think it's supposed to be a general-purpose storage format. It'sencoding just enough data to do good enough real-time visualization ofelevation, like hillshading or hypsometric tints, client side.Looks like at least rio-rgbify [1] allows setting a custom base valueand interval. That might be something we want to emulate as well,perhaps as creation options (if a raster format driver) or command lineoptions (if part of gdaldem).- Lars[1] https://github.com/mapbox/rio-rgbify_______________________________________________gdal-dev mailing listgdal-dev at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev--Andrey_______________________________________________gdal-dev mailing listgdal-dev at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev

From even.rouault at spatialys.com  Thu Jan  8 05:55:52 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Thu, 8 Jan 2026 14:55:52 +0100
Subject: [gdal-dev] Support for Terrain-RGB
In-Reply-To: <7de562a8-97c2-4f36-922c-df105255f63f@ahlzen.com>
References: <35be044e-0232-4cd0-90f8-a6a5394333c5@ahlzen.com>
 <199025618490178560.0.v2@titan.email>
 <d9eee51e-328a-4472-90cf-542fb246f662@ahlzen.com>
 <1767688854.62600921@f191.i.mail.ru>
 <7de562a8-97c2-4f36-922c-df105255f63f@ahlzen.com>
Message-ID: <673387c0-307c-40aa-9903-131480556594@spatialys.com>

Hum, if there are different underlying formats, then the situation is 
not all that clear to me.

Both options would be reasonable

- as a driver:

gdal raster convert dem.tif rgbterrain.png --of terrainrgb --co 
OFFSET=-10000 --co SCALE=0.1? [--co DRIVER=PNG]

- or a gdal CLI command:

gdal raster terrainrgb?dem.tif rgbterrain.png --offset=-10000 
--scale=0.1 [--driver PNG]

Perhaps the latter is slightly preferable ?? I've some doubts about the 
naming of the command though. There is a risk that "terrainrgb" would 
make users?believe it does what "gdal raster color-map --color-map" 
does, that is create an hypsometric rendering of a DEM.? "encode-as-rgb" 
maybe ?

Le 08/01/2026 ? 11:05, Lars Ahlzen a ?crit?:
>
> Good points.
>
> Given these and other comments, it sounds to me like we should support 
> different RGB raster formats, as the storage format really is 
> independent from the encoding. Also, supporting Mapbox Terrain RGB, 
> Terrarium RGB, and custom encodings would be desirable. I believe 
> these are all variants of the same thing anyway, with a base (offset) 
> and a scale for each of the R, G and B channels.
>
> Even, you probably know GDAL internals quite well, what are your 
> thoughts? If we were to support arbitrary RGB raster formats, would an 
> implementation elsewhere (like gdaldem) be more suitable than a new 
> raster driver, or could a raster driver support different actual file 
> formats?
>
> If the latter, could the existing MBTiles driver be used for direct 
> DEM -> RGB tiles (.png/.webp/...) -> .mbtiles generation?
>
> - Lars
>
> On 06/01/2026 08:40, Andrey VI wrote:
>> Hi all.
>>
>> It would be great to have RGB DEM support in GDAL.
>> Some considerations.
>> 1.?It makes sense to add support not only for Mapbox Terrain?RGB, but 
>> also for Mapzen Terrarium RGB [1][2]?encoding. Mapbox and Maplibre 
>> support both encodings, the latter also supports custom encoding 
>> [3][4]. Therefore, support for custom encoding will also be useful.
>> 2. I don't quite understand why only PNG format is being discussed 
>> here.?It is possible to encode a DEM into any raster RGB image 
>> format.?Moreover, PNG isn't the most optimal of them [5]. In my 
>> opinion, the WEBP format is preferable. For example, Maptiler uses it 
>> for Terrain RGB and Ocean RGB datasets [6].
>> 3. Ideally, the output should be not just an encoded image, but tiles 
>> ready for use in Mapbox/Maplibre/etc., including in the form of data 
>> sets (MBTiles, PMTiles).
>> [1] https://www.mapzen.com/blog/terrain-tile-service/
>> [2] 
>> https://github.com/tilezen/joerd/blob/master/docs/formats.md#terrarium
>> [3] 
>> https://docs.mapbox.com/style-spec/reference/sources/#raster-dem-encoding
>> [4] https://maplibre.org/maplibre-style-spec/sources/#encoding_1
>> [5] 
>> https://medium.com/@frederic.rodrigo/optimization-of-rgb-dem-tiles-for-dynamic-hill-shading-with-mapbox-gl-or-maplibre-gl-55bef8eb3d86
>> [6] https://www.maptiler.com/on-prem-datasets/dataset/terrain-rgb/ 
>> <https://www.maptiler.com/on-prem-datasets/dataset/terrain-rgb/#0.22/0/0>
>>
>>     Tuesday, January 6, 2026 0:46 AM +03:00 from Lars Ahlzen via
>>     gdal-dev <gdal-dev at lists.osgeo.org>:
>>     On 05/01/2026 19:47, rayg wrote:
>>     > Strange encoding, -10000 meters isn't deep enough for the Marianas
>>     > Trench. You could borrow another 10 km from the 1.6 million meters
>>     > still available on the positive side.
>>     >
>>     > Scaling by 0.1 also means a 10 cm vertical resolution., which is
>>     > useless for some use cases. The 24 bits per pixel could be much
>>     better
>>     > allocated.
>>
>>     I kind of agree with both points, but I guess the format is what
>>     it is.
>>
>>     I don't think it's supposed to be a general-purpose storage
>>     format. It's
>>     encoding just enough data to do good enough real-time
>>     visualization of
>>     elevation, like hillshading or hypsometric tints, client side.
>>
>>     Looks like at least rio-rgbify [1] allows setting a custom base value
>>     and interval. That might be something we want to emulate as well,
>>     perhaps as creation options (if a raster format driver) or
>>     command line
>>     options (if part of gdaldem).
>>
>>     - Lars
>>
>>     [1] https://github.com/mapbox/rio-rgbify
>>
>>     _______________________________________________
>>     gdal-dev mailing list
>>     gdal-dev at lists.osgeo.org
>>     https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>>
>> --
>> Andrey

-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260108/2994bf5f/attachment.htm>

From ftrastour at gmail.com  Thu Jan  8 06:19:00 2026
From: ftrastour at gmail.com (=?UTF-8?Q?Fr=C3=A9d=C3=A9ric_Trastour?=)
Date: Thu, 8 Jan 2026 15:19:00 +0100
Subject: [gdal-dev] Support for Terrain-RGB
In-Reply-To: <673387c0-307c-40aa-9903-131480556594@spatialys.com>
References: <35be044e-0232-4cd0-90f8-a6a5394333c5@ahlzen.com>
 <199025618490178560.0.v2@titan.email>
 <d9eee51e-328a-4472-90cf-542fb246f662@ahlzen.com>
 <1767688854.62600921@f191.i.mail.ru>
 <7de562a8-97c2-4f36-922c-df105255f63f@ahlzen.com>
 <673387c0-307c-40aa-9903-131480556594@spatialys.com>
Message-ID: <CAEL9=c=OOoM1zygUJW9KRpE0WC-9SDfhopcNwxThJb29dgq=tA@mail.gmail.com>

Hi,
in the case of the driver solution, it could be used with gdal2tiles which
is probably the next step of a RGB Terrain conversion.
Regards,
Fred.

Le jeu. 8 janv. 2026 ? 14:56, Even Rouault via gdal-dev <
gdal-dev at lists.osgeo.org> a ?crit :

> Hum, if there are different underlying formats, then the situation is not
> all that clear to me.
>
> Both options would be reasonable
>
> - as a driver:
>
> gdal raster convert dem.tif rgbterrain.png --of terrainrgb --co
> OFFSET=-10000 --co SCALE=0.1  [--co DRIVER=PNG]
>
> - or a gdal CLI command:
>
> gdal raster terrainrgb dem.tif rgbterrain.png --offset=-10000 --scale=0.1
> [--driver PNG]
>
> Perhaps the latter is slightly preferable ?  I've some doubts about the
> naming of the command though. There is a risk that "terrainrgb" would make
> users believe it does what "gdal raster color-map --color-map" does, that
> is create an hypsometric rendering of a DEM.  "encode-as-rgb" maybe ?
> Le 08/01/2026 ? 11:05, Lars Ahlzen a ?crit :
>
> Good points.
>
> Given these and other comments, it sounds to me like we should support
> different RGB raster formats, as the storage format really is independent
> from the encoding. Also, supporting Mapbox Terrain RGB, Terrarium RGB, and
> custom encodings would be desirable. I believe these are all variants of
> the same thing anyway, with a base (offset) and a scale for each of the R,
> G and B channels.
>
> Even, you probably know GDAL internals quite well, what are your thoughts?
> If we were to support arbitrary RGB raster formats, would an implementation
> elsewhere (like gdaldem) be more suitable than a new raster driver, or
> could a raster driver support different actual file formats?
>
> If the latter, could the existing MBTiles driver be used for direct DEM ->
> RGB tiles (.png/.webp/...) -> .mbtiles generation?
>
> - Lars
> On 06/01/2026 08:40, Andrey VI wrote:
>
> Hi all.
>
> It would be great to have RGB DEM support in GDAL.
>
> Some considerations.
> 1. It makes sense to add support not only for Mapbox Terrain RGB, but also
> for Mapzen Terrarium RGB [1][2] encoding. Mapbox and Maplibre support both
> encodings, the latter also supports custom encoding [3][4]. Therefore,
> support for custom encoding will also be useful.
>
> 2. I don't quite understand why only PNG format is being discussed
> here. It is possible to encode a DEM into any raster RGB image
> format. Moreover, PNG isn't the most optimal of them [5]. In my opinion,
> the WEBP format is preferable. For example, Maptiler uses it for Terrain
> RGB and Ocean RGB datasets [6].
>
> 3. Ideally, the output should be not just an encoded image, but tiles
> ready for use in Mapbox/Maplibre/etc., including in the form of data sets
> (MBTiles, PMTiles).
>
>
> [1] https://www.mapzen.com/blog/terrain-tile-service/
> [2] https://github.com/tilezen/joerd/blob/master/docs/formats.md#terrarium
> [3]
> https://docs.mapbox.com/style-spec/reference/sources/#raster-dem-encoding
> [4] https://maplibre.org/maplibre-style-spec/sources/#encoding_1
> [5]
> https://medium.com/@frederic.rodrigo/optimization-of-rgb-dem-tiles-for-dynamic-hill-shading-with-mapbox-gl-or-maplibre-gl-55bef8eb3d86
> [6] https://www.maptiler.com/on-prem-datasets/dataset/terrain-rgb/
> <https://www.maptiler.com/on-prem-datasets/dataset/terrain-rgb/#0.22/0/0>
>
>
> Tuesday, January 6, 2026 0:46 AM +03:00 from Lars Ahlzen via gdal-dev <
> gdal-dev at lists.osgeo.org>:
>
> On 05/01/2026 19:47, rayg wrote:
> > Strange encoding, -10000 meters isn't deep enough for the Marianas
> > Trench. You could borrow another 10 km from the 1.6 million meters
> > still available on the positive side.
> >
> > Scaling by 0.1 also means a 10 cm vertical resolution., which is
> > useless for some use cases. The 24 bits per pixel could be much better
> > allocated.
>
> I kind of agree with both points, but I guess the format is what it is.
>
> I don't think it's supposed to be a general-purpose storage format. It's
> encoding just enough data to do good enough real-time visualization of
> elevation, like hillshading or hypsometric tints, client side.
>
> Looks like at least rio-rgbify [1] allows setting a custom base value
> and interval. That might be something we want to emulate as well,
> perhaps as creation options (if a raster format driver) or command line
> options (if part of gdaldem).
>
> - Lars
>
> [1] https://github.com/mapbox/rio-rgbify
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
> --
> Andrey
>
> -- 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: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260108/bf5c3d7e/attachment-0001.htm>

From gcpp.kalxas at gmail.com  Thu Jan  8 07:34:20 2026
From: gcpp.kalxas at gmail.com (Angelos Tzotsos)
Date: Thu, 8 Jan 2026 17:34:20 +0200
Subject: [gdal-dev] Fwd: OGC Compliance Renewal Notification - 30 Day
 Expiration Notice
In-Reply-To: <963d3e39-9d57-4313-a1c9-fde32b47a8aa@gmail.com>
References: <1765361161.695827.236279.nullmailer@tic.ogc.org>
 <c2a46fb8-bca8-4c2b-aca1-0d5273c31bbb@gmail.com>
 <963d3e39-9d57-4313-a1c9-fde32b47a8aa@gmail.com>
Message-ID: <8edf1a4b-1688-428f-b9b3-71204aa02eb9@gmail.com>

Hi all,

The compliance submission has been completed.
We are waiting for feedback from OGC.

Best,
Angelos

On 1/4/26 16:36, Angelos Tzotsos wrote:
> Happy New Year!
>
> I have prepared the new compliance submission including CITE tests 
> from pycsw, GeoServer and pygeoapi.
> I have kept MapServer and GDAL listed, as last year.
> Should I wait for new tests or should I continue with submission?
>
> Best regards,
> Angelos
>
> On 12/10/25 14:57, Angelos Tzotsos wrote:
>> Dear all,
>>
>> Please prepare your OGC CITE tests and let us know by the end of the 
>> month so we can prepare the submission.
>>
>> Best regards,
>> Angelos
>>
>>
>> -------- Forwarded Message --------
>> Subject:???? OGC Compliance Renewal Notification - 30 Day Expiration 
>> Notice
>> Date:???? Wed, 10 Dec 2025 10:06:01 +0000
>> From:???? compliance at ogc.org
>> Reply-To:???? compliance at ogc.org
>> To:???? info at osgeo.org
>> CC:???? Angelos Tzotsos <tzotsos at osgeo.org>, Michael Smith 
>> <info at osgeo.org>, Even Roualt <even.rouault at spatialys.com>
>>
>>
>>
>> ?Open Source Geospatial Foundation (OSGeo)
>>
>> This is an automated email to inform you that your OGC-certified 
>> compliance license(s) for the following products are due to be 
>> renewed by *January 9th, 2026*. After that date, your products will 
>> no longer be listed as certified OGC compliant and you may not claim 
>> that they are compliant.
>>
>> Since you have reference implementations in your listings please be 
>> aware of the following:
>>
>> ?* You need to retest if you want to continue being listed as a
>> ?? reference implementation.
>> ?* If you want to provide a new version as a reference implementation
>> ?? you need to test that new version. The older version will no longer
>> ?? hold the status of reference implementations.
>> ?* If you want to continue displaying the certification for the older
>> ?? version of your product, then you will be required to pay for the
>> ?? certification.
>>
>> If you have already received an earlier notice and have started the 
>> renewal process please ignore this message.
>>
>> We invite you to easily renew online in our implementation portal: 
>> https://www.ogc.org/resource/products/registration
>>
>> As a reminder, the account used to manage your certification listings 
>> is: *osgeo (info at osgeo.org)*
>>
>> If you have any questions please send an email to compliance at ogc.org. 
>> The OGC compliance team will be more than glad to help you.
>>
>> ------------------------------------------------------------------------
>>
>>
>> ?? Current OGC-Compliant Listings
>>
>>
>> ???? GDAL/OGR 3.10
>>
>> Specification(s)???? Original Certification
>> OGC GeoTIFF Standard 1.1
>> (OGC Reference Implementation)???? 2025-01-10
>> OGC KML 2.2.0
>> (OGC Reference Implementation)???? 2025-01-10
>> OGC KML (Level 2) 2.2.0
>> (OGC Reference Implementation)???? 2025-01-10
>> OGC KML (Level 3) 2.2.0
>> (OGC Reference Implementation)???? 2025-01-10
>> OGC? GeoPackage Encoding Standard 1.2
>> (OGC Reference Implementation)???? 2025-01-10
>> OGC? GeoPackage Encoding Standard: Extension Mechanism 1.2
>> (OGC Reference Implementation)???? 2025-01-10
>> OGC? GeoPackage Encoding Standard: Features 1.2
>> (OGC Reference Implementation)???? 2025-01-10
>> OGC? GeoPackage Encoding Standard: Metadata 1.2
>> (OGC Reference Implementation)???? 2025-01-10
>> OGC? GeoPackage Encoding Standard: RTree Spatial Indexes 1.2
>> (OGC Reference Implementation)???? 2025-01-10
>> OGC? GML in JPEG 2000 (GMLJP2) Encoding Standard Part 1: Core 2.0
>> (OGC Reference Implementation)???? 2025-01-10
>>
>>
>> ???? GeoServer 2.27
>>
>> Specification(s)???? Original Certification
>> OGC API - Features - Part 1: Core 1.0???? 2025-07-10
>> OGC API - Features - Part 2: Coordinate Reference Systems by 
>> Reference 1.0???? 2025-07-10
>> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard 1.0
>> (OGC Reference Implementation)???? 2025-07-10
>> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Acquisition 
>> Information 1.0
>> (OGC Reference Implementation)???? 2025-07-10
>> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Acquisition 
>> Parameters 1.0
>> (OGC Reference Implementation)???? 2025-07-10
>> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Data 
>> Identification 1.0
>> (OGC Reference Implementation)???? 2025-07-10
>> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Earth 
>> Observation 1.0
>> (OGC Reference Implementation)???? 2025-07-10
>> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Earth 
>> Observation Collection 1.0
>> (OGC Reference Implementation)???? 2025-07-10
>> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Geometry 1.0
>> (OGC Reference Implementation)???? 2025-07-10
>> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Links 1.0
>> (OGC Reference Implementation)???? 2025-07-10
>> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Metadata 
>> Information 1.0
>> (OGC Reference Implementation)???? 2025-07-10
>> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Offering 1.0
>> (OGC Reference Implementation)???? 2025-07-10
>> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Product 
>> Information 1.0
>> (OGC Reference Implementation)???? 2025-07-10
>> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Properties 1.0
>> (OGC Reference Implementation)???? 2025-07-10
>> OGC GeoTIFF Standard 1.1
>> (OGC Reference Implementation)???? 2025-07-10
>> OGC? GeoPackage Encoding Standard 1.2
>> (OGC Reference Implementation)???? 2025-07-10
>> OGC? GeoPackage Encoding Standard: Extension Mechanism 1.2
>> (OGC Reference Implementation)???? 2025-07-10
>> OGC? GeoPackage Encoding Standard: Features 1.2
>> (OGC Reference Implementation)???? 2025-07-10
>> OGC? GeoPackage Encoding Standard: Metadata 1.2
>> (OGC Reference Implementation)???? 2025-07-10
>> OGC? GeoPackage Encoding Standard: RTree Spatial Indexes 1.2
>> (OGC Reference Implementation)???? 2025-07-10
>> OGC? GeoPackage Encoding Standard: Schema 1.2
>> (OGC Reference Implementation)???? 2025-07-10
>> OGC? WCS 2.0 Interface Standard- Core: Corrigendum 2.0.1
>> (OGC Reference Implementation)???? 2025-07-10
>> OGC? Web Coverage Service Interface Standard - Interpolation 
>> Extension 1.0
>> (OGC Reference Implementation)???? 2025-07-10
>> OGC? Web Coverage Service Interface Standard - Scaling Extension 1.0
>> (OGC Reference Implementation)???? 2025-07-10
>> OGC? Web Coverage Service Interface Standard - CRS Extension 1.0
>> (OGC Reference Implementation)???? 2025-07-10
>> OGC? Web Coverage Service Interface Standard - Range Subsetting 
>> Extension 1.0
>> (OGC Reference Implementation)???? 2025-07-10
>> OpenGIS Web Coverage Service (WCS) Implementation Specification 
>> (Corrigendum) 1.0.0
>> (OGC Reference Implementation)???? 2025-07-10
>> OpenGIS Web Coverage Service (WCS) Implementation Specification 
>> Corrigendum 1 1.1.1
>> (OGC Reference Implementation)???? 2025-07-10
>> OpenGIS Web Feature Service (WFS) Implementation Specification 1.1.0 
>> 2025-07-10
>> OpenGIS Web Feature Service (WFS) Implementation Specification 
>> (Basic) 1.1.0???? 2025-07-10
>> OpenGIS Web Feature Service (WFS) Implementation Specification 
>> (Transactional) 1.1.0???? 2025-07-10
>> OpenGIS Web Feature Service - Basic 2.0???? 2025-07-10
>> OpenGIS Web Feature Service - Locking 2.0???? 2025-07-10
>> OpenGIS Web Feature Service - Transactional 2.0???? 2025-07-10
>> OpenGIS Web Feature Service 2.0 Interface Standard (also ISO 19142) 
>> 2.0 2025-07-10
>> OpenGIS Web Map Service (WMS) Implementation Specification 1.3.0 
>> 2025-07-10
>> OpenGIS Web Map Tile Service Implementation Standard 1.0.0 2025-07-10
>> Web Feature Service 1.0.0
>> (OGC Reference Implementation)???? 2025-07-10
>> Web Feature Service (Transactional) 1.0.0
>> (OGC Reference Implementation)???? 2025-07-10
>> Web Map Service 1.1.1???? 2025-07-10
>>
>>
>> ???? istSOS 2.3.1
>>
>> Specification(s)???? Original Certification
>> OpenGIS Sensor Observation Service 1.0.0
>> (OGC Reference Implementation)???? 2018-01-09
>>
>>
>> ???? pycsw 2.6.0
>>
>> Specification(s)???? Original Certification
>> OGC GeoRSS Encoding Standard 1.0
>> (OGC Reference Implementation)???? 2022-04-28
>> OGC? Catalogue Services 3.0 Specification - HTTP Protocol Binding 3.0
>> (OGC Reference Implementation)???? 2021-01-09
>> OGC? Catalogue Services 3.0 Specification - HTTP Protocol Binding 
>> (OpenSearch) 3.0
>> (OGC Reference Implementation)???? 2021-01-09
>> OpenGIS Catalogue Service Implementation Specification 2.0.2
>> (OGC Reference Implementation)???? 2021-01-09
>> OpenGIS Catalogue Service Implementation Specification [Catalogue 
>> Service for the Web] 2.0.2
>> (OGC Reference Implementation)???? 2021-01-09
>>
>>
>> ???? pygeoapi 0.19.0
>>
>> Specification(s)???? Original Certification
>> OGC API - Environmental Data Retrieval Standard 1.0.1
>> (OGC Reference Implementation)???? 2025-01-10
>> OGC API - Environmental Data Retrieval Standard: Collections 1.0.1
>> (OGC Reference Implementation)???? 2025-01-10
>> OGC API - Environmental Data Retrieval Standard: CoverageJSON 1.0.1
>> (OGC Reference Implementation)???? 2025-01-10
>> OGC API - Environmental Data Retrieval Standard: EDRGeoJSON 1.0.1
>> (OGC Reference Implementation)???? 2025-01-10
>> OGC API - Environmental Data Retrieval Standard: GeoJSON 1.0.1
>> (OGC Reference Implementation)???? 2025-01-10
>> OGC API - Environmental Data Retrieval Standard: HTML 1.0.1
>> (OGC Reference Implementation)???? 2025-01-10
>> OGC API - Environmental Data Retrieval Standard: JSON 1.0.1
>> (OGC Reference Implementation)???? 2025-01-10
>> OGC API - Features - Part 1: Core 1.0
>> (OGC Reference Implementation)???? 2025-01-10
>> OGC API - Tiles - Part 1: Core 1.0
>> (OGC Reference Implementation)???? 2025-01-10
>> OGC API - Tiles - Part 1: DatasetTilesets 1.0
>> (OGC Reference Implementation)???? 2025-01-10
>> OGC API - Tiles - Part 1: GeoDataTilesets 1.0
>> (OGC Reference Implementation)???? 2025-01-10
>>
>>
>>
>

-- 
Angelos Tzotsos, PhD
President, Board of Directors
Open Source Geospatial Foundation
https://www.osgeo.org/member/angelos-tzotsos/



From mdsumner at gmail.com  Thu Jan  8 12:51:16 2026
From: mdsumner at gmail.com (Michael Sumner)
Date: Fri, 9 Jan 2026 07:51:16 +1100
Subject: [gdal-dev] Support for Terrain-RGB
In-Reply-To: <CAEL9=c=OOoM1zygUJW9KRpE0WC-9SDfhopcNwxThJb29dgq=tA@mail.gmail.com>
References: <35be044e-0232-4cd0-90f8-a6a5394333c5@ahlzen.com>
 <199025618490178560.0.v2@titan.email>
 <d9eee51e-328a-4472-90cf-542fb246f662@ahlzen.com>
 <1767688854.62600921@f191.i.mail.ru>
 <7de562a8-97c2-4f36-922c-df105255f63f@ahlzen.com>
 <673387c0-307c-40aa-9903-131480556594@spatialys.com>
 <CAEL9=c=OOoM1zygUJW9KRpE0WC-9SDfhopcNwxThJb29dgq=tA@mail.gmail.com>
Message-ID: <CAAcGz994HGa__a8bmAKJrkmSTgOUmrKncy+w+kOcpeguy+KiQw@mail.gmail.com>

>  Perhaps the latter is slightly preferable ?  I've some doubts about the
naming of the command though. There is a risk that "terrainrgb" would make
users believe it does what "gdal raster color-map --color-map" does, that
is create an hypsometric rendering of a DEM.  "encode-as-rgb" maybe ?

Totally agree, drop "terrain" and call it "gdal raster encode-rgb" or
something like that. There's nothing especially terrain (or topography)
about this afaics, and utility seems like the right approach rather than
creating a format variant.

Or is it perhaps a special case of offset/scale compression, like gdal
raster scale but with band splitting  and params rather than range?

Cheers, Mike

On Fri, Jan 9, 2026 at 1:19?AM Fr?d?ric Trastour via gdal-dev <
gdal-dev at lists.osgeo.org> wrote:

> Hi,
> in the case of the driver solution, it could be used with gdal2tiles which
> is probably the next step of a RGB Terrain conversion.
> Regards,
> Fred.
>
> Le jeu. 8 janv. 2026 ? 14:56, Even Rouault via gdal-dev <
> gdal-dev at lists.osgeo.org> a ?crit :
>
>> Hum, if there are different underlying formats, then the situation is not
>> all that clear to me.
>>
>> Both options would be reasonable
>>
>> - as a driver:
>>
>> gdal raster convert dem.tif rgbterrain.png --of terrainrgb --co
>> OFFSET=-10000 --co SCALE=0.1  [--co DRIVER=PNG]
>>
>> - or a gdal CLI command:
>>
>> gdal raster terrainrgb dem.tif rgbterrain.png --offset=-10000 --scale=0.1
>> [--driver PNG]
>>
>> Perhaps the latter is slightly preferable ?  I've some doubts about the
>> naming of the command though. There is a risk that "terrainrgb" would make
>> users believe it does what "gdal raster color-map --color-map" does, that
>> is create an hypsometric rendering of a DEM.  "encode-as-rgb" maybe ?
>> Le 08/01/2026 ? 11:05, Lars Ahlzen a ?crit :
>>
>> Good points.
>>
>> Given these and other comments, it sounds to me like we should support
>> different RGB raster formats, as the storage format really is independent
>> from the encoding. Also, supporting Mapbox Terrain RGB, Terrarium RGB, and
>> custom encodings would be desirable. I believe these are all variants of
>> the same thing anyway, with a base (offset) and a scale for each of the R,
>> G and B channels.
>>
>> Even, you probably know GDAL internals quite well, what are your
>> thoughts? If we were to support arbitrary RGB raster formats, would an
>> implementation elsewhere (like gdaldem) be more suitable than a new raster
>> driver, or could a raster driver support different actual file formats?
>>
>> If the latter, could the existing MBTiles driver be used for direct DEM
>> -> RGB tiles (.png/.webp/...) -> .mbtiles generation?
>>
>> - Lars
>> On 06/01/2026 08:40, Andrey VI wrote:
>>
>> Hi all.
>>
>> It would be great to have RGB DEM support in GDAL.
>>
>> Some considerations.
>> 1. It makes sense to add support not only for Mapbox Terrain RGB, but
>> also for Mapzen Terrarium RGB [1][2] encoding. Mapbox and Maplibre support
>> both encodings, the latter also supports custom encoding [3][4]. Therefore,
>> support for custom encoding will also be useful.
>>
>> 2. I don't quite understand why only PNG format is being discussed
>> here. It is possible to encode a DEM into any raster RGB image
>> format. Moreover, PNG isn't the most optimal of them [5]. In my opinion,
>> the WEBP format is preferable. For example, Maptiler uses it for Terrain
>> RGB and Ocean RGB datasets [6].
>>
>> 3. Ideally, the output should be not just an encoded image, but tiles
>> ready for use in Mapbox/Maplibre/etc., including in the form of data sets
>> (MBTiles, PMTiles).
>>
>>
>> [1] https://www.mapzen.com/blog/terrain-tile-service/
>> [2]
>> https://github.com/tilezen/joerd/blob/master/docs/formats.md#terrarium
>> [3]
>> https://docs.mapbox.com/style-spec/reference/sources/#raster-dem-encoding
>> [4] https://maplibre.org/maplibre-style-spec/sources/#encoding_1
>> [5]
>> https://medium.com/@frederic.rodrigo/optimization-of-rgb-dem-tiles-for-dynamic-hill-shading-with-mapbox-gl-or-maplibre-gl-55bef8eb3d86
>> [6] https://www.maptiler.com/on-prem-datasets/dataset/terrain-rgb/
>> <https://www.maptiler.com/on-prem-datasets/dataset/terrain-rgb/#0.22/0/0>
>>
>>
>> Tuesday, January 6, 2026 0:46 AM +03:00 from Lars Ahlzen via gdal-dev <
>> gdal-dev at lists.osgeo.org>:
>>
>> On 05/01/2026 19:47, rayg wrote:
>> > Strange encoding, -10000 meters isn't deep enough for the Marianas
>> > Trench. You could borrow another 10 km from the 1.6 million meters
>> > still available on the positive side.
>> >
>> > Scaling by 0.1 also means a 10 cm vertical resolution., which is
>> > useless for some use cases. The 24 bits per pixel could be much better
>> > allocated.
>>
>> I kind of agree with both points, but I guess the format is what it is.
>>
>> I don't think it's supposed to be a general-purpose storage format. It's
>> encoding just enough data to do good enough real-time visualization of
>> elevation, like hillshading or hypsometric tints, client side.
>>
>> Looks like at least rio-rgbify [1] allows setting a custom base value
>> and interval. That might be something we want to emulate as well,
>> perhaps as creation options (if a raster format driver) or command line
>> options (if part of gdaldem).
>>
>> - Lars
>>
>> [1] https://github.com/mapbox/rio-rgbify
>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>>
>> --
>> Andrey
>>
>> -- 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
>>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>


-- 
Michael Sumner
Ordinary Member,  Streets People Love Hobart Association
Research Software Engineer
Australian Antarctic Division
Hobart, Australia
0438489030
e-mail: mdsumner at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260109/4938d287/attachment-0001.htm>

From even.rouault at spatialys.com  Thu Jan  8 13:13:23 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Thu, 8 Jan 2026 22:13:23 +0100
Subject: [gdal-dev] Support for Terrain-RGB
In-Reply-To: <CAAcGz994HGa__a8bmAKJrkmSTgOUmrKncy+w+kOcpeguy+KiQw@mail.gmail.com>
References: <35be044e-0232-4cd0-90f8-a6a5394333c5@ahlzen.com>
 <199025618490178560.0.v2@titan.email>
 <d9eee51e-328a-4472-90cf-542fb246f662@ahlzen.com>
 <1767688854.62600921@f191.i.mail.ru>
 <7de562a8-97c2-4f36-922c-df105255f63f@ahlzen.com>
 <673387c0-307c-40aa-9903-131480556594@spatialys.com>
 <CAEL9=c=OOoM1zygUJW9KRpE0WC-9SDfhopcNwxThJb29dgq=tA@mail.gmail.com>
 <CAAcGz994HGa__a8bmAKJrkmSTgOUmrKncy+w+kOcpeguy+KiQw@mail.gmail.com>
Message-ID: <af905f43-69e7-43cf-8e72-1db786df9a45@spatialys.com>

>
> There's nothing especially terrain (or topography) about this afaics, 
> and utility seems like the right approach rather than creating a 
> format variant.

Actually Fr?d?ric's intersting remark abou potential usage with "gdal 
raster tile" would actually make the driver approach a better 
choice....? ?unless we would extend "gdal raster tile" to accept a 
pipeline to go to create a final tile from a 'raw' one, like 'gdal 
raster tile --tile-pipeline="read ! encode-rgb --offset=-10000 ! write 
--of PNG" --extension png? in.tif out_directory' .

But a ENCODE_RGB driver approach is more simple than implementing that.

Even

-- 
http://www.spatialys.com
My software is free, but my time generally not.


From rayg at daylongraphics.com  Thu Jan  8 16:07:02 2026
From: rayg at daylongraphics.com (rayg)
Date: Fri, 9 Jan 2026 00:07:02 +0000 (UTC)
Subject: [gdal-dev] Support for Terrain-RGB
In-Reply-To: <af905f43-69e7-43cf-8e72-1db786df9a45@spatialys.com>
References: <CAEL9=c=OOoM1zygUJW9KRpE0WC-9SDfhopcNwxThJb29dgq=tA@mail.gmail.com>
 <CAAcGz994HGa__a8bmAKJrkmSTgOUmrKncy+w+kOcpeguy+KiQw@mail.gmail.com>
 <af905f43-69e7-43cf-8e72-1db786df9a45@spatialys.com>
 <199313755508833280.0.v2@titan.email>
Message-ID: <199313755508833280.0.v2@titan.email>

An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260109/3bec2798/attachment.htm>

From andrey_vi at list.ru  Thu Jan  8 23:02:07 2026
From: andrey_vi at list.ru (=?UTF-8?B?QW5kcmV5IFZJ?=)
Date: Fri, 09 Jan 2026 10:02:07 +0300
Subject: [gdal-dev] =?utf-8?q?Support_for_Terrain-RGB?=
In-Reply-To: <199313755508833280.0.v2@titan.email>
References: <CAEL9=c=OOoM1zygUJW9KRpE0WC-9SDfhopcNwxThJb29dgq=tA@mail.gmail.com>
 <af905f43-69e7-43cf-8e72-1db786df9a45@spatialys.com>
 <199313755508833280.0.v2@titan.email>
Message-ID: <1767942127.779873340@f314.i.mail.ru>


Why not just "rgb-dem", i.e. "RGB encoded DEM"?

?
>Friday, January 9, 2026 3:16 AM +03:00 from rayg via gdal-dev < gdal-dev at lists.osgeo.org >:
>?
>Maybe call it "scalar-rgb"? Because ultimately what the encoding does is use the color channels to hold a single value. It doesn't even have to be for elevations at all.
>?
>Could also add swizzle options in case BGR or some other order is used. And include the alpha channel just in case, but also let alpha be alpha if needed. If e.g. "A" is left off from the swizzle option, then it's an actual alpha channel.
>?
>More general would be scalar encoding of any multichannel (multiband) file, e.g. YCbCr, HSV, CMYK, etc.
>?
>Ray
>
>
>?
>On Thu, 8 Jan 2026 at 1:13 PM Even wrote:
>>>
>>> There's nothing especially terrain (or topography) about this afaics, 
>>> and utility seems like the right approach rather than creating a 
>>> format variant.
>>
>>Actually Fr?d?ric's intersting remark abou potential usage with "gdal 
>>raster tile" would actually make the driver approach a better 
>>choice....? ?unless we would extend "gdal raster tile" to accept a 
>>pipeline to go to create a final tile from a 'raw' one, like 'gdal 
>>raster tile --tile-pipeline="read ! encode-rgb --offset=-10000 ! write 
>>--of PNG" --extension png? in.tif out_directory' .
>>
>>But a ENCODE_RGB driver approach is more simple than implementing that.
>>
>>Even
>>
>>-- 
>>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
>>
>?
>_______________________________________________
>gdal-dev mailing list
>gdal-dev at lists.osgeo.org
>https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Andrey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260109/6121650f/attachment.htm>

From jukka.rahkonen at maanmittauslaitos.fi  Thu Jan  8 23:54:29 2026
From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka)
Date: Fri, 9 Jan 2026 07:54:29 +0000
Subject: [gdal-dev] Support for Terrain-RGB
In-Reply-To: <1767942127.779873340@f314.i.mail.ru>
References: <CAEL9=c=OOoM1zygUJW9KRpE0WC-9SDfhopcNwxThJb29dgq=tA@mail.gmail.com>
 <af905f43-69e7-43cf-8e72-1db786df9a45@spatialys.com>
 <199313755508833280.0.v2@titan.email> <1767942127.779873340@f314.i.mail.ru>
Message-ID: <PA3PR09MB8258F9494225862B97C7C5B9FD82A@PA3PR09MB8258.eurprd09.prod.outlook.com>

Hi,

The encoding system does not care if the source data presents DEM or something else. Also, it does not need to be restricted to RGB. I tried to find similar use cases and it looks like encoding 32 bit floats into RGBA (or RG for 16 bits) was used with WebGL shaders when floats were not supported natively. See for example https://www.shadertoy.com/view/WsVGzm, https://gamedev.net/forums/topic/630239-encode-float-to-rg-or-rgb/, https://github.com/equinor/glsl-float-to-rgba

-Jukka Rahkonen-

________________________________________
L?hett?j?: gdal-dev <gdal-dev-bounces at lists.osgeo.org> k?ytt?j?n Andrey VI via gdal-dev <gdal-dev at lists.osgeo.org> puolesta
L?hetetty: Perjantai 9. tammikuuta 2026 9.02
Vastaanottaja: rayg <rayg at daylongraphics.com>
Kopio: gdal-dev <gdal-dev at lists.osgeo.org>
Aihe: Re: [gdal-dev] Support for Terrain-RGB

Why not just "rgb-dem", i.e. "RGB encoded DEM"??Friday, January 9, 2026 3:16 AM +03:00 from rayg via gdal-dev <gdal-dev at lists.osgeo.org>:?Maybe call it "scalar-rgb"? Because ultimately what the encoding does is use the color channels to hold a single value. It doesn't even have to be for elevations at all.?Could also add swizzle options in case BGR or some other order is used. And include the alpha channel just in case, but also let alpha be alpha if needed. If e.g. "A" is left off from the swizzle option, then it's an actual alpha channel.?More general would be scalar encoding of any multichannel (multiband) file, e.g. YCbCr, HSV, CMYK, etc.?Ray?On Thu, 8 Jan 2026 at 1:13 PM Even wrote:>
> There's nothing especially terrain (or topography) about this afaics, 
> and utility seems like the right approach rather than creating a 
> format variant.

Actually Fr?d?ric's intersting remark abou potential usage with "gdal 
raster tile" would actually make the driver approach a better 
choice....? ?unless we would extend "gdal raster tile" to accept a 
pipeline to go to create a final tile from a 'raw' one, like 'gdal 
raster tile --tile-pipeline="read ! encode-rgb --offset=-10000 ! write 
--of PNG" --extension png? in.tif out_directory' .

But a ENCODE_RGB driver approach is more simple than implementing that.

Even

-- 
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
[X]?_______________________________________________gdal-dev mailing listgdal-dev at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev--Andrey

From j1 at jimenezshaw.com  Fri Jan  9 13:55:47 2026
From: j1 at jimenezshaw.com (Javier Jimenez Shaw)
Date: Fri, 9 Jan 2026 22:55:47 +0100
Subject: [gdal-dev] cppcheck failures
Message-ID: <CADRrdKtvCgvk-1vjnYF0psVmuOWaumAjuE5W+Yba1vBbRvZ4FQ@mail.gmail.com>

Hi

I just rebased my fork of gdal to master, and a github action is failing
https://github.com/jjimenezshaw/gdal/actions/runs/20820414623/job/59807087520

Is it failing in master? Not here
https://github.com/OSGeo/gdal/actions/runs/20836683748/job/59862686160

How is it happening?

Cheers
Javier.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260109/be964429/attachment.htm>

From even.rouault at spatialys.com  Fri Jan  9 15:08:51 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Sat, 10 Jan 2026 00:08:51 +0100
Subject: [gdal-dev] cppcheck failures
In-Reply-To: <CADRrdKtvCgvk-1vjnYF0psVmuOWaumAjuE5W+Yba1vBbRvZ4FQ@mail.gmail.com>
References: <CADRrdKtvCgvk-1vjnYF0psVmuOWaumAjuE5W+Yba1vBbRvZ4FQ@mail.gmail.com>
Message-ID: <c6b29f64-aa78-442b-ada9-84394cfae616@spatialys.com>

Javier,

are you sure you've resync'ed on top of latest master. The commit fixing 
this dates back to yesterday:

https://github.com/OSGeo/gdal/commit/90e26afd7c38816df3900c68b6952393cc6e4cab

Even

Le 09/01/2026 ? 22:55, Javier Jimenez Shaw via gdal-dev a ?crit?:
> Hi
>
> I just rebased my fork of gdal to master, and a github action is failing
> https://github.com/jjimenezshaw/gdal/actions/runs/20820414623/job/59807087520
>
> Is it failing in master? Not here 
> https://github.com/OSGeo/gdal/actions/runs/20836683748/job/59862686160
>
> How is it happening?
>
> Cheers
> Javier.
>
> _______________________________________________
> 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 j1 at jimenezshaw.com  Fri Jan  9 15:11:13 2026
From: j1 at jimenezshaw.com (Javier Jimenez Shaw)
Date: Sat, 10 Jan 2026 00:11:13 +0100
Subject: [gdal-dev] cppcheck failures
In-Reply-To: <c6b29f64-aa78-442b-ada9-84394cfae616@spatialys.com>
References: <CADRrdKtvCgvk-1vjnYF0psVmuOWaumAjuE5W+Yba1vBbRvZ4FQ@mail.gmail.com>
 <c6b29f64-aa78-442b-ada9-84394cfae616@spatialys.com>
Message-ID: <CADRrdKvNc5D83bvPQ1eyF8kKq9GpY7AUrC1T+pFUKxcEf7mqUA@mail.gmail.com>

Thanks Even

I did rebase yesterday afternoon. A few hours before your fix.

On Sat, 10 Jan 2026 at 00:08, Even Rouault <even.rouault at spatialys.com>
wrote:

> Javier,
>
> are you sure you've resync'ed on top of latest master. The commit fixing
> this dates back to yesterday:
>
>
> https://github.com/OSGeo/gdal/commit/90e26afd7c38816df3900c68b6952393cc6e4cab
>
> Even
>
> Le 09/01/2026 ? 22:55, Javier Jimenez Shaw via gdal-dev a ?crit :
> > Hi
> >
> > I just rebased my fork of gdal to master, and a github action is failing
> >
> https://github.com/jjimenezshaw/gdal/actions/runs/20820414623/job/59807087520
> >
> > Is it failing in master? Not here
> > https://github.com/OSGeo/gdal/actions/runs/20836683748/job/59862686160
> >
> > How is it happening?
> >
> > Cheers
> > Javier.
> >
> > _______________________________________________
> > 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: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260110/33853048/attachment.htm>

From even.rouault at spatialys.com  Fri Jan  9 17:09:27 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Sat, 10 Jan 2026 02:09:27 +0100
Subject: [gdal-dev] Decoding feature blobs and tracking FIDs in MVT
 datasets
In-Reply-To: <6{X.IlfT.2nzmPnhoeMs.1fMdRC@seznam.cz>
References: <6oI.IlON.odzi0Q7Vfj.1f8lUH@seznam.cz>
 <nA.Ilib.5alAPaRWMH7.1fIf9P@seznam.cz>
 <280ce7c5-204e-4fdd-9662-650333ae7b7d@spatialys.com>
 <6{X.IlfT.2nzmPnhoeMs.1fMdRC@seznam.cz>
Message-ID: <b7ae50ed-26c7-4ae6-a019-5eb714189bd3@spatialys.com>

Hi Linda,

Happy New Year

> I?ve put together a short document with the planned implementations 
> [0]. Could you please take a look (or anyone else interested in this 
> topic) and let me know if this seems okay to implement? Part of the 
> work I have already done, but I?d like to make sure it follows GDAL 
> conventions all the way through.

I've read your detailed document. Your plan looks solid. My main remark 
is that when a driver accepts to open a dataset in GDAL_OF_UPDATE mode, 
it is expected that read operations are still available. Failing to do 
that could cause issues for users/software that always open in update 
mode if possible, even if they end up not doing any change. By using 
OGRMVTWriterDataset which is write-only, you wouldn't be able to meet 
that expectation. It could be complicated to extend OGRMVTWriterDataset 
to have read capabilities (especially since the writing side generates 
several zoom levels at once, whereas the reading side has one dataset 
per zoom level), so I would suggest that the update mode you describe is 
triggered by both GDAL_OF_UPDATE and a specific open option like 
EDIT_ONLY=YES / UPDATE_ONLY=YES. Or maybe just the later.

If you plan to implement updates of existing features, implementing 
ISetFeature() only would be sufficient. IUpdateFeature() is reserved for 
drivers that can offer such capability naturally, typically drivers for 
a SQL database.

Even

-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260110/a26e263b/attachment.htm>

From lars at ahlzen.com  Mon Jan 12 05:35:08 2026
From: lars at ahlzen.com (Lars Ahlzen)
Date: Mon, 12 Jan 2026 13:35:08 +0000
Subject: [gdal-dev] Support for Terrain-RGB
In-Reply-To: <1767942127.779873340@f314.i.mail.ru>
References: <CAEL9=c=OOoM1zygUJW9KRpE0WC-9SDfhopcNwxThJb29dgq=tA@mail.gmail.com>
 <af905f43-69e7-43cf-8e72-1db786df9a45@spatialys.com>
 <199313755508833280.0.v2@titan.email> <1767942127.779873340@f314.i.mail.ru>
Message-ID: <b109ff2e-6739-4255-9369-81ca20c59097@ahlzen.com>

I think either "rgb-dem" or "encode-rgb" could work. While not strictly 
limited to RGB or DEMs, at least that's their typical and intended use.

Sounds like a raster driver, rather than a new raster DEM mode, would be 
advantageous. I imagine creation options might include:

- OFFSET (or BASE, as known in the terrain-RGB spec)
Defaults to -10000

- SCALE (or maybe STEP, to not to confuse it with any required scaling 
of the input?)
Defaults to 0.1

- DRIVER
Raster driver to output encoded image, e.g. PNG, WEBP, GTiff. Inferred 
from the output extension if omitted.

- BANDS
Order of raster bands to encode values into, most significant first. 
E.g. "RGB", "RGBA", "BGR", "RG".
Defaults to "RGB". If A is not included in the bands, the A channel can 
be used for alpha.

For ease of use, perhaps an ENCODING option (or similar) could provide 
preset values for the above, such as:

--co ENCODING=TERRAIN_RGB
would be equivalent to
--co OFFSET=-1000 --co SCALE=0.1 --co BANDS=RGB

-co ENCODING=TERRARIUM
would be equivalent to
--co OFFSET=-32768 --co SCALE=0.00390625 --co BANDS=RGB

This driver would allow things like:

 ?gdal raster convert dem.tif rgb.png --of encode-rgb --co DRIVER=PNG 
--co ENCODING=TERRARIUM

 ?gdal raster convert dem.tif rgb.png --of encode-rgb --co DRIVER=PNG 
--co ENCODING=TERRAIN_RGB

 ?gdal raster convert dem.tif rgb.png --of encode-rgb --co DRIVER=PNG 
--co BANDS=RGB --co OFFSET=-10000 --co SCALE=0.1

 ?gdal raster convert dem.tif rgb.png --of encode-rgb --co DRIVER=PNG 
--co BANDS=BG --co OFFSET=-1000 --co SCALE=1

 ?gdal raster tile --min-zoom 5 --max-zoom 15 --format ENCODE_RGB --co 
DRIVER=PNG --co ENCODING=TERRARIUM dem.tif rgb-tiles/

 ?gdal raster tile --min-zoom 5 --max-zoom 15 --format ENCODE_RGB --co 
DRIVER=WEBP --co LOSSLESS=YES --co BANDS=RGB --co OFFSET=-10000 --co 
SCALE=0.1 dem.tif rgb-tiles/

Certain creation options, like LOSSLESS=YES in the last example, may 
need to be passed on from the ENCODE_RGB driver to the actual output 
driver. Is that possible in general, or would it have to be handled as 
special cases for different formats?

- Lars

On 09/01/2026 07:02, Andrey VI via gdal-dev wrote:
> Why not just "rgb-dem", i.e. "RGB encoded DEM"?
>
>     Friday, January 9, 2026 3:16 AM +03:00 from rayg via gdal-dev
>     <gdal-dev at lists.osgeo.org>:
>     Maybe call it "scalar-rgb"? Because ultimately what the encoding
>     does is use the color channels to hold a single value. It doesn't
>     even have to be for elevations at all.
>     Could also add swizzle options in case BGR or some other order is
>     used. And include the alpha channel just in case, but also let
>     alpha be alpha if needed. If e.g. "A" is left off from the swizzle
>     option, then it's an actual alpha channel.
>     More general would be scalar encoding of any multichannel
>     (multiband) file, e.g. YCbCr, HSV, CMYK, etc.
>     Ray
>
>
>     On Thu, 8 Jan 2026 at 1:13 PM Even wrote:
>
>         >
>         > There's nothing especially terrain (or topography) about this afaics, 
>         > and utility seems like the right approach rather than creating a 
>         > format variant.
>
>         Actually Fr?d?ric's intersting remark abou potential usage with "gdal
>         raster tile" would actually make the driver approach a better
>         choice....? ?unless we would extend "gdal raster tile" to accept a
>         pipeline to go to create a final tile from a 'raw' one, like 'gdal
>         raster tile --tile-pipeline="read ! encode-rgb --offset=-10000 ! write
>         --of PNG" --extension png? in.tif out_directory' .
>
>         But a ENCODE_RGB driver approach is more simple than implementing that.
>
>         Even
>
>         -- 
>         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
>
>     _______________________________________________
>     gdal-dev mailing list
>     gdal-dev at lists.osgeo.org
>     https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
> --
> Andrey
>
> _______________________________________________
> 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: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260112/de48c186/attachment-0001.htm>

From even.rouault at spatialys.com  Mon Jan 12 07:17:34 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Mon, 12 Jan 2026 16:17:34 +0100
Subject: [gdal-dev] Support for Terrain-RGB
In-Reply-To: <b109ff2e-6739-4255-9369-81ca20c59097@ahlzen.com>
References: <CAEL9=c=OOoM1zygUJW9KRpE0WC-9SDfhopcNwxThJb29dgq=tA@mail.gmail.com>
 <af905f43-69e7-43cf-8e72-1db786df9a45@spatialys.com>
 <199313755508833280.0.v2@titan.email> <1767942127.779873340@f314.i.mail.ru>
 <b109ff2e-6739-4255-9369-81ca20c59097@ahlzen.com>
Message-ID: <d881bdb0-f87d-403e-b695-43d81da08ad8@spatialys.com>

> Certain creation options, like LOSSLESS=YES in the last example, may 
> need to be passed on from the ENCODE_RGB driver to the actual output 
> driver. Is that possible in general, or would it have to be handled as 
> special cases for different formats?
>
You could require that such driver specific options are prefixed with 
something like DRV_OPT_? and then strip that prefix when sending them to 
the underlying driver

Even


-- 
http://www.spatialys.com
My software is free, but my time generally not.


From jeroen at groenebij.nl  Mon Jan 12 08:06:11 2026
From: jeroen at groenebij.nl (Jeroen Hovens)
Date: Mon, 12 Jan 2026 17:06:11 +0100
Subject: [gdal-dev] ogr2ogr explanations for error XML parsing of GML file
 failed?
Message-ID: <005c01dc83dd$5eeb1cf0$1cc156d0$@groenebij.nl>

Hi,

 

I use QGIS on Windows10 which comes with GDAL. The latest QGIS LTR (3.40.14)
uses GDAL 3.12.1

In QGIS I can open a terminal (browser panel, rightclick a folder and select
Open in Terminal) and immediately use ogr2ogr to convert a WFS to a
geopackage, because QGIS has altered the path to include the GDAL directory

However, with some WFS services ogr2ogr throws an error. I have no trouble
using those WFS services in QGIS.

 

For instance, this one I can't convert:

ogr2ogr -f gpkg test.gpkg
WFS:"https://service.pdok.nl/kadaster/bestuurlijkegebieden/wfs/v1_0?"
Provinciegebied -overwrite -nln provincie_kadaster

But this one I can:

ogr2ogr -f gpkg test2.gpkg WFS:"https://map.data.amsterdam.nl/maps/gebieden"
wijk -overwrite -nln amsterdam_wijk

 

The first WFS is part of a large Dutch open data organization and depending
on which WFS  I choose from them I see two different errors:

ERROR 1: XML parsing of GML file failed : no element found at line 27,
column 31065   (or different numbers)

Or

ERROR 1: XML parsing of GML file failed : unclosed token at line 555, column
9

 

I was able to compare a debug on with someone who was able to convert the
WFS to a gpkg and this part was surely different

VSICURL: Read attempt beyond end of file

VSICURL: Read attempt beyond end of file

 

After this, the error appeared.

 

 

To make things more complicated:

When I open a Windows Prompt (terminal) and set a path to the GDAL directory
in QGIS using set PATH=%PATH%;C:\Program Files\QGIS 3.40.14\bin

I can also use ogr2ogr.

Interestingly, now I can convert both WFS datasets to gpkg.

 

What could be different with the QGIS Terminal setting from a Windows Prompt
setting with the path set that would explain the errors?

What might be different in both WFS services that triggers these errors?

 

 

 

Kind regards,

 

Jeroen Hovens

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260112/99572021/attachment.htm>

From even.rouault at spatialys.com  Mon Jan 12 08:34:18 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Mon, 12 Jan 2026 17:34:18 +0100
Subject: [gdal-dev] ogr2ogr explanations for error XML parsing of GML
 file failed?
In-Reply-To: <005c01dc83dd$5eeb1cf0$1cc156d0$@groenebij.nl>
References: <005c01dc83dd$5eeb1cf0$1cc156d0$@groenebij.nl>
Message-ID: <8ef2c691-1ef1-45df-954f-555dcfab2baf@spatialys.com>

Hi Jeroen,

can you type "set" to list environment variables that are defined, both 
in a terminal from QGIS or the Windows prompt, (possibly redirecting to 
file, like "set > env_vars.txt"), and compare the differences

Even

Le 12/01/2026 ? 17:06, Jeroen Hovens via gdal-dev a ?crit?:
>
> Hi,
>
> I use QGIS on Windows10 which comes with GDAL. The latest QGIS LTR 
> (3.40.14) uses GDAL 3.12.1
>
> In QGIS I can open a terminal (browser panel, rightclick a folder and 
> select Open in Terminal) and immediately use ogr2ogr to convert a WFS 
> to a geopackage, because QGIS has altered the path to include the GDAL 
> directory
>
> However, with some WFS services ogr2ogr throws an error. I have no 
> trouble using those WFS services in QGIS.
>
> For instance, this one I can?t convert:
>
> ogr2ogr -f gpkg test.gpkg 
> WFS:"https://service.pdok.nl/kadaster/bestuurlijkegebieden/wfs/v1_0?" 
> Provinciegebied -overwrite -nln provincie_kadaster
>
> But this one I can:
>
> ogr2ogr -f gpkg test2.gpkg 
> WFS:"https://map.data.amsterdam.nl/maps/gebieden" wijk -overwrite -nln 
> amsterdam_wijk
>
> The first WFS is part of a large Dutch open data organization and 
> depending on which WFS ?I choose from them I see two different errors:
>
> ERROR 1: XML parsing of GML file failed : no element found at line 27, 
> column 31065 ??(or different numbers)
>
> Or
>
> ERROR 1: XML parsing of GML file failed : unclosed token at line 555, 
> column 9
>
> I was able to compare a debug on with someone who was able to convert 
> the WFS to a gpkg and this part was surely different
>
> VSICURL: Read attempt beyond end of file
>
> VSICURL: Read attempt beyond end of file
>
> After this, the error appeared.
>
> To make things more complicated:
>
> When I open a Windows Prompt (terminal) and set a path to the GDAL 
> directory in QGIS using set PATH=%PATH%;C:\Program Files\QGIS 3.40.14\bin
>
> I can also use ogr2ogr.
>
> Interestingly, now I can convert both WFS datasets to gpkg.
>
> What could be different with the QGIS Terminal setting from a Windows 
> Prompt setting with the path set that would explain the errors?
>
> What might be different in both WFS services that triggers these errors?
>
> Kind regards,
>
> Jeroen Hovens
>
>
> _______________________________________________
> 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: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260112/d5510ae7/attachment.htm>

From lars at ahlzen.com  Mon Jan 12 09:06:35 2026
From: lars at ahlzen.com (Lars Ahlzen)
Date: Mon, 12 Jan 2026 17:06:35 +0000
Subject: [gdal-dev] Support for Terrain-RGB
In-Reply-To: <d881bdb0-f87d-403e-b695-43d81da08ad8@spatialys.com>
References: <CAEL9=c=OOoM1zygUJW9KRpE0WC-9SDfhopcNwxThJb29dgq=tA@mail.gmail.com>
 <af905f43-69e7-43cf-8e72-1db786df9a45@spatialys.com>
 <199313755508833280.0.v2@titan.email> <1767942127.779873340@f314.i.mail.ru>
 <b109ff2e-6739-4255-9369-81ca20c59097@ahlzen.com>
 <d881bdb0-f87d-403e-b695-43d81da08ad8@spatialys.com>
Message-ID: <d687cde0-bfaa-4e33-8095-0830bd615b11@ahlzen.com>

On 12/01/2026 15:17, Even Rouault wrote:
>> Certain creation options, like LOSSLESS=YES in the last example, may 
>> need to be passed on from the ENCODE_RGB driver to the actual output 
>> driver. Is that possible in general, or would it have to be handled 
>> as special cases for different formats?
>>
> You could require that such driver specific options are prefixed with 
> something like DRV_OPT_? and then strip that prefix when sending them 
> to the underlying driver 

That's probably the way to go. The last example would then be:

gdal raster tile --min-zoom 5 --max-zoom 15 --format ENCODE_RGB --co 
DRIVER=WEBP --co DRV_OPT_LOSSLESS=YES --co BANDS=RGB --co OFFSET=-10000 
--co SCALE=0.1 dem.tif rgb-tiles/

I can start looking at implementing such a driver. I assume this would 
warrant an RFC?

- Lars



From even.rouault at spatialys.com  Mon Jan 12 09:15:12 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Mon, 12 Jan 2026 18:15:12 +0100
Subject: [gdal-dev] Support for Terrain-RGB
In-Reply-To: <d687cde0-bfaa-4e33-8095-0830bd615b11@ahlzen.com>
References: <CAEL9=c=OOoM1zygUJW9KRpE0WC-9SDfhopcNwxThJb29dgq=tA@mail.gmail.com>
 <af905f43-69e7-43cf-8e72-1db786df9a45@spatialys.com>
 <199313755508833280.0.v2@titan.email> <1767942127.779873340@f314.i.mail.ru>
 <b109ff2e-6739-4255-9369-81ca20c59097@ahlzen.com>
 <d881bdb0-f87d-403e-b695-43d81da08ad8@spatialys.com>
 <d687cde0-bfaa-4e33-8095-0830bd615b11@ahlzen.com>
Message-ID: <6c261ee9-d63a-4130-a489-0d28d12b57f9@spatialys.com>

>
> That's probably the way to go. The last example would then be:
>
> gdal raster tile --min-zoom 5 --max-zoom 15 --format ENCODE_RGB --co 
> DRIVER=WEBP --co DRV_OPT_LOSSLESS=YES --co BANDS=RGB --co 
> OFFSET=-10000 --co SCALE=0.1 dem.tif rgb-tiles/
>
> I can start looking at implementing such a driver. I assume this would 
> warrant an RFC?

Your call, but RFCs are generally used for changes with wide impact in 
the code base. Drivers have generally a localized impact, particularly 
here when they don't introduce new external dependencies. You could also 
for example create a ticket with details of your plan if you want to 
discuss them before starting the coding .


-- 
http://www.spatialys.com
My software is free, but my time generally not.


From even.rouault at spatialys.com  Mon Jan 12 10:07:18 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Mon, 12 Jan 2026 19:07:18 +0100
Subject: [gdal-dev] ogr2ogr explanations for error XML parsing of GML
 file failed?
In-Reply-To: <007e01dc83e4$cf446360$6dcd2a20$@groenebij.nl>
References: <005c01dc83dd$5eeb1cf0$1cc156d0$@groenebij.nl>
 <8ef2c691-1ef1-45df-954f-555dcfab2baf@spatialys.com>
 <007e01dc83e4$cf446360$6dcd2a20$@groenebij.nl>
Message-ID: <e3e53b2e-116e-40e8-a4b9-ffcd48663299@spatialys.com>

ok,

so the issue was related to QGIS setting VSI_CACHE=YES, which triggered 
a bug in /vsicurl_streaming/

So the workaround is that you type "set VSI_CACHE=" in the QGIS console

Proper fix queued in https://github.com/OSGeo/gdal/pull/13690

Even

Le 12/01/2026 ? 17:59, Jeroen Hovens a ?crit?:
>
> Hi Even,
>
> Find attached two txt files.
>
> env_var_winprompt is the normal windows prompt terminal after adding 
> the QGIS bin folder to path
>
> env_var_qgisterminal is the QGIS terminal as is, no changes made
>
> Jeroen
>
> *Van:*Even Rouault <even.rouault at spatialys.com>
> *Verzonden:* maandag 12 januari 2026 17:34
> *Aan:* Jeroen Hovens <jeroen at groenebij.nl>; gdal-dev at lists.osgeo.org
> *Onderwerp:* Re: [gdal-dev] ogr2ogr explanations for error XML parsing 
> of GML file failed?
>
> Hi Jeroen,
>
> can you type "set" to list environment variables that are defined, 
> both in a terminal from QGIS or the Windows prompt, (possibly 
> redirecting to file, like "set > env_vars.txt"), and compare the 
> differences
>
> Even
>
> Le 12/01/2026 ? 17:06, Jeroen Hovens via gdal-dev a ?crit?:
>
>     Hi,
>
>     I use QGIS on Windows10 which comes with GDAL. The latest QGIS LTR
>     (3.40.14) uses GDAL 3.12.1
>
>     In QGIS I can open a terminal (browser panel, rightclick a folder
>     and select Open in Terminal) and immediately use ogr2ogr to
>     convert a WFS to a geopackage, because QGIS has altered the path
>     to include the GDAL directory
>
>     However, with some WFS services ogr2ogr throws an error. I have no
>     trouble using those WFS services in QGIS.
>
>     For instance, this one I can?t convert:
>
>     ogr2ogr -f gpkg test.gpkg
>     WFS:"https://service.pdok.nl/kadaster/bestuurlijkegebieden/wfs/v1_0?"
>     <https://service.pdok.nl/kadaster/bestuurlijkegebieden/wfs/v1_0?>
>     Provinciegebied -overwrite -nln provincie_kadaster
>
>     But this one I can:
>
>     ogr2ogr -f gpkg test2.gpkg
>     WFS:"https://map.data.amsterdam.nl/maps/gebieden"
>     <https://map.data.amsterdam.nl/maps/gebieden> wijk -overwrite -nln
>     amsterdam_wijk
>
>     The first WFS is part of a large Dutch open data organization and
>     depending on which WFS ?I choose from them I see two different errors:
>
>     ERROR 1: XML parsing of GML file failed : no element found at line
>     27, column 31065 ??(or different numbers)
>
>     Or
>
>     ERROR 1: XML parsing of GML file failed : unclosed token at line
>     555, column 9
>
>     I was able to compare a debug on with someone who was able to
>     convert the WFS to a gpkg and this part was surely different
>
>     VSICURL: Read attempt beyond end of file
>
>     VSICURL: Read attempt beyond end of file
>
>     After this, the error appeared.
>
>     To make things more complicated:
>
>     When I open a Windows Prompt (terminal) and set a path to the GDAL
>     directory in QGIS using set PATH=%PATH%;C:\Program Files\QGIS
>     3.40.14\bin
>
>     I can also use ogr2ogr.
>
>     Interestingly, now I can convert both WFS datasets to gpkg.
>
>     What could be different with the QGIS Terminal setting from a
>     Windows Prompt setting with the path set that would explain the
>     errors?
>
>     What might be different in both WFS services that triggers these
>     errors?
>
>     Kind regards,
>
>     Jeroen Hovens
>
>
>
>     _______________________________________________
>
>     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.

-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260112/56d96c0f/attachment.htm>

From jeroen at groenebij.nl  Mon Jan 12 12:22:19 2026
From: jeroen at groenebij.nl (Jeroen Hovens)
Date: Mon, 12 Jan 2026 21:22:19 +0100
Subject: [gdal-dev] ogr2ogr explanations for error XML parsing of GML
 file failed?
In-Reply-To: <e3e53b2e-116e-40e8-a4b9-ffcd48663299@spatialys.com>
References: <005c01dc83dd$5eeb1cf0$1cc156d0$@groenebij.nl>
 <8ef2c691-1ef1-45df-954f-555dcfab2baf@spatialys.com>
 <007e01dc83e4$cf446360$6dcd2a20$@groenebij.nl>
 <e3e53b2e-116e-40e8-a4b9-ffcd48663299@spatialys.com>
Message-ID: <00a101dc8401$27240ce0$756c26a0$@groenebij.nl>

Okay, so I actually stumbled upon a GDAL bug, cool.

 

I think another workaround could be to edit the QGIS variable setting in Options>System



But I do not know if this will introduce other issues in QGIS ?

 

Just to let you know, I just tried this approach, which indeed results in the VSI_CACHE variable not being listed anymore when typing set

AND the WFS to gpkg conversion was successful.

 

 

Thanks,

Jeroen

 

Van: Even Rouault <even.rouault at spatialys.com> 
Verzonden: maandag 12 januari 2026 19:07
Aan: Jeroen Hovens <jeroen at groenebij.nl>
CC: gdal-dev at lists.osgeo.org
Onderwerp: Re: [gdal-dev] ogr2ogr explanations for error XML parsing of GML file failed?

 

ok,

so the issue was related to QGIS setting VSI_CACHE=YES, which triggered a bug in /vsicurl_streaming/

So the workaround is that you type "set VSI_CACHE=" in the QGIS console

Proper fix queued in https://github.com/OSGeo/gdal/pull/13690

Even

Le 12/01/2026 ? 17:59, Jeroen Hovens a ?crit :

Hi Even,

 

Find attached two txt files.

env_var_winprompt is the normal windows prompt terminal after adding the QGIS bin folder to path

env_var_qgisterminal is the QGIS terminal as is, no changes made

 

Jeroen

 

 

Van: Even Rouault  <mailto:even.rouault at spatialys.com> <even.rouault at spatialys.com> 
Verzonden: maandag 12 januari 2026 17:34
Aan: Jeroen Hovens  <mailto:jeroen at groenebij.nl> <jeroen at groenebij.nl>; gdal-dev at lists.osgeo.org <mailto:gdal-dev at lists.osgeo.org> 
Onderwerp: Re: [gdal-dev] ogr2ogr explanations for error XML parsing of GML file failed?

 

Hi Jeroen,

can you type "set" to list environment variables that are defined, both in a terminal from QGIS or the Windows prompt, (possibly redirecting to file, like "set > env_vars.txt"), and compare the differences

Even

Le 12/01/2026 ? 17:06, Jeroen Hovens via gdal-dev a ?crit :

Hi,

 

I use QGIS on Windows10 which comes with GDAL. The latest QGIS LTR (3.40.14) uses GDAL 3.12.1

In QGIS I can open a terminal (browser panel, rightclick a folder and select Open in Terminal) and immediately use ogr2ogr to convert a WFS to a geopackage, because QGIS has altered the path to include the GDAL directory

However, with some WFS services ogr2ogr throws an error. I have no trouble using those WFS services in QGIS.

 

For instance, this one I can?t convert:

ogr2ogr -f gpkg test.gpkg WFS: <https://service.pdok.nl/kadaster/bestuurlijkegebieden/wfs/v1_0?> "https://service.pdok.nl/kadaster/bestuurlijkegebieden/wfs/v1_0?" Provinciegebied -overwrite -nln provincie_kadaster

But this one I can:

ogr2ogr -f gpkg test2.gpkg WFS: <https://map.data.amsterdam.nl/maps/gebieden> "https://map.data.amsterdam.nl/maps/gebieden" wijk -overwrite -nln amsterdam_wijk

 

The first WFS is part of a large Dutch open data organization and depending on which WFS  I choose from them I see two different errors:

ERROR 1: XML parsing of GML file failed : no element found at line 27, column 31065   (or different numbers)

Or

ERROR 1: XML parsing of GML file failed : unclosed token at line 555, column 9

 

I was able to compare a debug on with someone who was able to convert the WFS to a gpkg and this part was surely different

VSICURL: Read attempt beyond end of file

VSICURL: Read attempt beyond end of file

 

After this, the error appeared.

 

 

To make things more complicated:

When I open a Windows Prompt (terminal) and set a path to the GDAL directory in QGIS using set PATH=%PATH%;C:\Program Files\QGIS 3.40.14\bin

I can also use ogr2ogr.

Interestingly, now I can convert both WFS datasets to gpkg.

 

What could be different with the QGIS Terminal setting from a Windows Prompt setting with the path set that would explain the errors?

What might be different in both WFS services that triggers these errors?

 

 

 

Kind regards,

 

Jeroen Hovens

 

 

 

 

 

_______________________________________________
gdal-dev mailing list
gdal-dev at lists.osgeo.org <mailto: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.

-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260112/c865bed7/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 7059 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260112/c865bed7/attachment-0001.png>

From lars at ahlzen.com  Tue Jan 13 01:31:11 2026
From: lars at ahlzen.com (Lars Ahlzen)
Date: Tue, 13 Jan 2026 09:31:11 +0000
Subject: [gdal-dev] Support for Terrain-RGB
In-Reply-To: <6c261ee9-d63a-4130-a489-0d28d12b57f9@spatialys.com>
References: <CAEL9=c=OOoM1zygUJW9KRpE0WC-9SDfhopcNwxThJb29dgq=tA@mail.gmail.com>
 <af905f43-69e7-43cf-8e72-1db786df9a45@spatialys.com>
 <199313755508833280.0.v2@titan.email> <1767942127.779873340@f314.i.mail.ru>
 <b109ff2e-6739-4255-9369-81ca20c59097@ahlzen.com>
 <d881bdb0-f87d-403e-b695-43d81da08ad8@spatialys.com>
 <d687cde0-bfaa-4e33-8095-0830bd615b11@ahlzen.com>
 <6c261ee9-d63a-4130-a489-0d28d12b57f9@spatialys.com>
Message-ID: <b579fa91-622d-44b0-b18e-b28605f0e2de@ahlzen.com>

On 12/01/2026 17:15, Even Rouault wrote:
>>
>> That's probably the way to go. The last example would then be:
>>
>> gdal raster tile --min-zoom 5 --max-zoom 15 --format ENCODE_RGB --co 
>> DRIVER=WEBP --co DRV_OPT_LOSSLESS=YES --co BANDS=RGB --co 
>> OFFSET=-10000 --co SCALE=0.1 dem.tif rgb-tiles/
>>
>> I can start looking at implementing such a driver. I assume this 
>> would warrant an RFC?
>
> Your call, but RFCs are generally used for changes with wide impact in 
> the code base. Drivers have generally a localized impact, particularly 
> here when they don't introduce new external dependencies. You could 
> also for example create a ticket with details of your plan if you want 
> to discuss them before starting the coding . 

Ok, thanks for the clarification. I'll use my judgement then based on 
how it looks like it's going to affect the rest of the code base.

- Lars


From gcpp.kalxas at gmail.com  Tue Jan 13 09:45:30 2026
From: gcpp.kalxas at gmail.com (Angelos Tzotsos)
Date: Tue, 13 Jan 2026 19:45:30 +0200
Subject: [gdal-dev] Fwd: OGC Compliance Renewal Notification - 30 Day
 Expiration Notice
In-Reply-To: <8edf1a4b-1688-428f-b9b3-71204aa02eb9@gmail.com>
References: <1765361161.695827.236279.nullmailer@tic.ogc.org>
 <c2a46fb8-bca8-4c2b-aca1-0d5273c31bbb@gmail.com>
 <963d3e39-9d57-4313-a1c9-fde32b47a8aa@gmail.com>
 <8edf1a4b-1688-428f-b9b3-71204aa02eb9@gmail.com>
Message-ID: <f9e0eedf-8a9d-4dfc-b91d-ee9db11de6e7@gmail.com>

Hi all.

The submission has been approved:

https://portal.ogc.org/public_ogc/compliance/compliant.php?display_opt=1&org_match=Open%20Source%20Geospatial%20Foundation

Thanks all for your feedback and testing.

Regards,
Angelos

On 1/8/26 17:34, Angelos Tzotsos wrote:
> Hi all,
>
> The compliance submission has been completed.
> We are waiting for feedback from OGC.
>
> Best,
> Angelos
>
> On 1/4/26 16:36, Angelos Tzotsos wrote:
>> Happy New Year!
>>
>> I have prepared the new compliance submission including CITE tests 
>> from pycsw, GeoServer and pygeoapi.
>> I have kept MapServer and GDAL listed, as last year.
>> Should I wait for new tests or should I continue with submission?
>>
>> Best regards,
>> Angelos
>>
>> On 12/10/25 14:57, Angelos Tzotsos wrote:
>>> Dear all,
>>>
>>> Please prepare your OGC CITE tests and let us know by the end of the 
>>> month so we can prepare the submission.
>>>
>>> Best regards,
>>> Angelos
>>>
>>>
>>> -------- Forwarded Message --------
>>> Subject:???? OGC Compliance Renewal Notification - 30 Day Expiration 
>>> Notice
>>> Date:???? Wed, 10 Dec 2025 10:06:01 +0000
>>> From:???? compliance at ogc.org
>>> Reply-To:???? compliance at ogc.org
>>> To:???? info at osgeo.org
>>> CC:???? Angelos Tzotsos <tzotsos at osgeo.org>, Michael Smith 
>>> <info at osgeo.org>, Even Roualt <even.rouault at spatialys.com>
>>>
>>>
>>>
>>> ?Open Source Geospatial Foundation (OSGeo)
>>>
>>> This is an automated email to inform you that your OGC-certified 
>>> compliance license(s) for the following products are due to be 
>>> renewed by *January 9th, 2026*. After that date, your products will 
>>> no longer be listed as certified OGC compliant and you may not claim 
>>> that they are compliant.
>>>
>>> Since you have reference implementations in your listings please be 
>>> aware of the following:
>>>
>>> ?* You need to retest if you want to continue being listed as a
>>> ?? reference implementation.
>>> ?* If you want to provide a new version as a reference implementation
>>> ?? you need to test that new version. The older version will no longer
>>> ?? hold the status of reference implementations.
>>> ?* If you want to continue displaying the certification for the older
>>> ?? version of your product, then you will be required to pay for the
>>> ?? certification.
>>>
>>> If you have already received an earlier notice and have started the 
>>> renewal process please ignore this message.
>>>
>>> We invite you to easily renew online in our implementation portal: 
>>> https://www.ogc.org/resource/products/registration
>>>
>>> As a reminder, the account used to manage your certification 
>>> listings is: *osgeo (info at osgeo.org)*
>>>
>>> If you have any questions please send an email to 
>>> compliance at ogc.org. The OGC compliance team will be more than glad 
>>> to help you.
>>>
>>> ------------------------------------------------------------------------ 
>>>
>>>
>>>
>>> ?? Current OGC-Compliant Listings
>>>
>>>
>>> ???? GDAL/OGR 3.10
>>>
>>> Specification(s)???? Original Certification
>>> OGC GeoTIFF Standard 1.1
>>> (OGC Reference Implementation)???? 2025-01-10
>>> OGC KML 2.2.0
>>> (OGC Reference Implementation)???? 2025-01-10
>>> OGC KML (Level 2) 2.2.0
>>> (OGC Reference Implementation)???? 2025-01-10
>>> OGC KML (Level 3) 2.2.0
>>> (OGC Reference Implementation)???? 2025-01-10
>>> OGC? GeoPackage Encoding Standard 1.2
>>> (OGC Reference Implementation)???? 2025-01-10
>>> OGC? GeoPackage Encoding Standard: Extension Mechanism 1.2
>>> (OGC Reference Implementation)???? 2025-01-10
>>> OGC? GeoPackage Encoding Standard: Features 1.2
>>> (OGC Reference Implementation)???? 2025-01-10
>>> OGC? GeoPackage Encoding Standard: Metadata 1.2
>>> (OGC Reference Implementation)???? 2025-01-10
>>> OGC? GeoPackage Encoding Standard: RTree Spatial Indexes 1.2
>>> (OGC Reference Implementation)???? 2025-01-10
>>> OGC? GML in JPEG 2000 (GMLJP2) Encoding Standard Part 1: Core 2.0
>>> (OGC Reference Implementation)???? 2025-01-10
>>>
>>>
>>> ???? GeoServer 2.27
>>>
>>> Specification(s)???? Original Certification
>>> OGC API - Features - Part 1: Core 1.0???? 2025-07-10
>>> OGC API - Features - Part 2: Coordinate Reference Systems by 
>>> Reference 1.0???? 2025-07-10
>>> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard 1.0
>>> (OGC Reference Implementation)???? 2025-07-10
>>> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Acquisition 
>>> Information 1.0
>>> (OGC Reference Implementation)???? 2025-07-10
>>> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Acquisition 
>>> Parameters 1.0
>>> (OGC Reference Implementation)???? 2025-07-10
>>> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Data 
>>> Identification 1.0
>>> (OGC Reference Implementation)???? 2025-07-10
>>> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Earth 
>>> Observation 1.0
>>> (OGC Reference Implementation)???? 2025-07-10
>>> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Earth 
>>> Observation Collection 1.0
>>> (OGC Reference Implementation)???? 2025-07-10
>>> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Geometry 1.0
>>> (OGC Reference Implementation)???? 2025-07-10
>>> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Links 1.0
>>> (OGC Reference Implementation)???? 2025-07-10
>>> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Metadata 
>>> Information 1.0
>>> (OGC Reference Implementation)???? 2025-07-10
>>> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Offering 1.0
>>> (OGC Reference Implementation)???? 2025-07-10
>>> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Product 
>>> Information 1.0
>>> (OGC Reference Implementation)???? 2025-07-10
>>> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Properties 1.0
>>> (OGC Reference Implementation)???? 2025-07-10
>>> OGC GeoTIFF Standard 1.1
>>> (OGC Reference Implementation)???? 2025-07-10
>>> OGC? GeoPackage Encoding Standard 1.2
>>> (OGC Reference Implementation)???? 2025-07-10
>>> OGC? GeoPackage Encoding Standard: Extension Mechanism 1.2
>>> (OGC Reference Implementation)???? 2025-07-10
>>> OGC? GeoPackage Encoding Standard: Features 1.2
>>> (OGC Reference Implementation)???? 2025-07-10
>>> OGC? GeoPackage Encoding Standard: Metadata 1.2
>>> (OGC Reference Implementation)???? 2025-07-10
>>> OGC? GeoPackage Encoding Standard: RTree Spatial Indexes 1.2
>>> (OGC Reference Implementation)???? 2025-07-10
>>> OGC? GeoPackage Encoding Standard: Schema 1.2
>>> (OGC Reference Implementation)???? 2025-07-10
>>> OGC? WCS 2.0 Interface Standard- Core: Corrigendum 2.0.1
>>> (OGC Reference Implementation)???? 2025-07-10
>>> OGC? Web Coverage Service Interface Standard - Interpolation 
>>> Extension 1.0
>>> (OGC Reference Implementation)???? 2025-07-10
>>> OGC? Web Coverage Service Interface Standard - Scaling Extension 1.0
>>> (OGC Reference Implementation)???? 2025-07-10
>>> OGC? Web Coverage Service Interface Standard - CRS Extension 1.0
>>> (OGC Reference Implementation)???? 2025-07-10
>>> OGC? Web Coverage Service Interface Standard - Range Subsetting 
>>> Extension 1.0
>>> (OGC Reference Implementation)???? 2025-07-10
>>> OpenGIS Web Coverage Service (WCS) Implementation Specification 
>>> (Corrigendum) 1.0.0
>>> (OGC Reference Implementation)???? 2025-07-10
>>> OpenGIS Web Coverage Service (WCS) Implementation Specification 
>>> Corrigendum 1 1.1.1
>>> (OGC Reference Implementation)???? 2025-07-10
>>> OpenGIS Web Feature Service (WFS) Implementation Specification 1.1.0 
>>> 2025-07-10
>>> OpenGIS Web Feature Service (WFS) Implementation Specification 
>>> (Basic) 1.1.0???? 2025-07-10
>>> OpenGIS Web Feature Service (WFS) Implementation Specification 
>>> (Transactional) 1.1.0???? 2025-07-10
>>> OpenGIS Web Feature Service - Basic 2.0???? 2025-07-10
>>> OpenGIS Web Feature Service - Locking 2.0???? 2025-07-10
>>> OpenGIS Web Feature Service - Transactional 2.0???? 2025-07-10
>>> OpenGIS Web Feature Service 2.0 Interface Standard (also ISO 19142) 
>>> 2.0 2025-07-10
>>> OpenGIS Web Map Service (WMS) Implementation Specification 1.3.0 
>>> 2025-07-10
>>> OpenGIS Web Map Tile Service Implementation Standard 1.0.0 2025-07-10
>>> Web Feature Service 1.0.0
>>> (OGC Reference Implementation)???? 2025-07-10
>>> Web Feature Service (Transactional) 1.0.0
>>> (OGC Reference Implementation)???? 2025-07-10
>>> Web Map Service 1.1.1???? 2025-07-10
>>>
>>>
>>> ???? istSOS 2.3.1
>>>
>>> Specification(s)???? Original Certification
>>> OpenGIS Sensor Observation Service 1.0.0
>>> (OGC Reference Implementation)???? 2018-01-09
>>>
>>>
>>> ???? pycsw 2.6.0
>>>
>>> Specification(s)???? Original Certification
>>> OGC GeoRSS Encoding Standard 1.0
>>> (OGC Reference Implementation)???? 2022-04-28
>>> OGC? Catalogue Services 3.0 Specification - HTTP Protocol Binding 3.0
>>> (OGC Reference Implementation)???? 2021-01-09
>>> OGC? Catalogue Services 3.0 Specification - HTTP Protocol Binding 
>>> (OpenSearch) 3.0
>>> (OGC Reference Implementation)???? 2021-01-09
>>> OpenGIS Catalogue Service Implementation Specification 2.0.2
>>> (OGC Reference Implementation)???? 2021-01-09
>>> OpenGIS Catalogue Service Implementation Specification [Catalogue 
>>> Service for the Web] 2.0.2
>>> (OGC Reference Implementation)???? 2021-01-09
>>>
>>>
>>> ???? pygeoapi 0.19.0
>>>
>>> Specification(s)???? Original Certification
>>> OGC API - Environmental Data Retrieval Standard 1.0.1
>>> (OGC Reference Implementation)???? 2025-01-10
>>> OGC API - Environmental Data Retrieval Standard: Collections 1.0.1
>>> (OGC Reference Implementation)???? 2025-01-10
>>> OGC API - Environmental Data Retrieval Standard: CoverageJSON 1.0.1
>>> (OGC Reference Implementation)???? 2025-01-10
>>> OGC API - Environmental Data Retrieval Standard: EDRGeoJSON 1.0.1
>>> (OGC Reference Implementation)???? 2025-01-10
>>> OGC API - Environmental Data Retrieval Standard: GeoJSON 1.0.1
>>> (OGC Reference Implementation)???? 2025-01-10
>>> OGC API - Environmental Data Retrieval Standard: HTML 1.0.1
>>> (OGC Reference Implementation)???? 2025-01-10
>>> OGC API - Environmental Data Retrieval Standard: JSON 1.0.1
>>> (OGC Reference Implementation)???? 2025-01-10
>>> OGC API - Features - Part 1: Core 1.0
>>> (OGC Reference Implementation)???? 2025-01-10
>>> OGC API - Tiles - Part 1: Core 1.0
>>> (OGC Reference Implementation)???? 2025-01-10
>>> OGC API - Tiles - Part 1: DatasetTilesets 1.0
>>> (OGC Reference Implementation)???? 2025-01-10
>>> OGC API - Tiles - Part 1: GeoDataTilesets 1.0
>>> (OGC Reference Implementation)???? 2025-01-10
>>>
>>>
>>>
>>
>

-- 
Angelos Tzotsos, PhD
President, Board of Directors
Open Source Geospatial Foundation
https://www.osgeo.org/member/angelos-tzotsos/



From andrea.aime at geo-solutions.it  Tue Jan 13 10:19:50 2026
From: andrea.aime at geo-solutions.it (Andrea Aime)
Date: Tue, 13 Jan 2026 19:19:50 +0100
Subject: [gdal-dev] Fwd: OGC Compliance Renewal Notification - 30 Day
 Expiration Notice
In-Reply-To: <f9e0eedf-8a9d-4dfc-b91d-ee9db11de6e7@gmail.com>
References: <1765361161.695827.236279.nullmailer@tic.ogc.org>
 <c2a46fb8-bca8-4c2b-aca1-0d5273c31bbb@gmail.com>
 <963d3e39-9d57-4313-a1c9-fde32b47a8aa@gmail.com>
 <8edf1a4b-1688-428f-b9b3-71204aa02eb9@gmail.com>
 <f9e0eedf-8a9d-4dfc-b91d-ee9db11de6e7@gmail.com>
Message-ID: <CALHQADU-+geozX6JQcZk7TbgpZQQF-f7H+N9uCfU4zCjNQJ4BA@mail.gmail.com>

Nice! And thanks for pushing this forward!

Cheers
Andrea

On Tue, Jan 13, 2026 at 6:45?PM Angelos Tzotsos <gcpp.kalxas at gmail.com>
wrote:

> Hi all.
>
> The submission has been approved:
>
>
> https://portal.ogc.org/public_ogc/compliance/compliant.php?display_opt=1&org_match=Open%20Source%20Geospatial%20Foundation
>
> Thanks all for your feedback and testing.
>
> Regards,
> Angelos
>
> On 1/8/26 17:34, Angelos Tzotsos wrote:
> > Hi all,
> >
> > The compliance submission has been completed.
> > We are waiting for feedback from OGC.
> >
> > Best,
> > Angelos
> >
> > On 1/4/26 16:36, Angelos Tzotsos wrote:
> >> Happy New Year!
> >>
> >> I have prepared the new compliance submission including CITE tests
> >> from pycsw, GeoServer and pygeoapi.
> >> I have kept MapServer and GDAL listed, as last year.
> >> Should I wait for new tests or should I continue with submission?
> >>
> >> Best regards,
> >> Angelos
> >>
> >> On 12/10/25 14:57, Angelos Tzotsos wrote:
> >>> Dear all,
> >>>
> >>> Please prepare your OGC CITE tests and let us know by the end of the
> >>> month so we can prepare the submission.
> >>>
> >>> Best regards,
> >>> Angelos
> >>>
> >>>
> >>> -------- Forwarded Message --------
> >>> Subject:     OGC Compliance Renewal Notification - 30 Day Expiration
> >>> Notice
> >>> Date:     Wed, 10 Dec 2025 10:06:01 +0000
> >>> From:     compliance at ogc.org
> >>> Reply-To:     compliance at ogc.org
> >>> To:     info at osgeo.org
> >>> CC:     Angelos Tzotsos <tzotsos at osgeo.org>, Michael Smith
> >>> <info at osgeo.org>, Even Roualt <even.rouault at spatialys.com>
> >>>
> >>>
> >>>
> >>>  Open Source Geospatial Foundation (OSGeo)
> >>>
> >>> This is an automated email to inform you that your OGC-certified
> >>> compliance license(s) for the following products are due to be
> >>> renewed by *January 9th, 2026*. After that date, your products will
> >>> no longer be listed as certified OGC compliant and you may not claim
> >>> that they are compliant.
> >>>
> >>> Since you have reference implementations in your listings please be
> >>> aware of the following:
> >>>
> >>>  * You need to retest if you want to continue being listed as a
> >>>    reference implementation.
> >>>  * If you want to provide a new version as a reference implementation
> >>>    you need to test that new version. The older version will no longer
> >>>    hold the status of reference implementations.
> >>>  * If you want to continue displaying the certification for the older
> >>>    version of your product, then you will be required to pay for the
> >>>    certification.
> >>>
> >>> If you have already received an earlier notice and have started the
> >>> renewal process please ignore this message.
> >>>
> >>> We invite you to easily renew online in our implementation portal:
> >>> https://www.ogc.org/resource/products/registration
> >>>
> >>> As a reminder, the account used to manage your certification
> >>> listings is: *osgeo (info at osgeo.org)*
> >>>
> >>> If you have any questions please send an email to
> >>> compliance at ogc.org. The OGC compliance team will be more than glad
> >>> to help you.
> >>>
> >>>
> ------------------------------------------------------------------------
> >>>
> >>>
> >>>
> >>>    Current OGC-Compliant Listings
> >>>
> >>>
> >>>      GDAL/OGR 3.10
> >>>
> >>> Specification(s)     Original Certification
> >>> OGC GeoTIFF Standard 1.1
> >>> (OGC Reference Implementation)     2025-01-10
> >>> OGC KML 2.2.0
> >>> (OGC Reference Implementation)     2025-01-10
> >>> OGC KML (Level 2) 2.2.0
> >>> (OGC Reference Implementation)     2025-01-10
> >>> OGC KML (Level 3) 2.2.0
> >>> (OGC Reference Implementation)     2025-01-10
> >>> OGC? GeoPackage Encoding Standard 1.2
> >>> (OGC Reference Implementation)     2025-01-10
> >>> OGC? GeoPackage Encoding Standard: Extension Mechanism 1.2
> >>> (OGC Reference Implementation)     2025-01-10
> >>> OGC? GeoPackage Encoding Standard: Features 1.2
> >>> (OGC Reference Implementation)     2025-01-10
> >>> OGC? GeoPackage Encoding Standard: Metadata 1.2
> >>> (OGC Reference Implementation)     2025-01-10
> >>> OGC? GeoPackage Encoding Standard: RTree Spatial Indexes 1.2
> >>> (OGC Reference Implementation)     2025-01-10
> >>> OGC? GML in JPEG 2000 (GMLJP2) Encoding Standard Part 1: Core 2.0
> >>> (OGC Reference Implementation)     2025-01-10
> >>>
> >>>
> >>>      GeoServer 2.27
> >>>
> >>> Specification(s)     Original Certification
> >>> OGC API - Features - Part 1: Core 1.0     2025-07-10
> >>> OGC API - Features - Part 2: Coordinate Reference Systems by
> >>> Reference 1.0     2025-07-10
> >>> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard 1.0
> >>> (OGC Reference Implementation)     2025-07-10
> >>> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Acquisition
> >>> Information 1.0
> >>> (OGC Reference Implementation)     2025-07-10
> >>> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Acquisition
> >>> Parameters 1.0
> >>> (OGC Reference Implementation)     2025-07-10
> >>> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Data
> >>> Identification 1.0
> >>> (OGC Reference Implementation)     2025-07-10
> >>> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Earth
> >>> Observation 1.0
> >>> (OGC Reference Implementation)     2025-07-10
> >>> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Earth
> >>> Observation Collection 1.0
> >>> (OGC Reference Implementation)     2025-07-10
> >>> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Geometry 1.0
> >>> (OGC Reference Implementation)     2025-07-10
> >>> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Links 1.0
> >>> (OGC Reference Implementation)     2025-07-10
> >>> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Metadata
> >>> Information 1.0
> >>> (OGC Reference Implementation)     2025-07-10
> >>> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Offering 1.0
> >>> (OGC Reference Implementation)     2025-07-10
> >>> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Product
> >>> Information 1.0
> >>> (OGC Reference Implementation)     2025-07-10
> >>> OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard: Properties 1.0
> >>> (OGC Reference Implementation)     2025-07-10
> >>> OGC GeoTIFF Standard 1.1
> >>> (OGC Reference Implementation)     2025-07-10
> >>> OGC? GeoPackage Encoding Standard 1.2
> >>> (OGC Reference Implementation)     2025-07-10
> >>> OGC? GeoPackage Encoding Standard: Extension Mechanism 1.2
> >>> (OGC Reference Implementation)     2025-07-10
> >>> OGC? GeoPackage Encoding Standard: Features 1.2
> >>> (OGC Reference Implementation)     2025-07-10
> >>> OGC? GeoPackage Encoding Standard: Metadata 1.2
> >>> (OGC Reference Implementation)     2025-07-10
> >>> OGC? GeoPackage Encoding Standard: RTree Spatial Indexes 1.2
> >>> (OGC Reference Implementation)     2025-07-10
> >>> OGC? GeoPackage Encoding Standard: Schema 1.2
> >>> (OGC Reference Implementation)     2025-07-10
> >>> OGC? WCS 2.0 Interface Standard- Core: Corrigendum 2.0.1
> >>> (OGC Reference Implementation)     2025-07-10
> >>> OGC? Web Coverage Service Interface Standard - Interpolation
> >>> Extension 1.0
> >>> (OGC Reference Implementation)     2025-07-10
> >>> OGC? Web Coverage Service Interface Standard - Scaling Extension 1.0
> >>> (OGC Reference Implementation)     2025-07-10
> >>> OGC? Web Coverage Service Interface Standard - CRS Extension 1.0
> >>> (OGC Reference Implementation)     2025-07-10
> >>> OGC? Web Coverage Service Interface Standard - Range Subsetting
> >>> Extension 1.0
> >>> (OGC Reference Implementation)     2025-07-10
> >>> OpenGIS Web Coverage Service (WCS) Implementation Specification
> >>> (Corrigendum) 1.0.0
> >>> (OGC Reference Implementation)     2025-07-10
> >>> OpenGIS Web Coverage Service (WCS) Implementation Specification
> >>> Corrigendum 1 1.1.1
> >>> (OGC Reference Implementation)     2025-07-10
> >>> OpenGIS Web Feature Service (WFS) Implementation Specification 1.1.0
> >>> 2025-07-10
> >>> OpenGIS Web Feature Service (WFS) Implementation Specification
> >>> (Basic) 1.1.0     2025-07-10
> >>> OpenGIS Web Feature Service (WFS) Implementation Specification
> >>> (Transactional) 1.1.0     2025-07-10
> >>> OpenGIS Web Feature Service - Basic 2.0     2025-07-10
> >>> OpenGIS Web Feature Service - Locking 2.0     2025-07-10
> >>> OpenGIS Web Feature Service - Transactional 2.0     2025-07-10
> >>> OpenGIS Web Feature Service 2.0 Interface Standard (also ISO 19142)
> >>> 2.0 2025-07-10
> >>> OpenGIS Web Map Service (WMS) Implementation Specification 1.3.0
> >>> 2025-07-10
> >>> OpenGIS Web Map Tile Service Implementation Standard 1.0.0 2025-07-10
> >>> Web Feature Service 1.0.0
> >>> (OGC Reference Implementation)     2025-07-10
> >>> Web Feature Service (Transactional) 1.0.0
> >>> (OGC Reference Implementation)     2025-07-10
> >>> Web Map Service 1.1.1     2025-07-10
> >>>
> >>>
> >>>      istSOS 2.3.1
> >>>
> >>> Specification(s)     Original Certification
> >>> OpenGIS Sensor Observation Service 1.0.0
> >>> (OGC Reference Implementation)     2018-01-09
> >>>
> >>>
> >>>      pycsw 2.6.0
> >>>
> >>> Specification(s)     Original Certification
> >>> OGC GeoRSS Encoding Standard 1.0
> >>> (OGC Reference Implementation)     2022-04-28
> >>> OGC? Catalogue Services 3.0 Specification - HTTP Protocol Binding 3.0
> >>> (OGC Reference Implementation)     2021-01-09
> >>> OGC? Catalogue Services 3.0 Specification - HTTP Protocol Binding
> >>> (OpenSearch) 3.0
> >>> (OGC Reference Implementation)     2021-01-09
> >>> OpenGIS Catalogue Service Implementation Specification 2.0.2
> >>> (OGC Reference Implementation)     2021-01-09
> >>> OpenGIS Catalogue Service Implementation Specification [Catalogue
> >>> Service for the Web] 2.0.2
> >>> (OGC Reference Implementation)     2021-01-09
> >>>
> >>>
> >>>      pygeoapi 0.19.0
> >>>
> >>> Specification(s)     Original Certification
> >>> OGC API - Environmental Data Retrieval Standard 1.0.1
> >>> (OGC Reference Implementation)     2025-01-10
> >>> OGC API - Environmental Data Retrieval Standard: Collections 1.0.1
> >>> (OGC Reference Implementation)     2025-01-10
> >>> OGC API - Environmental Data Retrieval Standard: CoverageJSON 1.0.1
> >>> (OGC Reference Implementation)     2025-01-10
> >>> OGC API - Environmental Data Retrieval Standard: EDRGeoJSON 1.0.1
> >>> (OGC Reference Implementation)     2025-01-10
> >>> OGC API - Environmental Data Retrieval Standard: GeoJSON 1.0.1
> >>> (OGC Reference Implementation)     2025-01-10
> >>> OGC API - Environmental Data Retrieval Standard: HTML 1.0.1
> >>> (OGC Reference Implementation)     2025-01-10
> >>> OGC API - Environmental Data Retrieval Standard: JSON 1.0.1
> >>> (OGC Reference Implementation)     2025-01-10
> >>> OGC API - Features - Part 1: Core 1.0
> >>> (OGC Reference Implementation)     2025-01-10
> >>> OGC API - Tiles - Part 1: Core 1.0
> >>> (OGC Reference Implementation)     2025-01-10
> >>> OGC API - Tiles - Part 1: DatasetTilesets 1.0
> >>> (OGC Reference Implementation)     2025-01-10
> >>> OGC API - Tiles - Part 1: GeoDataTilesets 1.0
> >>> (OGC Reference Implementation)     2025-01-10
> >>>
> >>>
> >>>
> >>
> >
>
> --
> Angelos Tzotsos, PhD
> President, Board of Directors
> Open Source Geospatial Foundation
> https://www.osgeo.org/member/angelos-tzotsos/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260113/a21292d0/attachment-0001.htm>

From michael.smith.erdc at gmail.com  Tue Jan 13 16:03:25 2026
From: michael.smith.erdc at gmail.com (Michael Smith)
Date: Tue, 13 Jan 2026 19:03:25 -0500
Subject: [gdal-dev] Odd issue with parquet using gdal python opening inside
 Django code
Message-ID: <7581F73C-14DE-44B1-A9A8-A52C7D994C91@gmail.com>

We use gdal with Django and build gdal from conda and install the parquet driver that way. But we have just found an odd issue when a parquet file is opened in our Django code vs in a Django shell.


In the shell we get


gf = gdal.OpenEx('/tmp/stac_48069_usgs-3dep_rasters.parquet')
GDAL: On-demand registering /home/gridusr/gridpixi/.pixi/envs/default/lib/gdalplugins/ogr_Parquet.so using RegisterOGRParquet.
GDAL: GDALOpen(/tmp/stac_48069_usgs-3dep_rasters.parquet, this=0x5626a2e395a0) succeeds as Parquet.
PARQUET: Compression (of first column): zstd
ARROW: Memory pool: bytes_allocated = 0
ARROW: Memory pool: max_memory = 0
GDAL: GDALClose(/vsis3/grid-dev-publiclidar/stac/testgrid/rasters/stac_48069_usgs-3dep_rasters.parquet, this=0x5626a2e38990)


And everything works fine


In the code we get
GDAL: On-demand registering /home/gridusr/gridpixi/.pixi/envs/default/lib/gdalplugins/ogr_Parquet.so using RegisterOGRParquet.
GDAL: GDALOpen(/tmp/stac_48069_usgs-3dep_rasters.parquet, this=0x7f43945696b0) succeeds as Parquet.
PARQUET: Dealing with field GEOMETRY of extension type geoarrow.polygon as list<rings: list<vertices: struct<x: double not null, y: double not null> not null> not null>
PARQUET: Compression (of first column): zstd
GDAL: GDALOpen(/tmp/stac_48069_usgs-3dep_rasters.parquet, this=0x7f43945d6760) succeeds as Parquet.
OGR: GetLayerCount() = 1


And this line seems to be the issue
PARQUET: Dealing with field GEOMETRY of extension type geoarrow.polygon as list<rings: list<vertices: struct<x: double not null, y: double not null> not null> not null>


In this case, the geometry is not recognized. 
Calling gdal.VectorInfo(gf) I see


INFO: Open of `/tmp/stac_48069_usgs-3dep_rasters.parquet'
using driver `Parquet' successful.


Layer name: stac_48069_usgs-3dep_rasters
Geometry: None
Feature Count: 109314
Layer SRS WKT:
(unknown)
GEOMETRY: String(JSON) (0.0)


In the django python shell we get
In [7]: print (res)
INFO: Open of `/tmp/stac_48069_usgs-3dep_rasters.parquet'
using driver `Parquet' successful.


Layer name: stac_48069_usgs-3dep_rasters
Geometry: Polygon
Feature Count: 109314
Extent: (-179.001667, -15.001667) - (180.000000, 84.001667)
Layer SRS WKT:
(unknown)
Geometry Column = GEOMETRY


Any ideas?




-- 


Michael Smith 
RSGIS Center ? ERDC CRREL NH 
US Army Corps 















From michael.smith.erdc at gmail.com  Tue Jan 13 16:04:04 2026
From: michael.smith.erdc at gmail.com (Michael Smith)
Date: Tue, 13 Jan 2026 19:04:04 -0500
Subject: [gdal-dev] Odd issue with parquet using gdal python opening
 inside Django code
In-Reply-To: <2456C9B5-6901-4498-BB0E-FBA1CD452499@gmail.com>
Message-ID: <33723C37-DC73-4FB4-8CA7-8CDF3773AC9A@gmail.com>

Looks like if I rewrite the file with gdal it now works in the Django code. 
PARQUET: geo = {"version":"1.1.0","primary_column":"GEOMETRY","columns":{"GEOMETRY":{"encoding":"WKB","crs":null,"bbox":[-179.001667174293,-15.0016666666675,180.0,84.001666666666694],"covering":{"bbox":{"xmin":["GEOMETRY_bbox","xmin"],"ymin":["GEOMETRY_bbox","ymin"],"xmax":["GEOMETRY_bbox","xmax"],"ymax":["GEOMETRY_bbox","ymax"]}},"orientation":"counterclockwise","geometry_types":["Polygon"]}}}
PARQUET: Bounding box column 'GEOMETRY_bbox' detected for geometry column 'GEOMETRY'


I think these files were orginally written with pyogrio and polars. 


Mike




-- 


Michael Smith 
RSGIS Center ? ERDC CRREL NH 
US Army Corps 










?On 1/13/26, 6:18 PM, "Michael Smith" <michael.smith.erdc at gmail.com <mailto:michael.smith.erdc at gmail.com> <mailto:michael.smith.erdc at gmail.com <mailto:michael.smith.erdc at gmail.com>>> wrote:




We use gdal with Django and build gdal from conda and install the parquet driver that way. But we have just found an odd issue when a parquet file is opened in our Django code vs in a Django shell.




In the shell we get




gf = gdal.OpenEx('/tmp/stac_48069_usgs-3dep_rasters.parquet')
GDAL: On-demand registering /home/gridusr/gridpixi/.pixi/envs/default/lib/gdalplugins/ogr_Parquet.so using RegisterOGRParquet.
GDAL: GDALOpen(/tmp/stac_48069_usgs-3dep_rasters.parquet, this=0x5626a2e395a0) succeeds as Parquet.
PARQUET: Compression (of first column): zstd
ARROW: Memory pool: bytes_allocated = 0
ARROW: Memory pool: max_memory = 0
GDAL: GDALClose(/vsis3/grid-dev-publiclidar/stac/testgrid/rasters/stac_48069_usgs-3dep_rasters.parquet, this=0x5626a2e38990)




And everything works fine




In the code we get
GDAL: On-demand registering /home/gridusr/gridpixi/.pixi/envs/default/lib/gdalplugins/ogr_Parquet.so using RegisterOGRParquet.
GDAL: GDALOpen(/tmp/stac_48069_usgs-3dep_rasters.parquet, this=0x7f43945696b0) succeeds as Parquet.
PARQUET: Dealing with field GEOMETRY of extension type geoarrow.polygon as list<rings: list<vertices: struct<x: double not null, y: double not null> not null> not null>
PARQUET: Compression (of first column): zstd
GDAL: GDALOpen(/tmp/stac_48069_usgs-3dep_rasters.parquet, this=0x7f43945d6760) succeeds as Parquet.
OGR: GetLayerCount() = 1




And this line seems to be the issue
PARQUET: Dealing with field GEOMETRY of extension type geoarrow.polygon as list<rings: list<vertices: struct<x: double not null, y: double not null> not null> not null>




In this case, the geometry is not recognized. 
Calling gdal.VectorInfo(gf) I see




INFO: Open of `/tmp/stac_48069_usgs-3dep_rasters.parquet'
using driver `Parquet' successful.




Layer name: stac_48069_usgs-3dep_rasters
Geometry: None
Feature Count: 109314
Layer SRS WKT:
(unknown)
GEOMETRY: String(JSON) (0.0)




In the django python shell we get
In [7]: print (res)
INFO: Open of `/tmp/stac_48069_usgs-3dep_rasters.parquet'
using driver `Parquet' successful.




Layer name: stac_48069_usgs-3dep_rasters
Geometry: Polygon
Feature Count: 109314
Extent: (-179.001667, -15.001667) - (180.000000, 84.001667)
Layer SRS WKT:
(unknown)
Geometry Column = GEOMETRY




Any ideas?








-- 




Michael Smith 
RSGIS Center ? ERDC CRREL NH 
US Army Corps 





























From even.rouault at spatialys.com  Tue Jan 13 16:33:24 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Wed, 14 Jan 2026 01:33:24 +0100
Subject: [gdal-dev] Odd issue with parquet using gdal python opening
 inside Django code
In-Reply-To: <7581F73C-14DE-44B1-A9A8-A52C7D994C91@gmail.com>
References: <7581F73C-14DE-44B1-A9A8-A52C7D994C91@gmail.com>
Message-ID: <b53feb7f-cfa7-4571-a482-98e23abea4a8@spatialys.com>

Mike,

any chance you can provide such sample file? From the logs it uses 
geoarrow.polygon encoding, which should be fine in theory. My hypothesis 
would be that in the Django context something registers the 
geoarrow.polygon extension to libarrow (pyarrow maybe). That said the 
Parquet driver is supposed to be robust to that, so there must be some 
subtelty. When rewriting the file, WKB encoding is selected, which works 
around any potential conflict related to a geoarrow.polygon extension 
being loaded

Even

Le 14/01/2026 ? 01:03, Michael Smith via gdal-dev a ?crit?:
> We use gdal with Django and build gdal from conda and install the parquet driver that way. But we have just found an odd issue when a parquet file is opened in our Django code vs in a Django shell.
>
>
> In the shell we get
>
>
> gf = gdal.OpenEx('/tmp/stac_48069_usgs-3dep_rasters.parquet')
> GDAL: On-demand registering /home/gridusr/gridpixi/.pixi/envs/default/lib/gdalplugins/ogr_Parquet.so using RegisterOGRParquet.
> GDAL: GDALOpen(/tmp/stac_48069_usgs-3dep_rasters.parquet, this=0x5626a2e395a0) succeeds as Parquet.
> PARQUET: Compression (of first column): zstd
> ARROW: Memory pool: bytes_allocated = 0
> ARROW: Memory pool: max_memory = 0
> GDAL: GDALClose(/vsis3/grid-dev-publiclidar/stac/testgrid/rasters/stac_48069_usgs-3dep_rasters.parquet, this=0x5626a2e38990)
>
>
> And everything works fine
>
>
> In the code we get
> GDAL: On-demand registering /home/gridusr/gridpixi/.pixi/envs/default/lib/gdalplugins/ogr_Parquet.so using RegisterOGRParquet.
> GDAL: GDALOpen(/tmp/stac_48069_usgs-3dep_rasters.parquet, this=0x7f43945696b0) succeeds as Parquet.
> PARQUET: Dealing with field GEOMETRY of extension type geoarrow.polygon as list<rings: list<vertices: struct<x: double not null, y: double not null> not null> not null>
> PARQUET: Compression (of first column): zstd
> GDAL: GDALOpen(/tmp/stac_48069_usgs-3dep_rasters.parquet, this=0x7f43945d6760) succeeds as Parquet.
> OGR: GetLayerCount() = 1
>
>
> And this line seems to be the issue
> PARQUET: Dealing with field GEOMETRY of extension type geoarrow.polygon as list<rings: list<vertices: struct<x: double not null, y: double not null> not null> not null>
>
>
> In this case, the geometry is not recognized.
> Calling gdal.VectorInfo(gf) I see
>
>
> INFO: Open of `/tmp/stac_48069_usgs-3dep_rasters.parquet'
> using driver `Parquet' successful.
>
>
> Layer name: stac_48069_usgs-3dep_rasters
> Geometry: None
> Feature Count: 109314
> Layer SRS WKT:
> (unknown)
> GEOMETRY: String(JSON) (0.0)
>
>
> In the django python shell we get
> In [7]: print (res)
> INFO: Open of `/tmp/stac_48069_usgs-3dep_rasters.parquet'
> using driver `Parquet' successful.
>
>
> Layer name: stac_48069_usgs-3dep_rasters
> Geometry: Polygon
> Feature Count: 109314
> Extent: (-179.001667, -15.001667) - (180.000000, 84.001667)
> Layer SRS WKT:
> (unknown)
> Geometry Column = GEOMETRY
>
>
> Any ideas?
>
>
>
>
-- 
http://www.spatialys.com
My software is free, but my time generally not.


From even.rouault at spatialys.com  Tue Jan 13 17:43:45 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Wed, 14 Jan 2026 02:43:45 +0100
Subject: [gdal-dev] Odd issue with parquet using gdal python opening
 inside Django code
In-Reply-To: <b53feb7f-cfa7-4571-a482-98e23abea4a8@spatialys.com>
References: <7581F73C-14DE-44B1-A9A8-A52C7D994C91@gmail.com>
 <b53feb7f-cfa7-4571-a482-98e23abea4a8@spatialys.com>
Message-ID: <328ea0ae-23d9-4f64-9fc2-a7ffd3c6f65e@spatialys.com>

>
> My hypothesis would be that in the Django context something registers 
> the geoarrow.polygon extension to libarrow (pyarrow maybe). That said 
> the Parquet driver is supposed to be robust to that, so there must be 
> some subtelty.

Actually it was not robust :-) Will be fixed per 
https://github.com/OSGeo/gdal/pull/13697

Even

-- 
http://www.spatialys.com
My software is free, but my time generally not.


From johnsmith7862025 at outlook.com  Tue Jan 13 21:13:02 2026
From: johnsmith7862025 at outlook.com (John Smith)
Date: Wed, 14 Jan 2026 05:13:02 +0000
Subject: [gdal-dev] =?windows-1252?q?Reading_GeoJSON_with_diacritics_via_?=
 =?windows-1252?q?GDAL_C=23_bindings_=97_identifiers_vs_data_values?=
Message-ID: <TYZPR06MB6237D2E8040E61B6810A9AD1888FA@TYZPR06MB6237.apcprd06.prod.outlook.com>

I am using GDAL 3.9.3 and reading GeoJSON files (saved in ANSI/Windows-1252 encoding) via the GDAL C# bindings. I want to clarify how SQL queries with diacritics are handled:

  1.
When a SQL query contains identifiers (table/column names) with diacritics, e.g., "Gel?nde", are the bytes looked up exactly as-is in the dataset, without any UTF-8 conversion?
  2.
When the query contains data values with non-English characters, e.g., 'CC?ri kom XXCX', does GDAL interpret these as UTF-8 (or according to the dataset encoding) internally?

In other words, is it correct to assume that identifiers are matched byte-for-byte, while data values are parsed according to GDAL?s encoding rules, when passing SQL queries via C# bindings?
Any clarification would be appreciated.


BR
John





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260114/6003d576/attachment-0001.htm>

From johnsmith7862025 at outlook.com  Tue Jan 13 21:59:02 2026
From: johnsmith7862025 at outlook.com (John Smith)
Date: Wed, 14 Jan 2026 05:59:02 +0000
Subject: [gdal-dev] =?windows-1252?q?Reading_GeoJSON_with_diacritics_via_?=
 =?windows-1252?q?GDAL_C=23_bindings_=97_identifiers_vs_data_values?=
In-Reply-To: <TYZPR06MB6237D2E8040E61B6810A9AD1888FA@TYZPR06MB6237.apcprd06.prod.outlook.com>
References: <TYZPR06MB6237D2E8040E61B6810A9AD1888FA@TYZPR06MB6237.apcprd06.prod.outlook.com>
Message-ID: <TYZPR06MB62378CA4A4D3A06A0A7E73C3888FA@TYZPR06MB6237.apcprd06.prod.outlook.com>

I am using GDAL 3.9.3 and reading GeoJSON files (saved in ANSI/Windows-1252 encoding) via the GDAL C# bindings. I want to clarify how SQL queries with diacritics are handled:

  1.
When a SQL query contains identifiers (table/column names) with diacritics, e.g., "Gel?nde", are the bytes looked up exactly as-is in the dataset, without any UTF-8 conversion?
  2.
When the query contains data values with non-English characters, e.g., 'CC?ri kom XXCX', does GDAL interpret these as UTF-8 (or according to the dataset encoding) internally?

In other words, is it correct to assume that identifiers are matched byte-for-byte, while data values are parsed according to GDAL?s encoding rules, when passing SQL queries via C# bindings?
Any clarification would be appreciated.


BR
John





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260114/09069ad6/attachment.htm>

From jukka.rahkonen at maanmittauslaitos.fi  Tue Jan 13 23:50:00 2026
From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka)
Date: Wed, 14 Jan 2026 07:50:00 +0000
Subject: [gdal-dev] 
 =?windows-1252?q?Reading_GeoJSON_with_diacritics_via_?=
 =?windows-1252?q?GDAL_C=23_bindings_=97_identifiers_vs_data_values?=
In-Reply-To: <TYZPR06MB62378CA4A4D3A06A0A7E73C3888FA@TYZPR06MB6237.apcprd06.prod.outlook.com>
References: <TYZPR06MB6237D2E8040E61B6810A9AD1888FA@TYZPR06MB6237.apcprd06.prod.outlook.com>
 <TYZPR06MB62378CA4A4D3A06A0A7E73C3888FA@TYZPR06MB6237.apcprd06.prod.outlook.com>
Message-ID: <PA3PR09MB8258E55E5E14FAE3886528F8FD8FA@PA3PR09MB8258.eurprd09.prod.outlook.com>

Hi,

I don't have an answer to your question, but I checked the JSON specification https://www.rfc-editor.org/rfc/rfc8259 and it says:
"JSON text exchanged between systems that are not part of a closed ecosystem MUST be encoded using UTF-8"

-Jukka Rahkonen-

________________________________________
L?hett?j?: gdal-dev <gdal-dev-bounces at lists.osgeo.org> k?ytt?j?n John Smith via gdal-dev <gdal-dev at lists.osgeo.org> puolesta
L?hetetty: Keskiviikko 14. tammikuuta 2026 7.59
Vastaanottaja: Even Rouault <even.rouault at spatialys.com>; David Klaus via gdal-dev <gdal-dev at lists.osgeo.org>
Aihe: [gdal-dev] Reading GeoJSON with diacritics via GDAL C# bindings ? identifiers vs data values

I am using GDAL 3.9.3 and reading GeoJSON files (saved in ANSI/Windows-1252 encoding) via the GDAL C# bindings. I want to clarify how SQL queries with diacritics are handled:When a SQL query contains identifiers?(table/column names) with diacritics, e.g., "Gel?nde", are the bytes looked up exactly as-is?in the dataset, without any UTF-8 conversion?When the query contains data values?with non-English characters, e.g., 'CC?ri kom XXCX', does GDAL interpret these as UTF-8 (or according to the dataset encoding) internally?In other words, is it correct to assume that identifiers are matched byte-for-byte, while data values are parsed according to GDAL?s encoding rules, when passing SQL queries via C# bindings?Any clarification would be appreciated.BRJohn

From jctoney at gmail.com  Wed Jan 14 09:07:05 2026
From: jctoney at gmail.com (Chris Toney)
Date: Wed, 14 Jan 2026 10:07:05 -0700
Subject: [gdal-dev] Documentation for VSIGlob()
Message-ID: <CALRbqOR0x+oyNgy3XaDb8kn15jdCxDGa01Q8TvwQRfHrebj8sA@mail.gmail.com>

Hi,
In the documentation for VSIGlob at https://gdal.org/en/stable/api/cpl.html,
is some outer quote / escaping needed in the last two examples? For example
with

VSIGlob("my_subdir" "/" "*.tif",NULL,...

Thanks.

Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260114/8aeda226/attachment.htm>

From even.rouault at spatialys.com  Wed Jan 14 09:14:48 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Wed, 14 Jan 2026 18:14:48 +0100
Subject: [gdal-dev] Documentation for VSIGlob()
In-Reply-To: <CALRbqOR0x+oyNgy3XaDb8kn15jdCxDGa01Q8TvwQRfHrebj8sA@mail.gmail.com>
References: <CALRbqOR0x+oyNgy3XaDb8kn15jdCxDGa01Q8TvwQRfHrebj8sA@mail.gmail.com>
Message-ID: <37716448-df7d-459c-afc5-110fd7041ae7@spatialys.com>

Hi Chris,

I could pretend the splitting was done on purpose to better highligh the 
file hiearchy, but ... the truth is I believe I had some issues with one 
of the components involve in our documentation building 
(doxygen/breathe/sphinx, or perhaps just C++ that would confuse "*/" 
with an end-of-C-comment marker) to make it happy with "**/*.tif", so I 
ended up falling back to this trick of splitting the string, which is 
exactly equivalent to merging them together.? I guess there must be some 
way of fixing this, but couldn't find it at the time this was written

Even

Le 14/01/2026 ? 18:07, Chris Toney via gdal-dev a ?crit?:
> Hi,
> In the documentation for VSIGlob at 
> https://gdal.org/en/stable/api/cpl.html, is some outer quote / 
> escaping needed in the last two examples? For example with
>
> VSIGlob("my_subdir" "/" "*.tif",NULL,...
>
> Thanks.
>
> Chris
>
>
>
> _______________________________________________
> 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 jctoney at gmail.com  Wed Jan 14 09:28:51 2026
From: jctoney at gmail.com (Chris Toney)
Date: Wed, 14 Jan 2026 10:28:51 -0700
Subject: [gdal-dev] Documentation for VSIGlob()
In-Reply-To: <37716448-df7d-459c-afc5-110fd7041ae7@spatialys.com>
References: <CALRbqOR0x+oyNgy3XaDb8kn15jdCxDGa01Q8TvwQRfHrebj8sA@mail.gmail.com>
 <37716448-df7d-459c-afc5-110fd7041ae7@spatialys.com>
Message-ID: <CALRbqOSe4n+J6RboAoReAjHVsEJvuu8=yhfW+iz+XToU1n9hmA@mail.gmail.com>

Ah yeah I see now. That makes sense. I was confused why that syntax at
first but you're right it does highlight the directory structure at least.

Chris

On Wed, Jan 14, 2026, 10:14 AM Even Rouault <even.rouault at spatialys.com>
wrote:

> Hi Chris,
>
> I could pretend the splitting was done on purpose to better highligh the
> file hiearchy, but ... the truth is I believe I had some issues with one
> of the components involve in our documentation building
> (doxygen/breathe/sphinx, or perhaps just C++ that would confuse "*/"
> with an end-of-C-comment marker) to make it happy with "**/*.tif", so I
> ended up falling back to this trick of splitting the string, which is
> exactly equivalent to merging them together.  I guess there must be some
> way of fixing this, but couldn't find it at the time this was written
>
> Even
>
> Le 14/01/2026 ? 18:07, Chris Toney via gdal-dev a ?crit :
> > Hi,
> > In the documentation for VSIGlob at
> > https://gdal.org/en/stable/api/cpl.html, is some outer quote /
> > escaping needed in the last two examples? For example with
> >
> > VSIGlob("my_subdir" "/" "*.tif",NULL,...
> >
> > Thanks.
> >
> > Chris
> >
> >
> >
> > _______________________________________________
> > 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: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260114/9d2a67a0/attachment.htm>

From andrew at aitchison.me.uk  Fri Jan 16 01:25:20 2026
From: andrew at aitchison.me.uk (Andrew C Aitchison)
Date: Fri, 16 Jan 2026 09:25:20 +0000 (GMT)
Subject: [gdal-dev] Updating requirements to C++20 for GDAL 3.13 ?
In-Reply-To: <CA+K_q_o+Ms+tRH-Cddpa2kVnKD+yUXUKcJDas2bHVBzwFe8GRg@mail.gmail.com>
References: <2e755b13-03fc-4bc5-9724-811f76d3b33d@spatialys.com>
 <CA+K_q_oE8TGD_Bfu8QcrJcrOV1Ys_Yje+8w5dFcfqt48un+Q+A@mail.gmail.com>
 <A9C8B956-567D-4A87-AA25-3DF80A2EC3CB@hobu.co>
 <CA+K_q_o+Ms+tRH-Cddpa2kVnKD+yUXUKcJDas2bHVBzwFe8GRg@mail.gmail.com>
Message-ID: <5561117c-dc50-ad4f-9d80-a2d4333e94cd@aitchison.me.uk>


[ Sorry for the delay in repyling.
   The list server messages have not been reaching my mailbox. ]

On Thu, Dec 18, 2025 at 12:28?PM Howard Butler wrote:
>> and the consequence of that is there is a lot of code in GDAL that could
>> be removed if it were more aggressive about taking advantage of
>> now-standard C++ facilities and constructs. Less code means less to
>> maintain and less to break.

Daniel Baston replied:
> I agree with this as a principle, but looking at C++20 specifically I don't
> see opportunity for significant code removal on the order of C++11 or
> C++17. This thread brings up cpl::contains, cpl::starts_with, and
> cpl::ends_with.

I have long been looking forward to std::span.
Not only does it make some things easier to write safely,
but static analysis options like
 	clang++ -Wunsafe-buffer-usage
are only useful with std::span.

-- 
Andrew C. Aitchison                      Kendal, UK
                    andrew at aitchison.me.uk

From ari.jolma at gmail.com  Sun Jan 18 01:11:23 2026
From: ari.jolma at gmail.com (Ari Jolma)
Date: Sun, 18 Jan 2026 11:11:23 +0200
Subject: [gdal-dev] Reading from (geo)parquet using mixed spatia and
 non-spatiall filters
Message-ID: <65347b6d-f5f8-4a22-b5ef-7f52df2764c9@gmail.com>

Hi all,

I need to read from a large Parquet file (10-20 GB, in S3) features 
using a set of user defined constraints that I can parse into 
non-spatial SQL and polygon masks. My tests so far show good performance 
with a single non-spatial constraint and (separately) with a bbox. 
However, I not sure how to go forward with mixing non-spatial 
constraints and perhaps multiple arbitrary polygons (which may be 
non-adjacent).

 ?GDAL SQL docs tell me that with Spatialite built-in I could use 
ST_Intersects but does that help with Parquet files? How about 
constructing the non-spatial SQL query first, use that on dataset, and 
then use SetSpatialFilterRect on the resulting layer object possibly 
multiple times?plus ogr.Geometry.Intersects on each feature coming from 
the obtained layer? My intuition would tell me to first do the spatial 
filtering as that (may) narrow down the search considerably. But then I 
cannot use the non-spatial SQL as that requires a dataset to be executed on.

The user is actually warned against leaving out the spatial filter as 
the Parquet files contain millions of features and the selection is any 
way truncated to max few hundred features.

Any ideas?

Ari



From even.rouault at spatialys.com  Sun Jan 18 06:50:04 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Sun, 18 Jan 2026 15:50:04 +0100
Subject: [gdal-dev] Reading from (geo)parquet using mixed spatia and
 non-spatiall filters
In-Reply-To: <65347b6d-f5f8-4a22-b5ef-7f52df2764c9@gmail.com>
References: <65347b6d-f5f8-4a22-b5ef-7f52df2764c9@gmail.com>
Message-ID: <0f39d6c5-ad45-467e-aa8f-38d38dd143e1@spatialys.com>

Ari,

> I need to read from a large Parquet file (10-20 GB, in S3) features 
> using a set of user defined constraints that I can parse into 
> non-spatial SQL and polygon masks. My tests so far show good 
> performance with a single non-spatial constraint and (separately) with 
> a bbox. 

Do you mean you get bad performance when setting both 
SetAttributeFilter() and SetSpatialFilter[Rect]() ? I cannot explain 
that. Combining them should not be less performant.

You don't mention if your geoparquet files have a covering bounding box 
column. For the default WKB encoding, this is essential to avoid full 
scan of the file.

> However, I not sure how to go forward with mixing non-spatial 
> constraints and perhaps multiple arbitrary polygons (which may be 
> non-adjacent).
If you have something like attr_filter && (Intersects(geom, poly1) || 
Intersects(geom, poly2))? , then you should do separately??attr_filter 
&& Intersects(geom, poly1)? ?and then attr_filter && Intersects(geom, 
poly2)
>
> ?GDAL SQL docs tell me that with Spatialite built-in I could use 
> ST_Intersects but does that help with Parquet files? 
No, because that wouldn't translate as a SetSpatialFilter[Rect]() 
request, and thus you would get full scan of the file
> How about constructing the non-spatial SQL query first, use that on 
> dataset, and then use SetSpatialFilterRect on the resulting layer 
> object possibly multiple times?plus ogr.Geometry.Intersects on each 
> feature coming from the obtained layer? My intuition would tell me to 
> first do the spatial filtering as that (may) narrow down the search 
> considerably. But then I cannot use the non-spatial SQL as that 
> requires a dataset to be executed on.

You could store the result of the spatial request in a temporary dataset 
(possibly in memory) and then apply the attribute filter. But as said 
above, I'm a bit surprised that combining the attribute filter and a 
(single geometry) spatial filter isn't efficient.

Instead of the Parquet driver, you may also try with duckdb and the ADBC 
driver. The duckdb SQL engine generally outperforms libarrow/libparquet.

Even

-- 
http://www.spatialys.com
My software is free, but my time generally not.


From ari.jolma at gmail.com  Sun Jan 18 08:01:44 2026
From: ari.jolma at gmail.com (Ari Jolma)
Date: Sun, 18 Jan 2026 18:01:44 +0200
Subject: [gdal-dev] Reading from (geo)parquet using mixed spatia and
 non-spatiall filters
In-Reply-To: <0f39d6c5-ad45-467e-aa8f-38d38dd143e1@spatialys.com>
References: <65347b6d-f5f8-4a22-b5ef-7f52df2764c9@gmail.com>
 <0f39d6c5-ad45-467e-aa8f-38d38dd143e1@spatialys.com>
Message-ID: <35299861-05ae-44a5-ab17-fa3fb31bf2e0@gmail.com>

Even Rouault kirjoitti 18.1.2026 klo 16.50:

> Ari,
>
>> I need to read from a large Parquet file (10-20 GB, in S3) features 
>> using a set of user defined constraints that I can parse into 
>> non-spatial SQL and polygon masks. My tests so far show good 
>> performance with a single non-spatial constraint and (separately) 
>> with a bbox. 
>
> Do you mean you get bad performance when setting both 
> SetAttributeFilter() and SetSpatialFilter[Rect]() ? I cannot explain 
> that. Combining them should not be less performant.


No, I'm, just looking for how to best mix spatial and non-spatial 
filters/constraints when retrieving features from a Paquet file using GDAL.


>
> You don't mention if your geoparquet files have a covering bounding 
> box column. For the default WKB encoding, this is essential to avoid 
> full scan of the file.


I don't know about that - will check - but the basic 
SetSpatialFilterRect on a GDAL Python layer works fine.


>
>
>> However, I not sure how to go forward with mixing non-spatial 
>> constraints and perhaps multiple arbitrary polygons (which may be 
>> non-adjacent).
> If you have something like attr_filter && (Intersects(geom, poly1) || 
> Intersects(geom, poly2))? , then you should do separately??attr_filter 
> && Intersects(geom, poly1)? ?and then attr_filter && Intersects(geom, 
> poly2)


Ok, so the attr_filter is not expensive even though it is applied twice.


>
>>
>> ?GDAL SQL docs tell me that with Spatialite built-in I could use 
>> ST_Intersects but does that help with Parquet files? 
> No, because that wouldn't translate as a SetSpatialFilter[Rect]() 
> request, and thus you would get full scan of the file


Ok, I assumed that too.


>
>> How about constructing the non-spatial SQL query first, use that on 
>> dataset, and then use SetSpatialFilterRect on the resulting layer 
>> object possibly multiple times?plus ogr.Geometry.Intersects on each 
>> feature coming from the obtained layer? My intuition would tell me to 
>> first do the spatial filtering as that (may) narrow down the search 
>> considerably. But then I cannot use the non-spatial SQL as that 
>> requires a dataset to be executed on.
>
> You could store the result of the spatial request in a temporary 
> dataset (possibly in memory) and then apply the attribute filter. But 
> as said above, I'm a bit surprised that combining the attribute filter 
> and a (single geometry) spatial filter isn't efficient.


Maybe I was not clear on that I'm at this point wondering how to best 
combine the attribute filter and the spatial filter.


>
> Instead of the Parquet driver, you may also try with duckdb and the 
> ADBC driver. The duckdb SQL engine generally outperforms 
> libarrow/libparquet.


Hm, Parquet files are given at this point - I'm doing 
consultancy/development for a client and Parquet is their choice so I 
guess I have developer role now. :)


>
> Even
>

Thanks,

Ari



From even.rouault at spatialys.com  Sun Jan 18 08:08:48 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Sun, 18 Jan 2026 17:08:48 +0100
Subject: [gdal-dev] Reading from (geo)parquet using mixed spatia and
 non-spatiall filters
In-Reply-To: <35299861-05ae-44a5-ab17-fa3fb31bf2e0@gmail.com>
References: <65347b6d-f5f8-4a22-b5ef-7f52df2764c9@gmail.com>
 <0f39d6c5-ad45-467e-aa8f-38d38dd143e1@spatialys.com>
 <35299861-05ae-44a5-ab17-fa3fb31bf2e0@gmail.com>
Message-ID: <dfdf7f90-7b29-487b-b37e-19bab3309880@spatialys.com>

>
>
>>
>> You don't mention if your geoparquet files have a covering bounding 
>> box column. For the default WKB encoding, this is essential to avoid 
>> full scan of the file.
>
>
> I don't know about that - will check - but the basic 
> SetSpatialFilterRect on a GDAL Python layer works fine.
$ ogr2ogr poly_with_bbox.parquet autotest/ogr/data/poly.shp
$ ogrinfo poly_with_bbox.parquet --debug on
[...]
PARQUET: geo = { ... "covering":{"bbox":{...} }
[...]
PARQUET: Bounding box column 'geometry_bbox' detected for geometry 
column 'geometry'
[...]

vs

$ ogr2ogr poly_without_bbox.parquet autotest/ogr/data/poly.shp -lco 
write_covering_bbox=no
$ ogrinfo poly_without_bbox.parquet --debug on
no mention of bbox in debug traces

>
>
> Hm, Parquet files are given at this point - I'm doing 
> consultancy/development for a client and Parquet is their choice so I 
> guess I have developer role now. :)

To be clear I meant using libduckdb+OGR ADBC as an alternate driver to 
read Parquet files: see https://gdal.org/en/stable/drivers/vector/adbc.html


-- 
http://www.spatialys.com
My software is free, but my time generally not.


From michael.smith.erdc at gmail.com  Sun Jan 18 08:09:05 2026
From: michael.smith.erdc at gmail.com (Michael Smith)
Date: Sun, 18 Jan 2026 11:09:05 -0500
Subject: [gdal-dev] Reading from (geo)parquet using mixed spatia and
 non-spatiall filters
In-Reply-To: <35299861-05ae-44a5-ab17-fa3fb31bf2e0@gmail.com>
References: <65347b6d-f5f8-4a22-b5ef-7f52df2764c9@gmail.com>
 <0f39d6c5-ad45-467e-aa8f-38d38dd143e1@spatialys.com>
 <35299861-05ae-44a5-ab17-fa3fb31bf2e0@gmail.com>
Message-ID: <481F52D3-0345-4DF4-B36E-48245AE4AB47@gmail.com>

I combine attribute and spatial filters a lot on large parquet files using a combination of SetSpatialFilter() and SetAttributeFilter() before querying. I've only had some issues with partition elimination which have now been fixed. Sometimes the ADBC connection can be faster to query but opening the file with gdal.OpenEx() is slower. And ADBC takes more memory. I find the gdal query method generally better. 

Having access to the sql functions of duckdb is the only reason I ever use ADBC. 

Mike


-- 

Michael Smith 
RSGIS Center ? ERDC CRREL NH 
US Army Corps 





?On 1/18/26, 11:02 AM, "gdal-dev on behalf of Ari Jolma via gdal-dev" <gdal-dev-bounces at lists.osgeo.org <mailto:gdal-dev-bounces at lists.osgeo.org> on behalf of gdal-dev at lists.osgeo.org <mailto:gdal-dev at lists.osgeo.org>> wrote:


Even Rouault kirjoitti 18.1.2026 klo 16.50:


> Ari,
>
>> I need to read from a large Parquet file (10-20 GB, in S3) features 
>> using a set of user defined constraints that I can parse into 
>> non-spatial SQL and polygon masks. My tests so far show good 
>> performance with a single non-spatial constraint and (separately) 
>> with a bbox. 
>
> Do you mean you get bad performance when setting both 
> SetAttributeFilter() and SetSpatialFilter[Rect]() ? I cannot explain 
> that. Combining them should not be less performant.




No, I'm, just looking for how to best mix spatial and non-spatial 
filters/constraints when retrieving features from a Paquet file using GDAL.




>
> You don't mention if your geoparquet files have a covering bounding 
> box column. For the default WKB encoding, this is essential to avoid 
> full scan of the file.




I don't know about that - will check - but the basic 
SetSpatialFilterRect on a GDAL Python layer works fine.




>
>
>> However, I not sure how to go forward with mixing non-spatial 
>> constraints and perhaps multiple arbitrary polygons (which may be 
>> non-adjacent).
> If you have something like attr_filter && (Intersects(geom, poly1) || 
> Intersects(geom, poly2)) , then you should do separately attr_filter 
> && Intersects(geom, poly1) and then attr_filter && Intersects(geom, 
> poly2)




Ok, so the attr_filter is not expensive even though it is applied twice.




>
>>
>> GDAL SQL docs tell me that with Spatialite built-in I could use 
>> ST_Intersects but does that help with Parquet files? 
> No, because that wouldn't translate as a SetSpatialFilter[Rect]() 
> request, and thus you would get full scan of the file




Ok, I assumed that too.




>
>> How about constructing the non-spatial SQL query first, use that on 
>> dataset, and then use SetSpatialFilterRect on the resulting layer 
>> object possibly multiple times plus ogr.Geometry.Intersects on each 
>> feature coming from the obtained layer? My intuition would tell me to 
>> first do the spatial filtering as that (may) narrow down the search 
>> considerably. But then I cannot use the non-spatial SQL as that 
>> requires a dataset to be executed on.
>
> You could store the result of the spatial request in a temporary 
> dataset (possibly in memory) and then apply the attribute filter. But 
> as said above, I'm a bit surprised that combining the attribute filter 
> and a (single geometry) spatial filter isn't efficient.




Maybe I was not clear on that I'm at this point wondering how to best 
combine the attribute filter and the spatial filter.




>
> Instead of the Parquet driver, you may also try with duckdb and the 
> ADBC driver. The duckdb SQL engine generally outperforms 
> libarrow/libparquet.




Hm, Parquet files are given at this point - I'm doing 
consultancy/development for a client and Parquet is their choice so I 
guess I have developer role now. :)




>
> Even
>


Thanks,


Ari




_______________________________________________
gdal-dev mailing list
gdal-dev at lists.osgeo.org <mailto:gdal-dev at lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/gdal-dev <https://lists.osgeo.org/mailman/listinfo/gdal-dev>





From j1 at jimenezshaw.com  Wed Jan 21 05:13:01 2026
From: j1 at jimenezshaw.com (Javier Jimenez Shaw)
Date: Wed, 21 Jan 2026 14:13:01 +0100
Subject: [gdal-dev] reading raster from memory
Message-ID: <CADRrdKvbwW_uospuxqTcyQwuNSvC2UEB4SbfeqyjfdiqxpnaKA@mail.gmail.com>

Hi

I am preparing a PR to read the Embedded image from a FLIR jpeg file
(another image inside the FLIR, yes). I am confused about how to implement
one step, avoiding leaks or invalid memory access.

Taking the funcion JPGDatasetCommon::OpenRawThermalImage
(gdal/frmts/jpeg/jpgdataset.cpp) as a reference (when the thermal image is
PNG), if I understand correctly, the steps are:

- copy the data into "GByte *pabyData"
- call "VSILFILE *fpRaw =
VSIFileFromMemBuffer(osTmpFilename.c_str(), pabyData, ... , true)" with the
last parameter to true, so VSI is taking care of the memory.
- call immediately "VSIFCloseL(fpRaw);" (as I said, the thermal image is a
PNG, so I ignore the block in between)
- create a dataset with "auto poRawDS
= GDALDataset::Open(osTmpFilename.c_str(), ...)"
- call "VSIUnlink(osTmpFilename.c_str());" to close the temporary file
- "return poRawDS;"

Calling VSIFCloseL is not deleting the data before
calling GDALDataset::Open?
Calling VSIUnlink is not loosing the access to the data in poRawDS, before
it can be used?

Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260121/036f31df/attachment.htm>