Día de la interoperabilidad INSPIRE Conference and JIIDE 2016 Barcelona Joan Masó 29 Setembre 2016 Copyright © 2015 Open Geospatial Consortium

Copyright © 2015 Open Geospatial Consortium Agenda 16:00 Introducción Athina Trakas 16:15 Últimos avances i tendencias en el OGC (REST, GeoJSON, integrated services,...) Joan Masó 16:35 Estado y futuro del WMTS. Nuevo test de implementaciones 16:45 Buscador de nombres geográficos IGN Search Guadalupe Cano 17:00 Implantación de servicios OGC en Latinoamérica 17:15 Futuras actividades del grupo y conclusiones Joan Masó y Athina Trakas Alguien quiere añadir alguan cosa? Copyright © 2015 Open Geospatial Consortium

Copyright © 2015 Open Geospatial Consortium Del XML al JSON Componentes del asunto: GeoJSON frente a GML JSON para coverages (CoverageJSON y CIS JSON) JSON en comunicaciones entre servicios JSON schema JSON-LD Copyright © 2015 Open Geospatial Consortium

Copyright © 2015 Open Geospatial Consortium GeoJSON frente a GML GeoJSON era un estándar creado por la comunidad. Ahora es un estándar IETF https://www.rfc-editor.org/rfc/rfc7946.txt Su uso en OGC presenta los siguientes problemas: No sigue la norma General Feature Model donde se define la necesidad de crear Feature Types. No soporta otro CRS que CRS84 No permite ser extendido sin que deje de ser GeoJSON. No permite migración a JSON-LD Copyright © 2015 Open Geospatial Consortium

JSON para coverages (CoverageJSON y CIS JSON) La idea original fue presentada en el TC de Nottingham. El proyecto Melodies recogió la idea y la desarrolló a su manera. https://github.com/covjson/specification En el WCS se está preparando la migración a la ISO Ahora GMLCov se llama CIS No és solo XML sino que además propone JSON Copyright © 2015 Open Geospatial Consortium

JSON en comunicaciones entre servicios No hay problema en redactar un GetCapabilities o cualquier otro mensage entre el cliente y el servidor en JSON pero… La mayoría de los nuevos servicios se basan el OWS Common. Es necesario un acuerdo en cómo derivar JSON desde OWS Common y que todos los servicios usen este acuerdo. En el Testbed 12 se está trabajado en esto Copyright © 2015 Open Geospatial Consortium

Copyright © 2015 Open Geospatial Consortium Un JSON más formal JSON Schema JSON-LD JSON tiene fama de más frexible que XML IMHO, un organismo de estandarización debe proporcionar mecanismos de validación JSON Schema proporciona una buena alternativa pero sus creadores han perddo la energia y no pueden continuar con el proceso de estandariación LD por lo de Linked Data Hay mucha confusion sobre lo que JSON-LD proporciona realmente En realidad es un mecanismo para introducir en JSON Semantica en base a URI’s Y así poder transformar estructuras JSON en RDF automáticamente. Algunas cosas (como los arrays dobles) no pueden ser transformados (GeoJSON). Copyright © 2015 Open Geospatial Consortium

Copyright © 2015 Open Geospatial Consortium Un JSON más format Existe una tensión entre si debemos formalizar más JSON o destinarlo solo a estructuras sencillas. Mi opinión es que en OGC/ISO estamos acostumbrados a definir estructuras en base a UML y que debemos necesitamos un conjunto de reglas para pasar de UML a JSON sin perder nada o al final no podremos hacer lo que queremos hacer. Estas reglas deben permitir crear JSON Schema y JSON-LD para connectar con linked data de manera automática. Copyright © 2015 Open Geospatial Consortium

Copyright © 2015 Open Geospatial Consortium Interfaces REST Durante años ha habido muchas discusiones sobre el papel de los interfaces REST en OGC. A pesar de que WMTS (i algun otro) usan interficies REST No existe una solución general No se ha incluido ninguna recomendación en OWS Common Los intentos de solucionar este asunto desde el plano conceptual han fallado Agotada esta vía, el Testbed 12 se está trabajando para generar un conjunto de recomendaciones pragmáticas para desencallar el tema. Parece que se está llegando a un cierto acuerdo. Se sugieren diversos niveles de REST Nivel 1: Reconocer los recursos Nivel 2: Uso de URLs para los recursos Nivel 3: Incluir enlaces a los recursos relacionados Copyright © 2015 Open Geospatial Consortium

Copyright © 2015 Open Geospatial Consortium Qué pasa con tanta API? En el pasado las aplicaciones web no podían conectar y definimos la idea de “interoperabilidad”. Aprendimos que debíamos usar interfaces interoperables Pero esto no es tan fácil: Debemos crear un servidor y un cliente por separado. En la práctica, si deseo incrustar un mapa en mi cliente, necesito programarme un cliente que use WMS/WMTS… … lo que requiere bastante código. Descubrimos que con el API de Google maps o de OpenLayers podíamos incrustar un mapa casi sin generar código. Esto ha conducido a una proliferación de las APIs y, a lo que es peor, a un cambio de actitud respecto a la interoperabilidad que se resume en: “Yo he definido mi API y soy interoperable. ¡Tú tienes que usar mi API!”. Y la pregunta es: ¿Y si no me da la gana? Es necesario pensar que papel deben tener las API el OGC Copyright © 2015 Open Geospatial Consortium

Cambios en la manera de trabajar El OGC está cambiando su manera de trabajar y generar documentos. En el pasado trabajábamos con Word y PDFs Después llego la twiki; más tarde rebautizada como foswiki Un entorno de páginas web en el que todo miembro del OGC puede editar de manera más o menos concurrente. Ahora llega el turno a GitHub i ASCIIdoc Los documentos se redactan en un lenguage similar a la twiki pero que permite una creación de documentos más directa. Los documentos aprobados se distribuyen en PDF y HTML Copyright © 2015 Open Geospatial Consortium