Wouter Schaubroeck ha scritto: ... >> 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
Yeah, there are a bit of label options that may make this less trivial. For example we have a vendor option to prioritize labels based on a constant value you specify in the SLD (different symbolizers, different priorities) or an attribute value. > 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. That's what DefaultLabelCache does, it's already in there. I have to port a improved version of it we developed in GeoServer but it's basically applying a conflict resolution algorithm and in the improved version can also displace labels along lines (but still not for points or polygons). > 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. Hmm... the car is an irregular shape, so you'd have to perform a lot of topological comparisons (a car can be only partially visible), those are very expensive, in the end you might take less time drawing all the cars directly (after all it's a bit blit, something accelerated in hardware). > 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). Don't know about OpenGL, recent java runtimes turn BufferedImage into volatile ones on your back as an optimization when possible. > And this is only valid for big > collection of points. The technique I used, was only faster if there > were more than 5000 points. Ok, so that would be a good criteria for choosing a custom renderer: the style must be simple enough and the points per pixel on image ratio must be over a certain threshold (that would be an heuristics, of course). >> 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? That sounds like a good idea. Wouter, meet Jonathan Milton, cc'ed. He's interested in creating such a cache as well. Btw, quite some time ago I wrote this on the topic: http://docs.codehaus.org/display/GEOTOOLS/Datastore+caching Unfortunately never got time/sponsoring to actually implement any of that, but it may be of use in your efforts. >> 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! Last time I heard about it they were talking about end of December but, that might have changed in the meantime (months have passed). > 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? Nope, never tried. Personally I would try hard to get whatever speedup possible without going down to native code, especially code that assumes a specific graphics card to be available. But that's just me, if Cuda is something that makes you happy working with, by all means do ;) 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
