Thanks for the summary Rich. From my perspective I am interested in
identifying areas where GeoTools is weak and working with you on an
appropriate proposal to avoid hacks and workarounds.
I liked your appropriate/creative use of a render transform that had not
occurred to me.
In addition to the idea of using a DirectLayer subclass you may find it
interesting to consider the result as a coverage (rather than as a vector
data). The results of your external rendering would come back as a coverage
which could be merged with other content.
If he idea of carrying around a mask is so useful in cutting down work you
may want to look at assembling a mask out of layers that "on top" of your
geowave layer.
--
Jody Garnett
On 10 February 2015 at 14:23, Rich Fecher <rfec...@gmail.com> wrote:
> 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
