Property Based Symbology

Krister,

The ability to use expressions when defining symbology key values is being considered for a future release. I would be quite interested to hear from you (and others) comments on the following:

• How often do you store graphic symbology settings in an external source such as a database or resource file?
• If you have additional business rules which determine graphic symbology for your feature instances, what development language has been used for implementation?

It depends from where the data is imported in database. Maybe the symbology is not stored directly in database but at least it should be possible to calculate the values and use the result directly

I agree with Oto. In our case we import large numbers of dgn-files with different content and we want to be able to display them exactly as they where created. With proper PBS you could do that without knowing details about the symbology.

/Krister

Real PBS is something that I believe has been desperately needed for a long, long, time.
After you reach a point of complexity, the existing approach becomes unmanageable.

For example, lets say that you have a bunch of features, say coax cable, that you want to differentiate graphically but don't want to create seperate features for each type. You can have quite a large variety of types, sizes, uses, etc.
Say you want to use all 8 internal linestyles, up to 8 lineweights, and only 8 colors. That's 512 possible combinations.
Because each field has to be tested independently for Color, Weight, and Style, you need 3 entries in the GSA per combo.
This means up to 1,536 seperate entries!
Of course we don't actually need all of those combinations, but it is common to use about half of them.
We have had to resort to writing programs to crowbar the values into the GSA XML file because it is an insurmountable task to enter manually, and accurately.

What if you wanted to "support" ad-hoc values of user's choice as drawn? If you limit yourself to the built-in styles, 32 lineweights, and 255 colors, that blows out to almost 200,000 entries in the GSA. Of course that is over the top, but perfectly achievable if it was as simple as:
Color = [ColorCode]
Weight = [LineWeight]
and so on.

Sadly, because the symbology is not directly related back to a field, to populate / update the underlying values when posting means writing a tool to perform automatically.

As is all too often the case in GIS, users are left to write tools to accomplish what we believe should be natively supported. Even ESRI folks say but no-one would ever want to do this, however the request is so common that a custom renderer to symbolize color, style, and weight by attributes was included as one of the examples in the SDK.

Frequently when I convert MicroStation or other CAD data for consumption by GIS apps I include these as attributes as fields. In a number of these apps I am able to use these as desired. It is quirky and frustrating that I can have ArcMap use these fields for rendering converted MicroStation data but cannot do this in Bentley Map.

I have not investigated writing an add-in for Map to do this, so do not know if it is do-able or practical. To me it would seem natural to include such capability natively in Map.

I couldn't agree more with Oto, Krister and Gerald. And for exactly the same reasons. What really would rock would be "FBS", or Function Based Symbology!

Let me take a complex but practical real world example from one of our applications - the symbology of a telecom cable depends on up to four properties:

1) technology (copper, fiber, ...)

2) assembly location (underground, aerial, underwater, ...)

3) usage state (operative, planned, demolished, ...)

4) connectivity (not connected, connected at one end, connected at both ends)

Actually, connectivity is not a real property of a cable, but it is determined by the current topology of the network. It should be calculated cable by cable, for which task a function would make a perfect tool. (In practice however, we do maintain connectivity as an attribute of cable, using database triggers. This will boost performance, anyway.)

As Gerald noted, combinations of properties like these will explode the number of criterias and symbology definitions. Life would be so much easier if we could just write a simple (or complex) function and use its result in GSA to determine the correct color, level etc. Currently, to cope with the upzillion different cases, we also need to write auxiliary programs to produce XML code for all the criterias and symbology settings, and hack the XML file directly, outside GSA. It's not that difficult, but I hate to do it anyway.

About Jeff's question:

1) We frequently store symbology settings in the database.

2) We have mainly used MDL for determining symbology of features. Also, we use database functions for more complex calculations.