27/12/2003Miguel A. Bernabé + Miguel A. Manso. Grupo de Trabajo MERCATOR. Dep. Ingeniería...

27/12/2003 Miguel A. Bernabé + Miguel A. Manso. Grupo de Trabajo MERCATOR. Dep. Ingeniería Topográfica y Cartografía. UPM 1

Tecnología OpenGIS para la Interoperabilidad de la Geo-

Información. Peter van Oosterom

Department of Geodesy, TU Delft, The Netherlands.

Con ejemplos de la nueva estructura de datos topográficos (top10nl)

¿Interoperabilidad de la IG? Y qué cojones es interoperabilidad? Entérate aquí

http://www.gisdevelopment.net/magazine/gisdev/2003/september/chigis1.shtml


Resumen previo

1. Introducción Interoperabilidad OpenGIS Consortium OpenGIS e ISO Projecto ObjectTop10

2. Geo-DBMS3. GML4. Internet GIS5. Conclusión


1. Introducción: Interoperabilidad

Sistemas IG (y componentes) de diferentes orígenes (fabricantes) deben trabajar juntos como si fuesen de la misma casa.

Los datos IG producidos en un sistema deben ser utilizados en otro sistema sin conversión (explícita); actualmente esto toma más del 50% del esfuerzo total de IG en algunas organizaciones.

Por ejemplo: almacenamiento de datos, editor, visualizador, herramientas de análisis, etc. pueden provenir cada una de diferentes fabricantes (y no necesitar conversores de datos)


1. Introducción: mercado IG

El objetivo de OpenGIS es crecer en mercado de la IG (software y datos) a través de la interoperabilidad

En la ‘Digital Earth’ (Tierra Didital) de Al Gore, la geoinformación juega un importante rol y se requiere la cooperación entre muchas organizaciones autónomas (y personas particulares). Necesidad de interfaces/estándares

Similar al World Wide Web Consortium (W3C)


1. Introduction: OpenGIS ConsortiumOrganization

Creado en la primera mitad de los 90s: una iniciativa conjunta de la industria, las universidades y el gobierno.

Al comienxo fundamentalmente organizaciones USA, actualmente participación de todo el mundo.

Son miembros los más importantes vendedores de SIG, DBMS software, hardware (y geo-datos)

Diferentes tipos (y precios) de pertenencia con diferentes niveles de influencia (desde miembros principales a asociados)


Las especificaciones abstractas forman los cimientos conceptuales de un cierto aspecto/dominio de la IG.

De acuerdo con la especificación abstracta se lanza una RFP (Request for Proporsal o Petición de Propuesta) para detallar una especificación de la implementación

Ambas deben ser aprobadas por los miembros del Comité Técnico (TC) y el Comité de Gestión (MC).

Discusión relativamente rápida para crear consenso Relative fast approach to create consensus, junto con un testbed

1. Introduction: OpenGIS Consortium

Descripción (1)


Cada dos meses reunión de ambas partes Comité Técnico + Comité Gestor en el sitio ofrecido por uno de los miembros.

El trabajo lo hacen los miembros en un WG (Grupo de Trabajo) o en un SIG (Grupo de interés especial) Grupo de trabajo. AS= Especificaciones abstractas Grupo de Interés Especial. IS= Implementación

especificaciones El trabajo tiene el apoyo de personal de OCG (alrededor de 10

personas pagadas con las tarifas de los socios) Programa de Certificación para los productos que esan

acordes con las especificaciones del OGC.


Descripción (2)


0: AS overview 1: feature geometry 2: spatial ref. systems 3: locational geometry 4: stored functions and

interpolations 5: OpenGIS feature 6: coverage type 7: earth imagery 8: feature relationships

9: accuracy 10: feature collections 11: metadata 12: service architecture 13: catalog service 14: semantics 15: image exploitation

services 16: image coordinate

trasformation services


Descripción (3)

AS: Abstract Specification


Estas AS están en muy diferentes situaciones de desarrollo pero todas pertenecen al genérico ‘core technology’ o tecnología fundamental

Adicionalmente hay SIGs (Grupos de Interés Especial) en tecnologías con dominio-específico; por ejemplo: SIG en Telecomunicaciones SIG en Transporte SIG en Defense SIG en WWW mapping SIG en Propiedad y tenencia de la tierra (previsto) SIG en Europa (un poco extraño ...)


Descripción (4)


1. Introducción: OpenGIS e ISO (1)

Los estándares en esta presentación son OpenGIS OpenGIS tiene dos niveles de estándares:

Especificaciones abstractas (campo del conocimiento) Especificaciones de implementación (para alguna DCPs *)

ISO (especialmente TC211) tiene/desarrolla también una serie de estándares geográficos, comparables a las especificaciones abstractas del OGC.

ISO y OpenGIS armonizan: las especificaciones abstractas y los estándares ISO son (o llegarán a ser) iguales

* DCP = Distributed Computing Platforms. En OSC: SQL, COM y CORBA


1. Introducción: OpenGIS e ISO (2)


1. Introducción: Project ObjectTop10 (1) background

Los geo-datos deben transferirse inmediatamente después de la creación del mapa digital

Muchos sistemas IG diferentes, necesidad de estándares (de-facto y oficiales), problemas que permanecen.

Después separación explícita: DLM and DCM Aceptación mundial de OpenGIS Proyecto TOP10 :

Acomodarse a los nuevos requisitos de los usuarios (CGI), Desarrollar nuevos modelos lógicos /DLM (ITC), Desarrollar prototipos GML para los nuevos DML (TUDelf)

DLM:Digital Lansscape ModelDCM: Digital Cartographic ModelCompleta descripción http://kartoweb.itc.nl/top10nl/TOP10NL_eng/index2.htmPequeña descripción Top10vector: http://www.geodan.nl/uk/product/nlgrschaal/tdn.htm

http://www.itc.nl/

http://www.tudelft.nl/

http://kartoweb.itc.nl/top10nl/TOP10NL_eng/index2.htm



http://www.geodan.nl/uk/product/nlgrschaal/tdn.htm

http://www.geodan.nl/uk/product/nlgrschaal/tdn.htm


1. Introducción: Project ObjectTop10 (2) necesidad de una Geo-DBMS

El nuwevo modelo conceptual de Top10 incluye: Un único id’s Aspectos temporales Muchos atributos Objetos complejos (topología, composiciones) Conjunto de datos continuo

Dejar el proceso de producción basado en archivos y migrar hacia un proceso basado en DBMS.


Vistazo

1. Introducción2. Geo-DBMS

arquitecturas funcionalidad feature geometry: simple, complex, raster

3. GML4. Internet GIS5. Conclusión

Acceso al sitio GDMC donde se desarrolla el GeoDBMS de la Universidad de Delf

http://www.gdmc.nl/


2. Geo-DBMS: arquitecturas

Primera: arquitectura dual (separar los datos espaciales de la gestión de los datos)

>> problemas de consistencia; Segunda: arquitectura en capas (todos los

datos en una DBMS, pero el conocimiento espacial en el middle ware; ej. Métodos de almacenamiento de

Datos:SDE (ESRI: Spatial Data Engine) y SDO (Oracle: Spatial Data Option)

>> no es lo óptimo para preguntas

Tercera: arquitectura integrada (todos los datos en DBMS, tipos espaciales/functiones)

>> problemas topológicos DBMS

GIS-frontend

RDBMS

spatial middleware

GIS-frontend

RDBMS Spatial

unique id’s

Spatial

GIS-frontend

extensible DBMS


2. Geo-DBMS: funcionalidad

Operadores de tipos de datos espaciales en DBMS: OpenGIS, IS (especificación de implementación), Simple Feature Specification para SQL

Topología (features complejas): en construcción en el OpenGIS

Aspectos temporales futuro: estándard en TSQL, entretanto: explicitar en el modelo de datos

Indexación espacial en clustering


2. Geo-DBMS: feature geometry, historia sencilla (1)

Tras 10-15 años de investigación en sistemas extensibles (Postgres, O2, Gral), la mayoría de las DBMSs tienen ahora sobre-extensibilidad con tipos de datos abstractos

Los tipos de datos espaciales 2D (punto, linea y polígono) y los operadores están estandarizados.

Ya la especificación de implementación 2simple feature” del OGC para SQL (nivel 1 no es OK, nivel 2 es OK), también en el futuro ISO SQL3 estándard

En 1999 estuvo disponible la primera implementación de este estándard


2. Geo-DBMS: feature geometry, algunos detalles sencillos (2)

Las features simples son auto-contenidas (y no tienen relaciones explícitas con otras)

Los operadores pueden operar una (unitaria) o dos (binaria) features simples

Algunos conocidos operadores son los operadores de relaciones topológicas (Egenhofer/Clementini)

No confundirlos con los operadores de estructuras topológicas (editar, analizar)


PointLineStringLinearRingPolygonMultiPointMultiLineStringMultiPolygon

CoordBoxAbstactGeom..

2. Geo-DBMS: feature geometrysimple (3) UML

Curso de UML en castellano: http://www.dsic.upv.es/~uml/index.html

http://www.dsic.upv.es/~uml/index.html














2. Geo-DBMS: feature geometry, historia completa (1)

Los modelos topológicos tienen una larga y bien conocida historia en los SIG. (ej. DIME, 1970)

Existen diferentes tipos para diferentes propósitos: Representar una partición plana (e.g. cadastral map) Representar una red lineal, calles, carreteras, clables,...

Las principales ventajas son: Evita redundancia y mantiene consistencia Facilita operadores complejos (ej. Camino más corto)

El modelo topológico es una feature compleja con referencia entre los diferentes componentes.


2. Geo-DBMS: feature geometry, modelos alternativos complejos

(2) Diferentes opciones: Bordes y caras para

almacenar Notar la diferencia en la terminología. Bordes y

caras en vez de lineas y polígonos. La topología plana debe permitir la reconstrucción

de polígonos (materialización) de una cara sin mirar el valor de las coordenadas.

Guía nacional holandesa para el intercambio de datos (NPR3611): chain + wheel topology


2. Geo-DBMS: feature geometry, complex (3) an implementation

Wheel topology: reference form face to everyedge in outer (and inner) boundaries:

4

8

5

29

+

-

-+

-

0

1. left/right references edge-to-face2. Ordered, singed ref’s face-to-edge: 4,-8,-5,2,0,-9

Drawback is variablelength of list


2. Geo-DBMS: feature geometry, complex (4) DBMS support

problem Storing the references in not a problem in an

RDBMS (pay attention to variable length) However, RDBMS does not support the

topology model: check correctness (after edit operations), compute area, perimeter,...

RDBMS (SQL) can not navigate within the system (against relational principle), a procedural language (iterator) outside needed

OO-DBMS can navigate within the system


2. Geo-DBMS: feature geometry, complex (5) DBMS support

wanted Due to difficulty to handle topology inside the

RDBMS it is handled outside (middle ware or frontend GIS); compare: early simple features

Non-optimal because: implementation of same functionality many times other direct RDBMS users might corrupt structure non-optimal query plans (DBMS knows only ‘half’) overhead/data transfer between RDBMS and middle ware

during query execution

Functionality is generic >> support by DBMS


2. Geo-DBMS: feature geometry, complex (6) ISO TC 211, spatial

schema (draft ISO 19107) Geometric objects: point, curve, surface, solid

geometric primitives (open, without boundary) geometric aggregates (multi…, non related sets) geometric complexes (closed, no interior overlap)

Topological objects: node, edge, face, solid topological primitives topological complexes topological complexes with geometric realization

up to 3D, many types of curves, surfaces not stated which ref’s to implement (abstract)


2. Geo-DBMS: feature geometry, raster

Abstract specification ‘earth imagery’ (compare abstract specification feature geometry for vector data, ‘ISO’ model)

Implementation specification ‘grid coverage’ (compare implementation for simple feature)


Overview

1. Introduction2. Geo-DBMS3. GML

overview schema document relay

4. Internet GIS5. Conclusion

Descripción total de GML en el WebSite de Open GIS Consortium (aquí)

http://www.opengis.org/docs/02-023r4.pdf


3. GML: overview (1) problema

Problema con los actuales formato de intercambio Estándares oficiales (NEN/CEN): no muy bien soportados

por productos Estándares de fabricantes específicos: no adecuados

para la competencia (otros fabricantes) y pueden cambiar en el tiempo (y pueden no ser los mismos sobre diferentes plataformas)

Solución: Para Internet GIS (web-mapping) se ha ofrecido una solución: Geography Markup Language (GML)


3. GML: overview (2) por qué XML?

GML está basado en dos importantes estándares: modelo geográfico de OpenGIS y XML

XML permite comprobar documentos bien-formateados y validar (de acuerdo al esquema)

XML son documentos de texto (editores sencillos) Integración con datos no-espaciales (basados-en-

XML) GML/XML son fáciles de transformar (de DLM a

DCM) utilizando XSLT


3. GML: overview (3) Ejemplo

<Point srsName=“EPSG:4326”> <Coord><x>5</x><y>10</y></Coord></Point>

<LineString srsName=“EPSG:4326”> <coordinates>0,2 3,4 4,-1</coordinates></LineString>

Dos ejemplos de elementos de primitivas geométricas(validos de acuerdo a estándard geometry.xsd)


3. GML: overview (4) definición del esquema

(schema) GML está basado en XML (eXtensible Markup

Language) Diferentes formas para definir el

modelo/etiquetas/… DTD: Document Type Definition XML Schema (W3C sucesor del DTD, oct 2000) RDF: Resource Description Framework

DTD y XML Schema son orientados a sintaxis/estructura, RDF está más orientado a semántica

GML 2.0 (y futuro 3.0) usan XML Schema


3. GML: overview (5) status

Historia: Mayo 2000: GML 1.0 (Recomendación) Diciembre 2000: GML 2.0 (Candidato a Recomendación) Marzo 2001: GML 2.0 (Implementación spec.)

Diciembre 2000: Ordnance Survey Initiative “DNF” (Digital National Framework) también basada en GML 2.0

Junio 2002: GML 2.1.2 (Implementación spec.) Abril 2001: comienzan trabajos sobre GML 3.0

(plan del documento para Diciembre 2002)


3. GML: schema definition (1)limitaciones de GML

Sólo elemntos lineales (no arcos) No topología (ej. NPR3611: chain + wheel)

Diferentes tipos para diferentes propósitos:• representar una partición plana (posible reconstrucción de

un polígono lado a lado sin mirar el valor de las coordenadas)

• Representar una red lineal de cables (o carreteras,…) Principales ventajas:

• Impedir redundancia y mantener consistencia• Facilitar opraciones complejas (ej. camino más corto)

No aspectos temporales (full delivery/actualizaciones)


3. GML: schema definition (2) TOP10 schema

Define application features (clases) con attributes (propiedades)

Puede solucionar limitaciones GML estándares mediante la aplicación de soluciones del schema para topología y/o aspectos temporales (no esperar que cada SIG pueda hacer esto)

Las clases del esque,a de aplicación pueden heredar de las clases (OpenGIS) abstractas

La definición de XML schema en un archivo ‘xsd’ Los datos XML en un archivo ‘xml’

3. GML: schema definition (3) prototipo 1, definicion (1/2)

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><schema targetNamespace="http://www.tdn.nl/top10test" xmlns="http://www.w3.org/2000/10/XMLSchema" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:gml="http://www.opengis.net/gml" xmlns:tdn="http://www.tdn.nl/top10test" elementFormDefault="qualified" version="0.4">

<import namespace="http://www.opengis.net/gml" schemaLocation="feature.xsd"/> <element name="top10vectorobjecten" type="tdn:top10vectorobjectenType" substitutionGroup="gml:_FeatureCollection"/>

<element name="Weg" type="tdn:WegType" substitutionGroup="gml:_Feature"/>


3. GML: schema definition (4) prototype 1, definition (2/2)

<complexType name="top10vectorobjectenType"> <complexContent> <extension base="gml:AbstractFeatureCollectionType"> <sequence> <element ref="tdn:Weg" minOccurs="0" maxOccurs="unbounded"/> </sequence> </extension> </complexContent> </complexType>

<complexType name="WegType"> <complexContent> <extension base="gml:AbstractFeatureType"> <sequence> <element name="TdnCode" type="integer"/> <element ref="gml:polygonProperty"/> </sequence> <attribute name="OID" type="integer" use="required"/> </extension> </complexContent> </complexType></schema>

3. GML: documento (1) prototipo 1, datos (1/2)

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<tdn:top10vectorobjecten xmlns:tdn="http://www.tdn.nl/top10test" xmlns:gml="http://www.opengis.net/gml" xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance" xsi:schemaLocation="http://www.tdn.nl tdndemo.xsd">

<gml:boundedBy> <gml:Box srsName="rd"> <gml:coordinates>0,300 300,600</gml:coordinates> </gml:Box> </gml:boundedBy>


3. GML: documento (2) prototipo 1, datos (2/2)

<tdn:Weg OID="33"> <tdn:TdnCode>02900</tdn:TdnCode> <gml:polygonProperty> <gml:Polygon srsName="rd"> <outerBoundaryIs> <LinearRing> <coord> <X>173.0739</X> <Y>447.5921</Y> </coord> <coord> <X>173.0771</X> <Y>447.5889</Y> </coord> <coord> <X>173.0786</X> <Y>447.5833</Y> </coord> ... <coord> <X>173.0649</X> <Y>447.5932</Y> </coord> <coord> <X>173.0649</X> <Y>447.5932</Y> </coord> <coord> <X>173.0689</X> <Y>447.5935</Y> </coord> <coord> <X>173.0739</X> <Y>447.5921</Y> </coord> </LinearRing> </outerBoundaryIs> </gml:Polygon> </gml:polygonProperty> </tdn:Weg>...</tdn:top10vectorobjecten>


3. GML: documento (3) validación (1/2)

Comprueba si el documento está “bien-formado” de acuerdo con el estándard xml (si las etiquetas casan)

Valida el archivo GML (.xml) frente al Schema Definition (.xsd)

Schema Definition es una colección de schemas: GML Feature GML Geometry Application (top10)

Se utiliza el software comercial XML Spy para este propósito


LIVE Prototype1

3. GML: documento (4) validación (2/2)


3. GML: document (5) generation (1/3)

Desde TDN Microstation Design Files a Oracle 9i spatial (object model) utilizando la herramienta de conversión FME

Define vistas DBMS para separar y obtener nombres adecuadaos para las clases y sus atributos.

Via JDBC Connection to Java Program el cual genera XML (data) y XSD (schema)

Se valida el resultado usando XML Spy


3. GML: documento (6) generación (2/3)

FME Interface


3. GML: documento (7) generación (3/3)

El programa JDBC Java utiliza la Librería Oracle SDO para reconstruir las geometrías DBMS

El programa es controlado por el estado de SQL el cual define la salida

select oid,tdncode,geom

from tdndata

where overlaps(geom, KLANTGEBIED

and tdncode between 3000 and 4000;

Esto genera tanto el schema definition como el archivo de datos GML


3. GML: relay

12 june 2001: KvAG seminar ‘GML relay’ Alterra, Wageningen general GML introduction 3 to 5 Geo-ICT participants:

their side of the story read, edit, and write GML for next participants

more info on http://www.kvag.nl/


3. GML: relay

12 june 2001: KvAG seminar ‘first GML relay’ at Alterra, Wageningen (only 2 vendors)

13 december 2002: KvAG seminar ‘second GML relay’ at TDN, Emmen

general GML – Top10NL introduction 3 to 5 Geo-ICT participants:

their side of the story read, edit, and write GML for next participants

more info on http://www.kvag.nl/


GML Relay scenarioDatabaseLegendIONIC WebMap ServerIONICPORTRAYAL ENGINEGMLIONIC WFS Framework(transactional)IONIC Core Featureserver for 8iInput streamView and UpdatestreamExport streamGMLdisplayupdateinputNext participant

Example of data from

GML in LAMPS2

Data courtesy ofTopografische Dienst


Overview

1. Introducción2. Geo-DBMS3. GML4. Internet GIS

GII metadatos/catálogos web mapping feature server

5. Conclusión


4. Internet GIS: GII (1) objetivo, nuevo approach

Nuevo approach que impide copiar conjuntos de datos: Los datos se mantenienen en la fuente Ninguna gestión de los datos en el lado del cliente Datos accesibles a todo el mundo

Nuevo approach que permite mejores precios: Posibilidad de cargar cada vez por conjunto ya usado En vez de pagar por datasets completos Bueno desde el punto de vista del vendedor y del

comprador

Ejemplo temprano; GeoShop (Magma/Lava).El servidor magma proporciona acceso a operaciones espaciales y a datos vector y raster. Lava, un applet de lava que muestra los datos recibidos del servidor magma. Ver aquí descripción

http://www.pgs.nl/doc/index.html



4. Internet GIS: GII (2) Ejemplo temprano

Rápido acceso a los geodatos:

- multi-fuente- transparente- Cliente Java

PGS, 1996: Casema, Almere and Kadaster.


4. Internet GIS: GII (3) componentes

La Infraestructura de la Geo-Información (GII) tiene cuatro componentes principales:

1. Conjuntos de Geodatos2. Servicios de procesamiento de Geodatos (geo-DBMS)3. Estándard de interoperabilidad4. Redes (sin cables)

Todos los componentes tienen aspectos: técnicos, organizativos, financieros, legales, y otros.


4. Internet GIS: servicios de metadatos y catálogo

Contenido/Estructura de los metadatos:OpenGIS sigue a ISO TC 211 (19115)

OpenGIS se centra en el servicios de catálogo, esto es, cómo acceder a los metadatos (y a procesos disponibles de descripción de metadatos)

El servicio de catálogo estándard de OpenGIS soporta la implementación descentralizada.

Utilizada para realizar los clearinghouses nacionales de ge-información. ej. NCGI en Holanda.


4. Internet GIS: web mapping (1)overview

Web mapping puede ser como una forma interactiva de interoperabilidad.

OpenGIS ha creado dos estándares para interrogar y recibir geodatos: web map server interface para cuestiones de preguntas:

GetCapabilities, GetMap y GetFeature_info geography markup language (GML) para transferencia de

datos vectoriales (simple features)

Hay muchos tipos (comerciales) de sistemas web-mapping pero hay 3 tipos básicos:


4. Internet GIS: web mapping (2)tipos de arquitecturas

Tres tipos de clientes web-mapping:

(JPEG)

(SVG)

(GML)

Formato de Imagen

Display

Render

DisplayElement

Generator

Filter

Features

Fuente de Datos

Estilo

Especific. OpenGIS

Para simples features

de la pregunta

Limitaciones

de la imagen

Limitaciones

Características

del Servicio

Raster/Vector

DescripcionesMuestraElementos

Imagen


4. Internet GIS: web mapping (3)HTTP GetMap request

Parámetros estandarizados en URL (HTTP-request), ej. BBOX, LAYERS, FORMAT,...

Ejemplo de GetMap (para un servidor de mapas web):

http://b-map-co.com/servlets/mapservlet?WMTVER=0.9&REQUEST=map&BBOX=-88.68815,30.284573,-87.48539,30.989218&WIDTH=792&HEIGHT=464&SRS=4326&LAYERS=AL+Highway,AL+Highway,AL+Highway&STYLES=casing,interior,label&FORMAT=GIF&TRANSPARENT=TRUE


4. Internet GIS: web mapping (4)respuesta GML

Los datos vuelven en GML, el formato y la estructura parecen formato HTML (etiquetas de inicio y final):

<usgs:road ID = "1354"> <usgs:NumLanes>4</usgs:NumLanes> <usgs:SurfaceType>LooseGravel</usgs:SurfaceType> <usgs:Centerline ogcgml:srsName= "http://www.opengis.org/srs#epsg:26751"> <ogcgml:LineString> <ogcgml:coordinates>0.0,0.0 1.123,1.56 2.34, 4.5 0.0,0.0</coordinates> </ogcgml:LineString> </usgs:Centerline></usgs:road>


4. Internet GIS: feature server

Tras el interfaz del Web Map Server (WMS) el trabajo continuó en el Web Feature Server (WFS) con un ‘request for comments’ sobre la propuesta: GetCapabilities DescribeFeature LockFeature Transaction GetFeature/GetFeatureWithLock

Futuro de Internet GIS: más que sólo lectura!


Overview

1. Introduction2. Geo-DBMS3. GML4. Internet GIS5. Conclusion


5. Conclusiones (1): XML, GML El GML se basa en dos estándares mundialmernte

aceptados (geometría OpenGIS/ISO y XML)

Mundo muy dinámico: cada mes nuevos estándares o versiones de estándares importantes.

Dificultades para seleccionar la versión correcta (última).

La versión actual de GML es muy limitada (no arcos, no 3D, no topología, no aspectos temporales)

El prototipo de la Application schema TOP10 GML puede tener dificultades para diferentes SIGs


5. Conclusiones (2): OpenGIS

6 Implementation specifications terminadas 2 programas de certificación (test) terminados Modelos eficaces, iniciativas chequeadas: WMT1, WMT2,

OpenLS Varios productos certificados (SFS-variants)

OpenGIS resultados/recientes desarrollos:

La Tecnología OpenGIS está necesitada de una eficiente y sostenible implementación del nuevo Top10


5. Conclusiones (3): GII y Geo-DBMS

La Infraestructuras de la Geo-Información ofrece un nuevo modelo: datos en la fuente

El rol de Geo-DBMS en la arquitectura de la GII es muy importante (totalidad de la comunidad)

La tecnología DBMS se empuja más allá de sus límites: tipos de datos espaciales, operadores, indexing, y clustering en DBMS (features simples y complejas , OpenGIS)

Se necesita más I+D


5. Conclusion (4): TU Delft, Dep de Geodesia

TU Delft, Dept. of Geodesy se ha convertido en un miembro del Consorcio OpenGIS y participa en la estandarización y en las comprobaciones.

TU Delft, Dept. of Geodesy ha establecido convenios con líderes en la induatria de la geo(ITC) : Sun (hardware, Java) Oracle (8i spatial): TU Delft es el único centro de I+D

Europeo del grupo de Centros de Excelencia espacial de Oracle

Computer Associates (Ingres, Jasmine) ESRI (ArcGIS, ArcIMS, ArcScene, ArcSDE,…) Bentley (3D, CAD, Microstation GeoGraphics) PGS (GEO++, Magma/Lava)



5. Conclusiones (5): Status Proyecto Top10vector

Evaluación de modelo de datos y GML Que requisitos del usuario se resuelven y cuales no no topologia, no 3D

Retroalimentación de los grupos de usuarios Nuevos proyectos:

cartographía / visualización Otras escalas (1:50.000 - 1:500.000)


Desde 15 Noviembre 2000 en Delft:Geo Data Management Center

Spatial DBMSItems de investigación:- topología- benchmark/test- time (TSQL)- data quality- 3D data types- VR/AR- VLM DBMS- generalization- ...http://

www.gdmc.nl/


Casagrande ??

Italiano, Ciclista… Qué?

Geo-data, spatial DBMS?


Casagrande ?

Italiano … ‘Almacén, En este caso De GeoDatos!


Casagrande !

Sun E3500 2 CPU’s 2 Gb mem. principal 0.6 Tb disks:

intern via FCAL software RAID1 y RAID 0

extern 2*A1000Storedge array

hardware RAID5


3. GML: transformaciones (1)

map making

DLM

DCM


3. GML: transformaciones (2) style sheets

Style sheet define como se presenta/visualiza el DLM descrito por GML

El DLM se transforma en presentación gráfica (también alguna clase de XML): SVG (scaleable vector graphics, W3C) VML (vector markup language, MicroSoft) X3D (‘variante XML’ de VRML, Web 3D consortium)

Dos aspectos de style sheets: the style description itself and the actual transformation


3. GML: transformaciones (3) XSLT

XSLT: Transformación de estilo de XML XSLT es un lenguaje de manipulación de texto ‘buscar y

reemplazar’ (texto azul por rojo) XSLT para especificaciones de estilos de mapa estándares

27/12/2003Miguel A. Bernabé + Miguel A. Manso. Grupo de Trabajo MERCATOR. Dep. Ingeniería...

Documents

Transcript of 27/12/2003Miguel A. Bernabé + Miguel A. Manso. Grupo de Trabajo MERCATOR. Dep. Ingeniería...