On Wed, Oct 3, 2012 at 5:44 AM, Jody Garnett <[email protected]> wrote:
> Quick comments on: nearest( attributeName, maxFeatures, filter )
> - attributeName: can this be any geometry expression or is it limited to
> attribute name
>
Only an attribute name, not every expression
> - filter: you mention this as CQL but I expect an actual filter can be
> passed in
>
>
Nope, I really meant a CQL formatted string, a Filter cannot be passed
because
it's not an Expression, and all filter function params are to be Expression
objects instead.
(at least this is my understanding).
> For the "vendor specific hint":
> - would rather have both parameters their, and marked as optional (i.e.
> may be supported by the implementation)
>
> Supporting both modes of operation seems to be throwing this design a
> curve ball.
>
>
What we do when we hit the next system that requires more extra params?
A single open ended optional param gives us extensibility without having to
count
the nulls: say we add a new param for a third system, the first two would
have to
be null and the third valid, then a fourth one comes in and we have to
leave three
nulls before adding the fourth param and so on, it's messy.
This trouble is caused by function params being positional instead of being
named.
> Some random ideas on that (but nothing good):
> - bad idea - two pass: could be used is as an aggregate function, stage
> your feature collection using the "category > 3" and then treat "nearest
> neighbour" as an aggregate function like unique or union.
>
This would prevent it to be used as a filter, e.g., could not be used to
return features in a GetMap/GetFeature request
> - high level optimisation: Make use of Query sortBy with a distance
> expression, filter by category 3, and set max features to 10. Recognise the
> whole mess as an attempt to call SQL_NN and implement it as such.
>
>
It seems to me a filter function is cleaner than both of the above
approaches, requires less effort to
be implemented, and provides the same amount of functionality.
Cheers
Andrea
--
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
