I can find documentation for the i-model ODBC connector.
Is it possible to use this with a dgn file as well as an i-model?
Unknown said:I can find documentation for the i-model ODBC connector
i-Models contain EC schema data. The data are stored in XML format in the i-Model and are described by the schema. Those data are created by the application (e.g. AECOSim) when it publishes an i-Model.
The various i-Model connectors work only with EC schema data, which is guaranteed to be present only in an i-Model, not in the DGN model from which it was published.
The various application groups would have to each to create its own connector for that application's data to do what you want. That's one reason why i-Models were invented: to eliminate the duplication of effort among the application groups.
Regards, Jon Summers LA Solutions
John, Phil,
Thanks for that it makes sense when you explain the reasoning.
I have had a lot of success with the i-model connector already - will keep on with that.
R
Hi,
while Phil focused more on the product and its intended use and Jon on technical aspects, I'd like to add own "practical note":
You can use i-model driver with normal DGN (I tried it based on your question :-), but the question is what can be a value of such use? As Jon wrote, business data (items) are stored as ECObjects in i-model files. But in original products like AECOsim Building Designer or Bentley Map, the data are stored in a proprietary format, which is the best for the particular application (and often because such way was chosen in the past). The data are transformed into ECObjects during i-model publishing, so if you open normal DGN file, you will usually see no items in it.
Some applications today dynamically expose their internal proprietary data as items, but if you will open such DGN in a plain MicroStation with no additional application, you will see no items.
With regards,
Jan
Bentley Accredited Developer: iTwin Platform - AssociateLabyrinth Technology | dev.notes() | cad.point
Unknown said:but the question is what can be a value of such use?
I agree. i-models seem to be of limited use. Good for querying stuff on site or for stuff to red line, but not ready very useful for real information modeling work.
The connectors look interesting for extracting a table so that you can print it. But, shouldn't this already be part of the data, normally? Something like Flexitable (or even Resolver One) inside Mstn, would be far more useful than having to export to Excel and fumble with formating everytime you want to review some tables.
I guess it's still early days for all this i-model business. Bentley has its i-ware drivers, Class Editor, I-model Composer, Data Manager and now an i-model Transformer tool... which has an intriguing option to export the i-model as a dgn... write enabled i-models at last ? :-)
SpecWave seems to work on i-models, not the dgn. It would be good to get more of an outline of how all these apps fit together.
Unknown said:Some applications today dynamically expose their internal proprietary data as items, but if you will open such DGN in a plain MicroStation with no additional application, you will see no items.
Sounds like a variation of the AutoCAD zombie / missing Object Enabler problem....? I guess one reason i-models are read-only is that the 'guardian' code is not loaded to make sure all the user's changes are 'kosher'. I suppose, for simple stuff, it should be possible for this to be allowed with the 'element handler' not loaded. Like Excel cells can have formulas that are linked to other cells?
Maybe, a dgn with say ABD or BM data can dynamically expose their internal proprietary data as Items when the dgn is attached as a Refence model, which is normally read-only.
Unknown said:An i-model Transformer tool, which has an intriguing option to export the i-model as a dgn
I'm not sure that's what the i-Model Transformer does, since there is no published information about it. Transforming an i-Model to a DGN doesn't make sense: an i-Model is already a DGN model, albeit one that is explicitly read-only.
Unknown said:The connectors look interesting for extracting a table so that you can print it
That's a rather limited view of what can be done with an i-Model connector. With an i-Model ODBC connector, for example, you would treat the EC schema as one or more database (DB) tables that can be linked with tables in other DBs. That way, someone in accounts, say, can execute a query that reveals the lowest-cost source of materials by linking the EC schema data with his tables of manufacturers' parts and manufacturing costs.
Unknown said:One reason i-models are read-only is that the 'guardian' code is not loaded
An i-Model contains a facsimile of the original graphics. Think of it as a 3D print. The original application data have been converted to EC schema data XML. The original graphic objects are there no more: even if you were somehow able to open an i-Model for edit with the originating application, it would find nothing to work on.
Unknown said:I'm not sure that's what the i-Model Transformer does, since there is no published information about it. Transforming an i-Model to a DGN doesn't make sense: an i-Model is already a DGN model, albeit one that is explicitly read-only.
Only the stuff in the help file...
The Export to DGN transform is used to export a DGN file from an i-model.
The DGN file that gets generated from the input i-model does not necessarily (and in most cases won't) reflect the exact same graphics as the original DGN that was used to produce the input i-model. This is due to the way i-models will often contain generic proxy objects as substitutes for "application-aware" design file elements. Furthermore, the originally published i-model may have had its emebedded schema(s) modified for a specific use case, decided upon when the original DGN was published as an i-model. Therefore, you should not assume that a DGN exported from an i-model can necessarily be "intelligently understood" by the original application that published the i-model.
For the reasons given above, the default file extension for design files produced by this transform is "x.dgn", to make the resulting output file stand out as having been the result of an i-model export.
Unknown said:That's a rather limited view of what can be done with an i-Model connector. With an i-Model ODBC connector, for example, you would treat the EC schema as one or more database (DB) tables that can be linked with tables in other DBs. That way, someone in accounts, say, can execute a query that reveals the lowest-cost source of materials by linking the EC schema data with his tables of manufacturers' parts and manufacturing costs.
Unknown said:An i-Model contains a facsimile of the original graphics. Think of it as a 3D print. The original application data have been converted to EC schema data XML. The original graphic objects are there no more: even if you were somehow able to open an i-Model for edit with the originating application, it would find nothing to work on.