jody.garnett wrote
>> 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.
> The downside to an optional parameter is that we cannot describe the
> contents very wellprogramatically. Still if that will help, is there any
> chance we can make it a String so at least a user interface can prompt the
> user for something.
Hi, I represent the City of Vienna, who is funding this development. I am no
GeoTools developer myself and I see this more from the point of view of the
developer of a client using GeoServer to query data. But I would like to
suggest the following:
Why not use a datastore specific function name instead of a generic one, as
the use of datastore specific parameters will in fact make it non-generic
anyway. In example instead of /nearest/ you could use /SDO_NN/, as Andrea
has already suggested to me, or /nearest_sdo/ and have only one optional
datastore specific parameter with a descriptive name and integer data type
like /batchSize/.
This would make the function mostly self documenting and should result in
easier maintainable code too.
In GeoServer it would be necessary to make sure anyway, that only one single
data store is used for all feature types and only present the function for
this data store in the filter capabilities, as the GeoServer user has no way
to know, which feature type uses which data store. So having optional
parameters for PostGIS *and* SDO in the function, this would lead to errors,
if the caller uses batch size with a feature type stored in a Postgres
database (or the other way around). At least in WFS 2.0 not only the
function name, but also the arguments are described in the filter
capabilities and a descriptive interface with only the relevant parameters
would help the user.
--
View this message in context:
http://osgeo-org.1560.n6.nabble.com/Adding-a-K-nearest-neighbours-filter-fuction-for-Oracle-tp5005857p5007163.html
Sent from the geotools-devel mailing list archive at Nabble.com.
------------------------------------------------------------------------------
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
