On GeoTools 2.4 onward we have changed how literals (and indeed expressions) are handled; for details please see the 2.4.x page under expression improvements (or something).
The long and short of it is that you can now evaulate with a specific target in mind: expr.evaulate( feature, String.class ); // will return a String even when faced with 1+1 expr.evaulate( feature, Integer.class ); expr.evaulate( feature, Color.class ); // will return a Color even for "#ff0000" So as often as possible you should not have to care what the internal literal value is (ie String, Integer, Double, Date) - only what you want it to be. With this in mind you do not have to inform GeoTools about the type of the attributes. Jody MVermeij wrote: > 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 >> >> >> > > ------------------------------------------------------------------------- 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
