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, 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.
Regards,
Jeff Bielefeld [Bentley]
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.
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
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,