Migrar unha plataforma xeoespacial 10 anos despois - Microstation Geographics - Oracle Spatial

Este é un reto común para moitos proxectos de Catastro e Cartografía, que en 2000-2010 Microstation Geographics integrado tempo como motor de datos espaciais, considerando razóns do seguinte xeito:

• A xestión do arco-nodo foi e segue sendo moi práctica para os proxectos catastrais.
• O DGN é unha alternativa atractivo, considerando os seus control de versión no mesmo arquivo, que non cambiou en 15 anos, a diferenza doutros formatos en que vimos moitas versións incompatibles cada tres anos.
• En 2002, o software libre era un soño afastado do que temos hoxe.
• Os estándares OGC non pesaban nin sequera no software propietario.
• Os ficheiros shp foron limitados para proxectos de alto perfil e as bases espaciais aínda estaban moi pechadas aos esquemas non estandarizados que comprometían o desempeño dos servidores ... ea prata.
• A conectividade remota foi incipiente en comparación co que temos agora.

Así, a implementación dun SIX baseado nun esquema de "CAD vinculado" foi unha solución viable, a pesar de sacrificar a usabilidade con fins de presentación atractivos. A API VBA foi abundante para programar rutinas de xestión transaccional conectadas a ProjectWise para o control de ficheiros físicos e a posibilidade de usar GeoWeb Publisher para a análise espacial desde o servidor, aínda que a publicación limitouse a ActiveX en Internet Explorer (que nese ano foi o navegador único).

O problema é que non evolucionou gradualmente e, en vez de mudarse a Geospatial Server ou versións máis robustas de ProjectWise, querer facer que un SIX sobreviva a partir de ficheiros físicos, ter todo o potencial de Oracle Spatial con licenza e a capacidade de desenvolverse. Así que ese foi o noso reto.

1. A base de datos: Postgres, SQL Server ou Oracle?

En particular, preferiría o primeiro. Pero cando estás diante dun sistema transaccional non orientado aos servizos pero que funciona ben, no que parte da lóxica e integridade é como PL na base de datos, o cambio a unha base de OpenSoure non é unha emerxencia. Non, a non ser que o seu obxectivo sexa desenvolver unha nova versión do sistema que non estea dispoñible no prazo inmediato.

Tampouco se trata de facer unha acción talibana para menosprezar todo o que cheira a privado. Quedarse con Oracle é unha decisión acertada, se funciona ben, se é grande e esixente, se está ben deseñado, protexido e se está a aproveitar o soporte. Tema para outra ocasión.

Entón o que quedou foi desenvolver funcionalidades para os datos que se migrarán a esta base, os servizos de publicación e as ferramentas de xestión de datos de vectores transaccionais.

Para controlar os roles e os usuarios, que previamente foron administrados desde ProjectWise, creouse unha ferramenta modular que permitía:

• Xestiona usuarios e roles desde o VBA de BentleyMap.
• Asignar do usuario dereitos de administración, dereito a departamentos e municipios.
• Asignar dereito ao ficheiro catastral por proxecto.
• Dereito ás ferramentas dispoñibles nos módulos de construción, edición, publicación, consulta e administración. Deste xeito, só se crean novas aplicacións que aparecen aos usuarios segundo a súa función ou tarefa específica.
• Este panel de inicio de sesión tamén simplifica a complejidad común dos proxectos de BentleyMap, de tal xeito que, con tan só entrar, verás a árbore das categorías e atributos definidos no Administrador geoespacial.

Un panel disto resolve malentendidos e riscos dos usuarios novos en funcións como a interoperabilidade de datos. O que é outra molestia, porque Bentley edita de forma nativa en Oracle Spatial, o que é marabilloso pero tamén arriscado se non tes control transaccional.

Así, por exemplo, o módulo de construción tiña as seguintes ferramentas:

• Asignar funcións
• Asistente de enlace xeográfico
• Migración espacial por lotes
• Eliminar obxectos
• Editar polígonos
• Exportar Shp / CAD
• Importar Shp / CAD
• Migración xeolóxica
• Migración Geopunto
• Migración Georegion
• Rexistrarse no mapa
• Ligazón Geo-Line
• Ligazón Geo-Point
• Ligazón Geo-rexión

As ferramentas complementarias foron engadidas gradualmente, incluíndo algunhas para editar directamente o administrador xeoespacial.

• Administrador para ver funcións
• Análise topolóxica
• Consulta SAFT
• Consultar función
• Converte Curve para LineString
• Crea características
• Crea propiedades
• Configuración de DBConnect
• DBConnect Query
• Editar característica Xfm
• Editar proxecto Xfm
• Elimina as características Xfm
• Identificación de parcelas
• Modificar a simbología
• Sobreescribir funcións
• Realización por clases
• Tematizar
• Tematizar por lista despregábel
• Utilidades Xfm

2. Os datos: migración de DGN a base espacial: Oracle Buider ou Bentley Map?

O reto máis interesante nesta época, unha migración controlada era necesaria e, tendo en conta que os arquivos DGN sendo actualizado hai máis de 10 anos podería ter problemas coa topoloxía dunha verdadeira tolemia.

Efectivamente foi. Os principais problemas dos mapas están aquí:

• Modificación dun enredo sobre o arquivo fronteira (sector ou zona) implica que debe haber modificación de ambos, incluíndo nós en casos de harmonización como cando un sector é unha soa liña, pero no veciño esta liña é segmentado.
• Hai ficheiros que despois de que as transaccións de mantemento 300 gardadas na historia do DGN poden estar corrompidas.
• Non hai problemas máis complexos despacho administrável, como cando unha área se é igual sobre outro veciño noutro ficheiro, por importes que non poden ser resoltos no mapa porque iso implicaría a inspección sobre o terreo para evitar que afectan a terceiros.
• Malas prácticas, como a inclusión de mapas en diferentes proxeccións, neste caso houbo sectores en NAD27, aínda que o estándar foi WGS84. En casos extremos, fixéronse axustes entre datos de diferentes proxeccións, o perverso.

A solución era unha ferramenta de tipo Wizzard para a migración masiva, que se pode migrar individualmente a un mapa, varios ou mesmo un municipio (concello) ou departamento.

Basicamente o que a ferramenta leva os datos do proxecto Geographics e os promove a características de Benltey Map, e fai unha serie de validacións, como:

• Unha a unha relación entre xeometría e base de datos,
• A validación da falta de duplicados,
• Validación da consistencia zona-centroide,
• A validación de obxectos de mapas con respecto a obxectos inactivos na base de datos,
• Validación de topoloxía con respecto ás topoloxías existentes na base espacial

Despois das validacións, o panel permite engadir información de xeito masivo, como o método de medida e o estándar de control de calidade destes datos.

Finalmente, publíqueo na base de datos, xerando finalmente un informe. Dito o feito hai un treito tremendo, pero finalmente axustouse aos caprichos de Oracle Spatial que aínda son tan descabellados como os de Bentley e a súa forma de ver propiedades complexas ou moitos vértices.

3. A publicación: Geoserver ou MapServer? OpenLayers ou Leaflet?

Construíuse un visor usando OpenLayers e algúns complementos. Por primeira vez despois de 10 anos de descoido no desenvolvemento da parte espacial, foi visible un novo visor que substituíu o ActiveX de GeoWeb Publisher. Usouse o código MapFish para imprimir, Geojson para controlar a árbore lateral, desde Geoserver servíronse as capas servidas desde OracleSpatial.

Finalmente, a substitución das tecnoloxías foi feita de acordo co seguinte gráfico. Como podes ver, unha combinación de código libre, mantendo a base de datos e xestión de terras usando software propietario.

4. Construír e editar, dirixir a Oracle Spatial. Mapa de Bentley ou QGIS?

Esta é outra historia. Bentley Map edítase de forma nativa sobre a base espacial, o que causa conflitos se non funciona cun servizo de funcións web transaccional (WFS). O conflito é:

Como resolver unha regra de non permitir a superposición de topoloxía, se está a ser editada e ao querer publicar informes de que o obxecto afecta a si mesmo?

Isto resólvese editando antes, editándose directamente e validando que cando se publica, se algo falla, a versión está recuperada deixando a transacción rematada pero en estado fallido.

Outro problema que tivo que ser resolto é a entrada de datos masiva, tendo en conta que os usuarios tiñan que deixar de usar Geographics e houbo varios proxectos de cadastre masivo.

Este foi fácil, porque só fixo unha ferramenta similar que para integrar datos no MicroStation Geographics, facilitando o potencial de BentleyMap e un asistente de máis controlada.

A imaxe mostra como esta ferramenta foi desenvolvida, con algunhas peculiaridades, como a creación e rexistro de vértices ea inclusión Puntoparcela como lista de funcionalidades no caso do método de medida dalgúns vértices non atender determinado nivel de calidade.

Sen dúbida, este fluxo foi moi bo, porque os usuarios sabían que ferramentas utilizaban con máis frecuencia. Foi necesario facelos cambiar a súa mentalidade entre pasar de múltiples funcións a xestión por niveis, promovendo novas vantaxes para que esquecesen o arcaico Microstation V8 2004, como o servizo WMS, transparencias e recoñecemento nativo de ficheiros DWG de versións recentes; sen esquecer a interoperabilidade con kml, shp e gml para os máis astrais.

De igual se fabricaron ferramentas para o mantemento catastral, tendo a opción de editar directamente en formas ou rebaixas no arco-nodo para casos complexos.

5. Cliente para municipios a través de GML. QGIS ou gvSIG?

QGIS. Pero esa é outra historia que contar despois.