Le 17/10/2014 23:07, edgar.sol...@web.de a écrit : > 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 . For vector layers, the tool reacts to mouse click or to mouse drag (multi-selection). Do you plan something comparable for layers ?
Luca, I checked that you are in the list of developpers of the project. So you should have write access to the svn with your username "betazza". Can you confirm ? > >> 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. maybe a stupid question : if the image can be retrieved on disk as needed (pan, zoom), would it be an option to retrieve raster data (cell values) on demand the same way ? maybe a solution for some formats (uncompressed) and not for others... > >> 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? Keeping a link to the source file is also the way vector layers work, but vector layers generally load data into memory (there is a shapefile driver in the wild which do not though). For images, I think that not loading (or loading only the minimum) is a better choice but there is probaby a big performance penalty for some functionnalities. Do you know what are usual tradeoffs of memory vs performance issues in other GIS / image software ? > >> 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. Nowadays, you can also work with images representing tens of gigas of uncompressed data (ecw, jpg2000), putting al this data in memory is not a solution for all situations. I would say that the default behaviour should be "read from disk on demand", and situation / plugins which need a faster access should be clearly identified. >> 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. Ya, the hack does not seem to be very efficient... If it is confirmed, I would say it is not worthwhile. Did you let the time to the GC, or did you force it to collect garbage ? Maybe teh hack missed the point. Could you check whare these 2 G of data are retained ? Michaël > > ..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 > ------------------------------------------------------------------------------ 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
