En urbiGIS estamos creando un catálogo de servicios geoespaciales de mapas, de geodatos y de localizadores. Es un propósito aparentemente similar al que tiene una Infraestructura de Datos Espaciales, pero con importantes diferencias y haré luego una breve exposición de ellas. Tras explorar miles de servidores espaciales y crear un catálogo con más de 1.600.000 geoservicios, ya tenemos una idea bastante precisa de la situación actual, de sus indudables ventajas (seríamos tontos si gastásemos el tiempo en explorar un sistema en el que no creemos) y también de sus inconvenientes (con algunas propuestas para mejorarlo).
En los últimos meses he visto algunos comentarios sobre la utilidad y actualidad de las Infraestructuras de Datos Espaciales, destaco los comentarios de Michael Gould en este video (III Seminario IDEAIS – YouTube). Michael es un experto en datos espaciales y sus opiniones representan bien la situación, claramente no está satisfecho del estado actual. Ante una realidad donde la información espacial se ha convertido en cotidiana y ubicua, Michael cree que se debe conseguir una mejor integración, casi en tiempo real, entre los ciudadanos, los gobiernos y las empresas, en un mundo lleno de sensores y sistemas automatizados y conectados, y tiene razón.
También me ha llamado la atención la presentación de Álvaro Anguix en el blog de gvSIG (Disponible la ponencia «Rompiendo las barreras ¿necesarias? para implantar con éxito Infraestructuras de Datos Espaciales» | gvSIG blog). Álvaro es General Manager de la Asociación gvSIG y un reconocido experto en software GIS libre. En esa presentación nos enseña lo sencillo que es con gvSIG saltar la brecha existente entre crear datos espaciales en una aplicación de escritorio y publicarlos en una IDE, muy bueno.
El Instituto Geográfico de España (IGN) define las IDE como «La puesta en práctica de un proyecto IDE se materializa a través de un Geoportal que ofrezca como mínimo: la visualización de los datos a través de servicios web, la búsqueda de los conjuntos de datos y servicios a través de sus metadatos y la localización en un mapa a través de un nombre geográfico. Ver por ejemplo el Geoportal de la Infraestructura de Datos Espaciales de España. **La Directiva INSPIRE2007/2/CE de 14 de marzo de 2007 establece el marco legal que regula la Infraestructura de Datos Espaciales de la Comunidad Europea dicha infraestructura se basa en las infraestructuras de información geográfica creadas por los Estados miembros. La transposición de INSPIRE al marco legal español se lleva a cabo por medio de la Ley 14/2010, de 5 de julio, sobre las infraestructuras y los servicios de información geográfica en España (LISIGE).»
Pero en la práctica las IDE/SDI han quedado exclusivamente como un servicio público, las empresas o las instituciones no gubernamentales no participan de esta iniciativa, quizá porque la misma Directiva antes citada indica que las IDE serán creadas por los Estados miembros, y porque eso también se observa de forma implícita en el documento Spatial Data Infrastructure (SDI) Manual for the Americas de la Tenth United Nations Regional Cartographic Conference for the Americas New York, 19-23, August 2013, o quizá también porque el objetivo de la IDE es aportar un Catálogo de recursos geoespaciales y este servicio no tiene un retorno económico inmediato para las empresas.
Desde mi punto de vista las IDE/SDI en este momento se enfrentan a cinco problemas:
1.- Alcance: son Catálogos públicos y parece que a ellos sólo accedan organismos o instituciones públicas, es muy raro encontrar servicios ofrecidos por empresas privadas. En este aspecto incidiré más adelante al hablar de los servicios geoespaciales ofrecidos por empresas privadas.
2.- Diversidad estructural: las IDE’s que he visto no siempre distinguen adecuadamente entre un servidor GIS y sus servicios contenidos, tienen criterios de búsqueda diferentes, interfaces diferentes (aunque GeoNetwork ha ayudado mucho a implementar IDS’s). Por todo esto los resultados finales no suelen ser congruentes entre diversas IDE’s y dificultan la experiencia de usuario.
3.- Mantenimiento: la IDE es un catálogo de servidores/servicios y se ha trabajado mucho en cómo alimentarlo y mantenerlo al día. Normalmente se arranca con un catálogo construido a mano por la entidad titular de la IDE a partir de una relación de servidores, pero mantenerlo actualizado exige recursos que no siempre están disponibles.
Solo hay dos vías para conseguirlo: la primera es que el titular del Catálogo lo alimente explorando de forma sistemática y continua el ambiente Internet y los servicios ofrecidos, y la segunda vía es que los candidatos a integrarse en el Catálogo se ocupen de presentarse ante él y aportar sus servicios o mantenerlos actualizados mediante técnicas de harvesting. Ninguna de las dos vías suele funcionar y como resultado los Catálogos se van quedando desactualizados progresivamente. Más adelante también comentaré los problemas derivados de la persistencia y administración de los servicios.
4.- Funcionalidad: los geoportales de IDE permiten realizar una búsqueda de servicios multicriterio: por la organización prestadora del servicio, por su tema o palabras clave, por el nombre del servicio, por el tipo de servicio, etc. En la mayoría de los casos permiten su visualización en un visor integrado dentro de la IDE o incluyen un link para acceder al visor propio del titular del servicio. Pero normalmente se limitan a presentar un mapa. En sus visores no es sencillo, o ni siquiera posible, la superposición de mapas de distintas fuentes. Esas utilidades quedan reservadas a las herramientas desktop del cliente que sí le permiten crear un proyecto de capas múltiples. Las IDE’s por tanto nos permiten descubrir el dato e inspeccionar si nos será útil, pero no sirven para crear un geoproyecto multicapa.
5.- Complejidad: aunque se utilicen las herramientas open existentes sigue siendo un proyecto complejo crear y mantener una IDE. Álvaro Anguix defiende la facilidad de creación de una IDE desde gvSIG, y no lo discuto. Pero el resultado, desde mi punto de vista, no es tanto una IDE, que trata de crear un Catálogo donde buscar georecursos, como un geoportal estándar donde una organización ofrece sus datos.
En resumen, si las IDE no se actualizan adecuadamente, ni cubren la totalidad de la oferta de su ámbito territorial o temático, ni facilitan la visualización y utilización de los datos y cada una funciona de forma distinta, no es de extrañar que tengan una crisis existencial.
Los geoservicios se dividen en dos clases básicas:
a) la clase de los orientados a servicios web (imagerest, featurerest, wms, wfs…) que ante una petición en la que se indica una extensión espacial suministran una imagen o un conjunto de vectores completo o teselado que la cubre
b) la clase de los orientados a fichero que devuelven un fichero espacial de tipo wkt, gml, kml o geojson representable directamente en el cliente.
Estos servicios no se distinguen de los ofrecidos por un servidor estándar que devuelve una página HTML o un documento, salvo por el formato de la petición y el tipo de elemento devuelto. En los geoservicios web es habitual que el servidor construya al vuelo la imagen o la geometría devuelta tras una consulta a un servidor espacial de datos, aunque lo habitual es que esa consulta esté cacheada para agilizar la respuesta. Si el geoservicio devuelve una imagen el cliente no tiene opción para modificar su simbología, pero si devuelve geometrías el cliente podrá aplicarles un estilo propio y utilizarlas como fuente de datos o apoyo geométrico.
Independientemente del tipo de servicio o de su formato, los servidores geoespaciales comparten los mismos problemas que los servidores estándar y además tienen algunos propios que voy a detallar:
1.- Persistencia: parece que quien publica un servidor en Internet tiene interés en que el servicio esté funcional 24/365, bien porque es un servicio público o bien porque de ello depende la rentabilidad de su empresa. Aunque este nivel no siempre es factible, los sistemas son cada día más sofisticados para qconseguirlo. A ello han contribuido mucho los servicios cloud, ya que simplifican la vida a los técnicos de sistemas evitando el mantenimiento del hardware local, además también, los sistemas redundantes y los sistemas en cluster que garantizan el mantenimiento del servicio.
Todo lo dicho no siempre es aplicable a los servicios geoespaciales, quizá porque, por ahora, parece que no tienen el mismo nivel de criticidad que otros servicios. Quitando por supuesto los servicios globales tipo Google Maps o Apple de los que dependen los sistemas de navegación de miles de millones de personas en sus smartphones. Por eso urbiGIS es un sistema cloud, porque una pequeña organización no tiene los recursos para mantener una instalación propia o su bajo nivel de uso no justifica el gasto. El caso es que el porcentaje de sistemas GIS caídos es enorme.
Algunas IDE ya proporcionan servicios de monitorización que verifican la disponibilidad de los datos, también hay empresas que ofrecen este tipo de servicios como Spatineo y desde urbiGIS estamos creando este servicio. Todo ello demuestra que la persistencia es un problema grave.
2.- Versionado: tanto los servidores Rest de Arcgis como los de Geoserver o Mapserver organizan sus servicios según el criterio establecido por su diseñador, algo completamente lógico, sin embargo cuando hay servicios sujetos a actualización periódica y se deseen conservar los servicios históricos lo lógico es que el servicio más actualizado esté indicado con una denominación similar: máxima actualidad, vigente, actual…. mientras que los servicios históricos van adquiriendo un número de versión o una fecha que identifique su posición en la serie temporal.
Pues lamentablemente esto no es habitual, cada nueva actualización lleva un nuevo nombre y sus gestores no se van a ocupar de notificar a cada usuario ese cambio. O los usuarios disponen de un servicio que explore las novedades, o dependen de que se publique en un boletín de noticias del ramo. Realmente es un problema sin solución, en urbiGIS solo lo hemos resuelto para los Inventarios, ya que su actualización mediante geotransacciones nos aseguran que la versión publicada siempre es la última y nunca cambia de nombre.
3.- Duplicidad: cuando los servicios son en realidad agrupamientos de servicios es habitual que varios grupos compartan las mismas capas, normalmente capas de referencia y tengan una o pocas capas realmente significativas o definitorias del grupo. En estos casos suele haber dos opciones, una que la llamada a cualquiera de las capas del grupo devuelva el grupo completo, este comportamiento suele ser habitual en los servidores arcgis, la otra es que la llamada a cada capa individual devuelva solo el contenido de esa capa, el grupo solo se devuelve cuando se llama al servicio agrupado.
La primera opción simplifica el manejo pero impide que las capas significativas del grupo se puedan visualizar de forma independiente, la segunda opción permite esa visualización independiente, pero supone que todas las capas de referencia de los distintos grupos están repetidas múltiples veces y falsea el tamaño del contenido real de capas del servidor. Este problema solo tiene una solución y es que las capas significativas se presenten dos veces, una de forma individual y otra de forma agrupada sin posibilidad de desglose. De esa forma el usuario puede optar por solicitar el grupo o por mostrar solo la capa significativa. En urbiGIS hemos optado por esta última solución, el único cambio es que los agrupamientos se denominan «colecciones».
4.- Rotura de la Interoperabilidad: los servicios web tienen una razón de ser primordial y es que permitan a muchos solicitar un servicio a una organización . De esa forma las actualizaciones de los datos que realice el se distribuyen de forma inmediata entre todos sus clientes. Pero en muchas ocasiones lo que se hace es descargar los datos de la organización propietaria y recortarlos o adaptarlos a las necesidades de la organización cliente, rompiendo el vínculo con los datos originales. Este es un tipo de perversión del sistema muy habitual y anula por completo una de las propiedades básicas del sistema.
Tampoco tiene solución, más allá de conseguir que los servicios remotos sean persistentes para que el cliente confíe en el servicio y de que el cliente tenga capacidad para adaptar el estilo a sus necesidades o enmascarar las porciones que no desee ofrecer en su geoportal, en este último aspecto los servicios que devuelven geometría tienen ventaja frente a los que devuelven imagen. Habría una tercera posibilidad y es que el recorte lo haga el servidor a petición del cliente, en este caso el cliente debería remitir al servidor la geometría de recorte junto con su petición. En urbiGIS estimamos que un servicio en cloud es la garantía de la persistencia y por ende del mantenimiento de la interoparabilidad.
5.- Apropiación: un caso semejante al anterior es la apropiación, un cliente redirige una capa de otra organización como si fuese suya, sin reconocer la autoría. Precisamente el objetivo de urbiGIS es garantizar la identificación del propietarios de los datos y su modo de licenciamiento.
6.- Cambio constante: no se puede evitar que el propietario de un servidor no intente mejorar su servicio de forma constante, puede que tenga que cambiar el direccionamiento, la organización interna, la denominación de los servicios o sus formatos. Pero estos cambios hacen muy complicado que sus clientes puedan mantener esos servicios referenciados, al final fomenta la rotura de la interoperabilidad por desconfiar de que el servicio original persista. Como en casos anteriores la solución es un servicio en cloud que garantice la estabilidad.
7.- Nomenclatura criptica: es habitual que los servicios, aunque residan en un servidor abierto y accesible, se hayan denominado y estructurado como si solo fuesen a ser consumidos por el geoportal de su propietario. Como éste tiene un control total de ambos lados no le importa que la capa se llame en el servidor «xxxs445_v2» y en el geoportal se llame «Parcelario», el código de su geoportal se ocupa de traducir esas claves de capa a nombres inteligibles. Pero si otro usuario intenta utilizar ese servicio tendrá muchas dificultades para saber que xxx445_v2 es en realidad la capa de Parcelario. Si el proveedor no informa de ello en los metadatos o en su web, el cliente que quiera utilizarlos tendrá que buscarse la vida inspeccionando el geoportal para realizar capa a capa esa asignación verificando las layers de las peticiones al activar cada capa.
8.- Visualización dependiente de la escala: los servidores de geodatos permiten ajustar el rango de escala donde son visibles, esta propiedad resulta muy útil cuando se quieren ofrecer mapas de diverso detalle según la escala. El ejemplo que siempre pongo es el plano de categorías de suelo de Castilla y León publicado por SiuCyL: https://urbigis.com/2aaac655-8e20-4386-a4ce-75109d5ce128.ms que solo se visualiza cuando la escala es inferior a 1.70.000. Esto puede ser un inconveniente porque para que la Comunidad de Castilla y León se vea completa en un monitor estándar hay que usar una escala aproximada de 1.800.000, por tanto hay que bajar mucho hasta que ese mapa se vea y mientras tanto el usuario recibe la impresión de que el servicio está caído. En el visor de SiuCyL esto no pasa porque las capas se van sucediendo a medida que se cambia de escala sin que el usuario tenga que activarlas y desactivarlas, la impresión del usuario es que el visor siempre está activo. En urbiGIS podemos emular ese comportamiento incluyendo las capas implicadas en una colección: https://urbigis.com/54f2dd3a-56e7-4f9e-adc0-08e26125f9f0.ms . La colección intenta presentar todas sus capas pero como tienen asignadas sus escalas por el servidor las iremos viendo a medidas que hacemos zoom.
Ya no basta con servir datos espaciales como imagen o como vector, en otras entradas de este blog he comentado como los componentes del territorio adquieren identidad y empiezan a disponer de agentes inteligentes propios que les permiten detectar cambios y reaccionar, incluso de devolver una imagen real y actual de sí mismos. Nuestro objetivo es disponer de servicios capaces de interactuar con esos agentes. Serán servicios SCADA de quinta generación capaces de producir geoinformación.
Eso significa que nuestro mapa de edificación no se construye como una imagen o una geometría desde un servidor espacial de datos que contiene las geometrías y propiedades de cada edificio, sino que se construye preguntando a cada edificio cómo es su envolvente o la distribución de sus componentes interiores o la temperatura interior o el rendimiento en este momento de sus sistemas fotovoltaicos. Es decir mediante miles de microservicios que sirven para construir al vuelo una imagen dinámica de conjunto o un cuadro de mando. No puede ser que sigamos actualizando el mapa de la edificación por fotointerpretación, incluso ni siquiera por geotransacciones desde los expedientes de licencias, si la ciudad es inteligente lo es porque sus componentes son inteligentes, dejemos las demás técnicas para los componentes tontos.
También significa que nuestros mapas dejan de representar solamente objetos estáticos, si los componentes territoriales se mueven y están autorizados a enviar su posición nuestro mapa será capaz de seguirlos y representarlos.
Decía Michael Gould en la presentación antes citada que se echa en falta un «Google de recursos geoespaciales», porque las IDE al uso se autolimitan a un ámbito geográfico, a una titularidad pública o a temáticas concretas. Precisamente por eso urbiGIS se concibe como un Catálogo global de recursos geoespaciales que intenta resolver los problemas de las IDE actuales y ofrecer los recursos para que buscar, crear, reutilizar y publicar datos geoespaciales sea sencillo e inmediato. Sabiendo que estamos a un paso de una revolución total en el modo en que concebimos la información espacial, en un marco no muy lejano donde las IDE y los actuales geoservicios estarán obsoletos.
Ignacio Arnaiz Eguren
Director
