Milton Jonathan ha scritto: > Hello Wouter and Andrea > > I've just read the whole exchange of e-mails from you guys, quite > interesting stuff. > > We've also been thinking about using different renderers depending on > the kind of layer (e.g., some may be perfectly rendered with OpenGL, > some may not due to unsupported styling, for instance). And we also have > been thinking about different kinds of caching strategies too. By the > way, I am also cc'ing Johann Sorel from Geomatys, since he is the cache > guy over there (ahm, I'm not sure whether we should shift this > discussion somewhere else to make things easier for everyone to follow..) > > Well, regarding the caching itself, our current approach (which is now > still only implemented in a different project in C++) is to cache the > original geometries (not the decimated ones) in blocks of data according > to a spatially indexed tree constructed only once on first access for > each layer/FeatureSource. These blocks are managed so that when a max > memory limit is reached, least used blocks are discarded to give way for > new data to be stored. This way, if the user stays within a certain > region, data for that region will eventually be all in the cache and > user interaction will be fast, allowing quick zooming, panning, editing > and style changing. Also, loading of blocks of data is done in a > separate background thread, so that the user can go around zooming and > panning while the data is being loaded and progressively rendered on the > screen.
Wow, this seems excellent design and quite widespread in applicability. I'm thinking of two use cases that do not have to do with rendering where that approach can provide very good results: - web applications in which the main interface is WMS, but WFS is used to provide some extra elements such as markers with popups. Generally speaking the markers are extracted with a limited area (they get enabled only when fairly zoomed in) so in a case of light load having the surrounding area cached as well may be quite a bit of help - spatial analysis in which you have to make inner loops. Think polygon map overlay, the usual way is to scan the first layer and gather the polygons of the 2nd whose bbox interferes with the current element of the 1st. Having a cache can help efficiently computing the overlay without requiring an unordinate amount of memory (the naive approach being loading all the polygons of the second layer in a in memory structure). > On the other hand, we've also been considering the idea of caching > decimated geometries, since zooming out and fitting the entire dataset > may go well over the cache limit, making our current cache kind of > useless in this case. In that respect, one of the wild ideas we started > to think about was to keep in memory at least the last level of detail > requested (which is not really much of a memory load even in the case of > fitting the entire world in the user display). As such, this would allow > some kind of rapid response whatever the user did, regardleess of the > situation, while the full level of detail was being loaded in a separate > thread. In any case, I guess we should take a look at alternative > strategies for decimating the geometries: maybe the simple one currently > used by StreamingRenderer, or one based on the Douglas-Peuker algorithm > (or something else). Sure, the approach used by streaming is naive and cannot reduce points that DP would remove (almost collinear points for example). I've tried DP but the extra cost offsets the gain in a pure streaming approach. If you have caching in the middle then it makes sense to spend more time generalizing in the hope that the result will be used over and over. The streaming renderer is already almost cut into two parts, the first loads the data and turns it into a RenderableFeature, that caches the transformed geometries, so we could effectively split it into two distinct parts, one that returns renderable features out of the datastores and one that performs the latter stages of the drawing. Using interfaces and composition it would be possible to stick a cache in the middle of the two. > Anyway, when we stop to think a little about it, it becomes clear to us > that there are different sorts of cache for different purposes, and some > of them may even be combined (full-blown object caches that allow all > kinds of object manipulations,visualization-specific caches, etc) > > Aside from all that, a completely different subject: I was really > interested when you mentioned HibernateSpatial - I hadn't heard of it, > and it sounds really interesting. Is anybody thinking about somehow > integrating it with GeoTools? Don't know, maybe a > HibernateSpatialDataStore? I'm just speaking in the heat of the moment, > and it surely wouldn't be the most interesting way to render things > fast, but I think it may allow applications to have a powerful and > flexible way to define layers that have complex feature objects along > with their relationships to other objects.. Any opinions? Eh, the sad thing is that I developed a hibernate based GT2 datastore three years ago for a company, but it was never released in open source (it was not using Hibernate Spatial, never heard of it at the time). So yeah, I have experience in developing that kind of thing and also in optimizing it for performance, and it's surely of interest if your application demands a static object model and uses some of GeoTools to handle the more GIS oriented part of the problem. Unfortunately at the moment nothing I'm doing demands the usage of Hibernate spatial, but I'm open to provide suggestions to whoever wants to try and implement such a thing, or even available to develop it again if someone finds enough sponsoring for the job. Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ _______________________________________________ Geotools-gt2-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
