• GDALMM: File import with GDAL/OGR libraries

Direct access to online help: GDALMM

Access the application from the menu: "File | Import | Files via GDAL/OGR"

Presentation and options

This application allows importing raster, vector and tabular formats into MiraMon formats through the GDAL/OGR libraries. It is expected that, in the future, the application will also be able to export the aforementioned formats; in the meantime, the GDAL libraries https://trac.osgeo.org/osgeo4w/#QuickStartforOSGeo4WUsers to execute instructions such as ogr2ogr can be installed.

The possible options are:

Information: Provides information about the file in a format importable via GDAL/OGR.

Importing a file using GDAL/OGR libraries.: Import the file, or a subset of its elements, using GDAL/OGR libraries.

Since its origins, in 1994, MiraMon has been developing a significant part of its own code to be able to access other common formats in the field of Geographic Information Systems and Remote Sensing, mostly through their import, although in some cases the direct access to other formats has been allowed (such as JPEG for visualization and for geometric image rectification). On the other hand, the maturity of the codes of the excellent GDAL/OGR initiative, started in the 2000s, meant that in 2024 MiraMon focused not only on the publication of the code to make MiraMon formats accessible in the GDAL/OGR environment, but also the direct reading of many other formats in the main MiraMon module (MM64). This initiative also gradually benefited other applications (RasSelec, VecSelec, etc) and stimulated the creation of the GDALMM application, which allows the unification in a single environment of the individual or mass import (via BAT, PS1, etc) of files of the wide variety of formats that GDAL/OGR allows to read.

Despite the incorporation of GDAL/OGR codes into MiraMon in 2024, MiraMon has not abandoned its reading and/or import codes for certain formats so that users of the program can continue to access formats for which the GDAL/OGR libraries do not yet provide access (such as the CEOS formats of the European Space Agency for Landsat data, the VEC/DVC format, etc), or do not allow the recovery of certain features of interest (such as aspects of symbolization in DXF, aspects of OEM-ANSI-UTF8 character sets in tables and text files, optimal treatment of NoData values, etc).

Limitations:

• As of 2019, GDAL/OGR libraries does not support 32-bit versions of their codes, and therefore the GDALMM application is not accessible on computers where the operating system is 32-bit.
• The GDAL/OGR data model (or the formats written by its libraries) do not support, or does not fully support, some features of the MiraMon data model, and vice versa, such as the vector model, and certain characteristics may be lost. To find out how to manage some of these losses, the section MiraMonVector driver of the GDAL documentation can be consulted. If in doubt, please contact with suport@miramon.uab.cat. The main losses that can occur are indicated below:
• The topological relations (always).
• The 1-to-many cardinality between graphic elements and the main alphanumeric attribute table (always). MiraMonVector driver explains how to mitigate this loss.
• The relational model of tables that can be linked to a main table (always). If the layer to be exported has relationships with several tables, remember that a single table can be created from MiraMon (option 17 of the GestBD application) and, although the relational model will be lost in the output format, all the information will be available.
• The multiple Z for the same XY coordinate (always ). MiraMonVector driver explains how to mitigate this loss, specifying which Z of the available is wanted to export.
• The long names in table fields (depending on the formats).
• The fields in tables of more than 254 fields (depending on the formats).
• The text fields (C) of more than 254 characters (depending on the formats).
• The space saving in vector entities with a constant Z, such as contour lines or building roofs in simple models (always).
• The symbolization in vector formats (always), although their interoperability is expected to be implemented soon.
• Some complex geometric features that are not included in the MiraMon data model (very rarely used).
• The complete metadata model (always), although some features can be preserved. MiraMonVector driver explains how to mitigate this loss, explaining the metadata documentation language. Below are several aspects that are lost:
• Units of those numeric fields that have them.
• Quality parameters.
• Specifications of the radiometric properties of images captured with remote sensing sensors.
• True minimum and maximum values of raster sets.

Note: The total or partial loss of these capabilities is not a defect of this implementation (GDALMM) but a consequence of the design of the GDAL/OGR model itself and of the design of the other formats and data models, with limitations that make complete format interoperability unfeasible. However, the high capacity for interoperability that GDAL/OGR allows must be recognized and valued very positively.

Particularities of the transformations carried out by GDALMM:

A GDAL file can contain one or more sets of information described below:

• Vector Layers
• of point or multipoint type: it is converted into a points .pnt
layer
• of line or multiline type: it is converted into an arcs .arc
layer
• of polygon or multipolygon type: it is converted into a polygons .pol
layer
• of undefined type: it is converted into one or more layers of points, arcs, polygons or DBF tables (or Extended DBF if necessary), depending on its content. For example, if the file only contains non-geometric elements the result will be a single DBF file.
• Raster layers
• with one band: it is converted into a single band .img
raster layer
• with several bands: it is converted into a multiband .img raster layer (several .img files linked through their I.rel file).
• with one or several subsets of information (subdatasets): it is converted into several single band or multiband .img layers depending on the original content.

It should be noted that:

• The resulting vector files do not have a verified topology.
• Vector files containing multipoints and multiline objects are converted to .pnt and .arc layers, respectively. In this conversion, each multipoint object is converted into several points and each multiline object into several arcs. This does not happen with polygons since the MiraMon data model does support multipolygons.
• The files that can be opened with GDAL are, in general, of vector or raster type and both types can have associated attribute tables. These tables are imported by generating a DBF file, in extended DBF format if necessary.
• The vector layers of the files can contain, in some cases, more than one element type (for example, points and polygons). All types will always be imported, resulting in several layers in MiraMon format with the same name but with the corresponding extensions.

Dialog box of the application

GDALMM dialog box.

Examples

Import all items from a file into a directory

GDALMM 1 d:\layers\territorial-topography.gpkg  d:\output_layers\TerritorialTopography /TIPUS_SORTIDA=D
GDALMM 1 d:\layers\territorial-topography.gpkg  d:\output_layers\TerritorialTopography

on:

territorial-topography.gpkg corresponds to the source file located in the directory d:\layers
TerritorialTopography corresponds to the output directory, which will be created automatically if it does not exist previously, located within the directory d:\output_layers
/TIPUS_SORTIDA is the optional parameter that indicates that the result of the import is to be saved in an output directory (D), although it would not be necessary in this case, as this is the default option of the application.

After import, this directory will contain all the elements of the source file in MiraMon format.

Import a subset of items from a file into a directory

GDALMM 1 d:\layers\territorial-topography.gpkg  d:\output_layers\TerritorialTopography d:\layers\selection.lst

on:

territorial-topography.gpkg corresponds to the source file located in the directory d:\layers
TerritorialTopography corresponds to the output directory, which will be created automatically if it does not exist previously, located within the directory d:\output_layers
selection.lst corresponds to the list file (.lst) containing the elements to be imported, which must be in the same directory as the source file (as in this case d:\layers) or in another directory with the file names in absolute or relative format to the name of the directory containing the file to be imported. This selection file can be built from the application window

After import, this directory will contain the subset of elements selected in the list selection.lst in MiraMon format. In this case the optional parameter /TIPUS_SORTIDA has not been indicated for the reasons explained in the previous example.

Import all elements of a file into a layer or multiple layers in MiraMon format by renaming the destination layers

GDALMM 1 d:\layers\MonumentalTrees.gpkg  d:\output_layers\CatalogatedMonumentalTrees.pnt /TIPUS_SORTIDA=F

on:

MonumentalTrees.gpkg corresponds to the source file, which contains only one layer, located in the directory d:\layers
CatalogatedMonumentalTrees.pnt corresponds to the output file with the desired name, located in the directory d:\output_layers which must exist previously
/TIPUS_SORTIDA corresponds to the optional parameter that indicates that the result of the import is a file (F). In this case it is necessary to indicate it since, otherwise, a directory called d:\output_layers\MonumentalTrees.pnt would be created and all the elements of the MonumentalTrees.gpkg file would be imported inside it

After the import, all the elements of the source file will be available in one or more files, according to the type of object of the source layer (point, arc or polygon) renamed and in the MiraMon format. For example, monumental trees that are point type elements will be imported as .pnt, monumental groves that are polygonal elements will be imported as .pol, etc.

Import a single element from a file containing multiple elements into a file in MiraMon format

GDALMM 1 d:\layers\territorial-topography.gpkg  d:\output_layers\TerritorialTopography\45_selected_layer.pol d:\layers\one_elem_selected.lst /TIPUS_SORTIDA=F

on:

territorial-topography.gpkg corresponds to the source file located in the directory d:\layers
45_selected_layer.pol corresponds to the output file with the desired name, located in the directory d:\output_layers\TerritorialTopography which must exist previously
one_elem_selected.lst corresponds to the list (lst) file containing the element to be imported, which must be in the same directory as the source file or in another directory with the files names in absolute or relative format to the name of the directory containing the file to be imported. This selection file can be built from the application window
/TIPUS_SORTIDA is the optional parameter that indicates that the result of the import is to be saved in an output file (F). In this case it is necessary to indicate it since, otherwise, a directory called 45_selected_layer.pol would be created and inside it the selected element from the territorial-topography.gpkg file would be imported

After the import, the source file element selected by the list will be available in one or more files, according to the type of source layer object selected (point, arc or polygon), in MiraMon format. As previously explained, it is also possible to rename the files during the import.