HORIZONTAL REFERENCE SYSTEM (GeM+)
Section [SPATIAL_REFERENCE_SYSTEM:HORIZONTAL] (REL file)


Name of GeM+ entry: Type
Name of REL file key: HorizontalSystemDefinition

Description and considerations: The reference frame or system with respect to which linear or angular quantities are measured and assigned to the location of a point.

It may take the following values:

See the explanation of the equivalence between this key and the "ref. system" entry in the older documentation files in the "Description" key.

The default value is Cartographic. When the key has this value it is not written to the REL file.

Follows the proposal of: The FGDC

Obligatory according to the FGDC: Yes

Cardinality: 1

Key type: C

AppliesToLayer: Yes
AppliesToSeries: Yes

Back
(Back to index)

Name of the GeM+ entry: Description
Name of the REL file key: HorizontalSystemIdentifier

Description and considerations: A geodesic reference system should be identified uniquely by an acronym or a short abbreviation of the full name, e.g. WGS84, such that this identifier is the route for identifying all the parameters of the reference system (projection, projection parameters, datum, etc).

This identifier allows all the parameters of the reference system to be known through its relation with geodesic tables. The principal table of a set of tables is called m_geodes.dbf and contains the identifiers of the reference system, its description (full name) and other information about the projection (m_proj.dbf), the projection parameters (m_parproj.dbf), the datum (m_datum.dbf) and the reference ellipsoid (m_ellip.dbf). All these tables are supplied by MiraMon and are located in the MiraMon directory.

The user can create their own geodesic tables (with the same names as the MiraMon tables but preceded by "u_" instead of "m_") with the same structure and relations as the MiraMon tables. These tables should be located in the program directory and can contain other reference systems (with a parameter set that is different from those supplied with the program). Care must be taken to ensure that the identifiers of the user-defined reference systems do not coincide with those defined in the MiraMon table (m_geodes.dbf).

There is a final option consisting of storing all the information about the reference system in the REL file. This method is particularly interesting for interchanging information between users (with different u_*.dbf geodesic tables). In this case the REL file should contain, as well as the reference system identifier, the full set of keys that define the system. By convention and for similarity with the geodesic table method, the names of these keys in the REL file follow the rule tabl_name.field_name. For example, to document the description of a reference system in the REL file it is necessary to use a key called geodes.DESCGEODES since normally this information is found in the field "DESCGEODES" in the table *_geodes.dbf.

In the cases where the horizontal reference system is local (HorizontalSystemDefiniton=Local) the Identifier key is not obligatory since it is unnecessary to refer to an identifier that relates to the geodesic tables. Nevertheless, it may be useful to save a local system identifier to allow users to know which of these systems may be overlain or not. For example:

HorizontalSystemDefiniton=Local
HorizontalSystemIdentifier=Enlargement of the Port of Barcelona

cannot be overlain on:

HorizontalSystemDefiniton=Local
HorizontalSystemIdentifier=Barcelona Airport

In the particular case that this key is literally "plane" it will indicate any flat and arbitrary Cartesian system. This is useful for scanned documents, planes without georeferences, etc.


* Equivalence between the "ref. system" entry in the older documentation files and the geodesic tables system:

The "ref. system" key in the older documentation files may contain various pieces of information that are now located in different places within the geodesic tables.

In the case where "ref. system" is "plane":

ref system : plane HorizontalSystemDefiniton=Local
( HorizontalSystemIdentifier= )
(the key may not be present)

The rest of the values that could be found in the "ref. system" entry do not refer to the Definition of Reference System (HorizontalSystemDefinition= ,key) but rather to a specific reference system. For each of the other values of "ref. system" the following keys will be generated:

HorizontalSystemDefiniton=Cartographic
HorizontalSystemIdentifier= ...

where the value of HorizontalSystemIdentifier= is that which corresponds in function to the specific value of "ref. system". For example:

ref system : UTM-31N HorizontalSystemDefiniton=Cartographic
HorizontalSystemIdentifier=UTM-31N-UB/ICC
ref system : Goode_Homolosine

HorizontalSystemDefiniton=Cartographic
HorizontalSystemIdentifier=Goode_Homolosine-WGS84

Follows the proposal of : the CEN

Obligatory according to the CEN: Yes

Cardinality: 1

Key type: C

AppliesToLayer: Yes
AppliesToSeries: Yes

Back
(Back to index)

Name of the GeM+ entry: Units
Name of the REL file key: unitats

Description and considerations: Units of measurement of the horizontal reference system, used for the latitude and longitude values (in a geographic reference system) or for distance measurements (in a planar reference system, cartographic or local).

Example of possible values:

It is often useful to distinguish when the units are unknown or there are no units so for this reason GeM+ provides the option to choose one of the following three possibilities using a radial button:

- choose one of the options shown or write the name of another unit.
- the system has no units.
- the units are unknown.

For the case where the units are unknown, the REL file will store the record "unitats=?". This is the default value when the key is not found in the file. To indicate that there are no units the REL file will contain an empty key ("unitats="). For the cases where the units take one of the values from the pull-down list, then the REL file will contain the symbol for that unit (for instance, if the choice from the list was "metres", the REL file will contain "unitats=m"). When the units are input by the user, and not selected from the pull-down list, then the whole character string written by the user will appear in the REL file.

This scheme for documenting units will be applied to other aspects of the metadata, like for example the units of the fields in the database (in the tag about Thematic Information).

For the case of the spatial reference system, it is only permissible to select no units in the case of a "local" reference system.

Follows the proposal of: the FGDC

Obligatory according to the FGDC: Yes

Cardinality: 1

Key type: C

AppliesToLayer: Yes
AppliesToSeries: Yes

Back
(Back to index)

Name of the GeM+ entry: Resolution
Name of the REL file key: resolution (see the key in case of raster and vector) and ResolutionY (see the key in case of raster and vector)

Description and considerations: By "resolution" is meant the minimum significant spatial unit or the sampling distance (for rasters). The resolution can be different in the X and Y directions, so GeM+ shows two keys: "Resolution in X" and "Resolution in Y ". According to the FGDC the resolution is "the minimum difference between two independently measured or computed values which can be distinguished by the measurement or analytical method being considered or used, expressed in Units distance".

This concept should not be confused with "precision" (not yet implemented) which refers to the number of significant figures with which numerical data can be stored (for example the planimetric precision refers to the number of significant figures with which coordinates are saved), nor should it be confused with the cell size (which only applies to rasters).

It is worth noting that this definition of resolution is a change from that used by MiraMon up to version 4 and converges with that used by Idrisi in its help related to the older documentation files. For this reason MiraMon will NOT complain about anything said as "resolution=" in relation to the calculations that MiraMon performs with the cell size.

In the conversion of the older documentation files, if the key "resolution :" is empty or contains a non-numeric value, then no value is set in the new metadata file. On the other hand, a numerical entry in the "resolution :" key will be assigned to "Resolution in X" and to "Resolution in Y".

In the case of a multi-band layer it is possible to document, for each band, a different value for this key from the general value (see the Thematic Information section). It is for this reason that there is a radial button in GeM+ (when dealing with a multi-band layer) that allows either the general data to be displayed or the data for the selected band (this selection is performed using the pull-down menu or the forward and back buttons located in the upper part of the GeM+.)


NOTE: The resolution in X and Y refer to the resolution in X and Y in the current reference system, not in whatever the system may have been for the layer in the previous phase. This is especially important when dealing with rasters acquired by remote sensing sensors which, during the geometric correction process usually experience a rotation of the reference system axes.

For example, an MSS image has a nominal resolution of 57m in X (columns) and 79m in Y (rows). These data are valid in the almost-raw (system corrected) format in which MSS data are distributed, but once geometrically corrected in order to georeference the image to the cartographic reference system of interest (UTM for example, etc), the new system X,Y will be rotated with respect to the original X,Y by the correction process so it would be necessary to recalculate the resolutions in X and in Y with a rotation factor that had been applied to the image.

The rigorous calculation of this factor is not trivial, and so the figure that is given is usually approximate. This in itself is not normally a problem since the parameter "resolution" is only an indicative approximation, especially for scanning sensors (with overlapping rows between scans) and in those for which the altitude above the terrain is nominal for each point (due to relief, inaccuracies in the determination of altitude, etc.)

Finally, it must be said that in many cases it may be admissible not to apply any correction with respect to the resolution of the original image and to simply document this. This is justifiable when the rotation is small, which is the usual case for the majority of remote sensing heliosynchronous platforms, that are almost polar, and the majority of cartographic projection systems which have north approximately aligned with the Y axis.

Follows the proposal of: The FGDC

Obligatory according to the FGDC: Yes

Cardinality: 1

Key type: N

AppliesToLayer: Yes
AppliesToSeries: Yes

Back
(Back to index)

Name of GeM+ entry: Resolution units
Name of REL file key: ResolutionUnits (general value and band value)

Description and considerations: The resolution units of the horizontal reference system. Often it is necessary to document these units as they may be different from the horizontal reference system units. For example, in a remotely sensed image that has not yet been georeferenced the reference system units may be pixels and the resolution units meters since the documented resolution is taken as the nominal known sensor resolution.

Follows the proposal of: GeM+

Obligatory according to GeM+: No

Cardinality: 1

Key type: C

AppliesToLayer: Yes
AppliesToSeries: Yes

Back
(Back to index)

Name of the GeM+ entry: Equivalent scale
Name of the REL file key: EquivalentScaleDenominator (general value and band vlaue)

Description and considerations: The denomintor of the equivalent paper map scale with the same quality as the digital cartography which is being documented.

Follows the proposal of: ISO

Obligatory according to ISO: No

Cardinality: 1

Key type: C

AppliesToLayer: Yes
AppliesToSeries: Yes

Back
(Back to index)

Name of the GeM+ entry: Cell size
Name of the REL file key: (it is not stored in the REL file, it is deduced dynamically)

Description and considerations: The cell size is the dimension of the cell in an image covering some terrain. The cell size is calculated from the number of columns and rows and the extent of a raster and is not documented in the REL file. The cell size may be different in the X and Y direction so GeM+ shows two keys: "Cell size in X" and "Cell size in Y". MiraMon does not give full support to this option, which it is recommended not to use. Only applies to rasters.

The cell size should not be confused with the resolution. For example, an image from the thermal channel 6 of the Thematic Mapper sensor of the Landsat-5 satellite has a "resolution" of 120 m, although frequently data are supplied resampled at 30 m (cell size). The resolution remains 120 m although the cell size is much less.

For the case of a multi-band layer it is possible to document a different value for this key for each band (see the Thematic Information) section. For this reason there is a radial button in GeM+ (when dealing with a multi-band layer) that allows either the general data or the selected band data to be displayed. (This choice is made using the pull-down menu or the forward and back buttons located in the upper part of the GeM+).

To avoid incoherent values between different GeM+ keys and since there is an implicit relationship between the numbers of rows and columns, the cell size (in both directions) and the extent of the layers, this key cannot be modified directly. In order to change it the "Change..." option must be selected which opens a dialog box for modifying these parameters together (changes in the numbers of rows and columns, cell size and extents).

Follows the proposal of: GeM+

Obligatory according to GeM+: It is deduced dynamically

Cardinality: 1

Key type: N

AppliesToLayer: Yes
AppliesToSeries: Yes

Back
(Back to index)