Hi, Summary of a long message: General Info tool can continue to use name "Feature Info". It does not feel odd for the users and others use similar naming. If there will be a separate raster query tool, call it as "Raster Info".
I did not check gvSIG and uDig but in QGIS a similar tool is called "Identify Features" and the same tool is used for vector and raster layers. If layer is a WMS layer the tool sends GetFeatureInfo requests to WMS service. If the WMS layer is made from vectors the request will send back vector attributes, but if it is a raster layer then the response is telling the pixel values for each band. I do not feel it necessary to rename FeatureInfo in OpenJUMP either just because it could be used as well as "RasterInfo". And raster layers are not so far from vector layers always because the pixel value can express attribute value in a cell which is actually presents a polygon or point (DEM, measurement grids). However, OpenJUMP has some differences to QGIS. Feature info makes query to all visible layers and that can't be controlled by setting a visible layer into queryable/not queryable state from U. It would irritate me as a user to get pixel info from background images always when only vector data really interests. But I read that raster query results would be on a new pane "R". It would be nice to test how it feels in use. If the raster query results are not automatically shown together with the vector query results it would probably feel OK. Having a separate "rasterinfo" tool does not feel perfect because I am not sure what to do is we will have some day a tool for doing WMS GetFeatureInfo queries? Should there be a third tool or should the feature be added either into vectorinfo or into rasterinfo tool? If I remember right the GetFeatureInfo that was in the deeJUMP version had a separate button. I was thinking about two alternatives 1) Have a single Info tool and keep the current behaviour with vector layers. Perhaps there could and an option in UI for making layer unqueryable even if it is visible. When raster layers are selected the Info tool would make raster info queries from selected and queryable raster layers. And if WMS layers are selected the tool would make GetFeatureInfo queries for layers which are announced queryable in WMS GetCapabilities. This option would be deactivated until OpenJUMP can do GetFeatureInfo. It may be that the third "R" pave gives excellent user experience without thinking about when to make certain layers queryable/not queryable. 2) Make a new "Raster info" tool and prepare for enhancing it into "Raster info toolbox" later. Besides point query from a single pixel there could be another tools which take a linestring and return raster profile (we have such already in "Sextante-raster" tools in OJ Plus), min, max, average, histogram along the line etc. Another tools could take a polygon and compute statistics from that area. The line and area tools could use the selected feature(s) from the project as reference geometries Alternative 2 feels teasing for me because it probably would make is easier to develop new raster tools. My personal needs may have an effect because I would actually have some use for an easy to use "Get histogram inside selected area" tool. Now I use Saga GIS for that purpose. By the way, it would be often nice to see the pixel values under the cursor in real time like coordinates are shown now. -Jukka Rahkonen- Michael Michaud wrote: > 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 ------------------------------------------------------------------------------ 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
