>
> To get this "solid" one would need a implementation that is part of
> GeoTools. See my comment about maintaining compatibility towards something
> that is not
> part of the API.
> If it's small changes that can be locked down with tests I don't see a
> particular problem, if we have instead to
On Mon, Feb 16, 2015 at 5:23 PM, Rich Fecher wrote:
> I can dig into the concept of GetMapCallback building a DirectLayer -
> from that standpoint we will ill fit into the spirit of geoserver/geotools
> public API's much better I think, and still have full control, similar to
> the full control
Wow, a lot of great activity on this thread over the weekend. On my end, a
family issue came up so I'm playing catch up now - first I'll try to give a
little background and then try to start from the top and work down...
As far as background, one thought here that's a bit bigger picture than my
s
On Mon, Feb 16, 2015 at 1:04 AM, Jim Hughes wrote:
> Hi all,
>
> I'd like to try and summarize the discussion so far to make sure that I
> understand.
>
> As a request comes into GeoServer, it would either be handled by a custom
> GetMapCallback or by a distributed-render-aware Renderer by GetMa
Hi all,
I'd like to try and summarize the discussion so far to make sure that I
understand.
As a request comes into GeoServer, it would either be handled by a
custom GetMapCallback or by a distributed-render-aware Renderer by
GetMap. From there, the distributed GeoTools data/feature store w
On Tue, Feb 10, 2015 at 8:23 PM, Rich Fecher 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 equi
On Sun, Feb 15, 2015 at 3:05 AM, Jody Garnett
wrote:
>
> Long story short, a layer parallel renderer seems suitable for desktop
>> usage (where you have one request at a time, and 8-16GB of memory to play
>> with),
>>
>> Agreed, hence my interest in taking part on behalf of the uDig project.
>
A
> Long story short, a layer parallel renderer seems suitable for desktop
> usage (where you have one request at a time, and 8-16GB of memory to play
> with),
>
> Agreed, hence my interest in taking part on behalf of the uDig project.
As for experience/observation - one way to approach the distribu
Parallelization of the rendering pipeline for faster rendering/painting
operations isn't the primary goal we had in GeoWave with the distributed
rendering request; rather we wanted to short circuit the actual reading of
features off of disk/memory based on "not coloring pixels twice for the
same F
On Sat, Feb 14, 2015 at 8:05 PM, Jody Garnett
wrote:
> If there is activity in this space I would be interest in setting up a
> multi threaded renderer and retiring the multithreaded renderer in uDig
> (but in the context of GeoServer):
>
I'm copying and pasting an answer I gave to someone that
If there is activity in this space I would be interest in setting up a
multi threaded renderer and retiring the multithreaded renderer in uDig.
The recent work on color blending means there a lot of composition action
going on inside a single layer of the map.
On Tue, Feb 10, 2015 at 11:53 AM Jody
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
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
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 funct
14 matches
Mail list logo
