Hi Andrea, the converter function is a really good idea, and just what I was thinking about when reading over the problem. One thing though, is that the way it is exposed seems like too java centric, perhaps it would be nice to create a function per primitive type (say, asInt(), asDouble(), etc), and avoid the java class names as argument? It is just because having a function tied to the underlying programming language in the interoperability protocol seems a bit odd.
Another thing I was thinking about is if there wasn't actually a way for the incomming, typeless, Feature attributes to be typed, like in using a well known xml/gml type. This way the type for the comparison could be inferred from the attribute and no extra function would be needed. If possible, still both possibilities would be of value, given the correct type shall be inferred from at least one of the compared arguments. But I didn't found much besides gml:Quantity, which is in the substitution group of gml:_ScalarValue, but requires a uom attribute. And yes, I know you're thinking that'd be a steeper learning curve for the non gml geek (aka, the normal user). So I'd say the converting function(s) is a very good way to go, just wanted to raise this little concern about the java centric parametrization instead of a more neutral one. Cheers, Gabriel Andrea Aime wrote: > Hi all, > in GeoServer land we have a little problem that could > be solved by a casting/converting function, and > trying to check if this is ok with other people as well. > > Basically we have user layers expressed in SLD, where > a GML feature collection, completely typeless in terms > of attributes (since there is no schema reference), > is being rendered using filters that have to do > numeric comparisons. > > However, the feature attribute themselves are assumed > to be strings, given there is no type information for > them, and the sld literals are parsed as strings as well. > Filter wise, this ends up being a string to string > comparison, which has a different meaning than the > desired numeric one. > (if you want more details, here is the issue: > http://jira.codehaus.org/browse/GEOS-2053) > > Now, the compare filter code could try an implicit > promotion in theory, and see if both sides can > be turned into numbers. But that would be a good > idea, we have already been beaten a number of > times by things that look numbers but are in > fact strings, like codes with leading zeroes. > Generally speaking trusting the feature type > values to be in the right type already is a good > idea. > > So, for case I cited at the beginning, I believe > exposing the converters as a filter function could > be a good idea: > > <Function name="convert"> > <Literal>15.0</Literal> > <Literal>java.lang.Double</Literal> > </Function> > > where the second literal identifies the target class. > The easiest way would be just just do the above, > and do a Class.forName for the target class. > With a little extra effort we can support primitives > as well, and assume that classes without name > are sitting in java.lang. > This name -> Class conversion seems to demand, guess what... > a converter ;-) > > Opinions? > Cheers > Andrea > > ------------------------------------------------------------------------------ > Stay on top of everything new and different, both inside and > around Java (TM) technology - register by April 22, and save > $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. > 300 plus technical and hands-on sessions. Register today. > Use priority code J9JMT32. http://p.sf.net/sfu/p > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Gabriel Roldan OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
