Web del MiraMon

MiraMon cartographic series


Cartographic series symbolization Cartographic series metadata

A cartographic series is a set of sheets in the same scale that adjacently cover the totality of a territory from the same point of view (topography, vegetation, geology, etc). In conventional paper cartography series exist due to territories that, given a certain area and scale, are too big to be represented on a single sheet of paper. The division of map sheets solves two problems simultaneously: the possibility to extend map prints on paper and the impractical nature of managing large sheets of paper.

In digital cartography it is possible to treat all of the territory as one continuous space and forget the division of individual sheets. In fact, this possibility is often presented as an advantage of geographic information systems (GIS) in comparison to conventional cartography. However, geographic information systems still support processing physical maps. There are two primary reasons for this fact:

  • First, there exists a tradition, or simmetry, with analogic cartography: Many users find agreeable to maintain a good correspondence in methods of measurement between digital and physical maps (typically edited by an organization responsible of map production).
  • Second, when a series encompasses a large territory and has a very detailed scale, even with the most powerful computers it is impractical to treat this data as a whole. For example, when loading online data or when querying by attribute diving by sheets is appropriate as it limits the territorial extent of the data that is being consulted, making it faster and easier to load.

In spite of what has just been explained, dividing map sheets also presents well known inconveniences, primarily from the fragmented nature of the data the GIS must treat these situations intelligently. After version 4.0 of MiraMon support for cartographic series is implemented from the point of view of representation and legend, but not from an analytical standpoint. In other words, MiraMon knows the existence of map series and permits symbolization changes (color changes, etc), change state to "visible", "consult attributes", "unify visible/consult", a change in visualization scale, etc, is propagated on all map sheets of a series without having to explicitly specify it sheet by sheet. Additionally, it is also possible to assign more than one set of symbols for all of the sheets of the same series in a simple manner, but it does not allow a query for all sheets at once. MiraMon also allows shared metadata for the entire series.

On the other hand, usually the legend is constant for the whole series and it would be inadequate if there are 6 sheets open to have the description of the legend 6 times, so that the description simply appears once.

MiraMon maintains a cartographic series on the same "level" of layers order, meaning that when a layer is opened belonging to a series or a map with layers that belong to a series, it is reorganized with the open layers such that they are drawn consecutively with the same ones of the series that are already open; this is esthetically better and useful since the layer manager groups them together in the same concept (series).If the user changes the order of one layer, MiraMon automatically ensures that the others in the same series are consecutive in the general order of layers. Finally, the series has an identifying title that is used in place of the individual name of each sheet (for example one sheet consisting of the series perhaps carries the title "Geologic Map 1:5000. Sheet 444-1-1. Riba-Roja of Ebre", although perhaps this series should be assigned as "Geologic Map 1:25000").

In future versions MiraMon will also support cartographic series from an analytic point of view. Meaning that, given a query by location of an element with continuity between sheets (for example a river), the information will be relative to its entire location, not only for the sheet which is being queried. In the same way, the queries by attributes and other operations of analysis will detect that a series is being worked with and will consider the territorial continuity of the related elements.

Important notes on topographic series:

Conventional topographic series typically have several elements (contour lines, hydrography, communication roads, etc). Although it is possible to maintain the original series with all of its layers in one single file (except if they are of a different geographic nature), the use of structured thematic layers in topographic series are highly recommended.

In this method, for example, the topographic sheets 1:5000 of Catalonia, numbered in the format "AAAxBB", where "AAA" is the number of the column and "BB" is the number of the row, it is possible to have in several layers with an "AAAxBBT" denomination, where T can be a thematic code (C for primary topographic lines, S for the minor lines, H for the hydrography, etc). One specific sheet of hydrography can be for example 297x89H.

With this structure, it is possible to manage smaller files and queries, etc. They are more specific to the theme in question in each moment (contour lines, roads, etc). If desired, all thematic layers can be opened simultaneously, so that they are visible in the printed topographic sheets, the correct option involves defining a map in MiraMon that opens the adequate files in each case (for example one that opens 297x89C, 297X89S, 297x89H, etc) indicating, through the use of a parameter "SerieColorTextVisuLlegenda" that the visual characteristics and treatment of the legend of all layers (C, S, H, etc) follow the criteria of the corresponding general series (see below for more details).

1.Technical specifications for the symbolization of cartographic series

1.1. How to define a series

Cartographic series are defined from a REL file that specifies its characteristics (descriptive title of the series, how it is visualized, how the legend must be shown, etc). This file is not directly associated with any specific graphical layer, but is linked to all the sheets in the series.

The REL file that describes the series can have any name. Its general structure is similar to other REL and MMM files: it is organized in sections and each section has a different name which is closed between brackets. Sections can be disorganized within the file and it is not necessary that they are all present.

Up to the date of this document, the supported sections are

  • [DOCUMENT] -> Section that describes general documentation of the series.
  • [COLOR_TEXT] -> Section giving several information that is useful in recognizing the characteristics of the visualization of the series.
  • [VISU_LLEGENDA] -> Section that describes how a series legend is shown.

Inside each section there is a set of key words followed by a sign equal and of a value or chain of characters. Up to the date of this document, supported key words are:

In the [DOCUMENT] section:

  • TitolSerie: Title of the map series. A description of up to 80 characters that is used to identify the series.

In the [COLOR_TEXT] section:

  • See relative entry [VECTOR_#] of MiraMon maps (MMM, MMZ and MMZX) and templates formats description, in the specifications of the visualization parameters. Note that if a file belongs to one series, this sections has priority over the homonymous REL section of the specific file (sheet).

In the [VISU_LLEGENDA] section:

  • See the section Control of the legend from MMM and REL files, in MiraMon general visualization characteristics where the parameters are explained in detail. Note that if a file belongs to one series, this section has priority over the homonymous REL section of the specific file (sheet).

NOTE: Sections [COLOR_TEXT] and [VISU_LLEGENDA] can be copied directly from the REL file from any sheet of the series. Check that the relative directions of the symbolization tables are properly entered and that fields such as ValorColor_0 (ValueColor_0) and ValorColor_n_1 (ColorValue_n_1) are in accordance with the whole series.

1.2. How to assign a sheet to a series

Method 1: Full Assignation

With the objective that a graphic file (a specific sheet) belongs to a series it is simply necessary that in its REL file the section [SERIES_CARTO] appears and the key word Serie_1.

For example, the file 297x89C.ARC, that contains the arcs of the primary topographic lines (C) of the sheet 297x89 of the 1:5000 Catalonia topographic series, have a REL file alongside (297x89Ca.REL) which contain the two following lines:

[SERIES_CARTO]
Serie_1=Top5kC.rel

Observe that Top5kC.rel is simply the number of the REL file that describes the series. This file can be placed in other directories, disks or computers if convenient.

Serie_1=..\..\Series\Top5kC.rel
Serie_1=F:\Series\Top5kC.rel
Serie_1=\\SERVIDOR\Series\Top5kC.rel

Its location, when expressed with a relative path or without one, uses the directory referenced in the same REL sheet.

Method 2: Assigning exclusively from a map in MiraMon

Sometimes it is convenient that a graphical file belongs to a series when it is opened from a map in MiraMon, but not when it is opened as an individual file. In this case the parameter "SerieColorTextVisuLlegenda" must be added to the section that contains the characteristics of visualization and treatment of the legend of the file of the map. The following sections include additional considerations and concrete examples.

1.3. Cartographic series and MiraMon Maps

MiraMon maps specify the files and characteristics of visualization that belong to a certain map. The specified parameters in the MiraMon maps have priority over those specified in the REL file of a specific layer. This way, although each layer has conditions of visualization by default that are directly applied (for example through a "File | Open structured vector"), under certain saved file combinations in a map, the layer can have other visualization combinations when desired.

By default, cartographic series follow the same criteria as individual layers: the specifications of MiraMon maps prevail over what is indicated in the series REL. When a map is saved, MiraMon writes the conditions of visualization of each layer in that moment and loses any link with the individual REL's or of a series (although, as it is explained below, the option "Maintain cartographic series" be activated).

Nevertheless, in some cases it is interesting that the MMM file has no indications over the visualization or the legend and is remitted to the characteristics indicated in the REL series. This is useful, for example, to show the sheets of a conventional topographic map based on several thematic series (layers) of hypsometry, hydrography, etc. With this method the need to specify this information in each of the MMM of the topographic series is solved and, more importantly, the user can change the visualization of all the topographic series with the specifications of the thematic series RELs that make it up.

To indicate this dependence simply active the box Maintain cartographic series in the dialog box of the map saver. When this box is checked, MiraMon adds a map parameter SerieColorTextVisuLlegenda in the section that contains the visualization characteristics and treatment of the legend of each of the layers (for example: C, S, H, etc). The value by default of this box when MiraMon is launched can be configured from the parameter MantenirSeriesCartografiquesEnMMM in the file MiraMon.par.

For example, the file 297x88.MMM that contains the different thematic layers of hypsometry and hydrography, etc, of the topographic sheet 297x88, could have the following appearance:

[VECTOR_1]
File=SIG\Carto\Topo_5k\297x88C.arc
SerieColorTextVisuLlegenda=Top5kC.rel

[VECTOR_2]
File=SIG\Carto\Topo_5k\297x88H.arc
SerieColorTextVisuLlegenda=Top5kH.rel

etc.

This way, MiraMon knows that the visualization of the layer 297x88C must be governed by the criteria of the series Top5kC, the layer 297X88H by the criteria of the series Top5kH, etc.

ATTENTION: the location of the files of a series are relative to the directory of the MMM file, not the directory of the sheet. This way, one sheet can be visualized according to different series (REL files) located in different directories according to the location of the MMM file.

This structure has the additional advantage that can save more than one set of symbolization for all of the sheets of the same series easily, consistently and occupying a minimum of space in the disc. For example, in the aforementioned case a second file 297x88BN.MMM, that contains the same thematic layers of the 297x88.MMM but specifying that all of the elements should be colored black. This is useful, for example, when printing the sheets in a printer of black and white (B/N) or over photographic images or of a satellite in color. The MMM in question could have the following aspect:

[VECTOR_1]
File=SIG\Carto\Topo_5k\297x88C.arc
SerieColorTextVisuLlegenda=Top5kCBN.rel

[VECTOR_2]
File=SIG\Carto\Topo_5k\297x88H.arc
SerieColorTextVisuLlegenda=Top5kHBN.rel

etc.

The files Top5kCBN.rel, Top5kHBN.rel, etc, contain a section [COLOR_TEXT] which indicates the desired color constant and black. Additionally, for more advanced users, the parameter "SerieColorTextVisuLlegenda" consists of permitting that a certain file is assigned to one series alone when it is loaded through a map, but so that it is unassigned to any series when it is opened as an individual layer. In fact, MiraMon supports the existence of the parameter "SerieColorTextVisuLlegenda" but not the existence of the section [SERIES_CARTO] in the REL file. Given that the files that are open and belong to a series are used exclusively with other open sheets of the series, this configuration can be useful for the possibility of working with a file completely unlinked of the series: this way when the file is opened in a normal method, through an MMM, it is governed by the characteristics of the series, but when it is opened as an individual layer (for example through "File | Open structured vector") it is treated completely unlinked to the series.

Precaution: The activation of the box "Maintain cartographic series" can cause unexpected results if its function is not properly understood. In fact, as explained, if it is not activated, its behavior will be the default map behavior. Meaning that if the colors, legend, etc, are modified its values will be those saved in the map and, when it is reopened, they will appear the same as when they were saved. On the other hand, if the box is checked, when it is reopened the colors, legend, etc will appear in the standard format of the series and not those of the modified visualization. In other words, if the visualization characteristics are modified of the series and they are saved in a map, this option must not be activated as the map will not be visually represented in the same way as it is seen now. On the other hand, if a map is saved where there are certain layers opened that belong to a cartographic series of which the visualization conditions haven't been modified the activation "Maintain cartographic series" has the advantage that if at some point new characteristics are added to the REL series or if another standard presentation is adopted (for example thicker topographic lines), the reopening of the map will follow the standard rules of the series.

Finally, remember that the option to manually create a new visualization and legend series is possible. The protocol to do this is as follows:

  1. Save a map "NOVALE.MMM" without checking the box "Maintain cartographic series". 1. Save a map "NOVALE.MMM" without checking the box "Maintain cartographic series". Save it in the same directory where series RELs will also be saved.
  2. Save another map with the valid name (for example "INFO_98.MMM") but activating the check box "Maintain cartographic series".
  3. Edit using Notepad NOVALE.MMM and following the corresponding sections, create one or more REL files with the sections [COLOR_TEXT] and [VISU_LLEGENDA]. Use as a model any REL series and/or the explanations given the previous REL format that describe the series. Keep in mind that the references relative to other files (symbolization tables, etc) may need your attention if those series RELs are saved in a directory different to the file where NOVALE.MMM is saved.
  4. EDIT with Notepad the valid map file ("INFO_98.MMM") and write, in all layers (sections) to have the key "SerieColorTextVisuLlegenda", the names of the proper RELs (the ones written in the previous step).
  5. Delete "NOVALE.MMM".

2. Technical specifications of cartographic series metadata: definition of the multiseries, of the series, of the sheet of the series and the layer of the sheet

  • 2.1 Definition of the multiseries

    Multiseries is defined from a REL file that contains its metadata and a DBF table containing the list of sheet-layers that make up the multiseries as well as the description of what subject, date and sheet (and of what tiling scheme) corresponds each layer. The structure of the DBF must have at least some predefined name fields.

    Table *.dbf

    • 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