Series cartográficas en MiraMon

Una serie cartográfica es un conjunto de hojas a una misma escala que cubren, adyacentemente, la totalidad de un territorio desde un mismo punto de vista (topografía, vegetación, geología, etc). En la cartografía convencional sobre papel las series existen porque a menudo, dado un territorio de cierta extensión y a cierta escala de representación, se necesitaría una hoja demasiado grande para representarlo todo en un solo mapa. La división en hojas soluciona simultáneamente dos problemas: la imposibilidad de impresión en un papel extensísimo y la inmanejabilidad práctica de hojas muy grandes.

En la cartografía digital puede tratarse todo el territorio como un espacio totalmente continuo y olvidar la división en hojas. De hecho, esta posibilidad se presenta frecuentemente como una ventaja de los sistemas de información geográfica (SIG) respecto a la cartografía convencional. No obstante, todavía hoy resulta interesante que los SIG soporten el tratamiento en hojas. Hay dos razones principales para este hecho:

En primer lugar hay una simple razón de tradición o, si se quiere, de simetría con la cartografía analógica: muchos usuarios encuentran agradable que haya una buena correspondencia entre las unidades de tratamiento en el ordenador y los mapas que tienen impresos (habitualmente editados por algún centro productor de cartografía).
En segundo lugar, cuando la serie abarca un gran territorio y tiene una escala muy detallada, incluso en los ordenadores más modernos resultaría poco práctico el tratamiento como una sola pieza. Por ejemplo, en las cargas remotas desde una red o en las interrogaciones por atributo, la división en hojas resulta adecuada porque nos permite limitar el alcance territorial del material que queremos consultar de una forma rápida y fácil.

A pesar de lo que acabamos de decir, la división en hojas presenta también conocidos inconvenientes, principalmente derivados de la fragmentación, y que el SIG debe intentar tratar de la forma más inteligente posible. A partir de la versión 4.0 de MiraMon se da soporte a las series cartográficas desde el punto de vista de la representación y la leyenda, pero no desde un punto de vista analítico. En otras palabras, MiraMon conoce la existencia de la serie y, gracias a esto, permite que un cambio de simbolización (color, etc), un cambio de estado de "visible", "consultable", "unificar visible/consultable", un cambio de escalas de visualización, etc, se propague por todas las hojas de la serie sin tener que explicitarlo hoja a hoja; también puede indicarse más de un juego de simbolización para todas las hojas de la misma serie de forma sencilla, pero en cambio no permite propagar una consulta a todas las hojas de la serie. Además, MiraMon también permite disponer de metadatos a nivel de serie cartográfica.

Por otra parte, habitualmente la leyenda es común a toda la serie y sería inadecuado que si tenemos abiertas 6 hojas apareciese 6 veces la descripción de la leyenda, de manera que simplemente aparece la descripción una sola vez.

MiraMon mantiene las series cartográficas en un mismo "plano" de orden de capas, es decir, al abrir una capa perteneciente a una serie o un mapa con capas que pertenecen a una serie, reordena las capas abiertas de manera que se dibujan consecutivamente con las de la misma serie que ya estaban abiertas; esto resulta estéticamente mejor y es útil porqué en el gestor de capas aparecen agrupadas todas las del mismo concepto (serie). Si el usuario cambia el orden de una capa, MiraMon automáticamente vela porque las otras de la misma serie le queden consecutivas en el orden general de capas. Por último, la serie tiene un título identificativo que se utiliza en lugar del nombre particular de cada hoja (por ejemplo una hoja constitutiva de la serie quizá lleve por título "Mapa geológico 1:5000. Hoja 444-1-1. Riba-Roja d'Ebre", pero quizás la serie debe designarse como "Mapa geológico 1:25000").

En futuras versiones MiraMon también dará soporte a las series cartográficas desde un punto de vista analítico, es decir, dada una consulta por localización sobre un elemento que tiene continuidad en otras hojas (por ejemplo un río), la información ofrecida será relativa a todo su trazado, no solamente a la hoja sobre la que hemos consultado. De la misma manera, las consultas por atributo y otras operaciones de análisis detectarán que estamos actuando sobre una serie y considerarán la continuidad territorial de los elementos.

Nota importante relativa a las seriestopográficas:

Las series topográficas convencionales suelen tener diversos elementos (curvas de nivel, hidrografía, vías de comunicación, etc). Aunque sería posible mantener la serie original con todas las capas en un solo fichero gráfico (excepto si son de naturaleza geométrica diferente), aconsejamos vivamente que se aproveche la posibilidad de estructurar en capas "temáticas" las series topográficas convencionales.

Así, por ejemplo, las hojas del mapa topográfico 1:5000 de Cataluña, numerados como "AAAxBB", donde "AAA" es el número de columna y "BB" el número de fila, pueden tenerse en diversas capas con la denominación "AAAxBBT", donde T puede ser un código temático (C para curvas de nivel principales, S para secundarias, H para hidrografía, etc). Una hoja concreta de hidrografía puede ser la 297x89H.

Con esto se manejan ficheros más pequeños y las consultas, etc, son más específicas a la temática a tratar en cada momento (curvas de nivel, vías de comunicación, etc). Si se desea abrir todas las diferentes temáticas simultáneamente, tal y como se ve en las hojas topográficas impresas, la opción correcta pasa por definir un mapa MiraMon que abra los ficheros adecuados en cada caso (por ejemplo que abra 297x89C, 297x89S, 297x89H, etc) e indicar, a través del parámetro "SerieColorTextVisuLlegenda" que las características de visualización y tratamiento de la leyenda de todas las capas (C, S, H, etc) sigan los criterios de las series generales correspondientes (véase más abajo para más detalles).

1. Especificaciones técnicas de las series cartográficas

1.1. Cómo definir la serie

Las series cartográficas se definen a partir de un fichero REL en el que se especifican sus características (título descriptivo de la serie, cómo se visualiza, cómo debe mostrarse en la leyenda, etc). Este fichero no está directamente asociado a ninguna capa gráfica en concreto, sino que se considera vinculado a todas las hojas de la serie.

El fichero REL que describe la serie puede tener cualquier nombre. Su estructura general es similar a la de otros ficheros REL y MMM: está organizado en secciones y cada sección tiene un nombre diferente, el cual se halla cerrado entre claudátors. Las secciones pueden estar desordenadas en el interior del fichero y no es necesario que todas estén presentes.

Hasta la fecha de este documento, las secciones soportadas son:

[DOCUMENT] -> Sección que describe documentación general de la serie.
[COLOR_TEXT] -> Sección que da diversas informaciones que serán utilizadas para conocer las características de visualización de la serie.
[VISU_LLEGENDA] -> Sección que describe cómo se muestra la serie en la leyenda

En el interior de cada sección hay una serie de palabras clave seguidas de un signo igual y de un valor o cadena de caracteres. Hasta la fecha de este documento, las palabras clave soportadas son:

En la sección [DOCUMENT]:

TitolSerie: Título de la serie mapa. Es una descripción, de hasta 80 caracteres, que será utilizada para identificar la serie.

En la sección [COLOR_TEXT]:

Véase la entrada relativa a [VECTOR_#] de Descripción de los formatos mapa (MMM, MMZ y MMZX) y plantillas de MiraMon, en las especificaciones de los parámetros de visualización. Nótese que si un fichero pertenece a una serie, ésta sección tiene prioridad sobre la sección homónima del REL del fichero específico (hoja).

En la sección [VISU_LEGENDA]:

Consúltese el apartado Control de la leyenda desde los ficheros MMM y REL, de los Aspectos generales de visualización en MiraMon. En él se detallan los parámetros. Nótese que si un fichero pertenece a una serie, esta sección tiene prioridad sobre la sección homónima del REL del fichero específico (hoja).

NOTA: Las secciones [COLOR_TEXT] y [VISU_LLEGENDA] pueden ser copiadas directamente del REL de una hoja cualquiera de la serie. Simplemente cuíidese de que las direcciones relativas de las tablas de simbolización estén bien entradas y que campos como ValorColor_0 y ValorColor_n_1 tengan sentido para toda la serie.

1.2.Cómo asignar una hoja a una serie

Método 1: Asignación plena

Con objeto de que un fichero gráfico (una hoja concreta) pertenezca a una serie simplemente hace falta que en su fichero REL aparezca la sección [SERIES_CARTO] y, en ésta, la palabra clave Serie_1.

Por ejemplo, el fichero 297x89C.ARC, que contiene los arcos de las curvas de nivel principales (C) de la hoja 297x89 del topográfico 1:5000 de Cataluña, tiene un fichero REL acompañante (297x89Ca.REL) dentro del cual pueden incluirse las dos líneas siguientes:

[SERIES_CARTO]
Serie_1=Top5kC.rel

Obsérvese que Top5kC.rel es simplemente el nombre del fichero REL que describe la serie. Este fichero puede ubicarse en otros directorios, discos u ordenadores si conviene:

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

Su ubicación, cuando se exprese con un path relativo o sin path, toma como directorio de referencia el del REL de la propia hoja.

Método 2: Asignación exclusivamente desde un Mapa MiraMon

A veces puede ser conveniente que un fichero gráfico pertenezca a una serie cuando se abre desde un Mapa MiraMon, pero no cuando se abre como fichero individual. En este caso se debe añadir el parámetro "SerieColorTextVisuLlegenda" a la sección que contiene las características de visualización y tratamiento de la leyenda del fichero en el mapa. En la siguiente sección encontrará consideraciones adicionales y ejemplos concretos.

1.3. Series cartográficas y Mapas MiraMon

Como ya sabemos, los mapas MiraMon especifican los ficheros y características de visualización que conforman cierto mapa. Los parámetros especificados en los mapas MiraMon tienen prioridad sobre los especificados en el fichero REL de una capa concreta. De esta manera, aunque cada capa tiene unas condiciones de visualización por defecto, que se aplican cuando la capa se abre directamente (por ejemplo a través de "Fichero | Abrir vector estructurado"), bajo cierta combinación de ficheros guardada en un mapa, aquella capa puede tener otras condiciones de visualización si así se desea.

Por defecto, las series cartográficas siguen el mismo criterio que las capas individuales: las especificaciones del Mapa MiraMon (MMM) prevalecen sobre lo indicado en el REL de la serie. Cuando guardamos un mapa, MiraMon escribe las condiciones de visualización de cada capa en aquel momento y se pierde cualquier vinculación con los REL individuales o de series (salvo que, como se explica más abajo, se active la opción "Mantener series cartográficas").

Sin embargo, en algunos casos resulta interesante que el fichero MMM no indique nada sobre la visualización ni la leyenda, y se remita a las características indicadas en el REL de la serie. Esto es útil, por ejemplo, para montar las hojas de un mapa topográfico convencional basado en diversas series (capas) temáticas de hipsometría, hidrografía, etc. De esta manera nos evitamos tener que especificar esta información en cada uno de los MMM de la serie topográfica y, lo que es más importante, pueden efectuarse cambios en la visualización de toda la serie topográfica simplemente cambiando las especificaciones en los RELs de las series temáticas que la componen (el REL de la serie de hipsometría, el de la serie de hidrografía, etc).

Para indicar esta dependencia simplemente active la casilla Mantener series cartográficas en la caja de diálogo de guardar el mapa. Cuando esta casilla está activada, MiraMon añade al mapa el parámetro SerieColorTextVisuLlegenda en la sección que contiene las características de visualización y tratamiento de la leyenda de cada una de las capas (por ejemplo: C, S, H, etc). El valor por defecto de esta casilla cuando se inicia MiraMon puede configurarse a partir del parámetro MantenirSeriesCartografiquesEnMMM del fichero MiraMon.par.

Por ejemplo, el fichero 297x88.MMM, que contiene las diferentes capas temáticas de hipsometría, hidrografía, etc, de la hoja topográfica 297x88, podría tener el siguiente aspecto:

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

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

etc.

De esta manera, MiraMon sabe que la visualización de la capa 297X88C debe ser gobernada por los criterios de la serie Top5kC, la de la capa 297X88H por los criterios de la serie Top5kH, etc.

ATENCIÓN: La ubicación de los ficheros de la serie se supone relativa al directorio del fichero MMM, no al directorio de la hoja. De esta manera, una misma hoja puede ser visualizada según diferentes series (ficheros REL) ubicadas en diferentes directorios según el fichero MMM donde esté.

Esta estructura tiene la ventaja adicional de poder almacenar más de un juego de simbolización para todas las hojas de la misma serie de forma fácil, consistente y ocupando un mínimo espacio de disco. Por ejemplo, en el caso anterior podríamos tener un segundo fichero, 297x88BN.MMM, que contiene las mismas capas temáticas que el 297x88.MMM pero especificando que queremos todos los elementos en color negro. Esto es útil, por ejemplo, para cuando quiera imprimir las hojas en una impresora en blanco y negro (B/N) o sobre imágenes fotográficas o de satélite en color. El MMM en cuestión podría tener el siguiente aspecto:

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

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

etc.

Los ficheros Top5kCBN.rel, Top5kHBN.rel, etc, contendrán una sección [COLOR_TEXT] en la que se indicará que se desean todos los colores constantes y negros. Otra utilidad, ya para usuarios más avanzados, del parámetro "SerieColorTextVisuLlegenda" consiste en permitir que cierto fichero se asigne a una serie solamente cuando se carga a través de un mapa, pero que no se encuentre asignado a ninguna serie cuando se abre como capa individual. En efecto, MiraMon soporta que exista el parámetro "SerieColorTextVisuLlegenda" pero que no exista la sección [SERIES_CARTO] en el REL del fichero. Dado que los ficheros que estan abiertos y pertenecen a una serie se tratan solidariamente con las otras hojas abiertas de la serie, esta configuración puede ser útil si quiere tener la posibilidad de tratar el fichero de forma totalmente desligada de la serie: de esta manera cuando lo abra en la forma normal, a través de un MMM, es gobernado por las características de la serie, pero cuando lo abra como capa individual (por ejemplo a través de "Fichero | Abrir vector estructurado") se le trata de forma totalmente desligada de la serie.

¡Precaución: la activación de la casilla "Mantener series cartográficas" puede dar sorpresas si no se comprende bien su funcionamiento. En efecto, tal y como hemos explicado, si no está activada, el comportamiento es el normal en los mapas, es decir, si ha modificado los colores, leyenda, etc, los valores modificados serán los que se guardarán en el mapa y, cuando se reabra, aparecerán iguales a como estaban cuando los guardó. En cambio, si la casilla está activada, cuando se reabra, aparecerán los colores, leyenda, etc, estándar de la serie, y no los de la visualización modificada. En otras palabras, si se modifican las características de visualización de la serie y se graba un mapa, no se debe activar esta opción porque al reabrir el mapa no será igual a como se ve ahora. En cambio, si se graba un mapa en el cual hay capas abiertas que pertenecen a series cartográficas de las cuales no se ha modificado las condiciones de visualización, la activación de "Mantener series cartográficas" tiene la ventaja de que si un día se añade a los REL de la serie nuevas características o se decide por otra presentación estándar (por ejemplo curvas de nivel más gruesas), la reapertura del mapa seguirá las normas estándar de la serie.

Finalmente, recuérdese que también puede optarse por activar esta opción y crear manualmente una nueva serie de visualización y leyenda. Puede seguirse el protocolo siguiente:

Guarde un mapa "NOVALE.MMM" sin activar la casilla "Mantener series cartográficas". Guárdelo en el directorio donde irán los RELs de la serie o series a crear.
Guarde otro mapa con el nombre válido que desee (por ejemplo "INFO_98.MMM") pero activando la casilla "Mantener series cartográficas".
Edite con el bloc de notas NOVALE.MMM y, a partir de las secciones correspondientes, cree uno o más ficheros REL con las secciones [COLOR_TEXT] y [VISU_LLEGENDA]. Utilice como modelo cualquier REL de serie y/o las explicaciones dadas anteriormente sobre el formato de los REL que describen las series. Tenga presente que las referencias relativas a otros ficheros (tablas de simbolización de color, etc) pueden necesitar una atención especial si los RELs de la serie se guardan en un directorio diferente a aquél donde ha guardado NOVALE.MMM.
Edite con el bloc de notas el fichero mapa válido ("INFO_98.MMM") y escriba, en todas las capas (secciones) que tengan la clave "SerieColorTextVisuLlegenda", los nombres de los RELs adecuados (los que acaba de crear en el punto anterior).
Borre "NOVALE.MMM".

2. Especificaciones técnicas de los metadatos de las series cartográficas: definición de la multiserie, de la serie, de la hoja de la serie y de la capa de la hoja

2.1 Definición de la multiserie

Una multiserie se define a partir de un fichero REL que contiene sus metadatos y una tabla DBF que contiene la lista de capas-hoja que forman la multiserie así como la descripción de qué tema, fecha y hoja (y de qué corte) corresponde cada capa. La estructura de la DBF debe tener como mínimo unos campos de nombre predefinidos.

Tabla*.dbf

FITXER: Dirección del archivo gráfico de la capa-hoja (arc, pol, etc.), relativa a la del fichero REL y DBF de la Multiserie.
ID_TEMA: Identificador del tema de la capa-hoja.
ID_DATA: Año o versión de la capa-hoja. Por ejemplo, en el caso de la Multiserie 'Topográfica' podría ser v2.0, etc. y en el caso del Mapa de Cubiertas del Suelo de Cataluña podría ser 1993 o 2000.
ID_FULL: A qué hoja corresponde esta capa-hoja
ID_TALL: A qué corte se corresponde la hoja definida en el campo anterior

Así, por ejemplo, algunos registros de esta tabla podrían ser:

bt5mv20.dbf

FICHERO	ID_TEMA	ID_DATA	ID_FULL	ID_TALL
f241x156\bt5mv20mm0f241156ac0r020.pnt	AltimetriaCotas	v2.0	241-156	MTN/IGN-5m
f241x156\bt5mv20mm0f241156rv0r020.pnt	PuntosReferenciaVerticesGeodesicos	v2.0	241-156	MTN/IGN-5m
f241x156\bt5mv20mm0f241156an0r020.pnt	AltimetriaTextosCurvasNivel	v2.0	241-156	MTN/IGN-5m
…	…	…	…	…
f242x138\bt5mv20mm0f242138ac0r020.pnt	AltimetriaCotas	v2.0	242-138	MTN/IGN-5m
f242x138\bt5mv20mm0f242138an0r020.pnt	AltimetriaTextosCurvasNivel	v2.0	242-138	MTN/IGN-5m
f242x138\bt5mv20mm0f242138hn0r020.pnt	HidrografiaToponimia	v2.0	242-138	MTN/IGN-5m
f242x138\bt5mv20mm0f242138mn0r020.pnt	MedioNaturalToponimia	v2.0	242-138	MTN/IGN-5m

Esta tabla está relacionada con otras tablas (con sufijo prefijado) que contienen los vínculos a raíces que definen las diferentes series (AltimetriaCotas, PuntossReferenciaVerticesGeodesicos, etc. siguiendo el ejemplo) y las diferentes hojas de la serie (241-156 y 242-138 del corte MTN/IGN-5m, siguiendo el ejemplo).

Las relaciones con estas otras tablas son a partir de campos combinados, como se irá comentando en las siguientes secciones. En el fichero REL de la Multiserie se definen las relaciones con estas tablas a través de campos 'simples', como habitualmente. Esto es suficiente para definir las relaciones pero no lo será para realizar las comprobaciones desde el GeM+. El Gestor Universal de Metadatos Geoespaciales, al entrar en la pestaña "Metadatos | Series" para una Capa- Hoja que forma parte de la Multiserie realiza las comprobaciones "estrictas" (usando la información de ambos campos a la vez).

Metadatos de la Multiserie

Para cualquier archivo de metadatos ahora se definen unas entradas nuevas de metadatos que permiten definir el nivel jerárquico de aquel conjunto de metadatos. La entrada de metadatos que contiene esta información proviene del estándar ISO19115, se denomina hierarchyLevel y se encuentra en la sección 'METADATOS'. Puede tomar 2 valores: 005, por capa (valor por defecto), y 006, por serie (códigos correspondientes al code-list MD_ScopeCode del estándar citado).

Los metadatos de la multiserie se corresponden al nivel jerárquico de serie, por lo tanto el REL de la multiserie encontraremos:

[METADADES]
; es un rel de SERIE
hierarchyLevel=006

En el modelo utilizado se utilizarán tres tipos de series diferentes: multiserie, serie y hoja de serie. Todos ellos tienen el mismo nivel jerárquico 'serie'. Utilizamos el miembro hierarchyLevelName para identificar con nombres prefijados el tipo de serie (según ISO esta es una entrada de texto libre, pero nosotros reconocemos algunos 'valores especiales'). Para las multiseries el REL se guardará:

[METADADES]
; es un rel de SERIE
hierarchyLevel=006
; de tipo 'Multisèrie'
hierarchyLevelName=##Multiserie##

En los metadatos también se debe definir las relaciones de este conjunto de metadatos con otros conjuntos de metadatos. El estándar ISO define dos vías para definir estas relaciones:

parentIdentifier: Es el FileIdentifier del metadato de la que esta es una parte. Se refiere al 'padre de los metadatos'. Sólo puede haber un parentIdentifier por conjunto de metadatos según ISO. Esto no resulta muy adecuado para porque querremos, desde la capa-hoja, explicar los tres 'padres' que tiene: serie, hoja y multiserie (la capa-hoja coge metadatos de los tres conjuntos de metadatos).
aggregateInfo: aporta información sobre la agregación de capas. Es de cardinalidad N y, por tanto, nos permite definir tantos niveles de agregación como sea necesario. Se refiere a los datos y no a los metadatos.

Usaremos el parentIdentifier para referirnos directamente a la multisErie desde los metadatos de las capas-hoja, las series y las hojas de serie. En teoría es necesario guardar el FileIdentifier del metadato correspondiente, pero en el modelo MiraMon nos es más útil guardar la dirección relativa del REL de la multiserie, que se guardará en la clave parentIdentifierFile1 del REL (clave "no ISO"). Los metadatos de la multiserie no definen ningún valor en esta clave.

[METADADES]
; es un rel de SERIE
hierarchyLevel=006
; de tipo 'Multiserie'
hierarchyLevelName=##Multiserie##
; y por tanto no tiene ningún parentIdentifierFile1
; parentIdentifierFile1=

Los metadatos comunes a este nivel jerárquico son, por ejemplo, parte del título (topográfico), la escala equivalente, etc.

Esquema de los archivos que definen la Multiserie

2.2 Definición de la serie

Cada una de las series que forman Multiserie se define a partir de un REL que contiene sus metadatos. Hay un archivo DBF que contiene la lista de las series que forman multiserie. La tabla puede tener cualquier nombre pero se recomienda que sea el mismo que el de la tabla principal de la Multiserie con el sufijo "_TemaData". Esta tabla contiene el nombre de todas las series e indica cuál es el REL que describe los metadatos de cada una de ellas. La estructura de la DBF debe tener como mínimo unos campos de nombre predefinidos.

Tabla *_TemaData.dbf

Esta tabla contiene los valores posibles de combinaciones del campo 'Tema' y el campo 'Fecha' de la tabla anterior. Cada combinación corresponde a una 'Serie'. Esta tabla se relaciona con la de la multiserie a partir del campo combinado ID_TEMA-ID_DATA, que aparece en las dos tablas. Los campos de la tabla son:

ID_TEMA: Identificador del tema de la capa-hoja.
ID_DATA: Año de la revisión de la capa-hoja
FITXER: Dirección del fichero REL que define los metadatos de la serie, relativa a la del fichero REL i DBF de la multiserie
ORDRESERIE: Campo opcional que permite indicar el orden de los registros si hay peligro de recuperar la tabla en un orden incorrecto
MS_PARCIAL: Campo opcional que indica el nombre de la Multiserie parcial a la cual pertenece esta serie. Este nombre es libre pero evidentemente debe ser diferente para cada multiserie parcial definida dentro de una multiserie. Véase más información en el apartado "Aspectos de la visualización de la Multiserie".
NIV_MS_PAR: Campo opcional que indica el número de niveles (es decir, el número de iteraciones de dibujado) que contiene la Multiserie parcial a la cual pertenece esta serie. Este nombre es libre pero evidentemente debe ser igual para todas las series de la misma Multiserie parcial. Véase más información en el apartado "Aspectos de la visualización de la Multiserie".

Así, por ejemplo, algunos registros de esta tabla podrían ser:

ID_TEMA	ID_DATA	FICHERO
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

Metadatos de la serie

Los metadatos de la serie se corresponden también al nivel jerárquico de serie; por tanto, en cada uno de los REL de serie (tantos como registros en la tabla bt5mv20_TemaData.dbf) encontraremos:

[METADADES]
;es un rel de SERIE
hierarchyLevel=006

Para las series, en el REL se guardará hierarchyLevelName igual a serie:

[METADADES]
; es un rel de SERIE
hierarchyLevel=006
;de tipus 'Serie'
hierarchyLevelName=##Serie##

[METADADES]
;es un rel de SERIE
hierarchyLevel=006
; de tipo 'Sèrie'
hierarchyLevelName=##Serie##
; y, por tanto, su parentIdentifierFile1 es la Multiserie
parentIdentifierFile1=..\bt5mv20.rel

También es necesario que el FileIdentifier de la Serie sea uno fijado: aquel que sale de la combinación del contenido de los campos ID_TEMA y ID_DATA correspondientes (de la tabla de definición de series) separados por un "_". Así, por ejemplo, el FileIdentifier de la primera serie del ejemplo (tabla bt5mv20_TemaData.dbf), será PoblamentToponimiaPrincipals_v2.0, y, por tanto, la sección de metadatos completa es:

[METADADES]
FileIdentifier=PoblamentToponimiaPrincipals_v2.0
; es un rel de SERIE
hierarchyLevel=006
; de tipo 'Serie'
hierarchyLevelName=##Serie##
; y, por tanto, su parentIdentifierFile1 es la Multiserie
parentIdentifierFile1=..\bt5mv20.rel

Algunos de los metadatos comunes a toda una Serie son una parte del título, la descripción del linaje y de las fuentes del linaje (a partir de qué información y cómo se capturan los datos), una fecha general temática, la estructura de la base de datos y la calidad general de cada uno de los campos de la base de datos, etc.

Nota: el tamaño máximo del FileIdentifier es 253, y dado que el de la serie se construye a partir del contenido de los campos ID_TEMA y ID_DATA más el carácter "_", ES NECESARIO que el tamaño máximo de estos dos campos sumados sea, como máximo, 252.

Esquema de los ficheros que definen la Serie

Orden de visualización de las capas en la Multiserie

El orden de las series en la tabla *_TemaData indica el orden de las capas en la visualización. Este orden "manda" sobre el orden de los mapas y permite controlar correctamente el orden de todas las capas, incluso aquellas que forman parte de la Multiserie y que no estaban presentes en la primera de las hojas abiertas con MiraMon. Cuanto más arriba se encuentre un registro en la tabla _TemaData, más arriba estará en el orden de capas. Este esquema de visualización es el tradicional en el que el orden de capas es "estricto" en tanto que se dibujan todos los objetos de una capa a la vez y, después, los de la segunda capa, y así hasta el final. Si se desea se puede indicar un campo ORDRESERIES que permita reordenar la tabla si existe peligro de recuperarla en un orden de registros incorrecto en una selección SQL (use "order by").

En algunos casos es necesario usar un esquema más complejo de visualización ya que hay que dibujar los objetos de algunas capas de manera combinada, en varias "iteraciones de dibujado". Por ejemplo puede ser necesario dibujar primero algunos objetos de la capa 1, después algunos de la capa 2, después algunos de la capa 3, luego el resto de objetos de la capa 2, y finalmente el resto de la capa 1 y el resto de la capa 3. Esta necesidad ha surgido para poder implementar correctamente la visualización de la Multiserie BT25M del ICGC (Instituto Cartográfico y Geológico de Cataluña), donde hay que combinar el dibujado de algunas de las capas de Vías de comunicación a fin de poder hacer pasar una carretera secundaria por encima o por debajo de una autopista, según convenga, a pesar de que los dos tipos de entidades esten en capas diferentes.

Para implementar esta estrategia de visualización han sido necesarias varias ampliaciones a la primera versión del modelo. Es necesario definir un campo nuevo (MS_PARCIAL) en la tabla que describe las series. Este campo está en blanco para todas las series que no tienen ninguna visualización agrupada con otras capas, y tiene un valor igual para todas las series (y capas) del mismo grupo que hay que combinar. Todas las series que forman parte de la misma Multiseie Parcial deben estar juntas en el orden de visualización .

En el REL de cada capa-hoja que forme parte de una de estas multiseries Parciales es necesario que exista, en la sección [METADATOS], una nueva clave OrdreDintreMultiSerieParcial1. Esta clave indica, separados por comas, los identificadores gráficos de los objetos de la capa que hay que dibujar en cada una de las iteraciones en que se pintarán las capas. Se denominan Niveles de la Multiserie parcial el número de iteraciones de dibujado para las capas que forman parte de la Multiserie parcial. Esta información se guarda en el campo NIV_MS_PAR de la tabla que describe las series y debe coincidir con el número de separadores más uno de la clave OrdreDintreMultiSerieParcial1 de las capas-hoja. Al leer la tabla MiraMon controla que todos los valores de las MSP de igual nombre sean iguales y mayores que cero y avisará si detecta inconsistencias.

Imaginemos un ejemplo sencillo con sólo 3 series: "Vías urbanas" (ViesComunicacioViesUrbanes), "Vías convencionales" (ViesComunicacioViesConvencionals) y "Autopistas y vías preferentes" (ViesComunicacioAutopistesViesPreferents) que formen parte de la misma multisèrie parcial, denominada "Vías de Comunicación" (ViesComunicacio). En la tabla DBF sobre las series indicará:

bt25mv10_TemaData.dbf

ID_TEMA	ID_DATA	FICHERO	MS_PARCIAL	NIV_MS_PAR
ViesComunicacioViesUrbanes	v1.0	...	ViesComunicacio	6
ViesComunicacioViesConvencionals	v1.0	…	ViesComunicacio	6
ViesComunicacioAutopistesViesPreferents	v1.0	…	ViesComunicacio	6

Como se ha indicado, cada REL de Capa-hoja que forme parte de esta multiserie parcial indicará la entrada del OrdreDintreMultiSerieParcial1 (aparte de las informaciones habituales de esta sección, obviadas aquí por claridad):

REL de la capa hoja de la serie "Vies urbanes":
[METADADES]
OrdreDintreMultiSerieParcial1=0-0,1-7,8-5301,,5302-5303,

REL de la capa-hoja de la serie "Vies urbanes":
[METADADES]
OrdreDintreMultiSerieParcial1=,0-3,4-518,,,519-572

REL de la capa-hoja de la serie "Vies urbanes":
[METADADES]
OrdreDintreMultiSerieParcial1=0-0,1-12,13-245,,246-326,

Así, según el ejemplo, a la hora de dibujar los elementos, se dibujarán en primer lugar el objeto con Identificador gráfico 0 de la capa-hoja de "Vies urbanes". En segundo lugar no se dibujaría ningún objeto de la capa-hoja de "Vies convencionals" (nótese que no hay ningún identificador gráfico antes de la primera coma). En tercer lugar se dibujaría el objeto con Identificador gráfico 0 de la capa-hoja de "Autopistes i vies preferents". Estos objetos formarían el primer nivel (o iteración de dibujado) de la multisèrie parcial "Vías de comunicación".

Después de dibujar los objetos de todas las capas por el primer nivel, se pasaría al segundo nivel de dibujado donde se dibujan los objetos del 1 al 7 de la capa-hoja de "Vies urbanes", del 0 al 3 de la capa-hoja de "Vies convencionals" y del 1 al 12 de la capa-hoja de serie "Autopistes i vies preferents". La secuencia "," indica que no hay objetos en ese nivel (iteración de dibujado) en esa capa. Al sexto nivel de dibujado de la multiserie parcial sólo se dibujan los objetos 519-572 de la capa-hoja de "Vies convencionals".

2.3 Definición de la hoja de serie

Cada una de las Hojas de Serie que forman la Multiserie se define a partir de un REL que contiene sus metadatos. Hay un archivo DBF que contiene la lista las Hojas de Serie que forman la multiserie. La tabla puede tener cualquier nombre pero se recomienda que sea el mismo que el de la tabla principal de la Multiserie con el sufijo "_FullTall". Esta tabla contiene el nombre de todas las hojas de series e indica cuál es el REL que describe los metadatos de cada uno de ellos. La estructura de la DBF debe tener como mínimo unos campos de nombre predefinidos.

Tabla *_FullTall.dbf

Esta tabla contiene los valores posibles de combinaciones del campo 'Full' y el campo 'Corte' de la tabla de la multiserie. Cada combinación corresponde a una 'Hoja de Serie'. Esta tabla se relaciona con la de la multiserie a partir del campo combinado Full-Tall, que aparece en las dos tablas. Los campos de la tabla son:

ID_FULL: A qué hoja corresponde esta Hoja de series
ID_TALL: A qué corte se corresponde la hoja definida en el campo anterior
FITXER: Dirección del fichero REL que define los metadatos de la hoja de la serie, relativa al fichero REL y DBF de la multiserie.

Así, por ejemplo, algunos registros de estat tabla podrían ser:

bt5mv20_FullTall.dbf

ID_FULL	ID_TALL	FITXER
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

Se pueden diferenciar dos grupos de metadatos asociados a una Hoja-Corte.

a) Metadatos genéricos del corte

a.1) Tabla de cortes cartográficos

Existe una tabla DBF que indica los diversos cortes Cartográficos disponibles y, para cada uno de ellos, cuál es el archivo gráfico de polígonos que contiene el corte topográfico. Típicamente este archivo de polígonos genera una división espacial en trapezoides, como por ejemplo los cortes del IGN. Pero se podría, sin ningún problema para el modelo, utilizar cualquier otra división, por ejemplo la división comarcal.

Tall.dbf

ID_TALL	FICHERO
MTN/IGN-5m	Tall_5m_IGN.pol
MTN/IGN-25m	Tall_25m_IGN.pol
MTN/IGN-50m	Tall_50m_IGN.pol

Típicamente, todas las series de la multiserie estarán apoyadas por el mismo corte y, por este motivo, la tabla Tall.dbf tendrá un solo registro. De hecho, tiene sentido tener una tabla general que defina todos los cortes existentes y que vincule a los diferentes ficheros de polígonos. Esto haría que las diferentes multiseries pudieran usar ese mismo 'tesauro' para conocer qué fichero de polígonos deben ir a buscar (según el corte que cada multiserie utilice). Por este motivo, esta tabla debe estar (típicamente) situada en un carpeta más externa 'a la de la multiserie (SI\Thesaurus, por ejemplo) y que tenga tantos registros como cortes utilizados por las diferentes multiseries (ex: MTN/IGN-5m, MTN/IGN-25m, MTN/IGN-50m, etc.).

Por tanto, como se ha optado por usar una tabla que defina los cortes externa a la multiserie, el REL de la multiserie debe definir una relación con esta tabla. Esta relación no es directa. El REL de la multiserie contiene las relaciones en las tablas TemaData y FullTall, y desde esta segunda se vincula a la tabla Tall.dbf. Los vínculos entre la tabla de la multiserie y las dos primeras tablas deberían ser a partir de un campo combinado. De momento se dejan indicadas en el REL a partir de un enlace simple. El vínculo hacia la tabla Tall.dbf sí es con un solo campo de enlace.

El contenido del campo ID_FULL de la tabla *_FullTall.dbf indica cuál es el identificador de ENTIDAD de la hoja dentro del archivo de polígonos indicado en el campo 'FICHERO' de la tabla Tall.dbf (el fichero de polígonos Tall_50m_IGN.pol en la tabla de ejemplo).

La aproximación utilizada típicamente en las series realizadas con anterioridad, era que existía para cada serie temática un corte cartográfico diferente (y repetido), que vinculaba con los mapas de cada Hoja para una Multiserie concreta. Así existía un corte que abría todas las hojas del topográfico y otro corte que abría todas las hojas del MCSC. La implementación actual permite evitar duplicar esta información gráfica y describir los metadatos de cada hoja de forma única.

a.2) Tabla principal del fichero de polígonos que define el Corte

La capa Tall_50m_IGN.pol define la geometría del corte. Generalmente los polígonos son trapezoidales pero también pueden ser polígonos de distribuciones administrativas, por ejemplo. En este caso, el archivo debe ser de grupos para que cada entidad tenga un solo registro. En ambos casos también debe tener un campo definido como ID_ENTITAT.

Los metadatos referidos a cada hoja del corte se encuentran directamente en la tabla DBF del archivo de polígonos. Es necesario que estos campos tengan un nombre de campo particular para conocer cual se corresponde a cada concepto de metadatos.

Los metadatos que se pueden extraer de la tabla del fichero de polígonos que describe el Corte Cartográfico son:

Envolvente: se extrae de la cabecera del archivo de polígonos para cada polígono. Si hay más de un registro para el mismo identificador de entidad (porque no están ciclados como grupos o porque hay multiregistro) entonces el envolvente se calcula como el envolvente "externo" en los diferentes polígonos.

Códigos de hoja: debe existir un campo definido como identificador de entidad que se usa en las otras mesas como contenido del campo 'ID_FULL'.

Denominación de la hoja: El nombre del campo es NOM_FULL. En versiones antiguas de este documento habíamos pensado en fijar el nombre de este campo topónimo, pero al final se ha puesto este porque en las bases de referencia disponibles en \\eclipta\SI (servidor interno de información geográfica) se llama así para la mayoría de archivos de cortes cartográficos.

Si esta DBF tiene otros campos con nombres diferentes, esta información será consultable desde el corte cartográfico pero no se podrá 'estirar' nunca desde los metadatos de la hoja para que se desconoce qué 'sentido' tiene (al menos de momento).

Los metadatos del Corte cartográfico, que se encuentran en la tabla principal de la base de datos de polígonos que define el Corte, corresponde al nivel jerárquico de capa. Por lo tanto en el REL del archivo de polígonos que define el Corte cartográfico (Tall_50m_IGNP.rel) encontraremos:

[METADADES]
; es un rel de CAPA (valor por defecto)
; hierarchyLevel=005

Por tanto, en el modelo utilizado se utilizarán dos tipos de capas diferentes: capas que representan el corte cartográfico y las capas-hoja en sí. Utilizamos el miembro hierarchyLevelName para identificar con un nombre prefijado este primer tipo especial de capa. Por tanto, en el REL del archivo de polígonos que define el Corte cartográfico (Tall_50k_IGNP.rel) encontraremos:

[METADADES]
; es un rel de CAPA (valor por defecto)
; hierarchyLevel=005
; de tipo 'Tall'
hierarchyLevelName=##Tall##

En los metadatos también hay que definir las relaciones de este conjunto de metadatos con otros conjuntos de metadatos. Pero como se ha comentado antes, el corte no hereda nunca metadatos, es genérico y usado por diferentes multiseries y por tanto no se vincula directamente con ninguna multiserie (no tiene ningún miembro parentIdentifier1 en su REL).

a.3) Esquema de los archivos que definen el Corte cartográfico

b)Metadatos para una Hoja-Corte

Los metadatos referidos a todas las capas-hoja de la misma Hoja-Corte en una multiserie. Así, dos versiones del MCSC tienen el mismo corte (y los metadatos de topónimo se extraen del mismo 'fichero') y, en cambio, pueden tener diferentes metadatos al referirnos a ellos como unidad Hoja-Corte dentro de una multiserie (este no es el caso del ejemplo mostrado en la tabla).

Esto nos hace llegar a algunos metadatos de cada hoja, que son los definidos en los ficheros REL de cada hoja y corte concreto para cada multiserie. Se podrían soportar diferentes cortes y por este motivo se describen aquí.

La Hoja-Corte sí que hereda algunos metadatos de la multiserie.

Los metadatos de la Hoja de Series (Hoja-Corte) se corresponden también al nivel jerárquico de serie, por lo tanto en el REL de la serie encontraremos:

[METADATOS]
; es un rel de SERIE
hierarchyLevel=006

Para las Hojas de series en el REL se guardará hierarchyLevelName igual a "Full":

[METADADES]
; es un rel de SERIE
hierarchyLevel=006
; de tipo 'Full'
hierarchyLevelName=##Full##

En los metadatos tambien hace falta definir las relaciones de este conjunto de metadatos con otros conjuntos de metadatos. Como se ha comentado anteriormente, se usará el parentIdentifier1 para referirnos a la multiserie desde los metadatos de las capas-hoja, las series y las hojas de serie. En este caso:

[METADADES]
; es un rel de SERIE
hierarchyLevel=006
; de tipo 'Full'
hierarchyLevelName=##Full##
; y por tanto, su parentIdentifierFile1...
parentIdentifierFile1=..\ bt5mv20.rel
; ...es la Multiserie

Tambien establecemos que el FileIdentifier de la Hoja de Series sea fijo, a aquel que se obtiene de la combinación del contenido de los campos ID_FULL y ID_TALL correspondientes (de la tabla de definición de serie: *_FullTall.dbf) separados per un "_". Así, por ejemplo, el REL de la Hoja de Series:

bt5mv20_FullTall.dbf

ID_FULL	ID_TALL	FITXER
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

Tendra el FileIdentifier igual a 241-156_MTN/IGN-5m, es decir, que la sección de metadatos completa es:

[METADADES]
FileIdentifier=241-156_MTN/IGN-5m
; es un rel de SERIE
hierarchyLevel=006
; de tipo 'Full'
hierarchyLevelName=##Full##
; y por tanto, su parentIdentifierFile1...
parentIdentifierFile1=..\ bt5mv20.rel
; ...es la Multiserie

Nota: el tamaño máximo del FileIdentifier es 253, y como el de la serie se construye a partir del contenido de los campos ID_TEMA y ID_DATA más el carácter "_", ES NECESARIO que el tamaño máximo de estos dos campos sumados sea como máximo 252.

Relación de la Hoja de Series con el Corte cartográfico correspondiente

Las Hojas de Serie hacen referencia directa al fichero de polígonos del Corte, y no sólo a la multiserie para que las aplicaciones no tengan que leer las DBF relacionadas con la multiserie cada vez.

Por otra parte, es necesario indicar a qué fichero de polígonos y polígono concreto dentro de este archivo (a partir del identificador de entidad) se corresponden los metadatos de esta Hoja-Corte. Esta información se puede extraer de la tabla de cortes, pero desde el REL de serie debería ir a buscar el REL de la multiserie y luego explorar las relaciones de éste hasta llegar a la tabla de Cortes. Es más útil que el Rel de la Hoja de Series vincule directamente contra el archivo de polígonos que define el corte, y que indique también el identificador de entidad que indica a qué polígono concreto de aquel archivo de polígonos se refiere aquella Hoja de Series.

Esta relación se hace a partir de la sección sobre información de agregación. Así, por tanto, los metadatos de la Hoja de Series usan la sección aggregationInfo para referirse al archivo de polígonos del Corte correspondiente. Los elementos que tiene esta sección son:

aggregateDataSetName (opcional, tipo CI_Citation): De momento no se utiliza. En el futuro se pondrá una caja independiente (CI_Citation) que lo tenga todo y se rehará la pestaña "Identificació" del GeM+ para que también tenga esta estética (todas las cosas juntas).
aggregateDataSetIdentifier (opcional, tipo MD_Identifier): Igual que con el parentFileIdentifier, se utiliza la clave propia aggre...File, y a partir el fichero REL ya se buscará el identifier.
associationType (DS_AssociationTypeCode): Es el único elemento obligatorio. En teoría este elemento debe formar parte de una lista de códigos predefinidos y puede tomar cualquiera de estos valores.
initiative (opcional, DS_InitiativeTypeCode): No es obligatorio y también es una lista de valores que se ofreceran a los usuarios.

Así, el usuario podrá definir que la capa forma parte de tantos agregados como se desee (como dice el estándar). En caso de que se quiera relacionar la Hoja de Series con el fichero REL de la capa de polígonos que define el Corte cartográfico será posible uno de estos agregados para describir el Corte Cartográfico.

Esto se consigue a partir de dos filtros. En primer lugar el agregado que describe el Corte Cartográfico debe tener un valor determinado al elemento associationType: debe ser LargerWorkCitation. En segundo lugar, si el valor es el predeterminado entonces activará un check: "Es REL de Corte". Así, para una misma capa se puede definir más de una capa agregada con asociación de tipo LargerWorkCitation pero sólo una de ellas podrá tener activado check en cuestión.

A parte de las claves de la sección [METADADES] comentadas antes, que describen el nivel jerárquico y el tipo de serie d la Hoja de Series, este fichero REL utilizará, para indicar el Corte Cartográfico relacionado:

[IDENTIFICATION:AGGREGATION_INFO1]
aggregateDatasetIdentifierFile=..\TallCarto\bt5mv20mm0Tall5m_01.pol
; de tipus partOfSeamlessDatabase
associationType=003
; de los diferentes agregados con tipo 'partOfSeamlessDatabase'
; este es el que define el fichero de polígonos con el Corte
EsRelDeTall=1

[IDENTIFICATION:AGGREGATION_INFO2]
aggregateDatasetIdentifierFile=...
; de tipo partOfSeamlessDatabase
associationType=003
; de los diferentes agregados con tipo 'partOfSeamlessDatabase'
; este NO define el fichero de polígonos con el Corte
; EsRelDeTall=0 -> valor por defecto

En ninguno de los ejemplos anteriores se ha definido la initiative porque puede tomar cualquier valor y, por tanto, el usuario ya decidirá lo que considere conveniente.

Esta información, sin embargo, es suficiente para conocer cuál es el fichero de polígonos que define el corte cartográfico, pero no se conoce cuál de los polígonos del archivo se corresponde con la Hoja que se está describiendo (en el ejemplo la Hoja de Series 241-156_MTN/IGN-5m). Conocer cuál de los polígonos del archivo se corresponde con la Hoja de Series es necesario para poder obtener información de la tabla de atributos del archivo de polígonos (p.ej. el topónimo de la hoja) sin tener que leer las tablas de la multiserie (tal y como se ha hecho con todas las informaciones del modelo).

Para conocer esta información se ha definido una nueva clave en esta sección que se llama aggregateDataSetIdEntitat y que indica el Identificador de entidad que identifica cuál de los polígonos del archivo se corresponde con esta Hoja de Series. Esta clave sólo se leerá y escribirá si la "información de agregación" es la que define el Corte cartográfico (es decir si EsRelDeTall=1). Desde el GeM+ se verá este identificador de entidad pero no se podrá modificar desde la pestaña que muestre la "información de agregación". Por tanto, es necesario completar la sección [IDENTIFICATION : AGGREGATION_INFO1] del ejemplo anterior:

[IDENTIFICATION:AGGREGATION_INFO1]
aggregateDatasetIdentifierFile=..\TallCarto\bt5mv20mm0Tall5m_01.pol
; de tipo partOfSeamlessDatabase
associationType=003
; de los diferentes agregados con tipo 'partOfSeamlessDatabase'
; este es el que define el fichero de polígonos con el Corte
EsRelDeTall=1
aggregateDataSetIdEntitat=241-156

Esquema de los ficheros que definen la Hoja de Series

2.4 Definición de la Capa-Hoja

Cada capa puede formar parte de una multiserie o no. La vinculación con el modelo es desde la tabla general de definición de la multiserie, a partir del campo FITXER (donde indica el nombre y path de cada una de las capas gráficas) y desde los metadatos de cada capa, donde se indica de qué multisèrie forma parte (elemento parentIdentifierFile1).

Los metadatosde la capa se corresponden también al nivel jerárquico de capa, por lo tanto en el REL de la capa encontraremos:

[METADADES]
; es un rel de CAPA (valor por defecto)
; hierarchyLevel=005

Para una capa-hoja (o para una capa no relacionada con ninguna serie) cartográfica en el REL se guardará hierarchyLevelName igual a "CapaFull", que es el valor por defecto:

[METADADES]
; es un rel de CAPA (valor por defecto)
; hierarchyLevel=005
; de tipos 'CapaFull' (valor por defecto)
; hierarchyLevelName=##CapaFull##

En los metadatos también hay que definir las relaciones de este conjunto de metadatos con otros conjuntos de metadatos. Como se ha comentado antes, usaremos el parentIdentifier para referirnos a la multiserie desde los metadatos de las capas-hoja, las series y las hojas de serie. En este caso: [METADADES]
; es un rel de CAPA (valor por defecto)
; hierarchyLevel=005
; de tipo 'CapaFull' (valor por defecto)
; hierarchyLevelName=##CapaFull##
; y su parentIdentifierFile1...
parentIdentifierFile1=..\bt5mv20.rel
; ...es la Multiserie

De la misma forma que la Hoja de series tiene una manera de indicar directamente el fichero del corte cartográfico, se establece que las capas-hoja hacen referencia a todos sus padres, y no sólo a la multiserie (idénticos motivos que en el caso anterior).

Esto se hace a través del elemento aggregationInfo de los metadatos. Los elementos que tiene son:

aggregateDataSetName (opcional, tipo CI_Citation): De momento no se utiliza. El día que se use se pondrá a una caja independiente (CI_Citation) que lo tenga todo, y se rehará la pestaña "Identificación" del GeM+ para que tenga también esta estética (todas las cosas juntas).
aggregateDataSetIdentifier (opcional, tipo MD_Identifier): igual que con el parentFileIdentifier, se utiliza una clave propia aggre...File, y a partir del fichero REL ya se buscará el identifier.
associationType (DS_AssociationTypeCode): es el único elemento obligatorio. En teoría este elemento debe formar parte de una lista de códigos predefinidos, y puede tomar cualquiera de estos valores.
initiative (opcional, DS_InitiativeTypeCode): no es obligatorio y también es una lista de valores que se ofreceran a los usuarios.

Así, el usuario podrá definir que la capa forma parte de tantos agregados como quiera (como dice el estándar). En caso de que la capa en cuestión forme parte de una multiserie será posible escoger dos de estos agregados para describir la Serie y la Hoja de Series.

Esto se hace a partir de dos filtros. En primer lugar el agregado que describe la Serie y la Hoja de Serie debe tener un valor determinado en el elemento associationType .

Serie: associationType debe ser partOfSeamlessDatabase

Hoja de series: associationType debe ser LargerWorkCitation

En segundo lugar, si el valor es uno de los dos predefinidos (y la capa forma parte de una multiserie) entonces se activarán unos checks del estilo: "Es la Hoja de Series de la cual la capa forma parte" o "Es la Serie de la cual la capa forma parte". Así, para una misma capa se puede definir más de una capa agregada con asociación de tipo partOfSeamlessDatabase pero sólo una de ellas podrá tener activado el check en cuestión.

Así, para una capa que forma parte de una multiserie usará, además de la sección [METADATOS] tal y como se muestra en la página anterior:

[IDENTIFICATION:AGGREGATION_INFO1]
aggregateDatasetIdentifierFile=bt5mv20mm0f241x156r02_01ca.rel
; de tipo LargerWorkCitation
associacionType=002
; de lo diferentes agregados con tipo 'LargerWorkCitation'
; este es el que define la Hoja de Series
EsRelDeSerie=1

[IDENTIFICATION:AGGREGATION_INFO2]
aggregateDatasetIdentifierFile=..\PalSimb\bt5mv20mm0AltimetriaCotes_01ca.rel
; de tipo partOfSeamlessDatabase
associacionType=003
; de los diferentes agregados con tipo 'partOfSeamlessDatabase'
; este es el que define la Serie
EsRelDeSerie=1

[IDENTIFICATION:AGGREGATION_INFO3]
aggregateDatasetIdentifierFile=...
; de tipo LargerWorkCitation
associacionType=002
; de los diferentes agregados con tipoi 'LargerWorkCitation'
; este NO define la Hoja de Series
; EsRelDeSerie=0 (valor por defecto)

[IDENTIFICATION:AGGREGATION_INFO4]
aggregateDatasetIdentifierFile=...
; de tipo partOfSeamlessDatabase
associacionType=003
; de los diferentes agregados con tipo 'partOfSeamlessDatabase'
; este NO define la Serie
; EsRelDeSerie=0 (valor por defecto)

; y otros agregados diferentes
[IDE14:51 28/10/2013NTIFICATION:AGGREGATION_INFO5]
aggregateDatasetIdentifierFile=...
; cualquiera de los tipos no 'predefinits'
; de tipo crossReference
associacionType=001

En ninguno de los ejemplos anteriores se ha definido la initiative porque puede tomar cualquier valor y, por tanto, el usuario ya decidirá lo que considere conveniente.

El Gestor Universal de Metadatos Geoespaciales, al entrar en la pestaña "Metadatos | Series" para una Capa-Hoja que forma parte de la Multiserie comprobará que estas informaciones definidas en el REL de la Capa-Hoja sean coherentes con lo que informan las tablas DBF que describen la Multiserie.

Esquema de los archivos que definen las Capas-Full

Las series cartográficas en MiraMon/a>