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 schemes and some important advantages of Bentley Map. Already in a post I spoke as 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 that 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 assigned it acquired the properties defined for that attribute (among them commands) and this was associated with the CATEGORY table. An object could have more than one attribute and the priority was the one that assigned the final style, that FEATURE and other objects linked to the base were associated to the MSCATALOG table where they were assigned the same 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 how to be the update in the tables that had information of the object such as area, perimeter and coordinates so that Publisher knew how to display it. It could also be extracted 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 stored data (in the same dgn), which is understood as xml or as Bentley calls it wfm. Then it also changes that now objects can only have one attribute, and be spatially associated by topological rules; before it could be the same line the boundary of the manzanero 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 one is also so.
So interacting with data, is a simple click, whether or not connected to the project, you can read everything that was left as data xfm. And then the handling of labels and properties of the attributes, with only making changes from the Geospatial Administrator. Before, making changes was only dynamic view through Publisher but the objects required to be removed and reassigned the attribute.
Additionally Bentley Map offers options to create data forms, sequential processes, associated commands (methods / operations / domains / criteria / reports) and other pirouettes that facilitate the construction of data.
Something did not change much, and is that as users say ESRI, that smoke takes up the green to chew and digest it.
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 has to 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 in Imoport1 a file or a complete directory is selected. It is possible to import Shape files is 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).
As Memin said in that old Mexican pakin:
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 they are in separate files. It would not hurt to work a vba in .NET for aut
To omit the process instead of facing this task on foot, which can cause more than one suicide one day. The whole problem is that to make the jump is still dependent on a specialized (and very smoked) advice to understand the guts to Bentley Map and Geographics, it is possible, but the applications should not be as astral (admit, 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.
The solution that I present is viable if there is little data, or if they were stored in a spatial cartridge, so the sad conclusion is that the migration from Geographics to Bentley Map is not so simple, due to the transformation of data. If the Geospatial Administrator, as I 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 "