On 16.10.2014 14:10, Alberto De Luca - GeA wrote: > Dear OJ developers, > > still working on OJ's raster handling features: we've modified the "Feature > info tool" to make it able to display the values of the rasters loaded in OJ. > I added a third pane (called "R") to the feature info tool, with a table > displaying, for every raster, the value at the mouse click. It works for > single-banded raster, for now. > > In the process of adding this feature, I modified the RasterImageLayer class: > - added two methods to retrieve the value of a cell from real-world > coordinate and from raster col/row; > - turned the noDataValue variable into non-static. > > The classes that I've modified (attached) are: > - com.vividsolutions.jump.workbench.ui.InfoFrame > - com.vividsolutions.jump.workbench.ui.cursortool.FeatureInfoTool > - org.openjump.core.rasterimage.RasterImageLayer > > If you agree with implementing these changes, the FeatureInfoTool should > probably be renamed into something more generic, without a reference to the > features.
the Tools are generally just cursor implementations that internally start other routines in this case the InfoFrame. so this is already generic internally. i don't see the advantage of renaming but go ahead if you feel inclined. be careful and find all the places that the class names need to be changed. do not forget default-plugins.xml . > One thing: when loading large rasters, the method > RasterImageLayer.clearImageAndRaster(boolean garbageCollect) nulls rasterData > variable, making it impossible to retrieve the cell values. In the infoTool > I've handled this circumstance using an exception, but it's just a patch: a > raster without cell values it's no more than a picture. when is this method run? sounds to me like a method that is called if the layer is removed. if not wouldn't it make sense to allow to recreate the data in case it's needed. > I think the problem of handling big rasters needs to be thought over. > Ideally, all raster data should reside in the RAM (like vector data do) but > we know that rasters can be very heavy. One solution could be to maintain > each raster linked to its source file and read the data only when needed > (slower, but lower RAM footprint). that is how the ReferencedImage reader works. did you have a look at it? do you plan to support it as well? >Nevertheless, it would also be nice to be able to create temporary rasters, >without the need of specifying a file name and format (just like it's done >with newly created vector layers). you mean for raster data e.g. generated by sextante? >In this case, a possible solution could be the creation of a temporary raster >in a temporary folder, and this would probably work also for rasters >downloaded from the web (WCS). In other words: rasters would be always >file-based, and when needed a temp file would be created. that is how WMS works and e.g. the old MrSID reader . > > As an alternative, we could just comment that rasterData = null statement, > and count on the virtually endless memory available on 64-bit systems. that's just a quick hack. you described the proper way to deal with it above. after all we are a java app (bad memory mgmt) and target ordinary desktop users, not professionals with ultimate workstations. > > I've done a new memory footprint test, with and without the "rasterData = > null" statement. I've loaded 5 rasters, 4728 cols by 5815 rows. Memory > consumption goes from 2400 MB to 2770 MB. I would have expected a larger > difference, but maybe it's just because the GC takes some time to do its job. > > What do you reckon? i'd really like to hear what Jukka says about the non static rasterData . but apart from that i'd say we will hear about it if raster become unusable from our users soon enough. if you did plausibility checks that's enough by me. ..ede ------------------------------------------------------------------------------ Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
