What is the bug or the crash?
The latest version of QGIS is not displaying the raster attribute table (RAT) from S-102 correctly. Specifically, it appears that incorrect data is ending up in the columns. Fields like "sourceSurveyID" are displaying boolean values but should be strings.
RATs were added to S-102 in version 2.2. S-102 3.0 test files can be found here. I have confirmed the data appears correct in these files using HDF5 readers and also using GDAL.
New RAT data types were added into GDAL, and specifically datetime and boolean data types are being used for the S-102 data. I suspect, although I'm not sure how to confirm, that something with reading the data in its new type is not working as expected.
Steps to reproduce the issue
Open a test file from the provided link in QGIS and view the RAT.
Open the same file with GDAL and view the RAT.
Compare the available data.
Versions
| QGIS version | 3.44.5-Solothurn |
| QGIS code revision | 5c593399236 |
| |
| Libraries |
| Qt version | 5.15.13 |
| Python version | 3.12.12 |
| GDAL version | 3.12.0 — Chicoutimi |
| PROJ version | 9.7.0 |
| EPSG Registry database version | v12.022 (2025-08-30) |
| GEOS version | 3.13.1-CAPI-1.19.2 |
| SQLite version | 3.50.4 |
| PDAL version | 2.9.0 |
| PostgreSQL client version | 17.3 |
| SpatiaLite version | 5.1.0 |
| QWT version | 6.3.0 |
| QScintilla2 version | 2.14.1 |
| OS version | Windows 11 Version 2009 |
| |
| Active Python plugins |
| crayfish | 4.0.0 |
| cruisetools | 2.3 |
| firstaid | 3.2.1 |
| loadthemall | 3.4 |
| pluginbuilder3 | 3.2.1 |
| plugin_reloader | 0.18 |
| profiletool | 4.3.3 |
| qduckdb | 2.2.6 |
| quick_map_services | 1.1.0 |
| Serval | 3.32.0 |
| processing | 2.12.99 |
Supported QGIS version
New profile
Additional context
No response
What is the bug or the crash?
The latest version of QGIS is not displaying the raster attribute table (RAT) from S-102 correctly. Specifically, it appears that incorrect data is ending up in the columns. Fields like "sourceSurveyID" are displaying boolean values but should be strings.
RATs were added to S-102 in version 2.2. S-102 3.0 test files can be found here. I have confirmed the data appears correct in these files using HDF5 readers and also using GDAL.
New RAT data types were added into GDAL, and specifically datetime and boolean data types are being used for the S-102 data. I suspect, although I'm not sure how to confirm, that something with reading the data in its new type is not working as expected.
Steps to reproduce the issue
Open a test file from the provided link in QGIS and view the RAT.
Open the same file with GDAL and view the RAT.
Compare the available data.
Versions
Supported QGIS version
New profile
Additional context
No response