GeoTools

Use of FilterCapabilities

Details

  • Type: Improvement Improvement
  • Status: Open Open
  • Priority: Critical Critical
  • Resolution: Unresolved
  • Affects Version/s: 2.5-M0
  • Fix Version/s: 2.7.6
  • Component/s: main
  • Labels:
    None

Description

The goal here is to have a Capabilities wrapper around a opengis FilterCapabilities data structure that we can use as method compatible replacement for the old FilterCapabilities class:

Capabilities capabilities = new Capabilities( filterCapabilities );
capabilities.addType( Beyond.class ); // add to SpatialCapabilities
capabilities.addType( PropertyIsEqualTo.class ); // add to ScalarCapabilities
capabilities.addName( "NullCheck" ); // will enable PropertyIsNull use
capabilities.addName( "MUL" ); // will enable hasSimpleArithmatic
capabilities.addName( "random" ); // a function returning a random number
capabilities.addName( "Length", 1 ); // single argument function
capabilities.addName( "toDegrees", "radians" ); // single argument function
capabilities.addName( "length", "expression" );

if( capabilities.fullySupports( filter ) ){
    // encode as SQL
}

Capabilities capabilities2 = new Capabilities();

capabilities2.addAll( capabilities );
capabilities2.addAll( Capabilities.LOGICAL ); // Capabilities.LOGICAL is a FilterCapabilities

The proposal page is here:

Issue Links

depends upon

Task - A task that needs to be done. GEOT-2199 Provide a replacement of PostPreProcessFilterSplittingVisitor that works on the non deprecated org.geotools.filter.Capabilities instead of the old geotools FilterCapabilities

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
is depended upon by

Bug - A problem which impairs or prevents the functions of the product. GEOT-1633 FilterToSQLSDE broken on FilterCapabilities class cast exception

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
supercedes

Bug - A problem which impairs or prevents the functions of the product. GEOT-1633 FilterToSQLSDE broken on FilterCapabilities class cast exception

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Jody Garnett added a comment -
This work is now committed on trunk, and will await public review before being closed.
Show
Jody Garnett added a comment - This work is now committed on trunk, and will await public review before being closed.
Hide
Permalink
Gabriel Roldan added a comment -
Hi Jody, I guess the missing bit for a wider adoption of org.opengis.filter.FitlerCapabilities is the port of PostPreProcessFilterSplittingVisitor, which I've done for WFS 1.1.
Yet, porting the test suite for it leads to failures since both IsFullySupportedFilterVisitor and IsSupportedFilterVisitor implement the following:

public Object visit( Function function, Object extraData ) {
        ScalarCapabilities scalar = capabilities.getScalarCapabilities();
        if( scalar == null ) return false;
        
        ArithmeticOperators operators = scalar.getArithmeticOperators();
        if( operators == null ) return false;
        
        Functions functions = operators.getFunctions();
        if( functions == null ) return false;
        
        // Note that only function name is checked here
        FunctionName found = functions.getFunctionName( function.getName() );
        if( found == null ) return false;
        
        return found.getArgumentCount() == function.getParameters().size();
}

Note that the last method's line compares the number of arguments in the function instance and the FunctionName declared argument count. I know arg count is a hot topic and not sure if we already solved it. Yet, I keep on thinking this last check is unnecessary and we should be ok with just matching the function name, since as per the spec and our implementation too there can't exist two functions with the same name and different number of arguments.

And since when adding support for a function to an org.geotools.filter.Capabilities FitlerCapabilities wrapper I cannot know the number of arguments beforehand.. what about eliminating that last check and returning true if the function names match?


Show
Gabriel Roldan added a comment - Hi Jody, I guess the missing bit for a wider adoption of org.opengis.filter.FitlerCapabilities is the port of PostPreProcessFilterSplittingVisitor, which I've done for WFS 1.1. Yet, porting the test suite for it leads to failures since both IsFullySupportedFilterVisitor and IsSupportedFilterVisitor implement the following: public Object visit( Function function, Object extraData ) {         ScalarCapabilities scalar = capabilities.getScalarCapabilities();         if( scalar == null ) return false;                  ArithmeticOperators operators = scalar.getArithmeticOperators();         if( operators == null ) return false;                  Functions functions = operators.getFunctions();         if( functions == null ) return false;                  // Note that only function name is checked here         FunctionName found = functions.getFunctionName( function.getName() );         if( found == null ) return false;                  return found.getArgumentCount() == function.getParameters().size(); } Note that the last method's line compares the number of arguments in the function instance and the FunctionName declared argument count. I know arg count is a hot topic and not sure if we already solved it. Yet, I keep on thinking this last check is unnecessary and we should be ok with just matching the function name, since as per the spec and our implementation too there can't exist two functions with the same name and different number of arguments. And since when adding support for a function to an org.geotools.filter.Capabilities FitlerCapabilities wrapper I cannot know the number of arguments beforehand.. what about eliminating that last check and returning true if the function names match?

People

  • Assignee:
    Unassigned
    Reporter:
    Jody Garnett
Vote (1)
Watch (2)

Dates

  • Created:
    Updated: