Yeah, so on the GeoWave project we started out with a simple sub-sampling
approach that used a render transform to pass the pixel dimensions of the
map request to our data store so that we could skip within our tablet
servers at the equivalent of a pixel resolution on our space filling
curve. This works well for basic point data but for polygons and lines -
data with more complex stylization that does not well map what is actually
rendered to the gridded representation on our space filling curve, we take
advantage of actually doing the rendering within the tablet servers.
Without finding any quick and easy extension points, our initial take on
this was to use spring bean exclusion in GeoServer to exclude the existing
map producers and add a distributed map producer. Within this specialized
map producer we try to re-use as much code as possible by extending the
StreamingRenderer with a distributed one. We basically try to process the
style to the point of decomposing the rules down to LiteFeatureTypeStyle
objects within GeoServer and send these styles along with map request
bounds to our tablet servers to render the features local to the data. At
this point we basically run through the StreamingRenderer logic to process
the symbolizers for each style rule. We keep each style separate and
ordered along with the labels separate so we can composite in the correct
order within GeoServer. In addition to distributing the load of the
rendering this concept allows us to subsample or skip over our feature data
that completely overlaps pixels that have already been rendered by
maintaining essentially an image mask of what we've rendered. This was
proving out the concept but we are interested in a more elegant integration
with geotools rendering code.
Thoughts?
Rich
On Tue, Feb 10, 2015 at 11:53 AM, Jody Garnett <jody.garn...@gmail.com>
wrote:
> Possible subject for discussion at foss4g-na, talking with GeoMesa /
> GeoWave people about integration options.
>
> My initial take was the Query/Transform Idea (see earlier emails) to
> surface Query as clear CQL expressions for distribution. Turns out this
> would need to be combined with aggregate functions (for simplifying the
> results).
>
> Discussion has moved over to options for hooking distributed rendering
> into the stack.
>
> * So far DirectLayer is a good candidate, may need a bridge between a
> DataStore and a "recommended" DirectLayer implementation
> * Had a look at Style2D classes (after all the SLD data structure has been
> boiled down)
> * Really wish the TileSet work was back ported so we could pretend the
> distributed renderer was a set of tiles...
>
> Any other options/suggestions?
> --
> Jody Garnett
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
