Migrar features de Geographics a Bentley Map

Hace un tiempo venimos hablando de lo que implica dar el salto desde Microstation Geographics a Bentley Map, hemos hablado de como funcionan ambos esquemas y algunas ventajas importantes de Bentley Map.  Ya en un post hablé como es posible migrar la estructura del proyecto, en este caso quiero masticar cómo migrar mapas con atributos de Geographics a feature classes de xfm.

Si bien, una estructura de proyecto construida con Geographics Legacy puede ser importada desde Bentley Map, no significa que los atributos que tienen los objetos serán reconocidos por el nuevo proyecto, estos deben ser asignados.

Como funcionaba Geographics

En el estilo Geographics los objetos a través de un MSLINK tenían una asociación a una base de datos, eso era todo lo que tenía el objeto, un enlace tipo OLE.  Este MSLINK asociaba el objeto gráfico desde el archivo dgn mediante el MAPNAME de la tabla MAPS, y mediante el MSCATALOG para identificar de donde sacar el dato a partir del Entitynum.  Adicionalmente, habían tablas dobles para los proyectos compatibles con Intergraph que usualmente llevaban un UG antes.

Adicionalmente el objeto tenía un FEATURE, aunque este no era dinámico, al asignarlo adquiría las propiedades definidas para ese atributo (entre ellos comandos) y este mismo estaba asociado a la tabla CATEGORY.  Un objeto podía tener más de un atributo y la prioridad era la que le asignaba el estilo definitivo, ese FEATURE y demás objetos ligados a la base estaban asociados a la tabla MSCATALOG donde se les asignaba el tal entitynum que era el ombligo de todo.

Luego el archivo index.dgn mantenía los shapes de mapas ligados, aquí los mapas adquirían un MAPID, de aquí que cada tabla vinculada a Geographics tenía al menos dos campos: MSLINK (número de entidad gráfica, es único en cada mapa) que siempre es la clave primaria y MAPID (en qué mapa está almacenada, es único en el catálogo de mapas) que es una clave externa a la tabla MAPS.

Así que la única forma de interactuar con los datos era estando conectado a la base, y las operaciones con esta se hacían a lo bestia  como ser la actualización en las tablas que tuvieran información del objeto tal como área, perímetro y coordenadas para que Publisher supiera como desplegarlo.  También se podía extraer labels que caían como objetos desde la base de datos con el mismo enlace del objeto ligado.

Parece simple pero me costó un mundo entenderlo desde MGE, y lo penoso es que toda esa fumada no sirve de mucho para un proyecto con Bentley Map.

Como funciona Bentley Map

Un proyecto de Bentley Map mantiene la misma lógica de Categoría, atributo, mapa, objeto; pero en este caso, al reemplazar la forma de enlace de datos OLE por XML mucho del proceso cambia.

En este caso, el objeto en el mapa puede tener datos almacenados (en el mismo dgn), que es entendida como xml o como le llama Bentley wfm.  Luego cambia también que ahora los objetos solo pueden tener un atributo, y estar asociados espacialmente mediante reglas topológicas; antes podía ser una misma línea el límite del manzanero y también el límite del predio, ahora deben ser objetos separados pero con una asociación topológica tal que al modificar uno el otro también lo sea.

Así que el interactuar con datos, está a un simple clic, esté o no conectado al proyecto, podrá leer todo lo que se dejó como data xfm.  Y luego se vuelve dinámico el manejo de labels y propiedades de los atributos, con solo hacer cambios desde el Geospatial Administrator.  Antes, hacer cambios solo era dinámica la vista por medio de Publisher pero los objetos requerían que se les quitara y volviera a asignar el atributo.

Adicionalmente Bentley Map ofrece opciones para crear formularios de datos, procesos secuenciales, comandos asociados (métodos / operaciones / dominios / criterios / reportes) y otras piruetas  que facilitan la construcción de datos.

En algo no cambió mucho, y es que como lo dicen los usuarios de ESRI, esa fumada ocupa de la verde para lograr masticarla y digerirla.

El problema

Ahora bien, migrar la estructura de un proyecto es posible, luego agregarle funcionalidades mediante el Geospatial Administrator, lo que supondría estar listo para seguir alimentando datos pero el dilema está en:

¿Y los mapas construidos con Geographics?

Para esto Bentley no ha diseñado algún artilfugio que permita convertir objetos de un proyecto Legacy a uno xfm… que jodida!

La propuesta que voy a sugerir es la que veo viable, luego de estar charlando con un amigo que desde Chile me contactó, después de varios correos hemos llegado a una Geofumada anticuada pero funcional.

Paso 1. Exportando hacia shape files

Desde un proyecto Geographics, abierto, se elige la opción de exportar atributos a shape files (file / export / SHP).  Esto hay que hacerlo por cada feature existente en el mapa.

Habría que batallar un poco cuando los objetos son centroide/boundary, pues sería necesario pasarlos a shapes trasladándoles el ligue.

También la exportación puede hacerse a Mapinfo, según se prefiera.

 

Paso 2. Importando desde Bentley Map

Y ahora, desde el Proyecto de Bentley Map, elegimos la opción importar (File / import / GIS Data types), con esto aparece la ventana Interoperability, se hace botón derecho del ratón en imports y se selecciona new import.

Con el botón derecho del ratón en Imoport1 se selecciona bien un archivo o un directorio completo.  Es posible importar shape files, o archivos de Mapinfo tipo mif y tab.

Al tocar el feature class podemos ver que es posible seleccionar el nivel, color, transparencia y otras propiedades.

Para asignarlo al feature que nos interesa basta con asignarle la capa (level).

 

Lo doloroso

Como decía Memín en aquel antiguo paquín mexicano:

“diantres!!!”

habría que hacer esto para cada feature en cada mapa en cada categoría en cada proyecto.

Para ello es posible guardar el import, así solo se llama archivo por archivo o por directorio. Lo cierto es que hay un duro trabajo para transformar datos, sobre todo si están en archivos separados.  No estaría de más, trabajarse una vba en .NET para aut
omatizar el proceso en lugar de afrontar esta tarea a pie, que puede provocar más de algún suicidio un día.  El problema toral está, que para dar el salto se continúa dependiendo de una asesoría especializada (y muy fumada) en entenderle las tripas a Bentley Map y Geographics, es posible, pero las aplicaciones no deberían ser tan astrales (admitámoslo, ambas lo son) para los usuarios comunes y corrientes.

Más doloroso aún, si en el dgn original estaba almacenada información en el history… el nuevo archivo no tendrá nada de historia.

En conclusión

La solución que presento es viable si se tiene pocos datos, o si se almacenaron en cartucho espacial, por lo que la triste conclusión es que la migración de Geographics a Bentley Map no está tan sencilla, por la transformación de datos.  Si el Geospatial Administrator, como decía antes, es un dolor de muelas, la migración de datos podría ser más doloroso aún a menos que Bentley piense en soluciones para sus usuarios que por eso no se quieren pasar de un día para otro.

Hablando con amigos geofumados me hacían una analogía poco prudente, pero como hoy es un aburrido día en hotel de mala muerte y la comparación es tan cierta, con su permiso la usaré:

“No es como cambiar de pareja…

…podría ser como volver a perder la virginidad”