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.
Hi,
Promote method does not exist for DFS feature. However, you can use Reset Feature tool (Tools > Geospatial > Utilities > Reset Feature) to "synchronizes the symbology of an element (or optionally, a collection of elements, if a fence is used) with its feature definition. This enables a user to return the correct feature definition to an element(s) that may been changed inadvertently during a workflow." (source: Bentley Map Help File)
I hope that helps,
Hi Sebastien,
I thought as much. We are aware of the reset feature tool and use it frequently when applicable, but what I described is a different situation.
The user is working on a collection of existing native features that already have a feature definition, but some of that data should be changed to the feature definition defined by the DFS under the Session category. This is not possible due to the lack of a promote method. Of course, the user has the possibility of changing the symbology of either the newly created level or the element itself, but this is inconvient, as a future Reset Feature call would revert these changes, and even if the features are never reset, I would consider it bad practice to mix feature-based and level-based symbology.
During my testing of the feature definition created by the DFS, I learned that the DFS does in fact create a Placement-method (Cell, Linear, Text, Polygon, depending on the geometry type of the first element drawn on the level). This method can be accessed either through the Command Manger or through the key-in "activate method [NewlyCreatedLevel] | Place".
With this being the case - the DFS engine already being equipped with functionality for creating methods - having it create Promote methods in addition to Place methods cannot be a far fetched task.
Anyway, thanks for the quick response.
- Anders
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