OK, will place a proposal there. Give me some time. Maybe I'll take the
weekend to get it done...
Interestingly, I do not find these mails on the geotools-devel archive
at https://sourceforge.net/p/geotools/mailman/geotools-devel/
Would have used those under "References". Is there any other (mirror)
archive available?
Carsten
Am 07.12.2023 um 23:51 schrieb Jody Garnett:
Proposals are in the wiki here:
https://github.com/geotools/geotools/wiki/Proposals
Idea is to get buy in before putting a bunch of work into a change.
And collect alternatives is there is feedback.
Jody
On Thu, Dec 7, 2023 at 8:50 AM Carsten Klein <c.kl...@datagis.com> wrote:
Hi Jody,
yes, the change must be applied in GeoTools. Shall I write such a
proposal as a New Feature (or Wish) in Jira for the GeoTools
(GEOT) project?
--
Carsten Klein
Am 07.12.2023 um 17:38 schrieb Jody Garnett:
I think this needs a geotools proposal to gather the results of
this thread into a form for folks to review.
While I could review this thread in order to chime in, it would
really benefit from a proposal describing proposed API /
functionality change.
This is a geotools level change right?
--
Jody Garnett
On Dec 4, 2023 at 10:06:08 PM, Carsten Klein
<c.kl...@datagis.com> wrote:
Hi Andrea,
what's next with the SQL-encodable filter functions. You said
I'll let the other core developers chime in and help with a
decision.
Is there anything new? Do you expect me to issue a Jira CR? Or
even a
ready to use patch?
I'd much appreciate if someone of the core devs could make these
(simple) changes, since I have not yet any experiences to hack
GeoTools
(and test with GeoServer). Setting up all this is perhaps much more
effort than the patch itself (which a coder used to work with both
projects will likely have finished in some minutes).
Cheers
Carsten
Am 25.10.2023 um 00:52 schrieb Andrea Aime:
Yes, I remember NativeFilter, there was some discussion about
whether
to allow
that interface to exist at all, the final agreement was that,
yes, ok,
we can have it,
as long as it's a low level programmer oriented tool, which
cannot be
seen by end users.
And we also have a similar interface for functions called
InternalFunction, which has a similar
attitude, a function that is not meant to be seen outside of code
(cannot be parsed from CQL or Filter XML encoding for example)...
although this one has
no usage in SQL encoding.
Perhaps a NativeFunction base interface could be used, to indicate
that the function
is not meant to be included in capabilities documents (odd
usage, not
working cross store),
and per store sub-interfaces like PostgisNativeFunction could
be used
to indicate the
function can be written as is in PostGIS for example.
I still don't like it much in general, as its usage would be
limited
to vendor extensions, but
I'm not going to cast a -1 either, as I see the convenience of the
approach for custom
GeoServer extensions.
I'll let the other core developers chime in and help with a
decision.
Cheers
Andrea
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
