Re: [Geotools-devel] Symbolizers pre-processor extensions for StreamingRenderer proposal

Thanks for writing that up, I will look when I get a moment. Naming is indeed hard; ProcessSymbolizersCallback may work? It is close to the name of the method, and it is a callback -- Jody Garnett On Fri, 15 May 2020 at 11:16, wrote: > Hi PMC and community. > > This proposal started on Geos

[Geotools-devel] Symbolizers pre-processor extensions for StreamingRenderer proposal

Hi PMC and community. This proposal started on Geoserver but now it was splitted into a Geotools proposal for having Symbolizers pre-processor extension point for StreamingRenderer class. I elaborated a Geotools proposal draft for you review and the technical discussion about. I wou

Re: [Geotools-devel] Is there a reason we do not have an ECQL null literal?

There is "Expression/NIL". But it is not a literal, it's a property :/ A pseudo-property I'd say. See org.geotools.filter.expression.NullPropertyAccessorFactory It definitely has uses, it's used in both app-schema and CSW mappings. A literal would be more appropriate. Regards Niels On 15/0

Re: [Geotools-devel] Is there a reason we do not have an ECQL null literal?

I wanted to test the handling of the mbstyle coalesce function (see pr ): filter:* ['coalesce', 'aString', null, 5]* And expected ECQL output similar to: filter:* coalesce('aString',NULL,5) = true* I was surprised to get a stack trace. -- Jody Gar

Re: [Geotools-devel] Is there a reason we do not have an ECQL null literal?

Hi Jody, null is not particularly useful in most expressions, as a consequence I'm not surprised there is not a NULL literal. However, just like in SQL, there is a "IS NULL" operator. From our examples : Filter filter = ECQL.toFilte