Chris,
thanks for your quick reply. I'm using a geotools version checked out
from svn on October 9th.
I will check in the next few days whether there are any fixes done
recently. Maybe Dave can give a hint?
Is there yet a timeline for the redesign? Any volunteers yet?
Though we can use some dirty workarounds avoiding our actual problem,
that flaw has a large impact on
other applications using geotools (espacially geoserver) where it's not
that easy to patch around.
Unfortunately I'm not an XML parser expert, so any help or hints from
the community would be appreciated!
Cheers,
Jürgen
Chris Holmes schrieb:
Quoting [EMAIL PROTECTED]:
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?
Yes, with that parser I'm pretty sure it's how it's supposed to work.
There have been a couple parsers in the pipeline, with a much better
design, that you may check out if you're doing advanced work with
filters. I'm short on time right now, but hopefully another developer
can fill you in. See
http://udig.refractions.net/confluence/display/OWS3/GTXML and
http://docs.codehaus.org/display/GEOTOOLS/Extending+The+XML+Parser?showComments=false
(I think they're different parsers, with similar designs but different
focuses)
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.
Yes, this is a known problem with the parser. Unfortunately it's a deep
problem with the design, instead of an easy fix. Like basically most
everything needs to be rewritten, but that actually may not be too hard
with the new parser stuff.
The problem with just making everything into strings is when geotools
does the parsing in java. If it passes the string to the backend it's
fine, since everything goes through strings anyways. But if the
geotools attribute is say a number, and it's trying to compare against
a string, it will fail. Though I feel like David did some work to
improve this, though I'm not sure if it fixed it entirely. Dave? I
think he made it so the parsing from a string to a number was done in
the java filtering code itself, and that solution may actually work for
you. What version of gt2 are you using? Though I'm not sure if it
ever got fully in...
The other option is to do schema aware parsing, which the new parsers
make possible. Instead of just making it a string, you know the type
expected, and can parse it well, instead of blindly trying to parse.
If you are doing serious parsing work with filters, it may well be worth
your while to investigate using one of the new parsers.
best regards,
Chris
By the way, the mentioned behaviour is also origin of Bug GEOT-717.
Cheers,
Jürgen
-------------------------------------------------------
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
