Native vs Inferred Feature Question for Bentley Support

Any feedback?

Greetings Alan,

First of all, for discussion purposes can you confirm that the "grouped holes" which you are referring to are unnamed cells consisting of one or more shapes and/or complex shapes? Are these being used to represent polygon areas of some type?

Next prior to the Bentley Map V8i (SELECTseries 3) 08.11.09 release, native XFM polygon collection feature instances were persisted using standard shape or complex shape elements with optional associative regions. This was done to create polygon feature instances which could be manipulated using standard MicroStation commands w/o requiring the use of the MicroStation drop command. The drop command as you have observed can cause a number of issues such as orphaned database rows which I'll discuss further below. In addition the use of the optional associative region resulted in duplicate shapes being stored in the design file which could sometimes cause difficulties during MicroStation manipulations.

Therefore to improve the handling of XFM polygon collection feature instances, for the Bentley Map V8i (SELECTseries 3) 08.11.09 release we created our own custom Type 106 polygon element. This new polygon element type in Bentley Map removes the need for the use of associative regions, thus eliminating the duplicate shape and complex shape storage requirements. In addition, this new polygon element type fully supports standard MicroStation manipulations as well as hole/solid face determination, important for polygon feature instances which may have holes and/or islands.

Now as with any MicroStation Type 106 custom element type, an element handler must be present to support manipulations. In Bentley Map V8i (SELECTseries 3) 08.11.09 we deliver the element handler which supports display and manipulation of the custom element type. In MicroStation we also deliver a supporting element handler so that MicroStation can display the geometries of the custom element type, but at the same time prevent manipulation. We do this in order to maintain referential integrity between the geometry and any associated business properties. If we allowed MicroStation to manipulate the graphic w/o any constraints there would be the potential risk that the business properties would become orphaned and/or duplicated. Therefore Bentley Map must be present to manipulate these Type 106 polygon elements so that the referential integrity between the geometry and the business properties can be safely maintained.

In your post you state...

Unknown said:

If we have a Group Hole which is an Inferred Feature and it's dropped the record is not removed from the database.

When a complex element such as grouped hole has one or more linkages that point to a row of a table in an external database, the MicroStation drop command does not attempt to delete the associated row. This behavior observed in Bentley Map is consistent with that of MicroStation and as you've seen leads to orphaned database rows.

Unknown said:

If however the group hole is a Native Feature, Map seems to have the intelligence NOT to be able to drop the feature.

In Bentley Map V8i (SELECTseries 3) the polygon collection feature instances as described above are custom Type 106 elements and do not make use of the MicroStation grouped hole element type so the polygon elements are not seen as complex element types and thus are ignored by the MicroStation drop command.

Unknown said:

The preferred behaviour would be that if we dropped the Group Hole of an Inferred Feature, all associated records were also removed from the database. It may well be the case that we have a Group Hole Feature that we want to drop and edit/modify and then promote it back as a new feature. The way it currently seems to works is we're left with orphan records in the database.

Again the result of the orphaned database rows is unfortunately standard MicroStation behavior which occurs during the drop command. Unlike a delete command where you can use the SET DELETE command to control what occurs in the database when an element is deleted, the drop command simply does not have enough context to know what your intentions are, so it simply removes the complex element header leaving the contained simple elements.Now if the database linkages had themselve been attached to the contained elements rather than the grouped hole element header, the orphans would not occur (e.g. since the elements and the associated database rows still exist).

Now having said that, you should be able to use Bentley Map to model native XFM polygon collection elements with RDBMS business properties which support standard MicroStation manipulations without the need to use the MicroStation drop command.

Unknown said:

If we use standard MicroStation and reference a Map file which is made up of Native Features, MicroStation won't let us copy the elements into the file. This is undesirable. A preferred options would be to allow it to copy the elements but strip the attributes off. Perhaps there's a switch somewhere that allows this but if so we weren't able to locate it.

Correct. As mentioned above the custom Type 106 polygon collection feature instances are visible within MicroStation but are considered read/only elements and cannot be copied or manipulated. An option such as you describe that would allow the geometries to be copied is not available today. However using a small bit of VBA code, one could craft a custom copy or fence copy command that would produce the desired copies of the geometries. Also in the Bentley Map V8i (SELECTseries 3) 08.11.09 release, in the Map Manager there does exist a new "Export..." command which provides the ability to "Export MicroStation Elements" from one or more selected map layers. This "Export..." command can be used to create MicroStation design files with standard MicroStation element types, fully symbolized according to currently displayed map layer settings.

Unknown said:

Another problem is if while in Map we Drop a Complex Element but then 'Undo' the drop, the original record(which may have contained a variety of attribute information) is deleted and replaced with a new blank record. The more desirable response to undoing a drop would be for the original record to be reinstated........not just the original feature graphics.

As discussed above, the MicroStation drop command does not have enough context to know what you might want to do with the associated database records. Similarly the MicroStation undo command has no way to persist copies of any deleted database rows for a potential INSERT back into previously linked database table. These are of course is a well known issues when using external RDBMS business properties with MicroStation elements. I would recommend the use the Bentley Map polygon collection element which eliminates the need to use the drop command.

I would also like to mention that one of the reasons that many Bentley Map users choose to use XFM feature instances with XML business properties is to have better integration with the MicroStation undo/redo system. If you have a need to have your business properties persisted in a relational database for reporting purposes or integration with other business systems, then you may want to consider the use of Bentley Map with Oracle Spatial or Microsoft SQL Server spatial persistence where in both cases the geometries and business properties are considered part of a feature "object" bound together, thus eliminating the traditional orphaned database record problem.

And finally, I hope that this response has helped to explain some of the observed behavior. I may not have answered all of your questions but at least we can continue this discussion with the above general understanding of these issues.

Thanks Jeff.

Since we seem to have a couple of issues with inferred/native features we'd prefer not to mix 'inferred' and 'native' at this stage but rather keep them as 'inferred' at this stage.

With the latest version is there any switchwe can toggle that stops the new UID element being included ie. stops making them Native Features?

Thank you.

Alan,

Depending on your exact needs, the following configuration variables may be helpful.

• MS_GEOXFM_NO_CLOSEDELEMENTCOLLECTIONS - If set to any value, disables dynamic feature scoring from automatically
  inferring closed regions as polygon collections.
• MS_GEOXFM_NO_DYNAMICSCOREDFEATURES - If set to any value, disables the "Dynamic Feature Scoring" (DFS) engine process
  which infers feature classes from standard MicroStation elements.

Thanks Jeff.

That's not really what I meant......

With Map SS3 additional XFM data is stored as XAttributes which is incompatible with

MicroStation, our graphics only need the mslink so this extra data is not required

but there does not seem to be any method for turning this "feature" off in Map.

The Map files are used as base (background) files for MicroStation users and when any

attempt is made to copy elements from these files an "XFM Feature element not valid for tool"

error occurs.

All original elements with the ODBC links (i.e. inferred features) have no issues, only

new elements placed with Map (i.e. native features) have this issue.

The current workflow using base files has worked well for many years and we may have to

consider making some changes but this would be a last resort.

The simple solution is to not attach the XAttributes, however any other suggestion would

be appreciated.