Dear all,
Any idea, comments about this issue ?
Thanks
Erwan
Le 19/04/2021 à 12:31, Erwan Bocher a écrit :
Dear Andrea,
I look at the implementation of the filter functions in geotools to
wrap them to the SFSSQL definitions.
I have troubles with some implementations that seem weird to me. I
shared an issue here https://osgeo-org.atlassian.net/browse/GEOT-6873
What is the reference specification used by geotools?
I thought it was about "Implementation Standard for Geographic
information - Simple feature access - Part 1: Common architecture ",
but it seems there is a shift in term of semantic.
e.g Geotools internal filter has the getGeometryN name and OGC and ISO
use the GeometryN name.
On the other hand, there are some unusual things about the
implementations.
e.g internal area function returns -1 when the input geometry is null.
If I'm not wrong when this function is translated to db provider for
example PostGIS, it will return NULL.
Any comments are welcome
Thanks
Erwan
Le 16/04/2021 à 17:40, Andrea Aime a écrit :
Functions are global, they are part of the OGC Filter subsystem. They
are not specific to a store, they end
up in the capabilities document of a WFS, they can be used in SLD no
matter what the underlying store is.
A store can only have a specific (optimized) translation of them.
Cheers
Andrea
On Fri, Apr 16, 2021 at 5:37 PM Erwan Bocher
<erwan.boc...@univ-ubs.fr <mailto:erwan.boc...@univ-ubs.fr>> wrote:
Hi Andrea
Le 16/04/2021 à 17:05, Andrea Aime a écrit :
Hi Erwan,
databases are not the only source of data. A function must be
able to work in memory first, so that it works
with shapefiles, elasticsearch, mongo and so on as well. Then
there can be an optimization translating
them down to SQL.
There is a filter splitter slicing filters in two parts, one
that can be encoded down into the datasources,
and one that will run in memory as a post filter. If the
datastore filter capabilities declare support for the
function, it will be encoded and executed in the database, not
in memory, regardless of whether it has
code to be executed in memory.
Each datastore can decide to translate the bits of filters and
functions in a different way, based on what
can or cannot be translated down to native filtering.
Ok but to do that the function must be declared on the datastore
driver no ?
e.g if I extend Area to ST_Area, ST_AREA must be declared as
Area. I think for PostGIS about the public static
FilterCapabilities createFilterCapabilities(boolean
encodeFunctions) method ?
Did I miss something ?
Cheers
Erwan
Cheers
Andrea
On Fri, Apr 16, 2021 at 4:53 PM Erwan Bocher
<erwan.boc...@univ-ubs.fr <mailto:erwan.boc...@univ-ubs.fr>> wrote:
Hi Andrea,
I'm extending some filter functions to be compliant with
SFSSQL.
What about adding this feature in the main geotools module
and declare those new functions in the DB FilterToSQLHelper
classes ?
If we have an external module, these functions will not be
optimized in SQL.
Erwan
Le 29/12/2020 à 15:45, Andrea Aime a écrit :
On Wed, Dec 23, 2020 at 3:55 PM Erwan Bocher
<erwan.boc...@univ-ubs.fr
<mailto:erwan.boc...@univ-ubs.fr>> wrote:
This is my idea : add support to SFS names in CQL
(filter and expression) without breaking anything in
the parser ;-)
As long as they are handled "in memory" I have no
objection, just make sure the semantics is the same as the
current functions, if not, create a separate one.
What alarmed me was the possibility of blindly translating
it down to SQL. That should be done on a database by
database basis, checking what they
support, and under which semantics.
Different semantics between CQL and SQL is an annoying
source of issues. For example, CQL has two valued logic,
but SQL has three valued logic (null gets its own category).
There is a filter translator we created to make sure the
SQL generated behaves in a two-way, which caused several
people to complain about performance (the generated
queries do a number of null checks, and harder to read and
optimize)
Cheers
Andrea
== GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information. == Ing. Andrea
Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di
Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313
fax: +39 0584 1660272 mob: +39 339 8844549
http://www.geo-solutions.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./
--
Ingénieur de Recherche CNRS - HDR,
Laboratoire Lab-STICC – UMR 6285
Equipe DECIDE
Institut Universitaire de Technologie de Vannes
8, Rue Montaigne - BP 561 56017 Vannes Cedex
T: +33 2 97 62 64 92
W:https://cv.archives-ouvertes.fr/erwan-bocher
W:http://www.labsticc.fr
--
Regards, Andrea Aime
== GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information. == Ing. Andrea Aime
@geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito
3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584
1660272 mob: +39 339 8844549 http://www.geo-solutions.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./
--
Ingénieur de Recherche CNRS - HDR,
Laboratoire Lab-STICC – UMR 6285
Equipe DECIDE
Institut Universitaire de Technologie de Vannes
8, Rue Montaigne - BP 561 56017 Vannes Cedex
T: +33 2 97 62 64 92
W:https://cv.archives-ouvertes.fr/erwan-bocher
W:http://www.labsticc.fr
--
Regards, Andrea Aime
== GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information. == Ing. Andrea Aime
@geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A
55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272
mob: +39 339 8844549 http://www.geo-solutions.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./
--
Ingénieur de Recherche CNRS - HDR,
Laboratoire Lab-STICC – UMR 6285
Equipe DECIDE
Institut Universitaire de Technologie de Vannes
8, Rue Montaigne - BP 561 56017 Vannes Cedex
T: +33 2 97 62 64 92
W:https://cv.archives-ouvertes.fr/erwan-bocher
W:http://www.labsticc.fr
--
Ingénieur de Recherche CNRS - HDR,
Laboratoire Lab-STICC – UMR 6285
Equipe DECIDE
Institut Universitaire de Technologie de Vannes
8, Rue Montaigne - BP 561 56017 Vannes Cedex
T: +33 2 97 62 64 92
W: https://cv.archives-ouvertes.fr/erwan-bocher
W: http://www.labsticc.fr
_______________________________________________
GeoTools-GT2-Users mailing list
GeoTools-GT2-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
