[gdal-dev] Codepage or UTF-8 in a metadata file Filename.aux in the Erdas Imagine format, describing a Filename.tif

[Mikael Rittri]

Thank you, Even and Jukka.

Jukka: If the .rrd and .rde files just contain overviews, then they are irrelevant for my purpose. The .tif file itself doesn’t give me problems, but I want to extract its Raster Attribute Table, and it seems that I can read it from the .aux file via GDAL whether or not the .rrd and .rde files are present. That’s good to know. (I mean, it’s good for me to know which sidecar files I can ignore since there are a lot of them: some Erdas ones and some Esri ones and some that I don’t recognize at all.)

Even: Thanks for the link to the format description. Since I, too, fail to find anything about character encoding there, I suppose the format is neutral about that, and then GDAL just retrieves the byte sequences as they are. So I ought to make my software more robust when handling the retrieved strings, which is also good to know.

Regards,

Mikael Rittri
Carmenta Geospatial Technologies
Sweden
carmenta.com

From: gdal-dev <gdal-dev-bounces at lists.osgeo.org> On Behalf Of Even Rouault
Sent: Monday, 26 June 2023 14:06
To: gdal-dev at lists.osgeo.org
Subject: Re: [gdal-dev] Codepage or UTF-8 in a metadata file Filename.aux in the Erdas Imagine format, describing a Filename.tif


This message was sent from outside of Carmenta. Please do not click links or open attachments unless you recognize the source of this email and know the content is safe.



Mikael,

to my surprise, the HFA format is actually published at https://hexagongeospatial.fluidtopics.net/r/fH0o7KrMKUViXGUeoilQuA/5DlRUpslzb6NK6uTz98KSg . Not sure if it is "new" or had already been available. From a quick look, it doesn't mention anything about string encoding.

My intuition would be that the encoding would be whatever the one of the machine generated the file was, but perhaps that's a fixed one. You could potentially try to ask Hexagon support about that.

GDAL itself makes not that many assumptions about the encoding, although it tries to expose as UTF-8 as much as possible (and recode to UTF-8 when it knows the source encoding), otherwise it will present strings as they are, hoping for the best. But language bindings might make stronger assumptions and indeed misbehave when UTF-8 is not encountered

Even
Le 26/06/2023 à 11:43, Mikael Rittri a écrit :
Hello list.

I have encountered a Filename.tif with an associated metadata file, Filename.aux. The .aux file can be understood by gdalinfo, which says

Driver: HFA/Erdas Imagine Images (.img)
Files: Filename.aux
       Filename.rrd
       Filename.rde

As I understand it, the .aux file is on an Erdas Imagine format intended to describe metadata for the Erdas .img format, but it can also be used to describe metadata for .tif files as in my case. (I have the Filename.rrd and the Filename.rde but not any Filename.img, so it is somewhat strange but useful that GDAL can read the .aux file directly).

Anyway, my question is: when the Filename.aux contains strings, in my case descriptions of terrain types represented by integers (part of a Raster Attribute Table), is there an established way to figure out whether the strings are stored in UTF-8, or if not, what codepage is used? In my case, the strings seem to be stored as 8-bit ASCII using the codepage 1252 (mainly for West-European alphabets), but GDAL seems to expect UTF-8 so the Swedish characters with diacritics become garbled.

I realize that if the .aux format is proprietary and has just been reverse-engineered, then maybe no-one knows the answer to this. But I am curious if anyone has had similar problems and maybe figured out a workaround. Or if there are any grounds to say that UTF-8 is mandatory in the .aux format, then my example file would be incorrect and that would also be useful to know.

Best regards,

Mikael Rittri
Carmenta Geospatial Technologies
Sweden
carmenta.com






_______________________________________________

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<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/20230626/694b8089/attachment-0001.htm>