Our intention is to develop a web application that investigates and
expands (if necessary) an OGC filter attached to a request.
We assume to use the following filter:
<Filter xmlns:gml="http://www.opengis.net/gml";>
<PropertyIsEqualTo>
<PropertyName>myValue</PropertyName>
<Literal>10</Literal>
</PropertyIsEqualTo>
</Filter>
To me, the obvious way to do so is to create a SAX-parser and add
an appropriate document filter (the usual FilterHandler decorated with
GMLFilterGeometry and GMLFilterDocument).
After a call to the ParserAdapter's parse()-method we retrieve a Filter object
that represents the request's OGC filter.
Up to now, everything works fine - my only question at this point: is this the
way it's meant to be?
In our project (and we're not alone :) we are facing the following filters:
<Filter xmlns:gml="http://www.opengis.net/gml";>
<PropertyIsEqualTo>
<PropertyName>myValue</PropertyName>
<Literal>0123456789123456</Literal>
</PropertyIsEqualTo>
</Filter>
That is, we filter on a textual property (a CHAR field) that contains only
numeric values.
When parsing this document, the Parser throws an exception:
java.lang.NumberFormatException: For input string: "0123456789123456"
at
java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
at java.lang.Integer.parseInt(Integer.java:480)
at java.lang.Integer.parseInt(Integer.java:518)
[...]
The obvious reason is that the parser (or the scanner, resp.) interprets the
literal token
according to his rules (as specified in expr.jjt) as an int.
I believe this a design flaw of the ExpressionParser: the filter document
contains Literal values
that are free from any format. Their format is defined not by there value, but
by the owning Property (feature type).
To my understanding it's basically impossible for a parser to judge about a
Literal's type!
Wouldn't it be correct to just parse Literals into Strings? In that way, their
value wouldn't be touched.
The type cast according to the Literal's feature type should be done in a
further step.
I would like to discuss this point - we would also like to contribute to its
solution.
By the way, the mentioned behaviour is also origin of Bug GEOT-717.
Cheers,
Jürgen
"Jetzt Handykosten senken mit klarmobil - 18 Ct./Min.! Hier klicken"
www.klarmobil.de/index.html?pid=73025
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
