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
