urbiGIS | Blog

Propuesta para un Sistema de Coordinación de la Información Geográfica

Tue, 13 Jan 2026 00:00:00 GMT

Hace poco la Comunidad de Madrid (España) lanzó consulta pública para la definición de un «Sistema de Coordinación de la Información Geográfica de la Comunidad de Madrid«. He escrito una propuesta donde compilo diversas entradas de este blog y que os incluyo:

1 Introducción

Conocemos el territorio gracias a procedimientos basados en la observación, mediante topografía o por fotointerpretación, con grandes y caros recursos con los que solo conseguimos obtener una imagen estática de un sistema que está en constante transformación. También lo conocemos, lo vivimos, mediante la experiencia personal.

Nuestros sentidos y memoria nos proporcionan un sistema potente y sutil de conocimiento y análisis del medio, pero la información resultante está sujeta a limitaciones de tiempo, alcance y transmisividad. Ninguno de los dos procedimientos sirve para planificar, administrar, utilizar o aplicar tecnología territorial con eficiencia.

Por eso hay que construir nuevos procedimientos basados en las TIC y la Colaboración. Procedimientos capaces de seguir su ritmo de cambio, que aporten la capacidad de interpretación humana del medio, y que abarquen desde la planificación urbana, hasta la descripción física y funcional del último elemento material o inmaterial y de sus interrelaciones. La Colaboración será abierta cuando ayuda a las instituciones, empresas, asociaciones o ciudadanos a compartir su información espacial sobre cualquier aspecto territorial. Y será Colaboración reglada cuando el propietario de la información exija a quienes efectúan transformaciones territoriales, que sus proyectos y operaciones de cambio incluyan una porción digital, normalizada y transaccional, apta para para mantener una imagen virtual del territorio construida sistemáticamente.

Pero la colaboración por sí misma no es suficiente para construir información útil y veraz. Es preciso encauzarla, construyendo circuitos virtuosos de datos que aseguren la sincronización entre el mundo real y su representación en un sistema de información espacial.

El territorio y la ciudad son los medios donde la actividad humana se materializa. Forma una amalgama de objetos, sistemas y funciones, un ecosistema dinámico. Una enorme máquina que debe resolver las necesidades actuales y futuras de una sociedad caracterizada por su voluntad de crecimiento y mejora constante.

Las Administraciones Públicas, responsables de regular y fomentar ese proceso de cambio y adaptación constantes, necesitan conocer y comprender el territorio objeto de su competencia para su regulación y control: prever las necesidades futuras, planificar sus transformaciones, evaluar su factibilidad y asegurar la sostenibilidad de la capacidad territorial. Todo ello en un marco de innovación tecnológica, de competitividad interurbana, de incremento de la participación social y de intenso control ciudadano de la acción pública.

Por eso las Administraciones tienen una necesidad urgente de construir sistemas que describan fielmente esa máquina urbana, porque actualmente la información territorial a disposición de los municipios y entidades supramunicipales está disgregada, es fragmentaria y poco fiable:

Esta disgregada porque la estructura organizativa y competencial de las administraciones públicas es muy vertical y genera compartimentos estancos.

Es fragmentaria porque no hay una estrategia sostenida de captura de datos que asegure un barrido completo del territorio.
Y es poco fiable porque no existen mecanismos sencillos y baratos para mantenerla al día.

Hay un enorme reto para construir un sistema público de información horizontal que sirva a todos. En el que todos puedan colaborar. Que se mantenga al día y que no suponga una inversión económica insostenible. Un sistema que sirva a todos los actores urbanos:

A los planificadores para obtener una visión actual, completa e inmediata de la ciudad, como base de conocimiento imprescindible para formular los planes.

A los gestores de la ciudad para disponer de una visión amplia de los objetos y relaciones existentes y del impacto de los cambios. Dándoles la posibilidad de gestionar eficientemente los nuevos servicios de gestión urbana basados en la inteligencia distribuida y la robotización de los sistemas urbanos.
A los desarrolladores y promotores para que puedan evaluar sin trabas sus oportunidades de actuación. Reduciendo el riesgo por falta de información actualizada.
A los responsables políticos para que dispongan de indicadores reales, producto de servicios de datos dinámicos. Que aprovechen eficientemente el sustrato de datos del sistema.
A los ciudadanos y visitantes, porque están asumiendo nuevos modos de interactuar con el territorio y sus componentes, de la mano de tecnologías emergentes y de sus dispositivos móviles. Nuevos modos que deben apoyarse en servicios de ubicación extendidos.

Mediante estos nuevos procedimientos y la tecnología interoperable es posible conseguir un objetivo disruptivo que supera el concepto de IDE: el Inventario territorial.

2 Nuestra experiencia

1990 – BADUR Base de Datos de Urbanismo para la Gerencia Municipal de Urbanismo de Madrid con componente GIS
1997 – Proyecto workflow para la gestión de licencias en la Gerencia Municipal de Urbanismo de Madrid
1997 – Inventario de GIS en la Comunidad de Madrid. Por encargo de ICM se contrató a Docutex para elaborar un Inventario de GIS de la Comunidad de Madrid, en el participamos como subcontratista de Docutex (se adjuntan sus documentos de resultado). Aunque tecnológicamente está obsoleto contiene muchas ideas utilizables.
2005 – GeoMadrid. Con el impulso de Maximino Galán se realizaron nuevos vuelos y una nueva cartografía sobre un modelo orientado a objetos y un Registro de Planeamiento normalizado transaccional de toda la Comunidad del que fui directamente responsable y creador.
2010 – Urbanismo en Red. El organismo público Red.es propuso e implantó en más de 200 municipios un Registro de Planeamiento transaccional cuyo origen es el de GeoMadrid.
2020 – Sistema urbiGIS: una plataforma para la creación, almacenamiento y publicación de información geográfica en cloud.

3 Limitaciones del concepto de IDE

Actualmente la Comunidad de Madrid ya dispone de una Infraestructura de Datos Espaciales que ofrece más de 1300 conjuntos de datos y servicios web ordenados por temas y tipo de recursos, según un modelo estándar.

En los últimos años 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.

Por su parte el https://www.ign.es/web/resources/docs/IGNCnig/IDE-Teoria.pdfInstituto 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:

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. Además, incluso hay criterios diferentes en cuanto al contenido, la IDEE intenta abarcar todos los servicios nacionales, autonómicos y locales, aunque no lo consiga. La IDE de la Comunidad de Madrid aparentemente solo contiene servicios proporcionados por la Comunidad, las escasas IDEs locales están orientadas a los datos abiertos municipales.

Diversidad estructural: las IDEs 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 IDEs). Por todo esto los resultados finales no suelen ser congruentes entre diversas IDEs y dificultan la experiencia de usuario.
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.

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 enlace para acceder al visor propio del titular del servicio. Pero normalmente se limitan a presentar un solo 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 multicapa. Las IDEs por tanto, nos permiten descubrir el dato e inspeccionar si nos será útil, pero no sirven para crear un geoproyecto.

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 georrecursos, como un geoportal estándar donde una organización ofrece sus datos.

En resumen, si las IDEs 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.

Por tanto, debe existir una normativa que garantice permita una gestión adecuada de la IDE, de la información geográfica y de la actividad cartográfica como herramientas indispensables para ejecutar las políticas sectoriales sobre el territorio y que resuelva los problemas de alcance, mantenimiento colaborativo, funcionalidad y complejidad antes comentados.

4 Los modos de adquisición de datos

4.1 Por observación

4.1.1 Medios tradicionales

Comprendemos, planificamos, navegamos o analizamos nuestro mundo y nuestras ciudades, con mapas construidos mediante técnicas de observación. Se mide, se dibuja y se representa lo que vemos, en directo o por telemetría. Construimos una imagen de un mundo que tiene muchos aspectos, cada uno con distintas velocidades de cambio, desde aspectos tan estáticos como los geomorfológicos, a algo más dinámicos como la estructura de los ecosistemas, y hasta los muy dinámicos como el clima, la estructura urbana o el tráfico de nuestros territorios.

La estructura de nuestras ciudades es el resultado de las actividades humanas de análisis y planificación, de construcción y de uso. Trabajando de forma incansable, bien dentro de la legalidad o por procedimientos informales. Actividades que llevan a cabo los promotores y agentes inmobiliarios, los urbanistas, los arquitectos, los ingenieros, los propios ciudadanos, las instituciones públicas o las privadas. Remodelando el territorio para responder a la demanda urbana y formando un mercado que representa un porcentaje muy significativo del PIB nacional.

Por otro lado, esos mismos actores, junto con las organizaciones gestoras de las ciudades y sus departamentos técnicos dedicados al urbanismo, el catastro, la seguridad, la protección civil, las infraestructuras, la movilidad o el medio ambiente entre otros, deben adoptar constantemente decisiones territoriales. Siempre es conveniente que lo hagan con información geográfica cierta y actualizada de la conformación del territorio, aunque no sea imprescindible, pero sin ella se incrementa el riesgo de tomar decisiones inadecuadas.

Actualmente, para conseguir información territorial, los gestores territoriales y las empresas consumen enormes recursos en departamentos cartográficos que intentan proporcionarles datos geográficos observados, siempre en constante actualización, pero siempre un paso por detrás de la realidad, un paso tanto más largo, cuantos menores sean los recursos técnicos y económicos de que disponga el gestor. A veces ese paso es tan largo que la información disponible deja de ser útil, los procesos de cambio la han mutado en obsoleta y fiar decisiones en ella será incluso peligroso. La transición desde los sistemas de papel a los digitales ha facilitado mucho el trabajo, incrementando la usabilidad, la precisión y la calidad final del resultado, pero no ha alterado de forma sustancial la metodología de trabajo ni ha aportado productos nuevos.

Hasta ahora estos sistemas cartográficos han servido para diseñar la ciudad y controlar sus aspectos básicos, porque no había otra solución. Pero la situación ha mejorado con la aparición de nuevos sistemas de información geográfica baratos y eficientes, de nuevos estándares GIS abiertos, de la universalización del uso de los sistemas GPS y con la demostración de las enormes posibilidades de difusión de información geográfica por Internet. Los nuevos sistemas de información territorial han salido del entorno de las oficinas técnicas, y de su alcance limitado a la producción de proyectos, para convertirse en una herramienta de uso generalizado, a la que se demandan prestaciones y contenidos cada día más sofisticados, tanto desde las instituciones, como desde el mundo empresarial o los ciudadanos.

Esta presión está provocando una crisis sobre los modos de adquisición de la información territorial, sobre los sistemas de tratamiento y verificación de los datos, sobre los sistemas de almacenamiento y, muy especialmente, sobre los sistemas de publicación y acceso a la información. Una crisis que se enfoca a nivel institucional mediante el desarrollo de Infraestructuras de Datos Espaciales; un gran paso adelante para compartir información geográfica, pero que debe aún evolucionar hacia un sistema de sistemas que garantice el adecuado nivel de integración y actualización y que asegure su utilidad pública y empresarial en competencia con las plataformas comerciales de mapas tales como Google Maps o Bing Maps, plataformas que están consiguiendo su objetivo de producir una versión virtual del mundo real accesible desde internet, extraordinariamente útil como soporte para decisiones de negocio.

4.1.2 Medios nuevos: la IA

Sobre los productos de la observación tan abundantes a través de satélites, vuelos tradicionales y drones se están haciendo enormes avances para extraer y analizar información mediate el tratamiento de imágenes por Inteligencia Artificial.

La IA demuestra una increíble capacidad para detectar patrones y extrapolar objetos en dos y tres dimensiones. Esto no solo tiene importancia para inventariar los objetos del territorio sino para detectar cambios. Los satélites proporcionan imágenes de un territorio con horas o pocos días de diferencia por lo que están siendo fundamentales para detectar los efectos de desastres naturales, guerras o simplemente para el seguimiento y control de infracciones.

4.2 Por colaboración

A ese escenario de adquisición de datos basado en la observación, vamos a llamarle “tradicional”, se ha incorporado un nuevo elemento de importancia vital y que es producto exclusivo de las TIC: la** colaboración**.

Sin la universalización del acceso a Internet la Colaboración nunca se podría haber planteado ni mucho menos extendido. Es notable destacar que toda la información sobre la estructura territorial existente en sistemas globales como Open Street Map, o gran parte de la que proporciona Google Maps, ya no proviene de empresas cartográficas, sino de la aportación desinteresada y voluntaria (o involuntaria) de cientos de miles de personas e instituciones que observan el territorio y aportan datos.

Cada vehículo que transita por el mundo con una aplicación de navegación abierta con acceso a Internet en su interior, está contribuyendo a crear y mantener la red viaria mundial y, además, está proporcionando la información suficiente para que los sistemas globales de navegación conozcan la situación del tráfico, aconsejen rutas óptimas e informen de los tiempos estimados de tránsito hasta el destino, haciendo casi inútiles las enormes inversiones municipales realizadas para el control del tráfico.

Este éxito se ha logrado multiplicando exponencialmente el número de sensores, porque cada colaborador pasa a ser un sensor inteligente, produciendo un efecto multiplicativo sobre la información disponible que hace rápidamente obsoleta cualquier otra técnica de recopilar y distribuir información masiva. En Internet se ha pasado en muy poco tiempo, de compartir únicamente páginas de información textual o infográfica a compartir también información geográfica, con un valor económico y funcional añadido de enorme importancia.

4.2.1 La colaboración abierta

La Colaboración no solo incrementa el número de sensores de observación, también es capaz de crear nueva información que va más allá de la obtenida por la mera observación. La “cartografía de lo visible” pasa a ser la “cartografía de lo que existe”, donde cabe de todo: la cartografía de lo imaginado, de lo planificado, de los derechos y los deberes, de lo funcional, de lo subterráneo y aéreo, de lo cultural, de las ideas y de los movimientos sociales.

La potencia de la Colaboración está revolucionando la información geográfica disponible, pero su efectividad solo se incrementará si se establecen algunas condiciones:

Aportar información espacial debe ser sencillo y gratuito. No siempre ha sido fácil crear información espacial. La topografía y la cartografía han sido nichos de especialistas que utilizan maquinaria y técnicas caras y sofisticadas. Pero un GPS montado en dispositivos de uso común, nos permite geoposicionar datos con precisiones que en poco tiempo serán centimétricas. Dibujar sobre un mapa geometrías sencillas ya es posible y práctico, lo están demostrando plataformas como Carto, Mapbox, MangoMap o urbiGIS que ayudan a usuarios sin conocimientos de topografía o de GIS a crear sofisticados mapas y publicarlos en Internet.

Obtener información espacial también debe ser sencillo y gratuito. Internet ha demostrado que el acceso a la información gratuita es un paso que no tiene vuelta atrás, por tanto, la información espacial también debe ser gratuita. Ya se ha pasado aquel momento en el que los organismos cartográficos públicos intentaban poner tarifas de venta de sus datos como forma de financiación de los elevados costes de creación de mapas. (aunque aún existeninstituciones irreductibles que no han salido de su obcecación)
Los modelos de datos deben ser abiertos. Open Street Map o Google, en su parte colaborativa, han tenido un enorme éxito, pero tienen modelos de datos cerrados, no es posible aportar información que no encaje en su estructura. Pero cada ciudadano, empresa o institución dispuestos a aportar información puede tener una forma de expresión, un idioma o un interés distinto que necesitan un cauce propio de expresión. Deben tener la facultad de crear sus propios modelos de datos. Esta falta de estructura genera dispersión y puede dificultar la agregación o el análisis masivo, pero enriquece el contenido. Dejemos a los sistemas de localización inteligente que se ocupen de normalizar y extraer la información agregada.
La información aportada debe estar disponible como servicios WEB abiertos. El Open Geospatial Consortium (OGC) fue creado en 1994 y agrupa (en febrero de 2009) a 372 organizaciones públicas y privadas que han creado los estándares internacionales para distribuir información espacial (Web Map Services y Web Feature Services, entre otros). Con estos estándares es posible compartir datos espaciales abiertos en Internet con pocos recursos y mediante sistemas gratuitos. También ha quedado atrás el momento en que para crear y publicar información espacial era preciso pagar enormes cantidades de dinero en licencias y royalties por software propietario.
Los aportantes de datos espaciales deben disponer de plataformas gratuitas para crear y publicar sus datos. Las redes sociales como YouTube, Instagram o Facebook nos han demostrado la potencia que proporciona Internet para distribuir en pocos instantes información fotográfica o de vídeo de forma global. Sin duda tienen peligros, pero nadie discute su enorme utilidad. Producir vídeos no era una tarea sencilla hasta que los smartphones y los programas gratuitos de edición la han simplificado, hasta el punto de que, con un mínimo entrenamiento, cualquier persona es capaz de producirlos y distribuirlos. Las plataformas de mapas deben seguir esa misma senda, poniendo a disposición de todas herramientas sencillas de producción y publicación de mapas y datos espaciales. Por ejemplo, en eso está trabajando la plataforma urbiGIS,dando a sus usuarios la posibilidad de crear servicios de datos y mapas OGC de forma gratuita y de acceso universal.

Estos nuevos sistemas colaborativos serán de extrema utilidad en muy diversos ámbitos: para los municipios y regiones que no disponen de los medios para publicar sus mapas de utilidad pública, para las organizaciones sin ánimo de lucro que publican el alcance de su actividad, para las instituciones de investigación y docencia que podrán publicar los mapas de sus resultados, para las empresas y organizaciones privadas que publican su estructura comercial y su oferta, para las asociaciones ciudadanas y los propios ciudadanos que podrán expresar sus inquietudes, demandas, denuncias o actividades en forma de mapa.

En el caso concreto de los municipios y demás entes administrativos territoriales, la Colaboración abierta será vital para aunar el máximo de información disponible sobre su ámbito de actuación, de forma que incremente su visibilidad en Internet, como vía para atraer visitantes o inversiones y para facilitar a sus ciudadanos el conocimiento y uso de su ciudad y de su oferta. Aportando datos en campos tan diversos como el callejero, la situación del tráfico, los aparcamientos, los transportes públicos, los recursos turísticos, culturales, de ocio o de deporte, la actividad cívica, la oferta comercial y hotelera, la oferta de suelo industrial, residencial o terciario, los equipamientos, la oferta educativa, los servicios de seguridad, la actividad municipal, el programa político, los resultados electorales, la demografía, la ecología urbana o la agenda pública, por citar solamente algunos.

La Colaboración abierta no está sujeta a supervisión, más allá de las verificaciones que puedan realizar las plataformas de publicación para evitar información inadecuada, algo que en el mundo de los mapas es más complicado que en el mundo de los vídeos, pero no es imposible, porque puede producirse la publicación de lugares protegidos o de seguridad nacional, de datos con fines terroristas, de datos inconvenientes para menores de edad o de datos simplemente erróneos con buena o con mala fe. Esta falta de supervisión puede afectar a la fiabilidad de los datos y por eso los usuarios deberán asumir que la fiabilidad del dato estará derivada de la fiabilidad de la fuente.

La Wikipedia nos ha demostrado que los procesos colaborativos de depuración funcionan, pues vamos a usarlos también para los datos espaciales. Serán los propios usuarios quienes valoren la calidad y utilidad de cada mapa y de cada dato mediante sus comentarios, votaciones o incluso enmiendas. Al final la Colaboración abierta producirá un universo de datos autorregulado, aunque siempre será más fiable la información proporcionada por un organismo público o una organización sin ánimo de lucro, que la proporcionada por una empresa o un ciudadano particular.

En este momento ya existen millones de mapas, producto de miles de organizaciones, disponibles en Internet mediante servicios OGC. Muchos de ellos ya pueden ser consultados mediante los visualizadores de mapas propios de cada organización o mediante catálogos globales de mapas como urbiGIS.

4.2.2 La colaboración reglada

En ese escenario que proporciona la Colaboración abierta, de abundante información, aunque dispersa y no estructurada, el gestor territorial o una organización privada pueden tener dificultades para obtener exactamente el dato que necesita para tomar decisiones, por eso es preciso habilitar otras formas de Colaboración, que aprovechen su potencia para construir información estructurada, nuevas formas que pasan por cumplir las siguientes condiciones:

La Colaboración reglada será el producto de un Acuerdo, público-privado, público-público o privado-privado, entre los actores y agentes que transforman los datos espaciales y las instituciones o empresas competentes para su gestión o propietarias de los datos finales.

El Acuerdo se adopta de forma explícita y obliga a ambas partes a contribuir en el sistema y ajustarse a sus reglas de funcionamiento. Por tanto, es una Colaboración Obligada.
En virtud del Acuerdo todo proyecto o intención de transformación de los datos espaciales tiene la obligación de realizar una descripción digital normalizada de los elementos que aporta o modifica.
Asimismo, todo proyecto debe establecer, de forma estricta, las operaciones que efectúa o pretende efectuar sobre los elementos del sistema, de forma que un proceso automático pueda ejecutarlas, en el momento en que se autoricen, sobre la versión virtual del territorio.
Los proyectos de cambio pueden afectar a elementos de todo tipo: ámbitos de planificación, derechos sobre el suelo o las construcciones, edificios y construcciones de todo tipo, elementos de urbanización, infraestructura y redes de transporte, elementos de mobiliario urbano, obligaciones de conservación o mantenimiento, activos inmobiliarios, etc… Incluidas las relaciones de todo tipo existentes entre ellos.

Sobre estas bases, el territorio se representa mediante un correlato virtual, un Inventario o un conjunto de Inventarios asociados a territorios, que son propiedad de una institución, una empresa, una asociación o un ciudadano, donde las operaciones de entrada y salida de elementos se efectúan mediante geotransacciones contenidas en proyectos y operaciones de cambio, y que pueden ser comandadas desde los procedimientos administrativos ya existentes de autorización y control, cuando el propietario es una institución pública.

Por otra parte, la Administración Pública, como ente regulador, utiliza cuatro herramientas de control:

La planificación para conseguir modelos urbanos eficientes y sostenibles económica y medioambientalmente.

La autorización previa al cambio verifica que las propuestas de cambio urbano se ajustan a la planificación y a unas condiciones técnicas mínimas.
La inspección del cambio se encarga de verificar que las piezas de la ciudad se están utilizando correctamente.
Y la asignación final de derechos y obligaciones es fundamental para que cada actor ejecute correctamente su papel en esa máquina urbana.

En definitiva, no es más que aplicar al Inventario territorial las mismas técnicas y procedimientos que las empresas vienen aplicando, desde hace muchos años, para mantener sus Inventarios de materias primas o de productos terminados, aunque, en este caso, las empresas son los organismos gestores de un territorio, los proveedores son los agentes transformadores del territorio y los clientes podemos ser todos.

La dinámica urbana de cambio constante se formaliza mediante documentos descriptivos y se ejecuta por agentes urbanos:

La descripción del cambio se conforma mediante un documento que define las operaciones que se pretenden realizar sobre la ciudad. Las piezas obsoletas que se quieren eliminar. Las nuevas piezas que se aportan a la ciudad o las piezas que cambian su forma o propiedades.

Los documentos de cambio (planes, proyectos, decretos, contratos…) son redactados por técnicos urbanos especializados y tienen una doble utilidad: sirven para que los responsables públicos puedan evaluar su conveniencia y autorizarlos o rechazarlos, y también sirven a sus ejecutores como guía para la realización efectiva del cambio sobre el territorio.
El cambio urbano está conducido por cuatro tipos de actor urbano: 1) por el promotor del cambio, normalmente un desarrollador urbano, un ciudadano o la propia administración pública; 2) por el técnico urbano: un arquitecto, un ingeniero o un abogado que redacta el documento de cambio; 3) por el funcionario urbano que desde la administración pública verifica su idoneidad; y 4) por los ejecutores urbanos: el constructor que actúa sobre los objetos físicos, el notario o abogado que actúa sobre los objetos funcionales, o el prestador de servicios urbanos que asegura que una pieza preste correctamente la función para la que está diseñada.

Todo ello quiere decir que la construcción y el mantenimiento de la ciudad ya son en este momento procesos colaborativos. Procesos que han tardado siglos en formalizarse y que funcionan de forma similar en todas las ciudades modernas. Con los matices que imponen cada cultura y los modelos jurídicos locales.

Si el cambio urbano ya es un proceso colaborativo (sustentado en papel), nuestra propuesta es aprovecharlo para que no solo sirva para construir la ciudad real, sino que sirva también, en paralelo, para construir la ciudad virtual. Para ello se precisan dos innovaciones en este proceso ya existente:

Sistematizar los documentos de cambio: actualmente los documentos de cambio urbano son redactados utilizando herramientas informáticas sofisticadas (procesadores de texto, base de datos, sistemas CAD/GIS/BIM) que resultan en un documento impreso en papel. Documento que en ocasiones se redigitaliza para servir como fuente de datos de los sistemas urbanos. Un proceso esquizofrénico y absurdo que debe ser reconducido mediante la sistematización: el documento de cambio debe pasar a ser una transacción digital que defina los objetos urbanos, sus propiedades, relaciones y operaciones asociadas. Un documento escrito en un lenguaje estricto que pueda ser utilizado por un ejecutor transaccional automatizado, capaz de mantener actualizado un Inventario de objetos urbanos.

Capacitar a los actores urbanos y proporcionarles las herramientas necesarias para intervenir en ese proceso cada uno con su papel correspondiente: de redacción de documentos de cambio, de verificación y de inspección, o de consulta.

Por ahora, salvo lo planteado por plataformas como urbiGIS, no existen muchos ejemplos de Colaboración reglada por diversas razones:

Porque la información es poder y en muchas ocasiones no conviene compartir información que facilite una oportunidad política o comercial a la competencia.

Porque no es sencillo modificar el comportamiento del conjunto de profesionales y actores que participan en la transformación territorial, para que colaboren desinteresadamente en aportar información, y las estrategias de obligación, emanadas desde los entes administrativos, no son políticamente rentables. En el mundo empresarial la implantación de los ERP ha sido posible gracias a que el ejercicio de la autoridad es más sencillo y a que el consejo de administración no cambia cada dos o cuatro años, con la pretensión de cambiar el modelo productivo de la empresa.
Porque las propias administraciones públicas no están preparadas para liderar la Colaboración público-privada y recoger eficazmente sus ventajas.
Porque no se han establecido los estándares industriales, terminológicos, de modelos de datos, de procedimientos y funciones que faciliten la integración y compartición de datos.

4.2.3 La colaboración M2M

Estamos llegando a un escenario, donde las comunicaciones entre personas serán solo una parte minoritaria del tráfico de Internet, la mayor parte estará ocupada por tráfico de datos entre máquinas (M2M). Pero el término máquina parece que limita los interlocutores a ordenadores, aunque efectivamente al final será entre ellos, pero serán ordenadores que representan a personas y a objetos del mundo mediante agentes inteligentes capaces de proporcionar una descripción de sí mismos y de su estado:

Nuestro smartphone o nuestros implantes nos proporcionarán una interfaz de conectividad M2M para el acceso a una realidad extendida, en la que nuestros interlocutores no solo serán personas, sino también agentes inteligentes asociados a objetos urbanos. Nos proponen escenarios donde los edificios, las aceras, los pasos de peatones, las señales o los vehículos pueden establecer una conversación con nosotros, por un medio adaptado a las condiciones sensoriales o mentales de cada persona.

Habrá un despliegue extenso de agentes inteligentes, proporcionando un ecosistema digital inmersivo, que nos ayudará incrementar la eficacia de nuestras ciudades, a reducir al máximo su huella ecológica y a proporcionarnos un nuevo nivel de comprensión y uso del entorno urbano:

Para controlar nuestras viviendas, oficinas o locales, las naves industriales y optimizar su uso y funcionalidad.

Para gestionar las infraestructuras de agua, saneamiento, electricidad o datos, los sistemas urbanos de mantenimiento, de control del tráfico o de limpieza, el mobiliario urbano.
Para ayudar a la conducción de los vehículos públicos o privados mediante autómatas
Para que los agentes de control de tráfico puedan adaptar constantemente la configuración de la infraestructura viaria a las necesidades de cada momento.
Se establecerá un dialogo entre elementos urbanos, que ayudará a resolver la gestión de la movilidad, la eficiencia energética, la seguridad de las propiedades y de las personas, etc. Aún no tenemos una idea real de hasta dónde puede llegar la intervención de la inteligencia distribuida en el funcionamiento urbano.

La Colaboración M2M cerrará un proceso, que se inició con la observación personal, siguió con la teledetección y se amplió con la Colaboración abierta y reglada. Una nueva forma de Colaboración donde las cosas que forman el mundo y las relacionas que las conectan, serán proporcionada por ellas mismas, porque tendrán la inteligencia suficiente para autodescribirse y para interactuar con las personas o con las demás cosas que las rodean.

5 Interoperabilidad: el Inventario territorial

5.1 Marco

De los nuevos modos de obtener y compartir datos nace un paradigma disruptor: el Inventario territorial, que adquiere un protagonismo central como fuente de datos para quienes actúan sobre el territorio y como pasarela o enlace entre los objetos que forman el territorio y los usuarios del sistema de información.

En la entrada del blog de Ministerio para la Transformación Digital y de la Función Pública titulada “Interoperabilidad de los datos geoespaciales en tiempo real: cómo los estándares OGC permiten intercambiar datos en tiempo real de sensores urbanos, movilidad o clima” aparte de recomendaciones fundamentales como incorporar la dimensión temporal o fomentar un ecosistema de reutilización basado en flujos continuos de datos interoperables, propone un marco de interoperabilidad que normalice la descripción de los fenómenos observados, la estructura de las series temporales y las interfaces de acceso en un ambiente de heterogeneidad tecnológica.

Para conseguirlo propone utilizar los estándares abiertos del Open Geospatial Consortium (OGC) que “Definen cómo representar observaciones, entidades dinámicas, coberturas multitemporales o sistemas de sensores; establecen API basadas en principios web que facilitan la consulta de datos abiertos; y permiten que plataformas distintas intercambien información sin necesidad de integraciones específicas. Su adopción reduce la fragmentación tecnológica, mejora la coherencia entre fuentes y favorece la creación de servicios públicos basados en datos actualizados.”

Y ese blog aporta unas condiciones de interoperabilidad de datos dinámicos que por su importancia reflejo íntegramente:

*Las administraciones públicas gestionan hoy datos generados por sensores de distinto tipo, plataformas heterogéneas, proveedores diferentes y sistemas que evolucionan de forma independiente. La publicación de datos geoespaciales en tiempo real exige una interoperabilidad que permita integrar, procesar y reutilizar información procedente de múltiples fuentes. Esta diversidad provoca inconsistencias en formatos, estructuras, vocabularios y protocolos, lo que dificulta la apertura del dato y su reutilización por terceros. Veamos qué aspectos de la interoperabilidad están afectados: *

La interoperabilidad técnica: se refiere a la capacidad de los sistemas para intercambiar datos mediante interfaces, formatos y modelos compatibles. En los datos en tiempo real, este intercambio requiere mecanismos que permitan consultas rápidas, actualizaciones frecuentes y estructuras de datos estables. Sin estos elementos, cada flujo dependería de integraciones ad hoc, aumentando la complejidad y reduciendo la capacidad de reutilización.
*La interoperabilidad semántica: los datos dinámicos describen fenómenos que cambian en periodos cortos —niveles de tráfico, parámetros meteorológicos, caudales, emisiones atmosféricas— y deben interpretarse de forma coherente. Esto implica contar con modelos de observación, *vocabulariosy definiciones comunes que permitan a aplicaciones distintas entender el significado de cada medición y sus unidades, condiciones de captura o restricciones. Sin esta capa semántica, la apertura de datos en tiempo real genera ambigüedad y limita su integración con datos procedentes de otros dominios.
La interoperabilidad estructural: los flujos de datos en tiempo real tienden a ser continuos y voluminosos, lo que hace necesario representarlos como series temporales o conjuntos de observaciones con atributos consistentes. La ausencia de estructuras normalizadas complica la publicación de datos completos, fragmenta la información e impide consultas eficientes. Para proporcionar acceso abierto a estos datos, es necesario adoptar modelos que representen adecuadamente la relación entre fenómeno observado, momento de la observación, geometría asociada y condiciones de medición.
*La interoperabilidad en el acceso vía API: constituye una condición esencial para los datos abiertos. Las API deben ser estables, documentadas y basadas en especificaciones públicas que permitan consultas reproducibles. En el caso de datos dinámicos, esta capa garantiza que los flujos puedan ser consumidos por aplicaciones externas, plataformas de análisis, herramientas cartográficas o sistemas de monitorización que operan en contextos distintos al que genera el dato. Sin API interoperables, el dato en tiempo real queda limitado a usos internos. *

*En conjunto, estos niveles de interoperabilidad determinan si los datos geoespaciales dinámicos pueden publicarse como datos abiertos sin generar barreras técnicas. *

5.2 geoObjetos

El Inventario territorial pasar a ser un repositorio gemelo del territorio real, mantenido colaborativamente mediante técnicas de interoperabilidad por todos los que controlan competencialmente el territorio, por los que proponen actuaciones y por los actúan sobre él. Estará alojado en un cloud público en el que los geoObjetos contenidos cumplen las siguientes condiciones:

A todos ellos los denominamos geoObjetos. Son entidades que se caracterizan por las siguientes propiedades:

Un geoObjeto es cualquier elemento que está situado en un momento dado sobre un determinado territorio y que ocupa un espacio propio, tanto da que sea estático como móvil, material o inmaterial. Un espacio adscrito al geoObjeto en virtud de una asignación jurídica, administrativa o funcional de forma explícita y pública. Su ubicación está consignada en todo momento en un Servicio de Ubicación administrado por el gestor territorial competente ante el que el geoObjeto se presenta mediante con un identificador convenido: un certificado electrónico, un UUID, una dirección MAC, una IP fija… Todos los elementos gestionados por los Inventarios disponen de ese identificador y por tanto pueden ser presentados al Servicio de Ubicación.

Una vez presentado al Servicio de Ubicación, el geoObjeto le informa en todo momento de cualquier cambio en su posición o propiedades. Por tanto, aunque el Inventario proporciona informaciones sobre las características y contenido de todos sus elementos aportadas por los Documentos de Cambio que los crearon, el geoObjeto adquiere una nueva dimensión: pasa a ser un objeto capaz de proporcionar información propia determinada por su propietario como: información producida mediante colaboración abierta, hiperenlaces a sitios web relacionados con el elemento, datos de realidad aumentada que permiten la navegación real o ficticia por su interior, datos de aspecto exterior o volumetría actualizados o datos definidos ad hoc y para cada momento por su propietario, en base a su interés comercial, turístico, cultural, social, de seguridad o de cualquier otro tipo.
La inserción y extracción de un geoObjeto del ámbito espacial de territorio controlado por el Servicio de Ubicación determina operaciones de bienvenida y despido que mantienen actualizada la composición de geoObjetos existente en ese ámbito en cada momento.
Todo geoObjeto tiene un propietario, una persona física o jurídica que ejerce un derecho real sobre el objeto, y que lo liga unívocamente al geoObjeto.
Todo geoObjeto debe ser capaz de autodescribirse ante el Servicio de Ubicación. Su descripción puede ser tan sencilla como un punto en el espacio definido únicamente por sus coordenadas, hasta complejos objetos tridimensionales en formatos de realidad virtual. Su descripción estará determinada por su propietario, con unas características mínimas establecidas por el Servicio de Ubicación. La descripción incluirá elementos de realidad aumentada, enlaces a otros sitios o servicios propios definidos por el propietario. Por tanto, cada geoObjeto funciona como un portal de contenidos definido por su propietario.
El acceso a la información espacial habrá cambiado sustancialmente, porque el mapa pasará de ser una representación bidimensional de elementos estáticos con simbología temática, a ser una consulta proporcionada por servicios WEB de ubicación, una tecnología emergente que cambiará profundamente la forma de acceder a la información espacial y que nos permitirá obtener representaciones dinámicas de objetos para formar escenarios virtuales dinámicos. Escenarios que se reconstruyen en cada instante en función de las instrucciones emanadas de cada objeto contenido en ellos, objetos a los que se llega gracias al Inventario y a los servicios de ubicación.
Esta tecnología supone que la forma y representación de cada objeto del territorio en el escenario virtual no se obtiene de un servidor de mapas centralizado, sino que se compone directamente por consulta a la carta de los objetos que forman la escena, que pueden estar cambiando dinámicamente su posición, su aspecto o su contenido, y adaptarse a los requisitos, dispositivos y necesidades de quien los solicita.

Pongamos como ejemplo de geoObjeto la Vía Pública: la vía es un espacio de dominio y uso público. Todo el espacio de vía pública en una ciudad está jurídicamente indiferenciado, lo habitual es que esté inscrito en el Registro de la Propiedad de forma parcial y además fragmentado en multitud de piezas según hayan accedido al dominio público a lo largo del tiempo.

Por tanto, la estructura jurídica de la vía pública no es un dato relevante excepto para dar fe de que efectivamente es dominio público. Como un espacio continuo e indiferenciado tan enorme no es utilizable, el administrador de la ciudad lo fragmenta según un criterio geoadministrativo-político: delimita “tramos de vía pública” a los que da un tipo (avenida, paseo, calle, callejón…), un nombre y una dimensión. Intentando que todo preboste o personaje tenga derecho a su “rincón de la fama”, y si ya están todos cumplidos aplica la imaginación o la toponimia histórica.

Cuando dos o más calles intersecan adopta dos estrategias posibles: una que la intersección adquiera rango de tramo de vía pública (plaza) fragmentando los tramos intersecados o simplemente lo ignora con lo que los tramos intersecados se superponen. (suele aprovechar la intersección para fragmentar un tramo largo y así dar cabida a más personajes en el callejero)

Llegados a este punto la conclusión es que el modo de fragmentación habitual de la vía pública nada tiene que ver con su funcionalidad, ni siquiera su tipo nos da muchas pistas sobre su configuración funcional.

En realidad, desde un punto estrictamente funcional, la vía pública se fragmenta en seis tipos de espacios:

La calzada: un espacio reservado al tráfico de vehículos distribuido en carriles internos y asignado cada uno de ellos a un sentido y tipo de vehículo, el carril dispone de una plataforma de espera conexa a un vado o una intersección.

La acera: un espacio reservado al tráfico peatonal distribuido en dos subtipos, el espacio ambulatorio y las plataformas de espera, estas últimas recogen peatones que pretenden cruzar un vado conexo.
El vado: un espacio mixto donde convergen vehículos y peatones en sentidos perpendiculares procedentes de las plataformas de espera de los espacios conexos, calzadas y aceras. Los tráficos se distribuyen de forma rotatoria ya que ambos no pueden ocupar simultáneamente el vado. Normalmente hay dos tipos de vado, los pasos de peatones y los vados de acera para entrada de vehículos en las parcelas.
La intersección: un espacio conectivo donde los tráficos se distribuyen de forma rotatoria entre las calzadas conexas según un esquema temporal predeterminado.
La plaza de aparcamiento: un espacio ocupado transitoriamente por un vehículo.
El espacio sin función: espacios que no tienen una función concreta o que actúan solamente como barrera y que son ajardinados o pavimentados

Si individualizamos cada pieza asignándole el espacio propio que le corresponde, obtendremos geoObjetos Urbanos y supongamos que, a cada uno de ellos, a cada trozo de calzada, acera o intersección, en virtud de la magia de la tecnología, le asignamos algunas capacidades especiales:

Lo primero es darle identidad: un nombre o un DNI, algo que le sea propio y que lo distinga de cualquier otro. Es importante, ya que se convierte en un interlocutor distinguible de los demás. Si pregunto al vado -¿Puedo pasar?- no lo pregunto a cualquier vado, lo hago a ese que tengo delante, al vado V34-43.

Se le asignará su espacio tridimensional y deberá tener modo de controlar sus fronteras para que no se le cuele nadie sin autorización.
Tendrá conocimiento de los espacios colindantes para que pueda hablar con ellos. El vado V34-43 recibe peticiones de paso de la acera porque ésta tiene peatones en su plataforma de espera, o de la calzada porque también tiene vehículos esperando y habla con la intersección para saber si puede enviarle vehículos, ya que mientras la intersección no los acepte podrá atender a las peticiones de sus aceras cliente.
El vado tiende a estar quieto, pero si se pudiera mover como un coche o una persona tendría un espacio accesible y una trayectoria. El vado en realidad tiene un espacio accesible, ¡pero es igual a su espacio propio!, así que malamente se puede mover y tiene una trayectoria, pero de longitud cero.
El vado decimos que es un espacio Conductor: mueve a otros geoObjetos como la acera o la calzada. A diferencia de la intersección que es un geoObjeto Distribuidor o de la parcela que es un geoObjeto Contenedor. Esta es una característica que determina la función principal de cada geoObjeto.
El vado es de propiedad municipal, su administrador delegado se ocupa de darle trabajo y atender sus incidencias, -que si hay demasiado tráfico y todo el mundo se queja, aunque él no tenga la culpa-, -que si los peatones lo invaden sin permiso-, -que si tiene la pintura fatal-… Fue creado por un proyecto de obras de urbanización hace unos años (Geotransacciones) y probablemente cese de servicio dentro de poco ya que se dice que van a remodelar toda la calle. Lo estupendo sería que lo reasignen a otro vado nuevo, aunque lo tengan que subir de versión.
Siempre está atendiendo a peticiones externas: que si nos des la estadística de peatones y coches por meses, que si cierres el paso a todo el mundo excepto al vehículo M34567 porque va a pasar un preboste, que si nos mandes tu geometría en 2D para que salgas en un mapa…
Además, tiene que vigilar, tiende a denunciar a todo vehículo o peatón que incumpla las normas. Pero se ocupa diligentemente de avisar a quien haga falta cuando en su espacio hay un incidente, una avería o una caída de un peatón o simplemente cuando cualquiera le pida ayuda, está diseñado para hacer todo lo que esté en su mano para ayudar.
Y todo esto lo hace porque el vado es un agente inteligente que está funcionando en cloud y está conectado con su sistema sensorial y con los geoObgetos vecinos, los vehículos y los peatones mediante la red internet. Y como agente inteligente participa activamente en establecer en todo momento estrategias de optimización del tráfico dentro de comités de calle y asambleas de distrito.

El Inventario será una réplica virtual de la ciudad, de sus geoObjetos y relaciones. Una representación veraz del mundo real, mantenida colaborativamente por todos los que proponen y ejecutan cambios en el territorio y controlada por los procesos administrativos que autorizan y verifican la ejecución de esos cambios. Una réplica organizada en cuatro niveles de objetos:

Objetos de planificación, representados por los ámbitos de planeamiento y sus datos asociados, nos indican cómo debe ser la ciudad y su desarrollo futuro.

Objetos de derechos: que comprenden todos los derechos sobre el suelo y las construcciones, que determinan la capacidad jurídica de las personas para usar el territorio.
Objetos físicos que comprenden la descripción y características de todos los elementos constructivos, instalaciones y mobiliario existentes sobre el territorio.
Objetos de obligación: que comprenden todos los deberes sobre el suelo y las construcciones para todos los actores urbanos, y que aseguran el funcionamiento sostenible de todo el sistema urbano.

Cuatro niveles completamente conectados por relaciones transversales que forman una inmensa red y que determinan cómo funciona la ciudad.

Todos los geoObjetos deben encajar en una estructura jerárquica que determina las reglas de dependencia mutua entre todos ellos y que reproduce el funcionamiento de la ciudad en todos los órdenes. Esta estructura jerárquica se apoya en distintas bases:

Topológica: determina la posición relativa entre dos geoObjetos: interna, externa, adyacente, alejada.

Jurídica: determina la dependencia patrimonial, derechos reales, derechos de uso, servidumbres…
Administrativa: determina la relación entre los geoObjetos y la estructura administrativa competencial.
Técnica: determina la dependencia física entre geoObjetos.
Funcional: determina la dependencia funcional entre geoObjetos.

Ello implica que la forma de acceso a los geoObjetos se verifica por niveles de profundidad, donde cada nivel establece las condiciones y forma de acceso a los niveles subsiguientes, desde el super geoObjeto “Ciudad” hasta el último geoObjeto contenido en un compartimento de un edificio o de una instalación.

Para establecer la jerarquía de geoObjetos se define el número mínimo de tipos que pueda servir para describir el número máximo de geoObjetos posibles sobre el territorio:

Área metropolitana: un conjunto geográficamente continuo de ciudades que tienen una fuerte interdependencia funcional.

Ciudad: un ámbito espacial contenedor sujeto a una administración unificada. dentro de Área metropolitana.
Distrito: un subámbito espacial contenedor y opcional sujeto a administración unificada dentro de la Ciudad.
Espacio No Asignado: compartimento contenedor, dentro del Distrito o en su defecto dentro de la Ciudad, que no tiene asociada una función específica, por ejemplo, un solar o un espacio no urbanizado.
Parcela: compartimento contenedor, dentro del Distrito o en su defecto dentro de la Ciudad, que tiene una función no conectiva, por ejemplo, una parcela residencial, industrial o dotacional.
Finca: compartimento contenedor, dentro de la Parcela, con asignación diferenciada de derechos, (Espacio común y Espacios privativos).
Local: compartimento contenedor dentro de la Finca, con una función diferenciada (Habitaciones o piezas)
Instalación: compartimento, dentro de la Ciudad, que tiene una función conectiva (redes de todo tipo, viarias, de agua, de energía, de alumbrado, de telecomunicación…).

Conducto: compartimento de una Instalación que sirve de canal de transporte especializado: calzadas, vados, vías férreas, aceras, carriles bici, tuberías, cables…

Nodo: compartimento de una Instalación que sirve de colector o repartidor: intersecciones viarias, depósitos, transformadores, estaciones, aeropuertos…
Vehículo: compartimento de transporte de personas o mercancías que circula por conductos especializados e interacciona con nodos. No está asignado jerárquicamente a ningún otro geoObjeto, ello no quiere decir que los geoObjetos que lo contienen en un momento determinado no están informados de su presencia y trayectoria.
Persona: persona física que circula por conductos especializados, interacciona con nodos o utiliza espacios de cualquier tipo. No está asignado jerárquicamente a ningún otro geoObjeto, ello no quiere decir que los geoObjetos que lo contienen en un momento determinado no están informados de su presencia y trayectoria. (Dentro del margen que determine el derecho a la privacidad)

Este Inventario Urbano, se mantiene actualizado mediante transacciones: las operaciones que definen los cambios sobre sus elementos en forma de adición de nuevos elementos, eliminación de elementos obsoletos y modificación de la descripción geométrica y de contenido de datos de los elementos existentes.

Transacciones que se materializan como Instrumentos, tradicionalmente representados en forma de planes, proyectos, convenios, contratos, decretos… los mismos que siempre se han utilizado para describir las alteraciones sobre la realidad urbana.

Pero dotar a los Instrumentos de este carácter transaccional, ya que en este momento son documentos descriptivos poco o nada normalizados y nunca sistematizados, exige que sufran un profundo cambio, al menos en parte de su contenido, de forma que no solo sirvan para dar forma a los cambios en el mundo real, sino también sirvan para ejercer ese papel transaccional sobre el Inventario virtual.

5.3 IOT e inteligencia artificial distribuida

El Inventario además se configura como un enrutador hacia las Cosas de Internet (IoT) que permite establecer un flujo bidireccional:

Desde el Inventario hacia los sistemas de gestión de la ciudad. Notificándoles las modificaciones efectuadas sobre el Inventario por los documentos de cambio urbano.

Desde los sistemas de gestión hacia el Inventario como forma de alimentación de indicadores a los cuadros de mando de la ciudad. Esta función permite que la ciudad gestione de forma eficiente el torrente de datos que generan los sistemas verticales aportando mecanismos de filtrado espacial y de simplificación y generalización de datos.

Los geoObjetos y toda la sensórica asociada a ellos estar controlada por Agentes Inteligentes que funcionan como autómatas de software (bueno en el caso de las personas es un poco distinto, pero ellas son el modelo que debe servir para construirlos). Esto supone, frente a los sistemas de IA al uso que están centralizados en inmensos y costosos centros de datos, que la IA de la ciudad está distribuida en cientos de miles de microsistemas aportando un plus de resiliencia al sistema.

De forma ideal (todo depende de si posible construirlo) los Agentes deben tener las siguientes características:

Como todo servicio el Agente puede funcionar en una máquina física o virtual, tanto embebida en el geoObjeto urbano como en un servidor remoto. Las posibilidades para que geoObjeto de cualquier clase adquieran capacidad para contener un Agente son prácticamente ilimitadas. La miniaturización, la reducción del consumo energético, la generación autónoma de energía por procesos electrónicos, químicos o físicos, la construcción de redes de sensores mediante comunicación inalámbrica o por redes eléctricas o por cualquier otro medio y otras muchas innovaciones nos aseguran la posibilidad de trasladar inteligencia a un geoObjeto.

Si el Espacio Accesible al geoObjeto es mayor que el Espacio Propio del geoObjeto, es decir si el geoObjeto puede moverse, el Agente deberá disponer de funcionalidad GPS que le permita mantener informada su posición, orientación y en su caso la trayectoria.
El Agente es autocontenido, no tiene ninguna dependencia de bases de datos, aplicaciones externas, librerías o sistemas que no sean el estándar del SO de la máquina en la que funciona. Todos sus datos y funciones están contenidos y administrados directamente por el geoObjeto según su propia lógica interna, por lo tanto, no depende de ningún dispositivo externo o repositorio de datos para su gestión, salvo del adecuado suministro de energía.
Dispone de una lógica de seguridad que establece los niveles de acceso a su información, administrada por su propietario legal.
Tiene memoria para almacenar experiencia y si es posible para aprender de ella.
Es autotransportable, de dos formas: a) con la autorización de su propietario es capaz de moverse de un soporte hardware a otro, sería como trasladar un programa licenciado para funcionar en una máquina a otra máquina, pero donde el traslado lo hace el propio programa y b) también previa autorización es capaz de abandonar un geoObjeto urbano y tomar posesión de otro geoObjeto de la misma naturaleza. Una especie de trasplante de cerebro. Ello permitiría que podamos cambiar de coche sin cambiar de agente inteligente. (aún no funciona con las personas, pero dale tiempo)
Es clonable, con la autorización de su propietario es capaz de crear una réplica de si mismo, dotarla de una nueva identidad y representar a un nuevo geoObjeto urbano.
Es universal, puede representar a geoObjeto urbanos de cualquier naturaleza siempre que haya adquirido las reglas de comportamiento y propiedades asociadas a cada clase de geoObjeto.
Dispone de un direccionamiento IP propio, bien público o a través de un router por tanto tiene conectividad con internet. En función de la dinámica del geoObjeto esta conexión será permanente o periódica y de ancho de banda proporcional a sus necesidades.
Regula las condiciones del sistema interno del geoObjeto, gestiona los inputs de información desde sus sensores y dispone de una ontología que le permite adoptar conductas adaptativas adecuadas a cada situación.
Dispone de un Servicio de Ubicación (LBS) propio que le permite conocer en todo momento la posición y forma de los dispositivos que controla o de otros geoObjeto que circulan por sus espacios.
Dispone de servicios web de consulta que le permiten interactuar con otros geoObjeto, con Servicios de Ubicación jerárquicamente superiores y proporcionar a su propietario un cuadro de mando que le permita establecer su comportamiento, conectividad con otros geoObjetos y con los usuarios.

5.4 Control y seguridad

El Inventario alimenta los sistemas de publicación de la ciudad poniendo al alcance del ciudadano una visión completa de su entorno sobre cualquier dispositivo (Computadora personal, Tablet o Smartphone) e incluye la posibilidad de que el ciudadano interactúe con el Inventario de dos formas:

Usando el Inventario como enrutador hacia información de valor añadido que el propietario de cada objeto urbano pone a disposición pública, bien de forma desinteresada o bien como herramienta de marketing de sus productos y servicios.

Enriqueciendo el Inventario con la aportación de información coyuntural, incidencias, denuncias, emergencias, documentos gráficos o de vídeo, información histórica o de interés cultural, propuestas, creaciones personales o contenidos libres de todo tipo. Proporcionando al Inventario una faceta más de interés público y de conocimiento de la ciudad.

La Colaboración reglada formará el sustrato básico para el despliegue de la ciudad inteligente, porque proporcionará a todos los sistemas urbanos implicados un Inventario completo y seguro de los elementos que la componen y un medio de conexión con ellos, independiente de cada sistema y ligado a los procesos legales de planificación, transformación y gestión urbana. Esta conexión entre los procesos administrativos territoriales y los objetos implicados en ellos es la que asegura su calidad y grado de actualización.

Contar con una normativa que regule la Colaboración reglada donde todos los actores tengan claramente definidos su derechos y obligaciones en el mantenimiento del Inventario y la categorización de los distintos niveles de privacidad y protección de datos.

6 Sobre los Servicios de datos geoespaciales

6.1 Servicios actuales

Los geoservicios se dividen en dos clases básicas:

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 suministra una imagen o un conjunto de vectores completo o teselado que la cubre.

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:

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 conseguirlo. 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 clúster 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.

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.

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».

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 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 interoperabilidad.

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 de los propietarios de los datos y su modo de licenciamiento.

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.
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 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.
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 predios de Azogues (Ecuador) https://urbigis.com/88726a43-c5cc-4750-b556-ef6549e14254.ms que solo se visualiza cuando la escala es inferior a 1.70.000.

Asimismo, debe existir una normativa que garantice que los Geoservicios que prestan datos críticos cumplan estas condiciones mínimas.

6.2 Nuevos geoservicios: geoSCADA

Ya no basta con servir datos espaciales como imagen o como vector, en otras entradas de este blog he comentado como los geoObjetos 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.

El Inventario se construye por la contribución de millones de agentes que colaboran con su descripción, propiedades y funciones.

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 geoObjetos son inteligentes, dejemos las demás técnicas para los geoObjetos tontos.

También significa que nuestros mapas dejan de representar solamente objetos estáticos, si los geoObjetos territoriales se mueven y están autorizados a enviar su posición, nuestro mapa será capaz de seguirlos y representarlos.

6.3 Nuevos geoservicios: el Servicio de Ubicación

El Inventario se puede publicar mediante servicios WEB estándar SOAP/WMS/WFS. Pero es preciso que aporte un modo nuevo de acceso a objetos espaciales: un Servicio de Ubicación (LBS o Located Based Services).

Un Servicio de Ubicación utiliza una base de datos espacial para contener la posición geográfica de cualquier elemento o dispositivo.

Tiene dos funciones básicas, una que le permite recibir dinámicamente la posición desde cada objeto y guardarla en su base de datos. Otra que le permite procesar peticiones de clientes que quieren saber dónde está un objeto o varios. Todas las nuevas capacidades para descubrir a amigos o para que los comercios te descubran cuando estás cerca y te ofrezcan bienes, están soportados por Servicios de Ubicación.

Los LBS actualmente están siendo aportados por los grandes operadores de navegadores y sistemas operativos: Google, Apple, TomTom, Garmin… Y se destinan a la geolocalización de dispositivos móviles con GPS incorporado. Un enorme negocio explotado en régimen de cuasi monopolio. Las Administraciones Públicas actualmente son clientes de esos servicios, a pesar de que suministran datos sobre el territorio de su competencia.

El propósito del Servicio de Ubicación del Inventario será trasladar a la Administración la competencia sobre los Servicios de Ubicación de su territorio:

Debe ser un servicio público proporcionado en su ámbito espacial de competencia.

Debe ser único para cada ámbito. De forma que los consumidores no tengan que seleccionar entre diversos sistemas y que los objetos sólo necesiten presentarse ante un único Servicio.
Debe contemplar no solo los elementos aportados por los Inventarios sino cualquier otro objeto estacionario o móvil que se identifique ante el Servicio.
Debe ser un Servicio permanente y estable, capaz de servir a millones de clientes con un alto grado de simultaneidad. Esto implica unos recursos de hardware, software y comunicaciones de enormes dimensiones. Por tanto, es recomendable que la Administración conceda su explotación a empresas que cumplan estas condiciones y que puedan retornar la inversión con un plan de negocio viable. De esta forma la Administración proporciona un servicio público sin coste, puede que incluso le sirva para mejorar su recaudación.
Debe resolver el alcance y modo de respuesta a las peticiones de sus clientes. Los actuales LBS lo tienen fácil, se limitan a devolver una lista de coordenadas que representa la posición actual de móviles o navegadores por GPS en un radio determinado. El cliente se ocupa de presentar esas coordenadas al usuario con una simbología determinada. Sin embargo, el nuevo LBS debe resolver la presentación de objetos bidimensionales y tridimensionales y sus modos de representación.

El Servicio, una vez identificados los objetos a devolver puede utilizar dos estrategias para obtenerlos:

Puede disponer de una caché de objetos en sus propios servidores, de forma que no necesite solicitar ninguna información al proveedor del objeto. Esto será posible si el Servicio dispone de recursos propios para almacenar millones de objetos y negociar con los proveedores los métodos de actualización.

Puede reenviar la petición a los proveedores de objetos y servir sólo como intermediario entre ellos y los clientes. Esto descarga parte de la responsabilidad en los servicios propios de los proveedores (que no siempre estarán operativos) pero asegura disponer siempre de la última versión de cada objeto.

Los Servicios de Ubicación controlan la posición de objetos sobre el territorio. Los Inventarios son la fuente básica de información para ese Servicio, pero no es la única fuente. El Servicio de Ubicación puede informar de cualquier objeto del que interese conocer su posición en cada momento.

Los LBS abren una forma de conocimiento y exploración del territorio completamente nueva: el territorio se autodescribe ante las personas.

7 Conclusión

En el mundo de los datos espaciales y los mapas, hay una revolución pendiente, los avances, que ya utilizamos cotidianamente, de navegación y mapas, apenas dejan entrever sus posibilidades, ventajas e implicaciones futuras. La realidad aumentada y la realidad virtual, en un mundo de comunicaciones ultrarrápidas y de conectividad entre personas y máquinas, empiezan a hacer posibles esos escenarios que solo vimos en la ciencia ficción.

Su consecución no solo necesita avances tecnológicos, necesita la Colaboración, porque al final son las personas quienes crean y consumen la información. La potencia de Internet está basada en la tecnología, pero son los millones de personas y máquinas que crean información quienes la hacen realmente útil. La información espacial producto de la Colaboración será el resultado de esa revolución.

Ignacio Arnaiz Eguren (iae@arnaizurbimatica.es)

Director

Arnaiz Urbimática

El geoportal municipal en urbiGIS: el caso de la Comunidad de Madrid

Thu, 16 Jan 2025 00:00:00 GMT

Salvo las grandes ciudades, como Madrid capital y pocos más, los municipios españoles no disponen de un geoportal propio. Los de la Comunidad de Madrid tampoco escapan de esta carencia, incluso los de mas de 100.000 habitantes (salvo Rivas-Vaciamadrid), aunque hay una enorme cantidad de información a disposición de los ayuntamientos.

Aprovechando que en UrbiGIS tenemos un geoportal específico a disposición de todos los ayuntamientos de España y de muchos países sudamericanos, (su dirección de internet esta compuesta por «https://urbigis.com/» + <el nombre del municipio sin espacios, ni acentos> + «.maps) hemos configurado una selección, no exhaustiva, de los datos que consideramos de utilidad para el ciudadano en algunos municipios de la Comunidad de Madrid (se puede amplir a todos).

Son hasta 390 geoservicios proporcionados por diferentes organismos y que hemos organizado por temas y subtemas:

En la imagen anterior solo se muestran los temas, pero cada uno se divide en subtemas que contienen sus mapas:

Las fuentes de los datos son diversas:

El propio Ayuntamiento si tiene un servidor de mapas en formato abierto (WMS, WFS, WMTS, REST) o cuando publica ficheros georreferenciados (GML, KML, GeoJSON, SHP ….) los publicamos como servicios web WMS desde urbiGIS que atacan directamente a portal de transparencia del ayuntamiento o cuando no es posible por descarga en el servidor urbiGIS.
Los servicios internos de urbiGIS
La IDE de Comunidad de Madrid
Los servicios de NomeCalles de la Comunidad de Madrid
El Instituto de Estadística de Madrid
La Dirección General del Catastro
El Instituto Geográfico Nacional
El Ministerio de Agricultura y Pesca, Alimentación y Medio Ambiente
El Ministerio para la Transición Ecológica y el Reto Demográfico
La Universidad Autónoma de Madrid

Además se incluye el servicio de ficha catastral de la Dirección General de Catastro.

Con ello se pretende demostrar que, normalmente, existe un océano de geodatos a disposición de los ciudadanos y de los servicios municipales, que, en el mejor de los casos, están dispersos en distintos geovisores, cuando no están ocultos o sólo accesibles a especialistas. En unas zonas de España hay más en otras menos pero siempre hay información disponible.

Por supuesto, estos geoportales municipales pueden ser integrados en las páginas web del ayuntamiento como un iframe embebido. Son geoportale de acceso público y gratuito ya que distribuyen mapas publicos. Pueden completarse de forma sencilla incorporando nuevos geoservicios ajenos o propios del ayuntamiento.

Si desea obtener más información de cómo configurar el geoportal de su ayuntamiento e incluirlo en su pagina web, solo tiene que enviar un correo a iae@arnaizurbimatica.es.

Os pongo un geoportal de ejemplo configurado para Villaviciosa de Odón: https://urbigis.com/villaviciosadeodon.maps

Ignacio Arnaiz Eguren

Director

urbiGIS ante catástrofes ambientales

Thu, 14 Nov 2024 00:00:00 GMT

En los últimos años hemos asistido a fenómenos ambientales extremos y la predicción es que el cambio climático incremente su número e intensidad. Algunos son predecibles y otros inesperados. El volcán de La Palma, el terremoto de Lorca, los incendios forestales de este año en Portugal y sobre todo la DANA de octubre en Valencia son ejemplos paradigmáticos.

Ante ellos hay distintas administraciones públicas que mapifican los riesgos e intentan cuantificar sus posibles efectos adversos sobre la población y la economía, con mayor o menor acierto. Y una vez que se producen las catástrofes, realizar un seguimiento de su avance, de las medidas para reducir los daños y de los trabajos de restauración.

En general esta mapificación es pública y se presenta en diferentes visores geográficos, desde los de organismos internacionales como Copernicus a la NASA, los de organismos nacionales, autonómicos y locales, los de distintos Institutos Geográficos, las Confederaciones Hidrográficas, los Ministerios afectados o el Colegio de Registradores.

Todos ellos aportan su granito de arena creando información geográfica útil, pero que tiende a quedar disgregada, cada organismo publica lo suyo. Además, algunos utilizan estándares Opengeo, otros servicios REST, algunos solo permiten descargar ficheros geojson o kml.

urbiGIS en este sentido asume un papel de concentrar la información dispersa de forma que aísle a los usuarios de la complejidad de acceder a tantas distintas fuentes y a tantos distintos formatos de datos.

En el caso particular de ls DANA de Valencia, todos los servicios y datos accesibles se presentan en el geoportal https://urbigis.com/danavalencia.maps

En este geoportal se ha organizado la información en primer lugar por la fuente de datos y secundariamente por tema:

La Generalitat de Valencia que aporta datos de Unidades administrativas, Infraestructuras, y Urbanismo
La Confederación Hidrográfica del Júcar que aporta datos de gestión de la cuenca
El Sistema Nacional de Cartografía de Zonas Inundables (SNCZI) que aporta la hidrografía, los riesgos y peligros de inundación
El Instituto Geográfico Nacional que aporta los modelos de elevación de terreno
Y la Unión Europea a través del programa Copernicus EMSR733 Flood in Valencia que aporta datos sobre el alcance de la inundación y sus daños.

En conjunto forman más de 70 mapas que se pueden visualizar de forma individual o conjunta, superpuestos o en pantalla dividida, con niveles de transparencia ajustables y en un orden configurable por el usuario, intentando que la usabilidad sea lo más sencilla posible. Por supuesto se aportan funciones para aproximarse de alejarse del terreno y para solicitar los datos asociados a cada mapa sobre cualquier punto del terreno.

En función de la disponibilidad de la fuente de datos es posibles descargarlos como ficheros SHP para ser utilizados en posteriores análisis por el usuario.

La información se puede presentar sobre varios fondos cartográficos como OpenStretMap o Google seleccionables por el usuario. Además, es posible añadir cualquiera de los cientos de mapas disponibles en al catálogo de urbiGIS.

Estimamos que de esta forma se facilita el acceso a la información a todos los niveles: ciudadanos, empresas e instituciones de la zona afectada, a las organizaciones o grupos que puedan prestar ayuda y simplemente de tengan interés ya que el sistema es plenamente accesible y sin limitaciones desde cualquier navegador estándar con acceso a Internet.

urbiGIS además proporciona utilidades para colaborar en la mapificacion de cualquier otra información geográfica y las pone a disposición de todos de forma gratuita, por ejemplo la situación de los centros de ayuda a los damnificados, hospitales, áreas impracticables o de alto riesgo, etc.

Reutilizar rápidamente información urbanística con #urbiGIS (https://urbigis.com)

Tue, 09 Jan 2024 00:00:00 GMT

La información urbanística está evolucionando, por fin, hacia información 100% digital. No siempre como nos gustaría, es decir como inventarios digitales transaccionales de #urbiGIS, pero sí al menos como conjuntos de datos normalizados.

Este es el caso de Galicia (España) donde sus normas determinan el contenido detallado de los planes y los formatos digitales de entrega.

En el video que adjunto muestro cómo, en pocos minutos, un municipio pequeño como Ribeira de Piquín (Lugo) puede reutilizar en su geoportal la información urbanística publicada por el sistema regional de datos abiertos (SIOTUGA), tanto usando sus servicios web WMS como mediante la descarga de datos vectoriales.

El vídeo demuestra que publicar información geográfica en #urbiGIS es sencillo, rápido y accesible, sin necesidad de costosas licencias, sistemas complejos ni desarrollos específicos de software.(Pido disculpas de antemano por la calidad del sonido, a mi de natural mala voz se suma la gripe)

Geoportal en Ribeira de Piquín (youtube.com)

La posición de urbiGIS en el mercado GIS

Thu, 06 Jul 2023 00:00:00 GMT

El mercado GIS mundial está dominado en este momento por ESRI (Environmental Systems Research institute). Proporciona sistemas desktop y cloud a miles de clientes de todo tipo, preponderando las administraciones públicas o a empresas que prestan servicios a organizaciones públicas. (Datos obtenidos a partir de análisis de servidores ArcGis REST realizado por urbiGIS).

Su predominio alcanzó el máximo cuando los sistemas desktop de la competencia del pasado siglo fueron desapareciendo del mercado, porque los sistemas desktop opensource como Quantum GIS o gvGIS, que aparecieron para contrarrestar ese cuasi monopolio, han tardado muchos años en desarrollar una funcionalidad competitiva. Aunque parece que, por ahora, las preferencias de los clientes (al menos de los que tienen recursos para pagar las licencias de ESRI) se decantan por ESRI. A ello contribuye la genial estrategia comercial de ESRI que facilita licencias casi gratuitas en los entornos docentes, fidelizando a sus futuros usuarios profesionales.

Sin embargo, estimo que los movimientos mundiales como el Open GIS Consortium y la investigación constante por la comunidad internacional para mejorar el manejo de datos y sus procesos, terminarán por ganar la batalla a ESRI. Simplemente es una cuestión de masa crítica, una empresa privada por muchos recursos que tenga no podrá competir con una comunidad internacional bien organizada. Al menos fuera de Estados Unidos, donde ESRI es omnipresente.

Los GIS en Internet

Los creadores de datos y analistas geoespaciales utilizan sistemas desktop, por ahora son casi imprescindibles para manejar eficientemente grandes volúmenes de datos vectoriales o raster. El problema se presenta cuando esos datos se deben publicar en Internet, porque el salto de utilizar dispositivos y redes locales a utilizar servidores y servicios Internet es muy duro, teniendo en cuenta además que se necesitan clientes especializados en manejarlos y donde los requisitos de seguridad son muy estrictos.

Para facilitar ese salto a la web hay dos soluciones posibles:

1) Construir proyectos sobre sistemas desktop (con coste o gratuitos) que luego puedan ser reutilizados por servidores web (subiendo los datos a cloud y publicándolos en servidores compartidos). Este es el sistema preferentemente utilizado por los desarrolladores de sistemas desktop para facilitar a sus usuarios el salto a la web. (ArcGis Online, qGIS Cloud, gvSIG Online …). Y también es el sistema utilizado por OpenStreetMap con sus distintos editores (JOSM, Postlach…)

2) Utilizar aplicaciones web que funcionan sobre cualquier explorador estándar donde todo el proceso se realiza directamente sobre un sistema cloud. En esta solución han aparecido bastantes sistemas SaaS que han permitido acercar el mundo GIS a los usuarios no expertos y a las organizaciones sin recursos técnicos ni humanos para crear y divulgar información geográfica. En estos sistemas no se excluye que haya datos creados con sistemas desktop pero solo como una etapa previa y no imprescindible. (Google My Maps, MapBox, GeoWE, GIS Cloud, InstaMaps, Carto, urbiGIS…)

Esta segunda opción se enfrenta a las limitaciones que ofrecen los navegadores estándar para el manejo eficiente de los recursos locales de memoria y disco, y de la gestión gráfica. Frente a esta limitaciones ofrecen una flexibilidad indiscutible para funcionar en cualquier dispositivo sin necesidad de instalar ningún aplicativo específico.

¿Cómo rentabilizar estos nuevos sistemas SaaS?

El mejor ejemplo es, otra vez, el de Microsoft Office vs. OpenOffice/LibreOffice. Microsoft en la práctica está abandonado sus sistemas desktop para distribuir Office 365 como un sistema SaaS, mientras que las alternativas abiertas siguen siendo plenamente desktop, y para evitar que Google le coma su mercado con sus aplicaciones SaaS de ofimática.

Microsoft 365 en un entorno doméstico es barato, es algo menos barato en uno empresarial, pero es muy atractivo para los administradores de sistemas empresariales porque sus costes de licencia son menores que los costes de administración de sistemas desktop distribuidos en todos sus dispositivos, así que no tienen duda; migración cloud, virtualización de escritorios y aplicaciones SaaS. Microsoft gana.

Si aplicamos estas lecciones aprendidas al mercado de GIS, sin duda el futuro está en los sistemas Cloud y SaaS, pero salimos de un mercado basado en la adquisición o alquiler de una licencia a un mercado basado en el uso de un servicio y como siempre hay dos opciones: el pago por uso o la tarifa plana.

Se me ocurren un par de estrategias en cuanto al diseño de la solución:

1) Vender productos muy sofisticados para pocos y grandes clientes que exigen soluciones personalizadas. Clientes para los que el branding es una parte esencial de su producto y que desean producir y ofrecer información geoespacial especializada. Para atender esa demanda es preciso construir soluciones con potentes API’s que permitan a sus programadores y diseñadores proporcionar a cada cliente una solución propia y personal.

En esta estrategia cada cliente tiene un presupuesto propio ajustado a sus necesidades y se trabaja por proyectos. En cierta forma el proveedor GIS es semejante a una agencia de publicidad. Su inconveniente son los plazos y los elevados costes que conlleva la necesaria implicación de un grupo de superespecialistas y la integración con otros sistemas internos del cliente.

Una vez construido el producto se suelen ofrecer planes de venta basados en el pago por uso según el número de capas disponibles y en el número de accesos a datos y mapas. En muchos casos son sistemas internos del cliente sin visibilidad internet o con visibilidad reducida.

2) Vender productos muy sencillos pero que satisfagan las necesidades básicas de muchas organizaciones independientemente de su tamaño. Productos con un grado de personalización muy bajo o inexistente pero con los que la puesta en marcha es inmediata. ¡Contratar y listo!

En esta estrategia los costes serán muy bajos, se estima del orden de un Microsoft 365 Home, y se aplican tarifas planas donde la rentabilidad se basa en que los excesos de uso de unos pocos se equilibran con los defectos de uso de muchos.

Los mercados

1) El mercado privado: está circunscrito en la práctica a grandes empresas de servicios territoriales y urbanos. Sin desmerecer las técnicas de geomarketing aplicadas a medianas y pequeñas empresas, pero que tienen un alcance coyuntural y necesitan enormes cantidades de datos no siempre disponibles para ajustar sus resultados.

2) El mercado público: sin duda el gran cliente de los sistemas GIS, con una segmentación que se deriva en algunos inconvenientes:

Los organismos globales: siempre utilizan soluciones propias y en algunos casos la dimensión de los datos que utilizan o sus formatos exigen tecnologías específicas que no tienen aplicación en sistemas locales.
Los organismos nacionales: divididos entre los adeptos a ESRI, normalmente alrededor del ámbito de influencia norteamericano, de los adeptos a sistemas abiertos, normalmente alrededor del ámbito de influencia de la Unión Europea. En todo caso su dimensión les orienta a soluciones personalizadas aunque es habitual utilizar soluciones opensource como geoNetwork para distribuir información espacial de interés nacional como las Infraestructuras de Datos Espaciales.
Los organismos regionales y las grandes ciudades, que son habitualmente el objeto de deseo de los suministradores de soluciones GIS y que son muy celosos de sus datos, habitualmente contratan estos servicios como grandes paquetes anuales de licencias y mantenimiento mediante concursos abiertos.
Los organismos locales, en la mayoría de los casos sin recursos para adquirir sistemas y también sin una directriz política y técnica que asigne prioridad a la información geográfica en sus cartas de servicio al ciudadano. Son los clientes ideales de sistemas cloud de tarifa plana que les permita publicar algunos datos sencillos sin grandes inversiones. Por desgracia no siempre es así de simple porque a veces llegan fondos europeos, se lían la manta a la cabeza y se lanzan a contratar lo mismo que podrían conseguir con una plataforma cloud sencilla, pero con plazos de un montón de meses, con intentos de integración poco estudiados y heredando con todo ello una plataforma GIS que no son capaces de mantener a medio y largo plazo. (no quiero dar nombres pero tengo a varios en la cabeza)

**La posición de urbiGIS **

urbiGIS es una plataforma cloud que permite importar, crear, almacenar y publicar datos geográficos sin necesidad de programación y de forma sencilla y accesible. Actualmente es de acceso libre y gratuito y estamos avanzando hacia un modelo mixto de consulta universal gratuita y de suscripción plana de bajo coste para edición y almacenamiento de datos.

La Gestión Documental en urbiGIS

Wed, 22 Mar 2023 00:00:00 GMT

Nos parece que los Sistemas de Información Geográfica sólo se ocupan de tratar con datos vectoriales o de imagen georreferenciada y de proporcionar las innumerables herramientas para su producción, almacenamiento, análisis y publicación. Casi en contraposición a los Sistemas de Gestión Documental que tratan con información no geográfica contenida en documentos de todo tipo. Pero la realidad es que nuestro mundo geográfico se desenvuelve en un entorno documental de informes, facturas, fotografías, estudios o análisis, últimamente digitales en origen, pero que en muchos casos aún son imágenes escaneadas de documentos de papel.

Todo esto supone que cuando identificamos un fenómeno geográfico por su posición, su forma o sus propiedades, es muy probable que esté conectado con documentos, como los que describen o justifican su existencia, los que informan de sus propiedades actuales o efectos, los que delimitan sus posibles transformaciones futuras… Una pléyade documental a la que es imprescindible acceder para poder actuar sobre él o comprenderlo.

En este negocio del GIS siempre trazamos la ruta hacia el documento desde el elemento geográfico pero en otros ámbitos la ruta es inversa, es el documento quien tiene el protagonismo y el elemento geográfico es un derivado. Hasta el punto de que la Gestión Geográfica pasa a ser un anexo de la Documental.

Sin llegar a ese extremo, el problema es que nuestros sistemas GIS no suelen disponer de una Gestión Documental integrada. Si hay que tratar con Documentos lo más inmediato es añadir en un fichero de formas un campo de texto con la ruta a un documento o a una carpeta de documentos. La solución suele ser suficiente, y será más eficiente si esa ruta no apunta a recursos locales, difíciles de compartir, sino que apunta a recursos remotos abiertos o compartidos. Siempre y cuando esos repositorios documentales no cambien de nombre o posición, rompiendo la integridad con las rutas del fichero de formas.

Si nuestro sistema está soportado por una base de datos espacial siempre queda la posibilidad de guardar una copia de los documentos en la misma base de datos o realizar una integración con un gestor documental al uso, lo que nos permitirá conservar la integridad referencial y robustecer la solución.

Como en urbiGIS tratamos con Inventarios y elementos geográficos que son fruto de una actividad reglada y bien documentada, es imprescindible resolver esta necesidad. Por eso hemos adoptado algunas soluciones.

Soluciones

1) Todo elemento o fenómeno geográfico contenido en urbiGIS es susceptible de contener documentos. En el caso de los Conjuntos de Datos sus documentos se pueden referir a la totalidad del Conjunto o a cualquiera de sus geometrías y además un documento puede ser compartido por varias geometrías. De la misma forma en el caso de los Instrumentos (Conjuntos de Datos de mantenimiento transaccional) sus documentos se pueden referir a la totalidad del Instrumento o a alguno de sus elementos, como a un Atributo concreto, a una Entidad geométrica, a una Relación con otro elemento o al valor concreto que un Atributo adquiere en una Entidad.

Por ejemplo en un Inventario de Planeamiento la determinación «Altura máxima» en la entidad «Casco antiguo» tendrá un valor medido en metros o plantas y tantos documentos como el plan incluya para interpretar correctamente la normativa (gráficos, fotos etc.). Incluso en ese caso la altura puede tener varios valores condicionados (si es esquina, si hay mucha pendiente, si al otro lado de la acera hay edificios bajos…), cada uno con sus documentos y por tanto lo que en teoría debería ser un dato simple, se convierte en un laberinto normativo y documental.

2) A esos elementos se les puede adjuntar cualquier tipo de documento, distinguiendo los siguientes:

Ficheros individuales (doc, pdf, xls, jpg, png…) no georreferenciados. Se suben y almacenan sin más operaciones.
Ficheros individuales georreferenciados que representan un área geográfica (fotografías aéreas o planos escaneados). Se suben sin más pero urbiGIS calcula su extensión y posición de forma que sea posible colocarlos como una capa más del escritorio de urbGIS. En este caso urbiGIS crea un fichero .prj que guarda como auxiliar del principal.
Ficheros individuales georreferenciados que representan un punto (fotografías con datos de posición). En este caso ese dato se utiliza para representar en el mapa mediante un punto todos los documentos que se seleccionen.
Formatos multiarchivo georreferenciados, tales como SHP o imágenes con ficheros world anejos, Se suben juntos y urbiGIS guarda los ficheros anejos como auxiliares del principal. Para urbiGIS el fichero .shp será el principal, los demás serán auxiliares.
Formatos multiarchivo georreferenciados de una mapa seriado. Se suben todos juntos y urbiGIS considera todas sus hojas como un documento único compuesto de tantas hojas como contenga la serie.
Direcciones URL a un fichero remoto o una página html. urbiGIS considera esta URL como un documento en si mismo.
Documentos carpeta. Son documentos virtuales que actúan como contenedores de otros documentos.

3) Todas las cuentas y usuarios de urbiGIS tienen la capacidad de establecer una estructura documental propia, de forma que siempre que se guarde un documento en cualquier elemento propiedad de esa cuenta se podrá utilizar dicha estructura.

4) Por supuesto todos los documentos (excepto las URL y Carpetas) son descargables con las restricciones de acceso o licencia de uso que su propietario haya establecido para el elemento que los contiene.

Acceso

En urbiGIS existen tres formas de acceso a los Documentos:

Desde el elemento que los contiene. En este caso es preciso llegar hasta el propio elemento para visualizar sus documentos adjuntos.
Desde la Consulta Gráfica. Utilizando el icono de consulta presentará los elementos identificados en el Panel de Datos:
Desde el buscador de Documentos. En la interfaz de urbiGIS se utiliza la pestaña de Documentos para buscarlos por diversos criterios: su nombre, el tipo de documento o el tipo de elemento al que está adjunto. Incluye un consulta gráfica propia que permite haciendo un clic sobre mapa obtener todos los documentos georreferenciados disponibles en ese punto.

Conclusión

urbiGIS propone ligar los elementos geográficos a los documentos que determinaron su origen, que informan de sus circunstancias actuales y que determinan su evolución futura, porque sin ellos no es posible comprender su papel sobre el territorio. Por eso incluye un Gestor documental sencillo y accesible que resuelve el problema sin necesidad de complejas integraciones y con plena garantía de integridad y seguridad para todo tipo de documentos.

Ignacio Arnaiz Eguren (Director)

Los gemelos digitales, un objetivo complejo

Fri, 17 Feb 2023 00:00:00 GMT

En los últimos meses estamos viendo como proliferan los llamados «Gemelos digitales». Su objetivo es obtener una copia digital de un objeto físico, de forma que enfrentando esa copia a situaciones diversas se pueda prever su comportamiento y resolver los problemas antes de que se presenten en el gemelo real. En este blog hay algunas entradas en las que sin hablar de gemelos se plantean soluciones similares (véase Componentes urbanos, y Activación de Componentes Urbanos). Sin duda en la industria son imprescindibles para testear sistemas antes de su entrada en producción. (Véase también El proyecto de edificación: ¿Un Autómata urbano virtual en el Internet de las Cosas?)

Además de en los sectores industriales los gemelos digitales están entrando con fuerza en los sistemas GIS, de la mano de las IAS y del big data. El territorio es una máquina inmensa (también hablamos de esto en la entrada Neurofisiología Urbana) , y por eso el concepto del Gemelo Digital es tan atractivo para los sistemas de gestión territorial. Si tuviésemos un territorio gemelo podríamos predecir los efectos de cualquier acción sobre su funcionamiento.

Pero ¿es posible construir un gemelo digital de un territorio? ¿Puede un sistema de inteligencia artificial ayudarnos hacerlo? Por lo que hemos visto hasta ahora los sistemas de IA en GIS se están utilizando para automatizar los procesos de identificación de estructuras y cambio territorial por teledetección. Ante la inmensa cantidad de información aportada por drones, vuelos y satélites, las IAS son una herramienta brutal para generar información vectorial 2D y 3D. Sin duda los procedimientos de restitución fotogramétrica manuales han pasado a la historia.

Los Gemelos humanos monocigóticos son casi idénticos, aunque en alguna medida (no soy un especialista) durante su desarrollo surgen mutaciones del genoma o cambios epigenéticos por factores ambientales y el envejecimiento que terminan por generar una diferencia. Asumamos también que el gemelo digital será, de forma generosa, «muy parecido» al real.

Para simplificar el problema vamos a descomponer el territorio en algunas cosas «sencillas de controlar» (no nos metamos en muchos jardines), supongamos que nuestros gemelos digitales del territorio tienen los siguientes órganos:

1.- Un sustrato físico, cuya forma se adapta continuamente a las necesidades derivadas del crecimiento y uso del territorio.

**2.- **Un despliegue de especies vegetales que responden a dos fuerzas a veces antagónicas: la constante diseminación natural y la siembra o distribución antrópica con propósitos productivos u ornamentales

3.- Varios sistemas que facilitan la actividad: comunicaciones superficiales o subterráneas desde sendas a enormes autopistas; sistemas de captación, tratamiento y distribución de agua; sistemas de evacuación y depuración de efluentes; sistemas de generación y distribución de energía eléctrica o hidrocarburos; sistemas de alumbrado nocturno; de telecomunicaciones digitales…

4.- Un conjunto de estructuras de actividad que van desde cabañas a grandes instalaciones industriales, a veces casi aisladas, pero normalmente formando densas urbes.

5.- Una asignación de derechos y obligaciones a personas o comunidades de personas, que determina su capacidad de uso y disfrute del sustrato y de las estructuras.

No quise meterme en muchos jardines pero esos cinco elementos tienen mucha miga, hay que tener en cuenta que además nuestro gemelo debe controlar en todos ellos los siguientes aspectos:

1.- Forma y posición: la cartografía del territorio debe identificar, medir y posicionar todos los elementos. No todos son visibles y algunos ni siquiera tienen una forma reconocible porque son relaciones o enlaces entre elementos. Aunque no sean visibles, conocer estos datos es crucial.

2.- Descripción y características: la capacidad de uso, de acción o de afección determinan la posible conducta, las posibilidades de interacción de cada elemento. Son aspectos que casi nunca se obtienen por teledetección y que deben ser objeto de carga individualizada, a veces son sencillos pero la tendencia es a que todo se complica.

3.- Proceso de creación: las actividades humanas y la propia naturaleza se encargan de añadir nuevos elementos de forma masiva, no puede ser que el gemelo dependa siempre de sistemas de teledetección para percibirlos. Al menos los producto de la actividad humana deben ser incluidos en el gemelo por los mismos procesos que se encargan de incluirlos en el gemelo real (en la entrada urbiThings y la Gestión de Expedientes en las Instituciones públicas del blog hablamos de estos procesos)

4.- Proceso de modificación: desde una tala de un árbol a una segregación de una parcela, pasando por la ampliación de un edificio, todo está sujeto a cambio constante, será también preciso conectar los procesos reales a los virtuales.

5.- Proceso de destrucción: suelen estar ligados a procesos de creación, para ellos también es preciso conectar procesos.

6.- Procesos de relación: todos los objetos están interconectados, en muchas ocasiones son relaciones topológicas que pueden resolver funciones GIS, pero la mayoría son relaciones no topológicas que generan una malla tridimensional que condiciona la función del modelo real. Generan un modelo jerárquico de un mundo donde nada existe de forma aislada.

7.- Restricciones y condicionantes de operación: determinan lo que puede o no puede ejecutar un elemento en cada momento, casi todos los elementos están sujetos a un cronograma lleno de dependencias internas. Son condiciones determinadas por la propia naturaleza del elemento, por disposiciones legislativas o administrativas o por acuerdos y contratos entre los agentes que tienen su control.

No tengo duda de que para una ciudad o un territorio concreto es posible capturar toda esta información. El territorio es un ámbito controlado (o presumiblemente controlado) por las Administraciones públicas y donde ellas no llegan pueden ayudar los procedimientos de colaboración público-privada. La colaboración activa de los ciudadanos y de las instituciones es un arma formidable para crear información y para seguir la dinámica territorial.

En este momento no hay condicionantes tecnológicos que impidan crear un ambiente cloud donde se puedan crear almacenes estructurados y seguros de datos, ni tampoco faltan las aplicaciones y la capacidad para crearlas nuevas si hacen falta. La dificultades están en coordinar a los productores de datos para que confíen en un sistema que los publica sin restricciones, hay una nula predisposición a compartir datos y por tanto todo es mucho más sencillo analizar una foto de satélite antes que conectar los procesos de uso territorial.

Siempre tengo la imagen de esa gran ciudad que alimenta sus bases de datos de edificación gracias a la imagen aérea en lugar de utilizar la inmensa cantidad y calidad de los datos que generan sus propios procesos administrativos.

Pero bueno, suponiendo que hayamos cargado nuestro gemelo con toda esta información (por supuesto acotada a un espacio y un momento determinados) y si nuestro propósito es utilizarlo para evaluar escenarios de cambio, entonces ese gemelo debe estar capacitado para computar en el tiempo de cada cambio, simulando verosímilmente los efectos que ese cambio produciría en el gemelo real. Es decir debe tener un simulador dinámico basado en tiempos y eventos que determine un estado futuro a partir de un estado actual.

Es también aquí donde el problema se agudiza, el gemelo no es solo una copia de formas físicas, es también una copia de funciones con capacidad de cómputo, con capacidad para resolver preguntas como ¿Cuánto costará el mantenimiento de los parques de un nuevo barrio, si la densidad estimada es de 45 viviendas por Ha.? o ¿Qué impacto tendrá el cambio climático en el gasto de energía de un sector y por ende en el dimensionamiento de sus redes eléctricas?

Conclusión

Para construir Gemelos Digitales de un territorio se necesitan nuevos sistemas de adquisición de datos capaces de utilizar la colaboración, nuevos modelos de datos capaces de asumir la complejidad territorial, nuevos marcos de relación entre las Administraciones y los Operadores territoriales para construir circuitos virtuosos de datos, nuevas herramientas de simulación de cambio y representación espacial. En otro caso estaremos usando GIS y sofisticadas IAs para fotointerpretar, una simplificación que tendrá una utilidad limitada a un espacio, un momento y un aspecto o sector territorial concreto pero no será un Gemelo Digital.

Cómo crear un Indicador ODS con urbiGIS

Tue, 12 Apr 2022 00:00:00 GMT

Dentro del proyecto de ODS Municipal que lideran el Instituto Arnaiz y la Federación Latinoamericana de Ciudades, Municipios y Asociaciones de Gobiernos Locales (FLACMA), se definen decenas de nuevo Indicadores ODS basados en un enfoque de localización y medición territorial de los problemas a nivel municipal, en contraposición al enfoque estándar de ODS, basado en la medición de la estadística socioeconómica tradicional a nivel nacional o estatal.

Los métodos de medición y cálculo de estos nuevos Indicadores ODS se implementan en urbiGIS mediante dos técnicas:

La espacialización de las áreas problema y datos básicos dentro de cada municipio. Un enorme trabajo para el que se cuenta con la colaboración voluntaria de estudiantes locales.
El recalculo automatizado de Indicadores a partir de los datos obtenidos durante el proceso de espacialización.

En esta entrada vamos a hacer una síntesis rápida de cómo es el proceso de recálculo desde que se parte con un conjunto de datos vacío hasta que se obtiene un Indicador en el Cuadro de Mandos de urbiGIS.

Para esta demo utilizaremos datos simples de obtener como la localización puntual de los hospitales existentes en el municipio, nuestros voluntarios deben situarlos como un punto a partir de información preexistente o mediante trabajo de campo, en este caso hemos utilizado los datos ejemplo del proyecto situados en Trinidad de Cercado (Bolivia):

En el mapa hemos dibujado con círculos grandes los Hospitales y los consultorios y centros de salud con pequeños. Para los Hospitales hemos asignado un radio de influencia de 1km, los demás tienen 500m. En municipios pequeños como éste no existe una red viaria utilizable para calcular rutas por métodos como Manhattan o Ruteo, así que utilizaremos el método Euclidiano para calcular al área de influencia de cada centro.

En urbiGIS crearemos un conjunto de datos de tipo Consulta que utilizará el radio asignado para crear un área de Buffer. Sobre su resultado crearemos otro conjunto de datos también de Consulta que realizará una Unión del buffer para obtener una única entidad. Como ambos son de tipo Consulta se actualizan automáticamente cada vez que se modifica el conjunto de Hospitales:

También disponemos de un conjunto de datos, igualmente de tipo Consulta, que delimita el «Área de huella urbana» y que ha sido obtenido haciendo una Unión de todas las áreas urbanas dibujadas por nuestro grupo de estudiantes, en la imagen siguiente vemos uno encima de otro:

Como se observa en la imagen el área de influencia de hospitales no cubre toda la huella urbana. Mediante otro conjunto de datos de tipo Consulta podemos realizar la Diferencia para obtener un Conjunto que solo tenga el «Área no cubierta por hospitales y clínicas», como resultado se ve en la imagen siguiente cómo la huella urbana está recortada:

El Indicador ODS que el proyecto de ODS Municipal ha planteado en este Objetivo es el «Proporción de superficie de Áreas residenciales alejadas de los centros asistenciales respecto de la superficie total de núcleos de población», para el Objetivo ODS a 2030 se debería conseguir que ese porcentaje sea cero o residual.

Para obtener los Indicadores el proyecto incluye cada uno dentro de un conjunto de datos con geometría de punto, en este caso reúne todos los del Objetivo 3 en un solo conjunto:

Para el cálculo de cada Indicador su registro correspondiente en ese conjunto de datos debe incluir una expresión SQL que obtenga el porcentaje de suelo a partir de dos conjuntos: («Área no cubierta por hospitales y clínicas» / » Área de huella urbana») * 100.

urbiGIS permite añadir a un conjunto de datos tantos «Campos calculados por expresión» como se necesiten, al editar el conjunto de datos esos campos especiales permiten que el usuario defina en ellos una expresión SQL del estilo de esta:

((select st_area(geom) from dts.»979df38c-9979-4474-8815-58ca8837f56c» where iden = 1)/(select st_area(geom) from dts.»82682e0f-f34b-4846-b390-6495a613d347″ where iden = 1))*100

Para simplificar su construcción, urbiGIS aporta un asistente de construcción de expresiones que permite buscar los conjuntos a operar e insertar sus identificadores y campos en la expresión. Desde luego es preciso conocer lenguaje SQL para asegurar su buen funcionamiento en otro caso presentará un mensaje de error.

El resultado se presentará en ese mismo campo del conjunto de Indicadores, en este caso el campo es «Calc» y el resultado un 72,32%:

Finalmente este resultado hay que presentarlo en el Cuadro de Mandos de urbiGIS seleccionando el indicador a presentar y sus propiedades. Una operación sencilla donde simplemente se escoge el tipo de gráfico a construir (en este caso un gráfico de texto simple), una select simple que devuelve el dato a presentar y los tipos de texto a utilizar. La select a utilizar es del tipo «select calc where code = ‘IT03-D6′» donde ese code identifica el Indicador que contiene la expresión de cálculo de entre todos los Indicadores que contiene el conjunto de datos.

Cualquier cambio en la Huella urbana o en la localización de Hospitales supondrá el recálculo inmediato del Indicador:

Conclusiones

En urbiGIS es posible construir procedimientos para obtener indicadores complejos a partir de conjuntos de datos simples y de conjuntos de datos producto de geoprocesos y consultas automatizados. Las únicas dificultades están en construir las sentencias de consulta para obtener el dato final o las sentencias de consulta para construir los cuadros de mando. En todo lo demás no hay que escribir ningún código y los resultados se presentan en geoportales temáticos organizados según los criterios de la organización propietaria de los datos.

Ignacio Arnaiz Eguren

Desde el GIS al NGS=Network gObjects System

Sat, 09 Apr 2022 00:00:00 GMT

Hace ya 9 años escribí una entrada en este blog a la que llamé GeoObjetos, una nueva forma de gestionar la información geográfica. Una ingenuidad sin duda, pero como no he aprendido nada en estos años, voy a rescatar la idea e intentar formalizarla un poco más en un ejercicio de fantasía geográfica. Antes de seguir es recomendable volver a leer esa entrada, pero si no lo haces volveré a definir lo que allí se denominaba geoobjetos pero de una forma más amplia y reduciendo su nombre a gObjetos.

Qué son los gObjetos

Nuestro mundo está formado por objetos, todo lo que vemos, lo que pisamos, los que existían antes del ser humano y los que hemos aportado nosotros, el propio mundo es un objeto. Estamos acostumbrados a percibirlos o investigarlos mediante sensores, nuestros propios sensores o los sensores que hemos inventado. Y somos capaces de colocarlos en una representación del mundo, antes hacíamos sobre papel, ahora de forma digital.

Todo el sistema está basado en un proceso: explorar – descubrir – analizar – representar. Todos lo hacemos constantemente y desde los primeros mapas hasta los sofisticados sistemas actuales el objetivo es que podamos utilizar las representaciones que han hecho otros, ya no necesitamos descubrirlo por nosotros mismos.

La cultura nos descubre el mundo. Pero por complicado que sea el sistema utilizado, su mecanismo por ahora sigue siendo básicamente el mismo: explorar – descubrir – analizar – representar. Como resultado para cada aspecto y espacio del mundo hay cientos, miles, millones de representaciones, todas iguales y todas diferentes, unas anticuadas y otras actualizadas, más o menos completas, mejor o peor simbolizadas, en 2D o en 3D. Los GIS nos ayudan a descubrirlas, construirlas y utilizarlas.

En la inmensa mayoría de los casos son representaciones que sólo incluyen elementos estáticos, aunque ya es habitual que las empresas y los ejércitos utilicen sistemas de control de flotas para representar objetos móviles, También podemos utilizar mapas de tráfico marítimo o de tráfico aéreo, que nos muestran en tiempo real la posición de los barcos o aviones obligados a llevar un transpondedor y nos proporcionan sus datos de identificación. Una explotación genial de todo eso son los mapas de tráfico rodado que nos permiten localizar densidades y velocidades de desplazamiento de smartphones con GPS sobre las vías e inferir a partir de ahí el estado del tráfico. Los usuarios en general no podemos acceder a los datos de cada smartphone, pero sin duda lo pueden hacer los gestores de las grandes plataformas de navegación.

Cambio de modelo

La propuesta de esta entrada es cambiar el proceso, no solo para los aviones, los barcos o los smartphones, sino cambiar el proceso para todo. Desde un árbol a un rascacielos. La información geográfica deja de estar repartida en millones de sistemas desconectados para ser un bien común accesible para todos y mantenido por todos. Los sistemas GIS seguirán sirviendo para visualizar, descargar, analizar y procesar datos geográficos pero tendrán un repositorio de gObjetos único y universal.

El nuevo modelo se compone de tres acciones:

1.- La exposición

En este mundo nuestro tan controlado, casi todo lo que tiene un valor económico está inventariado, identificado, medido y vigilado. Sus datos forman bancos especializados según su naturaleza, bancos que están divididos según la administración competente en su control. Datos públicos en muchos casos, pero privados en la mayoría y solo usables por quien ostenta su propiedad o competencia.

Supongamos que todos esos objetos adquieren una identificación. Internet nos ha enseñado que es posible asignar una dirección IP o una MACaddress a millones de máquinas y componentes de máquinas distribuidas por todo el mundo y a eliminar cualquier conflicto de duplicidad. En miles de servidores se replican constantemente esas listas para asegurarlo. Y no son solo dispositivos sino también transacciones identificadas mediante Blockchain. Ya no parece un problema insuperable disponer de un registro general de objetos de alcance global.

El registro global de gObjetos que propongo es parecido a un DNS pero no contiene nombres de dominio, contiene direcciones de gObjetos, será un NGS (Network gObjects System).

Y supongamos que el propietario del elemento o una institución con competencia sobre él le asigna ese identificador y lo declara en un registro global. Expone el elemento ante el mundo y aporta su contenido:

Tipo. Se ajustará a una lista convenida internacionalmente de tipos, un poco semejante a los sufijos de dominio, de forma que en las consultas sea posible discriminar que gObjetos se quieren obtener. La cartografía tradicional ya ha tipificado prácticamente todos los objetos del mundo, el NGS los unificará y reutilizará.
Descripción. Todo gObjeto debe ser capaz de autodescribirse ante sl NGS. Podrá ser tan completa y compleja como lo decida el expositor, desde un simple par de coordenadas a un objeto BIM complejo. Podrá ser adaptada por su expositor a las circunstancias de cada momento y puede representar el objeto de muchas formas simultáneamente. Por ejemplo el propietario de un edificio comercial puede adaptar la librea externa a su oferta, a la hora del día, a la época del año. O puede enlazar recorridos virtuales internos, mostradores digitales, elementos de realidad aumentada, enlaces a otros sitios o servicios. Por tanto cada gObjeto funciona como un portal de contenidos definido por su propietario.
Estado. Histórico, Actual o Futuro. De esa forma podemos ver la evolución en el tiempo de uno o varios gObjetos. También se podrán etiquetar como Dudosos o Provisionales.
Posición. Si el gObjeto cambia de posición puede actualizarla periódicamente según su velocidad, cada pocos segundos, cada pocas horas…
Representación. El propietario aporta la simbología o simbologías de representación que desee, adaptadas al formato de respuesta que se solicite. Si la respuesta es vectorial el cliente final podrá adaptar la representación a sus necesidades.
Propietario. Todo gObjeto tiene un propietario, una persona física o jurídica que ejerce un derecho real sobre el objeto, deberá incluir un certificado que identifica inequívocamente al propietario del gObjeto.

Si el gObjeto contiene un agente inteligente entonces será su lógica interna quien realice la exposición, el propietario no tiene que estar atento a exponer los cambios, el agente se ocupa. Si nuestro vehículo dispone de un agente podrá transmitir su posición y destino constantemente para obtener indicaciones de ruta óptima o de incidencias en la vía.

Una vez expuesto al NGS el gObjeto le informa en todo momento de cualquier cambio en su posición o propiedades.

El NGS es además una red de gObjetos, de ahí viene nuestra propuesta de cambio de GIS a NGS. Es una red porque cada gObjeto puede contener un número indefinido de Relaciones o links con otros gObjetos. Las relaciones establecen una conexión entre gObjetos. En sí mismas son también un gObjeto ya que pueden disponer de una geometría propia. Establecen un sentido entre los gObjetos que conectan, por eso en la relación unos gObjetos serán Origen de la relación y otros serán Destino de la relación. Cuando las relaciones son topológicas determinan su posición respectiva y, en el caso de ser adyacentes incluirán las reglas que debe cumplir la frontera que los separa. En todo caso el cumplimiento de esta reglas topológicas es responsabilidad de los propietarios de los objetos, el NGS es un mero testigo de ellas. Se plantean algunos de estos tipos de relación:

Destino y Origen se conectan bidireccionalmente
Destino se conecta unidireccionalmente con Origen
Destino está dentro de Origen
Destino está fuera de Origen
Destino es adyacente a Origen
Destino está encima de Origen
Destino está debajo de Origen
Destino es una consecuencia de Origen
Destino es una modificación de Origen

2.- La consulta

Ante una petición el NGS podrá actuar de dos formas:

Como enrutador: en este caso el NGS se limita a devolver la dirección del servicio que contiene los datos del gObjeto y será el servidor de su propietario quien resuelva la petición.
Como servidor: en este caso el NGS dispone de la información en cache del gObjeto y puede resolver la petición de forma directa.

Será el propietario de cada gObjeto el que decida si el NGS actúa de una u otra forma.

La naturaleza geo de los objetos que contiene el NGS determina la forma y el alcance de las consultas y responde a varios métodos de consulta:

Acceso a un gObjeto determinado. Se proporciona al NGS la dirección del gObjeto y el sistema devuelve la ruta a su propietario o directamente el contenido de su caché.
Acceso a los gObjetos relacionados con un objeto determinado. Se proporciona al NGS la dirección del objeto y el sistema devuelve todos los gObjetos relacionados con el tipo de relación
Acceso a todos los gObjetos presentes en el radio de un punto. Se proporciona al NGS la coordenada del punto, el radio de búsqueda y el tipo de objeto. El NGS devuelve las direcciones o datos de todos los gObjetos de ese tipo existentes en ese momento en el radio indicado.
Acceso a los gObjetos presentes en el radio de un punto. Se proporciona al NGS la coordenada del punto, el radio de búsqueda y el tipo de gObjeto. El NGS devuelve las direcciones o datos de todos los gObjetos de ese tipo existentes en ese momento en el radio indicado.

3.- La respuesta

En ambos casos se incluirá en la petición el formato deseado de la respuesta que será semejante a los que proporciona un Geoserver estándar: WMS o WFS y sus distintos formatos y los formatos 3DPS/I3S cuando el servidor sea capaz de proporcionarlos.

La respuesta del NGS se modulará en función de diversas consideraciones:

Puede devolver la geometría de los gObjetos en un formato estándar vector y deberá ser el cliente quien determine la forma y simbología de visualización 2D o 3D en función del tipo de geometría obtenida.
Puede devolver un escenario bidimensional ya simbolizado, tal y como la hace un servicio WMS, que el cliente se limite a presentar al usuario.
Puede devolver un escenario tridimensional ya simbolizado como un servicio VRML (véase Web3D Consortium)

El NGS, una vez identificados los objetos a devolver, puede utilizar dos estrategias para servirlos:

Puede disponer de una caché de gObjetos en sus propios servidores, de forma que no necesite solicitar ninguna información al proveedor del objeto. Esto será posible si el NGS dispone de recursos propios para almacenar millones de objetos y negocia con sus proveedores los métodos de actualización.
Puede enrutar la petición a los proveedores de gObjetos y servir sólo como intermediario entre ellos y los clientes. Esto descarga parte de la responsabilidad en los servicios propios de los proveedores (que no siempre estarán operativos) pero asegura disponer siempre de la última versión de cada objeto.

El NGS deberá establecer una estrategia para resolver los problemas del ámbito y la escala. En un servicio WMS convencional la cantidad de información suministrada al cliente es constante (el tamaño de la imagen que quepa en su navegador) y el servidor se ocupa de optimizar el tiempo y recursos a usar en la formación de la imagen según su escala, suponiendo que no haya cacheado previamente una pirámide de escalas que le evite formar una imagen para cada petición.

Un servicio WFS se ocupa de limitar la petición a un volumen máximo de objetos de forma que no atenderá peticiones con un marco geográfico excesivo que recargue la dimensión de la respuesta.

En el NGS no siempre es posible acudir al cacheado de los mapas ya que los gObjetos pueden moverse por el territorio a decenas o cientos de kilómetros por hora y por tanto el mapa se reconstruye con cada petición.
El NGS puede acudir a escenarios mixtos: proporcionar fondos de imagen fija para los gObjetos estables y puntos para los móviles con velocidades de refresco adecuadas a la escala y velocidad de los gObjetos que el cliente se encarga de simbolizar y superponer.
También puede proporcionar escenarios de imagen completa con actualizaciones incrementales de refresco. Es decir funciona como los servidores de escritorio remoto que solo transmiten la porciones de imagen modificadas en cada evento de cambio, en este caso sería con la frecuencia de refresco convenida con el cliente.

Cuando solicitamos a un DNS una dirección IP la consulta es sencilla, pero si el NGS actúa como servidor la consulta puede devolver cantidades muy importantes de datos.

Cómo funciona el NGS

1.- Diferencias frente a una IDE

Las infraestructuras de datos espaciales están bien, permiten acceder a información espacial a la que antes era imposible hacerlo. Pero tienen algunos problemas:

Dispersión: la información procede de fuentes muy diversas y nada controladas, la publicación de un nuevo servicio puede quedar oculta a sus usuarios potenciales si el proveedor no efectúa una acción voluntaria de publicidad. Los catálogos de geoservicios son también producto de la buena disposición de un colectivo o una persona. No disponen de medios de comprobación automatizados (como Google) para descubrir servicios.
Voluntariedad: los geoservicios son producto de la buena voluntad de los proveedores del servicio, no hay ninguna obligación legal o contractual para el mantenimiento del servicio. Incluso los servicios públicos como el Catastro o el PNOA son producto de la voluntad de la administración pública y de una carta de servicios con que la administración se autoobliga.
Estatismo: en el caso de los servicios WMS la simbología está determinada por el proveedor del servicio, el consumidor no puede modificarla.

Por contra el NGS proporciona soluciones para estos problemas aunque también es cierto que introduce otros nuevos. Las propiedades del servicio son las siguientes:

Es un servicio público proporcionado por la comunidad internacional de Internet similar a la existente para los servidores DNS.
Es un servicio permanente y estable, capaz de servir a millones de clientes con un alto grado de simultaneidad, esto implica unos recursos distribuidos de hardware, software y comunicaciones de enormes dimensiones.
Debe resolver el alcance y modo de respuesta a las peticiones de sus clientes. Los actuales LBS lo tienen fácil, se limitan a devolver una lista de coordenadas que representa la posición actual de móviles o navegadores por GPS en un radio determinado. El cliente se ocupa de presentar esas coordenadas al usuario con una simbología determinada.

2.- Quién aporta la información

La información expuesta en el NGS puede proceder de tres fuentes básicas:

Del propietario del gObjeto que tiene interés en exponer ante Internet las propiedades de su gObjeto y utilizar como punto de acceso a su oferta comercial, social, cultural o turístico.
De la institución pública competente para su utilización, vigilancia y control que tiene interés en presentar una visión actualizada y completa de su territorio.
De otras instituciones públicas o privadas que subsidiariamente y con el permiso de su propietario asumen la exposición del gObjeto de forma altruista.

3.- Problemas y sus posibles soluciones

Se pueden presentar varios tipos de problemas:

Que se expongan diferentes gObjetos ocupando el mismo espacio sin una justificación temporal o topológica convincente. En este caso el NGS puede recibir denuncias o notificaciones y exigir a quienes exponen esos gObjetos que resuelvan el conflicto. Mientras tanto los etiquetará como «dudosos».
Que se expongan gObjetos inexistentes o claramente diferentes de la realidad. En este caso el NGS puede recibir denuncias o notificaciones y adoptar la decisión directa de eliminar esos gObjetos.
Que se expongan gObjetos que han desaparecido del territorio y no se han dado de baja. En este caso el NGS puede recibir denuncias o notificaciones y adoptar la decisión directa de eliminar esos gObjetos.
Que existan objetos en el mundo real que no están expuestos en el NGS. En este caso el NGS podrá acudir a las fuentes actuales de datos geográficos para construir una primera versión temporal de esos gObjetos etiquetándolos como «provisionales». Una vez que su propietario los sustituya por versiones actualizadas serán eliminados.

Conclusiones

Los gObjetos y el NGS pueden proporcionar un mecanismo colaborativo de descripción del mundo que proporcione una visión actualizada y aumentada y supere los problemas que actualmente presentan los sistemas cartográficos vectoriales y de imagen convencionales.
El conocimiento y control del territorio ha sido posible gracias a los nuevos sistemas de información geográfica. Pero quienes están obteniendo ventajas reales de esa información no son los gobiernos, son las empresas privadas o las organizaciones de GIS abierto. Las empresas como Google Maps, Bing Maps o TomTom están adquiriendo cantidades masivas de información territorial que utilizan en su beneficio, incluso en ocasiones vendiendo esa información a los mismos gobiernos, incapaces de obtenerla por sus propios medios. Las organizaciones de GIS abierto como OpenStreetMap, OpenAccessMap, EcoZoom, Urban Commons, Wace (mapas de tráfico), FourSquare… están emergiendo constantemente para recopilar información de todo tipo, desde la colaboración humanitaria ante desastres hasta el intercambio de datos comerciales o de relación. Los NGS suponen un salto cualitativo y cuantitativo de enormes proporciones para el acceso a información geográfica.
La información territorial es un bien común y adquiere un nuevo papel: es liberable, es decir su propietario puede distribuirla sin coste gracias al NGS. Es colaborativa, es decir su coste de adquisición se puede distribuir entre millones de agentes haciéndolo cero en la práctica.
Todos estamos implicados. El territorio es el resultado de la actividad humana. Los nuevos mapas no solo sirven para conocer la forma física del territorio. También sirven para reflejar la actividad humana: los procesos de transformación del territorio. La planificación urbana y territorial, el control de la propiedad inmueble, su valoración e cargas impositivas, el control de la edificación y la urbanización. La gestión de las infraestructuras urbanas y el metabolismo urbano. Los procesos del mercado de bienes y servicios: la búsqueda y selección de la oferta y la demanda de toda clase de bienes. Los fenómenos culturales: el uso de los espacios públicos de relación, la realidad aumentada, el acceso a la cultura desde el mapa. El estado físico y de uso de los sistemas viarios, ferroviarios, aéreos o marítimos. El control del tráfico, los sistemas de navegación, la mejora del transporte público. La prevención y protección civil, el apoyo a la colaboración ante desastres naturales o accidentes y la mejora de la asistencia sanitaria. Todos somos simultáneamente consumidores y proveedores de información espacial en un mercado transparente.
El territorio ha pasado a ser un producto en Internet de la mano del GIS, el territorio y todo lo que contiene ha entrado en el escaparate comercial del mercado global.

En el mercado inmobiliario: desde el suelo al producto final la localización geográfica de los inmuebles y la visualización de su entorno ya es una necesidad imprescindible.

En la actividad comercial: localizar en el mapa ese comercio que tiene un determinado producto al mejor precio facilita extraordinariamente acceder a la ciudad.
En la actividad cultural y social: las redes sociales y la actividad cultural están haciendo un uso cada vez más intenso de los sistemas geográficos.
En el turismo virtual: cada vez hay más usuarios de los sistemas geográficos como medio para visitar países y ciudades remotas, un atractivo que potencia el turismo real.
En la gobernanza electrónica: la administración adquiere un mecanismo fundamental para publicar información espacial como el planeamiento urbanístico, los sistemas de transporte, la situación de las dotaciones y servicios, la información predial, los nombres y números de las calles y viales y para localizar la actividad, los diversos expedientes de gestión, las incidencias y alarmas, el control policial e innumerables otros aspectos.
El sistema pasa a ser el soporte espacial de la Smart City: se configura como el esqueleto al que se anclan todos los elementos y procesos que forman la ciudad: espacios tridimensionales como las calles, los edificios, las infraestructuras, los vehículos, incluso las personas son espacios fijos o móviles. La ciudad es, con seguridad, la máquina más grande construida por el hombre, una máquina compuesta de millones de piezas, cuyo perfecto engrane e interrelación es la piedra angular de su éxito como hábitat humano. Una máquina que metaboliza materia y energía, que crece y se renueva constantemente.

Ignacio Arnaiz Eguren

EL SIG Municipal, situación y análisis

Fri, 18 Feb 2022 00:00:00 GMT

Desde hace años, y lo hemos comentado en diferentes entradas de este Blog, algunos municipios están implementando lo que se llamó una IDE Local, en realidad un sistema SIG/GIS preparado no solo para publicar sino también para producir y administrar información geoespacial.

Lamentablemente hay pocos municipios que lo intenten, bien porque no disponen de los recursos suficientes o bien porque no existe un interés político en ofrecer este tipo de datos. Y peor aún, hay municipios que lo hacen y tras unos años cae en el olvido. Los cambios de legislatura son fatales para este tipo de servicios y eso que España bien puede presumir de un estamento funcionarial local estable y preparado. Si esto lo trasponemos a partes de mundo como Sudamérica donde el cambio de legislatura supone un reinicio completo de la maquinaria local, pues el resultado es catastrófico.

Lo cierto es que este tipo de dato ha sido tradicionalmente construido y publicado por organismos e instituciones geográficas supramunicipales, dado su alto coste y grado de especialización, a pesar de que es el municipio la fuente real de la mayoría de los datos espaciales de un territorio, y eso no ha favorecido que los municipios se impliquen en esta tarea.

Pero también es verdad que hoy día producir y publicar datos espaciales es mucho más sencillo, porque los sistemas colaborativos, las plataformas de SIG en la nube y los servicios abiertos de mapas globales o nacionales, proporcionan un entorno de trabajo a años luz de lo que disponían los geómetras hace poco más de veinte años. Con todo eso los municipios ya no tienen excusa para no ponerse las pilas en este aspecto.

Métodos de publicación de un SIG Municipal

A la hora de publicar un SIG los municipios tienen tres opciones:

Servidor y Datos propios: los servicios técnicos municipales disponen de un sistema SIG interno capaz de crear, almacenar y publicar datos espaciales.
Servidor ajeno y Datos propios: el municipio alquila una plataforma de servicios SIG y sube a ella sus datos.
Servidor y Datos ajenos: el municipio en realidad no participa ni siquiera en la creación de datos propios. Esta es la situación de muchos municipios españoles cuyo geoportal se sirve desde instituciones supramunicipales, normalmente fragmentando o enmascarando sus datos territoriales para que se contengan dentro del límite municipal.

Habitualmente los proveedores de plataformas SIG en la nube, salvo que sean institucionales o urbiGIS, suponen un coste para el municipio, bien por volumen de datos o por volumen de tráfico. Ese coste es complicado que lo asuman los municipios si no tienen una motivación elevada de transparencia y servicio público. Más aún cuando la legislación vigente exige que su contratación se realice mediante concurso abierto, lo que en la práctica hace imposible mantenerlo año tras año.

Hago la excepción de urbiGIS porque nosotros proporcionamos a todos los municipios un geoportal gratuito sin límites de volumen de datos ni de tráfico.

Por supuesto hay situaciones mixtas ya que los servicios web de mapas y datos permiten que en servidores propios o ajenos se publiquen capas que no son municipales, pero que ayudan a comprender o mejorar su contenido. En el caso de España, el Catastro y el PNOA son los ejemplos más significativos, aunque hay muchos más.

La situación actual

Para hacernos una idea del grado de implantación de los SIG municipales hemos utilizado urbiGIS como fuente de datos. En el cuadro siguiente hacemos por países un análisis de municipios con y sin un geoportal o al menos con o sin mapas publicados.

En urbiGIS se catalogan y ofrecen servicios abiertos de cualquier fuente, tanto sea pública como privada, casi hemos alcanzado los dos millones de mapas catalogados. En este caso solo se muestran los publicados por organizaciones públicas de ámbito local.

País

Administraciones de nivel municipal con capas SIG

Total de Administraciones de nivel municipal

United States of America

2.729

54.384

5,02%

Spain

377

8.240

4,58%

United Kingdom

159

8.735

1,82%

Poland

2.964

1,96%

Finland

311

14,79%

Germany

15.930

0,21%

Sweden

2.966

1,05%

Canada

5.000

0,60%

Netherlands

403

6,95%

France

36.295

0,07%

Italy

8.094

0,28%

New Zealand

247

8,50%

Denmark

15,15%

Colombia

1.130

1,33%

Portugal

4.588

0,33%

Brazil

5.644

0,27%

Czech Republic

6.261

0,22%

Argentina

1.545

0,84%

Norway

354

3,11%

Turkey

928

0,97%

Ecuador

988

0,91%

Mexico

2.442

0,33%

Lithuania

41,18%

Taiwan

381

1,84%

Costa Rica

680

1,03%

Australia

909

0,77%

Greece

325

1,85%

Switzerland

2.222

0,27%

Uruguay

125

4,00%

Ireland

291

1,72%

China

1.620

0,31%

Gabon

10,81%

Ukraine

122

3,28%

Pakistan

173

2,31%

South Africa

226

1,77%

Russian Federation

2.372

0,17%

Bulgaria

264

1,14%

Peru

1.841

0,16%

Vanuatu

100,00%

Croatia

124

1,61%

El Salvador

262

0,76%

Estonia

276

0,72%

Guatemala

340

0,59%

Bolivia

343

0,58%

Chile

346

0,58%

Venezuela

345

0,58%

India

3.212

0,06%

Romania

3.187

0,06%

Qatar

14,29%

Palestine

5,56%

Cape Verde

3,03%

New Caledonia

2,56%

Jordan

1,56%

Indonesia

1,04%

Iceland

119

0,84%

Island

119

0,84%

Malaysia

143

0,70%

Dominican Republic

155

0,65%

Slovenia

192

0,52%

Luxembourg

231

0,43%

Iran

291

0,34%

Belgium

642

0,16%

Panama

607

0,16%

Thailand

859

0,12%

Japan

1.780

0,06%

Philippines

1.709

0,06%

Austria

2.135

0,05%

Rwanda

2.155

0,05%

Total

3.806

198.984

1,91%

El cuadro sólo proporciona una idea aproximada por diferentes razones:

No siempre es sencillo decidir cuál es el nivel local en cada país, ya que su estructura administrativa es diferente a la española y la caótica terminología utilizada para cada nivel no ayuda.
No siempre es posible discriminar en cada servidor GIS si éste existe por una voluntad municipal explícita o es un producto supramunicipal más o menos asumido desde el nivel municipal.
En urbiGIS se realiza una exploración sistemática de Internet para descubrir servidores, pero es un trabajo muy grande que avanza despacio y no resulta sencillo automatizarlo, no sabemos con certeza cuál es el porcentaje explorado, pero seguramente el total existente será proporcional a lo hallado hasta el momento.
Solo se cuentan los servidores accesibles, suelen ser la mayoría, pero, sobre todo en Estados Unidos, hay servidores bloqueados a llamadas desde fuera del país o que sólo funcionan con usuario identificado. Los casos más sofisticados son los que establecen por el CDN (Content Delivery Network ) un retraso de unos segundos entre la petición y la respuesta, un retraso que inhabilita su uso normal como servicios o cuando exigen para acceder el relleno previo de un captcha, realmente una maldad inexplicable.
Tampoco se contabilizan los servidores con protocolos cerrados no estándar. Este tipo de servidores son habituales en empresas de servicios SIG en cloud del estilo de Carto, MapBox o SchneiderCorp. Resulta paradójico que instituciones públicas que por un lado se declaran transparentes por otro publican servicios únicamente accesibles desde sus aplicativos propios.

Conclusiones

Se observa que los porcentajes de Administraciones locales que publican mapas son bajísimos. Está claro que no es una prioridad municipal.
España ocupa un buen puesto en este ranking pero hay que tener en cuenta que más de un centenar de sus municipios solo publican las capas de Urbanismo en Red y en la mayoría de los casos son capas obsoletas.
Si analizamos la relevancia que los municipios prestan a los datos SIG en sus sitios web se presentan varias situaciones:

Que no digan nada de que hay un geoportal disponible. Puede parecer increíble pero la desconexión entre los técnicos SIG y los de diseño Web es muy frecuente.

Que haya un enlace para acceder al geoportal escondido entre las funciones de algún departamento del tipo “pinche aquí para acceder al mapa”. Un enlace que han puesto bien disimulado, quizá a propósito para que no se encuentre, no vaya a ser que no funcione.
Que exista un botón bien visible, pero dentro de la estructura departamental del municipio, si no se navega por ella, nunca se descubre.
Que en la pantalla principal de la web haya un botón o un enlace notorio a Mapas o a GIS. Este es un caso que solo se da en los portales de Estados Unidos, supongo que la necesidad de pagar una licencia para utilizar un producto GIS comercial les hace plantearse ofrecerlo bien visible. O sencillamente que en ese país la información espacial sí cuenta.
Viendo los motivos por los que el municipio monta un geoportal, la conclusión es que están en función de la necesidad del ciudadano para operar dentro del municipio:

Porque necesiten conocer los datos catastrales: este es el producto estrella, el caso del Catastro español es una excepción, lo normal es que sea una competencia municipal y es una partida fundamental de su presupuesto de ingresos.

Porque necesiten información sobre condiciones de la reforma o construcción de edificios. Sin llegar a la sofisticación normativa de España los mapas de Zoning y Future Land Use son sin duda los segundos del ranking.
Porque permitan evitar zonas de riesgo de inundación o incendio, son mapas fundamentales y no siempre están presentes.
Porque permitan conocer la situación de los servicios públicos, fundamentalmente de los colegios, policía y salud, ya que su posición suele influir en las decisiones sobre dónde comprar una vivienda o instalar una actividad.
Porque ayuden a comprobar la calidad de las infraestructuras: agua potable, saneamiento, luz y alumbrado, red viaria y parques.

Bueno, os animo a calificar la información espacial como un activo importante del Municipio. Que no se llegue a un dos por ciento de municipios que publiquen datos espaciales es bastante triste. Con urbiGIS no hay que preocuparse del coste y el incremento de gente capaz de crear información espacial en los últimos años ha sido espectacular porque la información colaborativa es la información del futuro.

Ignacio Arnaiz Eguren

Director

Open SDG/ODS Map

Wed, 12 Jan 2022 00:00:00 GMT

Qué es Open SDG/ODS Map (OSDGM)

En la inmensa mayoría de los municipios del mundo no es posible crear y obtener información espacial por la inexistencia de medios técnicos o humanos. Sin embargo, la colaboración ha demostrado que es capaz de cartografiar el mundo con la suficiente precisión y grado de actualización para que llegue a ser una herramienta extraordinariamente útil.

Pero siendo todo ello muy útil, no basta con describir la estructura física del territorio, las vías o los edificios, es necesario además obtener información sobre las condiciones de vida de sus habitantes y sobre el estado de su desarrollo.

Los SGD/ODS Objetivos de Desarrollo Sostenible están incidiendo profundamente en muchos gobiernos para mejorar esas condiciones de vida y de desarrollo, y lo hacen mediante estadísticas demográficas y económicas, pero no miden ni localizan espacialmente los problemas.

OSDGM se propone como un sistema colaborativo y abierto, sobre la plataforma de urbiGIS, para identificar, delimitar y medir los espacios donde las condiciones de vida y desarrollo de sus habitantes deben ser objeto de mejora.

OSDGM es un sistema dinámico, sus delimitaciones o “entidades” tienen nombre y fecha y no se hacen una vez, sino que se hacen tantas veces como sea necesario para evaluar su mejora temporal.

Cuando un colaborador de OSDGM aporta una entidad al sistema, es preciso que la identifique, date y anote la deficiencia observada. Él mismo o cualquier otro colaborador si observa cambios sustanciales de incremento o decremento de ese espacio aportará una nueva versión anotando su nueva delimitación y fecha. De esa forma todo espacio en OSDGM tendrá tantas versiones como cambios significativos se hayan observado a lo largo del tiempo.

Las alteraciones en el tiempo de las entidades marcarán la tendencia hacia el cumplimiento de las metas SGD.

Cada una de las entidades además se debe asignar a alguno de los territorios administrativos definidos de forma global en urbiGIS, de forma que sea posible el análisis tendencial por unidad administrativa simple o agrupada, siguiendo la escala jerárquica administrativa.

Cómo colaborar con Open SDG/ODS

Cualquier persona individual o un colectivo pueden colaborar con OSDGM, no existe ninguna restricción ni limitación salvo la verificación por el administrador de OSDGM de la calidad e idoneidad de la información aportada.

Para colaborar es preciso ser usuario de urbiGIS rellenando la solicitud de registro en http://urbigis.com/opensdg.maps.

Si es usted miembro de un colectivo el administrador de ese colectivo le indicará el nombre y contraseña del usuario que debe utilizar.

Desde nuestro punto de vista estos colectivos deben asimilarse a ámbitos administrativos de nivel municipal, barrio o similar, entendiendo que son los habitantes de esos territorios quienes mejor lo conocen y pueden evaluar sus necesidades.

Modo de Operación

urbiGIS proporciona un entorno de trabajo colaborativo basado en los siguientes componentes:

Inventario de espacios SDG/ODS: contiene todos los espacios delimitados como entidades, cada espacio forma una “Entidad del Inventario”. Las Entidades tienen una denominación que alude a la toponimia del paraje o lugar donde se sitúan. Se caracterizan mediante cuatro atributos:

Tipo: se ajusta a los tipos que se definen más adelante

Fecha: día de la toma de datos
Autor: nombre de la persona que se hace responsable del dato (voluntario)
Justificación: breve explicación de la situación

Las Entidades pueden tener diferentes versiones y a cada una se pueden adjuntar los documentos de cualquier tipo que ayuden a justificar su delimitación (fotografías, mapas, informes…)

Operación SDG/ODS: contiene las Entidades que un colaborador quiere aportar al Inventario. Pueden ser operaciones de inserción, modificación o creación de versión.

Los espacios del Inventario no pueden ser eliminados, pero pueden tener una última versión sin geometría en cuyo caso se entiende que para esa versión el problema ha quedado resuelto.

Los colaboradores pueden tantas Operaciones contra el Inventario como necesiten, una vez estimen que han quedado correctamente definidas las dan por finalizadas y tras una verificación por los administradores del Inventario serán aceptadas, en cuyo caso se ejecutan las operaciones, o rechazadas en cuyo caso se remiten al editor para que las reformule.

No existe limitación en el número de colaboradores, la única condición es que aporten una cuenta de correo verificable.

No existe limitación en el número de espacios a incluir en una Operación, sin embargo, la inspección previa a su ejecución verificará que son aparentemente aceptables y que no entran en conflicto con espacios delimitados previamente.

Para la delimitación de los espacios los colaboradores podrán utilizar todos los servicios de mapas y datos disponibles en urbiGIS. Incluidos los que resulten del proyecto ODS-Municipal actual en curso por parte del Instituto Arnaiz en muchos municipios de Sudamérica.

Para una explicación más detallada del modo de operación véase el documento de “Manual de Operación del colaborador de Open SDG/ODS Map” o el «Manual de paso a paso de SDG/ODS Map«

Tipos de entidades en OSDGM

Las entidades son siempre polígonos cerrados y se corresponden con los diferentes SDG:

Objetivo 1: Fin de la Pobreza

Espacios de desarrollo informal

Espacios con urbanización inexistente o muy deficiente

Objetivo 2: Hambre cero

Espacios agropecuariamente productivos no explotados

Espacios agropecuariamente productivos insuficientemente explotados

Espacios alejados del comercio alimentario

Objetivo 3: Salud y bienestar

Espacios alejados más de 15 minutos de centros de salud

Espacios con suelos y aguas subterráneas contaminados

Espacios afectados por contaminación acústica

Espacios afectados por contaminación aérea

Objetivo 4: Educación de calidad

Espacios a más de 15 minutos de centros docentes primarios

Espacios a más de 30 minutos de centros docentes secundarios

Objetivo 5: Igualdad de género

Espacios con alta violencia y criminalidad

Espacios a más de 15 minutos de centros de asistencia

Objetivo 6: Agua limpia y saneamiento

Espacios sin abastecimiento de agua limpia

Espacios sin recogida de aguas residuales

Espacios con vertidos incontrolados

Objetivo 7: Energía asequible y no contaminante

Espacios sin suministro eléctrico o con suministro deficiente

Objetivo 8: Trabajo decente y crecimiento económico

Espacios de interés económico no desarrollados

Espacios con alto índice de desempleo

Objetivo 9: Industria, innovación e infraestructura

Espacios sin acceso a telecomunicaciones o muy deficientes

Espacios con dificultades de accesibilidad

Objetivo 10: Reducción de las desigualdades

Espacios con infravivienda

Espacios alejados de los equipamientos sociales

Objetivo 11: Ciudades y comunidades sostenibles

Espacios sin ordenación urbanística

Espacios sin acceso a la red de transporte

Espacios con tráfico congestionado

Espacios sin servicios de limpieza urbana

Objetivo 12: Producción y consumo responsables

Espacios sin recogida de residuos sólidos

Espacios con vertederos incontrolados

Espacios con recursos naturales sobreexplotados

Objetivo 13: Acción por el clima

Espacios afectados por riegos de origen natural

Espacios afectados por riesgos de origen antrópico

Objetivo 14: Vida submarina

Espacios marinos contaminados

Espacios con recursos hídricos sobreexplotados

Objetivo 15: Vida de ecosistemas terrestres

Espacios con peligro de reducción de la biodiversidad

Espacios afectados por especies invasivas

Objetivo 16: Paz, justicia e instituciones sólidas

Espacios muy alejados de los centros de gobierno y seguridad

Espacios con viario sin alumbrado

Espacios sin control jurídico o administrativo

Objetivo 17: Alianzas para lograr objetivos

Espacios que no contribuyen fiscalmente

Espacios que deberían ser objeto de apoyo de cooperación internacional

Mapa urbanístico de España

Tue, 14 Dec 2021 00:00:00 GMT

En urbiGIS hemos iniciado una línea de trabajo para crear geoportales temáticos explotando su Catálogo de servicios de Mapas (que ya va en camino de los 2 millones de mapas)

El primero que hemos hecho es el Mapa Urbanístico de España, reuniendo en el geoportal los mapas de planificación publicados por las comunidades españolas, las diputaciones, los municipios y el Sistema de Información Urbanística del Ministerio de Transportes y Agenda Urbana. El geoportal está a vuestra entera disposición sin ninguna restricción de uso.

Estamos seguros de que es una herramienta formidable para contrastar el encaje del planeamiento de municipios adyacentes o para superponer mapas procedentes de distintas instituciones. En esta tareas serán también muy útiles las funciones de urbiGIS para dividir la pantalla, deslizar capas, establecer transparencias, seleccionar y reordenar capas…. Sin olvidar que aunque el geoportal se especializa en mapas de planificación, siguen estando disponibles los casi dos millones de capas restantes.

De los mapas de planificación que ofrece un servidor hemos escogido los que según nuestro criterio son los más útiles, eso no quiere decir que hayamos acertado, en cualquier caso todos los demás mapas no seleccionados siguen estando disponibles utilizando el buscador de Mapas (por nombre, territorio, cuenta que lo publica, tema o tipo).

Hasta el momento el geoportal contiene 3.143 mapas organizados por comunidades, provincias y municipios, pero seguimos buscando. Por ahora hemos encontrado Mapas en 309 municipios. También hemos incluido mapas sobre afecciones, protecciones, propiedad y ortofotos que suelen ayudar al urbanista.

A partir de este trabajo hemos obtenido algunas conclusiones:

1) Más allá de la diversidad normativa y terminológica inducida por las legislaciones regionales, la conclusión es que existe una enorme dispersión de contenidos, nomenclatura y simbología. Como consultor principal del programa de Urbanismo en Red me satisface ver que después de una década de su defunción aún siguen en pie muchos servidores y que ofrecen una visión bastante homogénea del planeamiento. Desgraciadamente hay muchos servidores que ya no funcionan, sin duda por obsolescencia del hardware, las dificultades para mantener el sistema en funcionamiento y la falta de actualización de los datos.

2) Los Municipios no disponen de medios para publicar sus planes salvo como documentos PDF. De esta limitación solo se salvan los grandes porque son capaces de pagar las licencias de los servidores o de mantener equipos humanos especializados. Algunas Diputaciones han hecho un esfuerzo de apoyo a los municipios (Albacete, Orense, Valladolid..). Las que funcionan lo hacen bien y en algunos casos incluso han invertido en actualizar y ampliar los datos. Aunque nuestra propuesta es que confíen en plataformas cloud como urbiGIS para que sus presupuestos se concentren en actualizar datos y no en mantener plataformas de publicación.

3) Siempre planea la pregunta de porqué no existe una plataforma nacional que ofrezca esta información. No parece posible, quizá en todo caso pueda existir una por cada región, teniendo en cuenta que las Instrucciones Técnicas para la redacción del planeamiento deben incrementar su grado de normalización y homogeneidad. Sin embargo, la renovación del planeamiento es tan lenta que eso tardará muchos años y no siempre las Instrucciones están orientadas a obtener materiales GIS. El mejor ejemplo es el SIU que, solo con grandes esfuerzos, consigue mantener un mapa continuo nacional y con un alcance muy simple. Así que por ahora este geoportal seguirá siendo necesario.

4) No siempre es factible saber si el Mapa ofrecido es realmente el vigente, a veces se aprueba un nuevo Plan pero no se actualiza el servidor de Mapas. Por supuesto es casi imposible que el Mapa sea un refundido actualizado de la situación y no existen metadatos que informen de este aspecto. Desgraciadamente todos estos servicios son orientativos y así lo avisan explícitamente en muchos casos. Por ahora hemos intentado no incluir planeamiento en tramitación, es sencillo cambiar el criterio, pero siempre se corre el peligro de ofrecer datos obsoletos.

5) Ya hemos comentado en otras entradas de este blog el problema de la calidad jurídica de los planes digitales (podéis ver la de Planificación digital, la solución de urbiGIS – Info urbiGIS). Este geoportal por supuesto no mejora nada la situación, salvo para poner de manifiesto la necesidad urgente de que haya una solución al problema, y preferiblemente con alcance nacional.

6) Este geoportal es una recopilación de mapas ofrecidos por servidores remotos, solo algunos pocos se ofrecen directamente desde la plataforma de urbiGIS. Esto supone que no siempre esos servidores responden rápido, a veces hay que bajar el zoom para poder ver un mapa, otras veces dejan de responder sin más, porque se han caído o porque su administrador los ha remodelado. Por favor en esos casos enviadnos una nota para repararlos en la medida de nuestras posibilidades.

**7) **Las denominaciones de los mapas son las establecidos por el administrador de cada servidor y no siempre son muy inteligibles. Hay que tener en cuenta que los diseñan para ser vistos por sus propios visores y no piensan en que pueden ser reutilizados por otras plataformas (¡aunque son servicios OGC o abiertos!). Por eso no nos culpéis de los nombres crípticos de alguno de los mapas. En todo caso también intentaremos interceder ante esas fuentes para que los simplifiquen. Con cuidado porque no descarto que cuando vean que sus mapas se ven en otros visores los cierren.

No más rollo, por favor si conocéis mapas que no hayamos incluido o tenéis cualquier comentario, enviadnos un correo a info@urbigis.com o incluirlo como comentario en esta entrada (si queréis que ese comentario sea público). Nosotros empezaremos a recopilar mapas para otros geoportales temáticos como Cultural, Turístico, Educación, Salud, Industrial, Residencial…

Ignacio Arnaiz Eguren

Director

Cuadros de Mando en urbiGIS

Mon, 26 Jul 2021 00:00:00 GMT

Cada día es más necesario presentar nuestra información geoespacial de forma intuitiva. Para ello los Cuadros de Mando nos ayudan a sintetizar indicadores y gráficos dinámicos y atractivos. Desde urbiGIS llevamos tiempo trabajando en un sistema de gráficos que sea sencillo y potente al mismo tiempo.

Nuestros primeros esfuerzos ya están visibles, aún falta mucho por hacer para que la interfaz de diseño sea más completa y potente, pero las bases de funcionamiento ya están creadas.

Por ahora solo es posible crear gráficas de mando sobre los Conjuntos de Datos, en una segunda etapa los ampliaremos para que también se puedan hacer sobre los Inventarios.

Hemos decidido utilizar como plataforma de desarrollo Google Charts que nos ofrece una funcionalidad suficiente y una integración aceptable en nuestro modelo de datos y nuestra interfaz de trabajo.

El procedimiento es sencillo. Se selecciona el Conjunto de Datos sobre el que trabajar y se hace clic sobre la opción de «Editar Gráficos»:

El sistema presentará la lista de gráficos asociados al Conjunto de Datos y su menú de opciones permite agregar o editar gráficos seleccionando sus propiedades:

– El título del gráfico

– El tipo: líneas, áreas, barras, columnas…

– La consulta: una query que sirva para obtener los datos a representar

– La lista de opciones del gráfico: dimensiones, colores, textos…, siguiendo las guías de opciones definidas por Google Charts

Una vez definidos todos los gráficos del Conjunto y guardados sus datos se ejecuta la opción de «Mostrar los Gráficos», bien desde el panel de Conjuntos de Datos o bien desde el buscador de Conjuntos de Datos.

Los gráficos se presentarán en el Panel inferior de Datos y se ordenan rellenando el espacio disponible según sus dimensiones. Si son muchos será preciso ampliar el panel o utilizar la barra de deslizamiento vertical para llegar a verlos todos. Hay que tener en cuenta que intentamos que los usuarios no tengan que programar un Cuadro de Mandos donde cada pieza encaja perfectamente en un panel, ya que eso supondría complicar de forma innecesaria la estructura del Panel de Datos.

En la imagen siguiente vemos a la izquierda el panel de diseño de Gráficos con tres gráficos definidos, a la derecha el panel de Escritorio que presenta el mapa con el Conjunto de Datos seleccionado (o de cualquiera de los mapas que se hayan generado con sus datos) y en la parte inferior el Panel de Datos con los tres gráficos creados para ese Conjunto.

A partir de aquí se abren muchas posibilidades para ampliar la funcionalidad inicial, con nuevos tipos de gráficos, con gráficos de tipo tabla, con gráficos de tipo datos unitario, con leyendas interactivas, con integración entre el mapa y el gráfico, con un constructor interactivo de consultas, extendiendo la posibilidad de gráficos que hagan join entre varios conjuntos de datos…

Conclusión

El objetivo es conseguir un sistema potente y sencillo que facilite al usuario construir Cuadros de Mando interactivos y creo que estamos en la vía correcta para conseguirlos y recuerde que utilizar urbiGIS es gratuito y solo es preciso solicitar una cuenta de usuario.

Ignacio Arnaiz Eguren

Director

Compruebe si los mapas de su Organización están en el Catálogo de urbiGIS

Thu, 15 Jul 2021 00:00:00 GMT

urbiGIS explora constantemente Internet para incluir en su Catálogo de mapas todos los servicios abiertos disponibles como una especie de IDE global para buscar y visualizar mapas. En esta entrada del blog voy a repasar cómo puede usted verificar si el Catálogo tiene o no sus mapas y qué casos se pueden presentar.

Comprobar si sus mapas ya están incluidos en el Catálogo:

Abra http://urbigis.com y siga estos pasos:

Si su organización no está presente en la lista de cuentas es que no hemos encontrado ningún mapa suyo en Internet. Si está presente pero la lista de mapas no muestra ninguno o solo uno es porque desde urbiGIS hemos creado su cuenta de forma automática. Este caso se da en los municipios para los que urbiGIS ha creado un geoportal por defecto (los de España, Portugal y todos los países de LATAM). Puede comprobar cómo funciona ese geoportal buscándolo en el módulo izquierdo de Geoportales y abriéndolo.

Haciendo clic en cada mapa de la lista de Resultados, el sistema hará zoom a su extensión y en su menú de opciones utilizando la «Vista previa» podremos visualizarlo en el mapa. Si deseamos dejarlo fijo en el Escritorio active su casilla y pulse el botón + para incluirlo en el Escritorio.

Si sus mapas ya están incluidos en el Catálogo se pueden dar varios casos:

Que usted no desee que sus mapas estén incluidos en el Catálogo de urbiGIS: en este caso remita un correo a info@urbigis.com indicando en el asunto su deseo de “Excluir mis mapas de urbiGIS” y la denominación de su organización. Iniciaremos un procedimiento de verificación de su identidad y si todo es correcto esos mapas se extraerán del Catálogo. Para que esto no vuelva a ocurrir les aconsejamos que activen algún tipo de protección de acceso en su servidor puesto que en realidad no son datos abiertos.
Que usted no tenga reparos a que sus mapas estén en el Catálogo, pero no desea que sean públicos. En este caso hay dos opciones: la primera es que una vez verificada su identidad nuestro equipo modifique la licencia de uso de todos esos mapas a “Privado de la Cuenta” y solo quedarán accesibles a los usuarios de su organización y la segunda es que solicite al equipo de urbiGIS un usuario administrador de su organización y sea usted mismo quien determine para cada mapa si es público (con alguno de los tipos de licencia de uso estándar) o si es privado.
Que usted esté de acuerdo con la situación actual de sus mapas, pero compruebe que hay defectos: no están todos, hay entradas obsoletas, algunos no funcionan, no están bien metadatados, etc. En este caso también hay dos opciones: la primera es que una vez verificada su identidad nuestro equipo corrija los defectos que nos señale en un correo a info@urbigs.com y la segunda es que solicite al equipo de urbiGIS un usuario administrador de su organización y sea usted mismo quien rectifique los datos.

Si sus mapas no están incluidos en el Catálogo también hay varios casos:

Que no tenga interés en que sus mapas se incluyan nunca en el Catálogo. En este caso remita un correo a info@urbigis.com indicando en el asunto su deseo de “No incluir mis mapas en el Catálogo de urbiGIS” y la denominación de su organización. Iniciaremos un procedimiento de verificación de su identidad y si todo es correcto se bloqueará la inserción futura de sus mapas en el Catálogo. En este caso será preciso que nos indique la URL o URL’s del servidor de mapas de su organización. También será aconsejable que establezca políticas de acceso a su servidor.
Que tenga interés en que sus mapas se incluyan en el Catálogo. En este caso remita un correo a info@urbigis.com indicando en el asunto su deseo de “Incluir mis mapas en el Catálogo de urbiGIS” y la denominación de su organización. Iniciaremos un procedimiento de verificación de su identidad y si todo es correcto se realizará la inserción inmediata de sus mapas en el Catálogo. En este caso será preciso que nos indique la URL o URL’s del servidor de mapas de su organización y que esos servidores estén abiertos.

En resumen

Recuerde que además usted puede solicitar a urbiGIS un geoportal propio que presente sus mapas y cuantos mapas vinculados de otras organizaciones le parezcan útiles a sus usuarios. En estos casos además será preciso solicitar en info@urbigis.com el alta de un usuario administrador de su organización que gestione sus mapas.

Con ese usuario también podrá crear o importar conjuntos de datos y utilizarlos para generar servicios de mapas, colecciones de mapas y servicios de localizadores propios.

urbiGIS es un servicio gratuito que facilita de forma global el acceso a información geoespacial de fuentes múltiples y que le aporta la posibilidad de crear y publicar información espacial sin necesidad de disponer de un sistema propio, sin tener que alquilar un sistema externo y sin tener que generar código para crear un visor.

Ignacio Arnaiz Eguren

Director

Algunos comentarios sobre los Servicios geoespaciales y las IDE/SDI

Thu, 01 Jul 2021 00:00:00 GMT

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).

Sobre las IDE

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.

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).»

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.

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.

Sobre los Servidores de datos geoespaciales

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.

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.

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.

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.

Nuevos geoservicios: geoSCADA

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.

Conclusión

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

ODS Municipal: territorializando los ODS

Wed, 02 Jun 2021 00:00:00 GMT

Ya he comentado en varias entradas de este blog los temas de ODS (Los Objetivos de Desarrollo Sostenible necesitan mapas, Una propuesta de Indicadores ODS locales: el caso de Tulancingo de Bravo (México) y Nuevos Indicadores ODS locales como resultado de la gestión territorial). En esta entrada voy a comentar cómo estamos enfocando desde urbiGIS la ayuda a los municipios para que puedan afrontar su papel en las metas ODS. Un papel que es fundamental porque los gobiernos locales son la fuente básica de datos territoriales.

Lo estamos haciendo con el proyecto ODS Municipal, bajo el liderazgo del Instituto Arnaiz y los convenios suscritos con el Consejo Consultivo y de Fomento de FLACMA (Federación Latinoamericana de Ciudades, Municipios y Asociaciones Municipalistas) que llevará a cabo el impulso del Proyecto y la parte operativa de ayudas económicas y con la colaboración de sus expertos. Puedes ver un ejemplo en el geoportal de ODS Maps Un ejemplo de contenido y estructura.

El proyecto ODS Municipal enfoca la localización de los ODS desde una óptica muy diferente de la habitual. En este momento los municipios están hablando de localización de los ODS como la alineación a cada Objetivo de los proyectos y programas de la agenda municipal. Estiman que su contribución a los ODS es proporcional al número o presupuesto de acciones susceptibles de ser alineadas con ellos. Su método consiste primero en formar la agenda municipal y después verificar su alineación con los objetivos. Si además tienen alguna métrica socioeconómica de ámbito local procedente de órganos estadísticos nacionales o locales que pueda asimilarse a los indicadores ODS, entonces mucho mejor, porque así podrán implementar un cuadro de mando muy correcto. Si además pueden distribuir los proyectos o datos por distritos, barrios o secciones censales, que son delimitaciones espaciales preexistentes, entonces, además, ¡tendrán un mapa!

Pero el proyecto de ODS Municipal propone un método muy diferente. Pretende realizar un análisis territorial que identifique, delimite y mida las dimensiones de los problemas existentes directamente desde la óptica de los Objetivos y con esos datos espaciales generar indicadores locales específicos, de forma que se puedan priorizar, justificar, programar y cotizar nuevas acciones de mejora en orden a conseguir recursos económicos nacionales e internacionales para su desarrollo. Así que este proyecto primero mide y documenta los problemas y después propone las acciones justificadas que debería acometer la agenda municipal.

Identificar y medir

Si nuestro municipio es económicamente fuerte y está bien organizado, es probable que ya disponga de una cartografía municipal, siempre un poco o un mucho atrasada frente a la realidad, pero en este caso es poco probable que necesite resolver necesidades de aquí al 2030, más allá de las derivadas del cambio climático o la pandemia. Y aunque este gran municipio tuviese algunos problemas, su estupenda cartografía bien poco le servirá para identificarlos, porque las cartografías al uso no suelen servir para saber dónde hay hambre, ni si faltan comercios de alimentación, ni dónde la atención sanitaria es débil o inexistente, ni dónde faltan escuelas o hay problemas de igualdad y seguridad, mucho menos nos dirá si hay accesos adecuados, si falta agua limpia, si no hay saneamiento o alumbrado público, o si las actividades económicas son suficientes o sostenibles, si la explotación agrícola, ganadera o forestal es la adecuada, y no hablemos de los riesgos ambientales o de la protección de los sistemas naturales y del adecuado aprovechamiento de los servicios de los ecosistemas.

Pero lo más probable es que nuestro municipio, aunque no tenga gran utilidad para nuestro caso, nunca haya tenido una cartografía y nadie la ha echado en falta porque hay otros problemas más urgentes, ni siquiera el órgano cartográfico nacional ha llegado hasta él, puede que sea porque es muy remoto, o es pequeño y proporciona pocos votantes, o puede ser que sea porque es demasiado grande, pobre y mal organizado o lleno de informalidad. Lo importante es que estos municipios son precisamente los que se enfrentan al desafío del 2030 y aunque probablemente todos sus habitantes sepan dónde están los problemas, unos porque los sufren y otros porque intentan resolverlos con pocos medios, ninguno es capaz de medirlos y mucho menos de sensibilizar a quien puede resolverlos.

Por tanto no siempre es fácil para los municipios hacer un balance de sus problemas, en los grandes porque el tamaño incrementa las dificultades y en los pequeños porque no disponen de medios. En este escenario, si algo realmente positivo han hecho los ODS ha sido poner blanco sobre negro cuáles son los problemas a identificar y medir y establecer un estándar universal para hacerlo. Pero es un estándar pensado por la estadística socioeconómica al uso, bien aplicable a naciones o estados, pero no es frecuente que lo sea en los territorios municipales. Por eso este proyecto aporta nuevas formas de medir lo que está pasando dentro de un municipio y en consecuencia generar nuevos indicadores que permiten verificar el avance hacia las metas ODS pero desde una óptica municipal.

Así que nuestro objetivo con este proyecto de ODS Municipal es aportar esas nuevas técnicas para identificar problemas, técnicas que deben ser sencillas y asumibles económicamente por cualquier municipio. Se basan en la colaboración y en delimitar áreas problemáticas sobre una ortofoto y con un paseo a pie de calle. Ponemos a un montón de jóvenes y ciudadanos a coleccionar los problemas de su ciudad, les enseñamos cómo repartirse el territorio por grupos, cómo caracterizar los problemas, cómo deslindarlos y dibujarlos en un GIS. Siguiendo un método unificado en todos los municipios, obteniendo información agregable y normalizada, campaña tras campaña para seguir su evolución, y publicados como mapas e indicadores ODS locales. Creemos que la colaboración es la fórmula mágica para obtener datos.

Estos grupos colaborativos no necesitan la cartografía tradicional, si la hay, bienvenida sea, pero pueden funcionar solo con una ortofoto que permita interpretar los rasgos principales del terreno. Puede ser una imagen satelital sin nubes con una resolución alta (ya pueden llegar a 25cm de pixel), o un ortofotoplano volado de 25cm a 50cm, o mucho mejor esas maravillas que se hacen ahora con drones, Pero no hay que tener paranoias de pixel minúsculo, es preferible una ortofoto limpia y completa de media resolución que un montón de vuelos de dron fragmentarios de altísima resolución. Lo que no se distinga en la foto, ya se distinguirá sobre el terreno.

Tampoco hace falta levantar las redes de agua o saneamiento, simplemente delimitar dónde hay gente viviendo sin agua limpia, no es preciso realizar un inventario exhaustivo de la edificación urbana, solo identificar dónde hay infravivienda, ni disponer de una versión digital de la planificación, solo poder deslindar la informalidad. Intentaremos aprovechar al máximo la información preexistente siempre que sea veraz y actual. OpenStreetMap es el ejemplo vivo de que la colaboración es y será cada día más una fuente inestimable de datos.

Nuestros colaboradores utilizarán urbiGIS que está configurado en cada municipio como un proyecto ODS Maps que contiene todos los conjuntos de datos necesarios y los mapas correspondientes. Se utiliza urbiGIS porque es gratuito y de uso sencillo y como funciona en la nube solo necesitan Internet y una computadora, no siempre es posible disponer de una, pero cada día son más accesibles. Los colaboradores se formarán en el uso de las herramientas y en las técnicas de recolección de datos, aprenderán cómo se manejan los datos espaciales y cómo se analizan, entenderán los principios de los ODS y su importancia y sobre todo se sensibilizarán sobre las necesidades de su territorio y aprenderán a verlo como una oportunidad de futuro y no como un lugar del que escapar lo antes posible a la gran metrópoli.

Analizar y priorizar

Los datos se deben convertir en información, como este método de recolección informal no siempre es todo lo eficiente que se necesita, habrá que depurar y asegurar la coherencia de los datos, rellenar los espacios vacíos y reparar los defectos. Será preciso obtener otros datos en gabinete por geoproceso, generando zonas de influencia, combinando distintas capas, ejecutando rutinas de verificación de datos, y comparando con las fuentes de datos ya existentes para aprovecharlas al máximo.

Con toda la información ya disponible será preciso detectar los conflictos graves y priorizarlos frente a los leves. Formular estrategias de mejora y concretarlos en propuestas de acción bien informadas. ODS Municipal debe servir para detonar proyectos municipales y encontrar financiación externa.

Difundir y sensibilizar

Los objetivos ODS no pueden ser solo un examen técnico circunscrito a las instituciones y los estamentos especializados, desde el primer momento se han planteado también como un mecanismo de sensibilización publica ante los problemas de sostenibilidad y de concienciación sobre la fragilidad del planeta. Los objetivos nos afectan a todos y de alguna forma, en mayor o menor medida deben cambiar nuestros hábitos y comportamientos. No son problemas que afecten solo al gobierno o a las grandes empresas sino que afectan a todos los ciudadanos y sus familias.

ODS Municipal proporciona a cada municipio un geoportal que aglutina y difunde toda la información obtenida, que evidencia los problemas detectados y las soluciones propuestas. También se quiere posicionar como un repositorio estable y seguro de información local que no esté sujeto a los vaivenes de la política local. Contendrá documentos de todo tipo, mapas, estadísticas, encuestas, normativas, planes y proyectos, noticias y publicaciones, propuestas ciudadanas.

Un geoportal que aporta para todos un cuadro de mando de la evolución del cambio. Fijadas las metas ODS 2030, a las que ayuda el Proyecto con una guía de acciones y tipos de políticas públicas y una estructura de programación adaptada a los distintos departamentos municipales, solo falta poder medir los avances y convertirlos en información pública dentro de un proyecto social y comunitario que trasciende a las instituciones e incluso al juego político y que cree una nueva cultura ciudadana.

Puesta en marcha

Ya estamos trabajando para que haya al menos un municipio piloto en los países de LATAM. Estamos alcanzando acuerdos de concertación en República Dominicana (Santo Domingo Norte, Moca, Las Yayas de Viajama, Padre las Casas, Peralta, Sábana Yegua, La Romana, Las Charcas), Uruguay (Canelones, San José, Colonia, Cerro Largo), en Perú (Ate, La Rioja). En el proyecto puede intervenir cualquier municipio con independencia de su tamaño o país. En los acuerdos se incluyen a universidades locales dado el carácter fuertemente formativo del proyecto.

El Proyecto no conlleva algún gasto económico para los municipios, ni en su fase de elaboración ni en su fase de difusión, el Instituto Arnaiz y el Consejo Consultivo de FLACMA buscarán financiación externa para cubrir unos costes que se calculan en 2 dólares por habitante. Como contrapartida, el municipio realizará trabajos de recopilación de la información, pondrá a disposición espacios físicos, gestionará las colaboraciones que desarrolle y divulgará el resultado del Proyecto ejecutado en el municipio.

El Proyecto tiene un plazo de ejecución de 6 meses por municipio. En este plazo no se incluyen los tiempos necesarios para la búsqueda ni la gestión de los recursos económicos que viabilicen su ejecución, que se iniciará en el momento en el que se suscriba el acuerdo de concertación.

Una vez que se ha alcanzado el acuerdo de concertación con todos los actores intervinientes, se iniciará la selección de los colaboradores que podrán ser alumnos de universidades, técnicos municipales, jóvenes de las comunidades vecinales y centros de formación locales o incluso de adultos interesados en formar parte del Proyecto.

Conclusión

Como una imagen vale más que mil palabras os comparto un ejemplo de geoportal que hemos realizado en un municipio boliviano, aún faltan muchos datos y otros no se corresponden con la realidad ya que hemos preferido que se vea como una indicación de cómo debe ser el resultado final. Estamos trabajando en los cuadros de mando y en la simbología más adecuada para cada dato. El propósito es que esta simbología y los contenidos de datos y documentos se presenta normalizada, de forma que permite comparar municipios y se puedan visualizar yuxtapuestos como un continuo, de tal forma que ojalá un día podamos visualizar un país entero. Os invito a explorar su contenido: ODS Maps Un ejemplo de contenido y estructura

Ignacio Arnaiz Eguren

Director

Anexo – Estructura del geoportal

El geoportal demo esta estructurado en varios nodos:

**Mapas: **presenta los mapas fabricados con todos los conjuntos de datos obtenidos por el proyecto

MB Mapas Base: contiene las características básicas del territorio, administrativas, de vialidad, de edificación, de identificación, de configuración, espacios singulares… Con todos ellos se forma una colección que denominamos «Base geográfica».

Información General de Municipio: contiene la documentación recopilada por el proyecto, se recorre mediante la opción «Documentos» del mapa de «Documentación general»

Participación social: presenta los puntos donde los ciudadanos han realizado algún tipo de aportación. Solo hemos puesto alguna de ejemplo.

Localización y Diagnóstico – Mapas agrupados: presenta como colecciones de mapas toda la información recolectada por cada uno de los ODS

Nodos de ODS (del 1 al 17) presentan la información detallada de cada ODS organizada en tres carpetas: Información, Diagnóstico y Planificación existente

Metas y Proyectos – Actuaciones: presentan para cada Objetivo las acciones propuestas por el proyecto

**Conjuntos: **son conjuntos de indicadores ODS, se pueden descargar o visualizar mediante la opción «Datos» en su menú de opciones.

Indicadores de ODS (del 1 al 17): contienen los indicadores ODS locales que se han considerado de importancia, con una simplificación previa de su transversalidad para unificarlos por Mapas, en unos casos procederán directamente de los procesos de medición e identificación y se codifican como indicadores territoriales «ITxx-xxx» y en otros son de alcance municipal y en ese caso se codifican como indicadores generales «IGxx-xxx».

Novedades 2021 en urbiGIS

Sat, 08 May 2021 00:00:00 GMT

Durante los últimos meses hemos incluido nuevas funciones en urbiGIS. Afectan a la interfaz de uso, a la organización de la información, a los geoprocesos de generación de conjuntos de datos, a los métodos de generación de servicios de mapas y a la ejecución y visualización de los Inventarios y sus operaciones. Además el Catálogo de Mapas se está incrementando constantemente y ya hemos superado el millón y medio de servicios accesibles.

Cambios en la interfaz de uso

Modificación de la barra superior: hemos extraído el selector de fondos del escritorio y lo hemos colocado en la barra superior. De esa forma no es preciso cambiar de contexto para cambiar el fondo, como se ve en la imagen de portada. También hemos subido el control del Territorio activo desde el Escritorio a la barra superior por el mismo motivo. Nuevo botón para Participar: entendemos que la Participación es una herramienta fundamental para abrir la información al público general. Además en muchos procesos públicos esa Participación es obligada normativamente. Ahora una anotación de participación puede tener múltiples puntos: Usuario activo: antes se presentaba en la barra superior el nombre del Acceso, ahora se presenta como un texto flotante cuando el cursor se coloca sobre el icono de sesión, que además cambia de color cuando hay una sesión abierta. De esa forma ganamos espacio en la barra superior.

Cambios en la organización de la información

Carpetas de Documentos: se ha añadido la posibilidad de que cada Cuenta establezca un estructura propia de Carpetas de Documentos. Esta estructura es usable en todos los elementos susceptibles de tener documentos adjuntos, sin perjuicio de que en cada elemento se puedan crear carpetas específicas. También se ha incluido un buscador de documentos para que cuando exista una estructura de carpetas compleja se pueda localizar rápidamente un determinado documento. Permisos de Conjuntos de Datos: se ha modificado la política de asignación de permisos a Conjuntos de Datos: pasan a estar Cerrados (no modificables) o Abiertos (modificables). De esta forma el administrador de la Cuenta tiene mejor control del ciclo de vida de sus datos.

Nuevos métodos de Geoproceso

La capacidad de urbiGIS para responder a las necesidades de sus usuarios en orden a crear y analizar la información espacial se ha incrementado con nuevos métodos de geoproceso que se añaden a los ya existentes: Zona de influencia, Combinación, Recorte, Diferencia, Disolver, Intersección, Multiparte a Monoparte, Reparar geometría y Diferencia simétrica: En las Zonas de Influencia: las distancias de buffer pueden venir indicadas en un campo del conjunto de datos. Conversor de polígonos en puntos: calcula los centroides de un Conjunto de Polígonos. Conversor de líneas a polígono: el conjunto de datos resultante se construye creando entidades poligonales a partir de las áreas cerradas de líneas del Conjunto de entrada. Los atributos del Conjunto resultante son los mismos que los del Conjunto de entrada. Recuento de puntos por polígono: realiza un recuento de los puntos del conjunto operacional incluidos en cada polígono del conjunto de entrada, añadiendo un campo «count» en el conjunto de resultado, que tendrá tantos polígonos como el de entrada. Si indica una distancia de tolerancia moverá los puntos del conjunto operacional dentro del polígono más cercano del conjunto de entrada según la distancia de tolerancia

Nueva Gestión de Encuadres

Los Encuadres, en el nodo de Selección del Escritorio, permiten al usuario asignar un nombre a la extensión actual del Mapa, de forma que sea posible volver a ella en todo momento. Hasta ahora esos Encuadres se guardaban como cookies en el perfil de cada usuario. Se ha añadido un nuevo Tema Estándar de Conjunto de Datos denominado «Encuadres», estos Conjuntos deberán estar formados por los polígonos que una Cuenta quiera utilizar como Encuadres prefijados para todos los usuarios que acceden a su Geoportal. Cuando ese Conjunto de Datos se asigna a su Geoportal el usuario tendrá a su disposición esos Encuadres además de los suyos propios:

Nueva Consulta de Instrumentos

El contenido de los Instrumentos en urbiGIS es complejo, a diferencia de la simplicidad de los Conjuntos de Datos, los Instrumentos son transaccionales y su estructura de datos está definida mediante Atributos, Asignaciones y Relaciones con Entidades geométricas organizadas en Grupos. Los Instrumentos se estructuran funcionalmente en dos tipos: los Inventarios que contienen la versión vigente de los elementos espaciales y los Operadores que contienen las propuestas de cambio de los Inventarios en forma de Operaciones. Cuando estas Operaciones se ejecutan actualizan el Inventario sobre el que actúan. Desde el momento en que la Cuenta que los gestiona decide hacerlos públicos, los Instrumentos aparecerán en el Buscador de Instrumentos y podrán colocarse sobre el Escritorio: Ejecutando una consulta gráfica sobre alguna de sus entidades geométricas, el Panel de Datos mostrará el contenido completo de las entidades que existan en ese punto:

Nuevos Métodos de Mapas

Los Conjuntos de Datos que contengan datos puntuales tienen dos nuevos Métodos de Mapa: Mapa de Calor: genera un gradiente de color en función de la densidad de puntos con el número de clases y rampa de color que establezca el usuario. Apilador de Puntos: agrupa los puntos cercanos en puntos de diámetro proporcional al número de puntos con el número de clases y color que establezca el usuario

Nuevas Colecciones de Mapas

Es habitual que los publicadores de Mapas agrupen varios Mapas sencillos para ser presentados como un conjunto, de forma que el usuario no tenga que ir activando y ordenando las capas que forman el mapa final, sino que las active de una sola vez. Las cartografías de base suelen ser de este tipo y en cada sistema GIS se gestionan de forma distinta, normalmente como «Layer Groups». En urbiGIS estos grupos de capas los hemos denominado «Colecciones«. Pueden contener cualquier tipo de Servicio de Mapa, tanto propio de la Cuenta como vinculado desde otras Cuentas. No hay limitación en el número de Colecciones ni en su tamaño. En todo caso es preciso tener en cuenta que el tiempo de descarga en el cliente de una Colección completa será la suma de los tiempos de descarga de sus mapas contenidos. El gestor de la Cuenta determina su denominación, composición, orden de presentación y transparencia de los Mapas dentro de la Colección: Las Colecciones se buscan y colocan en el Escritorio como cualquier otro Mapa. Una vez en el Escritorio se pueden activar para ver todo su contenido, la Leyenda mostrará todos los Mapas que forman la Colección y sus Leyendas individuales: También se pueden visualizar en forma de Secuencia: En este caso, la secuencia presentará toda la Colección bien superponiendo o bien sustituyendo cada Mapa y con la velocidad por Mapa que se establezca. urbiGIS presentará la Colección en el orden que se haya establecido al construirla, bien de forma automática o bien con controles para avanzar o retroceder en la secuencia:

http://info.urbigis.com/wp-content/uploads/2021/05/Ortofotos.mp4

Qué más cosas estamos haciendo

Durante este año 2021 nos gustaría tener disponibles algunas cosas importantes: Cuadros de Mando: los Geoinformes son un componente esencial de urbiGIS desde el primer momento, hace años se configuraban como documentos PDF construidos a partir de plantillas desde un constructor de reportes. En estos momentos es evidente que el análisis de contenidos y el control se está haciendo mediante nuevos componentes de mando más dinámicos, más atractivos y con capacidad para representar la información de formas múltiples. Por eso incluiremos tanto en los Conjuntos de Datos como en los Instrumentos la posibilidad de agregar Geoinformes basados en componentes dashboard en los que el usuario podrá definir los filtrados de datos, los mapas asociados y los componentes a presentar utilizando plantillas predefinidas de uso sencillo e inmediato. 2 millones de Mapas: aún quedan muchos servidores de datos espaciales pendientes de explorar e incluir en el Catálogo de urbiGIS. También es precisa una labor constante de actualización. Por desgracia los servidores de datos espaciales no siempre están soportados por un sistema seguro y fiable y son frecuentes los fallos de servicio. Es frecuente la reconfiguración interna de los servicios, aunque teóricamente son servicios abiertos, la realidad es que su gestor tiende a olvidar esa función y efectúa cambios constantes que solo se ven en sus visores mientras los demás usuarios de sus mapas tendremos enlaces rotos. También es frecuente la redirección de los servicios y es preciso cambiar las URL de acceso o el formato de las peticiones. Simbología multicapa: en este momento la simbología que utiliza urbiGIS se compone de una sola capa, sin embargo en muchas ocasiones se echa de menos la posibilidad de que una entidad geométrica se pueda visualizar con más de un símbolo, por ejemplo dos o más líneas con desplazamientos. Nuevo Contexto de Búsqueda de Documentos: la documentación asociada a los Conjuntos de Datos, a los Instrumentos o a las Anotaciones de Participación puede ser inmensa, por eso estamos incluyendo un nueva pestaña de Documentos en el Buscador que permita localizarlo por su nombre o por las propiedades del elemento al que esté adjunto. Nuevo Generador de Mapas de Instrumento: en este momento los Servicios de Mapa se pueden generar obteniendo datos de los Conjuntos de Datos y de las Anotaciones de Participación. Este nuevo generador permitirá construir Servicios de Mapa obteniendo datos de los Instrumentos. Geoportales Temáticos: actualmente el Geoportal de una Cuenta presenta todos los Mapas, Conjuntos de Datos e Instrumentos de la Cuenta que se hayan establecido como públicos o colocados por defecto en el Escritorio. Los Geoportales Temáticos permitirán a la Cuenta seleccionar los elementos a presentar según el Tema de Cuenta que tengan asignado, por tanto una misma Cuenta podrá tener tanto Geoportales Temáticos como Temas de Cuenta haya definido. Ignacio Arnaiz Eguren Director

Planificación digital, la solución de urbiGIS

Wed, 24 Feb 2021 00:00:00 GMT

De vez en cuando, sin demasiada frecuencia porque el tema es poco atractivo, se ven aparecer noticias o trabajos sobre cómo convertir la información de planificación territorial en información digital. No es un tema nuevo, colea desde los años setenta del siglo pasado cuando los primeros ordenadores y los sistemas de información geográfica aparecieron en las oficinas técnicas de planificación. Desde entonces, aparentemente, no se ha puesto solución. Mi objetivo en esta entrada del blog es revisar lo que se ha hecho y lo que, desde mi punto de vista, puede hacerse. Casi todo lo que ponga ya está dicho en entradas más antiguas de este mismo blog, pero creo oportuno hacer un resumen actualizado.

Hace unos meses, en noviembre de 2019, dentro de las Jornadas Ibéricas de Infraestructuras de Datos Espaciales, se produjo un interesante debate sobre este mismo tema con aportaciones españolas y portuguesas. Es interesante verlo en este enlace El urbanismo en las IDE. Entresaco alguna de sus conclusiones: la primera es que el planeamiento es complejo y digitalizarlo debe pasar por simplificarlo (una técnica muy utilizada en el SIU – Sistema de Información Urbana o en el SiuCyL de Castilla y León y alentada por INSPIRE), la segunda es que el planeamiento de largo plazo está sujeto a la superposición sucesiva de planes y su refundido <técnico> invalida la calidad jurídica del resultado (una carga de profundidad contra experiencias como Geomadrid o Urbanismo en Red), por eso algunos concluyen que es mejor proporcionar una réplica digital de los documentos resultantes de esa superposición para que el técnico interprete la realidad vigente (una solución actual aportada en la Comunidad de Madrid y en muchos otros lugares), la tercera es que no se debe renunciar a la idea de que el planeamiento digital no sea el resultado de un proceso más o menos alambicado, sino que nazca directamente de su productor en formato GIS (aunque no resuelve el problema de la superposición). No son ideas nuevas, en realidad llevan muchos años dando vueltas.

En esas jornadas Álvaro González Due, técnico de la Comunidad de Madrid, expuso una diapositiva bastante gráfica de los procesos actuales para generar planeamiento digital:

Describe el complejo camino que siguen los planes desde el productor del plan hasta la IDE. No los vamos a detallar pero desde luego es normal que el resultado final no tenga validez jurídica, es más, en algunos casos incluso deja de tener validez informativa. Aunque el productor haya hecho su trabajo en CAD e incluso lo haya hecho bien, no siempre es posible extraer todo lo que aguanta el papel, podéis ver como tratamos estos datos en Publicar planeamiento vectorial CAD en urbiGIS. Tampoco resultan válidos los sistemas de interpretación de los documentos para formar bases de datos refundidas de interés comercial porque nadie se fía de la calidad del proceso salvo para obtener resultados estadísticos agregados.

Parece que nadie haya leído los documentos del programa de Urbanismo en Red, que ya tiene la friolera de 12 años y que nace de los trabajos de Geomadrid tres años más antiguos, redactados por mi grupo de trabajo en el seno de Urbimática y que, ya en aquel momento, hacían un análisis de todos estos problemas, problemas que también han sido tratados profusamente a largo de este blog y que pretendía construir un refundido actualizado que sirviese como base para su posterior mantenimiento mediante operaciones digitales. Geomadrid lo hizo para los 179 municipios de la Comunidad de Madrid y Urbanismo en Red para más de 200 en toda España. Para el que tenga tiempo y ganas de leerlo os dejo para su descarga el documento de Informe_de_Alcance_de_la_Solucion.

Desde que falleció el programa de Urbanismo en Red, víctima de la crisis económica y del desinterés de Red.es, nosotros no hemos parado, el resultado es urbiGIS que también he descrito profusamente en las diferentes entradas de este blog, pero del que quiero resaltar algunas características:

a) Naturalmente que el productor del plan debe entregarlo en formato GIS, pero ese no es el problema, el problema es que NUNCA debe entregarlo en formato papel, ni siquiera en papel digital como un PDF firmado electrónicamente. ¿Alguien pide al banco los movimientos de su cuenta en papel?. Pues no parece útil, porque el papel (digital o no) es una foto fija de un proceso dinámico. De la misma forma la planificación territorial no es un Plan sino un proceso sucesivo de mejora e incremento del detalle que no tiene sentido que esté en papel. Cuando se habla de planes superpuestos se está confundiendo el fotograma con el film, reliquias mentales de un mundo de papel, porque en realidad los planes son operaciones contra las cuentas territoriales, las cuentas de suelo, de edificación, de gestión… todas en definitiva cuentas medibles y dinámicas.

b) Si el productor no puede entregar papel diligenciable ni PDF firmados. ¿Cómo podemos garantizar la calidad jurídica de la ordenación?. Pues porque todos tenemos un contrato con la Administración Pública, como lo tenemos con la Hacienda Pública o con nuestro banco. Un contrato que nos garantiza que esas cuentas son correctas y válidas y donde se establece que si ella incumple ese compromiso tendrá sus consecuencias. He estado en ayuntamientos donde había varios ejemplares del Plan General todos distintos y ¡todos diligenciados!. No me parece que el papel sea en realidad una garantía suficiente. Hay quien dirá que alterar una base de datos es sencillo, solo hace falta tener acceso y conocer su arquitectura, pero en realidad no es tan sencillo si sus procedimientos de control son los correctos. Dicen que hay piratas que entran en los sistemas bancarios y se apropian de dinero, pero no lo veo fácil. Por eso las bases de datos del planeamiento deben dejar de ser sistemas administrativos de baja seguridad para ser sistemas jurídicos de alta seguridad, igual que el Registro de la Propiedad abandonará el Folio Real por el Folio Digital y abandonará los apuntes en el Folio por operaciones digitales sobre el Folio digital. No hay más que ver como ha evolucionado el Catastro español asumiendo este modelo de funcionamiento.

c) Si el productor debe generar un plan digital sin papel, este plan debe ser completo no puede una versión simplificada, tendrá que ser todo lo complejo que le exija la legislación urbanística. La digitalización no equivale necesariamente a simplificar, en realidad mi experiencia me indica que la legislación está muy cerca de la programación informática, ambos son conjuntos de reglas inteligentes y si están mal planteadas tanto el programa como la realidad funcionarán mal. El sistema de planificación digital debe reproducir toda la complejidad necesaria que la legislación le exija.

d) La informática nos brinda recursos que son inimaginables en el mundo de papel. Ya no solo que podamos acceder a la planificación vigente actualizada al momento, sino que los conceptos urbanísticos emanados de la legislación son directamente accesibles desde los sistemas de información. Las referencias a términos legales, las notas a pie de página o los conceptos y parámetros urbanísticos estándar no necesitan estar duplicados en cada Plan. En urbiGIS los atributos que sirven para cualificar una entidad urbanística, desde una clase de suelo a un elemento catalogado, están definidos una sola vez en los que llamamos Instrumentos Base. Estos Instrumentos definen atributos a nivel internacional, nacional, regional o local e intentan que solo exista una instancia de cada concepto o parámetro urbanístico. Si la legislación nacional determina que el concepto tiene ámbito nacional y todas las legislaciones regionales o locales se deben subordinar a él, entonces urbiGIS lo incluirá en su Instrumento Base nacional de planificación y allá donde se cualifique la de un ámbito hará referencia a ese concepto unívoco. Si las legislaciones regionales redefinen ese concepto (es lo que tiene el estado de las autonomías), los planes regionales o locales deberán referirse al concepto regional, aunque en urbiGIS se puede establecer una relación de equivalencia entre conceptos similares de diferentes niveles legislativos, como vía para obtener vistas homogeneizadas de planes yuxtapuestos regionales o locales aparentemente distintos porque en su estructura o contenido responden a legislaciones distintas. Este tema lo explico en Sistematizando con urbiThings que aunque ya tiene mucho tiempo sigue siendo válida

e) En urbiGIS la Planificación forma un Inventario. Denominamos así a un conjunto de datos cuyos mecanismos de actualización son siempre mediante Operaciones. Nadie puede alterar directamente ningún dato de un Inventario, únicamente se puede realizar mediante una Operación perfectamente trazable. Al igual (espero) que nadie puede acceder directamente al saldo de mi cuenta bancaria para modificarlo. El Inventario es propiedad de una organización (denominada en urbiGIS) y solo sus usuarios o a quienes admita en su equipo de trabajo pueden plantear Operaciones. En todo caso las operaciones solo afectarán al Inventario cuando su propietario las admita, por tanto el control de los propietarios sobre sus datos es completo. Pueden leer la entrada al blog de Geotransacciones para ver en detalle cómo funciona.

f) El Inventario de Planeamiento no solo proporciona una vista vigente de todas las operaciones de planificación aprobadas sobre un territorio. También proporciona un modo diferente de acceder a la información. Primero, porque es posible consultar el sistema utilizando criterios múltiples que en un sistema de papel son imposibles de realizar. Segundo, porque el sistema informa siempre del dato final, del saldo real de cada cuenta, pero guardando los movimientos que han dado lugar a ese saldo. Tercero, porque separa nítidamente el dato del símbolo, este aspecto es apasionante porque por fin aparca la discusión de si la calidad jurídica del plan se pierde por cambiar la distribución de las hojas, sus colores, su escala o los tramados. Por seguir con el ejemplo bancario nadie duda del saldo de su cuenta aunque lo vea con un formato distinto según acceda desde un ordenador o desde un smartphone. El dato es el dato se pinte como se pinte. Las Instrucciones Técnicas de Planeamiento actuales definen el contenido mínimo del Plan, cosa que está bien, pero luego siempre se centran en los formatos de papel, las simbologías, los sellos y las firmas. Si exigen entregas GIS o CAD son con datos simplificados.

g) Los Inventarios en urbiGIS no se limitan al Planeamiento, se pueden formar Inventarios con cualquier tipo de objetos o elementos situados sobre el territorio sobre los que queremos establecer un sistema colaborativo de mantenimiento: objetos constructivos, derechos, obligaciones, infraestructuras, servicios, afecciones, producción primaria, protecciones territoriales, productos inmobiliarios… Cualquier colección de cosas de las que no solo necesitemos saber cómo son sino también dónde están y cómo se mantienen actualizados.

f) urbiGIS es una plataforma privada. Los datos residen en una nube que no está en un servidor propiedad de la administración pública, aparentemente fuera del alcance de sus propietarios. Esto para los datos públicos siempre es un problema, aunque existen plataformas de gestión de expedientes que funcionan bien bajo esta misma arquitectura. Naturalmente es posible sincronizar su contenido con copias espejo locales que garanticen al propietario de los datos preservarlos ante un conflicto con urbiGIS o un incidente en su nube. En todo caso urbiGIS proporciona mecanismos de seguridad que impiden el acceso a la base de datos a usuarios no autorizados por el propietario de los datos. En cierta forma el conflicto sobre los datos públicos de carácter jurídico y su almacenamiento en la nube es similar al de los datos privados y personales en esa misma nube. Al final se debe supeditar a un contrato que defina las obligaciones y derechos de cada una de las partes.

Conclusión

Cambiar la forma de hacer y publicar los planes es una tarea ingente e ingrata. Mucha gente tiene que cambiar su forma de trabajar, hay un acervo legal complejo de actualizar, aún deben resolverse problemas de seguridad y acceso a la información, la colaboración público-privada es esencial pero complica aún más el problema. Lo que no se puede decir es que no hay una solución que permita producir, mantener y publicar planeamiento 100% digital.

Ignacio Arnaiz Eguren

Director

Geoportales, un modo diferente de compartir información

Tue, 06 Oct 2020 00:00:00 GMT

Desde urbiGIS nos hemos propuesto aportar un geoportal a cualquier organización pública o privada que tenga la necesidad de publicar geodatos y mapas. Porque la información territorial es un bien valioso. Como ya comenté en un post anterior la Comisión europea proclamó la directiva 2019/1024 que considera la información geoespacial como ««documentos cuya reutilización está asociada a considerables beneficios para la sociedad, el medio ambiente y la economía, en particular debido a su idoneidad para la creación de servicios de valor añadido, aplicaciones y puestos de trabajo nuevos, dignos y de calidad, y al número de beneficiarios potenciales de los servicios de valor añadido y aplicaciones basados en tales conjuntos de datos» y más aún en un escenario de pandemia global como el actual.

Y la forma idónea con la que una organización puede colaborar en ese objetivo es mediante un geoportal propio. Un espacio donde ofrecer su información espacial o la publicada por otras organizaciones pero que considera de interés para sus visitantes.

Ofrecer un geoportal, como ya he comentado en otras ocasiones, no es sencillo. Necesita un infraestructura compleja de montar y mantener o se debe adquirir a alguna empresa de GIS con un coste. En NosoloSIG hay una entrada precisamente sobre el hardware necesario: Hardware básico para montar un Geoportal corporativo Sirva de ilustración el ejemplo que se aporta en ese artículo de la IDE.Sevilla.

No siempre serán tan completos y bien estructurados como éste, pero si se quiere asegurar su estabilidad y rendimiento sin duda deben ser muy parecidos. En todo caso hay mucha literatura en Internet sobre cómo montar un geoportal:

Valenty González en su publicación de COMO HACER UN GEOPORTAL EN 15 MINUTOS?
¿QUÉ ES UN GEOPORTAL Y CÓMO SE CREA? de Valentina Mejía Cardona y otros
Las publicaciones de MappingGIS: Opciones para crear una arquitectura WEB GIS en un servidor o la de Primeros pasos con ArcGIS Online
También las de NosoloSIG: Creación de un Geoportal IDE con Geonode
En sigdeletras Patricio Soriano plantea cómo utilizar QGIS: QGIS2Mapea4. Plugin de QGIS para crear visores web con datos de Andalucía
Montar un Geoportal con ESRI Geoportal Server un producto gratuito de código abierto en GitHub que promete una instalación sencilla en tu servidor
Utilizar los servicios de Carto Zone
O montar un servidor de GeoNetwork que es la solución de código abierto más recomendable para montar un geoportal

Como veis, con mayor o menor dificultad, es posible montar un geoportal. Lo que ya no suele ser tan fácil es mantenerlo, es decir asegurar que está siempre disponible y ampliar su oferta de forma sencilla. Y lo más prioritario: convertirlo en un activo de la organización con la suficiente importancia como para que sobreviva a su autor, porque en muchas ocasiones es el producto del esfuerzo de una persona, o unas pocas personas, que son quienes lo han creado y lo conocen y que si faltan en la organización el geoportal termina por desaparecer. Seguramente esta es la causa de que los enlaces rotos en el mundo de los geoportales sea más elevado que en los portales web normales.

Otra opción es utilizar un servicio de publicación de mapas en el que incluir nuestros mapas, no son verdaderamente un geoportal pero suplen la necesidad de publicar algún mapa. En este estilo hay algunos ejemplos:

Harward WorldMap (aunque ya no responde)
En MappingGIS se explica Cómo publicar tus mapas online en 5 minutos con CARTO y también Cómo crear un mapa con Google Fusion Tables o cuáles son los principales sistemas GIS en la nuble: 10 aplicaciones GIS en la nube para publicar mapas (aunque no cita a urbiGIS lo cual es lamentable)

En este ambiente geoespacial urbiGIS aporta algunas características diferenciales:

Es completamente gratuito
Crear un geoportal para cualquier organización solo precisa darse de alta en urbiGIS y solicitar un geoportal propio mediante un correo a info@urbithings.com.
urbiGIS ya dispone de más de 24.000 geoportales para todos los municipios de España, Portugal, México, Guatemala, Nicaragua, Honduras, Costa Rica, Puerto Rico, El Salvador, Cuba, Panamá, Venezuela, Colombia, Bolivia, Ecuador, Perú, Chile, Argentina y Brasil, que están disponibles para su utilización inmediata. Sus urls de acceso se publican en el módulo de Geoportales de urbiGIS.
Dispone de acceso a más de 1.200.000 mapas abiertos para enriquecer el geoportal vinculándolos a su organización
Permite agregar un número ilimitado de conjuntos de datos, servicios de mapas y servicios de localización de su organización (incluidos documentos vinculados)
Si los documentos vinculados están georreferenciados permite su visualización como una capa más.
Proporciona funciones para crear nuevos conjuntos de datos por dibujo, importación y análisis espacial

Ignacio Arnaiz Eguren

Director

Spatial computing y los nuevos dispositivos de realidad aumentada y realidad mixta, diseñando con hologramas los nuevos interfaces para ciudadanos

Mon, 07 Sep 2020 00:00:00 GMT

Para el VI Congreso de Ciudades Inteligentes, previsto en Madrid para el 15 de septiembre de 2020, se ha presentado esta comunicación, y ha sido aceptada por el Congreso. Yo creo que tiene un interés indudable así que con el permiso de sus autores la voy a incluir íntegra como una entrada de este blog, aunque mi participación se ha reducido a apoyar fervientemente su contenido y a postular a urbiGIS como un futuro productor colaborativo de realidad aumentada.

Los autores

Gustavo Medina del Rosario, CEO, Singularfactory.com

Antonio Sánchez, Responsable de proyectos Spatial Computing, Singularfactory.com

Izzat Sabagh, Responsable de proyectos, Singularfactory.com

Miguel Betancor, Doctor en psicopedagogía y experto en innovación deporte. Autor del concepto ADL

Ignacio Arnaiz, Director de Arnaiz Urbimatica

Resumen

Desde Singular Factory creemos que la realidad mixta será lo próximo que la tecnología y los mercados traerán para el mercado del gran consumo tecnológico. En muy poco tiempo los ciudadanos comenzarán a llevar un dispositivo de realidad aumentada que usarán diariamente. Ya sean gafas, lentes o teléfonos inteligentes. Si nuestra visión se cumple, si cree que lo que aquí decimos tiene sentido y ocurrirá, es el momento de trabajar en los contenidos. En el diseño, formato y plataforma. Spatial Computing es el concepto que subyace y da sentido a la combinación de estas tecnologías y sus contenidos. Nos permitirá crear contenido (hologramas), fijarlos en el espacio, mezclarlos e integrarlos en nuestro mundo físico. En esta comunicación queremos compartir nuestra visión y nuestras primeras experiencias y las diferentes iniciativas de organizaciones y compañías por todo el mundo.

Introducción

Para ayudar al lector a contextualizar lo que aquí vamos a comunicar, ha de entender que se ha escrito desde el ángulo de una compañía con un 95% de personal técnico. Por tanto puede ser poco convencional y está alejada de aproximaciones teóricas. Quizás por esa razón hablamos de mercados, empresas y experiencias en proyectos concretos. Para una punto de vista más académico sugerimos visitar https://ieeexplore.ieee.org/document/8656800

Diferencias entre realidad virtual, aumentada y mixta

Aunque técnicamente podemos describir diferencias de implementación, dispositivos o tecnologías, para hacer estas definiciones fáciles de comprender para todo tipo de perfiles profesionales, simplificaremos diciendo que en: Realidad Virtual, todo el contenido es virtual y fabricado para esa experiencia totalmente inmersiva. Un ejemplo sería una aplicación de realidad virtual en el que simular estar en un cine y ves la película. Realidad Aumentada, parte de los contenidos son virtuales que se “mezclan” o se sobre-impresionan con la realidad física de objetos o entorno. La tecnología “aumenta” la experiencia física real con contenidos virtuales superpuestos. Por ejemplo las famosas gafas Google Glass en el que la información se mostraba superpuesta a cualquier objeto. Finalmente Realidad Mixta es muy parecida a la realidad aumentada. El valor que aporta es que los objetos virtuales no sólo se sobre-impresionan sino que de alguna manera se anclan al espacio real y podemos manipularlos e interactuar con ellos y responder como si fuesen objetos reales. Un ejemplo que se ve en promociones de esta tecnología es la imagen de un cirujano que opera a un paciente mientras tiene delante una representación gráfica del órgano o parte del cuerpo del paciente sobre el que trabaja. A todos ellos se les denomina de manera general Realidad Extendida

Spatial Computing

Se basa en la idea de que el mundo real y el mundo virtual pueden interactuar y tener relación e incluso dependencias el uno del otro. Con él no sólo nace la funcionalidad de fijar contenidos virtuales a espacios físicos, sino que tenemos la persistencia, que además facilita que esa realidad se mantenga en el tiempo y pueda ser compartida por muchos usuarios a la vez, desde sus propios dispositivos. Quizás dos ejemplos de claros casos de uso pueden ser pensar en tener en casa o la oficina una decoración real, pero otra virtual, en forma de hologramas. Fijadas a las paredes, sobre la mesa, corriendo por las habitaciones. Cuando vuelves a casa aún siguen ahí. El dispositivo es capaz de reconocer el espacio y mostrar los contenidos asociados. Pero es que además tus vecinos los verán cuando vengan de visita, siempre que compartan los registros virtuales de ese espacio. Lo mismo ocurre en el espacio público, con señales de tráfico, avisos de aparcamientos, espacios de ocio y deporte, etc.

Lo que el mercado está haciendo actualmente

Sin entrar en opinar sobre el rendimiento o calidad de sus productos o políticas, es indiscutible que aunque no sean los primeros en conceptualizar, los lanzamientos de Apple tienen la capacidad de crear un mercado donde no lo había. Eso volverá ocurrir a finales de 2021 o comienzos de 2022. Y si estamos de acuerdo en que eso va a ocurrir, estamos de acuerdo en que existe una oportunidad para las ciudades en crear la infraestructura y los contenidos para ese momento y posicionarse de manera privilegiada. No son los únicos. Magic Leap en Florida que, aunque ahora no pasa por su mejor momento, representó la mayor inversión de capital semilla ante un producto que pocos pudieron probar como prototipo. Facebook se abre a la realidad mixta y Google retoma su idea inicial. El propio Microsoft lanzó hace unos años las Hololens, que ahora van por su segunda versión. Ya del lado del software, Magic Leap lleva unos meses trabajando en su propio Magicverse a partir de su apuesta por Spatial Computing. Y también Microsoft, inicialmente orientada al mercado corporativo, justo acaba de presentar su proyecto de renderizado remoto, permitiendo modelos complejos de hasta 100.000.000 de polígonos. Todo esto junto a su plataforma Azure Spatial Anchoring que, sorprendentemente, es agnóstica, y permitirá almacenar información espacial anclada al mundo real mediante señales GPS, wifi o bluetooth. Se abre la puerta al almacenamiento y generación de contenidos a gran escala en edificios, instalaciones o ciudades. Por último el mercado de adquisiciones de startups y equipos pioneros en esta tecnología no ha hecho más que empezar. Facebook a finales del pasado año comenzó la incorporación de Scape, una compañía especializada en Spatial Computing que lo apostaba todo al reconocimiento de imágenes. En el momento de la adquisición tenía prácticamente finalizado un completo escaneo gráfico del centro de la ciudad de Londres.

Figura 1. Magicverse, de Magic Leap

Nuestra visión de un interface para ciudadanos en un living lab

Tenemos la oportunidad de experimentar todos estos conceptos en laboratorios reales de vecindarios y comunidades de 400 a 2000 habitantes. Se acabó la teoría, toca poner en práctica en el campo de pruebas. Con usuarios y necesidades reales.

Llegados a este punto permítanos describir un poco más la visión que debemos probar basada en las siguientes ideas:

La tecnología juega a nuestro favor, evoluciona a gran velocidad desde las Google Glass, a las Hololens o actualmente todos los prototipos para estos dos años. Sólo hay que esperarla y estar preparados. Toca focalizarse en los contenidos. En las funciones que los almacenan, los evalúan, los pone a disposición de los usuarios con precisión y garantías. Todos ahora mismo asumimos que las redes 5G y los dispositivos de realidad mixta (necesarios para que toda esta comunicación tenga sentido) vienen de camino. Desarrollándose tanto en capacidad y funcionalidades como en adecuación de costes. En algunos sitios cuestión de meses.
No tiene sentido asumir la responsabilidad de crear todos los contenidos cuando experiencias anteriores en la industria TIC nos han demostrado que la mejor estrategia es crear la plataforma, los canales y los conectores que permitan que la propia comunidad participe y enriquezca.

Nuestra apuesta es la de crear la plataforma en la nube que aporte lo siguiente:

Capacidad espacial, persistencia y multiusuario (obviamente permite contenidos privados) a la comunidad que publica aplicaciones.
Permita añadir y filtrar contenidos mediante una API y un SDK apropiados y confiables.
Permita consumirlos apropiadamente a los usuarios. Apropiadamente aplica a hacerlo en el lugar y momentos que son requeridos y para lo que fueron diseñados.
Permita a la comunidad y desarrolladores de terceros crear y publicar contenido propio, público o privado.

Escrito así parece sencillo. Y realmente lo es. Pero es importante recordar que la tecnología viene detrás y nos acompaña.

Figura 2. Arquitectura para el desarrollo de un repositorio en la nube para contenidos realidad mixta

Para poder probar todos estos conceptos con usuarios reales debíamos dar el paso definitivo a crear nuestros propios contenidos y aplicaciones y diseñar lo que entendíamos que sería el interface de un futuro (quizás no tan futuro) ciudadano vecino de una ciudad, un vecindario o un edificio que haya creado su propio universo.

Capas (layers)

Las capas son, para nuestra representación de cómo un ciudadano interactúa con el entorno y con otros ciudadanos, una de las piezas más importantes. Se trata de representar contenidos desde repositorios de datos. Mezclados con imágenes reales, persistentes, anclados y multiusuario.

a) Sensores ambientales y energéticos

Temperatura actual e histórica, calidad del aire, tráfico, nivel de ruido, nivel de CO2, eficiencia energética…

Figura 3. Representación de lo que un usuario ve anclado en el cielo con datos de sensores ambientales

b) Reconocimiento facial

Todos aquellos ciudadanos que hayan interactuado con el usuario que use en ese momento el interface y sea reconocido y dentro del círculo de contactos, podrá ser identificado prácticamente en tiempo real, ver sus últimas publicaciones en redes, etc.

Figura 4.Reconocedor de caras

c) Accesibilidad

Quizás de las funcionalidades más interesantes de entre todas las capas desarrolladas. Específicamente pensada para que, mediante gps, spatial computing y IoT pueda asistir a personas con algún tipo de discapacidad para hacer más cómoda su interacción con el entorno. El ejemplo típico podría ser el de una persona con visibilidad reducida o que necesite silla de ruedas que mediante audio o imágenes superpuestas sobre los pasos peatonales pueda llevar de manera segura y guiada al destino seleccionado.

Figura 5. Contenido de interface de guía para personas discapacitadas.

Tienda de aplicaciones

Junto a las capas, las aplicaciones son el segundo componente del prototipo. Como esta misma comunicación describirá, comenzamos creando la tienda de aplicaciones y las API y SDK para permitir que la comunidad de desarrolladores pueda eventualmente crear sus propios contenidos. El trabajo inicial de simulación de este interface no deja de ser una especie de sistema operativo sobre el sistema operativo existente en el dispositivo. Una app de apps, un ecosistema propio. Creamos de entrada cinco aplicaciones o pruebas de concepto.

Figura 6. Tienda de aplicaciones

a) Solicitudes de mantenimiento

Mediante una fotografía desde las mismas gafas, se requiere alguna reparación o se reporta la incidencia.

b) Ecommerce local

Pequeña plataforma de ecommerce como prueba de concepto de compra remota en tienda local.

c) Soporte técnico en remoto

¿Problemas con el aire acondicionado? el manual de instrucciones está en la nube, las gafas reconocen el panel de mandos y te guía paso a paso y, si no fuera suficiente, el usuario puede video-llamar directamente a soporte. Quienes acceden a la cámara de las gafas y ofrecen ayuda.

d) Salud

Acceso a los registros médicos que la nube almacena desde repositorios de terceros (sistema local de salud).

e) Smarthome

Prueba de concepto para acceder a elementos IoT domésticos.

Figura 7. Aplicaciones de salud y Smarthome

Vida Activa Digital (ADL)

Vida activa digital (Active Digital Living) es un concepto innovador que enlaza las experiencias de los ciudadanos con el diseño urbano. Se trata de incluir la actividad física, aspectos sociales y emocionales en el diseño de la ciudad vinculando todo lo que los datos y la tecnología pueden aportar. Los urbanistas y arquitectos se hacen co-responsables del bienestar físico de los usuarios finales.

El reto de transmitir estos principios en un interface y experiencia de una comunidad no era sencillo. Pero finalmente concluimos con tres mini proyectos:

a) Ranking ADL

El concepto del ranking ATP (tenis) era algo que nos encajaba muy bien. La puntuación no sólo valoraba resultados sino perseverancia. Una persona constante que caminase unos kilómetros diarios podía competir en el ranking social de la comunidad. La información la adquiría de aplicaciones de salud de sistemas IOS y Android así como con el resto de aplicaciones del interface.

Una forma de activar ciudadanos es gamificando experiencias concretas. Esto ya lo hemos vivido anteriormente con juegos y gamificaciones sociales digitales. Se trata de probar el concepto y medir resultados.

c) Yoga en casa

La tercera experiencia ADL se diseñó tanto para dispositivos de realidad mixta (con tu monitor a pocos metros de ti en formato holográfico) como en pantallas de televisión de un típico salón familiar. Todo el concepto pivota en un sensor de 12MP RGB y un depth sensor de 1MP y un sistema de AI que es capaz de detectar la posición de un usuario y transmitirle con un sintetizador de texto a voz las correcciones necesarias.

Figura 8. Yoga. Interface de realidad mixta y representación en televisión HD

Una plataforma abierta

Como hemos comentado en esta comunicación, existe la oportunidad de contar con una potente comunidad de creadores detrás de cualquier proyecto. El reto y, casi siempre, el éxito de una iniciativa pública o privada se sustenta en la capacidad de involucrar a una comunidad que aporte contenidos. Las ciudades no son diferentes.

Puedo aventurarme a afirmar que de todos los desarrollos, diseñar una plataforma abierta es de los más importantes.

a) API – SDK

Un conjunto de librerías y documentación facilitan la incorporación de contenidos en forma de capas (layers) y de aplicaciones. Virtualmente cualquier usuario acreditado puede crear su propia aplicación compatible con el interface y aportar contenidos para almacenar o consultar en tiempo real con datos actualizados (por ejemplo un letrero con las plazas libres actualizadas de un aparcamiento privado o público que virtualmente exista sobre la cornisa real de un edificio.

b) Portal del desarrollador

Canal desde el que solicitar la acreditación, proponer, publicar, cancelar o editar esos contenidos de manera ordenada y con su propio control.

Agradecimientos

Agradecemos a todo el equipo de Singular Factory y a los clientes representantes de las comunidades y regiones que han apostado por el desarrollo de este proyecto de investigación aplicada a un resultado tangible sobre una comunidad real. Seguimos implantando interfaces y contenidos y recopilando todo el feedback de un proyecto que sigue vivo.