Hi Simone, thanks for the detailed description of the intended work. It sounds very interesting to me and the approach just right.
In my opinion, if there's something preventing innovation on trunk then our process is weak, even if trunk is approaching a release. May be we shouldn't release from trunk but move it to a "stable" branch before it reaches the release status? Hopefully most of us are already used to have our own git clones of trunk and to keep them in sync, which makes it way easier to have non disruptive experimental branches. So I'd say go for it. If you see you can make it for the release then merge, otherwise just keep your branch in sync for after the release and then merge. It's totally up to you guys and I'm sure you'll get it right. Question: is sld:Transformation in SE 1.1. or would it be a custom extension? blesses, Gabriel On Thu, 2010-12-23 at 12:07 +0100, Simone Giannecchini wrote: > 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 -- Gabriel Roldan grol...@opengeo.org Expert service straight from the developers ------------------------------------------------------------------------------ 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
