I managed to add a simple function "add", which returns the sum of both
its Double arguments. The add function follows the GeoTools Function
tutorial: it directly implements the Function interface and gets created
by my own FunctionFactory, which is registered via
META-INF/services/org.geotools.filter.FunctionFactory.
However, only the Java implementation is actually used.
GeoTools/GeoServer makes no attempt to encode the "add" function in SQL
when using a PostgreSQL store. What am I missing?
Another question: most of the built-in functions do not implement the
Function interface directly but extend FunctionExpressionImpl (which
implements FunctionExpression). According to the docs, these functions
must be registered via
META-INF/services/org.geotools.api.filter.Function. So, I added a "sub"
function, returning a - b, which is based on the FunctionExpression
approach (which seems to be quite a bit more comfortable and newer).
Unfortunately, GeoServer/GeoTools seems not to know the new "sub"
function and throws an error when I try to use that function through a
WFS GetFeature request.
BTW, interface FunctionExpression states:
[...]
* All implements should be registered for service provider interface
*
* <pre>
* org.geotools.api.filter.Function</code>
* DefaultFunctionFactor.
*
* <p>
* If you have a large number of related functions consider the use of
{@link FunctionFactory}.
[...]
The lines around <pre> and </code> seem to be mixed up and may be not
correct (looks like a merge error). Actually most other built-in
functions are registered in a file
META-INF/services/org.geotools.api.filter.expression.Function
(e.g. org.geotools.data.postgis.filter.FilterFunction_pgNearest).
However, changing the registration of my "sub" function does not help:
GeoServer still cannot find that function.
Cheers
Carsten
Am 26.09.2023 um 09:43 schrieb Andrea Aime:
Sort of on track. First class functions have both a java
implementation and a way to be delegated to
the database.
There are however a few functions that have no equivalent and can be
run only against a particular database,
like pgNearest:
https://github.com/geotools/geotools/blob/main/modules/plugin/jdbc/jdbc-postgis/src/main/java/org/geotools/data/postgis/filter/FilterFunction_pgNearest.java
These functions still have to be recognized as part of the filter
capabilities and have custom encoding code:
https://github.com/geotools/geotools/blob/main/modules/plugin/jdbc/jdbc-postgis/src/main/java/org/geotools/data/postgis/FilterToSqlHelper.java#L196
The downside of these is that they make for a broken system, the
moment there is more than one backend data source,
or just by the fact of being there.
E.g., pgNearest is always there as postgresql store is always
included, but installations might be using Oracle, sql server,
shapefiles, all sources where attempting usage of such function will fail.
So it's not clean, but also normally not a big deal because the
description of functions in WFS capabilities is so poor that clients
cannot automatically
use them anyways, clients using functions are usually written by hand
anyways.
Cheers
Andrea
On Tue, Sep 26, 2023 at 9:01 AM Carsten Klein <c.kl...@datagis.com> wrote:
Hi Jody,
thanks for your response :)
Since I will likely not be able to modify/extend FilterToSqlHelper
from a GeoTools Filter Function Plugin, it will be best to focus
on PostgreSQL functions that can be encoded as
functionName(p1, p2, ... pN)
In that case, PostgisFilterToSQL will translate my Java
implemented custom functions to SQL without any further action
required? (Given that "encode functions" is enabled.)
I guess, the actual Java implementation is not required to
return/evaluate any meaningful results based on the arguments,
right? (I won't be able to re-implement e.g. Full Text Search in
Java, of course)
Still on track?
Regards,
Carsten
Am 26.09.2023 um 08:31 schrieb Jody Garnett:
You are running alongside the right track :)
To work you implement in java (for any non PostGIS data) and then
adjust the PostGIS DataStore code to map those functions to SQL.
* PostGISDialect
* PostgisFIlterToSQL
* FilterToSqlHelper
* FilterToSqlHelper.visitFunction(function,extraData)
<https://github.com/geotools/geotools/blob/main/modules/plugin/jdbc/jdbc-postgis/src/main/java/org/geotools/data/postgis/FilterToSqlHelper.java#L522>
You can see the mapping being done from the GeoTools function
data structure (which is why you need a java implementation) to
the SQL.
--
Jody Garnett
On Sep 25, 2023 at 11:23:00 PM, Carsten Klein
<c.kl...@datagis.com> wrote:
Hi there,
I'd like to use some custom PostgreSQL functions as filters in
standard
WFS 2.0.0 requests. The goal is to request features filtered by
e.g.
Full Text Search or the word_similarity function provided by the
pg_trgm
extension (Trigram/Trigraph support).
Since WFS only provides a quite limited set of operators
(PropertyIs[Not]EqualTo, PropertyIsLessThan, PropertyIsLike,
etc.), my
idea is to use my own filter functions in order to access those
custom
database functions.
In GeoTools, there is a Function tutorial explaining how to
create my
own Function Factory and function implementations. However, all
samples
and functions I've seen so far are implemented in Java. Is it
possible
for these Filter Functions to contribute to the WHERE clause of the
actual SQL statement executed in the database?
For a GeoServer (Data)Store, there is an option "encode functions",
causing all/most filters to be implemented in SQL for performance
reasons. Does this affect Filter Functions from those Filter
Factories
as well?
Looking at the Function's interfaces (Expression,
ExpressionVisitor,
Function), I don't see any point at which SQL could come into
play. Am I
on the right track?
Any advice is appreciated :)
Carsten
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Regards,
Andrea Aime
==GeoServer Professional Services from the experts!
Visit http://bit.ly/gs-services-us <http://bit.ly/gs-services-us>for
more information.==Ing. Andrea Aime @geowolfTechnical Lead
GeoSolutions Groupphone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
https://www.geosolutionsgroup.com/ <https://www.geosolutionsgroup.com/>
http://twitter.com/geosolutions_it <http://twitter.com/geosolutions_it>
-------------------------------------------------------
Con riferimento alla normativa sul trattamento dei dati personali
(Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati
“GDPR”), si precisa che ogni circostanza inerente alla presente email
(il suo contenuto, gli eventuali allegati, etc.) è un dato la cui
conoscenza è riservata al/i solo/i destinatario/i indicati dallo
scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a
cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato
se potesse darmene notizia.This email is intended only for the person
or entity to which it is addressed and may contain information that is
privileged, confidential or otherwise protected from disclosure. We
remind that - as provided by European Regulation 2016/679 “GDPR” -
copying, dissemination or use of this e-mail or the information herein
by anyone other than the intended recipient is prohibited. If you have
received this email by mistake, please notify us immediately by
telephone or e-mail
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
