WFS version 2.0.0 requests with Filter String Property Literals starting with leading zero returns not working


Executing WFS requests (version 2.0.0), using Filter String Property Literals starting with leading zero results in an empty response even if the searched fetures are in the postgis database.
Sample request:

Corrsponding Geoserver log:

It's clear that the requested literal string 061051 has been transformed to 61051 in the geotools filter.




Jukka Rahkonen
May 11, 2016, 1:57 PM

I guessed so but it is essential to know, thank you.

Robert Coup
July 22, 2016, 11:23 AM

Against master today (pre-1.10; 43d4aba9e8)

  • Reproducible under WFS 2.0

  • Not reproducible with WFS 1.0 or 1.1

Robert Coup
July 22, 2016, 2:03 PM

Culprit is – the parser in this context has zero information on what it's comparing to so tries to cast number-like things to be numbers. Later when the comparison hits the datastore it's cast back to a string parameter (eg. WHERE foo='7')

That actually seems like sane behaviour in general. But according to the OGC filter specs...

Literals can, optionally, be typed using the type attribute. The value of the attribute type is the name of type from some type system.

EXAMPLE The following XML fragment: <Literal type="xs:date">1963-10-13</Literal> encodes a date value. The type of the value is xs:date as defined in (see W3C XML Schema Part 2).


So potentially supporting <Literal type="xsd:string">01234</Literal> could allow the parser to set FilterFilter.convertLiteralToNumber=False. Doing that in the debugger produces the correct result to the request.

Looks like one approach for that could be to expand LiteralExpressionImpl to support the type= attribute, and also use that for comparisons (<Literal>123</Literal> != <Literal type="xs:string">123</Literal> – see LiteralExpressionImpl.equals() for current state). Then when loading the expression value if type is set to string then avoid the numeric conversion.

Andrea Aime
October 28, 2016, 3:45 PM

As far as I know, the ExpressionSaxParser should not be doing that, the filter encoders in the stores have the context to decide if stuff is to be encoded one way or the other, the parser does not.

Andrea Aime
October 28, 2016, 3:49 PM

Oh, one more observation, while GeoServer allow to use ogc:Filter along with WFS 2.0 for leniency, a valid request should be using fes:Filter (Filter 2.0)




Hervé Minko


Fix versions


Affects versions