Strip XFM data from features interactively or via code

Gerald,

In Bentley Map today, there does not exist any user level type command that strips intelligence and linkages from an XFM native feature instance. There are however some ways to achieve this result using the Bentley Map API using C or C++ native code. I could assist you with development of such a command but before we venture down that path I'm quite interested in the workflow issues described in your post.

When an XFM root feature instance is copied, Bentley Map is designed to create a copy but ensure that the (new) feature instance can stand on it's own. In the described Oracle Spatial workflow you should be able to query an existing XFM feature instance from Oracle Spatial, copy it, modify the geometry of the new feature instance and post it back to Oracle.

Are you possibly copying sub-feature geometries? If so then the behavior is controlled based upon the "Propagation Rules" defined as part of your XFM schema. These "Propagation Rules" allow you to define (as part of the feature class definition) the desired behavior during MicroStation manipulatiion commands such as copy, move and delete.

The following video illustrates a single XFM feature instance of a cable with multiple annotation sub-features. The feature class definition has defined the "Propagation Rules" in such a way that whenever the root linear cable feature is moved, all annotation sub-features (children) move with it. The annotation sub-features themselves each have rules that define their behavior duing MicroStation manipulation commands. For example, the blue sub-feature text elements (Cable - 2, Cable 10) are allowed to be moved independent of other parts of the feature instance, however the orange sub-feature text elements (Cable - 2 - A, Cable - 2 - B) always move with their immediate parent. Each orange child sub-feature text element is allowed to be moved independent of it's parent.

Please note that double clicking on the video once it is playing should enable full screen video mode.

Please refer to the "XFM Feature Propagation Rules" section of the Bentley Map help for additional details.

Could you provide me with a sample design file in which the XFM feature instance does not exhibit the behavior as you would expect? A copy of your XFM schema would also be valuable for diagnosis. Depending on the size of your design file and schema, you may want to post to our FTP site using these instructions then notifying me of the upload.

Jeff,

That got me thinking and I just double checked what the actual error is.
Looks like the Feature ID's are acting properly as you describe.
Turns out that the problem is with database ID's.
We have a sequence in Oracle XFM_ID_SEQ that is set up in the "Id Generators" in the GSA.
Everything works fine normally.

However, when we copy an element then on post we get a unique key violation on the XFM_ID.
So apparently MAP is not attempting to pull a new ID from the sequence.
Is this expected?

None of the features in question at the moment are sub-features, but you bring up a good point.
I do need to review the GSA to see what behavior we would get in that case, I would not be at all surprised if this is incorrect / incomplete as we have not gotten to that point in the project yet.

Currently for all the root features, with no sub features, all of the propogation rules are set to "Never".

I will gladly send you the GSA. I do not have it available at the moment, but will later tonight.

Thanks!
-G-

Gerald,

First thank you clarifying what was actually occurring. I wanted to ensure that you were aware of the purpose of "Propagation Rules" so that you could apply them as desired in your workflows.

Next, the copied feature instance should be seen as a new thus causing the Oracle Spatial post process to insert one or more new rows (depending on the feature class definition) and obtain new required primary key (PK) values where necessary, from your sequence. If this is not occurring then I would suggest that you file a Bentley Service Ticket so that our analysts can fully diagnose the problem

From what I can tell thus far in this thread, what you are attempting to do is a fully supported Bentley Map workflow.

Jeff,

Thank you. Creating new features works perfectly. Promoting features works perfectly. When copying, they are indeed flagged, recognized as "new" features and assigned new UUID's. But on post they are not getting new PK values from the sequence. So it looks like I will need to file a service ticket.

Getting that working should solve one of the challenges.
Now, back to the other part of the conversation.
How about the ability to strip the linkages off of copied elements for the sake of using copies / offsets as construction lines and such?
These new elements would be completely disposable and do not want them to be posted back and do not want to damage the existing feature.

My C skills are very rusty. I'm from the old K&R C days before they started decorating it with "+" and stuff ;-)
But that doesn't stop me from hacking away. Although I am quite proficient in other dev platforms.

So do you have some guidance to point me in the right direction on how to accomplish this the proper and safe way?
It would be much appreciated!

Thanks,
-G-

Gerald,

It good to hear that your feature creation, promote and copy processes are generating the UUIDs as expected. Once you file a Service Ticket for the failed post process, I'm sure our support analysts will be able to assist and determining the cause of the failed PK generation.

Regarding the stripping of the XFM intelligence from copied elements, could you describe how you would want a command like that to work? For example, do you first want to copy the feature instance, then remove the intelligence in a separate step? Would you prefer to have a special copy command that allows you to select any part of an XFM feature instance and copy it (as you do with MicroStation) to a new location w/o the intelligence?

Depending on your response I may be able to craft a small application that achieves the desired result.

Jeff,

The key part is a method to strip the linkage from a copied element.
The "copy" itself could result from a straight up copy or copy parallel for the most part.

In the end, I expect to end up with seperate commands that does everything self contained so there is no chance for the user to forget a step.
The copy example would be pretty much exactly as you described:

Choose special copy command and select element to copy.
The command will create the copy, remove the linkages, set level and symbology etc. appropriate for disposable construction lines.

I'm sure there will be situations where drafters will end up with copies of features from some of the many native commands. In those cases I would like them to be able to create a selection set and run a command to strip linkages.

If you could craft a small app that achieves any of those that would be terrific!
I would then be able to take it from there and create the other variations as needed.

Thanks!
-G-

Jeff,

The key part is a method to strip the linkage from a copied element.
The "copy" itself could result from a straight up copy or copy parallel for the most part.

In the end, I expect to end up with seperate commands that does everything self contained so there is no chance for the user to forget a step.
The copy example would be pretty much exactly as you described:

Choose special copy command and select element to copy.
The command will create the copy, remove the linkages, set level and symbology etc. appropriate for disposable construction lines.

I'm sure there will be situations where drafters will end up with copies of features from some of the many native commands. In those cases I would like them to be able to create a selection set and run a command to strip linkages.

If you could craft a small app that achieves any of those that would be terrific!
I would then be able to take it from there and create the other variations as needed.

Thanks!
-G-

Gerald,

I've crafted and posted a small VBA and native code application here which is described as follows:

Files: strip1.mvba, strip1.dll, strip1.ma

Purpose: Provide a command that can be used to interactively copy and create simple MicroStation elements from Bentley Map XFM feature instances.

Notes: This application requires the services of the provided strip1.dll to perform the removal of the intelligence on the XFM feature instances while VBA portion handles element selection. By having element selection in the VBA code, users can modify to suite their specific needs.

Throughout this application, at no time are the original XFM feature instances ever modified. Copies are always made. When performing interactive copies, the operation is similar to that of MicroStation in that the user can dynamically transform the location of the copied element. For file, fence and selection set processing, no attempt is made to perform any transformations (e.g. all copies are made in place). The ability to create copies of elements from reference files is supported.

Installation: The strip1.dll, strip1.ma files included in the archive should be placed in a directory pointed to by the MS_MDL configuration variable. The strip1.mvba application should be placed in a folder pointed to by the MS_VBASEARCHDIRECTORIES configuration variable.

The following video provides a brief narrated overview of the commands operation. Please note that double clicking on the video once it is playing should enable full screen video mode.

Please let me know if this command is at least somewhat along the lines of what you desired.

Jeff,

Thank you very much.
This addreses the task of copying elements very well, but maybe a little too well.
It leaves my quest for knowledge a bit unsatisfied :-)

I was kind of hoping for maybe a little less, in maybe just a StripXFM (ByRef ElemDescrOfCopiedFeature).
Since your method performs the copy internally it doesn't help me solve the other issue of stripping linkage off of user copied features, like copy parallel for example.

I am curious as to what is happening within the DLL.
Is it copying the element and stripping the XFM?
Or is it copying the graphics only and not attaching XFM?
What is the effect of performing a copy from the GUI? Clearly the element is being assigned a new UUID, but is the XFM pieces limited to element linkage or is it also copying/creating an underlying non-graphical element? So if one was to forcefully strip the attributes from the graphics then additional pieces would be orphaned with undesired consequences.?

I am kind of going in circles in the research I've been able to do.
Which API(s) would really come into play?
I am not finding anything that looks like what I am looking for in the XFM Programmers Reference Guide.
The Bentley Map MDL Library (Map_SDK.chm) does mention the existance of mdlMap_modifyStripFeature method but is light on details.

So yes, what you provided does an excellent job of dealing with the copying without XFM.
However, I still have the challenge of handling elements already copied through the GUI and other ideas I would like to implement.

-G-

Gerald,

You're correct, The current VBA example calls a native code function in strip1.dll that performs both operations. Copying an XFM (root or sub) feature instance using the MicroStation copy command(s) causes Bentley Map to first evaluate the propagation rules (discussed earlier in this thread) then perform required copies of any graphic elements and/or XML data required to properly represent the feature instance. If you forcefully remove attributes from an XFM feature instance, then yes there is potential for orphaned business intelligence.

In the current Bentley Map public API you won't find functions or methods required to perform the removal, so you have not overlooked anything.

I'll update the example to include a new function which performs just the removal of the XFM feature instance intelligence, and not the copy. I'll also consider adding some code that would perform a "demote" type operation on existing feature instances, one that you could use to remove the intelligence from XFM feature instances which may have been copied using whatever means. I'll try to post the updated example early next week.

Gerald,

I've got a preliminary version of the modifications discussed late last week working. With these changes the VBA application can now optionally request that the native code portion of the application only strip the XFM intelligence such as the method you suggested StripXFM (ByRef ElemDescrOfCopiedFeature).

However while implementing the changes a number of questions began to come to mind. First of all, this type of application has no way of knowing what is a copy and what is an actual legitimate feature instance. For example, if your application was to pass a reference to an element representing a graphic root level feature that has child sub-features, what would you expect the result to be? I would think you would not want to allow this to happen since doing so would orphan the sub-features. In the previous provided implementation, always working with a copy of the element mitigated this risk. I can imagine that this type of removal should only be allowed for those portions of a feature instance that have no child sub-features.

I'm wondering if we could discuss possibly by phone some of the subtle issues that arise for a tool such as this. Please send me a private message to discuss the possibility of a more in depth conversation on this topic.

Jeff,

Ah, excellent point.
I didn't fully consider this as we do not yet use the propogation much, but suspect that we will in the not too distant future.
I suppose we could traverse the relationship tree and strip from the bottom up, but that adds a great deal of complexity.
I suppose in the short term, the user would need to select all of the related elements and strip the XFM.
If they did not, then it woud / should rightfully generate errors on post.

However, my expectation is that the original source features are still sitting in Oracle unaffected as hopefully the tool does not register as a delete; that would be bad if they were to select all the queried elements and choose to Strip the XFM. Actually, at times this might even be desirable to do this on everything. But of course there are ways of accomplishing that via FF or Export.

Will contact you offline.
Thanks!
-G-