Descripción de los formatos vectoriales de MiraMon

En MiraMon, se trata como vectorial cualquier representación del espacio cartográfico que se hace por representación simbólica mediante puntos, líneas o polígonos. MiraMon soporta tanto archivos vectoriales estructurados como no estructurados. Los archivos vectoriales estructurados pueden tener relaciones topológicas explícitas.

Los ficheros vectoriales no estructurados son archivos de texto (ASCII) que "simplemente" contienen entidades geográficas, pero sin una estructura interna que permita un rápido acceso y consulta, o relaciones topológicas explícitas entre objetos. Contienen un solo atributo y no están vinculados a una base de datos externa al fichero. Los archivos no estructurados de MiraMon son directamente compatibles con los archivos vectoriales ASCII de Idrisi, v. 4.x, y presentan las ventajas de sencillez de creación y de edición, y la facilidad de exportación/importación.

Por otro lado, los ficheros vectoriales estructurados son ficheros binarios con estructura interna para permitir un rápido acceso y consulta y relaciones topológicas explícitas (es decir, son capaces de saber de la existencia de diversos agujeros dentro de los polígonos, qué polígonos se encuentran alrededor de un determinado polígono, qué líneas estan en contacto con otras líneas, e incluso pueden conectar islas separadas que deben ser consideradas como un conjunto). Están vinculados a bases de datos y, por tanto, permiten realizar análisis complejos de la información con rapidez. Pueden contener relaciones 1 a muchos en cualquier nivel del árbol relacional (por ejemplo, un elemento gráfico como una parcela catastral puede relacionarse con tantos registros (propietarios) como sea necesario). A partir de la versión 4.0 de MiraMon se puede acceder a cualquier base de datos, como por ejemplo, MS-Access, Oracle, SQLServer, DB2, EXCEL, DBF y muchas otras, utilizando la tecnología ODBC Microsoft. Los formatos vectoriales que puede abrir MiraMon de forma directa son sus formatos propios (PNT, ARC/NOD y POL) y SHP, DXF, GPX, KML, DGN y GML; por motivos de acceso rápido, estos formatos están estructurados, pero no están estructurados topológicamente cuando se leen para su visualización, si bien se pueden convertir en verdaderos conjuntos de datos topológicos con las herramientas adecuadas de MiraMon. Adicionalmente, un extenso número de otros formatos vectoriales pueden ser incorporados vía importación como son los formatos E00 vectoriales, ArcSDE, SDO (Oracle), VEC (Idrisi), CDF (NetCDF) y cualquier importación de datos provenientes de un receptor GNSS (GPS). Para más información, consúltese la opción Importar del menú "Archivo". Con anterioridad a la versión 4.0 de MiraMon, el único formato para la base de datos era el DBF.

Podemos resumir las diferencias entre los ficheros vectoriales no estructurados y los estructurados de la siguiente forma:

La descripción que viene a continuación explica los archivos estructurados desde un punto de vista de usuario. Si se desea una explicación más técnica (formato interno, etc) y conceptualmente profunda (tipo de relaciones topológicas, etc), consúltese el documento técnico: Structured vector file format (topological or not) in MiraMon.

Descripción del formato vectorial no estructurado propio de MiraMon:

El formato vectorial no estructurado propio de MiraMon se basa en un archivo de texto (ASCII). Este archivo sólo guarda el atributo temático de cada objeto, el número de coordenadas para representarlo y las coordenadas de cada vértice.

Estas capas vectoriales están constituidas por dos ficheros:

a) El primero contiene la representación gráfica así como un simple atributo para cada entidad geográfica y tiene extensión .vec. Su estructura general es la repetición del siguiente esquema tantas veces como objetos (puntos, líneas o polígonos) contenga el fichero:

Atributo Numero_de_Coordenadas
CoordenadaX CoordenadaY [CoordenadaZ]    
: : :

En el caso de los ficheros que contienen puntos, Numero_de_Coordenades siempre vale 1 y en los que contienen polígonos la última coordenada repite la primera, para cerrarlos.

Dos ceros separados por una espacio en blanco en una nueva línea indica el final del fichero:

0 0

Los archivos VEC tienen un formato muy parecido a los ficheros vectoriales ASCII del software Idrisi a partir de la versión 4.x, pero se diferencian porque:

• Soportan coordenadas de doble precisión (15 a 17 cifras significativas)
• Soportan atributos "long" (valores entre -2147483648 y 2147483647) [referidos como "long" o como "integer" en la clave "id type" del DVC], atributos "integer" (valores entre -32768 y 32767) [referidos como a"Integer" en la clave "id type" del DVC], y "real" (valores ± 3.4E ± 38, con 6-9 cifras significativas) [referidos como "real" en la clave "id type" del DVC]. La razón para soportar atributos "long" radica en la posibilidad de tratarlos como identificadores y no como simples atributos, convirtiéndolos en verdaderos índices a una base de datos (por compatibilidad en las operaciones de importación/exportación). Así el formato no está limitado a tener 32767 objetos en cada capa, sino que se puede tener hasta 2100 millones de objetos; el primer límite puede ser alcanzado fácilmente en imágenes clasificadas provenientes de teledetección cuando son vectorializadas.
• Pueden contener atributos de tipo "cadena de caracteres", los cuales son documentados como de tipo "string" en la clave "id type" del archivo DVC.
• Son siempre archivos de texto (no binarios).

b) El segundo archivo contiene los metadatos: tipo de objeto (punto, línea o polígono), ámbito geográfico, unidades, etc, y tiene extensión .dvc. Su formato es compatible con los del software Idrisi, v. 4.x.; sin embargo, Miramon presenta algunas ampliaciones y restricciones. Su estructura general se muestra a continuación:

file title: Título 
id type: integer (o float o string)
file type: ascii
object type: point (o también line o polygon)
ref. system: UTM-31N-ETRS89 (o también  plane o cualquier otro sistema de referencia)
ref. units: m (o también píxeles)
unit dist.: 1.000000
min. X:  414791.000000
max. X:  428809.800000
min. Y: 4585571.000000
max. Y: 4594974.200000

Descripción de los formatos vectoriales estructurados (topológicos o no) propios de MiraMon:

Los formatos vectoriales estructurados se basan en archivos almacenados en un formato binario propio desarrollado por Xavier Pons y Joan Masó. Esencialmente hay tres grandes familias o tipos de capas vectoriales estructuradas: los puntos, los arcos y los nodos, y los polígonos.

• PUNTOS: Contienen entidades de tipo punto, es decir, descritas por una sola coordenada (x,y) o (x, y, z).
• ARCOS Y NODOS: Contienen entidades de tipo arco, es decir, líneas descritas por una serie de segmentos cada uno de ellos definidos por coordenadas (x, y) o (x, y, z) y, cuando estan estructurados topológicamente, nunca son intersectados ni en contacto con otros arcos de la misma base de datos gráfica, o bien sólo estan en contacto en sus extremos (denominados nodos). Cada coordenada se denomina vértice, i la línea, siempre recta, que los une se llama segmento. Como se ha comentado previamente, los dos vértices extremos de cada arco se llaman nodos. Cada arco debe contener un mínimo de 2 vértices (y, en este caso, deben ser diferentes y formar un solo segmento). En otras terminologías, un arco se llama también "cadena" (chain, string) o "polilínea" (polyline), si bien estos términos también se usan en sentidos más amplios e incluso diferentes.

  Aunque no es el caso típico, en MiraMon también es posible usar ficheros estructurados para almacenar entidades que no han sido estructuradas topológicamente, por ejemplo, ficheros de líneas que continen entidades en las cuales es posible tener intersecciones no explicitadas, ficheros de puntos en los cuales la unicidad espacial no ha sido comprovada, etc. En este caso, la cabecera del fichero es consciente de eso y el usuario puede conocerlo a través de "Presentación | Aspectos técnicos" en la pestaña del Gestor Universal de Metadatos Geoespaciales (GeM+), o cargando la capa en MiraMon y ejecutando "Información | Vectores abiertos"; en ambos casos se muestra un texto explícito, como "topología garantizada" o "topología NO garantizada".

• 
  A veces nos interesa diferenciar los nodos desde el punto de vista de en qué arcos y en qué número, convergen, ya que esto tiene implicaciones en las relaciones topológicas en el plano. Así pues,se pueden diferenciar cuatro tipos de nodos dependiendo de su función.

• -Nodo típico: es un nodo que conecta tres o más arcos de cualquier tipo, o bien dos o más arcos (en este caso al menos un arco debe conectar al nodo por sus dos extremos).

  -Nodo de línea: es un nodo que conecta dos y sólo dos arcos, y cada arco solo se conecta una sola vez al nodo. Sirve para separar dos arcos que tienen atributos diferentes y se quieren mantener separados a la base de datos alfanumérica (en otros software o formatos, los nodos de línea pueden aparecer porque el número máximo de vértices por arco es pequeño (por ejemplo, 500) y se ha alcanzado dicho límite).

  -Nodo de anillo: es un nodo que conecta un solo arco. Este arco está cerrado sobre sí mismo uniendo sus dos extremos.

  -Nodo final: es un nodo que conecta un solo arco por un solo extremo.

  Nodo típico	Nodo de línea	Nodo de anillo	Nodo final

  Con MiraMon, cuando hablamos simplemente de "nodos" nos referiremos a cualquier tipo de nodo, sea "típico", "de línea", "de anillo" o "final". En la base de datos hay un campo llamado TIPUS_NODE que codifica estos cuatro tipos de nodos, respectivamente, utilizando los números 0, 1, 2 y 3; se puede definir un pequeño tesauro si se desea leer "nodo típico", "nodo de línea", etc. en lugar de 0, 1, etc. Sin embargo, sus nombres se generan automáticamente en la leyenda, e incluso los códigos pueden aparecer al activar "valores" en el cuadro de diálogo "Visualización de la capa en la leyenda":

  

  En el caso de MiraMon, una capa de arcos siempre lleva asociada una capa de nodos.

• POLÍGONOS:
• Contienen entidades de tipo polígono, es decir recintos cerrados descritos por uno o más arcos. A veces un polígono contiene agujeros en su interior, en este caso, hablaremos de polipolígono y llamaremos a cada uno de los polígonos que lo forman (el exterior y cada uno de los que delimitan los agujeros interiores) polígon elemental (o "anillo "o" contorno "). Cuando hablamos simplemente de "polígonos" nos referimos a cualquier tipo de polígono, sea formado por varios polígonos elementales o por uno solo.

  Polipolígon

  Un polígono topológico no se define directamente a partir de sus vértices, sino a partir de las secuencias de arcos que lo forman. El proceso básico para construir la topología de polígonos empieza por la construcción de la topología arco-nodo y el ciclado de todos los arcos hasta no dejar ninguna región abierta.

  MiraMon permite la creación (reciclado) de más de una base de polígonos sobre una misma base de arcos. Un ejemplo típico es una base arcos que define los límites municipales. Como habitualmente los municipios forman parte de agrupaciones de rango superior (comarcas, provincias, países, estados, comunidades de estados, etc.), es posible reciclar, sobre la misma base de arcos, los polígonos que forman los municipios, las comarcas, las provincias, los países, etc. Esto permite un ahorro importante de almacenamiento y una mayor consistencia de los datos: si un límite municipal cambia o se redibuja de forma más precisa, automáticamente quedan cambiados los eventuales límites comarcales, nacionales, etc. de la que también forma parte el límite modificado. Esta característica de MiraMon implica que el archivo de metadatos debe indicar sobre qué base de arcos está ciclado el fichero de polígonos. Así pues, las diferentes capas de polígonos creadas a partir del mismo conjunto de datos de arcos no utilizan los mismos arcos (o al menos no todos).

Una capa que contenga objetos de alguna de estas familias está formada por un cierto número de archivos, algunos de los cuales son específicos para alguna de estas familias. No obstante, hay tres archivos que son comunes para todas las familias, los cuales se describen a continuación:

• Archivo de elementos gráficos: Contiene la base de datos gráfica con las coordenadas que definen las entidades vectoriales, así como sus relaciones topológicas (espaciales), cuando corresponde. Es siempre un archivo binario. La extensión del archivo gráfico depende de la familia que se trate, tal y como se muestra a continuación:

  Familia	Extensión
  Puntos	*.pnt
  Arcos	*.arc
  Nodos	*.nod
  Polígonos	*.pol

• Tabla principal: Contiene la tabla principal de la base de datos en formato dBASE (DBF) o en DBF extendida si es necesario. Puede contener cualquier tipo de campo, pero MiraMon sólo mostrará los siguientes: Numérico (N, admite números enteros y números reales de prácticamente cualquier extensión y precisión), Carácter (C), Lógico (L) y Fecha (D). Los campos de tipo Memo, OLE, etc., son ignorados. La extensión del fichero tabla principal depende de la familia de que se trate, tal y como se muestra a continuación:
  

  Familia	Extensión
  Puntos	*T.dbf
  Arcos	*A.dbf
  Nodos	*N.dbf
  Polígonos	*P.dbf

  Esta tabla identifica los objetos que contiene un código numérico único. Este código es un valor entero numerado desde 0 (cero) que llamamos identificador gráfico. Por definición, la base de datos gráfica no contiene nunca dos elementos con el mismo identificador gráfico ni contiene discontinuidades en la numeración de los elementos: se ordena formando una serie monótona creciente estricta. En otras terminologías, el identificador gráfico se denomina también "identificador interno". El identificador gráfico puede estar en cualquiera de los campos de la tabla principal alfanumérica (aunque típicamente es el primero) y puede tener cualquier nombre (aunque típicamente se denomina ID_GRAFIC), pero debe tener dos características indispensables: ser de tipo numérico (N) y estar ordenado de forma ascendente (si es necesario se puede ordenar desde MiraDades). Cualquier base de datos externa puede enlazarse con la tabla principal a través de un campo que actúe de vínculo. Esta operación de enlace (join dinámico) se puede establecer en la pestaña "Información temática" del Gestor Universal de Metadatos Geoespaciales (GeM+) con el botón derecho del ratón. Al mismo tiempo, cualquier tabla vinculada se puede volver a enlazar a través de alguno de sus campos utilizando el mismo procedimiento. Además, un campo se puede enlazar a más de una base de datos, y es posible establecer enlaces desde tantos campos de una tabla como sea necesario. Finalmente, es también posible definir, para cada enlace, la cardinalidad de la relación (uno a uno, muchos a uno, muchos a uno asumiendo que la relación siempre será posible [a un diccionario], etc).

  Este campo ID_GRAFIC contendrá sólo números enteros, si bien se admite:

  -Que haya negativos (y, por tanto, no vinculados a ningún objeto gráfico).
  -Que haya con valor superior o igual al número de objetos gráficos (y, por tanto, no vinculados a ningún objeto gráfico).
  -Que haya más de uno para un mismo identificador gráfico y, por tanto, multiregistro. Dicho de otro modo, es posible establecer una cardinalidad de uno a muchos de la base de datos gráfica a la base alfanumérica. Por ejemplo, en el caso de una ficha de análisis periódicos de aguas en cada fuente de un parque natural: cada fuente tendrá tantas fichas asociadas como análisis se hayan realizado, es decir, para una misma fuente (identificador gráfico único) habrá varios datos analíticos en función de la fecha de análisis en dicha fuente (cabe tener en cuenta que este esquema no es posible en en típicos ficheros Shape ni en la mayoría de otros formatos).
  -Que haya "huecos" en la serie (elementos gráficos que no tienen registro asociado a la base de datos alfanumérica). Esta situación, que no es ideal pero es tolerada, permite en el ejemplo anteriormente explicado, que haya fuentes en las que no se realice el análisis de aguas para todas las fechas.

  Si la tabla principal contiene entidades que nunca serán vinculadas a ningún objeto gráfico puede ser útil asignar simplemente un identificador negativo (que incluso puede ser siempre el mismo, como por ejemplo -1). Recuérdese, sin embargo, que después de añadir los nuevos registros hay que reordenar (con MiraDades, con orderby, etc, según los software) la tabla principal tomando como criterio el campo que contiene el identificador gráfico (o añadiendo estos registros en el correcto orden). La tabla principal también contiene otros campos, llamados geométrico-topológicos, que contienen atributos geométricos o topológicos de los objetos gráficos. Por ejemplo, en la tabla principal de una capa de polígonos encontraremos típicamente el área y el perímetro de cada polígono, el número de polígonos elementales que lo componen, etc., mientras que en la de una capa de arcos encontraremos la longitud, el identificador del nodo inicial y final, etc. Todos estos campos son mantenidos por MiraMon y el usuario no debería nunca editar su contenido ni tipología.

  Las tablas de la base de datos pueden estar en formato DBF (incluyendo el formato DBF extendido, una extensión prácticamente ilimitada del formato clásico) y/o en cualquier formato accesible vía el estándar ODBC (MS-Access, Oracle, SQL Server, MS-Excel, etc). Sin embargo, la tabla principal debe estar en formato DBF (clásico o extendido) . Si se desea mantener todos los atributos temáticos en una o más tablas en otros formatos, simplemente se debe definir en la tabla principal y en la primera de las tablas de enlace en otros formatos un campo que actúe de identificador de entidad (ID_ENTITAT). Se puede establecer una relación 1 a 1 o 1 a muchos entre las dos tablas, según convenga. De esta manera, la tabla principal puede acabar conteniendo sólo el campo ID_GRAFIC, los campos geométrico-topológicos y el campo ID_ENTITAT (este último campo se llama, en otros software, identificador de usuario).

• Archivo de metadatos, relaciones y simbolización: contiene datos adicionales sobre los datos, las relaciones de la base de datos y la descripción de la visualización (simbolización). La extensión también depende de la familia (tipo de geometría), tal y como se muestra acontinuación:

  Familia	Extensión
  Puntos	*T.rel
  Arcos	*A.rel
  Nodos	*N.rel
  Polígonos	*P.rel

  El archivo de metadatos es un archivo en formato INI de Windows, formado por secciones i claves. Este archivo es editable con cualquier procesador de textos (NOTEPAD, etc), pero debido a su complejidad, es aconsejable documentar a través de la aplicación del Gestor Universal de Metadatos Geoespaciales (GeM+). En el interior de cada sección, hay una serie de claves seguidas de un signo igual y de un valor o cadena de caracteres. Estas palabras clave permiten definir la información que deben contener los metadatos. El orden de las secciones a lo largo del fichero y el orden de las claves dentro cada sección no es relevante para la correcta interpretación del mismo y no es necesario que estén todas presentes. El formato REL, caracterizado por la presencia de la sección [VERSION] con las claves "Vers=" y "Subvers=" es el que permite un esquema de relaciones entre tablas extraordinariamente flexible, de forma que cada campo puede vincularse a un número ilimitado de tablas y, a la vez, cada nueva tabla asociada puede, a su vez, asociarse a un número ilimitado de otras tablas a través de sus campos. Este esquema admite un número ilimitado de niveles y el acceso a bases de datos diferentes de forma simultánea, las cuales pueden ser en formato DBF o en cualquier formato que soporte el acceso a través del estándar ODBC (MS-Access, Oracle, SQL Servidor, etc.).

  En la versión actual de MiraMon, las principales secciones soportadas en los ficheros de metadatos de los vectores estructurados topológicamente (.rel) son:

  • [VERSIO] -> Sección que describe la versión y subversión del fichero REL.
  • [METADADES] -> Sección que describe las características generales de los metadatos, por ejemplo el idioma o idiomas en los que estan los metadatos, la fecha de creación, el juego de caracteres o el identificador único del fichero.
  • [METADADES:ORGANISME_#] -> Sección que describe el organismo editor de los metadatos. El símbolo # es el número del organismo que ha participado.
  • [TAULA PRINCIPAL] -> Sección que describe qué campo del fichero tabla principal (DBF) contiene el identificador gráfico y, por tanto, actúa de vínculo entre la base de datos alfanumérica principal y la gráfica. Esta información es obligatoria y se expresa así:
    IdGrafic=NOM_CAMP (donde "NOM_CAMP" es el nombre del campo de la tabla principal que contiene el identificador gráfico).
  • [TAULA_PRINCIPAL:NOM_CAMP] -> Secciones que describen la información de cada campo existente en la tabla principal (hay tantas secciones de éstas como campos). Permiten decidir si el campo es visible, simbolizable, las unidades a mostrar, etc.
  • [IDENTIFICATION] -> Sección que describe el título de la capa, etc.
  • [[OVERVIEW] -> Sección que describe, entre otros, la fecha de creación de la base, la fecha de actualización, un resumen así como también datos del coordinador, promotor, editor y distribuidor de la base.
  • [OVERVIEW:ASPECTES_TECNICS] -> Sección que describe, entre otros, el tipo de archivo, el modelo de datos, el tipo de objeto (puntos, arcos, nodos, polígonos), el número de objetos, la base alfanumérica, así como también comentarios diversos.
  • [GEOMETRIA_I_TOPOLOGIA] -> Sección que describe los campos que contienen los atributos geométricos y topológicos de la capa.
  • [SPATIAL_REFERENCE_SYSTEM: HORIZONTAL] -> Sección que indica el tipo de sistema de referencia horizontal (cartográfico o local) y su descripción, unidades, proyección, dátum y elipsoide, etc.
  • [EXTENT] -> Sección que describe, entre otros, la extensión de la base (coordenadas del envolvente) así como del centro de escena.
  • [QUALITY:LINEAGE:PROCESS_#] -> Secciones que describen los diferentes procesos realizados en la base (creación de polígonos con estructura topológica, unión de varias capas, etc.). El organismo que los ha realizado y la fecha de realización. El símbolo # es el número del proceso efectuado en la base en el orden en que se han realizado. El primer proceso siempre es el número 1 y los posteriores llevan números consecutivos.
  • [TAULA_PRINCIPAL: NOM_CAMP] -> Sección que describe las características de un campo concreto de la tabla principal (ID_GRAFIC, N_VERTEX, PERIMETRE, AREA, COLOR, etc.), tales como el descriptor del campo, si la capa es visible y/o simbolizable, etc.
  • [TAULA_NOM_TAULA] -> Sección que informa, entre otros, los enlaces de la tabla principal con otras tablas, y el campo que se utiliza para el enlace.
  • [TAULA_NOM_TAULA: NOM_CAMP] -> Sección que describe las características de un campo concreto de la tabla enlazada.

Se puede consultar un ejemplo de fichero P.rel (vector de polígonos de una base del PEIN) aquí. Para información más completa consúltese la ayuda del Gestor Universal de Metadatos Geoespaciales.

En versiones anteriores a la versión 4.0 del MiraMon había un archivo adicional de documentación (con extensiones *.DVT, *.DVA, *.DVN y *.DVP para las familias de puntos, arcos, nodos y polígonos respectivamente, que han quedado absorbidos en el archivo de documentación *.rel correspondiente. Este era un archivo de texto plano, editable con cualquier procesador de textos (NOTEPAD, etc.).

Tal y como se ha podido observar, los archivos DBF y REL tienen como último carácter de su nombre una T, una A, una N o una P, según correspondan a bases de datos de puntos, arcos, nodos o polígonos. Esta característica es necesaria para soportar el hecho, no raro, de tener bases de datos gráficos de diferente naturaleza con el mismo nombre. Por ejemplo, si se tiene los archivos Veget.pnt y Veget.arc, en estos casos los archivos DBF y REL tendrían el mismo nombre para las dos capas, opción que no es permitida (puesto que uno borraría el otro); el problema se evita definiendo los nombres VegetT.dbf, VegetT.rel, VegetA.dbf, vegetA.rel.

A continuación se muestra un resumen de los ficheros que contendrán cada uno de los tipos (familias) de vectores estructurados topológicamente del formato propio de MiraMon:

Por motivos de rendimiento, los diferentes ficheros gráficos (PNT, ARC, etc) son binarios y segun un formato predefinido. Este formato es abierto y gratuito. Consúltese Notas técnicas para mayor información.