On Sat, Dec 6, 2008 at 3:30 PM, Andrea Aime <[EMAIL PROTECTED]> wrote: > Wouter Schaubroeck ha scritto: >> >> Hi list, >> >> I read this interesting page: >> http://geotools.codehaus.org/Rendering+Optimization about rendering >> optimization, and was wondering, how far this actually got >> implemented. What is implemented in Geotools and what not? >> It's because I've made actually one implementation of optimized >> rendering for points with geotools (kinda udig style), and it's >> working very well! Some technical details can be found here: >> http://conference.osgeo.org/index.php/foss4g/2008/paper/view/340/196 >> (PDF). > > Very interesting. I'm wondering how easy is to generalize. Certainly > we can setup a 1 pixel width grid and light up pixels as points > hit them, but what about non trivial styling, labels and the like?
Indeed, this is the next step. Personally, i think the labels in this matter should be last to look at. This for the following reasons: 1. only draw labels for these points that we are certain that they are on the map 2. There are several label optimization techniques (and algorithms), and implementing these together with the other will be hard: the positions of the labels can only be calculated after that all the visible points are known. For the non trivial styling: I was thinking on something like this: Let's say, we display the points with a simple car, so each point is displayed as a car. Now we calculate the spatial extend (on the map) of that car, and keep it in memory, together with the geometry this car represents ( in this case: a polygon). We iterate over each point in the collection, and compare it's position on the map to the spatial extend of the geometry of the car, if it's not contained by the spatial extend or the geometry, then it would be added to a MemoryFeatureCollection. The original geometry of the car will be extended to contain this new point (so this geometry may become a multipolygon!). This continues for each point in the collection. The final step is to draw the MemoryFeatureCollection. What do you think about this? I know, it has some issues, like: you need a beefy server to calculate all this, and i don't know if it's worth the juice... Perhaps there's a bigger performance gain if we should use a different way of rendering the image (BufferedImage <-> volatileImage) or even opengl? (ofcourse there's allways the hardware requirements for these last ones). And this is only valid for big collection of points. The technique I used, was only faster if there were more than 5000 points. > The optimization must be smart enough to handle all possible point > styles the user throws at it (and eventually disable itself if > it cannot handle the current style). > For example, what if you wanted to colour each lighting with a > different color based on its magnitude (don't know if it makes > any sense, but if not, think of any point located variable > that has an attribute that can be used to drive color), > in that case what do you do? The grid should probably contain > not only the fact that there's a point there, but also what > is the "most interesting" (supposedly, the highest) value > that occurred in it. Very right indeed. The application has something like this, but it doesn't use the optimalization. It always displays all the points. This is because, currently the application has no clue about which point is more interesting. Although I think it's quite easy to implement this: we could create some kind of filter: if the current displayed object is more important than the evaluated one, nothing happens, and vice versa. But again, this all costs cpu cycles... > >> I'm working on a optimization for displaying linestrings (and perhaps >> polygons), based on generalization. But that is still a work in >> progress. > > The current streaming renderer does exactly that, generalization on the > fly before rendering. To get better performance you should keep an > in memory cache of the generalized geometries I guess. > Anyways, I may be missing something. What's your approach, in detail? I haven't implemented a memory cache yet, I'm still working on the implementation of the Douglas Peuker algorithm (because it's only a testcase). To be honest, I didn't know the streaming renderer had a generalization, I guess I may stop now, and focus perhaps on the memory cache? > >> If you guys are interested, I'd like to integrate my code with the >> geotools code, but honestly, I don't know how this has to be done, are >> there some procedures you have to follow, or can i just send my code >> to somebody? > > Let's talk more in detail about it. Then you can attach patches > to Jira. > > Quite frankly for these cases I'd like to see a renderer much like > uDig one, layered, so that each layer can use its own specific > rendering strategy (so your approach could be used only if the > data and styles used make sense for it). > > I know there is a renderer like that in the works at Geomatys, > but for contractual reasons they cannot open its sources just > yet. That renderer should have the renderer per layer approach, > and I still have a tiny hope that we can use StreamingRenderer > as a singe layer renderer inside that framework (and add renderers > such as yours as specific layer renderer instead). > That is, provided it's not too hard to back port it to java5. > > Anyways, in the meantime we can talk about your work and a possible > merge with the StreamingRenderer (which I help to maintain), with > time we'll see if it's possible to merge everything with Geomatys > work of if we'll have to roll a new multilayer renderer for GeoTools. Is there any date set for this framework of Geomatys? I like the idea of a specific renderer for each layer! For the integration of my work in the streaming renderer, I'm creating an develop environment for geotools on my pc and next I'm going to study the code, implement my stuff and run some tests. I'll keep you updated! Some other stuff, I guess you all heard of the cuda library of nvidia (use the gpu of your machine for complex floating point calculations). I know there's a javaport of this library, has anyone used it together with geotools or other geospatial stuff? Greetings, Wouter > > 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
