Schema - "complex" criteria

Wise forum folks,

One more question for you.  XFM Schema appears to have difficulty with interpreting "complex" criteria (e.g., criteria that reference more than one attribute), such as:

     ([attribute1]>0) && ([attribute2]<100)

Or even better:

     COMPARE("[attributea]","True","") && ([attributeb]>0)

I couldn't find guidance in the Help files addressing situations like this.  Has anyone else tried something similar?

Thanks.

Janice

Parents Reply
  • Ok, I took a look at the road_name criteria.  It looks almost identical to the first example I gave, inasmuch as it concatenates two conditions, each evaluating a different attribute, that share the same basic logic (i.e., both are COMPARE criteria):

        COMPARE("[Road:Name]", "MAIN","") && COMPARE ("[Road:Type]","2-Lane","")

    So Example #1 works - check.  But what about Example #2 that I gave above?  The main difference here is that both conditions have different sort of logic.  The reason I ask is because the last time I tried to implement this scenario, it didn't work.

    Thanks.

    Janice

Children
  • Also, for what it's worth, what's the difference between the following criteria expressions?  Both evaluate a feature's property value as a string against the string value "compareValue".  I get that the second uses the C string compare function "strcmp", but what's really the difference here?  Just curious.

        COMPARE("[feature_instance_alias:property_name]", "compareValue", "")

        0==strcmp("[feature_instance_alias:property_name]","compareValue")

  • COMPARE function allows passing a delimeter string in the last parameter to compare a value against a delimited list of possible values.

    For example...

    From "Performance Notes" paragraph in the XFM Overview section of the Bentley Map Customization Guide (search for  "Performance Notes"):

    If you need to compare a single property to numerous values then use the COMPARE function with a delimited list of values instead of separate COMPARE functions.

    Instead of: COMPARE("[SIZE]","220","") || COMPARE("[SIZE]","240","") || COMPARE("[SIZE]","640","")

    Consider using: COMPARE("[SIZE]","220|240|640","|")

    Regards,

    Chris


    This is a test

  • For your example # 2: COMPARE("[attributea]","True","") && ([attributeb]>0)

    Ensure that attributeb has a value or the expression evaluation will fail.  You could accomplish this by specifying a default value in the expression:

    ([attributeb|0]>0)

    To specify a default value, add a vertical bar character followed by the default value after the property name.


    This is a test

  • Thanks for pointing that out.  I actually have a number of instances where I *want* the expression to fail.  Take my example #2 -

        COMPARE("[attributea]","True","") && ([attributeb]>0)

    When this expression is true, I want to place a cell (Cell B) containing PBA Replacement Text that is populated by Attribute B.  When there is no Attribute B, this expression obviously fails, and Cell B is not placed.  In this case (Attribute B does not exist), I actually prefer to place another cell (Cell A), so I've written another expression to "catch" this:

        COMPARE("[attributea]","True","")

    As you point out, I just need to make sure that the first expression appears first in the .xml hierarchy so that it's evaluated first - otherwise, the second expression will take precedence (and Cell A will be placed for each instance, regardless of whether Attribute B exists or not.)

    Side note: I don't want to pass a default value in the expression (as you suggested) for various reasons.  For one thing, the default value would end up populating the PBA Replacement Text, and I don't want that...

    Just curious, can I write an expression that queries whether or not Attribute B *exists*?  What syntax would I use?

    Thanks,

    Janice