[Geoserver-devel] Comparing boolean feature properties in SLD/Filter

Gertjan_van_Oosten · July 6, 2007, 1:48pm

As quoted from Gertjan van Oosten <gertjan@anonymised.com>:

If I try to insert a feature that has a boolean element "isValid" [...]

While we're at it, how do I check for a boolean feature property in an
SLD? I've tried:

          <ogc:Filter>
            <ogc:PropertyIsEqualTo>
              <ogc:PropertyName>isValid</ogc:PropertyName>
              <ogc:Literal>true</ogc:Literal>
            </ogc:PropertyIsEqualTo>
          </ogc:Filter>

and many variations thereof ("TRUE", "True", "t", "1", ...) but none of
these seem to match.

The problem is not in the SLD, because if I change the test to be
against some string property I get the right result; it's just that I
can't figure out what the right literal value for a boolean property
should be...
Oh, one more thing: if I leave the value for isValid empty (NULL in the
database) and test for <ogc:Literal></ogc:Literal> it does match.

N.B. The feature property is returned from my PostGIS store by
Geoserver as either "true" or "false" (all lowercase).

As a final test I tried:

          <ogc:Filter>
            <ogc:PropertyIsLike wildCard="*" singleChar="#" escapeChar="!">
              <ogc:PropertyName>activeAlert</ogc:PropertyName>
              <ogc:Literal>*t*</ogc:Literal>
            </ogc:PropertyIsLike>
          </ogc:Filter>

Wahey, that *does* work (and yes: it only matches the ones that are
true, not the ones that are false or NULL). Still, what's the proper
literal value for a boolean? That's the question.

Kind regards,
--
-- Gertjan van Oosten, gertjan@anonymised.com, West Consulting B.V., +31 15 2191 600

Gertjan_van_Oosten · July 6, 2007, 2:21pm

Noticed a small cut&paste error in my previous message.

As quoted from Gertjan van Oosten <gertjan@anonymised.com>:

          <ogc:Filter>
            <ogc:PropertyIsLike wildCard="*" singleChar="#" escapeChar="!">
              <ogc:PropertyName>activeAlert</ogc:PropertyName>

That line in the message should have read:
<ogc:PropertyName>isValid</ogc:PropertyName>
to avoid any confusion.

              <ogc:Literal>*t*</ogc:Literal>
            </ogc:PropertyIsLike>
          </ogc:Filter>

--
-- Gertjan van Oosten, gertjan@anonymised.com, West Consulting B.V., +31 15 2191 600

Justin_Deoliveira · July 6, 2007, 2:23pm

Hi Gertjan,

Initially I thought that this was related to the previous issue but this one actually works for me. Can you include the structure of your table?

Thanks.

-Justin

Gertjan van Oosten wrote:

As quoted from Gertjan van Oosten <gertjan@anonymised.com>:

If I try to insert a feature that has a boolean element "isValid" [...]

While we're at it, how do I check for a boolean feature property in an
SLD? I've tried:

          <ogc:Filter>
            <ogc:PropertyIsEqualTo>
              <ogc:PropertyName>isValid</ogc:PropertyName>
              <ogc:Literal>true</ogc:Literal>
            </ogc:PropertyIsEqualTo>
          </ogc:Filter>

and many variations thereof ("TRUE", "True", "t", "1", ...) but none of
these seem to match.

The problem is not in the SLD, because if I change the test to be
against some string property I get the right result; it's just that I
can't figure out what the right literal value for a boolean property
should be...
Oh, one more thing: if I leave the value for isValid empty (NULL in the
database) and test for <ogc:Literal></ogc:Literal> it does match.

N.B. The feature property is returned from my PostGIS store by
     Geoserver as either "true" or "false" (all lowercase).

As a final test I tried:

          <ogc:Filter>
            <ogc:PropertyIsLike wildCard="*" singleChar="#" escapeChar="!">
              <ogc:PropertyName>activeAlert</ogc:PropertyName>
              <ogc:Literal>*t*</ogc:Literal>
            </ogc:PropertyIsLike>
          </ogc:Filter>

Wahey, that *does* work (and yes: it only matches the ones that are
true, not the ones that are false or NULL). Still, what's the proper
literal value for a boolean? That's the question.

Kind regards,

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

Gertjan_van_Oosten · July 6, 2007, 2:41pm

As quoted from Justin Deoliveira <jdeolive@anonymised.com>:

Initially I thought that this was related to the previous issue but this
one actually works for me. Can you include the structure of your table?

Straight from PostgreSQL:

Regards,
--
-- Gertjan van Oosten, gertjan@anonymised.com, West Consulting B.V., +31 15 2191 600

Justin_Deoliveira · July 6, 2007, 3:06pm

Hmmm... strange. I am able to get the filter to work with a similar table. Can you turn debugging on and send the error log. It should show the exact sql that is being generated for the query, might give us a better idea of what is going on.

-Justin

Gertjan van Oosten wrote:

As quoted from Justin Deoliveira <jdeolive@anonymised.com>:

Initially I thought that this was related to the previous issue but this one actually works for me. Can you include the structure of your table?

Straight from PostgreSQL:

db# \d features
Table "public.features"
Column | Type | Modifiers ----------------+--------------------------+------------------------------------------------------
oid | integer | not null default nextval('features_oid_seq'::regclass)
isValid | boolean |
name | character varying |
type | character varying |
description | character varying |
timestamp | timestamp with time zone |
geom | geometry |

Regards,

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

Justin_Deoliveira · July 6, 2007, 3:22pm

Oops. i missed the part that the filter is in an sld and not a wfs request. Using it in an sld i can indeed reproduce it... looks like you have found another bug.

I believe the problem lies in the fact that the filter / sld parser does not treat true as a boolean but as a string. When doing a query against postgis this works ok because postgres can cast for you when you do "isValid" = 'true'.

But sld filters are applied in memory afaik and must not be doing the conversion properly. Scheduling another 1.5.2 bug.

http://jira.codehaus.org/browse/GEOS-1198

Thanks for the bug reports!!

-Justin

Gertjan van Oosten wrote:

As quoted from Justin Deoliveira <jdeolive@anonymised.com>:

Initially I thought that this was related to the previous issue but this one actually works for me. Can you include the structure of your table?

Straight from PostgreSQL:

db# \d features
Table "public.features"
Column | Type | Modifiers ----------------+--------------------------+------------------------------------------------------
oid | integer | not null default nextval('features_oid_seq'::regclass)
isValid | boolean |
name | character varying |
type | character varying |
description | character varying |
timestamp | timestamp with time zone |
geom | geometry |

Regards,

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

Gertjan_van_Oosten · July 6, 2007, 3:26pm

As quoted from Justin Deoliveira <jdeolive@anonymised.com>:

Oops. i missed the part that the filter is in an sld and not a wfs
request. Using it in an sld i can indeed reproduce it...

Ah! Strange difference... Anyway, I posted my own work-around, so for
the moment I can use it from my SLD.

looks like you have found another bug.

Rest assured: I am done for today.
Thanks for the quick responses!

Regards,
--
-- Gertjan van Oosten, gertjan@anonymised.com, West Consulting B.V., +31 15 2191 600