Re: [Geotools-gt2-users] Alias on filter function

[Erwan Bocher]

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 
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
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
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 

Re: [Geotools-gt2-users] Projection transformation from Arc 1960 / UTM zone 36S To WGS84

[Ian Turton]

On Mon, 26 Apr 2021 at 02:53, George Budeba  wrote:

> Hi Ian,
>
> Thank you very much for your reply.
>
> In fact, I went through that related documentation like this one
> .
> I understood how to achieve this with other several projections, but I am
> still not so much clear on how to go on with Arc 1960. I wonder If it is
> supported at all and if it is, I would very much appreciate a sample
> demonstration on how to achieve the reprojection from Arc 1960.
>
>
In which case it would have been helpful if you had said as much in your
initial question - so really your question is does GeoTools support your
projection? which probably boils down to is there an EPSG code for it - a
quick google gives https://epsg.io/21036 so your existing code with
EPSG:21036 will owrk fine.

Ian
___
GeoTools-GT2-Users mailing list
GeoTools-GT2-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users