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