Property Based Symbology

Janice,

Never too late, thank you for your input. WRT a potential timeline, this capability will not be included in the forthcoming Bentley Map V8i (SELECTseries 3) 08.11.09 release. This new capability along with many additional customer requests are being evaluated for possible inclusion in subsequent Bentley Map product releases later this year.

Finally, I will add that everyone's feedback on this particular issue has definitely been helpful.

I realize I'm a bit late to the conversation, but just wanted to throw my support behind this as well (better late than never, right?)

In building a schema for our organization we're encountering the same situation described by Gerald and Matti (criteria and symbology definitions spiraling out of control), which has forced us into trying other less-desirable solutions to manage this - pre-processing our files using FME workbench, etc.  Development of PBS or "FBS" would be a HUGE help here.  

Jerry's suggestion is minimally useful to us (and likely others who would benefit from PBS) since we - a Federal mapping agency - don't fit into one of the Industry "boxes".

So, glad to hear you're considering this for future development.  Any ideas yet of a timeline for release?

And about Jeff's questions....

1) Frequently!

2) Mainly MDL and look-up tables, also experimenting with FME to run some more complex queries.

First of all, thanks to each of you for your input, much appreciated. Next as mentioned below, for a future Bentley Map release, we are considering adding the ability to use expressions (including use of custom functions) when defining symbology key values. Your input on this matter has been invaluable.

Just a note, there are Industry solutions Bentley provides for different industry platforms ( Electric, Gas, Substation, Comms, Conduit, etc. ) that take into account the needs of the respective industries.

These solutions provide tools outside of the GSA to configure the system for criteria, PBS, PBA, connectivity, additional standard placements and forms generation that do not require extensive editing of the XFM schema  file used by the GSA. The tools actually generate the XFM schema used by the GSA, that can then be used to generate the workspace needed.

All of these solutions use Bentley Map as the base technology.

If you have not already done so, maybe looking into these solutions would be worth your time.

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.