OSGeo
A new driver to support MiraMon’s raster data format
Feature description
Dear all, Following the integration of the MiraMonVector driver in GDAL 3.9, which provides support for the vector format of the MiraMon GIS, we are now willing to integrate the development of a new driver to support MiraMon’s raster data format. In line with the previous naming convention, this new driver will be called MiraMonRaster.
General Information
The technical documentation is available on the official website: 👉 https://www.miramon.cat/eng/NotesTecniques.htm Under the title: Format specification of the MiraMon raster files. 👉https://www.miramon.cat/new_note/eng/notes/MiraMon_raster_file_format.pdf The development will be carried out in two main phases:
- Reading support
- Writing support, once the reading phase is validated—similarly to the vector driver development process.
Objective
Our intention is to contribute this new driver to the GDAL project once it is fully implemented and thoroughly tested. With this contribution, we aim to facilitate the access of the MiraMon open raster format to the broader community—students, researchers, GIS professionals, public administrations, and individual users—who currently work with this format. We are available to answer any questions or provide clarifications regarding the format.
Development Plan
- MiraMonRaster reader development The implementation will be done in C++, leveraging portions of code from the MiraMonVector driver (previously accepted during its 2024 development). We plan to start with reading support to ensure broader accessibility.
- Test generation A Python script will be created to perform comprehensive tests, including:
- Metadata reading (single-band and multiband)
- Pixel value reading (for each band)
- Palette color retrieval (for each band)
- Lookup table values from the associated DBF (or extended DBF if needed, already defined in https://www.miramon.cat/new_note/eng/notes/DBF_estesa.pdf and already used in MiraMonVector) Tests will also cover single-band and multiband scenarios, including spatial reference extent checks, palettes and so...
- Actions and Pull Request Once development is complete and all GDAL Actions pass across platforms, we will submit a Pull Request for review.
- Writing implementation After the reading capabilities are reviewed and accepted, we will proceed with implementing writing functionality, using a similar structure.
Technical Summary of the MiraMonRaster Format
Technical documentation: https://www.miramon.cat/new_note/eng/notes/MiraMon_raster_file_format.pdf Summary: Main file extension: .img Associated metadata file: I.rel The format supports:
- Compression
- Rich metadata (including georeferencing)
- Associated palettes in DBF files
- Tables of categories in DBF files
- Multi-band datasets (RGB is a special case)
Note: Although GDAL already supports files with the .img extension (e.g., the HFA driver: https://gdal.org/en/stable/drivers/raster/hfa.html), the MiraMon format differs in structure, metadata location, compression mechanisms, palette location, possibility of thesaurus...
Supported Data Types
- byte: from 0 to 255 (8-bit unsigned) – 1 byte
- integer: from -32,768 to 32,767 (16-bit signed) – 2 bytes
- uinteger: from 0 to 65,535 (16-bit unsigned) – 2 bytes
- long: from -2,147,483,648 to 2,147,483,647 (32-bit signed) – 4 bytes
- real: approximately from -3.4×10±38 to 3.4×10±38 (32-bit float, 6-9 significant figures of precision) – 4 bytes
- double: approximately from -1.7×10±308 to 1.7×10±308 (64-bit float, 15–17 significant figures digits of precision) – 8 bytes
Each data type can be stored compressed or uncompressed. Available compression methods:
- Classic RLE: row-based compression based on repeated pixel values (efficient for categorical data)
- Extended RLE: optimized RLE that avoids redundant encoding of non-repeated pixels
- In all cases, the format supports optional indexing after the last pixel for faster access.
For all types:
- A palette may be associated For all types, except real and double:
- A DBF (or extended DBF table) may be used to associate pixel values with alphanumerical tables (typically containing categorical descriptions or identifiers from vector features rasterization)
Multi-band File Characteristics
- Multi-band files are linked via a single .rel file containing metadata for all bands
- Each band may have its own number of rows/columns, bounding box and cell size
We remain at your disposal for any questions you may have. Thank you very much for your time and support. Best regards, The MiraMon Development Team
Additional context
No response
- A palette may be associated
Exposed using the GDALColorTable mechanism ?
A DBF (or extended DBF table) may be used to associate pixel values with alphanumerical tables (typically containing categorical descriptions oor identifiers from vector features rasterization)
Exposed using the GDALRasterAttributeTable mechanism ?
- A palette may be associated
Exposed using the GDALColorTable mechanism ?
A DBF (or extended DBF table) may be used to associate pixel values with alphanumerical tables (typically containing categorical descriptions oor identifiers from vector features rasterization)
Exposed using the GDALRasterAttributeTable mechanism ?
Yes, the intention is to translate the values from our DBF into the format required by the GDALColorTable or GDALRasterAttributeTable. Thanks for asking!
In the case of MiraMon, multiple files can be linked through a single I.REL file. This file contains information about each of the IMG files that make up the dataset. There are no restrictions regarding the raster size (in pixels and lines) or cell size, and these properties may differ between them.
What would be the appropriate model to generate a correct translation of this structure? A dataset should be created for each group of bands sharing the same characteristics, resulting in a single dataset in the best case, or N > 1 datasets if, for example, there are multiple bands with different cell sizes (as is the case in some Landsat satellite images, which include several 30 m bands and one 15 m band plus the thermal bands at different resolution).
Thanks for clarifying that!
I guess the file that would be opened through GDALOpen() would be the .REL file ?
A dataset should be created for each group of bands sharing the same characteristics, resulting in a single dataset in the best case, or N > 1 datasets if, for example, there are multiple bands with different cell sizes (as is the case in some Landsat satellite images, which include several 15 m bands and one 30 m band).
Yes, sounds reasonable. The Sentinel2 driver does that exposing as many subdatasets as there are resolutions: $ gdalinfo autotest/gdrivers/data/sentinel2/fake_l1c/S2A_OPER_PRD_MSIL1C.SAFE/S2A_OPER_MTD_SAFL1C.xml
[...]
Subdatasets:
SUBDATASET_1_NAME=SENTINEL2_L1C:autotest/gdrivers/data/sentinel2/fake_l1c/S2A_OPER_PRD_MSIL1C.SAFE/S2A_OPER_MTD_SAFL1C.xml:10m:EPSG_32632
SUBDATASET_1_DESC=Bands B2, B3, B4, B8 with 10m resolution, UTM 32N
SUBDATASET_2_NAME=SENTINEL2_L1C:autotest/gdrivers/data/sentinel2/fake_l1c/S2A_OPER_PRD_MSIL1C.SAFE/S2A_OPER_MTD_SAFL1C.xml:20m:EPSG_32632
SUBDATASET_2_DESC=Bands B5, B6, B7, B8A, B11, B12 with 20m resolution, UTM 32N
SUBDATASET_3_NAME=SENTINEL2_L1C:autotest/gdrivers/data/sentinel2/fake_l1c/S2A_OPER_PRD_MSIL1C.SAFE/S2A_OPER_MTD_SAFL1C.xml:60m:EPSG_32632
SUBDATASET_3_DESC=Bands B1, B9, B10 with 60m resolution, UTM 32N
SUBDATASET_4_NAME=SENTINEL2_L1C:autotest/gdrivers/data/sentinel2/fake_l1c/S2A_OPER_PRD_MSIL1C.SAFE/S2A_OPER_MTD_SAFL1C.xml:PREVIEW:EPSG_32632
SUBDATASET_4_DESC=RGB preview, UTM 32N
$ gdalinfo SENTINEL2_L1C:autotest/gdrivers/data/sentinel2/fake_l1c/S2A_OPER_PRD_MSIL1C.SAFE/S2A_OPER_MTD_SAFL1C.xml:10m:EPSG_32632
[...]
Band 1 Block=128x128 Type=UInt16, ColorInterp=Red
Description = B4, central wavelength 665 nm
[...]
Band 2 Block=128x128 Type=UInt16, ColorInterp=Green
Description = B3, central wavelength 560 nm
[...]
I guess the file that would be opened through GDALOpen() would be the .REL file ?
in general, users are used to opening IMG files directly. In the future, it would be great if QGIS, for instance, could open a MiraMon IMG file seamlessly. The way I plan to handle this is: when an IMG is opened, a small routine will look for the corresponding REL file in the same directory—usually with the same name but no extension, ending in I.rel for single-band, or a similar multiband version also ending in I.rel. This REL file indicates which bands are present, and it must include at least one band matching the IMG filename. Also, as a general rule, opening an IMG file with an associated multiband REL implies that all bands listed in the REL should be opened—unless specified otherwise through an "open option" indicating that only the specific band should be loaded.
That said, I do see a clear advantage in allowing GDALOpen() to also accept an I.REL file directly, interpreting it as a request to import all the datasets or bands listed in it.
Great example the Sentinel2 one.
Hi,
A pull request has been submitted: https://github.com/OSGeo/gdal/pull/12841.
I hope the code is clear. I’ve reused some logic from the vector side, particularly for reading DBF files and certain metadata handling.
AI assistance was used only for consultation purposes — mainly for generating small Python snippets, which I subsequently reviewed and fully understood, as well as for improving the clarity of the English writing.
If any part is unclear or needs adjustment, I’ll be available in September to answer questions or consider any suggestions reviewers may have.