[BM SS4] User Data Linkages and Group Hole Elements

Bruce,

I've confirmed the reported behavior of the "Promote" process not retaining database linkages when processing grouped hole elements. Upon further investigation have determined that this is a known issue with an existing Bentley Map defect on file.

Considering this problem and what you are attempting to accomplish as described in this thread I developed the attached Bentley Map MVBA promote1.mvba example application which uses Dynamic Feature Scoring (DFS) to locate elements (including grouped holes) to be promoted to native XFM polygon collections. During the promote process the existing business properties (from the database) are copied from the inferred DFS feature instances to the new native XFM polygon collection feature instance. The process of copying these business properties can be eliminated or modified as desired (e.g. maybe only copying the MSLINK value) to suite your specific data conversion needs.

promote1.mvba

Jeff:

I tried again, this time WITH an active DB connection and got the same results (no apparent property enumerator). Now, the specific GROUPED HOLE inferred feature components are on "Level 1" and the defined feature class level is "Siteusepermit". My DFS .xml file is very simple:

<FeatureScoringRules minScore="100">
<Feature useCriteria="" name="Siteusepermit_Collection">
<Rule type="DBEntity" score="100" entity="755"/>
</Feature>
</FeatureScoringRules>

Thanks,

Bruce

I've attached some sample data with a couple of GroupedHole elements that illustrate no property enumerator is being found for the inferred features.

JeffAtBentley.zip

Bruce

Bruce,

After a quick review, I believe your use of the DFS rules file is causing the observed difference when running the promote1.mvba process. I will perform some additional verification testing and update you with my findings.

Question, I noticed that all polygons are linked to a single database row. Once promoted and posted to your spatial database you are expecting the result to be represented by a single polygon collection feature instance (e.g. single row, multiple geometries) as well, yes/no? If yes then I will need to modify the promote sample code to use the MSLINK value as a key to identify those graphic elements which should exist in the same polygon collection feature instance. Please let me know.

Bruce, thank you for that confirmation. If you could send me one more sample design file that contains shapes, complex shapes and grouped holes connecting to at least 3 different MSLINK values then I will complete verification testing of my revised code which will allow you to do the conversion in a single step.

Bruce, thank you for that confirmation. If you could send me one more sample design file that contains shapes, complex shapes and grouped holes connecting to at least 3 different MSLINK values then I will complete verification testing of my revised code which will allow you to do the conversion in a single step.

Here is some sample data:

7181.jeffAtBentley.zip

Thanks,

Bruce

Bruce,

I appreciate the additional sample data. I've been out of the office for the past few days travelling on business but earlier today using the new data I ran the attached promote2.mvba process which created 4 new polygon collection feature instances that I then successfully posted to a Microsoft SQL Server Spatial database instance.

Before running the promote2.mvba process you will need to modify your DFS rules XML file so that the feature name attribute is different than that of the feature class name for the promoted feature instances. For example I used "MySourcePolygons" as seen in the following...

...which you will see referenced in the VBA code. This change is required so that XFM can enumerate the business property names on the inferred feature class and read the original MSLINK property value.

To perform the data conversion I used the following steps:

1. Modified the DFS rules file as described above.
2. Started a new Bentley Map session using a Bentley Geospatial Administrator defined workspace that included a registered Microsoft SQL Server Spatial graphical source and a MS_GEOXFM_DYNAMICFEATURESCORING_FILES macro which referenced the DFS rules XML file.
3. Entered "VBA RUN [promote2]Module1.promotePolygons Siteusepermit" and followed the prompt, pressing a Datapoint to accept and process the entire design file.
4. Using "Analyze Feature" reviewed the result of the promote process, verifying that the ORACLE_LINK business property on each feature instance had the correct value.
5. Performed a spatial "Post" operation to upload the promoted polygon collection feature instances to the spatial database.
6. Performed a spatial "Erase" operation to remove from the session the locally cached polygon collection feature instances.
7. Performed a spatial "Query" operation to fetch the polygon collection feature instances from the spatial database.

Please note this promote process does not attempt to remove from the design file the original input MicroStation elements. I will leave that removal to your discretion.

promote2.mvba