Ticket #1874 (closed bug: fixed)
Filters may evaluate incorrectly when using features and filters that are read in by Format classes
| Reported by: | ahocevar | Owned by: | ahocevar |
|---|---|---|---|
| Priority: | minor | Milestone: | 2.8 Release |
| Component: | Format | Version: | SVN |
| Keywords: | Cc: | ||
| State: | Complete |
Description
Our format classes do not handle data types. So if we read in something like <ogc:value>200</ogc:value>, this will become "200" and not 200. This is true for filters as well as feature attributes. Now if we want to evaluate features against filters, the following will happen:
"200"<"1000" >>> false
although we would probably have expected to get
200<1000 >>> true
For OGC services, we could rely on WFS DescribeFeatureType to determine if a feature attribute is to be treated as string or as number. For other data sources, there may not be an easy way to do that.
Also, I found out that it would be enough to convert strings either in the filter or in the feature attributes to numbers, because JavaScript seems to auto-convert the string then for the comparison. Since converting strings to numbers for features would slow down our format parsers, it would be sufficient to do this in the Filter format parser (which is currently part of the topp/wfs sandbox).

