In an earlier post (http://communities.bentley.com/products/geospatial/desktop/f/5924/t/116655) Jeff Bielefeld explained that graphics "Promoted" to a Native Feature still retain any source User Data Linkage information until they are posted into a Spatial Database Feature, providing you the opportunity to extract the linkage information and assign values as a property(s) of the feature. In "Promoting" existing data, I have run into instances where there are Grouped Hole elements with the User Data Linkage on the cell header component that "appears" to be lost when the "Promote" process creates the Native Feature. When you process the sub-features, the cell header is not included as a sub-feature of the feature.
One solution (the only one I can think of so far) is to "pre-process" the original data, and copy the User Data Linkage from the header of the Grouped Hole and attach it to the Grouped Hole components so it would be available when you process the Native Feature sub-features.
Are there any other approaches or methods to access those linkages on the Grouped Hole cell header?
Thanks
Bruce
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.
Regards,
Jeff Bielefeld [Bentley]
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,
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
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.