Dear All,
I am writing this email in order to get your feedback about this bit
of work that Andrea et al. @ GeoSolutions are looking into doing right
now in geotools.
These below are the requirements we have:
* Raster to Vector
* given a grid coverage, render it as a set of vector (arrows,
using two bands for direction and intensity). Equivalent to a raster
to point transformation plus point symbolizers (with eventual
priority?)
* given a grid coverage, render it as contour lines
* given a grid coverage, render it as vectorized polygon
* Raster Transformations
*given a grid coverage, apply raster algebra transformations
before rendering it
Summarising we would like to be able to rendere raster data as either
point, countour or polygon using the vector styling capabilities of
GeoTools. We would like to
be able to use this from GeoServer or GeoTools via SLD since we need
to control this process from clients that may want to change the
control parameters for this processes on the fly.
While the first three points are needed right now, the latter will be
implemented later on next year. Notice that we inted to rely on the
work that Michael is doing inside JAI-Tools in
order to come up with JAI operators for the contouring as well as the
vectorization.
Now we have been thinking about the least invasive approach for
supporting this work given the very short time window we have for
windows taking into account that
GeoTools and GeoServer are on the verge of a release and that we
cannnot make extensive changes.
Also, we’d like to avoid making custom modifications just for these
needs, we’re sure there will be more on the fly data transformations
in the future that cannot just be addressed by simple geometry
transformations, but we’d like a generic way to chain a generic
process into the rendering if at all possible.
Our rough proposal (Andrea will come up with an official one soon..)
can be summarized as follows:
== Tranformations in SLD ==
The transformation is called within the render via the least
disruptive SLD extension possible.
There is some background to be laid down here:
-a raster symbolizer always sees the whole coverage as the input
-a vector symbolizer sees the single feature instead
In order to support a full data transformation (including chainging
the data type from raster to vector) the transformation has to occur
before the renderer starts walking over the input feature collections
(in the raster case, the collection contains a single feature wrapping
the coverage, old hack that did stand the trial of time, we’ll take
care of that as well)
Long story short, the right place in which a transformation has to be
made is likely at the FeatureTypeStyle level. The transformation could
be as simple as calling a filter function, or more complex, like
calling a process. In fact we could have a simple bridge (a filter
function factory) that makes it so that every registered process can
be also seen as a ogc Function (provided it returns just one output).
We could have something like:
<FeatureTypeStyle>
<sld:Transformation>
<ogc:Function name="gs:intersection">
<ogc:Literal>input</ogc:Literal>
<ogc:Function name="identify"></ogc:Function> <!-- fake
function that returns just returns its context, which would be the
feature collection, the whole transformation would be in fact invoked
passing down the feature collection as the thing to be evaluated -->
<ogc:Literal>cookieCutter</ogc:Literal>
<ogc:Literal><gml:Polygon>...<gml:Polygon>
...
</ogc:Function>
</ogc:Function>
</sld:Transformation>
The bridge between functions and processes has to take care of one
fundamental difference: in functions arguments are positional, in
processes they are named. The above makes it work by specifying the
argument name, then its value, then the next argument name, next
value, and so on.
For multivalued arguments we could have a “list” function that
collects them into a single item, so we preserve the name/value
alternation
For raster data we can recognize the feature collection is wrapping a
raster and unpack it, passing down into the transformation function
the coverage instead, and wrap back the result. This would keep our
wrapping hacks under the carpet.
One interesting aspect of this approach is that the processes, wrapped
as functions, would enter the picture only if the WPS module was added
to GeoServer, but there would not be any part of GeoTools or GeoServer
depending on it thanks to the process/function bridge.
==
We believe the approach we have underlined above will have a rather
limited impact on the codebase, therefore we would like to proceed
with a short cycle of proposal/implement directly on the current
trunk. We believe that the potential of this work could be of general
benefit since other more complex transformations might be added
relatively easily, just like geometry transformations it would be an
open ended extension point.
Just to give you an insight on where we will go after this, we are
also thinking about improving GeoServer in order to have processes as
a source of layers. In this case a new layer will be configured that
will be backed by a WPS process returning either a feature collection
or a grid coverage. Of course the impact of this change would be
rather large therefore we ill go back to this next year.
Regards,
Simone.
-------------------------------------------------------
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584962313
fax: +39 0584962313
mob: +39 333 8128928
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini
http://twitter.com/simogeo
-------------------------------------------------------
------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
