groldan++

You are correct the implementation of Length needs to be fixed exactly 
as you outlined.

There are two more missing parts to Filter:
- we need to have a plugin system behind our spatial functions (so they 
can use ISO Geometry as well as JTS)
- Function.getNumberOfArguments() is not present in GeoAPI, the idea is 
split between the Function "data structure" (ie Function) and the the 
function description (FilterCapabilities), really what we need is to do 
the same plugin trick here for functions that we did for property access 
and spatial filters - I had an email on the topic but have not made a 
proposal.

If you would like to start a proposal page on any of these issues I can 
try contributing later in the week.
Jody

Gabriel Roldán wrote:
> Hi all,
>
> if you remember, I've talked about using a custom FilterFactory and thus 
> Filter* implementation for dealing with ISO Feature.
>
> It turned out to not be necessary, as the Filter implementation is 
> "pluggable" 
> enough (i.e. using PropertyAccessors and Converters should just make the 
> trick).
>
> The problem I've faced early was Filter evaluation (such as Equals, etc) did 
> not know how to extract the value of an org.opengis.feature.Attribute to 
> compare against, for example, a Literal.
>
> Once again the latest filter design seems to be thought well enough as to 
> handle this. the problem is two fold, Filter and Expression evaluation.
>
> Filter evaluation is mostly handled by delegating to 
> FilterAbstract.eval(Expression, Object), for which the only needed change is 
> to check if  object is an Attribute, and in that case to return the Attribute 
> content:
>
> protected Object eval(org.opengis.filter.expression.Expression expression, 
> Object object) {
>               if( expression == null ) return null;
>               Object value = expression.evaluate( object );
>         if(value instanceof org.opengis.feature.Attribute){
>             value = ((org.opengis.feature.Attribute)value).get();
>         }
>         return value;
>       }
>
> This handles, for example the equality check (IsEqualToImpl) with no change:
>  final Object value1 = eval(expression1, feature);
>  final Object value2 = eval(expression2, feature);
>
> Also note this does not adds a dependency over any unsupported module, since 
> the dependency over geoapi is already there, and we're only checking for a 
> geapi interface.
>  ....
>
> By the other hand, Expression's evaluate methods make use of Converters to 
> get 
> a value adjusted to its expected type.
>
> In this case no code change is (should be) needed, but adding an 
> AttributeConverterFactory handles it.
>
> I say "should be" because, even if the framework is well thought, not all 
> classes are adapted to work with it.
>
> Take for example LenghtFunction, it does:
> public Object evaluate(Object feature) {
>   Expression ae = (Expression)getParameters().get(0);
>    return new Integer(ae.evaluate(feature).toString().length());
> }
>
> where the following options handles it far better:
>
> public Object evaluate(Object feature) {
>       Expression ae = (Expression)getParameters().get(0);
>       String value = (String) ae.evaluate(feature, String.class);
>       return new Integer(value == null? 0 : value.length());
> }
>
> This way, we explicitly tell the attribute expression to evaluate to a 
> String, 
> so no need to guess or customly handle a different object type.
>
> With this few changes, we would be a big step forward in actually making 
> Filter to easily work with whatever object model we want.
>
> Note the build keeps completely sane after doing this change, so it would be 
> nice to directly incorporate them to the code base instead of having to fork 
> something.
>
> opinions?
>
> Cheers,
>
> Gabriel
>
>
>
>   


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to