Re: [JPP-Devel] Static object in RasterImageLayer class

2014-10-17 Thread edgar . soldin 
hey Jukka,

did you find time to doublecheck this change?

..ede

On 07.10.2014 15:25, edgar.sol...@web.de wrote:
> download snapshots r4064 and r4063.. load big rasters as sextante raster. 
> work a little with them and have a look at memory consumption, do the same 
> with the other snapshot. compare results ;)
> 
> ..ede
> 
> On 07.10.2014 12:02, Rahkonen Jukka (Tike) wrote:
>> Hi,
>>
>>  
>>
>> What difference this change could mean and how to test?
>>
>>  
>>
>> -Jukka Rahkonen-
>>
>>  
>>
>> Michael Michaud wrote:
>>
>>  
>>
>> Hi Alberto, Stefan,
>>
>> Just commit Alberto's patch (r4064)
>> please test,
>>
>> Michaël
>>
>> Dear OJ developers,
>>
>> after a break (of a few years...), I'm back on OJ development, still 
>> focussed on raster management and close to be ready to make available to the 
>> community an improved version of the "raster color editor", allowing the use 
>> of ramps, intervals, single colour values...
>>
>> Nevertheless, there is a design issue in the class
>>
>> org.openjump.core.rasterimage.RasterImageLayer
>>
>> that is giving me some problems. The point is that the Raster variable 
>> "rasterData" is static. As a consequence, it gets shared across all the 
>> instances of RasterImageLayer, making thinks a bit awkward. Do you see any 
>> problem in turning rasterData into non-static? I've tested this change, and 
>> everything appears to be working alright. You can find attached the modified 
>> RasterImageLayer.java
>>
>> Cheers
>> Alberto
>>
>>
>>
>> 
>> --
>>
>> Slashdot TV.  Videos for Nerds.  Stuff that Matters.
>>
>> 
>> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
>>
>>
>>
>>
>> ___
>>
>> Jump-pilot-devel mailing list
>>
>> Jump-pilot-devel@lists.sourceforge.net 
>> 
>>
>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>
>>  
>>
>>
>>
> 
> --
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> ___
> 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

Re: [JPP-Devel] Info tool for rasters

2014-10-17 Thread edgar . soldin 
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