From: <jue...@fr...> - 2005-10-28 07:04:09
|
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 jue...@fr...: > > > >> 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 >> > |