Home > Geoespatial / GIS > Migrating features from Geographics to Bentley Map

Migrating features from Geographics to Bentley Map

TRANSLATION NOTES: Please read some comments at the end of this post.

Some time ago we have being speaking of what it takes to make the leap from Microstation Geographics to Bentley Map; we talked about how both schemes work and some important benefits of Bentley Map. In a preview post I spoke how it is possible to migrate the project structure; in this case I would like to chew how to migrate maps with Geographics attributes to xfm’s feature classes.

While a project structure built with Geographics Legacy can be imported from Bentley Map, it does not mean that the objects attributes will be recognized by the new project, these should be assigned.

How Geographics worked

In the Geographics style objects through a MSLINK had an association to a database that was all the object had, an OLE type link. This MSLINK associated graphic object from the dgn file using the MAPNAME of MAPS table, and through MSCATALOG to identify where to get the data from Entitynum. Additionally, there were doubles tables for the projects compatible with Intergraph that usually carried a UG before.

clip_image001

Additionally, the object was a FEATURE, although this was not dynamic, when allocate acquired the properties defined for that attribute (including commands) and itself was associated with the CATEGORY table. An object could have more than one attribute and the priority was which assigned to it the definitive style, this FEATURE and other objects linked to the base were associated with the MSCATALOG table where it were allocated such entitynum that was the navel of everything.

clip_image002

Then the index.dgn file kept the shapes of linked maps, maps here took a MapID so that each table linked to Geographics had at least two fields: MSLINK (graphical entity number, unique on each map) that is always the primary key and MapID (on which map is stored, is unique in the maps’ catalog) which is an external key to MAPS table.

So the only way to interact with the data was maintaining connection to the base, and the operations with it were done carelessly (*) like the update in tables that have information of the object such as area, perimeter and coordinates so that Publisher would know how to deploy it. It can also be removed labels that fell as database objects with the same link of the linked object.

It seems simple but it cost me too much understand it from MGE, and the painful situation is that all this smoke does not serve much for a project with Bentley Map.

clip_image003How Bentley Map functioned

A Bentley Map project maintains the same logic of category attribute, map, and object; but in this case, when replacing OLE link’s way for XML much of the process changes.

In this case, the object on the map can have stored data (in the same dgn), which is understood as xml or as it’s called by Bentley wfm. Then also changes that now objects can only have one attribute and be spatially associated through topological rules; time ago the block’s limit could be a same line and the property’s limit also, but now they must be separate objects but with a topological partnership such that when changing one, another does too.

So interact with data is just at a simple click, whether or not connected to the project, you can read all that was left as xfm data. And then it becomes dynamic labels’ handling and attributes properties, with only making changes from the Geospatial Administrator. Before, make a change was only dynamically view through Publisher but objects required to be removed and re-assigned the attribute.

Additionally Bentley Map provides options for creating data forms, sequential processes, associated commands (methods / operations / domains / criteria / reports) and other pirouettes that facilitate data construction.

In something did not change so much, and it is like ESRI users say it, that smoke occupies the green one for chewing and digesting it.

The problem

However, transferring a project structure is possible, and then to add functionalities through Geospatial Administrator, which would suppose being ready to continue feeding data but the dilemma is:

And the maps constructed with Geographics?

For that Bentley has not designed a trick to convert objects of a Legacy project to xfm draft… what fucking!

The proposal I will suggest is one which I see viable, after being chatting with a friend contacted from Chile, after several mails we have reached to an outdated but functional egeomate.

Step 1. Exporting to shape files

From a Geographics project, opened, select the option export attributes to shape files (file / export / SHP). This must be done for every existing feature in the map.

clip_image004

It would have to struggle a bit when objects are centroid / boundary, because it would be necessary to convert to shapes moving the link.

Export can also be done to Mapinfo, as you prefer.

clip_image005Step 2. Importing from Bentley Map

And now, from the Bentley Map Project, choose the import option (File / import / GIS Data types), with this the Interoperability window appears, we apply right mouse button on Imports and select new import.

clip_image006With the right mouse button in Import1 it is selected either a file or an entire directory. Shape files can be imported or Mapinfo files type mif and tab.

When touching the feature class we can see that it is possible to select the level, color, transparency and other properties.

To assign it to the feature that is of our interest, just assign the layer (level).

The painful part

As Memín said in that old Mexican Comic (**):

“Heck!”

It would have to do this for each feature on each map in each category in each project.

To do this you can save the import, and only called file by file or directory. The truth is that there is a lot of work to transform data, especially if they are in separate files. It wouldn’t be bad, to work a vba in .NET to automate the process instead of dealing with this task manually, which may cause more than some suicide one day. The main (***) problem is, that to make the leap we are continuously depending on a specialized (and very smoked) advice to understand the Bentley Map’s and Geographics’ guts, it is possible, but applications should not be so astral (let’s face it, both are) for ordinary users.

It’s even more painful, if in the original dgn was stored information in the history … the new file will have nothing of history.

In conclusion

The solution presented is feasible if you have little data, or if they were stored on spatial cartridge, therefore the sad conclusion is that migration from Geographics to Bentley Map is not as simple data transformation. If Geospatial Administrator, as I said before, is a toothache, data migration could be still more painful unless Bentley thinks on solutions for their users that for this reason don’t want to migrate from one day to another.

Talking with egeomated friends they made me an unwise analogy, but as this is a boring day at a seedy hotel and the comparison is so true, with your permission I will use it:

“It is not like changing couple …

… it could be like losing again virginity ”

TRANSLATION NOTES:

(*) a lo bestia: A Spanish idiom that means something has not be done carefully.

(**) paquín: In Mexico, this word is used instead of Comic.

(***) toral: This jargon is used instead of ‘main’ or ‘principal’.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.