- FILE: Layer-sheet graphic file address (arc,
pol, etc.), relative to that of the REL and DBF file of the
Multiseries.
- ID_SUBJECT: Layer-sheet theme identifier.
- ID_DATA: Year or version of the layer-sheet. For example, in
the case of the Multiseries 'Topographic' could be
v2.0, etc. and in the case of the Land Cover Map of
Catalonia could be 1993 or 2000.
- ID_SHEET: Which sheet corresponds to this layer-sheet
- ID_TILE: Which tiling scheme corresponds the sheet defined in
previous field
So for example some records from this table
could be:
bt5mv20.dbf
FILE |
ID_SUBJECT |
ID_DATA |
ID_SHEET |
ID_TILE |
f241x156\bt5mv20mm0f241156ac0r020.pnt |
AltimetriaCotes |
v2.0 |
241-156 |
MTN/IGN-5m |
f241x156\bt5mv20mm0f241156rv0r020.pnt |
PuntsReferenciaVertexsGeodesics |
v2.0 |
241-156 |
MTN/IGN-5m |
f241x156\bt5mv20mm0f241156an0r020.pnt |
AltimetriaTextosCorbesNivell |
v2.0 |
241-156 |
MTN/IGN-5m |
… |
… |
… |
… |
… |
f242x138\bt5mv20mm0f242138ac0r020.pnt |
AltimetriaCotes |
v2.0 |
242-138 |
MTN/IGN-5m |
f242x138\bt5mv20mm0f242138an0r020.pnt |
AltimetriaTextosCorbesNivell |
v2.0 |
242-138 |
MTN/IGN-5m |
f242x138\bt5mv20mm0f242138hn0r020.pnt |
HidrografiaToponimia |
v2.0 |
242-138 |
MTN/IGN-5m |
f242x138\bt5mv20mm0f242138mn0r020.pnt |
MediNaturalToponimia |
v2.0 |
242-138 |
MTN/IGN-5m |
This table is related
with other tables (with prefixed suffix) containing the
links to the RELs that define the different series
(AltimetriaCotes, PuntsReferenciaVertexsGeodesics, etc.
following the example) and the different sheets in the series
(241-156 and 242-138 of the MTN/IGN-5m tiling scheme, following
the example).
Relationships with these
other tables are from combined fields, as it will go
commenting in the following sections. In the Multiserie REL file
the relation with these tables are defined
through 'simple' fields, as usual. This is
enough to define relationships but it will not be to
perform checks from GeM+. The MiraMon Metadata Manager, when you enter the tab "Metadata
| Series" for a Layer-Sheet that is part of the
Multiseries performs "strict" checks
(using information from both fields at once).
Multiseries metadata
For any
new metadata file entries are now defined
which allow to define the hierarchical level of that set
of metadata. The metadata entry that contains
information comes from the ISO19115 standard, it is called
hierarchyLevel and is in the 'METADATA' section. Can
take 2 values: 005, for a layer (default value), and 006,
for a series (codes corresponding to the code-list MD_ScopeCode of
the cited standard).
Multiseries metadata
correspond to the hierarchical level of series, therefore to the multiserie REL
we will find:
[METADADES]
; is a SERIE rel
hierarchyLevel=006
In the model used
three different types of series will be used: multiseries,
series and serial sheet. They all have the same level
hierarchical 'Series'. We use the member
hierarchyLevelName to identify with prefixed names the
serial type (according to ISO this is a text entry
free, but we will recognize some 'specials values'). For Multiseries, in the REL it
will be saved:
[METADADES]
; is a SERIE rel
hierarchyLevel=006
; 'Multiserie' type
hierarchyLevelName=##Multiserie##
At metadata is also needed
define the relationships of this metadata set with
other metadata sets. The ISO standard defines
two ways to define these relationships:
- parentIdentifier: It is
the FileIdentifier of the metadata of which this
is a part. It refers to the 'father of metadata'.
There can only be one parentIdentifier per metadata set
according to ISO. This is not very appropriate because we want to,
from the layer-sheet, explain the three 'parents' who
has: serial, sheet, and multiseries (layer-sheet captures metadata
of all three metadata sets).
- aggregateInfo: It brings
layer aggregation information. It is N
cardinality type and therefore allows us to define so many levels
of aggregation as needed. It refers to the data
and not to metadata.
The
parentIdentifier has to be used to refer directly to the
multiseries from sheet-layer metadata, series
and serial sheets. In theory it is necessary to save the
FileIdentifier of the corresponding metadata, but in the
MiraMon model is more useful to save the relative address of the
REL of the multiseries, which will be saved to the key
REL's parentIdentifierFile1 ("no ISO" key). Multiserie metadata do not define any value in this
key.
[METADADES]
; is a SERIE rel
hierarchyLevel=006
; 'Multisèrie' type
hierarchyLevelName=##Multiserie##
; and therefore has no parentIdentifierFile1
; parentIdentifierFile1=
Common metadata to this
hierarchical level are, for example, part of the title
(topographic), the equivalent scale, etc.
Outline of the files that
define the Multiseries
2.2 Definition of the series
Each of the series that
form the Multiseries is defined from a REL that
contains your metadata. There is a DBF file that contains the
list of series that make up the multiseries. The table can
have any name but it is recommended that it be the same as
the one in the main table of the Multiseries with the suffix
"_TemaData". This table contains the name of all
series and indicates the REL that describes the metadata of
each of them. The structure of the DBF needs to
have at least predefined name fields.
Table
*_TemaData.dbf
This table contains the possible values of
combinations of 'Subject' field and field
'Date' in the table above. Each combination corresponds
to a 'Series'. This table is related to that of the
multiseries starting from the combined field ID_SUBJECT-ID_DATA, which
appears in both tables. The fields in the table
are:
- ID_SUBJECT: Identifier of the
layer-sheet theme.
- ID_DATA: Year or version of the
layer-sheet.
- FILE: Address
of the REL file that defines the metadata of the series, relative to that
of the REL and DBF file in the multiseries.
- ORDERSERIE: Optional field
which allows you to indicate the order of the records if any
danger of retrieving the table in an incorrect order.
- MS_PARCIAL: Optional field
indicating the name of the partial Multiseries to which belongs
this series. This name is free but obviously should
be different for each partial multiseries defined within
a multiseries. See more information in the section
"Aspects of the
Multiseries".
- NIV_MS_PAR: Optional field
which indicates the number of levels (ie the number
of drawing iterations) contained in the Multiseries
to which this series belongs. This number is
free but obviously it should be the same for all
series of the same Partial Multiseries. See more
information in the "Display Aspects section
from the Multiseries".
So, for example, some
records in this table could be:
ID_SUBJECT |
ID_DATA |
FILE |
PoblamentToponimiaPrincipals |
v2.0 |
PalSimb\bt5mv20mm0PoblamentToponimiaPrincipals_01ca.rel |
PoblamentToponimiaAltres |
v2.0 |
PalSimb\bt5mv20mm0PoblamentToponimiaAltres_01ca.rel |
MediNaturalToponimia |
v2.0 |
PalSimb\bt5mv20mm0MediNaturalToponimia_01ca.rel |
HidrografiaToponimia |
v2.0 |
PalSimb\bt5mv20mm0HidrografiaToponimia_01ca.rel |
PuntsReferenciaVertexsGeodesics |
v2.0 |
PalSimb\bt5mv20mm0PuntsReferenciaVertexsGeodesics_01ca.rel |
PoblamentPunt |
v2.0 |
PalSimb\bt5mv20mm0PoblamentPunt_01ca.rel |
AltimetriaCotes |
v2.0 |
PalSimb\bt5mv20mm0AltimetriaCotes_01ca.rel |
AltimetriaTextosCorbesNivell |
v2.0 |
PalSimb\bt5mv20mm0AltimetriaTextosCorbesNivell_01ca.rel |
… |
… |
… |
AltimetriaRelleuAltresPol |
v2.0 |
PalSimb\bt5mv20mm0AltimetriaRelleuAltresPol_01ca.rel |
TallCartograficArc |
v2.0 |
PalSimb\bt5mv20mm0TallCartograficArc_01ca.rel |
TallCartograficPol |
v2.0 |
PalSimb\bt5mv20mm0TallCartograficPol_01ca.rel |
Serie metadata
Serie metadata
also correspond to the hierarchical level of series; therefore, each of the serial RELs (as many as records in the table
bt5mv20_TemaData.dbf) we will find:
[METADADES]
is a SERIE rel
hierarchyLevel=006
For the Series, in the REL hierarchyLevelName will be saved equal to series:
[METADADES]
; is a SERIE rel
hierarchyLevel=006
;'Serie' type
hierarchyLevelName=##Serie##
The relationships of this metadata set with
other metadata sets are also needed
to define. As mentioned before,
we will use the parentIdentifier to refer to the
multiseries from sheet-layer metadata, series
and serial sheets. In this case:
[METADADES]
; is a SERIE rel
hierarchyLevel=006
; 'Serie' type
hierarchyLevelName=##Serie##
; so its parentIdentifierFile1 is the Multiserie
parentIdentifierFile1=..\bt5mv20.rel
It is also necessary that the
FileIdentifier of the Series be fixed: that which
comes from the field content combination of corresponding ID_SUBJECT and
ID_DATA (of the series definition table)
separated by a "_". So, for example, its
FileIdentifier of the first series of the example
(table bt5mv20_TemaData.dbf), will be
PoblamentToponimiaPrincipals_v2.0, and therefore the section of
complete metadata is:
[METADADES]
FileIdentifier=PoblamentToponimiaPrincipals_v2.0
; is a SERIE rel
hierarchyLevel=006
; 'Serie' type
hierarchyLevelName=##Serie##
; and therefore its parentIdentifierFile1 it the Multiserie
parentIdentifierFile1=..\bt5mv20.rel
Some of the common metadata
to an entire series are part of the title, the description
of the lineage and the sources of the lineage (from which
information and how data is captured), a general date
thematic, database structure and quality
general of each of the fields in the database,
etc.
Note: The maximum size of the
FileIdentifier is 253, and as that of the series is
builds from the contents of the fields ID_SUBJECT and ID_DATA
plus character "_", The maximum size
of these two fields added is required to be maximum
252.
Outline of the files that
define the Series
Display order of
the Multiseries layers
The order of the series in the
table *_SubjectData indicates the order of the layers in the
display. This order "commands" over the order
of the maps and allows you to properly control the order of
all layers, even those that are part of the
Multiseries and that were not present in the first of the sheets
open at MiraMon. The higher up a record is in the
table *_ThemeDate, above will be in the order of layers.
This display scheme is the traditional one in which
the layer command is "strict" while
draw all the objects in one layer at a time and then
those of the second layer, and so on until the end. And it is possible to specify an ORDRESERIES field to reorder the table
if there is a danger of retrieving it in a record order
incorrect in SQL selection.(use "order
by").
In some cases it is necessary
use a more complex display scheme as it is needed
to draw the objects of some layers in a combined way,
in various "drawing iterations". For example
you may need to draw first some objects of the layer
1, then some of layer 2, then some of layer 3,
then the rest of the objects in layer 2, and finally the
rest of layer 1 and the rest of layer 3. This need
has emerged to be able to properly implement the
display of the ICC BT25M Multiseries, where required
combine the drawing of some of the layers of roads in order to be able to pass a secondary road
above or below a motorway, as appropriate,
although both types of entities are layered
different.
To implement this
visualization strategy extensions of the first version of the model have been required.
It is necessary
to define a new field (MS_PARCIAL) in the table describing the
series. This field is blank for all series that
have no display grouped with other layers, and it has the same
value for all series (and layers) in the same group
which must be combined. All series that are part of the
same Partial Multiseries must be together in
the display order.
A new key OrdreDindreMultiSerieParcial1 is needed to be at least in the [METADADES] section of the REL file that belongs to each of these Partial Multiseries. This key states, separated by the use of commas, the graphic identifiers of the layer objects that need to be drawn on each interaction the layers are going to be drawn at. The number of drawing interactions for the layers that belong to the partial multiseries are named Levels of the partial multiseries. This information is saved at field NIV_MS_PAR of the table that describes the series, and must match the name of separators plus one from the key OrdreDindreMultiSerieParcial1 of the layer-sheets. When reading the table, MiraMon controls that all MSP values with the same name are the same and bigger than zero, and it will notice users if inconsistencies are detected.
Let's imagine a simple example with 3 series: "Urban roads" (ViesComunicacioViesUrbanes), "Conventional roads" (ViesComunicacioViesConvencionals) and "Highways and priority roads" (ViesComunicacioAutopistesViesPreferents) that belong to the same partial multiseries, named "Communication roads" (ViesComunicacio). In the DBF table of the series, it will state:
bt25mv10_TemaData.dbf
ID_SUBJECT |
ID_DATA |
FILE |
MS_PARCIAL |
NIV_MS_PAR |
ViesComunicacioViesUrbanes |
v1.0 |
... |
ViesComunicacio |
6 |
ViesComunicacioViesConvencionals |
v1.0 |
… |
ViesComunicacio |
6 |
ViesComunicacioAutopistesViesPreferents |
v1.0 |
… |
ViesComunicacio |
6 |
As stated already, each layer-sheet REL that belongs to this partial multiseries will state the input OrdreDintreMultiSerieParcial1 (besides the usual information of this section, sidelined here for clarity):
Layer-sheet REL from series "Urban roads" (ViesComunicacioViesUrbanes):
[METADADES]
OrdreDintreMultiSerieParcial1=0-0,1-7,8-5301,,5302-5303,
Layer-sheet REL from series "Conventional roads" (ViesComunicacioViesConvencionals):
[METADADES]
OrdreDintreMultiSerieParcial1=,0-3,4-518,,,519-572
Layer-sheet REL from series "Highways and priority roads" (ViesComunicacioAutopistesViesPreferents):
[METADADES]
OrdreDintreMultiSerieParcial1=0-0,1-12,13-245,,246-326,
So then, according to the example, when drawing the elements, the object with the graphic identifier 0 from "Urban roads" layer-sheet will be drawn first. Secondly, any object will be drawn in "Conventional roads" layer-sheet (note that there is no graphic identifier before the first comma). Thirdly, the object with a 0 graphic identifier from "Highways and priority roads" layer-sheet will be drawn. These objects will shape the first level (or drawing iteration) of the partial multiseries "Communication roads.
After drawing the objects of all layers from the first level, the second drawing level will be boarded where objects from 1 to 7 of "Urban roads" layer-sheet, from 0 to 3 of "Conventional roads" layer-sheet, and from 1 to 12 of series layer-sheet "Highways and priority roads" will be drawn. The sequence ",," states that there are no objects on that level (drawing iteration) in that layer. On the sixth drawing level of the partial multiseries, objects 519-572 from "Conventional roads" layer-sheet are drawn only.
2.3 Definition of serie sheet
Each one of the Serie Sheets that shape the multiserie is defined through a REL that contains its metadata. There is a DBF file that contains the list of Serie Sheets that shape the multiseries. The table can have any name, but it is recommended that it coincide with the name in the main table of the multiseries with the suffix "_FullTall." This table contains the name of all serie sheets and indicates which REL describes the metadata of each one of them. The structure of the DBF file needs to have at least some predefined name fields.
Table
*_FullTall.dbf
This table contains the possible values of combinations of field 'FULL' (sheet) and field 'TALL' (Tile schema) of the multiseries table. Each combination corresponds to a 'Serie Sheet'. This table is related to the multiseries table via the combined field Full-Tall (Tile schema-Sheet), that appears in both tables. The fields of the table are:
- ID_FULL:
Sheet to which Serie sheet corresponds.
- ID_TILE:
Tile schema to which the sheet defined in the previous field corresponds.
- FILE:
Address of the REL file that defines the metadata of the serie sheet, concerning to the one in the REL file and DBF file of the multiseries.
Thus, for example, some registers of this table could be:
bt5mv20_FullTall.dbf
ID_FULL |
ID_TILE |
FILE |
241-156 |
MTN/IGN-5m |
f241x156\bt5mv20mm0f241x156r02_01ca.rel |
241-157 |
MTN/IGN-5m |
f241x157\bt5mv20mm0f241x157r02_01ca.rel |
241-158 |
MTN/IGN-5m |
f241x158\bt5mv20mm0f241x158r02_01ca.rel |
242-138 |
MTN/IGN-5m |
f242x138\bt5mv20mm0f242x138r02_01ca.rel |
242-139 |
MTN/IGN-5m |
f242x139\bt5mv20mm0f242x139r02_01ca.rel |
… |
… |
… |
316-082 |
MTN/IGN-5m |
f316x082\bt5mv20mm0f316x082r02_01ca.rel |
316-083 |
MTN/IGN-5m |
f316x083\bt5mv20mm0f316x083r02_01ca.rel |
316-084 |
MTN/IGN-5m |
f316x084\bt5mv20mm0f316x084r02_01ca.rel |
317-081 |
MTN/IGN-5m |
f317x081\bt5mv20mm0f317x081r02_01ca.rel |
Two metadata groups associated to a Tile schema-Sheet can be differentiated.
a)
Generic metadata of the Tile schema
a.1)
Table of Cartographic Tiles schema
There is a DBF table that states several Cartographic Tiles schema available and which is the graphic polygon file that contains the topographical tile schema for each one of them. Typically, this polygon file generates spatial division in trapezoids, as for example the tile schema of the IGN. But any other division could be used without problem from the model, a regional division for example.
Tall.dbf
ID_TILE |
FILE |
MTN/IGN-5m |
Tall_5m_IGN.pol |
MTN/IGN-25m |
Tall_25m_IGN.pol |
MTN/IGN-50m |
Tall_50m_IGN.pol |
Typically, all series from the multiseries are supported by the same tile schema and, due to that, the table Tall.dbf will have a single register. In fact, it makes sense to have a general table that defines all existing tiles and links them to the different polygon files. This will make that different multiseries could use this equal 'thesaurus' in order to know which polygon files have to look for (according to the tile each multiseries use). For this reason, this table must be (typically) located in a 'further' file than the one of the multiseries (in SI\Tesaurus, for example), and it must have as many registers as the used tiles for the different multiseries (ex: MTN/IGN-5m, MTN/IGN-25m, MTN/IGN-50m, etc).
Therefore, since the use of a table that defines the external tiles of the multiserie has been chosen, the REL of the multiserie has to define a relationship with this table. The multiserie REL contains the relationships in the tables TemaData and TileSheet, and it is from the second table that it is linked to the table Tall.dbf. The links between the multiserie table and the first two tables should be via a combined field. Up to the date of this document, those are stated in the REL through a simple link. The link leading to the table Tall.dbf only has a single linking field.
The content of field ID_FULL of the table *_FullTall.dbf (SheetTile table) indicates which is the ENTITY identifier of the sheet inside the polygon file stated on field 'FILE' of table Tall.dbf (Tile table) (the polygon file Tall_50m_IGN.pol in the table of the example)
The typical approximation used in the series performed beforehand was: for each themed serie there was a different (and repeated) cartographic tile that was linked with the maps of each Sheet for a concrete multiseries. Thus, there was a tile that opened all sheets of the topographic and another tile that opened all the sheets of MCSC. Current implementation avoids duplicating this graphic information and describes metadata of each sheet solely.
a.2)
Main table of the polygon file that defines the Tile
The layer Tall_50m_IGN.pol defines the geometry of the tile. Generally, the polygons are trapezoidal, but also they can be administrative distribution polygons, for example. In this case, the file must be in groups because each entity must have a single register. In both cases, there must be a field defined as ID_ENTITAT too.
Metadata referred to each sheet of the tile schema are placed directly in the DBF table of the polygon file. It is needed that those fields have a particular field name in order to know which one corresponds to each metadata concept.
The metadata that can be extracted from the table of the polygon file and that describe the Cartographic Tile are:
Extent: It is extracted from the polygon file header for each polygon. If there is more than a register for the same entity identifier (because they are not cycled as groups or there is a multi-register), then the extent is calculated as the "external" extent of the different polygons.
Sheet codes: a defined field must exist as an entity identifier, that is used in the other tables as content of the field 'ID_FULL'
Sheet denomination: The name of the field is NOM_FULL. In previous versions of this document, we thought on fixing the name of this field as TOPONIM, but finally NOM_FULL has been chosen because according to available reference basis in \\eclipta\SI (internal server of geographic information) that is its name in most cartographic tiles schema files.
If this DBF has other fields with different names, this information will be searchable from the cartographic tile schema, but it never can be 'stretched out' from the metadata of the sheet because its sense is unknown (by the moment).
Metadata of the cartographic tile schema, placed in the main table of the polygon database that defines the Tile schema, corresponds to the hierarchical level of the layer. Thus, in the REL of the polygon file that defines the Cartographic tile (Tall:50m_IGNP.rel) we will find:
[METADADES]
; it is a SHEET rel (default value)
; hierarchyLevel=005
Therefore, in the used model, two different types of layers will be used: layers that represent the cartographic tile schema and layer-sheets themselves. We will use the member hierarchyLevelName to identify this first special type of layer with a prefixed name. Thus, in the polygon file REL that defines the cartographic tile (Tall_50k_IGNP.rek) we will find:
[METADADES]
; it is a LAYER rel (default value)
; hierarchyLevel=005
; 'tiling scheme' type
hierarchyLevelName=##Tall##
In metadata, it is also needed to define the relationships of this set of metadata with other sets of metadata. But, as said before, the tile will never inherit metadata, it is generic and it is used by different multiseries, so it is not directly linked with multiseries (it does not have member parentIdentifier1 in its REL).
a.3)
Scheme of the files that define the cartographic tile
b)
Metadata for a Sheet-Tile
Metadata are referred to all layer-sheets from the same Sheet-Tile within a multiseries. Therefore, both versions of the MCSC have the same tile (and toponym metadata are extracted from the same 'file') and, in contrast, they can have different metadata when we refer them as a Sheet-Tile unit inside a multiseries (that is not the case of the example shown in the table).
This sends us some metadata of each sheet, that are the ones defined in REL files of each sheet and tile for each multiseries. Different tiles can be supported and for this reason, those are described here.
The Sheet-Tile does inherit some metadata of the multiseries.
The metadata of the Series Sheet (Sheet-Tile) correspond to the hierarchical level of the series too, so we will find in the REL of the series:
[METADADES]
; it is a SERIE rel
hierarchyLevel=006
For Series Sheets hierarchyLevelName will be saved equal to "Sheet":
[METADADES]
; is a SERIE rel
hierarchyLevel=006
; 'Sheet' type
hierarchyLevelName=##Full##
It is also needed to define relationships of this metadata set with other metadata sets. As said before, we will use parentIdentifier1 to refer to the multiseries via the metadata of layer-sheets, the series and the series sheets. In this case:
[METADADES]
; it is a SERIE rel
hierarchyLevel=006
; 'Sheet' type
hierarchyLevelName=##Full##
; and therefore, its parentIdentifierFile1...
parentIdentifierFile1=..\ bt5mv20.rel
; ...it Multiseries
Also, we will fix that the FileIdentifier of the Series Sheet is one that is fixed already, fixed to that one that appears from the combination of the corresponding fields ID_SHEET and ID_TILE (from the series definition table: *_FullTall.dbf) separated by a "_". So, for example, the REL of the Series Sheet:
bt5mv20_FullTall.dbf
ID_FULL |
ID_TILE |
FILE |
241-156 |
MTN/IGN-5m |
f241x156\bt5mv20mm0f241x156r02_01ca.rel |
241-157 |
MTN/IGN-5m |
f241x157\bt5mv20mm0f241x157r02_01ca.rel |
241-158 |
MTN/IGN-5m |
f241x158\bt5mv20mm0f241x158r02_01ca.rel |
Its FileIdentifier will be the same as 241-156_MTN/IGN-5m, i.e., the complete metadata selection is:
[METADADES]
FileIdentifier=241-156_MTN/IGN-5m
; it is a SERIE rel
hierarchyLevel=006
; 'Sheet' type
hierarchyLevelName=##Full##
; so therefore, its parentIdentifierFile1...
parentIdentifierFile1=..\ bt5mv20.rel
; ...is the Multiseries
Note: the maximum size of FileIdentifier is 253, and since the one of series is constructed from the content of fields ID_SUBJECT and ID_DATA plus the character "_". IT IS NEEDED that the maximum size of those two added fields would be 252 at its most.
Relationship of the Series Sheet with the corresponding Cartographic Tile schema
Series Sheets refer directly to the polygon file of the tile, and not only to the multiseries in order that the applications don't need to read the DBF related with the multiseries each time.
Moreover, it is needed to indicate which polygon file and the exactly which polygon in this file (through the entity identifier), the metadata of this Sheet-Tile corresponds to. This information can be extracted from the table of tiles, but from the series REL it must look for the multiseries REL and then explore the relationships of this one until arriving to the table of tiles. It is more useful that the REL of the Series Sheet links directly to the polygon file that defines the cut, and that it also states the entity identifier that indicates to which concrete polygon of that polygon file that Series Sheet is referred to.
This relationship is made through the adding information section. So, thus, Series Sheet metadata use aggregationInfo section to refer to the polygon file of the corresponding tile. Elements placed in this section are:
-
aggregateDataSetName (optional, type CI_Citation): Up to the date of this document, it is not used. The day when it gets implemented, it will be placed at an independent box (CI_Citation) that has it all, and the tab "Identification" of GeM+ will be remade in order to have this aesthetic too (all things together).
-
aggregateDataSetIdentifier (optional, type MD_Identifier): Same as in parentFileIdentifier, the independent key aggre…File is used, and, from the REL file, the identifier will be already found.
-
associationType (DS_AssociationTypeCode): It is the only compulsory element. In theory, this element has to belong to a list of predefined codes, and can take any of those values.
-
initiative (optional, DS_InitiativeTypeCode): It is not compulsory, and it is also a value list that will be offered to users.
In such way, users will be able to define that layer belong to as many aggregates as desired (as said by the standard). In the case that Series Sheet wants to be related with the REL file of the polygon layer that defines the cartographic tile, it will be possible to add one of these aggregates to describe the Cartographic tile.
This is made through two filters. Firstly, the aggregate describing the Cartographic tile must have a value determined in the element associationType: it must be LargerWorkCitation. Secondly, if the value is a predefined one, then a check will activate: "It is Tile REL". So then, more than one aggregated layers with LargerWorkCitation type association can be defined for the same layer, but only one of these would have the check itself activated.
Besides the section keys [METADADES], already explained, that describe the hierarchical levels and the series type of the Series Sheet, this REL file will use, in order to indicate the related Cartographic tile:
[IDENTIFICATION:AGGREGATION_INFO1]
aggregateDatasetIdentifierFile=..\TallCarto\bt5mv20mm0Tall5m_01.pol
; partOfSeamlessDatabase type
associationType=003
; from the different aggregates with type
'partOfSeamlessDatabase'
; this one defines the polygon file with the Tile
EsRelDeTall=1
[IDENTIFICATION:AGGREGATION_INFO2]
aggregateDatasetIdentifierFile=...
; partOfSeamlessDatabase type
associationType=003
; from the different aggregates with type
'partOfSeamlessDatabase'
; this one DO NOT defines the polygon file with the Tile
; EsRelDeTal l=0 -> valor per defecte
In any of the preceding examples the initiative has not been defined because it can take any value and, consequently, users will decide the most convenient one.
This information, however, is mostly enough to know which one is the polygon file that defines the cartographic tile, but not sufficient to know which polygon of the file corresponds to the Sheet that is being described (Series Sheet 241-156 MTN/IGN-5m in the example). Knowing which polygon from the file corresponds to the Series Sheets is needed to obtain information about the attribute table of the polygon file (ex: the toponym of the sheet) without reading the multiseries tables (as it has been done with all the information of the model).
In order to know this information, a new key in this section has been defined named aggregateDataSetIdEntitat that indicates the entity identifier which detects to which file polygons correspond this Series Sheet. This key will only be read and get written if the "aggregation information" is the one defined by the Cartographic tile (i.e., it is EsRelDeTall=1). From GeM+ this entity identifier would be seen, but it cannot be modified from the tab that shows "aggregation information." Therefore, it is needed to complete the section [IDENTIFICATION:AGGREGATION_INFO1] of the preceding example.
[IDENTIFICATION:AGGREGATION_INFO1]
aggregateDatasetIdentifierFile=..\TallCarto\bt5mv20mm0Tall5m_01.pol
; partOfSeamlessDatabase type
associationType=003
; from different aggregates with type
'partOfSeamlessDatabase'
; this one defines the polygon file with the tile
EsRelDeTall=1
aggregateDataSetIdEntitat=241-156
Outline of files that define the Series Sheet
2.4 Definition of a layer-sheet
Each layer can belong to a multiseries or not. Linking with the model is made from the general definition table of the multiseries, through the field FILE (where the name and path of each one of the graphic layers is stated) and via the metadata of every layer, where it states the multiseries it belongs to (element parentIdentifierFile1).
Metadata of the layer also correspond to the hierarchical level of the layer, so in the layer REL we will find:
[METADADES]
; it is a LAYER rel (default value)
; hierarchyLevel=005
For a layer-sheet (or in a layer that is not related to any series) cartographic in REL hierarchyLevelName will be saved as same as in "LayerSheet", its default level:
[METADADES]
; it is a LAYER rel (default value)
; hierarchyLevel=005
; 'LayerSheet' type (default value)
; hierarchyLevelName=##CapaFull##
In metadata, it is also needed to define relationships of this set of metadata with other sets of metadata. As said before, we will use parentIdentifier in order to refer to the multiseries from the metadata of the layer-sheets, the series and the series sheets. In this case: [METADADES]
; it is a LAYER rel (default value)
; hierarchyLevel=005
; 'LayerSheet' type (default value)
; hierarchyLevelName=##CapaFull##
; and its parentIdentifierFile1...
parentIdentifierFile1=..\bt5mv20.rel
; ...is Multiserie.
Similarly, that a Series sheet has a way of stating directly the file of the cartographic tile, it is agreed that layer-sheets refer to all their parents, not only the multiseries (identical reasons that in the preceding case).
This is done through the aggregationInfo element of the metadata. The elements it has are:
- aggregateDataSetName
(optional, type CI_Citation): Up to the date of this document, it is not used. The day when it gets implemented, it will be placed in an independent box (CI_Citation) that has it all, and the tab "Identification" of GeM+ will be remade in order to have this aesthetic too (all things together).
- aggregateDataSetIdentifier (optional, type MD_Identifier): same as in parentFileIdentifier, an independent key aggre…File is used, and from the REL file the identifier will be already found.
- associationType
(DS_AssociationType Code): it is the only compulsory element. In theory, this element has to belong to a list of predefined codes, and can take any of these values.
- initiative (optional, DS_InititaveType Code): it is not compulsory, and it is also a value list that will be offered to users.
So then, users would define that the layer belongs to as many aggregates as desired (as said by standards). In the case that the layer itself belongs to a multiseries, it will be possible to choose two of those aggregates in order to describe the Series and the Series Sheet.
This is made through two filters. Firstly, the aggregate that describes the Series and the Series Sheet must have a determined value in the element associationType.
Series: associationType must be partOfSeamlessDatabase
Series sheet: associationType must be LargerWorkCitation
Secondly, if the value is one of the two predefined ones (and the layer belongs to a multiseries), then some checks will activate in the style of: "It is the Series Sheet where the layer belongs" or "It is the Series where the layer belongs". So, for the same layer, more than one aggregated layer can be defined with an association of the type partOfSeamlessDatabase, but only one of those can have the check itself activated.
Therefore, for a layer that belongs to a multiseries, users will use, in addition to section [METADADES] as shown on the previous page:
[IDENTIFICATION:AGGREGATION_INFO1]
aggregateDatasetIdentifierFile=bt5mv20mm0f241x156r02_01ca.rel
; LargerWorkCitation type
associacionType=002
; from the different aggregates with type
'LargerWorkCitation'
; this one defines the Series Sheet
EsRelDeSerie=1
[IDENTIFICATION:AGGREGATION_INFO2]
aggregateDatasetIdentifierFile=..\PalSimb\bt5mv20mm0AltimetriaCotes_01ca.rel
; partOfSeamlessDatabase type
associacionType=003
; from the different aggregates with type
'partOfSeamlessDatabase'
; this one defines the Series
EsRelDeSerie=1
[IDENTIFICATION:AGGREGATION_INFO3]
aggregateDatasetIdentifierFile=...
; LargerWorkCitation type
associacionType=002
; from the different aggregates with type
'LargerWorkCitation'
; this one DO NOT defines the Series Sheet
; EsRelDeSerie=0 (default value)
[IDENTIFICATION:AGGREGATION_INFO4]
aggregateDatasetIdentifierFile=...
; partOfSeamlessDatabase type
associacionType=003
; from the different aggregates with type
'partOfSeamlessDatabase'
; this one DO NOT defines the Series
; EsRelDeSerie=0 (valor per defecte)
; and other different agreggates
[IDE14:51 28/10/2013NTIFICATION:AGGREGATION_INFO5]
aggregateDatasetIdentifierFile=...
; any of the non-'predefined' types
; crossReference type
associacionType=001
In any of the preceding examples, the initiative has been defined because it can take any value and, consequently, users will decide the most convenient one.
The Universal Geospatial
Metadata Manager, when accessing the tab "Metadata | Series" for a Layer-Sheet that belongs to the multiseries, will check that this information defined on the REL of the Layer-Sheet is coherent in relation with the information given in DBF tables that describe the multiseries.
Outline of files that define Layer-Sheets