Our users often have the need of creating new feature definitions on-the-fly that are only relevent for a particular job, if not just a single map. While these could be defined in the GSA, we refrain from during so since
In the pre-Bentley Map era, creating a new feature definition would be accomplished by creating a new level, setting up the symbology and start working on this level. This method seems to transit well into the Bentley Map GSA-setup as the first element drawn on the new level will adopt the geometry type from the element and create a new feature definition in the Session-category within the Command Manager. Every subsequent feature created using this new entry in the Command Manager will be a native feature using the symbology defined by the level.
This works well, but the usage is limited to creating new features by hand using the placement method created when the feature was dynamically scored. The reason for this is the lack of creation of a corresponding promote method. As such, our users are unable to perform tasks such as
Is it somehow possible to control what methods the DSF-engine produces (i.e. Promote in addition to Place)? If not, I would like a change request on the matter.
Can you step back and approach this from a different direction.
1. Turn off DFS. This is only looking at it from a level / geometry point of view, right ?
2. Use the promote for a existing defined feature to move these inferred features to native features.
HTH
It's not about changing inferred features to native ones, it's about changing native features with in existing feature definition into native features with a dynamically scored feature definition.
I'll try to clarify using a simplified example of what happens in our production environment.
My user has a model containing data - all of it tied to feature definitions in the GSA. One of these definitions is Building. Now, for just this single, particularly map, some of these buildings should be distinguished from the rest, so the user creates a new level called BuildingSpecial and draws a shape element, thus creating the BuildingSpecial feature definition through DFS.
If the BuildingSpecial feature definition had a promote method, the user could select the Building-features that should be changed and promote them into BuildingSpecial. Right now, he has to digitize all of them by hand through the BuildingSpecial's Place method.
To quote myself, we cant predict each and every feature definition the user might need and we don't want to undergo the cumbersome task of adding new feature definitions to the schema, when said features are rarely used .
What we want is the combination of flexibility and guarentee of mutual geometry types that the feature definition created through DFS allows for, without having it limited to creation through the Place method. This could be achieved quite elegantly, if the dynamically scored feature definitions had a promote method.
We solved the issue by developing a custom Promote tool. My question no longer has relevance.
Answer Verified By: Sebastien Lefrancois