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.RasterImageLayerIf you agree with implementing these changes, the FeatureInfoTool should probably be renamed into something more generic, without a reference to the features.
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.
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). 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). 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.
As an alternative, we could just comment that rasterData = null statement, and count on the virtually endless memory available on 64-bit systems.
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? Alberto
Info.7z
Description: Binary data
------------------------------------------------------------------------------ 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
