Hi everyone. Ede: 1 - The clearImageAndRaster() method is called a few times inRasterImageLayer: inside the createImage(), getTileAsImage, getTileAsRaster(), and setVisible() methods. 2 - I had a look at the ReferencedImage framework, but I couldn't find a way to retrieve the actual cell values for the loaded images. In some places it uses GDAL to load images. Do you know how this framework relates to the RasterImageLayer class? Is it older, newer, could the two be merged? 3 - The "temporary rasters" I was talking about would be typically created by some raster processing plugin (like sextante), yes. The point would be that the user wouldn't need to specify a path for the output rasters.
Michaël: 4 - Multi-click/multi-selections: I hadn't thought about that. Multi-click could be done, it would show the values of all the clicked cells, instead of just the last one. Multi-selections I don't really know: how would you see it implemented for rasters? 5 - Retrieving cell values on demand from disk: yes, definitely an option. 6 - Memory vs. performance in other software. I've checked QGIS: the raster management appear totally disk-based. Opening large rasters has almost no impact on memory usage, and raster processing requires a path to the output raster. GDAL is somehow involved. ArcMap's raster managements too is file-based, and they enforce the use of pyramids to speed up raster visualization. 7 - I played a bit with the sextante tools and some big rasters using the r4004 release. Using the 64-bit JRE I managed to load a single 5000 by 5000 raster, and complete a "flow accumulation" operation (memory usage was up to some GBs...). With the 32-bit JRE I got a "Cannot constuct DataBuffer"error. Additionally, opening the sextante toolbar and selecting the different tools was very slow, probably because sextante is doing some checks on the loaded raster to know what tools to activate. That said, we can: a - revise the RasterImageLayer class, and see if we can load in memory only what's strictly needed. b - try to delegate the raster management to GDAL (like QGIS) that probably has already very sophisticated means to load only what's needed to display the image (or part of it) and to provide basic image information (min and max value, unique cell values for discrete rasters...) needed for rendering purposes. c - ...? In any case, I don't know how tools like sextante would work: would they need anyway at some point to load in memory the whole array of cell values to perform the processing? If the operation to be be made on the raster is cell based, there should be no problem in processing a tile at a time. But if the operation needs information about neighbouring cells too (like flow accumulation does), special precautions would be needed... By the way, I can confirm: I have access to that "bertazza" sourceforge account. I don't think I've ever made any commit to the OJ project though... :P Alberto ------------------------------------------------------------------------------ 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
