Migrar una plataforma Geoespacial 10 años después – Microstation Geographics – Oracle Spatial

Este es un reto común para muchos proyectos de Catastro o Cartografía, que en la época 2000-2010 integraron Microstation Geographics como motor de datos espaciales, considerando razones como las siguiente:

• La gestión arco-nodo era y continúa siendo sumamente práctica, para proyectos catastrales.
• El DGN es una alternativa atractiva, considerando su versionado en el mismo fichero, que no ha cambiado en 15 años, contrario a otros formatos en el que hemos visto muchas versiones incompatibles cada tres años.
• En 2002 el software libre era un sueño lejano de lo que tenemos hoy.
• Los estándares OGC no pesaban aun sobre el software privativo.
• Los ficheros shp eran limitados para proyectos de alto calado y las bases espaciales todavía eran muy cerradas a esquemas no estandarizados que comprometían el rendimiento de los servidores… y la plata.
• La conectividad remota era incipiente comparado con lo que ahora tenemos.

De modo, que implementar un SIG basados en un esquema “CAD vinculado” era una solución viable, pese que se sacrificaba la usabilidad para fines de presentación atractiva.  La API VBA era abundante para programar rutinas de gestión transaccional conectado a ProjectWise para el control de ficheros físicos y la posibilidad usar GeoWeb Publisher para análisis espacial desde el servidor, aunque la publicación se limitara a ActiveX en Internet Explorer (que en aquel año era el único navegador).

El problema es no haber evolucionado de manera gradual y en lugar de pasar a Geospatial Server o versiones más robustas de ProjectWise, querer hacer sobrevivir un GIS a partir de ficheros físicos, teniendo todo el potencial de Oracle Spatial licenciado y la capacidad de desarrollar.  De modo que ese fue nuestro reto.

1. La base de datos:  ¿Postgres, SQL Server o Oracle?

En lo particular, hubiera preferido el primero.  Pero cuando estás frente a un sistema transaccional no orientado a servicios pero funcionando bien, en el que parte de la lógica e integridad está como PL en la base de datos, el cambio a una base OpenSoure no es una urgencia.  No, a menos que tengas en meta desarrollar una nueva versión del sistema que no está en el plazo inmediato.

Tampoco se trata de hacer una acción talibán de menospreciar todo lo que huele a privativo.  De modo que quedarse con Oracle es una decisión sabia, si está funcionando bien, si el tamaño y exigencia es amplio, si está bien diseñada, protegida y si el soporte se está aprovechando.  Tema para otra ocasión.

Así que lo que quedaba era desarrollar funcionalidades para que la data se migrara a esta base, servicios de publicación y herramientas de gestión transaccional de datos vectoriales.

Para controlar los roles y usuarios, que antes eran gestionados desde ProjectWise, se creó una herramienta modular que permitía:

• Gestionar usuarios y roles desde la VBA de BentleyMap.
• Asignar desde el usuario con derechos de administración, derecho a departamentos y municipios.
• Asignar derecho a ficha catastral por proyecto.
• Derecho a herramientas disponibles en los módulos de Construcción, edición, publicación, consulta y administración.   De esta manera, solo se van creando nuevas aplicaciones y van apareciendo a los usuarios según su rol o asignación específica.
• Este panel de login también simplifica la complejidad común de los proyectos BentleyMap, tal que con solamente ingresar le aparece el árbol de categorías y atributos definidos en el Geospatial Administrator.

Un panel de esto resuelve líos de poco entendimiento y riesgos de usuarios nuevos a funcionalidades como Data Interoperability.  Que es otro rollo, pues Bentley edita de forma nativa en Oracle Spatial, lo que es una maravilla pero también arriesgado si no se tiene el control transaccional.

Así, por ejemplo, el módulo de Construcción tenía las siguientes herramientas:

• Asignar Features
• Asistente de Vinculación geográfica
• Batch Migración Espacial
• Borrar objetos
• Editar polígonos
• Exportar Shp/CAD
• Importar Shp/CAD
• Migración Geolínea
• Migración Geopunto
• Migración Georegión
• Registrar mapa
• Vincular Geo-Línea
• Vincular Geo-Punto
• Vincular Geo-Región

Las herramientas complementarias se fueron agregando de forma gradual, incluidas algunas para editar directamente el Geospatial Administrator.

• Administrador para visualizar features
• Análisis Topológico
• Consulta SAFT
• Consultar Feature
• Convertir Curva a LineString
• Crear Features
• Crear propiedades
• DBConnect configuration
• DBConnect Consulta
• Editar feature Xfm
• Editar proyecto Xfm
• Eliminar Features Xfm
• Identificación parcelaria
• Modificar simbología
• Sobre-escribir features
• Tematización por clases
• Tematizar
• Tematizar por lista Desplegable
• Utilerías Xfm

2.  Los datos: Migración de DGN a base espacial: ¿Oracle Buider o Bentley Map?

El reto más interesante en esto era, que se requería una migración controlada y, teniendo en cuenta que los ficheros DGN al haber recibido actualización por más de 10 años podrían tener problemas de topología -una verdadera locura-.

En efecto así fue.  Los principales problemas de los mapas están aquí:

• La modificación de una parcela en la frontera del fichero (sector o zona) implica que debe haber modificación de ambos, inclusive la coincidencia de nodos en casos como cuando en un sector es una sola línea pero en el vecino esa línea está segmentada.
• Hay ficheros que luego de 300 transacciones de mantenimiento guardados en el histórico del DGN se pueden corromper.
• Hay problemas más complejos no controlables en gabinete, como cuando un predio se traslapa sobre otro vecino en otro fichero, por cantidades que no se pueden resolver en el mapa pues implicaría hacer inspección de campo para evitar afectar a un tercero.
• Malas prácticas, como la inclusión de mapas en diferentes proyecciones, en este caso habían sectores en NAD27, aunque el estándar era WGS84. En casos extremos se hicieron ajustes entre datos de diferentes proyecciones, a lo perverso.

La solución fue una herramienta tipo Wizzard para la migración de forma masiva, la que puede migrar de forma individual un mapa, varios o inclusive todos los de un municipio (ayuntamiento) o departamento.

Básicamente lo que la herramienta hace tomar los datos del proyecto Geographics y promoverlos a features de Benltey Map, luego hace una serie de validaciones, tal como:

• Relación uno a uno entre geometría y base de datos,
• Validación de falta de duplicados,
• Validación de consistencia área-centroide,
• Validación de objetos del mapa respecto a objetos inactivos en la base de datos,
• Validación de topología respecto a topologías existentes en la base espacial

Luego de las validaciones, el panel permite agregar información de forma masiva, tal como método de medición y estándar de control de calidad de esos datos.

Finalmente, postea a la base de datos, generando finalmente un reporte.  Del dicho al hecho hay un tremendo trecho, pero finalmente se ajustó a los caprichos de Oracle Spatial que no dejan de ser tan descabellados como los de Bentley y su forma de ver los predios complejos o las parcelas muchos de vértices.

3.  La publicación: ¿Geoserver o MapServer? ¿OpenLayers o Leaflet?

Se construyó un visor utilizando OpenLayers y algunos plugins.  Por primera vez después de 10 años de abandono del desarrollo de la parte espacial, fue visible un nuevo visor que reemplazó el ActiveX de GeoWeb Publisher.  Se utilizó el código de MapFish para la immpresión, geojson para controlar el árbol lateral, desde Geoserver se sirvieron las capas servidas de OracleSpatial.

Finalmente el reemplazo de tecnologías se hizo de acuerdo al siguiente gráfico. Como se puede ver, una combinación de código libre, manteniendo la base de datos y la gestión parcelaria utilizando software privativo.

4.  Construcción y edición, directo a Oracle Spatial. ¿Bentley Map o QGIS?

Esta es otra historia.  Bentley Map edita nativo en la base espacial, lo que genera conflictos si no se trabajará con un Web Feature Service Transaccional (WFS). El conflicto es:

¿Cómo resolver una regla de no permitir traslape de topología, si se está editando y al querer postear reporta que el objeto se afecta a símismo?

Esto se resuelve versionando antes, editando directamente y validando que al postear, si algo falla el versionado se recupera dejando la transacción finalizada pero en estado fallido.

Otro problema que hubo que solventar es el ingreso masivo de datos, considerando que los usuarios debían de dejar de usar Geographics y habían varios proyectos levantando catastro masivo.

Esto fue fácil pues solo se hizo una herramienta similar a la que había para integrar los datos en Microstation Geographics, facilitando con los potencialidades de BentleyMap y con un asistente más controlado.

La imagen muestra como se desarrolló esta herramienta, con algunas particularidades, como la creación y registro de vértices y la inclusión del Puntoparcela, como funcionalidad lista en caso que el método de medición de algunos vértices no reunieran cierto estándar de calidad.

Defintivamente este flujo quedó muy bien, pues los usuarios sabían qué herramientas con más frecuencia utilizaban.  Fue necesario hacerlos cambiar de mentalidad entre el paso de features múltiples a gestión por niveles, promoviendo nuevas bondades para que olvidaran el arcaico Microstation V8 2004, tal como el servicio WMS, las transparencias y reconocimiento nativo de ficheros DWG de versiones recientes; que no decir de la interoperabilidad con kml, shp y gml para los más astrales.

De igual se hizo herramientas para mantenimiento catastral, teniendo la opción de editar directamente en shapes o bajándolos a arco-nodo para casos complejos.

5.  Cliente para las municipalidades vía GML. ¿QGIS o gvSIG?

QGIS.  Pero esa, es otra historia para contar después.