Just wondering if anyone is using GUID-based workflows in their apps.
This thread mentions something called 'Cross Diciplinary Coordination Services' xDCS, which is apparently and outgrowth of ISM, Design Sync...which looks like a devlopment of the old Design History API. There doesn't seem to be much in the forums about xDCS. Any info online about what it does?
IFC is also based on GUIDs, as does Aecosim and OpenPlant. Mstn has its ElementID.
Aecosim's old Triforma Drawing Extration Manager (DEM) will persist the GUID from the orginal 3d element that produces a 2d proxy graphic in an extraction if the 'Preserve 3d Data' option is ticked. I think that the DV's also provide a similar link when a CVE is generated. Element/Display Handlers?
Recently, Prostructures has offered up the ability to track changes made in Aecosim, and automatically update its rebar objects. Presumably, this is done through reading the GUID's generated by Aecosim.
I also notices this thread, where ideally, the elements in one file would merge with another automatically. Similar to the way PS updates its rebar to suit a change made to an Aecosim wall, it would be good to have a 'smart' merge or copy 'associative' tool, which would allow the GUID's to be saved and used to track updates.
Can the ISM or Design History API be used to provide a generalised tool to 'copy and swap' selectively using the same interface as the Structural Synchronizer?
The app would offer the user to assign a GUID to an object (via the Item Types tool?), that would allow the user to 'copy monitor' objects that are copied into the model.
Maybe, the GUID dependency graph would be stored centrally by ProjectWise? Or in an ISM?
GUID's seem to be useful for tracking things, which must be something that will be increasingly needed in the data-centric BIM world?
Unknown said:It appears that you are looking to be able to ensure proper change notification workflows can be implemented and respected based on each element/component being uniquely identified for any and all applications that encounter it.
Yes, but I was hoping that there would be more. GUID's look like they will be much more important with data-centric workflows. I am surprised that you did not mention Design Sync, ISM, Design History, xDCS etc. It would be good if Bentley had a strategic framework instead of letting each vertical 'roll their own': To promote interoperability between the Bentley 'family' of apps, GUID's would be a 'key' tool.
Unknown said:Though we currently do not provide end-to-end GUID support of component elements across all products and various workflows possible, a combination of MicroStation and ProjectWise does support that level of uniqueness with two different implementations.
Great. But, a lot of users still do not employ ProjW due to its cost and complexity. Maybe something like ISM / DesignSync would be good starting point. Look at Openplant, where most of the steelwork design is done using file-based apps by 'tier two' contractors, who wouldn't be on PW.
Unknown said:ProjectWise does use GUIDs for each unique document. When a document is created in ProjectWise a unique GUID is created (using Microsoft APIs) to ensure the uniqueness of that document (GUID)
OK. This is good for document tracking, but the more data-centric we get, the more granular we will need to be with tracking and versioning information. There is also the increasing need to enable parametric / associative propagation of information across files or other data containers. Data-centric also means more model-based documentation workflows, where information is defined and stored centrally in models or databases and extracted elsewhere in drawings, schedules etc... which would require granular versioning and smarter incremental updates.
Unknown said:Component Indexing feature that allows you to perform space/time/metadata related operation and queries; ensuring a managed document's uniqueness along with the MicroStation design file element IDs uniqueness. ProjectWise also supports "Workflows" that can provide event notification and custom actions to be performed as a managed document changes from one state to the next in a workflow.
Comp Indexing sounds promising. Where can we find more info on this? Which app uses it? One problem that comes up regularly is maintaining persistent GUID's between exports or translations to a coordination format like IFC. The same elements need to have the same GUID's to allow change tracking, and merging / updating of business data supplied by others. Yes, we can't expect all of these guys to be BDN members, or duck the issue by leaving it to the user to manage manually.
How would the user define a Component? We don't want to have to track everything.
Unknown said:MicroStation on the other hand has a couple areas/features that do use GUIDs, but for historic reasons the MicroStation V8 design file format uniqueness of components is resolved using: Design File > ElementID (unique 64-bit integer that should never be re-used even if element/component is deleted).
This is interesting. Where is it documented that the ElementID's should not be re-used? Are the ElementID's sequential? I imagine that GUID's would not be easy to index. What happens with Bentley's SQLite-based file formats? Will the need for GUID's go away? Let's say we have multiple discipline-specific dgndb's for structures, MEP, civils etc. And the MEP supports are linked to both the structural beams (in the structural model) and the MEP model. Can the support modeler pick up the changes in either (like the Aecosim/Prostructures example) automatically and walk through the changes and accept/reject the updates ala ISM? OPMS can do this already but it relies on converting everthing back into its SQL database which is slow.
It looks like Aecosim's GUID's are exposed and available for use by others. What would be required for Prostructures to implement something similar? Is Aecosim's GUID implementation readily transferable? API? Or should Comp Indexing be used? Is xDCS really the same thing as Comp Indexing?
I suppose CI should be a superset of DesignSync which is a spin off of ISM, which adds data/parameter tracking to Design History that only tracked dgn geometry elements. It would be great to reach into excel or SpecWave 'spec modeling' xml documents and use that info to dynamically update dgn or other models.
Unknown said:The MicroStation dependency manager can help ensure any elements that have been identified as related/dependent in the chain allow only changes that are allowed by a product or custom application (present or not) and perform a rollback if any applications in the chain do not wish to allow a subsequent change to occur.
Yes, the DM would be key. I think that the DM manages call-backs at run time; it is not transaction-savvy. Apparently, it does not prioritise how call-backs get processed. Probably uses ElementID's to find the children associated with the root element triggering the call-back?
I suppose that Prostructures is already using it to read the Aecosim GUID info to (re)connect the external elements and maybe using Aecosim's timestamp info to selectively trigger an update/callback? Timestamps sound completely unreliable in thios context. Who's clock would be used? What happens if the participants are global and there is latency. Would ProjW provide a central clock?
Unknown said:So in some sense we do have and can managed most of what you present by the "copy monitor" though we currently do not have that exact type of feature implemented at this time.
Yea. But, the fact that there isn't one speaks volumes.
bump
bump... Will i.model 2.0 provide this missing 'end-to-end GUID support?"