Since I'm experiencing the same problem, I would like to know whether this problem is actually solved in the current geotools version (I am using version gt2-2.3.3).
If it is actually solved, how do I inform geotools about the type of the attributes? Regards, Maarten Vermeij Gabriel Roldán wrote: > > Hi Duncan > > yes, that's an old and well known problem. > The good news is that we have a couple ideas and are waiting for 2.3.0 to > get > out before implementing it (http://jira.codehaus.org/browse/GEOT-602) > > So please keep in sync since we're going to fix it asap, and do not > hesitate > to talk back if you have any suggestion. > > > regards, > > Gabriel > On Thursday 14 September 2006 13:25, Duncan Clarkson wrote: >> Hi, >> >> We're having a problem with the way that geotools 2.1.1+ deals with >> parsing literal values in OGC filters. We are providing data to users >> via Geoserver 1.3.0 which uses the 2.1.1 version of Geotools. >> >> Some of the datasets we offer have a string column called 'label' >> although the value of this field can be numeric and can contain leading >> zeros. We need to generate EqualTo and Like filters based on these >> fields but the problem is that they are being treated as integers by >> geotools. Here is the code that handles this >> (org.geotools.filter.ExpressionSAXParser): >> >> } else if (curExprssn instanceof LiteralExpression) { >> // This is a relatively loose assignment routine, which >> uses // the fact that the three allowed literal types have a strict >> // instatiation hierarchy (ie. double can be an int can >> be a >> // string, but not the other way around). >> // A better routine would consider the use of this >> expression >> // (ie. will it be compared to a double or searched with >> a >> // like filter?) >> //HACK: This should also not use exception catching, it's >> //expensive and bad code practice. >> try { >> Object temp = new Integer(message); >> ((LiteralExpression) curExprssn).setLiteral(temp); >> currentState = "complete"; >> } catch (NumberFormatException nfe1) { >> try { >> Object temp = new Double(message); >> ((LiteralExpression) >> curExprssn).setLiteral(temp); >> currentState = "complete"; >> } catch (NumberFormatException nfe2) { >> Object temp = message; >> ((LiteralExpression) >> curExprssn).setLiteral(temp); >> currentState = "complete"; >> } >> } >> } >> >> So if the literal can be converted to a number it will be, leading zeros >> will be lost. This of course means that the SQL generated by Geoserver >> to extract the features will return no data as '007' != 7. >> >> We were thinking that a better way to handle this would be not to try >> and convert a literal unless it is required by a calculation. Any ideas >> or plans for what to do about this? >> >> Duncan >> >> PS. For completeness sake here is the output I have from Geoserver: >> >> 176638862 [FINER] org.geotools.filter.ExpressionSAXParser - incoming >> type: Literal >> 176638862 [FINER] org.geotools.filter.ExpressionSAXParser - declared >> type: PropertyName >> 176638862 [FINER] org.geotools.filter.ExpressionSAXParser - current >> state: complete >> 176638863 [FINER] org.geotools.filter.ExpressionSAXParser - is literal >> expression >> 176638863 [FINER] GMLFilterDocument - RETURN >> 176638864 [FINER] GMLFilterDocument - ENTRY [EMAIL PROTECTED] 77 3 >> 176638864 [FINER] org.geotools.filter.ExpressionSAXParser - incoming >> message: 007 >> 176638864 [FINER] org.geotools.filter.ExpressionSAXParser - should read >> chars: true >> 176638865 [FINER] GMLFilterDocument - RETURN >> 176638865 [FINER] GMLFilterDocument - ENTRY http://www.opengis.net/ogc >> Literal ogc:Literal >> 176638865 [FINER] org.geotools.filter.FilterFilter - found start >> element: Literal >> 176638865 [FINER] AbstractFilter - ENTRY 109 >> 176638865 [FINER] org.geotools.filter.FilterFilter - found an expression >> filter end >> 176638866 [FINER] org.geotools.filter.ExpressionSAXParser - declared >> type: Literal >> 176638866 [FINER] org.geotools.filter.ExpressionSAXParser - end message: >> Literal >> 176638867 [FINER] org.geotools.filter.ExpressionSAXParser - current >> state: complete >> 176638867 [FINER] org.geotools.filter.FilterFilter - expression factory >> is ready >> 176638868 [FINER] org.geotools.filter.ExpressionSAXParser - about to >> create expression: 7 >> 176638868 [FINER] org.geotools.filter.FilterSAXParser - current state >> (end): complete >> 176638869 [FINER] GMLFilterDocument - RETURN >> 176638869 [FINER] GMLFilterDocument - ENTRY http://www.opengis.net/ogc >> PropertyIsEqualTo ogc:PropertyIsEqualTo >> 176638869 [FINER] org.geotools.filter.FilterFilter - found start >> element: PropertyIsEqualTo >> 176638869 [FINER] AbstractFilter - ENTRY 14 >> 176638870 [FINER] org.geotools.filter.FilterSAXParser - complete called, >> state = complete >> 176638870 [FINER] org.geotools.filter.LogicSAXParser - added a filter: [ >> label = 7 ] >> 176638870 [FINER] org.geotools.filter.LogicSAXParser - added to sub >> filters: [ label = 7 ] >> >> ------------------------------------------------------------------------- >> Using Tomcat but need to do more? Need to support web services, security? >> Get stuff done quickly with pre-integrated technology to make your job >> easier Download IBM WebSphere Application Server v.1.0.1 based on Apache >> Geronimo >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >> _______________________________________________ >> Geotools-gt2-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users > > -- > Gabriel Roldán ([EMAIL PROTECTED]) > Axios Engineering (http://www.axios.es) > Tel. +34 944 41 63 84 > Fax. +34 944 41 64 90 > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Geotools-gt2-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users > > -- View this message in context: http://www.nabble.com/OGC-Filter---Literal-Handling-tf2271004.html#a13404449 Sent from the geotools-gt2-users mailing list archive at Nabble.com. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Geotools-gt2-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
