Hi all,
I've been recently queried about ideas on how to support Mapnik style
compositing and image filters in Geotools/GeoServer SLD:
http://mapbox.com/blog/tilemill-compositing-operations-preview/
http://mapbox.com/blog/expanding-mapnik-carto/
http://mapnik.org/news/2012/04/20/smart-halos/
Compositing wise, we have some support in AlphaComposite (
http://docs.oracle.com/javase/1.5.0/docs/api/java/awt/AlphaComposite.html),
see some examples here:
http://docs.oracle.com/javase/tutorial/2d/advanced/compositing.html
This is a vendor option that could be applied to both the single
symbolizer (for efficiency) or to the whole FeatureTypeStyle (to be
used when we compose it with the eventual FeatureTypeStyle objects
behind it).
There is however a problem, Mapnik supports all the SVG compositing
methods, while Java2D only a few of them:
http://www.w3.org/TR/2009/WD-SVGCompositing-20090430/
Looking at that, it seems that the missing methods can be emulated
via JAI image processing.
However, that is something that can only be done when a raster is handy,
so it's something doable only at the FeatureTypeStyle level.
My takeout would be that we could support only the java2d supported
methods at the symbolizer level (for efficiency) and support
others also at the FeatureTypeStyle level, maybe via a pluggable API
so that more compositing methods could be added over time
(maybe at the beginning only a few are implemented, allowing
more to be added later).
Image filters, like embossing, blur, and so on (full list here:
http://support.mapbox.com/discussions/tilemill/1806-image-filters-reference
)
are, like then name says, only possible as you have an image,
which means they can only be applicable at the FeatureTypeStyle
level, once we're done rasterizing all the features.
Here too I'd envision a pluggable system where people can add their
own image filters.
SLD syntax wise, I guess we could use VendorOption for both.
Symbolizer already has support for a list of VendorOption, adding
one to FeatureTypeStyle should not be hard.
However that has some limitations, in that we could support only
one image filter per feature type style, whilst Mapnik supports
a chain of them.
They actually do that in a single attribute, sticking filter params in
it too:
image-filter="grey|blur:rx=4,ry=4|emboss|..."/
Hum... that seems a bit extreme, on the other side if we are going
to support many of them in a single vendor option, I don't see
a way out.
Either that, or we also support image-filter-2, image-filter-3, filter...
as more
vendor option keys, and apply them in order.
The alternative is to do an operation like the rendering transforms one,
in which we allow one or more extra elements, which guess what,
could look like filter functions again, each defining a image filter
and meant to receive a RenderedImage as an input, instead of a feature.
<ImageFilter>
<ogc:Function name="gray"/>
</ImageFilter>
<ImageFilter>
<ogc:Function name="blur">
<ogc:Literal>4</ogc:Literal>
<ogc:Literal>4</ogc:Literal>
</ogc:Function>
</ImageFilter>
...
Hum... opinions?
Cheers
Andrea
--
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
