[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

One again - Thanks for the explanation and the possible work-around. I will look at the provided example. It sounds like a possible good solution.

As a FYI, I did write some VBA code that does take the Grouped Hole elements (i.e. un-named cells), read the User Data Linkage from the header and then "attach" the linkages to the sub-elements. I haven't attempted to "Promote" one of these via Bentley Map yet, but I think it may be another alternative for a one-time attempt....


Thanks,
Bruce

When I run the example code, once the inferred features are located and ILocateEvents_OnFinished() is called, the code attempts to find the PropertyName for "Mslink" in the function getMslinkPropertyName(). Once in that function, the property enumerator always comes back "empty" - no properties are found. Is that because we are searching the "inferred feature" and the created Feature Instance? Should the inferred feature return a valid property enumerator?

...yes, a DFS inferred feature instance will return a valid property enumerator. Does your session have an active database connection? When you perform "Analyze Feature" do the business properties from the linked database row appear?

IIRC, I did NOT have an active database connection, but I *was* able to "Analyze Feature" and see the property names (no values). The issue remains as to how to extract an existing User Data Linkage value from a Native and.or Inferred "Group Hole" polygon. Once you are processing a "feature" it seems you don't have access to the "source" graphic element.

IIRC, I did NOT have an active database connection, but I *was* able to "Analyze Feature" and see the property names (no values). The issue remains as to how to extract an existing User Data Linkage value from a Native and.or Inferred "Group Hole" polygon. Once you are processing a "feature" it seems you don't have access to the "source" graphic element.

Bruce,

When I developed the example promote1.mvba I tested using both shape, complex shape and grouped hole elements. The fact that you indicated a property enumerator was not being returned for a DFS inferred feature instance leads me to suspect your data is somewhat different than what I mocked up. Let me ask, are your non-promoted grouped hole elements already on the same level as the level defined in the (to be promoted to) feature class definition? If they are it may cause the behavior you describe. In my test case the (to be promoted DFS inferred) grouped hole elements were on a level different than that of the (to be promote to) polygon collection class definition.

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.

Ideally, each polygon collection will be a single row in the database. I wasn't expecting to be able to do that initially. I was thinking the first step is to get each polygon into it's own record, with it's User Data MSLINK value, and, as you observed, there would be more than one polygon/MSLINK for some of the data. Step 2 was going to be query for MSLINKs where the count>1, and "combine" them into a single "record". If that can be done as one step, it would be that much better...