Nuno we are struggling a bit with what you propose because you are wishing to make up symbolizers on a feature by feature basis. My understanding is streaming renderer goes to a lot of work to review what is intended to be a static style in order to break the rendering task up into buffers, z-orders, sorting, queries, etc…
Yes. Most of that is done at the feature type level though (besides attribute selection, see below).
Adding new symbolizers on a feature by feature basis is not going to have an effect on that logic.
If the extension point allowed to modify feature types and rules, then yes, it would be harder (whether it would be too much, or not, that’s another story).
I am concerned that streaming renderer is very complicated and that by changing the symbolizers no the fly you will either upset performance (never a good idea) or make the code even harder to maintain (when you try and restore performance.
Neither seems to be true to me… most of the optimizations happen at the higher levels.
If the extension point is called at the beginning of processSymbolizers, we are at a point where
the code is really just executing painting instructions for that one feature.
The one downside that there might be, is that the renderer will give the extension point a feature whose attributes have been reduced to the ones
explicitly used in the style, it will have to work with what it has there. Thinking out loud, it could be extended a bit more to have a voice
regarding the attribute selection, giving it the ability to claim for extra attributes needed to do its work.
For work that is not desirable to express in SLD we do have an “out” in the form of GeoTools Direct Layer. All the same same functionality available to streaming renderer (converting geometry to Java 2D shapes) is available for you to use in your own implementation. You could even try subclassing StreamingRenderer, or forking it, as was done with previous shapefile streaming renderer.
I have stayed out of this discussion so far… In my opinion, the single focus on dynamic highlight muddied the waters.
The way I see it, an extension point like this one allows to do something that would be hard or impossible to do with SLD and its static structure limits, including:
- Complex calculation that could be hard, or very inefficient, to run as OGC Expressions. Context, I had to do several rounds of optimizations in the GeoTools expression evaluation engine to make the OSM styles perform, and yet, it’s still very slow, has an allocation rate that’s just murder due to the “everything is an object” paradigm and widespread usage of converters. Will never be able to compete with a direct java implementation of the same logic, by design.
- Stateful evaluation, in particular, keeping track of interesting features and so something different based on their re-appearance or overlap with other layers. For example, in marine cartography one needs to change symbology based on what’s overlapping in previously painted layers… An SLD extension doing something like this would have to change the language in a significant way, I believe.
- Out of band information. The SLD painting model is pretty simple, can only play with the layers that are included in the map being painted, one at a time. A programmable extension point would allow to reach out of these limits, and perform decisions based on information present outside of the current map layers.
Rendering transformations could also be used to achieve some of the above goals, but they would have to act without knowing how the feature is going to be depicted, while this extension point gets the symbolizers, and can take decisions based on them too.
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.
