Have defined criteria using COMPARE function and used them to set the symbology (cell, line and fill colour) in Geospatial Manager, for features that were generated by registering some SQL server geometry tables.
The symbology is not being applied when the feature layer is loaded from the database into the current working drawing. It looks like the criteria is being ignored or is not working, however there appears to be no way of testing the criteria to determine if there is a syntax error.
I do not reproduce the issue. When using registered features from GSA, be sure to selected the Graphical Source name in the Map Connection dialog. In that way, it will used symbology and criteria defined in the GSA schema.
We are using the graphical source defined in the GSA. The issue may be with the criteria but there seams to be no way to test it and very vague/sparse documentation on how to define it.
If we use a user defined symbology rules in Map Manager it works fine. Also it is inconsistent as some work and some don't.
to test it, you may create a placement method in GSA. Right-click on feature and select Insert Polygon Placement Metadata. check-on "Sow Properties At Placement" and click Ok. Then, go to User Interface > Command Manager and Update command Manager List. Save, export, and run from schema.
In Map, place polygon by setting appropriate Asset Class to see if it applied properly the color defined by the criteria. Like this you will be able to validate criteria defined without before querying feature database.
Otherwise, I do not reproduce any issue with Criteria on my side. Be sure to use Feature Name and not display name for Criteria. Also, another setting could cause unexpected behavior is the display style. Be sure to use Wireframe to avoid any display issue.
Of course, it should not be inconsistent. Criteria are True or False. Symbology in Map Manager using where clause and it is different than Criteria from GSA. In a Map Definition, Symbology will always override symbology display defined in the schema. It should be consistent as well. Which of those two gave inconsistent results? both?
About Criteria documentation, we have some examples defined in help and wiki. If you do not find enough about specific request you want to build, please do not hesitate to ask to Communities, any members of our Communities could bring solutions and tricks.
Could send me your schema XML? Your settings are good in screen captures above. But even if I do not have access to your data, maybe I could find the culprit ? why it does work as you expected?
I hope that helps.
I have sorted out the issue.
If the database column in source table is of type char or nchar then the value read into the feature includes the whitespace at the end of the value required to pad it out to the length of the column. Padding the compared to value out to the same length resolves the problem and results in the criteria matching as expected. How ever this inconstancy in handling whitespace creates another issue when editing features that include properties based on domain lists.
Domain list values are trimmed of the whitespace but the property values in the column that the the domain list is associated with, are not. As a result the edit form dose not match the current value to a value in the list and instead sets it to the first value. After selecting ok and posting the change back to the spatial table this value is written to the database undenounced to the user and results in the data being courted.