Ticket #1874 (closed bug: fixed)

Opened 4 years ago

Last modified 4 years ago

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).

Attachments

1874-r8507-A0.patch Download (2.9 KB) - added by ahocevar 4 years ago.
One possible solution
1874-r8507-A0.2.patch Download (2.9 KB) - added by ahocevar 4 years ago.
One possible solution. Patch against the topp/wfs sandbox.
1874-r8505-A0.patch Download (2.7 KB) - added by ahocevar 4 years ago.
patch against trunk
1874-r8924-A1.patch Download (6.0 KB) - added by ahocevar 4 years ago.

Change History

Changed 4 years ago by ahocevar

The above patch is against the topp/wfs sandbox.

Changed 4 years ago by ahocevar

(In [8508]) added numericIf method (references #1874)

Changed 4 years ago by ahocevar

One possible solution

Changed 4 years ago by ahocevar

One possible solution. Patch against the topp/wfs sandbox.

Changed 4 years ago by ahocevar

  • keywords wfs sandbox removed

Actually not only the topp/wfs sandbox is affected by this, but also the current trunk. I am attaching a new patch which is against trunk.

Relevant tests still pass.

Changed 4 years ago by ahocevar

patch against trunk

Changed 4 years ago by ahocevar

  • state set to Review

Changed 4 years ago by fredj

The patch looks good but could the numericIf function be moved into the OpenLayers.Number name space ? (lib/OpenLayers/BaseTypes.js)

Changed 4 years ago by ahocevar

  • owner changed from tschaub to ahocevar

Changed 4 years ago by ahocevar

added new patch with tests, moved numericIf function to OpenLayers.String (not OpenLayers.Number as suggested by fredj), and use our isNumeric function in numericIf

Changed 4 years ago by ahocevar

Changed 4 years ago by tschaub

  • state changed from Review to Commit

Patch looks good. Tests pass. Please commit.

Changed 4 years ago by ahocevar

  • status changed from new to closed
  • state changed from Commit to Complete
  • resolution set to fixed

(In [8927]) Cast values containing numbers into Number objects in Filter and SLD format to ensure correct comparison of scale denominators against map scale and filters against features. Introduces a new OpenLayers.String.numericIf function. r=fredj,tschaub (closes #1874)

Note: See TracTickets for help on using tickets.