[JPP-Devel] Raster Styler added to OJ core
Hi everyone. I added the Raster Styler tool (that creates symbologies for 1-banded rasters) to the OJ core (thanks also to Peppe for his help). The tool is made of several classes, you can see them in this package (and subpackages): org.openjump.core.rasterimage.styler The tool is handled as an Extension, so I added it to default-plugins.xml: extension org.openjump.core.rasterimage.styler.RasterStylesExtension /extension To use it, load a sextante raster, and click the Raster Styles... on the layer contextual menu. The tool also gives the option of showing the raster legend by clicking, in the contextual menu, the Legend item. Some TODOs: - improve the legend: now it's a horrible floating dialog, I'll try to turn it into a tree-like legend like the one used by vector layers; - translate the strings and include them in the main OJ language files. Now they're located in a separate file in the org.openjump.core.rasterimage.styler.resources package, and are English only; - add the option to save custom styles. Alberto -- ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Fwd: Fwd: NullPointerException Change Raster Image Properties
Peppe, just a quick note: point d) was actually due to a bug in the RasterImageLayer class. It should be fixed now. Alberto On 08/06/2015 8:22 AM, Giuseppe Aruta wrote: Hi Alberto, I gave a look on this weekend to your plugin. Personally I support your idea to integrate your plugin into OpenJUMP. These are my impressions and some brief considerations: a) Your raster styler (RS) has more advanced options than actual Raster color editor (RCE) integrated into OpenJUMP. Those avanced options can be summarized into 2 points: * RS has /ramp/, /user-defined intervals/ and /single/ values options while RCE supports basically only ramp. I started to integrate a possibility to have intervals on RCE but, looking at your code and plugin, I realized that you already made it (I was discovering the wheel again ) * RS provides a raster legend (what OJ currently need, in my opinion) while RCE doesn't. b) I gave a look on your RS source code and I realize that many RS classes are already integrated into OpenJUMP c) OpenJUMP RCE has some options that actually are missing on your RS (possibility to define an user range of values, invert color LUT), but those options are quite limited comparing to the advances of yur plugin (user-defined intervals and Legend, for instance) d) In your RS there is an option to manage nodata value which seems not to working As I wroye before, I vote to integrate your plugin into OpenJUMP, possibily as panel of Sextante Raster layer treeChange Raster Raster Image properties, as you suggested some months ago, substituting RCE. In the future we can work to move the extra options in RCE (see point c) to your plugin and deactivate one. RCE will survive anyhow under Raster menu Regarding point d), currently OpenJUMP handles nodata cells as transparent: no way to colourize them. This seems an advance for users: transparent-no data limit the area of analysis. On the other hand the possibility to colourized no-data cells with and out-of-order colour helps during some raster processes (for instance no data cells come out quickly if users apply Black/White colour schema and Red for no data). I would suggest to deactivate the nodata panel on your plugin until we find a solution. Best Regards Peppe -- ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Fwd: Fwd: NullPointerException Change Raster Image Properties
Hi everyone, as you might know, I've been working (lately not much, to be honest) on a new raster styler. If you reckon it could be useful, I would be pleased to share it with you. I was hoping to improving it a bit more, but I see that I keep procrastinating... The styler is an independent plugin (that I could easily incorporate into the core OJ if you want), you can find jar and source code here https://www.dropbox.com/sh/8ldfw5ue8v74awz/AAAiW0dJy3sznv4Crwm6geGZa?dl=0. I don't know if it can address all the needs of the OJ users, for example it's limited to 1-band rasters (1 bands rasters are handled as if they had only one band). In addition, it needs some testing. Let me know! Alberto On 05/06/2015 10:31 AM, Uwe Dalluege wrote: Hi Peppe, thank you for your long explanation of the problem. Sorry, but I am not able to decide which solution is the best. In the moment I do not use the RasterRaster Color Editor... with my students. This was only a test for me to decide, whether I can use it for my lessons. But it does not work correctly, you know. Please ask the OJ community which solution is the best. Have a nice weekend! Uwe Am 05.06.2015 um 10:22 schrieb Giuseppe Aruta: Hi everybody, this is a dialog between Uwe about the possibility to deactivate a plugin (RasterColor Editor) as it was substituded by the new Raster Image tree menuRaster Layer PropertiesRaster Color Editor Panel*. * My mistake thatthis dialog remained between Uwe and I*. * I would like the opinion of the other developers thanks Peppe -- Forwarded message -- From: *Giuseppe Aruta* giuseppe.ar...@gmail.com mailto:giuseppe.ar...@gmail.com Date: 2015-06-04 17:53 GMT+02:00 Subject: Re: [JPP-Devel] Fwd: NullPointerException Change Raster Image Properties To: uwe.dallu...@hcu-hamburg.de mailto:uwe.dallu...@hcu-hamburg.de Hi Uwe, I checked the code of **RasterRaster Color Editor* *(original plugin)*. *It seems that the new raster improvements broke its capability to restore original color scheme. And I don't want to make any change as those improvements have been applied to other classes/plugins, which have no described bugs. There are some solutions, I will describe them after a brief description of how and when to apply those plugins (sorry for the boringness and redundancy) *Actual situation:* _Single Band Raster_. to apply color schemas on these files, an user should use Raster Image tree menuRaster Layer PropertiesRaster Color Editor Panel* *(derived plugin)). It is possible to restore the Default Colors of a DEM (since these files have no default color schema, OJ adopted a standard B/Grays/W ramp). This derived plugin has also more options and color schemas that the original one. _Raster with multiple bands_. the original plugin affects (and affected) only the Band num. 0, which is usually the red channel on image files. The other channels (blue and green) are hidden. This behaviour has a few application, I feel, on raster analysis. On the other hand the option to restore default color doesn't work, because of the raster framework improvements. Alberto, if he reads these notes, can probably explain better than I do. The derived plugin is not activated if a multi-band raster is selected. *Possible solutions*: If you need to use the original plugin. Or you need to use false color schemas on multi-band rasters, there are a couple of option that we can discuss about: a) I can add modify the code in order that, when user choose Default color, the raster layer is reloaded with its original color schemas (RGB). In this case the original plugin is saved. b) I can add a plugin that divide RGB channels of an Image into separate single band rasters, than user can apply color schemas using the derived plugin. In this case I would deactivate the original plugin. I am waiting for your opinion about. Your experience with the students is important. In my opinion I woulddeactivate the original plugin in order not to confuse users. Best regards Peppe 2015-06-01 14:24 GMT+02:00 Uwe Dalluege uwe.dallu...@hcu-hamburg.de mailto:uwe.dallu...@hcu-hamburg.de: ... I hope you will have nice free days! uwe Am 01.06.2015 tel:01.06.2015 um 13:51 schrieb Giuseppe Aruta: Hi Uwe, Thanks for hte test.I was aware of that bug. It was corrected on Raster Layer PropertiesRaster Color Editor layer menu but not on the RasterRaster Color Editor one. I am out for a couples of days. I will give a look when I will be back home Best regards Peppe 2015-06-01 11:16 GMT+02:00 Uwe Dalluege uwe.dallu...@hcu-hamburg.de mailto:uwe.dallu...@hcu-hamburg.de mailto:uwe.dallu...@hcu-hamburg.de mailto:uwe.dallu...@hcu-hamburg.de: Hi Peppe, sorry for answering so late but I was on holiday :-) I have some problems with RasterRaster Color Editor...
Re: [JPP-Devel] Sextante Raster Image; Raster Layer Info; Coordinate out of bounds!
Hi everyone! It appears to me that the issue is due to the fact that OpenJUMPSextanteRasterLayer and GridExtent assume X and Y cell sizes to be equal. This is a problem when, like with this very TIFF, the two sizes differ, and the method GridExten#recalculateNXAndNY() calculates a wrong row count (because it uses the x cell size, the only one it knows, instead of the y cell size). In practice, it calculates 778 rows instead of 777. Using the right y cell size would lead to a correct result. I could try to amend the OpenJUMPSextanteRasterLayer (up to ISextanteLayer) and make them capable of handling two different cell sizes for x, and y (to be honest I don't know how many other classes will be involved...). What do you reckon? Alberto -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] 2 bugs on Sextante Raster Image layer
Hey Giuseppe, sorry I didn't take care of them earlier... They should be fixed now, I committed the changes on SF. Let me know Alberto On 07/04/2015 9:22 AM, Giuseppe Aruta wrote: Hi Alberto, a month ago I opened 2 bug tickets about Sextante RasterImageLayer. a)https://sourceforge.net/p/jump-pilot/bugs/391/ The alpha transparency doesn't work anymore b) https://sourceforge.net/p/jump-pilot/bugs/392/ and also the single color transparency is off I checked that these bugs were introduced after OpenJUMP-20150110-r4259, by the time you upgraded the new raster framework. You should give a look. Peppe -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Questions about how OJ handle TIFF
Peppe, it appears to me that the file dem.tif has no information about the nodata value. I've checked using QGIS (it says: no data value not defined) and the AWare Systems AsTiffTagViewer http://www.awaresystems.be/imaging/tiff/astifftagviewer.html (it doesn't show the 42133 tag, that should store the nodata value). This is why the 0 value is considered as a valid elevation number in OJ and QGIS. Until we implement a tool in OJ allowing the user to set the nodata tiff tag when it's missing, I think the only solution would be using gdal_translate -a_nodata, as Jukka suggested. Alberto On 02/03/2015 20:36 PM, Giuseppe Aruta wrote: Hi Alberto, thanks for your replay. I attached the file to this mail. Peppe 2015-03-02 11:28 GMT+01:00 Alberto De Luca - GeA alberto.del...@geomaticaeambiente.com mailto:alberto.del...@geomaticaeambiente.com: Dear all, sorry for the late reply (especially sorry to Peppe), I presently do not have much time to dedicate to OJ development. About TIFFs and nodata: the org.openjump.core.rasterimage.TiffTags class has a static method (readMetadata()) that canalso read the noData value (as the non-standard tag 42113). There is still no support for nodata values stored in the .AUX file. When no 42113 tag is found, the nodata value is set to -3.40282346639e+038, which I believe is derived from esri software (this can clearly be changed). The nodata value is then accessible through RasterImageLayer#getNoDataValue() method. I see from Peppe's mail that something is not working as expected. Peppe, can you pass me the DEM where the actual nodata value (0) is replaced by the 3.4...+38 value, I'll try to see if I can fix it. Alberto -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net mailto:Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Questions about how OJ handle TIFF
Dear all, sorry for the late reply (especially sorry to Peppe), I presently do not have much time to dedicate to OJ development. About TIFFs and nodata: the org.openjump.core.rasterimage.TiffTags class has a static method (readMetadata()) that canalso read the noData value (as the non-standard tag 42113). There is still no support for nodata values stored in the .AUX file. When no 42113 tag is found, the nodata value is set to -3.40282346639e+038, which I believe is derived from esri software (this can clearly be changed). The nodata value is then accessible through RasterImageLayer#getNoDataValue() method. I see from Peppe's mail that something is not working as expected. Peppe, can you pass me the DEM where the actual nodata value (0) is replaced by the 3.4...+38 value, I'll try to see if I can fix it. Alberto -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] bugs on Raster Image layers
Hey Peppe, about GIFs: I discovered (late, my bad) that GIFs use the IndexColorModel. I therefore adjusted a couple of methods (in RasterImageLayer and ExtractSelectedPartOfImage) to account for this type of images. It should be ok now, have a look at my latest commit. a) FLT/ASC: yes, I've added the methods to write these formats, although they could be improved in terms of efficiency and implementation, so if you have better code it's very welcome! XYZ ASCII shouldn't be a problem to implement, while Surfer grid is a format I don't know. b) I sometimes find the RasterPixel inspector very handy, because using it is very immediate: you click and see the pixel value right there, without the need to look at the Feature info dialog... So I personally wouldn't ditch it. Maybe it'd need a different icon, to distinguish it from the Info tool? c) Sure I agree with including the symbology plugin into OpenJUMP. I believe it would then be also nice to add support for multi-band rasters (I'm thinking for instance of Landsat images and false-colour composites...)... And saving the raster symbology into the project would be awesome... Till soon Alberto On 01/02/2015 12:24 PM, Giuseppe Aruta wrote: Hi Alberto, It seems that everything is going fine, except, as you wrote, loading gif file. I took time to see the other job you did on OJ raster capabilities a) some method to save .FLT and .ASC files. I was working around, with my limited java skills, to a similar project. It is my intention to add an Export to grid plugin to save to ASC, FLT, GRD (Surfer grid file 6) and XYZ table file. The latter two options (GRD and XYZ) came out from a couple of costumers who had to work with those two types of file. I have the code for this plugin that I wanted to add in the next days - I am glad to discuss with you, if you have other ideas about. - and find a common solution b) Now Feature Info Tool also shows raster cell value in a R panel. We should change the name of the plugin to Info Tool. This option makes RasterPixel Inspection tool obsolete. I think we can save this plugin, that I added two years ago, and transform as a ArcGIS-like Pixel Inspection tool to query individual or areas of cells which values can be saved in a vector layer. Even in this case I have a partial solution (individual cells) for this plugin and your (or others) opinion is welcome. c) Raster ColorModels. I gave a look to your RasterStyles and RasterLegend plugins. These are definitely more efficient than Raster Color Editor (RasterColorEditor.class and package) embedded into OJ (Legend, pixel transparency, etc). I think we talked about few weeks ago - and I changed my mind. I feel that we can add your plugin, if you agree, into OJ code. As you wrote, It could be as panel of ChangeRasterImagePropertiesPlugIn, Hiding RasterColorEditorPanel and adding an enablkecheck to activate it only for single band raster. In this case I can help you adding more color schemas (see the one I embedded into RasterColorEditorPanel). Regarding RasterColorEditor.class, we can save the access under Raster menu, if any user are using it. In any case there are no problems of compatibility as ColorModels are not saved into OpenJUMP project files. I can go on for more. I checked AdBToolbox and GvSIG code and there are many opportunities to extend OJ raster capabilities and I am really glad that you decide to collaborate with your java competence and interests. Alberto, if you want, you can write me personally in Italian, for any kind of details and information. Best regards Peppe 2015-01-29 11:28 GMT+01:00 Alberto De Luca - GeA alberto.del...@geomaticaeambiente.com mailto:alberto.del...@geomaticaeambiente.com: Hey Peppe, I've commited some changes that should fix most of the issues. I don't know how to solve the problem of the GIF files being read as monoband: it's something related to javax.imageio classes, I'lll see what I can do. Alberto On 28/01/2015 16:16 PM, Giuseppe Aruta wrote: Hi Alberto, I tested this new OpenJump.jar, using RasterImage Layer class. I did a large test to check also the other file formats. I listed below the results *Loading multiband files: * 1) JPG, OK 2) PNG, OK 3) TIF, OK 4) GIF. Only one band is loaded, It seems to me band 0 and the image is displayed as B/W *Loading monoband raster* 1) TIF, OK 2) ASC, OK 3) FLT, OK 4) PNG, OK *Saving multiband files as TIF* 1) save JPG to TIF Null point exception java.lang.NullPointerException at org.openjump.core.ui.plugin.layer.pirolraster.SaveRasterImageAsImagePlugIn.execute(SaveRasterImageAsImagePlugIn.java:131) 2) save PNG to TIFF, OK 3) Save TIF to TIF, OK 4) Save GIF to TIF, OK (Saved file is monoband , as the displayed) *Saving monoband as TIF* 1) TIF, OK 2) ASC, OK 3) FLT, OK 4
Re: [JPP-Devel] bugs on Raster Image layers
Hey Peppe, I've commited some changes that should fix most of the issues. I don't know how to solve the problem of the GIF files being read as monoband: it's something related to javax.imageio classes, I'lll see what I can do. Alberto On 28/01/2015 16:16 PM, Giuseppe Aruta wrote: Hi Alberto, I tested this new OpenJump.jar, using RasterImage Layer class. I did a large test to check also the other file formats. I listed below the results *Loading multiband files: * 1) JPG, OK 2) PNG, OK 3) TIF, OK 4) GIF. Only one band is loaded, It seems to me band 0 and the image is displayed as B/W *Loading monoband raster* 1) TIF, OK 2) ASC, OK 3) FLT, OK 4) PNG, OK *Saving multiband files as TIF* 1) save JPG to TIF Null point exception java.lang.NullPointerException at org.openjump.core.ui.plugin.layer.pirolraster.SaveRasterImageAsImagePlugIn.execute(SaveRasterImageAsImagePlugIn.java:131) 2) save PNG to TIFF, OK 3) Save TIF to TIF, OK 4) Save GIF to TIF, OK (Saved file is monoband , as the displayed) *Saving monoband as TIF* 1) TIF, OK 2) ASC, OK 3) FLT, OK 4) PNG, OK *Extract part of selected image (monoband files)* 1) TIF, OK 2) ASC, OK 3) FLT, OK 4) PNG, OK *Extract part of selected image (multiband files)* I had problems. All extractions failed with a error message. I listed below all these messages 1) *JPG,* java.lang.NullPointerException at org.openjump.core.rasterimage.RasterImageIO.writeImage(RasterImageIO.java:664) at org.openjump.core.ui.plugin.layer.pirolraster.ExtractSelectedPartOfImage.execute(ExtractSelectedPartOfImage.java:89) 2) *PNG,* Javax.media.jai.util.ImagingException: All factories fail for the operation scale at javax.media.jai.OperationRegistry.invokeFactory(OperationRegistry.java:1687) at javax.media.jai.ThreadSafeOperationRegistry.invokeFactory(ThreadSafeOperationRegistry.java:473) at javax.media.jai.registry.RIFRegistry.create(RIFRegistry.java:332) at javax.media.jai.RenderedOp.createInstance(RenderedOp.java:819) at javax.media.jai.RenderedOp.createRendering(RenderedOp.java:867) at javax.media.jai.RenderedOp.getWidth(RenderedOp.java:2179) at org.openjump.core.rasterimage.TiffUtils.readImage(TiffUtils.java:85) at org.openjump.core.rasterimage.RasterImageIO.loadImage(RasterImageIO.java:131) at org.openjump.core.ui.plugin.layer.pirolraster.ExtractSelectedPartOfImage.execute(ExtractSelectedPartOfImage.java:102) 3) *TIF,*java.lang.NullPointerException at org.openjump.core.ui.plugin.layer.pirolraster.ExtractSelectedPartOfImage.execute(ExtractSelectedPartOfImage.java:90) at com.vividsolutions.jump.workbench.plugin.AbstractPlugIn$1.actionPerformed(AbstractPlugIn.java:342) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2018) at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2341) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259) at javax.swing.AbstractButton.doClick(AbstractButton.java:376) 4)***GIF. *javax.media.jai.util.ImagingException: All factories fail for the operation scale at javax.media.jai.OperationRegistry.invokeFactory(OperationRegistry.java:1687) at javax.media.jai.ThreadSafeOperationRegistry.invokeFactory(ThreadSafeOperationRegistry.java:473) at javax.media.jai.registry.RIFRegistry.create(RIFRegistry.java:332) at javax.media.jai.RenderedOp.createInstance(RenderedOp.java:819) at javax.media.jai.RenderedOp.createRendering(RenderedOp.java:867) at javax.media.jai.RenderedOp.getWidth(RenderedOp.java:2179) at org.openjump.core.rasterimage.TiffUtils.readImage(TiffUtils.java:85) at org.openjump.core.rasterimage.RasterImageIO.loadImage(RasterImageIO.java:131) at org.openjump.core.ui.plugin.layer.pirolraster.ExtractSelectedPartOfImage.execute(ExtractSelectedPartOfImage.java:102) Loading, saving extracting parts of monoband raster is fine. Problems come with multiband files. Peppe 2015-01-28 12:06 GMT+01:00 Alberto De Luca - GeA alberto.del...@geomaticaeambiente.com mailto:alberto.del...@geomaticaeambiente.com: Peppe, I fixed an issue related to single-band PNGs. With regards to JPGs, I can load with no problem in my Windows machine all the samples you attached to your mail. Nevertheless, the problem you see should be related to JAI: in snapshot 4090 the read operation was made using ImageIO.read, while in snapshot 4283 is made using JAI.create(fileload, ...). I've now modified the code so that ImageIO.read() is used first, and JAI.create() only as a fallback if ImageIO fails. The weird thing is that in r4283 JAI is however used to load TIFF files, but it appears that you can load them no problem... Since I cannot reproduce your error, before committing I'd like you to test these changes. Could you please download
Re: [JPP-Devel] bugs on Raster Image layers
Peppe, I fixed an issue related to single-band PNGs. With regards to JPGs, I can load with no problem in my Windows machine all the samples you attached to your mail. Nevertheless, the problem you see should be related to JAI: in snapshot 4090 the read operation was made using ImageIO.read, while in snapshot 4283 is made using JAI.create(fileload, ...). I've now modified the code so that ImageIO.read() is used first, and JAI.create() only as a fallback if ImageIO fails. The weird thing is that in r4283 JAI is however used to load TIFF files, but it appears that you can load them no problem... Since I cannot reproduce your error, before committing I'd like you to test these changes. Could you please download this https://www.dropbox.com/s/fexjyucup49hihn/OpenJUMP-0.0.0-rnull.jar?dl=0 OpenJUMP.jar, replace it to the one you have in snapshot 4283 and tell me how it behaves? Thanks Alberto -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] bugs on Raster Image layers
Hi Peppe, I've managed to track down the cause of bug #386: ExtractSelectedPartOfImage works fine with TIFF or PNG raster files but it fails to work whenever I try to extract a part of ASC or FLT monoband raster.. With regards to bug #387, what do you mean with RasterImageLayer class seems not working with JPG files? With the latest snapshot (r4283) I can open and display the bologna1_4326.jpg image you provided some weeks ago, and some other jpg/png files I tested. Can you pass me some non working jpg and png files? Cheers Alberto On 26/01/2015 8:33 AM, Giuseppe Aruta wrote: @ Alberto Last week I tested the new Raster Image Layer framework and I found a couple of bugs. I posted them as bug tickets 386 and 387 on http://sourceforge.net/p/jump-pilot/bugs/?source=navbar. Can you please give a look? If you need more information I will write you in detail thanks Peppe -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] OJ and rasters, again
Hi everyone, I committed the changes regarding Sextante Raster Image handling to SVN. @Peppe You're right, the sextante raster image, in the way I was seeing it, was a single-band image to be used in data processing (overlay, raster combination, hydrology...) where normally only one band is used at time... No worries, I already modified the code to account for multi-band images, so now 3-bands JPGs and TIFFs should be visualized properly. The multi-band image support is not complete though: ideally, when an image as more than 1 band, the user should be able to choose what band to use in each of the three RGB channels. This would be especially useful whit images having more than 3 bands. We will work on that. Related to this: the Raster Style plugin for the moment only works on a single band at the time, so it's useful only for single-band images. Do you want us to merge it with the Change Raster Image Properties plugin, or is it better to keep it as an external plugin? Yet to be done: support for statistics saved as a tiff tag. Alberto On 09/01/2015 15:03 PM, Giuseppe Aruta wrote: Hi Alberto, the file I attached to the mail is not a B/W file but a coloured RGB orthophoto. The question is that the new modified Sextante RasterImage displays only the 1st band (the red one). And it happens with all the RGB image files I tried to open (I attached another sample, a JPG from a screenshot of WMS Geoportale Nazionale). I tested the RasterStyles.jar, the symbology and Legend. I works very nice. I think that this should be a part of OJ core ( I saw also the depency to othre classes: org/openjump/core/rasterimage/RasterSymbology), thanks Peppe 2015-01-09 11:23 GMT+01:00 Alberto De Luca - GeA alberto.del...@geomaticaeambiente.com mailto:alberto.del...@geomaticaeambiente.com: Hi everyone! @Jukka Statistics inside the GeoTIFF, as a TAG: I hadn't considered that, but it shouldn't be a problem reading them. I found some documentation in this page http://www.awaresystems.be/imaging/tiff/tifftags/gdal_metadata.html, is it correct if I assume that other items (such as min value, max value...) are just stored as other elements using the same keys used in the aux.xml file , e.g.: ... Item name=STATISTICS_MAXIMUM2775/Item Item name=STATISTICS_MINIMUM540.4/Item ... @Ede My SF account name is bertazza, and yes, testing and debugging here is paramount, the number of classes/methods where we put our hands is worrying... @Giuseppe Thank you for letting me know what you have been working on. And I'll try to avoid duplicates in terms of classes related to raster metadata. We added the two RasterStyle and Legend classes to try to consolidate symbology management. We also implemented a plugin called Raster Styles. In the OJ build that I gave you for testing, the plugin is available via the raster context menu: right click on the raster name in the layer panel, and select Raster Styles. You should be able to change raster symbology: interval, ramps and single values are available. The plugin is not complete nor optimized yet, but you can have a feel of what we're trying to do. Ubuntu problem: on windows 8 I could open your TIF file without problems, I see it as nice B/W orthophoto. I wonder what could be different in Linux. Do you have any idea about where the origin of the problem could be, maybe JAI? I will check the problem with Extract part of image, thank you for telling me. Alberto On 09/01/2015 10:41 AM, edgar.sol...@web.de mailto:edgar.sol...@web.de wrote: On 09.01.2015 10:09, Alberto De Luca - GeA wrote: Jukka, - raster readers: I agree that tidying up a bit would be good, but honestly I'd need to check them all before recommending anything; no haste there, let's integrate your changes and we'll clean up after SNIP - With regards to the timing to contribute the changes to OJ, unless big bugs are found or substantial new features are required, they shouldn't take long. Since we've worked on the source code from OJ 1.7.1-r4004, we'd need to check if everything is ok with the most recent source code, but I don't see it as a lengthy operation. to make it available to a broader test user group i'd like to have it committed soon, so users can stumble over problems when using the snapshots ;) what is yoursf.net http://sf.net account name? ..ede -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation
Re: [JPP-Devel] OJ and rasters, again
Jukka,
- raster readers: I agree that tidying up a bit would be good, but
honestly I'd need to check them all before recommending anything;
- the .aux.xml file should be created in the same folder where the tiff
file reside, right beside it. The source code is something like:
File auxXmlFile = new File(imageFile.getParent(), imageFile.getName() +
.aux.xml);
if(auxXmlFile.exists()) {
// Read...
return;
}
// Create...
- The aux.xml file structures for the files created by gdal and the ones
created by OJ should be the same, even if with different sets of
information. At the bottom of this email you find the content of the
files generated by GDAL and OJ on the same TIFF.
- With regards to the timing to contribute the changes to OJ, unless big
bugs are found or substantial new features are required, they shouldn't
take long. Since we've worked on the source code from OJ 1.7.1-r4004,
we'd need to check if everything is ok with the most recent source code,
but I don't see it as a lengthy operation.
Till soon
Alberto
GDAL:
PAMDataset
PAMRasterBand band=1
Metadata
MDI key=COLOR_TABLE_RULE_RGB_0-4.320724e+003 -2.904333e+003 0
191 191 0 255 0/MDI
MDI key=COLOR_TABLE_RULE_RGB_1-2.904333e+003 -1.487941e+003 0
255 0 255 255 0/MDI
MDI key=COLOR_TABLE_RULE_RGB_2-1.487941e+003 -7.155029e+001
255 255 0 255 127 0/MDI
MDI key=COLOR_TABLE_RULE_RGB_3-7.155029e+001 1.344841e+003
255 127 0 191 127 63/MDI
MDI key=COLOR_TABLE_RULE_RGB_41.344841e+003 2.761232e+003 191
127 63 20 20 20/MDI
MDI key=COLOR_TABLE_RULES_COUNT5/MDI
MDI key=STATISTICS_MAXIMUM2775.2758789063/MDI
MDI key=STATISTICS_MEAN540.42157279456/MDI
MDI key=STATISTICS_MINIMUM-4.3070001602173/MDI
MDI key=STATISTICS_STDDEV580.26974362042/MDI
/Metadata
/PAMRasterBand
/PAMDataset
OpenJUMP:
?xml version=1.0 encoding=UTF-8 standalone=no?
PAMDataset
PAMRasterBand band=1
Metadata
MDI key=STATISTICS_MINIMUM-4.307000160217285/MDI
MDI key=STATISTICS_MAXIMUM2775.27587890625/MDI
MDI key=STATISTICS_MEAN540.421572794561/MDI
MDI key=STATISTICS_STDDEV580.2697436204171/MDI
/Metadata
/PAMRasterBand
/PAMDataset
On 08/01/2015 19:45 PM, Rahkonen Jukka (MML) wrote:
Hi,
I made a quick test and my feeling was pretty good. I have some questions for
Alberto:
- We have an amazing number of raster readers. Can you recommend which driver
behaves best, and do you think that we could drop out some others for making
life easier for OpenJUMP users?
- I noticed the lag before first opening of the image but I did not see the
aux.xml file anywhere after this process. Where in the file system it is
written?
- Does the aux.xml file have the same structure as the one created with
gdalinfo -stats?
Once the image is opened all pan/zoom operations are for sure fast enough for
all digitizing work. I made a few tests also by combining more images (400
MB each) into the same Image layer and they worked very well together. I
think that this is gonna be good.
-Jukka Rahkonen-
edgar.soldin wrote:
Jukka,
can you please have a look at this and give your opinion? if you generally
agree that it goes into the right direction, i'd like to give Alberto svn
access.
Alberto: what are your plans/timeline on contributing the changes to OJ?
..ede
On 08.01.2015 09:16, Alberto De Luca - GeA wrote:
Hi everyone.
We've tried to add some more raster-handling features to OpenJUMP, in detail:
- Overview handling (read only) for TIFF files. External (.ovr file) and
internal overviews are now handled to speed up reading/displaying time. The
.ovr file can be created using GDAL or ArcMap. In addition, when neither
external nor internal overviews are found, decimation (subsampling) is used.
When only a portion of the image is needed for display, only that part is
loaded. Note that when only a portion of an image is loaded, there are two
sets of image metadata (columns, rows, envelope...), one for the image
actually loaded, the other for the whole image. You therefore will find two
sets of getters in RasterImageLayer, one for the actual image, one for the
whole image.
- Raster statistics for TIFF files: they are calculated just once, and then
written in an .aux.xml file. For display purposes the min and max cell
values need to be known, and clearly it's better to look for them just once.
For big rasters ( 500 MB) calculating statistics takes a few seconds, but I
still haven't added a Pane with a message: Please wait while calculating
statistics, so be patient).
Now memory consumption when loading large TIFF files is always reasonable,
and when the .aux.xml and .ovr files are present, reading even a big (1 GB)
raster is almost immediate.
Again, we had to modify several classes, and we didn't feel like pushing
them in SVN without your previous consent
Re: [JPP-Devel] OJ and rasters, again
Hi everyone! @Jukka Statistics inside the GeoTIFF, as a TAG: I hadn't considered that, but it shouldn't be a problem reading them. I found some documentation in this page http://www.awaresystems.be/imaging/tiff/tifftags/gdal_metadata.html, is it correct if I assume that other items (such as min value, max value...) are just stored as other elements using the same keys used in the aux.xml file , e.g.: ... Item name=STATISTICS_MAXIMUM2775/Item Item name=STATISTICS_MINIMUM540.4/Item ... @Ede My SF account name is bertazza, and yes, testing and debugging here is paramount, the number of classes/methods where we put our hands is worrying... @Giuseppe Thank you for letting me know what you have been working on. And I'll try to avoid duplicates in terms of classes related to raster metadata. We added the two RasterStyle and Legend classes to try to consolidate symbology management. We also implemented a plugin called Raster Styles. In the OJ build that I gave you for testing, the plugin is available via the raster context menu: right click on the raster name in the layer panel, and select Raster Styles. You should be able to change raster symbology: interval, ramps and single values are available. The plugin is not complete nor optimized yet, but you can have a feel of what we're trying to do. Ubuntu problem: on windows 8 I could open your TIF file without problems, I see it as nice B/W orthophoto. I wonder what could be different in Linux. Do you have any idea about where the origin of the problem could be, maybe JAI? I will check the problem with Extract part of image, thank you for telling me. Alberto On 09/01/2015 10:41 AM, edgar.sol...@web.de wrote: On 09.01.2015 10:09, Alberto De Luca - GeA wrote: Jukka, - raster readers: I agree that tidying up a bit would be good, but honestly I'd need to check them all before recommending anything; no haste there, let's integrate your changes and we'll clean up after SNIP - With regards to the timing to contribute the changes to OJ, unless big bugs are found or substantial new features are required, they shouldn't take long. Since we've worked on the source code from OJ 1.7.1-r4004, we'd need to check if everything is ok with the most recent source code, but I don't see it as a lengthy operation. to make it available to a broader test user group i'd like to have it committed soon, so users can stumble over problems when using the snapshots ;) what is your sf.net account name? ..ede -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] OJ and rasters, again
Hi everyone. We've tried to add some more raster-handling features to OpenJUMP, in detail: - Overview handling (read only) for TIFF files. External (.ovr file) and internal overviews are now handled to speed up reading/displaying time. The .ovr file can be created using GDAL or ArcMap. In addition, when neither external nor internal overviews are found, decimation (subsampling) is used. When only a portion of the image is needed for display, only that part is loaded. Note that when only a portion of an image is loaded, there are two sets of image metadata (columns, rows, envelope...), one for the image actually loaded, the other for the whole image. You therefore will find two sets of getters in RasterImageLayer, one for the actual image, one for the whole image. - Raster statistics for TIFF files: they are calculated just once, and then written in an .aux.xml file. For display purposes the min and max cell values need to be known, and clearly it's better to look for them just once. For big rasters ( 500 MB) calculating statistics takes a few seconds, but I still haven't added a Pane with a message: Please wait while calculating statistics, so be patient). Now memory consumption when loading large TIFF files is always reasonable, and when the .aux.xml and .ovr files are present, reading even a big (1 GB) raster is almost immediate. Again, we had to modify several classes, and we didn't feel like pushing them in SVN without your previous consent. Therefore, just to test you can download this OJ temporary build https://www.dropbox.com/s/lqmlkfprnoopfi1/OpenJUMP-1.7.1-r4004-CORE.7z?dl=0 (built against OJ 1.7) and you can download the modified sources here https://www.dropbox.com/s/sxqo96rh8jtan0k/Modified.7z?dl=0. Let us know Alberto On 26/11/2014 9:52 AM, Rahkonen Jukka (Tike) wrote: Hi, http://docs.geoserver.org/stable/en/user/production/data.html I believe that most Geoserver users are creating overviews with gdaladdo but the document mentions that there is also the OverviewsEmbedded command included in Geotools. I use external overviews myself with Mapserver but there are pros and cons + External overviews can be created for all formats + When image goes to archive external overviews can be deleted for saving space. Removing internal overviews from tiff file does make the file any smaller without complete rewrite. + It is easier to experiment with different overview resampling methods because not satisfying result can just be deleted. - Tiff + external overviews take a bit more disk space than tiff with internal overviews. - Some programs support internal but not external overviews. Image mosaic in Geoserver is one such example. In server use overviews are a must. About 30 % more disk space is needed but that's nothing compared to improved speed. Overviews can also be compressed (LZW or deflate for topographic maps, --config COMPRESS_OVERVIEW JPEG --config PHOTOMETRIC_OVERVIEW YCBCR for aerial images) which is reducing the size very much. For OpenJUMP usage my wish list is - Ability to utilize existing overviews, ideally both external and internal, and also compressed - Create overviews with java from OJ. Some programs ask user Image does not have overviews. Do you want to create them? As you can see from the gdaladdo page there are lots of options for creating overviews. For OJ perhaps the most simple recipe would do: external, uncompressed overviews with so many levels that at the lowest resolution the image fits into about 200x200 pixels. It is also possible improve the speed in small scales at least with some type of tiffs even without overviews. If the tiff file is written as stripes it is possible to read for example only every 10th or 50th stripe, depending on the required output resolution. Probably that is not possible or at least not so efficient with tiled tiffs. -Jukka Rahkonen- alberto deluca wrote: Hi everyone. overviews sound interesting to me. I don't know either if there exists a standard, but the GDAL way to go sure is the more widely accepted/supported. I've had a look at the GDALADDO tool: overviews can be internal to the GeoTIFF or external (.ovr file). The latter is the option used by esri's ArcMap. Personally I don't like either the idea of modifying the original tif file. There might be some GeoServer or GeoTools code that creates overviews, I'll try to find out something more. I hope reading/writing the overviews won't imply that we will need to dump the JAI image drivers for something totally new... Alberto -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE
Re: [JPP-Devel] Info tool for rasters
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 DataBuffererror. 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
[JPP-Devel] Info tool for rasters
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. 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
Re: [JPP-Devel] Static object in RasterImageLayer class
Hi Michaël, I've done some tests on memory usage and, as expected, the memory footprint increases if the Raster variable is non-static. I tried loading 4 rasters, 2 esri ASCII grid, 1 esri FLT grid and 1 tif, all of them having 4728 columns and 5815 rows. The memory used by OJ went from 1.1 GB up to 1.3 GB. By the way, I've noticed also another static variable in RasterImageLayer that apparently shouldn't be so: noDataValue, maybe I should spend some time checking this aspect too. And, still need to check the ReferencedImagesLayer stuff. I'll get back to you soon. Alberto On 07/10/2014 08:39, 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=160591471iu=/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=154622311iu=/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=154622311iu=/4140/ostg.clktrk___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] Static object in RasterImageLayer class
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 RasterImageLayer.7z Description: Binary data -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471iu=/4140/ostg.clktrk___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Enhancement of raster support: proposed developments
Stefan, ok, I believe I managed to check out a copy of the source code from SVN and set up a NetBeans project (awesome!). With regards to your questions: we could definitely check if OpenJUMP works with the new Sextante releases. I have to say though that I don't know much about the Framework you ported from Sextante. But anyway I don't see why we shouldn't take the time to check if there is something new to be ported to it. The classes involved are the ones contained inside the package org.openjump.core.rasterimage.sextante? Alberto On 18/01/2012 17:57, Stefan Steiniger wrote: Hi Alberto, well... for SVN we have just the usual rules as for other versioning tools. Most important is updating before commits are done, that submitted code must work (no missing files or libraries), and that commits are commented. Btw. the changelog.txt should be updated too when commits are made that: - contain new functionality - fix a bug - change/alter existing code or in summary: everything that maybe of importance to/influences the work of other developers. So for instance updates of language files do not go into changelog, or a change of a variable name, or smaller refactoring within a class, or adding a new method within a class when you working on functionality. So - something that would be important to tell to people in releases for instance. All commits are send to our svn log email list, to which you can subscribe to see what is going on. https://lists.sourceforge.net/lists/listinfo/jump-pilot-svn-notify Actually I have a question. I am not sure how much you would work with the Framework I ported from Sextante and its Toolbox capabilities. But, I have seen in Victors blog [1] that he made some larger changes to the Sextante framework. And I wonder if you would have time to a) test if OpenJUMP works with newer Sextante releases (i.e. our interface works), b) if we should port this changes to the raster framework (if there are some) to OpenJUMP as well. Though - if you think your work is not concerned by changes on the Sextante side or you have no time for such things at all, then maybe some day I should check compatibility. cheers, stefan [1] http://sextantegis.blogspot.com/2011/04/big-changes-in-sextante.html see in particular what he writes about: Algorithm Providers On 18/01/2012 1:09 AM, Alberto De Luca - GeA wrote: Michaël, thank you for your reply. As you said I'm fairly familiar with the openjump basecode (well, with some parts of it at least!) but I've never used sourceforge/svn before (we mostly use Mercurial), so I thought maybe there was something to know about it... Anyway, I'll bother the community every time I have a doubt/question :P Thank you Alberto PS: I will send you a PM with instructions about the AdB-ToolBox activation code On 18/01/2012 00:09, Michaël Michaud wrote: Hi Alberto, You now have full access to the svn We have not much guidelines. I suppose you know our wiki and its pages dedicated to developpers : http://sourceforge.net/apps/mediawiki/jump-pilot/index.php?title=Developer_Documentation_and_HowTo You probably also know how packages are organized, with the original jump com package and the new openjump org package, both being organized in a similar way (more or less), with most new plugins going now to org.openjump.core.ui.plugin.*. Some parts have been let in separate packages, but it is not encouraged. We have also a (few years old) xml-based mechanism to activate/deactivate new plugins (default-plugins.xml file). I don't know what can be useful to you as you probably already knows how OpenJUMP is organized quite well. The best is to share your ideas and your plans so that any experienced programmers and/or users can give you some hints, ideas or guidance. Regards Michaël PS - I never could test AdbToolbox because of the activation code needed. I wrote to the webmaster and get a user name, a password and a tax code, but could never get an activation code. I would be pleased if you could help me to get this code (if AdbToolbox usage is not restricted). Le 17/01/2012 09:09, Alberto De Luca - GeA a écrit : Hey Stefan and Michael, thank you for your enthusiasm and trust! Indeed I am still working on AdB-ToolBox, and a new version is expected in the next few months, with new tools for hydraulics analysis. My sourceforge account name is bertazza. Looking forth to start submitting some new raster functions! By the way, have you got any particular guideline before I start committing code to sourceforge? Thanks guys Alberto On 13/01/2012 22:26, Stefan Steiniger wrote: I did not see your name in the list of OJ authorized commiters. Do you want to give me or Stefan your sourceforge user name so that we can add it to committer list ? thanks Michael, didn't thought about this. Your welcome Alberto to commit directly ;) stefan Michaël
Re: [JPP-Devel] Enhancement of raster support: proposed developments
Michaël, thank you for your reply. As you said I'm fairly familiar with the openjump basecode (well, with some parts of it at least!) but I've never used sourceforge/svn before (we mostly use Mercurial), so I thought maybe there was something to know about it... Anyway, I'll bother the community every time I have a doubt/question :P Thank you Alberto PS: I will send you a PM with instructions about the AdB-ToolBox activation code On 18/01/2012 00:09, Michaël Michaud wrote: Hi Alberto, You now have full access to the svn We have not much guidelines. I suppose you know our wiki and its pages dedicated to developpers : http://sourceforge.net/apps/mediawiki/jump-pilot/index.php?title=Developer_Documentation_and_HowTo You probably also know how packages are organized, with the original jump com package and the new openjump org package, both being organized in a similar way (more or less), with most new plugins going now to org.openjump.core.ui.plugin.*. Some parts have been let in separate packages, but it is not encouraged. We have also a (few years old) xml-based mechanism to activate/deactivate new plugins (default-plugins.xml file). I don't know what can be useful to you as you probably already knows how OpenJUMP is organized quite well. The best is to share your ideas and your plans so that any experienced programmers and/or users can give you some hints, ideas or guidance. Regards Michaël PS - I never could test AdbToolbox because of the activation code needed. I wrote to the webmaster and get a user name, a password and a tax code, but could never get an activation code. I would be pleased if you could help me to get this code (if AdbToolbox usage is not restricted). Le 17/01/2012 09:09, Alberto De Luca - GeA a écrit : Hey Stefan and Michael, thank you for your enthusiasm and trust! Indeed I am still working on AdB-ToolBox, and a new version is expected in the next few months, with new tools for hydraulics analysis. My sourceforge account name is bertazza. Looking forth to start submitting some new raster functions! By the way, have you got any particular guideline before I start committing code to sourceforge? Thanks guys Alberto On 13/01/2012 22:26, Stefan Steiniger wrote: I did not see your name in the list of OJ authorized commiters. Do you want to give me or Stefan your sourceforge user name so that we can add it to committer list ? thanks Michael, didn't thought about this. Your welcome Alberto to commit directly ;) stefan Michaël -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Enhancement of raster support: proposed developments
Hey Stefan and Michael, thank you for your enthusiasm and trust! Indeed I am still working on AdB-ToolBox, and a new version is expected in the next few months, with new tools for hydraulics analysis. My sourceforge account name is bertazza. Looking forth to start submitting some new raster functions! By the way, have you got any particular guideline before I start committing code to sourceforge? Thanks guys Alberto On 13/01/2012 22:26, Stefan Steiniger wrote: I did not see your name in the list of OJ authorized commiters. Do you want to give me or Stefan your sourceforge user name so that we can add it to committer list ? thanks Michael, didn't thought about this. Your welcome Alberto to commit directly ;) stefan Michaël -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] Enhancement of raster support: proposed developments
Hi everyone, back in 2010 I did a bit of work to help improving the raster support capabilities of OpenJUMP (basically to add support for ESRI ASCII and Floating Point grid formats). Now I may have the resources to go further on with raster support by: - adding a tool to query raster values (possibly to be integrated with the Feature Info tool); - improving the Raster Color Editor (to include legends by single values, ramps and classes); - fixing problems related to raster with negative coordinates; - adding raster writing capabilities (at least for geotiffs, ESRI ASCII and ESRI Floating Point grids); - improving the support for nodata values (they should be shown as transparent by default); - fixing layer cut/copy/paste tools (they don't work with raster layers); - improving display speed for big rasters. These enhancements should make OJ able to fully support plug-ins involving rasters (both in input and output). What do you think, shall we proceed? I'm asking Stefan in particular, who has always been working on raster support in OJ. Alberto -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Enhancement of raster support: proposed developments
Jukka, - your first use case is a typical example of a plug-in that would be possible to developed once a couple of the enhancement I proposed are implemented (in particular: raster writing capabilities and improved symbology managament); - visualizing geotiffs with z-values would be also covered by improving the symbology management. Alberto On 13/01/2012 15:41, Rahkonen Jukka wrote: Hi, I have two use cases in my mind, do you believe your work could help in solving these? - Create simple density maps (heatmaps) from point data. A nice browser example is here: http://sloweb.org.uk/ollie/heatmap/ However, I would like to see a bit more advanced tool which would use the attributes too so that if two person died in one accident it would look on a map alike than two accidents with one victim each. - Visualise geotiffs which contain z-values by applying user defined colour ramps. -Jukka Rahkonen- Alberto De Luca wrote: Hi everyone, back in 2010 I did a bit of work to help improving the raster support capabilities of OpenJUMP (basically to add support for ESRI ASCII and Floating Point grid formats). Now I may have the resources to go further on with raster support by: - adding a tool to query raster values (possibly to be integrated with the Feature Info tool); - improving the Raster Color Editor (to include legends by single values, ramps and classes); - fixing problems related to raster with negative coordinates; - adding raster writing capabilities (at least for geotiffs, ESRI ASCII and ESRI Floating Point grids); - improving the support for nodata values (they should be shown as transparent by default); - fixing layer cut/copy/paste tools (they don't work with raster layers); - improving display speed for big rasters. These enhancements should make OJ able to fully support plug-ins involving rasters (both in input and output). What do you think, shall we proceed? I'm asking Stefan in particular, who has always been working on raster support in OJ. Alberto -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
