Re: [Geotools-devel] Changes to gt2 render model?

[Jody G. <jga...@re...>]

Thanks for the reply Andrea:

>>This is a *very* extensive design/change proposal - apparently James
>>suggested this back at the dawn of time?
>>    
>>
>There was an initial implementation in Java2DRenderer with fine grained
>wrappers called RenderedFeatures if I remember correctly... this was abandoned
>since at the time I performed some optimization on the simpler LiteRenderer
>code and Martin provided the more advanced j2d stateful renderer...
>  
>
Hrm - I am not sure I quite understand. What I am looking to do is 
derive what is display on the screen from a user model of layers to a 
render model of layers using metadata provided by DataStore.

>This separation is of course natural if you have some kind of caching, but I 
>don't see the advantage if you want to be stateless (that is, to limit the 
>total amount of memory needed to perform the rendering).
>  
>
I am not sure we are talking about the same separation of concerns - I 
am trying to separate out request from response (user model vs 
application model).

>j2d already has the separation, and if it learns to work with a fixed memory
>size (independent on the amount of data needed) we can just drop LiteRenderer
>at once :-)
>  
>
I am not sure j2d is the right place to do this sort of thing, I would 
kind of like to leave any caching at the DataStore/GridCoverageExchange 
level (where could cache to local disk if needed). That way more client 
code can have the benifit. Put another way I am not sure we can teach 
j2d enough about WMS requests to cache them effectively.

>There is no LayerManager in gt2 (maybe there is one in Jump?). Anyway, I like
>the idea of having a well defined separation between the rendering of a single 
>layer and the composition... which is in fact what j2d does I guess, 
>j2d.Renderer is just the manager, the actual drawing is performed by the 
>RenderedLayers. Only, the renderer now doesn't have any idea about the data 
>sources, so at the moment it can't perform the kind of euristic you 
>describe... 
>  
>
You are right but in all the gt2 demos we have a List of MapLayers to be 
displayed. Interesting about j2s having the separation you describe it 
may be the right location to do this sort of work. This thread 
origionally started on the uDig email list where we are tyring to draw 
lines in the sand between what development goes where.

>>This can be turned into the following MapLayers for display (Alternate &
>>Combine):
>>- A - WMS request asking for both road and river
>>- B -  Shapefile FeatureSource request for ditch
>>
>>As the user zooms in it may become more efficient to do this (Alternate):
>>- A - WMS request asking for road
>>- B - WFS FeatureSource  request for river
>>- C -  Shapefile FeatureSource request for ditch
>>    
>>
>This works fine in theory... but in practice, since the datastore are plugin 
>based, how do you evaluate the cost of different strategies? Also, you could
>have local on disk caches for wfs requests making those less expensive...
>It's not that I don't like the idea in general, it's just that I don't easily 
>see a way to perform this kind of decision. In the geoserver case, I'm
>not sure the above euristic can always work, for example, a wfs request
>is probably more i/o intensive and a wms more cpu intensive, and the
>optimal threshold for switching from one to another depends also on the 
>kind of current server workload... 
>  
>
The difficult part is not the WFS but WMS - it does not really want to 
fit into any of the boxes we have made for it. It is not a DataStore, 
and despite our best efforts it is not really a GridCoverageExchange.

You know we almost do this huristic right now - we have that magical 
part of our pipeline when we try to locate a DataStore for a given 
request (using Param objects). Interesting - we are so close to what I 
have in mind, but we lack intergration. I need to take this out to the 
"next level" where I have a "Data Manager" or something that actually 
goes and grabs the appropriate metadata so we can make judgement calls 
like this.

This is the same Catalog/Metadata lack I tried to address back in 
september, I suppose now that I have read the specs I can do something 
about it.

Jody

>PS: it has been a pain, but I finally succeded in installing Oracle spatial on
>a Linux box of mine (the notebook, since it won't install on my Mandrake 
>10)... :-)
>  
>
That is great news! More testing the better.