hello all, On Thursday 13 September 2007 07:48:05 Jody Garnett wrote: > ... > Here are the three cases: > - aggregate functions do not work (and have not since 2.3) - this > prevents uDig trunk from having a style editor, and prevents the SLD > generator from being happy > - "problem with adding features" email thread on geotools-users - > basically FeatureID is not stable, to fix this Jesse makes his own > FidFilter and updates the internal Set<String> after the commit. This > FidFilter is just a GeoAPI filter so a lot of the geotools datastores > die on it > - casting Filter.INCLUDES and Filter.EXCLUDES as per Andrea's > original email > > Does anyone have anything else for this list? Chances are this stuff > will trip us up in the code sprint.
i'm not sure if what i'm about to describe falls under the same heading as Jody's email re. the filter fixes, and my apologies in advance for the noise if it isn't, but there seems to be a problem with filter processing when an attribute, although defined as string, its values look like numbers; e.g. US zip codes such as "02760" and "356HH". basically what happens is that at some stage the GeoTools code (FilterFilter.processCharacters() --> ExpressionSAXParser.message()) attempts to convert the string value into an Integer, Double, or leave it as String depending on whether it succeeds in parsing the string or a NumberFormatException is intercepted in the process (version 2.3.4 and i believe 2.4M0 as well of the GeoTools libraries). recently (Jody i think) a new boolean flag was added to the FilterFilter, on the trunk, to disable the above behavior and hence forces all values to be left as strings (parameter convertLiteralToNumber in a FilterFilter ctor). yet: a. this constructor does not look like it's being called, and b. if it is (or will be) i still don't see how ignoring the feature's attribute type when converting a string representation of supposedly one of its values is a real solution. cheers; rsn
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
