OK that makes more sense.  Thanks for the reply.  So it sounds like my
understanding of the theory was ok, but my implementation was bad.  I guess
it's time to look at a little code.  For the function that I'm working on, I
send in the following ogc:Filter xml in my query request via WFS:

                                <ogc:PropertyIsEqualTo matchCase="true">
                                        <ogc:Function name="TrajectoryQuery">
                                                
<ogc:Literal>-111.97777222222223,40.78838888888889
                                                        
-75.24086666666666,39.87225</ogc:Literal>
                                                
<ogc:Literal>25000.0</ogc:Literal>
                                                
<ogc:Literal>1343857109000</ogc:Literal>
                                                <ogc:Literal>300.0</ogc:Literal>
                                        </ogc:Function>
                                        <ogc:Literal>true</ogc:Literal>
                                </ogc:PropertyIsEqualTo>

I recognize that the first argument should probably be a geometry type
instead of a literal, but I'm taking it one step at a time and figured this
would be easier to start with.  So the idea is that the function would use
these parameters to perform some calculations on the records from the data
store to decide whether or not they meet some criteria that must be met in
order to be rendered on the WFS client.

Here is how I set up those parameters in my FunctionImpl subclass:

                public static final FunctionName NAME = new FunctionNameImpl(
                    "TrajectoryQuery", Boolean.class,
                    parameter("geometry", String.class),
                    parameter("width", Double.class),
                    parameter("queryTime", Long.class),
                    parameter("speed", Double.class)
                );      

For our current purposes, the evaluate method could be as simple as this:

            public Object evaluate(Object feature) {
                System.out.println("FEATURE=" + feature);
                return (feature != null);
            }

It is worth noting however that if I add lines to do things like this:

            double width =
super.getParameters().get(1).evaluate(feature,Double.class);

... then all the proper values are there.  So it does receive the parameters
that I pass in.

So in other words, my code does meet the criteria that you mention would be
problematic (all literals).  So it sounds like there may be a couple ways to
address this:

1 - Perhaps making the first arg an actual geometry is better, but not sure
how that would be associated with a property on the data store feature
(though it does have a geom field).  

2 - Perhaps I can directly reference other properties of the feature in the
args... I'll do some more review of the docs.

I'll research these items while awaiting more feedback, but if you have any
other tips that might help me get just that feature != null check working
then I'd be very grateful.

Thanks.







--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Re-Geotools-devel-Custom-Filter-Function-Getting-Started-Question-tp5065918p5066045.html
Sent from the geotools-gt2-users mailing list archive at Nabble.com.

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
GeoTools-GT2-Users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users

Reply via email to