El lenguaje de marcado geográfico ( GML ) es la gramática XML definida por el Open Geospatial Consortium (OGC) para expresar características geográficas. GML sirve como lenguaje de modelado para sistemas geográficos, así como un formato de intercambio abierto para transacciones geográficas en Internet. La clave de la utilidad de GML es su capacidad para integrar todas las formas de información geográfica, incluidos no solo los objetos "vectoriales" o discretos convencionales, sino también las coberturas (véase también GMLJP2 ) y los datos de sensores.
GML contiene un amplio conjunto de primitivas que se utilizan para crear esquemas específicos de la aplicación o lenguajes de aplicación. Estas primitivas incluyen:
El modelo GML original se basaba en el Resource Description Framework (RDF) del World Wide Web Consortium . Posteriormente, el OGC introdujo esquemas XML en la estructura de GML para ayudar a conectar las distintas bases de datos geográficas existentes, cuya estructura relacional se definía con mayor facilidad mediante esquemas XML. El GML basado en esquemas XML resultante conserva muchas características de RDF, incluida la idea de los elementos secundarios como propiedades del objeto principal (RDFS) y el uso de referencias de propiedades remotas.
Los perfiles GML son restricciones lógicas de GML y pueden expresarse mediante un documento, un esquema XML o ambos. Estos perfiles tienen como objetivo simplificar la adopción de GML y facilitar la adopción rápida del estándar. Los siguientes perfiles , tal como se definen en la especificación GML, se han publicado o propuesto para uso público:
Los perfiles son distintos de los esquemas de aplicación. Los perfiles son parte de los espacios de nombres GML (Open GIS GML) y definen subconjuntos restringidos de GML. Los esquemas de aplicación son vocabularios XML definidos mediante GML y que residen en un espacio de nombres de destino definido por la aplicación. Los esquemas de aplicación se pueden crear sobre perfiles GML específicos o utilizar el conjunto completo de esquemas GML.
Los perfiles a menudo se crean para respaldar lenguajes derivados de GML (ver esquemas de aplicación) creados para respaldar dominios de aplicación específicos, como la aviación comercial, la cartografía náutica o la explotación de recursos.
La especificación GML (desde GML v3) contiene un par de scripts XSLT (generalmente denominados "herramienta de subconjunto") que pueden usarse para construir perfiles GML.
El perfil de características simples de GML es un perfil de GML más completo que el perfil de puntos anterior y admite una amplia gama de objetos de características vectoriales, incluidos los siguientes:
Dado que el perfil tiene como objetivo proporcionar un punto de entrada simple, no brinda soporte para lo siguiente:
No obstante, admite una buena variedad de problemas del mundo real.
Además, la especificación GML proporciona una herramienta de subconjunto para generar perfiles GML que contienen una lista de componentes especificada por el usuario. La herramienta consta de tres scripts XSLT. Los scripts generan un perfil que un desarrollador puede ampliar manualmente o mejorar de otro modo mediante la restricción de esquemas. Como restricciones de la especificación GML completa, los esquemas de aplicación que puede generar un perfil deben ser esquemas de aplicación GML válidos.
La herramienta de subconjuntos también puede generar perfiles por muchas otras razones. Al enumerar los elementos y atributos que se incluirán en el esquema de perfil resultante y ejecutar la herramienta, se obtiene un único archivo de esquema de perfil que contiene únicamente los elementos especificados por el usuario y todas las declaraciones de elementos, atributos y tipos de los que dependen los elementos especificados. Algunos esquemas de perfil creados de esta manera admiten otras especificaciones, incluidas IHO S-57 y GML en JPEG 2000.
Para exponer los datos geográficos de una aplicación con GML, una comunidad u organización crea un esquema XML específico para el dominio de la aplicación de interés (el esquema de la aplicación ). Este esquema describe los tipos de objetos en cuyos datos está interesada la comunidad y que las aplicaciones de la comunidad deben exponer. Por ejemplo, una aplicación para turismo puede definir tipos de objetos que incluyan monumentos, lugares de interés, museos, salidas de carreteras y miradores en su esquema de la aplicación . Esos tipos de objetos a su vez hacen referencia a los tipos de objetos primitivos definidos en el estándar GML.
Otros lenguajes de marcado para geografía utilizan construcciones de esquemas, pero GML se basa en el modelo de esquema XML existente en lugar de crear un nuevo lenguaje de esquemas. Los esquemas de aplicación normalmente se diseñan utilizando UML conforme a la norma ISO 19103 (Información geográfica – Lenguaje de esquemas conceptuales) [3] y luego la aplicación GML se crea siguiendo las reglas que se indican en el Anexo E de la norma ISO 19136 .
A continuación se muestra una lista de esquemas de aplicación GML conocidos y de acceso público:
KML , popularizado por Google, complementa a GML. Mientras que GML es un lenguaje para codificar contenido geográfico para cualquier aplicación, describiendo un espectro de objetos de aplicación y sus propiedades (por ejemplo, puentes, carreteras, boyas, vehículos, etc.), KML es un lenguaje para la visualización de información geográfica adaptado a Google Earth . KML se puede utilizar para representar contenido GML, y el contenido GML se puede "estilizar" utilizando KML con fines de presentación. KML es, ante todo, un transporte de representación en 3D, no un transporte de intercambio de datos. Como resultado de esta diferencia significativa en el propósito, la codificación de contenido GML para representación utilizando KML da como resultado una pérdida significativa e irrecuperable de estructura e identidad en el KML resultante. Más del 90% de las estructuras de GML (como, por nombrar algunas, metadatos, sistemas de referencia de coordenadas , datos horizontales y verticales, integridad geométrica de círculos, elipses, arcos, etc.) no se pueden transformar a KML sin pérdida o codificación no estándar. De manera similar, debido al diseño de KML como un medio de transporte de representación, la codificación de contenido KML en GML dará como resultado una pérdida significativa de estructuras de representación KML, como regiones, reglas de nivel de detalle, información de visualización y animación, así como información de estilo y representación multiescala. La capacidad de representar marcas de posición en múltiples niveles de detalle distingue a KML de GML, ya que la representación está fuera del alcance de GML. [12]
GML codifica las geometrías GML , o características geométricas , de objetos geográficos como elementos dentro de documentos GML según el modelo "vectorial". Las geometrías de esos objetos pueden describir, por ejemplo, carreteras, ríos y puentes.
Los tipos de objetos de geometría GML clave en GML 1.0 y GML 2.0 son los siguientes:
GML 3.0 y superior también incluye estructuras para describir información de "cobertura", el modelo "raster", como el recopilado mediante sensores e imágenes remotas, incluida la mayoría de los datos satelitales.
GML define características distintas de los objetos geométricos . Una característica es un objeto de aplicación que representa una entidad física, por ejemplo, un edificio, un río o una persona. Una característica puede tener o no aspectos geométricos. Un objeto geométrico define una ubicación o región en lugar de una entidad física y, por lo tanto, es diferente de una característica .
En GML, una característica puede tener varias propiedades geométricas que describen aspectos geométricos o características de la característica (por ejemplo, las propiedades Punto o Extensión de la característica). GML también proporciona la capacidad de que las características compartan una propiedad geométrica entre sí mediante una referencia de propiedad remota en la propiedad geométrica compartida. Las propiedades remotas son una característica general de GML tomada prestada de RDF. Un atributo xlink:href en una propiedad geométrica de GML significa que el valor de la propiedad es el recurso al que se hace referencia en el enlace.
Por ejemplo, una característica Building en un esquema de aplicación GML particular podría tener una posición determinada por el tipo de objeto de geometría GML primitivo Point . Sin embargo, Building es una entidad separada de Point que define su posición. Además, una característica puede tener varias propiedades geométricas (o ninguna), por ejemplo, una extensión y una posición .
Las coordenadas en GML representan las coordenadas de los objetos geométricos . Las coordenadas se pueden especificar mediante cualquiera de los siguientes elementos GML:
<gml:coordenadas> <gml:pos> <gml:posList> GML tiene múltiples formas de representar coordenadas. Por ejemplo, el <gml:coordinates>elemento se puede utilizar de la siguiente manera:
<gml:Punto gml:id= "p21" srsName= "http://www.opengis.net/def/crs/EPSG/0/4326" > <gml:coordenadas> 45,67, 88,56 </gml:coordenadas> < /gml:Punto> Cuando se expresa como se indica arriba, las coordenadas individuales (por ejemplo, 88.56 ) no son accesibles por separado a través del Modelo de Objetos de Documento XML, ya que el contenido del elemento es solo una única cadena.<gml:coordinates>
Para que las coordenadas GML sean accesibles a través del DOM XML, GML 3.0 introdujo los elementos <gml:pos>y <gml:posList>(aunque las versiones 1 y 2 de GML tenían el <gml:coord>elemento, se lo trata como un defecto y no se lo utiliza). Si se utiliza el <gml:pos>elemento en lugar del <gml:coordinates>elemento, el mismo punto se puede representar de la siguiente manera:
<gml:Punto gml:id= "p21" srsName= "http://www.opengis.net/def/crs/EPSG/0/4326" > <gml:pos srsDimension= "2" > 45,67 88,56 </gml :pos> </gml:Punto> Las coordenadas de un <gml:LineString>objeto geométrico se pueden representar con el <gml:coordinates>elemento:
<gml:LineString gml:id= "p21" srsName= "http://www.opengis.net/def/crs/EPSG/0/4326" > <gml:coordenadas> 45,67, 88,56 55,56,89,44 </gml:coordenadas> </gml:LineString> El <gml:posList>elemento se utiliza para representar una lista de tuplas de coordenadas, como se requiere para geometrías lineales:
<gml:LineString gml:id= "p21" srsName= "http://www.opengis.net/def/crs/EPSG/0/4326" > <gml:posList srsDimension= "2" > 45,67 88,56 55,56 89,44 < /gml:posList> </gml:LineString > Para los servidores de datos GML ( WFS ) y las herramientas de conversión que solo admiten GML 1 o GML 2 (es decir, solo el <gml:coordinates>elemento), no existe una alternativa a <gml:coordinates>. Sin embargo, para los documentos GML 3 y posteriores, <gml:pos>y <gml:posList>son preferibles a <gml:coordinates>.
Un sistema de referencia de coordenadas (CRS) determina la geometría de cada elemento de geometría en un documento GML.
A diferencia de KML o GeoRSS , GML no utiliza un sistema de coordenadas de forma predeterminada cuando no se proporciona ninguno. En su lugar, el sistema de coordenadas deseado debe especificarse explícitamente con un CRS. Los elementos cuyas coordenadas se interpretan con respecto a dicho CRS incluyen los siguientes:
<gml:coordinates><gml:pos><gml:posList>Un atributo srsName adjunto a un objeto de geometría especifica el CRS del objeto, como se muestra en el siguiente ejemplo:
<gml:Punto gml:id= "p1" srsName= "#srs36" > <gml:coordenadas> 100,200 </gml:coordenadas> </gml:Punto> El valor del atributo srsName es un Identificador uniforme de recursos (URI). Hace referencia a una definición del CRS que se utiliza para interpretar las coordenadas en la geometría. La definición del CRS puede estar en un documento (es decir, un archivo plano ) o en un servicio web en línea. Los valores de los códigos EPSG se pueden resolver utilizando el registro de conjuntos de datos de parámetros geodésicos EPSG operado por la Asociación de productores de petróleo y gas en [1] Archivado el 9 de agosto de 2020 en Wayback Machine .
El URI srsName también puede ser un nombre de recurso uniforme (URN) para hacer referencia a una definición de CRS común. OGC ha desarrollado una estructura de URN y un conjunto de URN específicos para codificar algunos CRS comunes. Un solucionador de URN resuelve esos URN en definiciones de CRS GML.
Los objetos Polígonos , Puntos y Cadenas de líneas están codificados en GML 1.0 y 2.0 de la siguiente manera:
<gml:Polygon> <gml:outerBoundaryIs> <gml:LinearRing> <gml:coordinates> 0,0 100,0 100,100 0,100 0,0 </gml:coordinates> </gml:LinearRing> </gml:outerBoundaryIs> < /gml:Polígono> <gml:Punto> <gml:coordenadas> 100.200 </gml:coordenadas> </gml:Punto> <gml:LineString> <gml:coordenadas> 100.200 150.300 </gml:coordenadas> </gml:LineString> Los objetos LineString , al igual que los objetos LinearRing , suponen una interpolación lineal entre los puntos especificados. Además, las coordenadas de un polígono deben ser cerradas.
El siguiente ejemplo de GML ilustra la distinción entre entidades y objetos geométricos . La entidad Building tiene varios objetos geométricos y comparte uno de ellos (el Point con identificador p21 ) con la entidad SurveyMonument :
<abc:Edificio gml:id= "SearsTower" > <abc:height> 52 </abc:height> <abc:position xlink:type= "Simple" xlink:href= "#p21" /> </abc:Edificio > <abc:SurveyMonument gml:id= "g234" > <abc:posición> <gml:Punto gml:id= "p21" > <gml:posList> 100,200 </gml:posList> </gml:Point> </abc:position> </abc:SurveyMonument> La referencia es al Punto compartido y no al SurveyMonument , ya que cualquier objeto de entidad puede tener más de una propiedad de objeto de geometría .
El perfil de puntos GML contiene una única geometría GML, es decir, un <gml:Point>tipo de objeto. Cualquier esquema XML puede utilizar el perfil de puntos importándolo y haciendo referencia a la <gml:Point>instancia del sujeto:
<PhotoCollection xmlns= "http://www.myphotos.org" xmlns:gml= "http://www.opengis.net/gml" xmlns:xsi= "http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation= "http://www.myphotos.org MyGoodPhotos.xsd" > <items> <Item> <name> Lynn Valley </name> <description> Una toma de las cataratas desde el puente colgante </description> <where> North Vancouver </where> <position> <gml:Point srsDimension= "2" srsName= "http://www.opengis.net/def/crs/EPSG/0/4326" > <gml:pos> 49,40 -123,26 </gml:pos> </gml:Point> </position> </Item> </items> </PhotoCollection> Al utilizar el Perfil de puntos , el único objeto geométrico es el objeto '<gml:Point>'. El resto de la geografía está definida por el esquema de colección de fotografías.
Ron Lake comenzó a trabajar en GML en el otoño de 1998, después de un trabajo anterior sobre codificaciones XML para transmisión de radio. Lake presentó sus primeras ideas en una reunión de OGC en Atlanta, Georgia, en febrero de 1999, bajo el título xGML. Esto introdujo la idea de un GeoDOM y la noción de lenguaje de estilo geográfico (GSL) basado en XSL . Akifumi Nakai de NTT Data también presentó en la misma reunión el trabajo parcialmente en curso en NTT Data sobre una codificación XML llamada G-XML, que estaba dirigida a servicios basados en la ubicación. [13] En abril de 1999, Galdos creó el equipo XBed (con CubeWerx, Oracle Corporation , MapInfo Corporation , NTT Data, Mitsubishi y Compusult como subcontratistas). Xbed se centró en el uso de XML para geoespacial. Esto condujo a la creación de SFXML (Simple Features XML) con aportes de Galdos, US Census y NTT Data. Galdos demostró un motor de estilo de mapas temprano que extraía datos de un servidor de datos "GML" basado en Oracle (precursor del WFS) en el primer banco de pruebas de mapas web de OGC en septiembre de 1999. En octubre de 1999, Galdos Systems reescribió el documento borrador de SFXML en una Solicitud de comentarios y cambió el nombre del lenguaje a GML (lenguaje de marcado geográfico). Este documento introdujo varias ideas clave que se convirtieron en la base de GML, incluyendo 1) la regla de objeto-propiedad-valor, 2) propiedades remotas (a través de rdf:resource) y 3) la decisión de usar esquemas de aplicación en lugar de un conjunto de esquemas estáticos. El documento también propuso que el lenguaje se basara en el Marco de descripción de recursos (RDF) en lugar de en los DTD utilizados hasta ese momento. Estas cuestiones, incluido el uso de RDF, fueron objeto de intensos debates en la comunidad OGC durante 1999 y 2000, con el resultado de que el Documento de recomendación GML final contenía tres perfiles GML (dos basados en DTD y uno en RDF), y uno de los DTD utilizaba un enfoque de esquema estático. Este documento fue aprobado como Documento de recomendación en la OGC en mayo de 2000. [14]
Incluso antes de la aprobación del Documento de Recomendación en la OGC, Galdos había comenzado a trabajar en una versión de GML en esquema XML , reemplazando el esquema rdf:resource para referencias remotas con el uso de xlink:href y desarrollando patrones específicos (por ejemplo, Barbarians at the Gate) para manejar extensiones para estructuras complejas como colecciones de características. Gran parte del trabajo de diseño de esquema XML fue realizado por el Sr. Richard Martell de Galdos, quien se desempeñó como editor de documentos y fue el principal responsable de la traducción del modelo GML básico a un esquema XML. Otras contribuciones importantes en este período provinieron de Simon Cox (CSIRO Australia), Paul Daisey (US Census), David Burggraf (Galdos) y Adrian Cuthbert (Laser-Scan). El Cuerpo de Ingenieros del Ejército de los EE. UU. (en particular Jeff Harrison) apoyó bastante el desarrollo de GML. El Cuerpo de Ingenieros del Ejército de los Estados Unidos patrocinó el proyecto “USL Pilot”, que resultó muy útil para explorar la utilidad de los conceptos de vinculación y estilo en la especificación GML, con un trabajo importante realizado por Monie (Ionic) y Xia Li (Galdos). El borrador de la especificación del esquema XML fue presentado por Galdos y fue aprobado para su distribución pública en diciembre de 2000. Se convirtió en un Documento de recomendación en febrero de 2001 y en una Especificación adoptada en mayo del mismo año. Esta versión (V2.0) eliminó los “perfiles” de la versión 1 y estableció los principios clave, como se describe en la presentación original de Galdos, como la base de GML.
Mientras se desarrollaban estos acontecimientos, en Japón se seguía trabajando en paralelo en G-XML bajo los auspicios del Centro de Promoción de Bases de Datos Japonés bajo la dirección del Sr. Shige Kawano. G-XML y GML diferían en varios aspectos importantes. Destinado a aplicaciones LBS, G-XML empleaba muchos objetos geográficos concretos (por ejemplo, Mover, POI), mientras que GML proporcionaba un conjunto concreto muy limitado y construía objetos más complejos mediante el uso de esquemas de aplicación. En ese momento, G-XML todavía se escribía utilizando un DTD, mientras que GML ya había hecho la transición a un esquema XML. Por un lado, G-XML requería el uso de muchas construcciones fundamentales que en ese momento no estaban en el léxico de GML, incluyendo temporalidad, referencias espaciales por identificadores, objetos con historias y el concepto de estilo basado en topología. GML, por otro lado, ofrecía un conjunto limitado de primitivos (geometría, característica) y una receta para construir tipos de objetos (características) definidos por el usuario.
Una serie de reuniones celebradas en Tokio en enero de 2001, en las que participaron Ron Lake (Galdos), Richard Martell (Galdos), el personal de OGC (Kurt Buehler, David Schell), el Sr. Shige Kawano (DPC), el Sr. Akifumi Nakai (NTT Data) y el Dr. Shimada (Hitachi CRL), condujeron a la firma de un memorando de entendimiento entre DPC y OGC por el que OGC se esforzaría por inyectar los elementos fundamentales necesarios para dar soporte a G-XML en GML, permitiendo así que G-XML se escribiera como un esquema de aplicación GML. Esto dio lugar a que muchos tipos nuevos entraran en la lista de objetos básicos de GML, incluidas observaciones, características dinámicas, objetos temporales, estilos predeterminados, topología y puntos de vista. Gran parte del trabajo fue realizado por Galdos bajo contrato con NTT Data. Esto sentó las bases para GML 3, aunque se produjo un nuevo desarrollo significativo en este período, a saber, la intersección de OGC e ISO/TC 211 .
Aunque existía una codificación básica para la mayoría de los nuevos objetos introducidos por el acuerdo GML/G-XML, y para algunos introducidos por Galdos dentro del proceso OGC (en particular, las coberturas), pronto se hizo evidente que pocas de estas codificaciones cumplían con las especificaciones abstractas desarrolladas por el TC/211 de ISO, especificaciones que se estaban convirtiendo cada vez más en la base de todas las especificaciones OGC. La geometría GML, por ejemplo, se había basado en un modelo de geometría anterior y solo parcialmente documentado (Simple Features Geometry) y esto era insuficiente para soportar las geometrías más extensas y complejas descritas en el TC/211. La gestión del desarrollo de GML también se modificó en este período de tiempo con la participación de muchas más personas. Milan Trninic (Galdos) (estilos predeterminados, CRS), Ron Lake (Galdos) (Observaciones) y Richard Martell (Galdos) (características dinámicas) realizaron contribuciones significativas en este período de tiempo.
El 12 de junio de 2002, el Sr. Ron Lake fue reconocido por la OGC por su trabajo en la creación de GML al recibir el premio Gardels. [15] La cita en el premio dice: “En particular, este premio reconoce su gran logro en la creación del lenguaje de marcado geográfico (GML) y su trabajo excepcionalmente sensible y efectivo para promover la reconciliación de las diferencias nacionales para promover una estandarización significativa de GML a nivel global”. Simon Cox (CSIRO) [16] y Clemens Portele (Interactive Instruments) [17] también recibieron posteriormente el premio Gardels, en parte por sus contribuciones a GML.
El Consorcio Geoespacial Abierto (OGC) es una organización internacional de estándares de consenso voluntario cuyos miembros mantienen el estándar de lenguaje de marcado geográfico . El OGC se coordina con la organización de estándares ISO TC 211 para mantener la coherencia entre el trabajo de estándares de OGC y de ISO. GML fue adoptado como estándar internacional (ISO 19136:2007) en 2007.
GML también puede [ aclaración necesaria ] incluirse en la versión 2.1 del Modelo Nacional de Intercambio de Información de los Estados Unidos (NIEM).
La norma ISO 19136 Información geográfica – Geography Markup Language, es una norma de la familia ISO – de normas para información geográfica (ISO 191xx). Surgió de la unificación de las definiciones del Open Geospatial Consortium y Geography Markup Language (GML) con las normas ISO-191xx.
Las versiones anteriores de GML no eran conformes con la norma ISO (GML 1, GML 2) y la versión 3.1.1 de GML no lo era. La conformidad con la norma ISO significa, en particular, que GML ahora es también una implementación de la norma ISO 19107 .
El lenguaje de marcado geográfico (GML) es una codificación XML que cumple con la norma ISO 19118 para el transporte y almacenamiento de información geográfica modelada según el marco de modelado conceptual utilizado en la serie ISO 19100 y que incluye tanto las propiedades espaciales como las no espaciales de las características geográficas. Esta especificación define la sintaxis, los mecanismos y las convenciones del esquema XML que: