Migrate features from Geographics to Bentley Map

Some time ago we have been talking about what it means to make the leap from Microstation Geographics to Bentley MapWe talked about how Both work schematics and some important benefits of Bentley Map. In a post I already talked about how it is possible Migrate structure Of the project, in this case I want to chew on how to migrate maps with Geographics attributes to xfm feature classes.

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

How Geographics Worked

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

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

Then the file Index.dgn (MAPID), so that each table linked to Geographics had at least two fields: MSLINK (unique entity number on each map) which is always the primary key and MAPID ( On which map it is stored, is unique in the map catalog) which is a foreign key to the MAPS table.

So the only way to interact with the data was by being connected to the base, and operations with it were done wildly  such as updating the tables that had information about the object such as area, perimeter and coordinates so that Publisher knew how to display it. You could also extract labels Which fell as objects from the database with the same link of the linked object.

It seems simple but it cost me a world to understand it from MGE, and the painful thing is that all that smoke does not help much for a project with Bentley Map.

How Bentley Map works

A Bentley Map project maintains the same logic of Category, attribute, map, object; but in this case, by replacing the form of OLE data link by XML much of the process changes.

In this case, the object on the map can have data stored (in the same dgn), which is understood as xml or as Bentley wfm calls it. Then it also changes that now objects can only have one attribute, and be associated spatially by topological rules; Before, the limit of the apple tree could be the same line and also the limit of the property, now they must be separate objects but with a topological association such that when modifying one the other is also so.

So interacting with data is just one click away, whether or not you are connected to the project, you can read everything that was left as data xfm. And then the handling of labels and attributes properties, just by making changes from the Geospatial Administrator. Previously, making changes was only dynamic in the view through Publisher, but objects required the attribute to be removed and reassigned.

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

Something did not change much, and is that as users say ESRI, that smoke takes up the green to chew and digest it.

The problem

However, migrating the structure of a project is possible, then add functionalities through the Geospatial Administrator, which would mean being ready to continue to feed data but the dilemma is:

And the maps built with Geographics?

For this Bentley has not designed any artifact that allows converting objects from a Legacy project to an xfm ... What a fucking deal!

The proposal that I will suggest is the one I see viable, after being chatting with a friend who from Chile contacted me, after several emails we have arrived at an outdated but functional Geofumada.

Step 1. Exporting to shape files

From an open Geographics project, the option to export attributes to shape files is chosen (File / export / SHP). This must be done for each feature Existing on the map.

It would be necessary to fight a little when the objects are centroid / boundary, as it would be necessary to pass them to shapes by transferring the ligue.

Also the export can be made to Mapinfo, according to its preference.

Step 2. Importing from Bentley Map

And now, from the Bentley Map Project, we chose the import option (File / import / GIS Data types), This shows the window Interoperability, You right-click on imports And select New import.

With the right mouse button on Imoport1 you select either a file or an entire directory. It is possible to import Shape files: Mapinfo files type mif and tab.

When playing 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 Which interests us is enough to assign the layer (level).

How painful

As Memin said in that old Mexican pakin:

"damn!!!"

You 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, so it is only called file by file or by directory. The truth is that there is hard work to transform data, especially if it is in separate files. It would not hurt, work a vba in .NET for aut
Skip the process instead of tackling this task on foot, which can lead to more than a few suicide a day. The main problem is that to make the leap we continue to depend on a specialized (and highly smoked) consultancy to understand the guts of Bentley Map and Geographics, it is possible, but the applications should not be so astral (let's face it, both are) for ordinary users.

Even more painful, if in the original dgn was stored information In history... the new file will have nothing of history.

In conclusion

The solution that I present is viable if you have little data, or if it was stored in a spatial cartridge, so the sad conclusion is that the migration from Geographics to Bentley Map is not so easy, due to data transformation. If the Geospatial Administrator, as he said before, is A toothache, data migration could be even more painful unless Bentley thinks of solutions for its users that do not want to go from one day to the next.

Talking with geofumados friends made an unwise analogy, but since today is a boring day in a hotel of bad death and the comparison is so certain, with your permission I will use it:

"It's not like changing partners ...

... could be like losing again virginity "