In Mstn CE, users can now reference the new navigator i.model format that is based on sqlite... its ' secret sauce '. The file sizes are hugely smaller, and I think that they load faster as well although I am told that this should not be the case. I am wondering if there are plans to adopt this more database friendly format for OPMS in future. 1. OPMS seems to work like Bentley Maps model server, based on Oracle Spatial. All the dgn elements are converted to and from a database format that is not bound by its file storage structure. This allows al kinds of nice parametrics and propagation to happen... easier. The cost would be the conversion and transaction check-in/out process that needs to happen every time a user needs to get at his data. I think that OPMS now allows the user to keep the checked-in dgn on his local folder and synch to OPMS after he loads the dgns. Why not just use the i.model format which is database file. "To take advantage of this wonderful tool, Bentley joined the SQLite Consortium and embarked on a multi-year project to transform all of the information in DGN based i-models into an SQL schema based on SQLite. In fact a mobile i-model is a SQLite file. That means that all information from DGN-based (and other formats) applications appears as normalized rows in a SQL database. And, that same file can be combined with any other SQL data source to be “joined” by business logic in SQL." Hopefully, this will speed any syncs up because OPMS would be comparing two RDMS database formats and not one DB and one CAD format. The i.model would function as a database cache and deltas can then be sent using high level database short-hand over the WAN/LAN. I understand that even using the GPU 's to get order of magnitude speedups are possible using SQlite. Maybe one day, OPMS would be run on the cloud with racks filled with GPU's linked together to allow large in-memory databases. 2. SQlite is not designed as a client-server DBMS and doesn't do concurrent writes but it is apparently possible for it to function as the storage engine. Some may find this counter to the 'one big source or playing field' aims that OPMS is based on, I think that its no getting away from the fact that there are some 'natural' segmentation lines between the disciplines. QSlite supports sharding and PDMS has always been hierarchial . This would also provide a middle ground between the centralised datastore OPMS offers and the file (.ism, i.dgn, .dgn, .i-model, .dwg, .ifc etc etc) based world. Bentley has always been about 'federating' file-based info. OPMS doesn't seem to do this very well at all, having to rely on a second tier of file-based workflows based on file based tools like Reference files/ XRefs to provide much needed interoprability. It has only recently provided an ISM-based connection to a handful of structural apps. Even the check-in/out dialog to OPMS has gotten more ISM-like. ...
↧