Re: [JPP-Devel] OpenKLEM

[Alberto De Luca]

Hi Michaël and Ede,

the repository for OpenKLEM is luckily just one, the one on bitbucket that
you already now. You can discuss with Roberto Rossi (who is also reading
this reply) about the option of using SVN. Roberto, I don't know if you're
already following this list, but I think it would be a good idea!

About the bluelines: they represent a vector layer used to recondition the
DEM (in ArcGIS they call it "DEM reconditioning"). In practice, they are
used in cases where the topography is not accurate enough to effectively
describe the drainage network.

>From https://www.caee.utexas.edu/prof/maidment/giswr2012/Ex4/Ex42012.htm:
"DEM reconditioning is a process of adjusting the DEM so that elevations
direct drainage towards the vector information on stream position [...].
DEM reconditioning is only suggested when the vector stream information is
more reliable than the raster DEM information."

Thank you guys for your work!
Alberto


On 25 January 2017 at 23:53, Michaël Michaud 
wrote:

> Hi Ede,
>
> Do you mean the compiled code ? Because I suppose that Roberto Rossi has
> his own source code manager (probably BitBucket).
>
> Michaël
>
>
> Le 25/01/2017 à 12:29, edgar.sol...@web.de a écrit :
> > hey Mike,
> >
> > if you value that component, how about suggesting to add it to the OJ
> svn and giving him an account. this way you could work on it together and
> maybe eventually add it to PLUS?
> >
> > ..ede
> >
> > On 25.01.2017 09:48, Alberto De Luca wrote:
> >> Hey Michaël,
> >>
> >> sure I'm still monitoring this list, sadly I just don't have much time
> to contribute. OpenKLEM is a project managed now by Roberto Rossi from the
> University of Padova. Last time I heard from him, a couple of months ago,
> he told me that his plan was to create a page for OpenKLEM on the
> University's website, where he would put the compiled files, some
> documentation, and the link to the OpenJUMP project and the OpenKLEM source
> code.
> >>
> >> I know he tested OpenKLEM extensively (against OpenJUMP 1.9 at least)
> so it should work. You can find all the binaries he used
> (openklem+dependencies) in this folder <https://www.dropbox.com/sh/
> 4rqgjpw6a1agi81/AAD904CK35kWZrXSFzXIV_0ga?dl=0> (they need to go in the
> /ext directory). The idea was to provide all these files in a zip file to
> the final user. But, if you reckon this is not the right way to go, please
> let us now, and we'll try to fix it!
> >>
> >> In OpenKLEM you don't need to set any workspaces: you load the rasters
> in OpenJUMP (the preferred format is GeoTIFF, but any format supported by
> OpenJUMP is fine) and you should be able to use them in all the OpenKLEM
> tools.
> >>
> >> If needed, you can reach Roberto using this e-mail address:
> roberto.ro...@unipd.it <mailto:roberto.ro...@unipd.it>, he will gladly
> help!
> >>
> >> Alberto
> >>
> >>
> >> On 25 January 2017 at 09:07, Michaël Michaud <
> m.michael.mich...@orange.fr <mailto:m.michael.mich...@orange.fr>> wrote:
> >>
> >>  Hi Alberto,
> >>
> >>  I don't know if you still monitor this list,
> >>
> >>  I just had a try on OpenKLEM (from bitbucket) to check if it is
> >>  compatible with the most recent version of OpenJUMP (1.10).
> >>
> >>  I could install it (with some difficulty because I did not find a
> maven
> >>  or a ant file). Installation was find but I did not find a way to
> set a
> >>  workspace so that I can access Raster layers or DEM layers. Maybe
> I have
> >>  no dataset in the format required by the software. Is there any
> >>  guideline about how to install it and use it ?
> >>
> >>  Thanks for your help (and fill free to add reference to your work
> in
> >>  OpenJUMP wiki).
> >>
> >>  Michaël
> >>
> >>
> >>  
> --
> >>  Check out the vibrant tech community on one of the world's most
> >>  engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> >>  ___
> >>  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 <
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel>
> >>
> >>
> >>
> >>

Re: [JPP-Devel] OpenKLEM

[Alberto De Luca]

Hey Michaël,

sure I'm still monitoring this list, sadly I just don't have much time to
contribute. OpenKLEM is a project managed now by Roberto Rossi from the
University of Padova. Last time I heard from him, a couple of months ago,
he told me that his plan was to create a page for OpenKLEM on the
University's website, where he would put the compiled files, some
documentation, and the link to the OpenJUMP project and the OpenKLEM source
code.

I know he tested OpenKLEM extensively (against OpenJUMP 1.9 at least) so it
should work. You can find all the binaries he used (openklem+dependencies)
in this folder

(they
need to go in the /ext directory). The idea was to provide all these files
in a zip file to the final user. But, if you reckon this is not the right
way to go, please let us now, and we'll try to fix it!

In OpenKLEM you don't need to set any workspaces: you load the rasters in
OpenJUMP (the preferred format is GeoTIFF, but any format supported by
OpenJUMP is fine) and you should be able to use them in all the OpenKLEM
tools.

If needed, you can reach Roberto using this e-mail address:
roberto.ro...@unipd.it, he will gladly help!

Alberto


On 25 January 2017 at 09:07, Michaël Michaud 
wrote:

> Hi Alberto,
>
> I don't know if you still monitor this list,
>
> I just had a try on OpenKLEM (from bitbucket) to check if it is
> compatible with the most recent version of OpenJUMP (1.10).
>
> I could install it (with some difficulty because I did not find a maven
> or a ant file). Installation was find but I did not find a way to set a
> workspace so that I can access Raster layers or DEM layers. Maybe I have
> no dataset in the format required by the software. Is there any
> guideline about how to install it and use it ?
>
> Thanks for your help (and fill free to add reference to your work in
> OpenJUMP wiki).
>
> Michaël
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] A problem about class org.openjump.core.rasterimage.TiffUtils

[Alberto De Luca]

Hey Peppe!

Would you mind tell me, possibly step by step, how to reproduce te
behaviour you describe? The code in TiffUtils should already account for
the fact that the aux.xml file already exists. In theory, the code that
creates the .aux file should be triggered only if: there are no stats saved
internally in the tiff file AND (there is no .aux.xml file OR the .aux.xml
file cannot be read properly).

My educated guess is that the code reading the .aux.xml file might be buggy
and therefore not able to properly read some .aux.xml files. Can you share
your tiff and .aux.xml file for testing?

Thanks
Alberto


On 15 March 2016 at 16:35, Giuseppe Aruta  wrote:

> Hi all, and Alberto
>
> I noted that, every time we open a Tiff raster, an auxiliary  aux.xml file
> is created with raster statistics. I checked TiffUtils class is invoched in
> this case: if no auxiliary file is found, the methods
> calculateStats/createStatsXml write a new one.
>
> The problem is that those methods rewrite also a pre-existing auxiliary
> file, if no statistics was found inside it, loosing possible other useful
> informations (like Spatial reference, for instance) which could be stored
> into this file.
>
> I wonder if it is possible to  change these methods in order to save these
> information for future usage, maybe a) checking if the aux.xml file has
> statistic info, b) appending statistic info to the file if there are not
> found.
> best regards
> Peppe
>
>
>
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Fwd: [jump-pilot:bugs] #414 Image Layer Resizing lost after loading project

[Alberto De Luca]

Hey Peppe,

I should have fixed the problem with r4804. Nevertheless, I forgot to
specify the commit message, which should have been:
"Fix for missing layers problem when loading projects that include rasters."
Anybody knows how I can amend this?

Cheers
Alberto
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Add some useful methods on Layer.class and RasterImageLayer.class

[Alberto De Luca]

Ede,

yes I am aware of the majority of the additions relate to Layer.java, but I
wouldn't venture into commenting on those since my knowledge with regards
to the Layer class is limited. What I could say though is that for what
I've seen the design of Layer is very neat and though-through in comparison
to RasterImageLayer, therefore I would think more than twice before
touching it.

Alberto

On 27 January 2016 at 11:13,  wrote:

> Alberto,
>
> you are aware most additions Peppe did were to Layer.java where they
> definitely don't belong?
>
> if it's needed in RasterImageLayer, i don't oppose at all.
>
> ..ede
>
> On 27.01.2016 10:53, Alberto De Luca wrote:
> > Hey guys,
> >
> > at the moment RasterImageLayer is quite a messy class (a mess to whom
> I've
> > been contributing, by the way), because there's a bit of everything in
> in,
> > from methods that manipulate the raster values to methods that take care
> of
> > the rendering on screen...
> >
> > So while we wait for the lucky ticket-owner to come along, I think that
> the
> > utility methods added by Peppe (that to me are definitely useful) should
> > stay: they just made the class a bit messier :P
> >
> > Alberto
> >
> >
> > On 27 January 2016 at 03:00, Stefan Steiniger  wrote:
> >
> >> see below
> >>
> >> Am 26.01.16 um 13:31 schrieb Giuseppe Aruta:
> >>> Just few extra details:
> >>>
> >>> 1) Temporary vector (Layer.class) and raster (RasterImageLayer.class)
> >>> layers (isTemporaryLayer())
> >>> - Sextante is a different software and it handles raster and vector in
> a
> >>> separate way from OpenJUMP
> >>> - while TEMP files should be stored in Windows forever (except if user
> >>> does a deep OS cleaning) Linux and MacOSX delete these files from the
> >>> /TEMP folder on shuts down
> >>> Linux and Mac users should be aware that, if they shut down the OS and
> >>> if they don't save these temp data in another folder, they will lost
> >>> them. But I am sure that few know about this.
> >>>
> >>> Pratical usage:
> >>> Other temporary layers  also layers with no datasource.
> >>> SaveLayrsWithoutDatasourcePlugIn of Michael already advises users about
> >>> the presence of these layers.
> >>> I am planning to expand this plugin  to this other group of temporary
> >>> layers (the one stored into /TEMP folder) both Layers and
> >> RasterImageLayers.
> >>> I could work on the plugin without adding new boolean on System classes
> >>> (you are right, Ede, those functionality are already there)
> >>> But a flag like RasterImagerLayer.isTemporary() would avoid some extra
> >>> code and, more important,  it could be used also in the future
> >>
> >> I agree with Peppe here...
> >> But perhaps we need to see how this fits also with Michaels DB
> >> experiences (and approaches). At least most Raster-Related helper
> >> classes make sense to me. Perhaps Alberto has a comment on that too.
> >> And if Ede points out to the original JUMP design/development... well
> >> the design focus was on vector... everything else raster wise was more
> >> experimental (my opinion). And this is now also some wooohhhoo 12-13
> >> years ago... ;)
> >>
> >> Ideally of course one would need to do what QGIS did, a complete
> >> redesign of the core, but... (perhaps someone wins in the lottery and
> >> funds 5 devs from that :)
> >>
> >> cheers,
> >> Stefan
> >>
> >>
> >>
> --
> >> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> >> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> >> Monitor end-to-end web transactions and take corrective actions now
> >> Troubleshoot faster and improve end-user experience. Signup Now!
> >> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> >> ___
> >> Jump-pilot-devel mailing list
> >> Jump-pilot-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> >>
> >
> >
> >
> >
> --
> > Site24x7 APM Insight: Get Deep Visibility into Application Performance
> > APM + Mobile APM

Re: [JPP-Devel] Add some useful methods on Layer.class and RasterImageLayer.class

[Alberto De Luca]

Hey guys,

at the moment RasterImageLayer is quite a messy class (a mess to whom I've
been contributing, by the way), because there's a bit of everything in in,
from methods that manipulate the raster values to methods that take care of
the rendering on screen...

So while we wait for the lucky ticket-owner to come along, I think that the
utility methods added by Peppe (that to me are definitely useful) should
stay: they just made the class a bit messier :P

Alberto


On 27 January 2016 at 03:00, Stefan Steiniger  wrote:

> see below
>
> Am 26.01.16 um 13:31 schrieb Giuseppe Aruta:
> > Just few extra details:
> >
> > 1) Temporary vector (Layer.class) and raster (RasterImageLayer.class)
> > layers (isTemporaryLayer())
> > - Sextante is a different software and it handles raster and vector in a
> > separate way from OpenJUMP
> > - while TEMP files should be stored in Windows forever (except if user
> > does a deep OS cleaning) Linux and MacOSX delete these files from the
> > /TEMP folder on shuts down
> > Linux and Mac users should be aware that, if they shut down the OS and
> > if they don't save these temp data in another folder, they will lost
> > them. But I am sure that few know about this.
> >
> > Pratical usage:
> > Other temporary layers  also layers with no datasource.
> > SaveLayrsWithoutDatasourcePlugIn of Michael already advises users about
> > the presence of these layers.
> > I am planning to expand this plugin  to this other group of temporary
> > layers (the one stored into /TEMP folder) both Layers and
> RasterImageLayers.
> > I could work on the plugin without adding new boolean on System classes
> > (you are right, Ede, those functionality are already there)
> > But a flag like RasterImagerLayer.isTemporary() would avoid some extra
> > code and, more important,  it could be used also in the future
>
> I agree with Peppe here...
> But perhaps we need to see how this fits also with Michaels DB
> experiences (and approaches). At least most Raster-Related helper
> classes make sense to me. Perhaps Alberto has a comment on that too.
> And if Ede points out to the original JUMP design/development... well
> the design focus was on vector... everything else raster wise was more
> experimental (my opinion). And this is now also some wooohhhoo 12-13
> years ago... ;)
>
> Ideally of course one would need to do what QGIS did, a complete
> redesign of the core, but... (perhaps someone wins in the lottery and
> funds 5 devs from that :)
>
> cheers,
> Stefan
>
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Fwd: [jump-pilot:bugs] #414 Image Layer Resizing lost after loading project

[Alberto De Luca]

Jumping in late as usual.

I believe the NPE error happens when a project including a raster is loaded
and no other project (task) is present. That happens also with rasters
others than PNG.

An easy fix would be putting a check in RasterImageLayer#setSymbology at
line 1674, to verify that LayerViewPanel is not null. Nevertheless, I think
the actual problem is somewhere related to XML2Java, and eventually leads
to setSymbology being called too early, before the lauyerviewpanel is
created.

What do you reckon?
Alberto


On 20 January 2016 at 18:47, Giuseppe Aruta 
wrote:

> I did some test from my side with no NPE
> We probably need a test image ( as I can see RasterImageLayer.setSymbology
> is invoked on Error. This is a method only for monobad raster file. Freelon
> talks about PNG).
> We should know what exactly was  his procedure.
>
>
>
>
> 2016-01-20 18:28 GMT+01:00 :
>
>> any idea about the NPE during loading? do you need a test image from
>> Freelon? ..ede
>>
>> On 20.01.2016 18:14, Giuseppe Aruta wrote:
>> > *3) >although I don't unterstand why it puts a 800x800px image to have a
>> > size of ~2500x2500*
>> >
>> > I tested it. Not my fault. At this moment I don't understand the
>> problem.
>> >
>> > 2016-01-20 16:01 GMT+01:00 Giuseppe Aruta :
>> >
>> >> Hi Ede,
>> >> maybe I can answer to those questions
>> >>
>> >> 1) > *I can't select it though with the select tool and thus cannot
>> >> resize it*
>> >> Currently is not possible to resize Sextante Layers by dragging them.
>> The
>> >> only way to resize it is a) Draw a Fence, b) Apply "Resize raster to
>> the
>> >> fence" from Sextante  Layer context menu
>> >>
>> >>
>> >> *2) >In OpenJump 1.9 (1.8 as well) I create a new project and add a PNG
>> >> image in a new image layer. Then I resize the image and save layer and
>> >> project. When I reopen the project the resizing information is missing
>> and
>> >> the image is displayed in its original pixel size again. The .jml file
>> >> contains the correct outline values in feature-geometry-Polygon-...-*
>> >> *coordinates*.
>> >> In This case he is talking about an image loaded via ReferencedImage
>> >> (Layer.class). In this case it is true that resizing the image and save
>> >> nothing happens. But I feel this is a good politics as it is easy that
>> an
>> >> user can resize an image by mistake and save it on a project.
>> >> We can skip this adding the possibility to save resized image as new
>> file
>> >> and using the envelope info to create a new worldfile
>> >>
>> >> *3) >although I don't unterstand why it puts a 800x800px image to have
>> a
>> >> size of ~2500x2500*
>> >> Probably my fault.It comes from "Raster property" plugin on Sextante
>> >> Raster conetxt layer menu. What is written as "Pixel", it should go as
>> >> "meter" or other Unit of the map. I recognize that this plugin is too
>> >> big/redundant and somehow slow, I planned to rewrite, similar to
>> >> LayerPropertiesPlugIn. on Layer context menu
>> >>
>> >> Regarding the point 2), we should also take into account that (when
>> >> closing a project or a task)  OpenJUMP warns only the presence of
>> >> a) modified vector layers with datasource and b) temporary vector with
>> no
>> >> datasource.
>> >> As far as I know OpenJUMP doesn't warn other "modified" aspects of a
>> >> projects
>> >> - Sextante Raster Layers generated by Sextante or by
>> >> ExtractSelectedPartOfImage and WarpImageToFencePlugIn which are saved
>> into
>> >> a temporary folder (eg. in windows C:\Users\Beppe\AppData\Local\Temp).
>> >> Those files should be treated as "Raster with no datasource" (thinking
>> >> about Linux/MacOSX user: whenever they shut PC /temp folder is cleaned
>> up)
>> >> -  (as Freloon pointed out) ReferencedImage Layers which envelope has
>> been
>> >> modified
>> >>
>> >> For the next day I will work to solve problem 3
>> >>
>> >> Best
>> >> Peppe
>> >>
>> >> 2016-01-20 14:39 GMT+01:00 :
>> >>
>> >>> Alberto,
>> >>>
>> >>> any idea? s.b. ..ede
>> >>>
>> >>>
>> >>>  Forwarded Message 
>> >>> Subject: [jump-pilot:bugs] #414 Image Layer Resizing lost after
>> loading
>> >>> project
>> >>> Date: Wed, 20 Jan 2016 12:18:25 +
>> >>> From: Freelon Xamar 
>> >>> Reply-To: [jump-pilot:bugs]  <4...@bugs.jump-pilot.p.re.sf.net>
>> >>> To: [jump-pilot:bugs]  <4...@bugs.jump-pilot.p.re.sf.net>
>> >>>
>> >>> When loading as a sextant raster (FIle..Open..Sextant Raster Image) it
>> >>> gets loaded (although I don't unterstand why it puts a 800x800px
>> image to
>> >>> have a size of ~2500x2500). I can't select it though with the select
>> tool
>> >>> and thus cannot resize it.
>> >>> Anyway, if I save the project (just the project in this case, because
>> I
>> >>> don't have the save option for the raster image layer) now and try to
>> open
>> >>> it again I get a "null" exception:
>> >>>
>> >>>
>> >>> 
>> >>> java.lang.Exception: Loading project file '/home/XYZ/ffm.jmp' failed
>> with
>> >>> the error:
>> >>> null.
>> >>> 

Re: [JPP-Devel] SVN: [4666] core/trunk

[Alberto De Luca]

Right, got it... NetBeans would build anyway, needed to clean the project
to see it...

Give it a try. I also tried to solve the problem with GeoServer. Let me
know.

Alberto

On 24 December 2015 at 14:52, Rahkonen Jukka (MML) <
jukka.rahko...@maanmittauslaitos.fi> wrote:

> Hi,
>
>
>
> I do not build myself, the link above contains the error from the Ede’s
> snapshot build system.
>
>
>
> -Jukka-
>
>
>
> *Lähettäjä:* Alberto De Luca [mailto:berta...@gmail.com]
> *Lähetetty:* 24. joulukuuta 2015 15:34
> *Vastaanottaja:* OpenJump develop and use
> *Aihe:* Re: [JPP-Devel] SVN: [4666] core/trunk
>
>
>
> Jukka, what error do you get? It builds for me...
>
>
>
> Alberto
>
>
>
> On 24 December 2015 at 13:58, Rahkonen Jukka (MML) <
> jukka.rahko...@maanmittauslaitos.fi> wrote:
>
> Hi,
>
> R4666 did not build
>
>
> http://sourceforge.net/projects/jump-pilot/files/OpenJUMP_snapshots/OpenJUMP-20151224-r4666.log/download
>
> -Jukka-
>
> -Alkuperäinen viesti-
> Lähettäjä: jump-pilot-...@lists.sourceforge.net [mailto:
> jump-pilot-...@lists.sourceforge.net]
> Lähetetty: 24. joulukuuta 2015 14:34
> Vastaanottaja: jump-pilot-devel@lists.sourceforge.net
> Aihe: [JPP-Devel] SVN: [4666] core/trunk
>
> Revision: 4666
>   http://sourceforge.net/p/jump-pilot/code/4666
> Author:   bertazza
> Date: 2015-12-24 12:33:54 + (Thu, 24 Dec 2015)
> Log Message:
> ---
> Removed IOExpcetion throw from TaskFrame
>
> Modified Paths:
> --
> core/trunk/ChangeLog
> core/trunk/src/com/vividsolutions/jump/workbench/ui/InfoFrame.java
>
> core/trunk/src/com/vividsolutions/jump/workbench/ui/PrimaryInfoFrame.java
> core/trunk/src/com/vividsolutions/jump/workbench/ui/TaskFrame.java
> core/trunk/src/com/vividsolutions/wms/AbstractParser.java
> core/trunk/src/com/vividsolutions/wms/Parser.java
>
> Modified: core/trunk/ChangeLog
> ===
> --- core/trunk/ChangeLog2015-12-24 12:03:26 UTC (rev 4665)
> +++ core/trunk/ChangeLog2015-12-24 12:33:54 UTC (rev 4666)
> @@ -4,6 +4,9 @@
>  #< 80 chars
> -->#
>
>  2015-12-24 bertazza
> +  * Removed IOExpcetion throw from TaskFrame
> +
> +2015-12-24 bertazza
>* Info feature tool for WMS: info shown only for visible layers, added
>  &FEATURE_COUNT=10 parameter, and changed method to retrieve url as
>  suggested by Jukka (should now support basic authentication).
>
> Modified:
> core/trunk/src/com/vividsolutions/jump/workbench/ui/InfoFrame.java
> ===
> --- core/trunk/src/com/vividsolutions/jump/workbench/ui/InfoFrame.java
> 2015-12-24 12:03:26 UTC (rev 4665)
> +++ core/trunk/src/com/vividsolutions/jump/workbench/ui/InfoFrame.java
> 2015-12-24 12:33:54 UTC (rev 4666)
> @@ -108,7 +108,7 @@
>  public InfoFrame(
>  WorkbenchContext workbenchContext,
>  LayerManagerProxy layerManagerProxy,
> -final TaskFrame taskFrame) throws IOException {
> +final TaskFrame taskFrame) {
> blackboard =
> PersistentBlackboardPlugIn.get(workbenchContext);
>  geometryInfoTab = new GeometryInfoTab(model, workbenchContext);
>  rasterInfoTab = new RasterInfoTab(null, null); @@ -375,7 +375,7 @@
>
>  private final JEditorPane jEditorPane;
>
> -public WMSInfoTab() throws IOException {
> +public WMSInfoTab() {
>
>  setLayout(new BorderLayout());
>
>
> Modified:
> core/trunk/src/com/vividsolutions/jump/workbench/ui/PrimaryInfoFrame.java
> ===
> ---
> core/trunk/src/com/vividsolutions/jump/workbench/ui/PrimaryInfoFrame.java
>  2015-12-24 12:03:26 UTC (rev 4665)
> +++
> core/trunk/src/com/vividsolutions/jump/workbench/ui/PrimaryInfoFrame.java
>  2015-12-24 12:33:54 UTC (rev 4666)
> @@ -45,7 +45,7 @@
>   * positions InfoFrames differently depending on whether or not they are
> primary.
>   */
>  public class PrimaryInfoFrame extends InfoFrame {
> -public PrimaryInfoFrame(WorkbenchContext workbenchContext,
> LayerManagerProxy layerManagerProxy, TaskFrame taskFrame) throws
> IOException {
> +public PrimaryInfoFrame(WorkbenchContext workbenchContext,
> + LayerManagerProxy layerManagerProxy, TaskFrame taskFrame) {
>  super(workbenchContext, layerManagerProxy, taskFrame);
>  }
>  }
>
> Modified:
> core/trunk/src/com/vividsolutions/jump/workbench/ui/TaskFrame.java
> ===

Re: [JPP-Devel] SVN: [4666] core/trunk

[Alberto De Luca]

Jukka, what error do you get? It builds for me...

Alberto

On 24 December 2015 at 13:58, Rahkonen Jukka (MML) <
jukka.rahko...@maanmittauslaitos.fi> wrote:

> Hi,
>
> R4666 did not build
>
>
> http://sourceforge.net/projects/jump-pilot/files/OpenJUMP_snapshots/OpenJUMP-20151224-r4666.log/download
>
> -Jukka-
>
> -Alkuperäinen viesti-
> Lähettäjä: jump-pilot-...@lists.sourceforge.net [mailto:
> jump-pilot-...@lists.sourceforge.net]
> Lähetetty: 24. joulukuuta 2015 14:34
> Vastaanottaja: jump-pilot-devel@lists.sourceforge.net
> Aihe: [JPP-Devel] SVN: [4666] core/trunk
>
> Revision: 4666
>   http://sourceforge.net/p/jump-pilot/code/4666
> Author:   bertazza
> Date: 2015-12-24 12:33:54 + (Thu, 24 Dec 2015)
> Log Message:
> ---
> Removed IOExpcetion throw from TaskFrame
>
> Modified Paths:
> --
> core/trunk/ChangeLog
> core/trunk/src/com/vividsolutions/jump/workbench/ui/InfoFrame.java
>
> core/trunk/src/com/vividsolutions/jump/workbench/ui/PrimaryInfoFrame.java
> core/trunk/src/com/vividsolutions/jump/workbench/ui/TaskFrame.java
> core/trunk/src/com/vividsolutions/wms/AbstractParser.java
> core/trunk/src/com/vividsolutions/wms/Parser.java
>
> Modified: core/trunk/ChangeLog
> ===
> --- core/trunk/ChangeLog2015-12-24 12:03:26 UTC (rev 4665)
> +++ core/trunk/ChangeLog2015-12-24 12:33:54 UTC (rev 4666)
> @@ -4,6 +4,9 @@
>  #< 80 chars
> -->#
>
>  2015-12-24 bertazza
> +  * Removed IOExpcetion throw from TaskFrame
> +
> +2015-12-24 bertazza
>* Info feature tool for WMS: info shown only for visible layers, added
>  &FEATURE_COUNT=10 parameter, and changed method to retrieve url as
>  suggested by Jukka (should now support basic authentication).
>
> Modified:
> core/trunk/src/com/vividsolutions/jump/workbench/ui/InfoFrame.java
> ===
> --- core/trunk/src/com/vividsolutions/jump/workbench/ui/InfoFrame.java
> 2015-12-24 12:03:26 UTC (rev 4665)
> +++ core/trunk/src/com/vividsolutions/jump/workbench/ui/InfoFrame.java
> 2015-12-24 12:33:54 UTC (rev 4666)
> @@ -108,7 +108,7 @@
>  public InfoFrame(
>  WorkbenchContext workbenchContext,
>  LayerManagerProxy layerManagerProxy,
> -final TaskFrame taskFrame) throws IOException {
> +final TaskFrame taskFrame) {
> blackboard =
> PersistentBlackboardPlugIn.get(workbenchContext);
>  geometryInfoTab = new GeometryInfoTab(model, workbenchContext);
>  rasterInfoTab = new RasterInfoTab(null, null); @@ -375,7 +375,7 @@
>
>  private final JEditorPane jEditorPane;
>
> -public WMSInfoTab() throws IOException {
> +public WMSInfoTab() {
>
>  setLayout(new BorderLayout());
>
>
> Modified:
> core/trunk/src/com/vividsolutions/jump/workbench/ui/PrimaryInfoFrame.java
> ===
> ---
> core/trunk/src/com/vividsolutions/jump/workbench/ui/PrimaryInfoFrame.java
>  2015-12-24 12:03:26 UTC (rev 4665)
> +++
> core/trunk/src/com/vividsolutions/jump/workbench/ui/PrimaryInfoFrame.java
>  2015-12-24 12:33:54 UTC (rev 4666)
> @@ -45,7 +45,7 @@
>   * positions InfoFrames differently depending on whether or not they are
> primary.
>   */
>  public class PrimaryInfoFrame extends InfoFrame {
> -public PrimaryInfoFrame(WorkbenchContext workbenchContext,
> LayerManagerProxy layerManagerProxy, TaskFrame taskFrame) throws
> IOException {
> +public PrimaryInfoFrame(WorkbenchContext workbenchContext,
> + LayerManagerProxy layerManagerProxy, TaskFrame taskFrame) {
>  super(workbenchContext, layerManagerProxy, taskFrame);
>  }
>  }
>
> Modified:
> core/trunk/src/com/vividsolutions/jump/workbench/ui/TaskFrame.java
> ===
> --- core/trunk/src/com/vividsolutions/jump/workbench/ui/TaskFrame.java
> 2015-12-24 12:03:26 UTC (rev 4665)
> +++ core/trunk/src/com/vividsolutions/jump/workbench/ui/TaskFrame.java
> 2015-12-24 12:33:54 UTC (rev 4666)
> @@ -224,7 +224,7 @@
>  return task.getLayerManager();
>  }
>
> -public InfoFrame getInfoFrame() throws IOException {
> +public InfoFrame getInfoFrame() {
>  if (infoFrame == null || infoFrame.isClosed()) {
>  infoFrame = new PrimaryInfoFrame(workbenchContext, this,
> this);
>  }
>
> Modified: core/trunk/src/com/vividsolutions/wms/AbstractParser.java
> ===
> --- core/trunk/src/com/vividsolutions/wms/AbstractParser.java   2015-12-24
> 12:03:26 UTC (rev 4665)
> +++ core/trunk/src/com/vividsolutions/wms/AbstractParser.java   2015-12-24
> 12:33:54 UTC (rev 4666)
> @@ -220,20 +220,20 @@
>  boundingBoxList.add ( new
> BoundingBox("Geographi

Re: [JPP-Devel] SVN: [4663] core/trunk

[Alberto De Luca]

Hi.

@Ede
1) that is something added by eclipse (
http://stackoverflow.com/questions/654037/what-does-non-nls-1-mean). I took
it away from the WMS-related files, but you will find it in several other
files.

2) yes, changing the API of TaskFrame wasn't brilliant... I reverted to
it's original state. For the neat implementation of InfoRequest, it will be
done, but I need some more time.

@Jukka
I changed the method used to retrieve the url as you suggested. I added the
FEATURE_COUNT=10 parameter, and I limited the WMS info to the visible
layers. Not visible and selected, just visible, to make it consistent with
vector layers.

Alberto

On 24 December 2015 at 13:02,  wrote:

> hey Alberto,
>
> i have some questions/comments
>
> 1.
> in several files eg. Parser.java you added lines ending with
> '//$NON-NLS-1$' . why?
>
> 2.
> you insert wms code (url appending) directly into the featureinfotool up
> to the point that it even runs the web request.
> why don't you use the wms package? i see you added the info url to the
> capabilities already. would you mind implementing that cleanly with a
> InfoRequest object along the lines of existing MapRequest.java . this way
> you can reuse all the magic there is already including auth/proxy usage.
> changing the API of TaskFrame to an IOException throwing getInfoFrame() is
> an absolute no go from my point of view.
>
> how long would it take for you to fix it? keep in mind, we can easily slip
> in a clean version with the first maintenance release. so no hurry.
>
> ..ede
>
>
> On 24.12.2015 00:18, Alberto De Luca wrote:
> > Right sorry,
> >
> > I think Parser.java was the culprit. I had deleted it locally, but not on
> > the server. It is no longer needed actually, but instead of deleting it I
> > edited to make it compatible with the modified WMS classes (so we can
> keep
> > it, you never know...).
> >
> > Apparently it builds now, let me know.
> > Alberto
> >
> > On 23 December 2015 at 22:00,  wrote:
> >
> >> Alberto,
> >>
> >> your commit seems incomplete.. ede
> >>
> >>
> >> On 23.12.2015 18:28, Rahkonen Jukka (MML) wrote:
> >>> Hi,
> >>>
> >>> r4663 did not build
> >>>
> >>
> http://sourceforge.net/projects/jump-pilot/files/OpenJUMP_snapshots/OpenJUMP-20151223-r4663.log/download
> >>>
> >>> -Jukka Rahkonen-
> >>>
> >>>
> >>> -Alkuperäinen viesti-
> >>> Lähettäjä: jump-pilot-...@lists.sourceforge.net [mailto:
> >> jump-pilot-...@lists.sourceforge.net]
> >>> Lähetetty: 23. joulukuuta 2015 18:27
> >>> Vastaanottaja: jump-pilot-devel@lists.sourceforge.net
> >>> Aihe: [JPP-Devel] SVN: [4663] core/trunk
> >>>
> >>> Revision: 4663
> >>>   http://sourceforge.net/p/jump-pilot/code/4663
> >>> Author:   bertazza
> >>> Date: 2015-12-23 16:26:41 + (Wed, 23 Dec 2015)
> >>> Log Message:
> >>> ---
> >>> Info feature tool: added a pane to show WMS info.
> >>>
> >>> Modified Paths:
> >>> --
> >>> core/trunk/ChangeLog
> >>> core/trunk/src/com/vividsolutions/jump/workbench/ui/InfoFrame.java
> >>>
> >>
> core/trunk/src/com/vividsolutions/jump/workbench/ui/PrimaryInfoFrame.java
> >>> core/trunk/src/com/vividsolutions/jump/workbench/ui/TaskFrame.java
> >>>
> >>
> core/trunk/src/com/vividsolutions/jump/workbench/ui/cursortool/FeatureInfoTool.java
> >>> core/trunk/src/com/vividsolutions/wms/AbstractParser.java
> >>> core/trunk/src/com/vividsolutions/wms/Capabilities.java
> >>> core/trunk/src/com/vividsolutions/wms/MapLayer.java
> >>> core/trunk/src/com/vividsolutions/wms/ParserWMS1_0.java
> >>> core/trunk/src/com/vividsolutions/wms/ParserWMS1_1.java
> >>> core/trunk/src/com/vividsolutions/wms/ParserWMS1_3.java
> >>> core/trunk/src/com/vividsolutions/wms/WMService.java
> >>> core/trunk/src/org/openjump/core/ui/plugin/queries/QueryDialog.java
> >>>
> >>> Added Paths:
> >>> ---
> >>>
> >>
> core/trunk/src/com/vividsolutions/jump/workbench/ui/cursortool/clean.xsl
> >>> core/trunk/src/com/vividsolutions/wms/MapStyle.java
> >>>
> >>> Modified: core/trunk/ChangeLog
> >>> ===
> >>> --- core/trunk/ChangeLog   

Re: [JPP-Devel] SVN: [4663] core/trunk

[Alberto De Luca]

Right sorry,

I think Parser.java was the culprit. I had deleted it locally, but not on
the server. It is no longer needed actually, but instead of deleting it I
edited to make it compatible with the modified WMS classes (so we can keep
it, you never know...).

Apparently it builds now, let me know.
Alberto

On 23 December 2015 at 22:00,  wrote:

> Alberto,
>
> your commit seems incomplete.. ede
>
>
> On 23.12.2015 18:28, Rahkonen Jukka (MML) wrote:
> > Hi,
> >
> > r4663 did not build
> >
> http://sourceforge.net/projects/jump-pilot/files/OpenJUMP_snapshots/OpenJUMP-20151223-r4663.log/download
> >
> > -Jukka Rahkonen-
> >
> >
> > -Alkuperäinen viesti-
> > Lähettäjä: jump-pilot-...@lists.sourceforge.net [mailto:
> jump-pilot-...@lists.sourceforge.net]
> > Lähetetty: 23. joulukuuta 2015 18:27
> > Vastaanottaja: jump-pilot-devel@lists.sourceforge.net
> > Aihe: [JPP-Devel] SVN: [4663] core/trunk
> >
> > Revision: 4663
> >   http://sourceforge.net/p/jump-pilot/code/4663
> > Author:   bertazza
> > Date: 2015-12-23 16:26:41 + (Wed, 23 Dec 2015)
> > Log Message:
> > ---
> > Info feature tool: added a pane to show WMS info.
> >
> > Modified Paths:
> > --
> > core/trunk/ChangeLog
> > core/trunk/src/com/vividsolutions/jump/workbench/ui/InfoFrame.java
> >
>  core/trunk/src/com/vividsolutions/jump/workbench/ui/PrimaryInfoFrame.java
> > core/trunk/src/com/vividsolutions/jump/workbench/ui/TaskFrame.java
> >
>  
> core/trunk/src/com/vividsolutions/jump/workbench/ui/cursortool/FeatureInfoTool.java
> > core/trunk/src/com/vividsolutions/wms/AbstractParser.java
> > core/trunk/src/com/vividsolutions/wms/Capabilities.java
> > core/trunk/src/com/vividsolutions/wms/MapLayer.java
> > core/trunk/src/com/vividsolutions/wms/ParserWMS1_0.java
> > core/trunk/src/com/vividsolutions/wms/ParserWMS1_1.java
> > core/trunk/src/com/vividsolutions/wms/ParserWMS1_3.java
> > core/trunk/src/com/vividsolutions/wms/WMService.java
> > core/trunk/src/org/openjump/core/ui/plugin/queries/QueryDialog.java
> >
> > Added Paths:
> > ---
> >
>  core/trunk/src/com/vividsolutions/jump/workbench/ui/cursortool/clean.xsl
> > core/trunk/src/com/vividsolutions/wms/MapStyle.java
> >
> > Modified: core/trunk/ChangeLog
> > ===
> > --- core/trunk/ChangeLog  2015-12-23 15:39:50 UTC (rev 4662)
> > +++ core/trunk/ChangeLog  2015-12-23 16:26:41 UTC (rev 4663)
> > @@ -3,6 +3,8 @@
> >  # 2. make sure that lines break at 80 chars for constricted display
> situations
> >  #< 80 chars
> -->#
> >
> > +2015-12-23 bertazza
> > +  * Info feature tool: added a pane to show WMS info.
> >
> >  <--- Changes.txt updated
> 'til here
> >  2015-12-21 bertazza
> >
> > Modified:
> core/trunk/src/com/vividsolutions/jump/workbench/ui/InfoFrame.java
> > ===
> > --- core/trunk/src/com/vividsolutions/jump/workbench/ui/InfoFrame.java
>   2015-12-23 15:39:50 UTC (rev 4662)
> > +++ core/trunk/src/com/vividsolutions/jump/workbench/ui/InfoFrame.java
>   2015-12-23 16:26:41 UTC (rev 4663)
> > @@ -61,6 +61,8 @@
> >  import com.vividsolutions.jump.workbench.ui.images.IconLoader;
> >  import
> com.vividsolutions.jump.workbench.ui.plugin.PersistentBlackboardPlugIn;
> >  import com.vividsolutions.jump.workbench.ui.plugin.ViewAttributesPlugIn;
> > +import java.io.IOException;
> > +import javax.swing.JEditorPane;
> >  import javax.swing.JScrollPane;
> >  import javax.swing.JTable;
> >  import javax.swing.table.DefaultTableModel;
> > @@ -99,16 +101,18 @@
> >  private GeometryInfoTab geometryInfoTab;
> >  private JTabbedPane tabbedPane = new JTabbedPane();
> >  private RasterInfoTab rasterInfoTab;
> > +private WMSInfoTab wmsInfoTab;
> >  private WorkbenchFrame workbenchFrame;
> >  private static ImageIcon ICON =
> IconLoader.icon("information_16x16.png");
> >
> >  public InfoFrame(
> >  WorkbenchContext workbenchContext,
> >  LayerManagerProxy layerManagerProxy,
> > -final TaskFrame taskFrame) {
> > +final TaskFrame taskFrame) throws IOException {
> >   blackboard =
> PersistentBlackboardPlugIn.get(workbenchContext);
> >  geometryInfoTab = new GeometryInfoTab(model, workbenchContext);
> >  rasterInfoTab = new RasterInfoTab(null, null);
> > +wmsInfoTab = new WMSInfoTab();
> >  //Keep my own copy of LayerManager, because it will be nulled
> in TaskFrame
> >  //when TaskFrame closes (it may in fact already be closed,
> which is why
> >  //a LayerManagerProxy must be passed in too). But I have to @@
> -150,6 +154,7 @@
> >  tabbedPane.addTab("", IconLoader.icon("Table.gif"),
> attributeTab, TABLE_VIEW);
> >  tabbedPane.addTab("", IconLo

Re: [JPP-Devel] release status

[Alberto De Luca]

Ede,

I retrieved the feature info url from the WMSService of each WMS layer,
added to that url the needed parameters (BBox...), and sent the request
over to server.

Alberto

On 23 December 2015 at 15:03,  wrote:

> Alberto,
>
> simply commit your changes. Jukka can then easily test the snapshot.
>
> i am reasonably sure that the WMS Connection caches the auth info, didn't
> you reuse the existing infrastructure?
>
> ..ede
>
> On 23.12.2015 14:21, Alberto De Luca wrote:
> > Jukka,
> >
> > I don't have access to a server requesting authentication, so I can't
> test that feature. And, to be honest, I don't believe it's working at the
> moment!
> >
> > How would you like to procede? Shall I commit the changes so far so you
> can test and fix the issue yourself? Or do you want me to pass you the
> updated source code so you can have a look before committing? Or maybe you
> could give me access to a mock wms server with authentication?
> >
> > Alberto
> >
> > On 22 December 2015 at 22:11, Rahkonen Jukka (MML) <
> jukka.rahko...@maanmittauslaitos.fi  jukka.rahko...@maanmittauslaitos.fi>> wrote:
> >
> > Hi,
> >
> > __ __
> >
> > Once you are ready I can test with our server how GetFeatureInfo
> works through https and basic authentication.
> >
> > __ __
> >
> > -Jukka Rahkonen-
> >
> > __ __
> >
> > Alberto De Luca wrote:
> >
> > __ __
> >
> > Edgar,
> >
> > __ __
> >
> > I know this might be annoying, but I got today a request for adding
> to the FeatureInfoTool the capability to display the results from querying
> WMS layers. I've already implemented it (very basic: a fourth panel in the
> FeatureInfoTool, showing the server response as plain text), but I'd need a
> day more to test it.
> >
> > __ __
> >
> > Let me know if you can wait.
> >
> > Alberto
> >
> > __ __
> >
> > On 22 December 2015 at 16:27,  edgar.sol...@web.de>> wrote:
> >
> > hey All,
> >
> > i am getting warmer to put together OJ 1.9 . has anybody any
> objections? what is the status in your fields of interest?
> >
> > ..ede
> >
> >
>  
> --
> > ___
> > Jump-pilot-devel mailing list
> > Jump-pilot-devel@lists.sourceforge.net  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  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
> >
>
>
> --
> ___
> 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] release status

[Alberto De Luca]

Jukka,

I don't have access to a server requesting authentication, so I can't test
that feature. And, to be honest, I don't believe it's working at the moment!

How would you like to procede? Shall I commit the changes so far so you can
test and fix the issue yourself? Or do you want me to pass you the updated
source code so you can have a look before committing? Or maybe you could
give me access to a mock wms server with authentication?

Alberto

On 22 December 2015 at 22:11, Rahkonen Jukka (MML) <
jukka.rahko...@maanmittauslaitos.fi> wrote:

> Hi,
>
>
>
> Once you are ready I can test with our server how GetFeatureInfo works
> through https and basic authentication.
>
>
>
> -Jukka Rahkonen-
>
>
>
> Alberto De Luca wrote:
>
>
>
> Edgar,
>
>
>
> I know this might be annoying, but I got today a request for adding to the
> FeatureInfoTool the capability to display the results from querying WMS
> layers. I've already implemented it (very basic: a fourth panel in the
> FeatureInfoTool, showing the server response as plain text), but I'd need a
> day more to test it.
>
>
>
> Let me know if you can wait.
>
> Alberto
>
>
>
> On 22 December 2015 at 16:27,  wrote:
>
> hey All,
>
> i am getting warmer to put together OJ 1.9 . has anybody any objections?
> what is the status in your fields of interest?
>
> ..ede
>
>
> --
> ___
> 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
>
>
--
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] release status

[Alberto De Luca]

Great thanks, I'll let you know asap!

Alberto

On 22 December 2015 at 19:05,  wrote:

> no problemo. thats why i ask early ;)).. just holler when your done.. ede
>
> On 22.12.2015 18:47, Alberto De Luca wrote:
> > Edgar,
> >
> > I know this might be annoying, but I got today a request for adding to
> the
> > FeatureInfoTool the capability to display the results from querying WMS
> > layers. I've already implemented it (very basic: a fourth panel in the
> > FeatureInfoTool, showing the server response as plain text), but I'd
> need a
> > day more to test it.
> >
> > Let me know if you can wait.
> > Alberto
> >
> > On 22 December 2015 at 16:27,  wrote:
> >
> >> hey All,
> >>
> >> i am getting warmer to put together OJ 1.9 . has anybody any objections?
> >> what is the status in your fields of interest?
> >>
> >> ..ede
> >>
> >>
> >>
> --
> >> ___
> >> 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
> >
>
>
> --
> ___
> 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] release status

[Alberto De Luca]

Edgar,

I know this might be annoying, but I got today a request for adding to the
FeatureInfoTool the capability to display the results from querying WMS
layers. I've already implemented it (very basic: a fourth panel in the
FeatureInfoTool, showing the server response as plain text), but I'd need a
day more to test it.

Let me know if you can wait.
Alberto

On 22 December 2015 at 16:27,  wrote:

> hey All,
>
> i am getting warmer to put together OJ 1.9 . has anybody any objections?
> what is the status in your fields of interest?
>
> ..ede
>
>
> --
> ___
> 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] raster style language files

[Alberto De Luca]

Hi Ede,

here you are, short and simple (maybe too short?):

New features:
- "Raster styler" to edit, load and save raster symbologies

Improvements:
- better handling of TIFF files: partial image loading, support for
overviews, support for raster statistics (in .aux.xml file and
as GDAL_METADATA tag), improved raster legend representation in layer list;
- better support for raster symbologies, now saved in project file.

Alberto

On 21 December 2015 at 10:56,  wrote:

> Alberto,
>
> not today and probably not before the release but somewhen in  the future
> i will move the language files to src/language/rasterstyle/ . so don't be
> surprised in that case ;)
>
> ..ede
>
> PS: could you please give me a short description of your additions for the
> upcoming release's Changes.txt? thx..
>
>
> --
> ___
> 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] New improvement on Raster Style by Alberto

[Alberto De Luca]

Hi everyone.

I've updated the properties files for ES and IT. While doing so, I
corrected a small bug: when the number of classes was not valid (in the
"Intervals" tab), there was no feedback to the user. So I added an error
message. If you want to add translations to it other than EN, ES, IT you
can use this key in your resource files:

org.openjump.core.rasterimage.styler.ui.IntervalPanel.numberOfClassesError

Alberto

On 19 December 2015 at 16:03, Alberto De Luca  wrote:

> HI Peppe.
>
> I'll check the Italian and update the two files in the next couple of days!
>
> Thanks
> Alberto
>
> On Sat, 19 Dec 2015 14:51 Giuseppe Aruta  wrote:
>
>> Hi Jukka,
>> I did sone tests and it seems that stored raster styles are not applied
>> and  just skipped, when I open a new generation JML with older OJ versions.
>>
>> @Alberto
>> I worked on Italian translation for Raster Styler (Bundle_it.properties).
>> I ask you if you can check and eventually correct  mistakes.
>> I also need somebody who upgrade Bundle_it.properties and
>> Bundle_es.properties files on SVN. I am traveling in Chile in this moment
>> and have no access to OJ SVN.
>> I attached thos two files to this mail
>>
>> Best regards
>> Peppe
>>
>> 2015-12-18 18:04 GMT+01:00 Rahkonen Jukka (MML) <
>> jukka.rahko...@maanmittauslaitos.fi>:
>>
>>> Hi,
>>>
>>>
>>>
>>> I haven’t been testing anything but I wonder if it would be good to add
>>> a version number to the OpenJUMP project file XML. Then it could be
>>> possible to implement something
>>>
>>>
>>>
>>> -  Open new generation JML with older OJ versions –> stored
>>> raster styles are not applied but hopefully they are just skipped
>>>
>>> -  Show a warning: Project file was saved as JMP version {0}
>>> but this OJ supports only {1}. Some project features may be lost on opening.
>>>
>>> -  Perhaps warn also before overwriting existing JMP file with
>>> older JML version.
>>>
>>>
>>>
>>> -Jukka Rahkonen-
>>>
>>>
>>>
>>> Alberto De Luca wrote:
>>>
>>>
>>>
>>> Thank you Peppe,
>>>
>>>
>>>
>>> changes are now committed!
>>>
>>>
>>>
>>> Alberto
>>>
>>>
>>>
>>> On 17 December 2015 at 20:52, Giuseppe Aruta 
>>> wrote:
>>>
>>> Hi Alberto,
>>>
>>> I did a couple of tests, following this schema
>>> a) I opened  a jump project
>>>
>>> b) loaded one or two raster and applied different color simbologies
>>>
>>> c) saved and closed the project
>>>
>>> d) loaded the project again
>>>
>>> It seems that everything works fine.
>>>
>>> Very nice work
>>>
>>> Best regards (from Chile)
>>>
>>> Peppe
>>>
>>>
>>>
>>> 2015-12-16 11:04 GMT+01:00 :
>>>
>>> On 15.12.2015 18:54, Alberto De Luca wrote:
>>> > Hi there.
>>> >
>>> > I've added today the capability to save the raster symbology in the
>>> OpenJUMP project file. I'd like to ask you a couple of things though:
>>> > - is it too late to add it now? I'm not sure, but I might have read in
>>> some posts that the features are frozen by now;
>>>
>>> i called  it a soft freeze;).. so nothing made out of stone. generally,
>>> as the next release is around the corner, we should clean up, translate and
>>> do not start big reworks.
>>>
>>> adding features (alas not perfect) or fixing bugs is totally fine. we
>>> can easily release a maintenance version when users stumble over show
>>> stoppers.
>>>
>>> i plan to release during the holidays, but hey, if it gets january
>>> because we fixed/added some more that's fine for everybody i guess.
>>>
>>> so, no problemo.. ede
>>>
>>> > - if the answer is no, would someone be so kind (Peppe!!!) to test the
>>> feature a bit before I commit the changes? I had to modify a few classes,
>>> I'd like to be sure I haven't broken anything... If so, you can find the
>>> compiled openjump jar here:
>>> >
>>> >
>>> >
>>> https://www.dropbox.com/s/zf1eshbiuucohck/OpenJUMP-0.0.0-rnull.jar?dl=0
>>> >
>>> >
>>> > Cheers
>>&g

Re: [JPP-Devel] New improvement on Raster Style by Alberto

[Alberto De Luca]

HI Peppe.

I'll check the Italian and update the two files in the next couple of days!

Thanks
Alberto

On Sat, 19 Dec 2015 14:51 Giuseppe Aruta  wrote:

> Hi Jukka,
> I did sone tests and it seems that stored raster styles are not applied
> and  just skipped, when I open a new generation JML with older OJ versions.
>
> @Alberto
> I worked on Italian translation for Raster Styler (Bundle_it.properties).
> I ask you if you can check and eventually correct  mistakes.
> I also need somebody who upgrade Bundle_it.properties and
> Bundle_es.properties files on SVN. I am traveling in Chile in this moment
> and have no access to OJ SVN.
> I attached thos two files to this mail
>
> Best regards
> Peppe
>
> 2015-12-18 18:04 GMT+01:00 Rahkonen Jukka (MML) <
> jukka.rahko...@maanmittauslaitos.fi>:
>
>> Hi,
>>
>>
>>
>> I haven’t been testing anything but I wonder if it would be good to add a
>> version number to the OpenJUMP project file XML. Then it could be possible
>> to implement something
>>
>>
>>
>> -  Open new generation JML with older OJ versions –> stored
>> raster styles are not applied but hopefully they are just skipped
>>
>> -  Show a warning: Project file was saved as JMP version {0} but
>> this OJ supports only {1}. Some project features may be lost on opening.
>>
>> -  Perhaps warn also before overwriting existing JMP file with
>> older JML version.
>>
>>
>>
>> -Jukka Rahkonen-
>>
>>
>>
>> Alberto De Luca wrote:
>>
>>
>>
>> Thank you Peppe,
>>
>>
>>
>> changes are now committed!
>>
>>
>>
>> Alberto
>>
>>
>>
>> On 17 December 2015 at 20:52, Giuseppe Aruta 
>> wrote:
>>
>> Hi Alberto,
>>
>> I did a couple of tests, following this schema
>> a) I opened  a jump project
>>
>> b) loaded one or two raster and applied different color simbologies
>>
>> c) saved and closed the project
>>
>> d) loaded the project again
>>
>> It seems that everything works fine.
>>
>> Very nice work
>>
>> Best regards (from Chile)
>>
>> Peppe
>>
>>
>>
>> 2015-12-16 11:04 GMT+01:00 :
>>
>> On 15.12.2015 18:54, Alberto De Luca wrote:
>> > Hi there.
>> >
>> > I've added today the capability to save the raster symbology in the
>> OpenJUMP project file. I'd like to ask you a couple of things though:
>> > - is it too late to add it now? I'm not sure, but I might have read in
>> some posts that the features are frozen by now;
>>
>> i called  it a soft freeze;).. so nothing made out of stone. generally,
>> as the next release is around the corner, we should clean up, translate and
>> do not start big reworks.
>>
>> adding features (alas not perfect) or fixing bugs is totally fine. we can
>> easily release a maintenance version when users stumble over show stoppers.
>>
>> i plan to release during the holidays, but hey, if it gets january
>> because we fixed/added some more that's fine for everybody i guess.
>>
>> so, no problemo.. ede
>>
>> > - if the answer is no, would someone be so kind (Peppe!!!) to test the
>> feature a bit before I commit the changes? I had to modify a few classes,
>> I'd like to be sure I haven't broken anything... If so, you can find the
>> compiled openjump jar here:
>> >
>> >
>> > https://www.dropbox.com/s/zf1eshbiuucohck/OpenJUMP-0.0.0-rnull.jar?dl=0
>> >
>> >
>> > Cheers
>> > Alberto
>> >
>> > On 19 November 2015 at 21:56, Alberto De Luca > <mailto:berta...@gmail.com>> wrote:
>> >
>> > Hey Peppe,
>> >
>> > thank you. I know having the raster symbologies saved with the
>> project would be nice. I haven't had the chance to work on it yet and
>> honestly I've no idea about how much effort it'd required... I'll have a
>> look at it.
>> >
>> > Alberto
>> >
>> >
>> > On Thu, 19 Nov 2015 19:12 Giuseppe Aruta > <mailto:giuseppe.ar...@gmail.com>> wrote:
>> >
>> > Nice addiction to Raster Style, Alberto!
>> > There are new color palettes and the possibility to save raster
>> styles as SLD files (I saw the 

Re: [JPP-Devel] New improvement on Raster Style by Alberto

[Alberto De Luca]

Thank you Peppe,

changes are now committed!

Alberto

On 17 December 2015 at 20:52, Giuseppe Aruta 
wrote:

> Hi Alberto,
> I did a couple of tests, following this schema
> a) I opened  a jump project
> b) loaded one or two raster and applied different color simbologies
> c) saved and closed the project
> d) loaded the project again
> It seems that everything works fine.
> Very nice work
> Best regards (from Chile)
> Peppe
>
> 2015-12-16 11:04 GMT+01:00 :
>
>> On 15.12.2015 18:54, Alberto De Luca wrote:
>> > Hi there.
>> >
>> > I've added today the capability to save the raster symbology in the
>> OpenJUMP project file. I'd like to ask you a couple of things though:
>> > - is it too late to add it now? I'm not sure, but I might have read in
>> some posts that the features are frozen by now;
>>
>> i called  it a soft freeze;).. so nothing made out of stone. generally,
>> as the next release is around the corner, we should clean up, translate and
>> do not start big reworks.
>>
>> adding features (alas not perfect) or fixing bugs is totally fine. we can
>> easily release a maintenance version when users stumble over show stoppers.
>>
>> i plan to release during the holidays, but hey, if it gets january
>> because we fixed/added some more that's fine for everybody i guess.
>>
>> so, no problemo.. ede
>>
>> > - if the answer is no, would someone be so kind (Peppe!!!) to test the
>> feature a bit before I commit the changes? I had to modify a few classes,
>> I'd like to be sure I haven't broken anything... If so, you can find the
>> compiled openjump jar here:
>> >
>> >
>> > https://www.dropbox.com/s/zf1eshbiuucohck/OpenJUMP-0.0.0-rnull.jar?dl=0
>> >
>> >
>> > Cheers
>> > Alberto
>> >
>> > On 19 November 2015 at 21:56, Alberto De Luca > <mailto:berta...@gmail.com>> wrote:
>> >
>> > Hey Peppe,
>> >
>> > thank you. I know having the raster symbologies saved with the
>> project would be nice. I haven't had the chance to work on it yet and
>> honestly I've no idea about how much effort it'd required... I'll have a
>> look at it.
>> >
>> > Alberto
>> >
>> >
>> > On Thu, 19 Nov 2015 19:12 Giuseppe Aruta > <mailto:giuseppe.ar...@gmail.com>> wrote:
>> >
>> > Nice addiction to Raster Style, Alberto!
>> > There are new color palettes and the possibility to save raster
>> styles as SLD files (I saw the code. I  think I will  add this option also
>> to Export file to raster plugins).
>> > I was studying your code using RasterColorEditorPanel as a
>> test. I think we can deactivate this class on next OJ realize as this last
>> is a duplicate but yours is better working.
>> > We also should start to translate before the new OJ realize
>> > Just a question: do you think it is possible for you to add the
>> capability to save raster styles also to OpenJUMP file project?
>> > Best regards and thanks
>> > Peppe
>> >
>>  
>> --
>> > ___
>> > Jump-pilot-devel mailing list
>> > Jump-pilot-devel@lists.sourceforge.net > 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
>> >
>>
>>
>> --
>> ___
>> 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
>
>
--
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] New improvement on Raster Style by Alberto

[Alberto De Luca]

Hi there.

I've added today the capability to save the raster symbology in the
OpenJUMP project file. I'd like to ask you a couple of things though:
- is it too late to add it now? I'm not sure, but I might have read in some
posts that the features are frozen by now;
- if the answer is no, would someone be so kind (Peppe!!!) to test the
feature a bit before I commit the changes? I had to modify a few classes,
I'd like to be sure I haven't broken anything... If so, you can find the
compiled openjump jar here:


https://www.dropbox.com/s/zf1eshbiuucohck/OpenJUMP-0.0.0-rnull.jar?dl=0


Cheers
Alberto

On 19 November 2015 at 21:56, Alberto De Luca  wrote:

> Hey Peppe,
>
> thank you. I know having the raster symbologies saved with the project
> would be nice. I haven't had the chance to work on it yet and honestly I've
> no idea about how much effort it'd required... I'll have a look at it.
>
> Alberto
>
> On Thu, 19 Nov 2015 19:12 Giuseppe Aruta  wrote:
>
>> Nice addiction to Raster Style, Alberto!
>> There are new color palettes and the possibility to save raster styles as
>> SLD files (I saw the code. I  think I will  add this option also to Export
>> file to raster plugins).
>> I was studying your code using RasterColorEditorPanel as a test. I think
>> we can deactivate this class on next OJ realize as this last is a duplicate
>> but yours is better working.
>> We also should start to translate before the new OJ realize
>> Just a question: do you think it is possible for you to add the
>> capability to save raster styles also to OpenJUMP file project?
>> Best regards and thanks
>> 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] New improvement on Raster Style by Alberto

[Alberto De Luca]

Hey Peppe,

thank you. I know having the raster symbologies saved with the project
would be nice. I haven't had the chance to work on it yet and honestly I've
no idea about how much effort it'd required... I'll have a look at it.

Alberto

On Thu, 19 Nov 2015 19:12 Giuseppe Aruta  wrote:

> Nice addiction to Raster Style, Alberto!
> There are new color palettes and the possibility to save raster styles as
> SLD files (I saw the code. I  think I will  add this option also to Export
> file to raster plugins).
> I was studying your code using RasterColorEditorPanel as a test. I think
> we can deactivate this class on next OJ realize as this last is a duplicate
> but yours is better working.
> We also should start to translate before the new OJ realize
> Just a question: do you think it is possible for you to add the capability
> to save raster styles also to OpenJUMP file project?
> Best regards and thanks
> 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

[JPP-Devel] Raster Styler added to OJ core

[Alberto De Luca - GeA]

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:

 
 org.openjump.core.rasterimage.styler.RasterStylesExtension
 

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

[Alberto De Luca - GeA]

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 tree>Change 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

[Alberto De Luca - GeA]

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 
. 
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 Raster>Raster 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 (Raster>Color Editor) as it was substituded by the new Raster
Image tree menu>Raster Layer Properties>Raster 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* 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 


Hi Uwe,
I checked the code of **"Raster>Raster 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 menu>Raster Layer Properties>Raster 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 mailto:uwe.dallu...@hcu-hamburg.de>>:

 ... I hope you will have nice "free" days!

 uwe

 Am 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 Properties>Raster Color Editor layer menu but not on the
 Raster>Raster 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
 mailto:uwe.dallu...@hcu-hamburg.de>
 >>:


  Hi Peppe,

  sorry for answering so late but I was on holiday :-)

  I have some problems with Raster>Raster Color Editor...
  in OJ r.4471.

  1. Open with Sextante Rast

Re: [JPP-Devel] Sextante Raster Image; Raster Layer Info; Coordinate out of bounds!

[Alberto De Luca - GeA]

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

[Alberto De Luca - GeA]

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_15&utm_medium=email&utm_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_15&utm_medium=email&utm_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

[Alberto De Luca - GeA]

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 
<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

[Alberto De Luca - GeA]

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

[Alberto De Luca - GeA]

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 Raster>Pixel 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  
panel. We should change the name of the plugin to "Info Tool".
This option makes Raster>Pixel 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 
<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

Re: [JPP-Devel] bugs on Raster Image layers

[Alberto De Luca - GeA]

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 
<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 c

Re: [JPP-Devel] bugs on Raster Image layers

[Alberto De Luca - GeA]

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 
 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

[Alberto De Luca - GeA]

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

[Alberto De Luca - GeA]

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 
<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.:

...
2775
540.4
...

@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

Re: [JPP-Devel] OJ and rasters, again

[Alberto De Luca - GeA]

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.:


...
2775
540.4
...

@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

[Alberto De Luca - GeA]

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:


   
 
   -4.320724e+003 -2.904333e+003 0 
191 191 0 255 0
   -2.904333e+003 -1.487941e+003 0 
255 0 255 255 0
   -1.487941e+003 -7.155029e+001 
255 255 0 255 127 0
   -7.155029e+001 1.344841e+003 
255 127 0 191 127 63
   1.344841e+003 2.761232e+003 191 
127 63 20 20 20
   5
   2775.2758789063
   540.42157279456
   -4.3070001602173
   580.26974362042
 
   


OpenJUMP:



   
 
   -4.307000160217285
   2775.27587890625
   540.421572794561
   580.2697436204171
 
   




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. 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 a

Re: [JPP-Devel] OJ and rasters, again

[Alberto De Luca - GeA]

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 
 
(built against OJ 1.7) and you can download the modified sources here 
.


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
http://pubads.g.doubleclick.ne

Re: [JPP-Devel] Info tool for rasters

[Alberto De Luca - GeA]

Hi everyone.

Ede:
1 - The clearImageAndRaster() method is called a few times 
inRasterImageLayer: inside the createImage(), getTileAsImage, 
getTileAsRaster(), and setVisible() methods.
2 - I had a look at the ReferencedImage framework, but I couldn't find a 
way to retrieve the actual cell values for the loaded images. In some 
places it uses GDAL to load images. Do you know how this framework 
relates to the RasterImageLayer class? Is it older, newer, could the two 
be merged?
3 - The "temporary rasters" I was talking about would be typically 
created by some raster processing plugin (like sextante), yes. The point 
would be that the user wouldn't need to specify a path for the output 
rasters.

Michaël:
4 - Multi-click/multi-selections: I hadn't thought about that. 
Multi-click could be done, it would show the values of all the clicked 
cells, instead of just the last one. Multi-selections I don't really 
know: how would you see it implemented for rasters?
5 - Retrieving cell values on demand from disk: yes, definitely an option.
6 - Memory vs. performance in other software. I've checked QGIS: the 
raster management appear totally disk-based. Opening large rasters has 
almost no impact on memory usage, and raster processing requires a path 
to the output raster. GDAL is somehow involved. ArcMap's raster 
managements too is file-based, and they enforce the use of pyramids to 
speed up raster visualization.

7 - I played a bit with the sextante tools and some big rasters using 
the r4004 release. Using the 64-bit JRE I managed to load a single 5000 
by 5000 raster, and complete a "flow accumulation" operation (memory 
usage was up to some GBs...). With the 32-bit JRE I got a "Cannot 
constuct DataBuffer"error. Additionally, opening the sextante toolbar 
and selecting the different tools was very slow, probably because 
sextante is doing some checks on the loaded raster to know what tools to 
activate.

That said, we can:
a - revise the RasterImageLayer class, and see if we can load in memory 
only what's strictly needed.
b - try to delegate the raster management to GDAL (like QGIS) that 
probably has already very sophisticated means to load only what's needed 
to display the image (or part of it) and to provide basic image 
information (min and max value, unique cell values for discrete 
rasters...) needed for rendering purposes.
c - ...?

In any case, I don't know how tools like sextante would work: would they 
need anyway at some point to load in memory the whole array of cell 
values to perform the processing? If the operation to be be made on the 
raster is cell based, there should be no problem in processing a tile at 
a time. But if the operation needs information about neighbouring cells 
too (like flow accumulation does), special precautions would be needed...

By the way, I can confirm: I have access to that "bertazza" sourceforge 
account. I don't think I've ever made any commit to the OJ project 
though... :P

Alberto

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] Info tool for rasters

[Alberto De Luca - GeA]

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

[Alberto De Luca - GeA]

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=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


--
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

[JPP-Devel] Static object in RasterImageLayer class

[Alberto De Luca - GeA]

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=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

Re: [JPP-Devel] Enhancement of raster support: proposed developments

[Alberto De Luca - GeA]

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 :
&g

Re: [JPP-Devel] Enhancement of raster support: proposed developments

[Alberto De Luca - GeA]

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

[Alberto De Luca - GeA]

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

Re: [JPP-Devel] Enhancement of raster support: proposed developments

[Alberto De Luca - GeA]

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

[JPP-Devel] Enhancement of raster support: proposed developments

[Alberto De Luca - GeA]

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] georeferencing from gvSIG

[Alberto De Luca]

Beppe,

a very limited part of the code comes from the AdB-ToolBox codebase, 
namely the class for reading the ESRI floating point file format (flt). 
In fact, as you noted, AdB-ToolBox uses GDAL for raster visualization, 
but the single raster analysis plug-ins only allow the flt as input 
format (every tool reads the flt raster from disk, regardless of the 
file being already open in AdB-Toolbox).


I agree with you: the "Read raster value" tool would be useful to get 
the value of single raster cells. I've been thinking about it, the 
proper way to do it would be to integrate it with the feature info tool 
(now used to query vector layers) to avoid two separate buttons (like in 
AdB-ToolBox). We could try to implement it when Stefan is back.


Alberto

On 13/12/2010 11:23, Giuseppe Aruta wrote:

Alberto,
Does it derive from originalAdB-ToolBox capability? I can see that the 
latter does depend on GDAL. But it would be interesting to port the 
tool "Leggi valore raster" (read raster value) from  AdB-ToolBox to 
OpenJUMP.

Thanks

Peppe

--- *Lun 13/12/10, Alberto De Luca //* ha 
scritto:



Da: Alberto De Luca 
Oggetto: Re: [JPP-Devel] georeferencing from gvSIG
A: jump-pilot-devel@lists.sourceforge.net
Data: Lunedì 13 dicembre 2010, 10:03

Michaël and Rashad,

before version 1.4, OJ could already open and visualize raster
objects. But rasters were treated as images, so once loaded and
visualized, information on pixel values was lost. Hence, no raster
analysis of any sort was possible.

Stefan and I tried to fill this gap. To avoid using 3d party code
or native DLLs (gvSIG uses GDAL for instance) we limited the
raster support to few formats, i.e. TIFF, ESRI ASCII grid and ESRI
Floating point grid. So now you should be able to read all these
formats and, more important, you have access to the actual pixel
values onche they have been loaded. As you will see, we just
started to deal with this issue, and there's great room for
improvement.

Have a look at these packages:
org.openjump.core.rasterimage
org.openjump.core.rasterimage.sextante

and in particular at these classes:
RasterImageLayer
OpenJUMPSextanteRasterLayer

Alberto



On 09/12/2010 13:07, Michaël Michaud wrote:

Hi Mohammad,

My knowledge about raster support in OpenJUMP is very limited.
Stefan Steiniger (one of the OpenJUMP projects administrator) did
most of the work to integrate Sextante raster into OpenJUMP, but
he's travelling and will not be back before several months. One
of its last work was to make OpenJUMP as compatible as possible 
with Sextante.


I think Alberto de Luca has worked on AdbToolbox (an Italian
project extending OpenJUMP raster capabilities). Maybe he can
give you some hints. And may be interesting for you to have a
close look of what has been achieved by this project.

Victor Olaya is the main developper of Sextante
(http://forge.osor.eu/projects/sextante/). First
OpenJUMP/Sextante binding plugin has been written by Sexyante
team. Last update of the binding has been made by Stefan. It is
on Sextante svn (a copy of the jar file is available via OpenJUMP
sourceforge project). I think Victor and gvSIG team work closely
and can provide help.

Note : there are several bug / feature request about raster
framework in OpenJUMP. You could have a look at them to start
familarizing with the code.

Michaël

Le 09/12/2010 12:30, Mohammed Rashad a écrit :

I checked Kosmo SAIG and I think to work on gvSIG georeferencing
which is more good (free from bugs) than Kosmo SAIG

On Thu, Dec 9, 2010 at 4:57 PM, Giuseppe Aruta
> wrote:

Hi Mohammed,
I think you should see also the source of Kosmo (SAIG). It
has a georeferencing tool, probabily derived from GvSIG.
Since Kosmo has many codes deriving to JUMP, as OpenJUMP,
you should find more (relatively) more easy job.
As I know both georeferencing tool doesn't use sextante.

Peppe

--- *Gio 9/12/10, Mohammed Rashad
/>/* ha scritto:


Da: Mohammed Rashad >
Oggetto: Re: [JPP-Devel] georeferencing from gvSIG
A: "OpenJump develop and use"
>
Data: Giovedì 9 dicembre 2010, 12:11




On Thu, Dec 9, 2010 at 4:33 PM, http://mc/compose?to=edgar.sol...@web.de>> wrote:

On 09.12.2010 12:00, Mohammed Rashad wrote:
> One question may be stupid
> Why cant we make a georeferencing module using
sextante?

Who says you can't? Feel free to do so.

Ok . I first planned to develop georef using openjump's
sextante lib
But I cant find any tutorial for learning sextante and

Re: [JPP-Devel] georeferencing from gvSIG

[Alberto De Luca]

Michaël and Rashad,

before version 1.4, OJ could already open and visualize raster objects. 
But rasters were treated as images, so once loaded and visualized, 
information on pixel values was lost. Hence, no raster analysis of any 
sort was possible.


Stefan and I tried to fill this gap. To avoid using 3d party code or 
native DLLs (gvSIG uses GDAL for instance) we limited the raster support 
to few formats, i.e. TIFF, ESRI ASCII grid and ESRI Floating point grid. 
So now you should be able to read all these formats and, more important, 
you have access to the actual pixel values onche they have been loaded. 
As you will see, we just started to deal with this issue, and there's 
great room for improvement.


Have a look at these packages:
org.openjump.core.rasterimage
org.openjump.core.rasterimage.sextante

and in particular at these classes:
RasterImageLayer
OpenJUMPSextanteRasterLayer

Alberto



On 09/12/2010 13:07, Michaël Michaud wrote:

Hi Mohammad,

My knowledge about raster support in OpenJUMP is very limited.
Stefan Steiniger (one of the OpenJUMP projects administrator) did most 
of the work to integrate Sextante raster into OpenJUMP, but he's 
travelling and will not be back before several months. One of its last 
work was to make OpenJUMP as compatible as possible  with Sextante.


I think Alberto de Luca has worked on AdbToolbox (an Italian project 
extending OpenJUMP raster capabilities). Maybe he can give you some 
hints. And may be interesting for you to have a close look of what has 
been achieved by this project.


Victor Olaya is the main developper of Sextante 
(http://forge.osor.eu/projects/sextante/). First OpenJUMP/Sextante 
binding plugin has been written by Sexyante team. Last update of the 
binding has been made by Stefan. It is on Sextante svn (a copy of the 
jar file is available via OpenJUMP sourceforge project). I think 
Victor and gvSIG team work closely and can provide help.


Note : there are several bug / feature request about raster framework 
in OpenJUMP. You could have a look at them to start familarizing with 
the code.


Michaël

Le 09/12/2010 12:30, Mohammed Rashad a écrit :
I checked Kosmo SAIG and I think to work on gvSIG georeferencing 
which is more good (free from bugs) than Kosmo SAIG


On Thu, Dec 9, 2010 at 4:57 PM, Giuseppe Aruta 
mailto:giuseppe_ar...@yahoo.it>> wrote:


Hi Mohammed,
I think you should see also the source of Kosmo (SAIG). It has a
georeferencing tool, probabily derived from GvSIG. Since Kosmo
has many codes deriving to JUMP, as OpenJUMP, you should find
more (relatively) more easy job.
As I know both georeferencing tool doesn't use sextante.

Peppe

--- *Gio 9/12/10, Mohammed Rashad /mailto:mohammedrasha...@gmail.com>>/* ha scritto:


Da: Mohammed Rashad mailto:mohammedrasha...@gmail.com>>
Oggetto: Re: [JPP-Devel] georeferencing from gvSIG
A: "OpenJump develop and use"
mailto:jump-pilot-devel@lists.sourceforge.net>>
Data: Giovedì 9 dicembre 2010, 12:11




On Thu, Dec 9, 2010 at 4:33 PM, http://mc/compose?to=edgar.sol...@web.de>> wrote:

On 09.12.2010 12:00, Mohammed Rashad wrote:
> One question may be stupid
> Why cant we make a georeferencing module using sextante?

Who says you can't? Feel free to do so.

Ok . I first planned to develop georef using openjump's
sextante lib
But I cant find any tutorial for learning sextante and after
some googling I found that gvsig uses sextante raster for the
georeferencing
So I thought to use it.

If you can help for start I can stick to openjump only.

As long as there is no problem from oj devs I can get into gvsig


My Plan is this:
Add gvsig georeferencing modules to OpenJump and the to make
the modules good for OJ.
If the first step of adding georeferencer to OpenJump is done.
I can easily know which files are need and what is their
functionality and all.
And finally we will have georeferencer and raster libraray
independent og gvSIG or others.

May I know your and other developers opinion,
suggestions,comments for my work

Only changes to oj's current core are a matter of the
community. What extensions you create is up to you.

ede


--
This SF Dev2Dev email is sponsored by:

WikiLeaks The End of the Free Internet
http://p.sf.net/sfu/therealnews-com
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
<http://mc/compose?to=jump-pilot-de...@lists.sourceforge

Re: [JPP-Devel] naming of raster loader/processing

[Alberto De Luca]

  Stefan and Peppe,

I also believe that the word "Sextante" could be dropped in favour of 
something like "Raster grid". Maybe we could keep a reference to 
sextante in the description statement at the top of the "Open..." window?

About the "Raster color editor" tool, don't you think it's still too 
immature? Maybe it's release could be deferred to 1.4.1?

Alberto

On 27/09/2010 12:55, Stefan Steiniger wrote:
> Hei Peppe,
>
> thanks for your thoughts.
> on a) I would focuss on 1.4.1?
> on b) good question... the question is do people understand that loading
> an image is something different than loading a sextante raster. Since
> the functions of the Raster menu only work with the latter. Maybe your
> suggestion to add "grid" makes it clear?
>
> or should we just remove the word "sextante"? On the other hand, If
> people want to work with Sextante, they can only use the Sextante Raster
> option. So this link would be lost.
>
> any comments by others?
>
> stefan
>
> Giuseppe Aruta schrieb:
>> Hi Stefan,
>> thanks for the comment. I have been far away and now I am checking the
>> new functions for OJ 1.4.
>> Justa a couple of thought.
>> a) Sextante Raster layer menu have no icons, like regular Layer menu. It
>> would be nice to add some (if possible) for 1.4 or 1.4.1.
>> b) thanks for  the new Raster tools! But this make a bit confusion to
>> newbies to what to use: regular imagery tool? The so called "Sextante
>> Raster". I wonder if we could abandon that denomination ("Sextante
>> Raster") and adopt a more general one ("Raster grid") on Load File Window.
>>
>> regards
>>
>> Peppe
>>
>> --- *Dom 26/9/10, Stefan Steiniger //* ha scritto:
>>
>>
>>  Da: Stefan Steiniger
>>  Oggetto: [JPP-Devel] towards version 1.4 - translators needed
>>  A: "List for discussion of JPP development and use."
>>  ,
>>  openjump-us...@googlegroups.com
>>  Data: Domenica 26 settembre 2010, 17:41
>>
>>  Hei all,
>>
>>  now that we did some clean-ups this weekend (thanks to Ede&
>>  Michael), I
>>  wonder if we should do now:
>>  (i) a feature freeze (no more new functions)
>>  (ii) only bug fixing of bugs that may be found now (the ones major and
>>  easy to fix, i.e. where fixes are not impacting other stuff - otherwise
>>  there is room for 1.4.1)
>>  (iii) add missing translation of new functions.
>>
>>  With respect to the latter point: As far as I remember we have complete
>>  translations for: English,  French, Spannish, Italian, German and
>>  (almost) Finnish.
>>
>>  I think (brazilian) Portugese is the  most important one left (from my
>>  perspective). And we can ask Christiano Almeida (in a private email) if
>>  he would be willing/has time to do it again. Other languages that
>>  should
>>  be updated are Chinese (who?) and Japanese (Hisaji?), Hungarian
>>  (who?),...
>>
>>  If someone wants to help with those translations - please write me/us
>>  (Michael, Stefan, etc).
>>
>>  Finally, if that goes fast enough I can do a release middle of October
>>  (focussing on 15th onward...) - before I start traveling.
>>
>>  any comments/suggestions?
>>
>>  cheers,
>>  stefan
>>
>>  
>> --
>>  Start uncovering the many advantages of virtual appliances
>>  and start using them to simplify application deployment and
>>  accelerate your shift to cloud computing.
>>  http://p.sf.net/sfu/novell-sfdev2dev
>>  ___
>>  Jump-pilot-devel mailing list
>>  Jump-pilot-devel@lists.sourceforge.net
>>  
>>  https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>
>>
>>
>> 
>>
>> --
>> Start uncovering the many advantages of virtual appliances
>> and start using them to simplify application deployment and
>> accelerate your shift to cloud computing.
>> http://p.sf.net/sfu/novell-sfdev2dev
>>
>>
>> 
>>
>> ___
>> Jump-pilot-devel mailing list
>> Jump-pilot-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> --
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>

--
Start u

Re: [JPP-Devel] SextanteRasterLayer, pixel values and visualization

[Alberto De Luca]

 Stefan,

- with regards to the ascii grid displacement problem, there was 
actually an error in reading the header values (when handling the corner 
vs. centre origin position). I attach to this email 2 new java files 
that should be ok (the flt grid code had the same problem). When I have 
time (sic!) I might try to reorganize the two now independent classes in 
one abstract class and 2 subclasses. Let me know if things are ok now. 
If not, could you please send me the ascii grid that's giving you 
problems, so I can test on it?


- incidentally: I've noticed that when a grid file is read by the 
AddRasterImageLayerWizard class, if a world file is not found the method 
#getGeoReferencing will generate one for you. This could be dangerous 
because next time you open the raster, the georeferencing information 
are read from the world file and not from the raster. So if the file 
(say an ASCII GRID) has been modified in terms of georeferencing, it 
will be loaded in the wrong position. What do you reckon?


- the javax.swing.GroupLayout is a standard feature in Java SE 6 
(http://download-llnw.oracle.com/javase/6/docs/api/javax/swing/GroupLayout.html). 
I can rewrite the plug in to avoid SE 6 classes if you want. Let me know.


I'm going back to raster symbology as soon as I can. In the meantime, 
thank you for your help.


Alberto


On 10/08/2010 21:38, Stefan Steiniger wrote:

so, I think I could fix the problem.
What I do now is a complete reload of the image when getRasterData() is
called (but not replacing the image4display). This way I get sure that
always the rasterdata are delivered to Sextante which seemed to be the
problem.

While testing I noticed that when I load an ascii grid and calculate the
contours of that grid with sextante [own plugin that accesses the
sextante function], then the delivered contours are displaced in the
location (don't fit with the raster anymore). Not sure where this is to
be attributed to?

But when I calculate contours for KernelDensity raster (tif) that I
created earlier out of points, then the contours seem to be in the right
place. So maybe its some referencing info

Alberto, could you check that?

I hope tomorrows nightly build is fine with all the raster stuff

stefan

Stefan Steiniger wrote:

Hei Alberto,

ok.. I have a problem here.
I needed to revert some changes (dynamic loading etc).
I am not sure what is going on, but if I do now some calculations I
don't get proper reference to the rasters/layerable.

So sometimes I have no reference and in other instance after the
processing is done and results are returned... those results are
shifted. It even happens with the convert to polygons function.
Interestingly this faulty behaviour is visible when I open the raster
color editor. if it contains no further elements, just the name, then
something is wrong.

However, if I use from the raster layer context menu the function:
"Export Envelope as geometry", then I get the correct reference back.

not sure what happens here...

stefan

Stefan Steiniger wrote:

me again,

I don't have
javax.swing.GroupLayout

where is that from? I have only GridBagLayout from java.awt.*

stefan

Stefan Steiniger wrote:

I actually just see that the Properties dialog of the raster layer has a
transparency checkbox

stefan

Stefan Steiniger wrote:

Hei Alberto,

I changed the RasterImageLayer class to allow for dynamic loading.
I haven't tested fully if it works as expected. Can you have a look.
With respect to this I chose now some arbitrary values for
maxPixelsForFastDisplayMode
so we can change it...

I have also added the changes to read ASCII grids.

Also if you want I can give you write access to our SVN. I think you
will do the right thing... ;)

next I will look at the coloring.
Have a good 2 weeks (holidays I assume ;).

stefan

Alberto De Luca wrote:

--
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel



--
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel



--
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
__

Re: [JPP-Devel] SextanteRasterLayer, pixel values and visualization

[Alberto De Luca]

 Stefan,

thank you for your plug-in, I'm looking forth to have a look at it. And 
about trasparency, I believe that something can be done with the 
RasterImageLayer class, I'll give it a try...
I'll be away for 2 weeks, so I hope I'll be able to get back to this 
stuff when I'm back.


Alberto

On 05/08/2010 19:05, Stefan Steiniger wrote:

Hei Alberto,

i-loading small images:
interesting proposal, need to look at it when I have time. (still 
hoping for the weekend)


ii-coloring:
the coloring is similar to what I did based on Paul Plouy's code - so 
I guess this is the way to go. I zip all classes and attach them. It 
contains also a color editor from pirol, but I didn't use it yet.


iii-Transparency for no-data is also an open issue - don't know if 
that info is somewhere stored with RasterImageLayer. In Sextante it is...



cheers,
stefan

Alberto De Luca wrote:

 Stefan,

thank you for your quick reply. A couple of things about raster display:

1) when panning, only small images are reloaded. To avoid this, in 
RasterImageLayer.java we could just call #setNeedToKeepImage(true) 
when the following condition is true (around line 300):


this.origImageWidth * this.origImageHeight) < 
RasterImageLayer.getMaxPixelsForFastDisplayMode() // faster 
display (uses more RAM) for small images


This way, we'd speed up the display of small images without the risk 
of finishing memory up.


2) The parameter maxPixelsForFastDisplayMode has a fixed value of 
25. Maybe we could make this value dependent on available memory, 
so the concept of "small image" won't be absolute but dependent on 
system resources.



With respect to raster symbology, I'd be interested to see your work. 
I've done a bit of work on raster symbology myself, it's just 
preliminary work, but I'd like to share it with you to see if it can 
be useful. I'm attaching here just a simple plug-in (source and jar 
in the rar archive) that allows to chose from a list of color models 
and repaints the selected raster consequently using a stretch 
renderer. There is only one color model available, and the color 
values are hardcoded. So you just select a raster layer from the 
layer list, start the plug-in from the tools menu, pick a color model 
and hit ok. The only problem is that you need to zoom in or out to 
see the changes in raster symbology! There used to be a method in the 
RasterImageLayer class, #forceRepaint that did the refresh, but I 
can't find it anymore... Plus I need to figure out how to show nodata 
cells as transparent. If you find this approach acceptable, I'd like 
to extend the tool so to allow the user to create and edit color 
models, both for stretched renderers and for class renderers. The 
models would then be saved as ascii filed (xml maybe).


Alberto

On 04/08/2010 18:57, Stefan Steiniger wrote:

Hei Alberto,

I hope to integrate your changes towards the weekend - if that works 
for

you.
And yes, I noticed too that the images are (most often) read for very
pan or zoom operation to save memory. I discovered this when I did the
coloring of the image and when I did a pan all the colors where gone -
so I need to set

 layer.setNeedToKeepImage(true);

and then it is not reloaded from file.
However, so the easy fix may be to just set this option right after
loading the file in #loadImage(). But then we might run into memory
problems if several images are loaded... need to think about it.

but if you have suggestions let me know.

stefan

Alberto De Luca wrote:

  Stefan,

I had a look at your work, it seems great. To carry it a bit further I
wrote a new class (GridAscii) to add reading capabilities for the  
ESRI

ASCII GRID format. Consequently, I modified the following classes:

AddRasterImageLayerWizard.java
RasterImageLayer.java
SelectRasterImageFilePanel.java

I also did a bit of clean-up to the GridFloat class: following your
work, I replaced the double[][] array with a Raster object. So you can
now read the raster directly from GridFloat (and GridAscii as well)
without need of any conversion. You can find all the java files 
attached

to this email.

It seems to me that the RasterImageLayer class makes a very 
conservative
use of memory, favouring disk access to memory consumption. I was 
doing
some tests using a 2000x2000 ASCII GRID file (roughly 35 MB on 
disk) and

noticed that it is read 2 times from disk during the loading phase
(because it's big, smaller images are read just once). Plus, if I want
to retrieve the pixel values later, the image is read again from disk.
This can slow things down quite a bit, do you think we could come up
with a faster solution?

Thanks a bunch
Alberto



On 03/08/2010 19:04, Stefan Steiniger wrote:

Hei Alberto,

I did some changes to the model yesterday night.
Instead of a double array I used "Raster".
I adde getRasterData() to the RasterImageLayer cl

Re: [JPP-Devel] SextanteRasterLayer, pixel values and visualization

[Alberto De Luca]

 Stefan,

thank you for your quick reply. A couple of things about raster display:

1) when panning, only small images are reloaded. To avoid this, in 
RasterImageLayer.java we could just call #setNeedToKeepImage(true) when 
the following condition is true (around line 300):


this.origImageWidth * this.origImageHeight) < 
RasterImageLayer.getMaxPixelsForFastDisplayMode() // faster display 
(uses more RAM) for small images


This way, we'd speed up the display of small images without the risk of 
finishing memory up.


2) The parameter maxPixelsForFastDisplayMode has a fixed value of 
25. Maybe we could make this value dependent on available memory, so 
the concept of "small image" won't be absolute but dependent on system 
resources.



With respect to raster symbology, I'd be interested to see your work. 
I've done a bit of work on raster symbology myself, it's just 
preliminary work, but I'd like to share it with you to see if it can be 
useful. I'm attaching here just a simple plug-in (source and jar in the 
rar archive) that allows to chose from a list of color models and 
repaints the selected raster consequently using a stretch renderer. 
There is only one color model available, and the color values are 
hardcoded. So you just select a raster layer from the layer list, start 
the plug-in from the tools menu, pick a color model and hit ok. The only 
problem is that you need to zoom in or out to see the changes in raster 
symbology! There used to be a method in the RasterImageLayer class, 
#forceRepaint that did the refresh, but I can't find it anymore... Plus 
I need to figure out how to show nodata cells as transparent. If you 
find this approach acceptable, I'd like to extend the tool so to allow 
the user to create and edit color models, both for stretched renderers 
and for class renderers. The models would then be saved as ascii filed 
(xml maybe).


Alberto

On 04/08/2010 18:57, Stefan Steiniger wrote:

Hei Alberto,

I hope to integrate your changes towards the weekend - if that works for
you.
And yes, I noticed too that the images are (most often) read for very
pan or zoom operation to save memory. I discovered this when I did the
coloring of the image and when I did a pan all the colors where gone -
so I need to set

 layer.setNeedToKeepImage(true);

and then it is not reloaded from file.
However, so the easy fix may be to just set this option right after
loading the file in #loadImage(). But then we might run into memory
problems if several images are loaded... need to think about it.

but if you have suggestions let me know.

stefan

Alberto De Luca wrote:

  Stefan,

I had a look at your work, it seems great. To carry it a bit further I
wrote a new class (GridAscii) to add reading capabilities for the  ESRI
ASCII GRID format. Consequently, I modified the following classes:

AddRasterImageLayerWizard.java
RasterImageLayer.java
SelectRasterImageFilePanel.java

I also did a bit of clean-up to the GridFloat class: following your
work, I replaced the double[][] array with a Raster object. So you can
now read the raster directly from GridFloat (and GridAscii as well)
without need of any conversion. You can find all the java files attached
to this email.

It seems to me that the RasterImageLayer class makes a very conservative
use of memory, favouring disk access to memory consumption. I was doing
some tests using a 2000x2000 ASCII GRID file (roughly 35 MB on disk) and
noticed that it is read 2 times from disk during the loading phase
(because it's big, smaller images are read just once). Plus, if I want
to retrieve the pixel values later, the image is read again from disk.
This can slow things down quite a bit, do you think we could come up
with a faster solution?

Thanks a bunch
Alberto



On 03/08/2010 19:04, Stefan Steiniger wrote:

Hei Alberto,

I did some changes to the model yesterday night.
Instead of a double array I used "Raster".
I adde getRasterData() to the RasterImageLayer class. Subsequently I
also changed the retrieval method in Sextante.
I.e. instead of
 m_Raster = layer.getImage().getData();
i use now
 m_Raster = layer.getRasterData();

I have done only some preliminary tests and most of the stuff worked as
far as I can assess (i.e. I fixed broken functions). However more
testing is probably needed.

stefan

Alberto De Luca wrote:

Stefan,

thank you for you time. About your doubts:


- you change finally the image loaded. This means that the data/image
delivered to sextante will contain the scaled values.


When you need to pass over the data/image to sextante, you could always
retrieve the actual raster data. The rescaling of the data is done for
display purposes only. Sure, you couldn't instantiate an
OpenJUMPSextanteRasterLayer from a RasterImageLayer (like you do in your
class CreatePolygonGridFromSelectedImageLayerPlugIn.java), you'd need to
use a different constructor

Re: [JPP-Devel] SextanteRasterLayer, pixel values and visualization

[Alberto De Luca]

Stefan,

thank you for you time. About your doubts:

> - you change finally the image loaded. This means that the data/image
> delivered to sextante will contain the scaled values.
>
When you need to pass over the data/image to sextante, you could always 
retrieve the actual raster data. The rescaling of the data is done for 
display purposes only. Sure, you couldn't instantiate an 
OpenJUMPSextanteRasterLayer from a RasterImageLayer (like you do in your 
class CreatePolygonGridFromSelectedImageLayerPlugIn.java), you'd need to 
use a different constructor and a couple of other methods to set image 
properties and data. But still it would be feasible. Or am I missing the 
point here?
> - you assume that the data loaded have only one band, so you need only
> one array.
>
You're right. But we could replace the single array with a series of 
arrays, each of them storing the cell values of a single band. It should 
be feasible. I'd give it a try to see if it can be done. What do you reckon?

> Mhm.. not sure what to do, maybe we modify the RasterImage method such
> way that images/data with one band will always be GridFloat files?
> But then we still would need to ensure that Sextante will get the
> correct values? Or we change the Sextante interface-classes. I actually
> talked to Victor a few weeks earlier, and it may be the better option to
> have the interface classes maintained by us? [which means more work... ;)]
>
Don't know, I'd prefer to spend some more time on the topic and try to 
find a more general solution keeping the sextante classes untouched...

Thanks again
Alberto

>
> Alberto De Luca schrieb:
>
>> Stefan,
>>
>> thank you for your (not so late) answer, you told me you'd be away, so
>> no problem at all!
>>
>> I had a look at Erwan's plug in: very interesting work! Briefly, if I
>> got it right: he wrote a RasterLayer class that extends the jump Layer
>> class. He then uses some geotools classes to read the ASCII grid file,
>> and the GT GridCoverage2D class to store the raster values and
>> properties. This is a useful class, because it stores the rescaled
>> raster values as a PlanarImage (that can be passed to OJ for display),
>> but also the actual cell values (that can be retrieved anytime using the
>> appropriate method).
>>
>> On the other side, it seems to me that the OJ RasterImageLayer class
>> stores only the image information. But I think it shouldn't be difficult
>> to add a field (and a getter) to handle the raster cell data. I gave it
>> a try (only for FLT raster file handling, which I know best):
>> - I created a double[][] to store the raster values;
>> - I created a getter to get the whole array (this clearly could be
>> improved by adding direct access to single cell values);
>>
>> When an FLT is loaded:
>> - the array is filled right after the raster is read;
>> - the values are rescaled and passed over for visualization (as a b/w
>> stretched image);
>>
>> When the actual values are needed, they can be accessed via the getter.
>> This could be useful also when the image is redrawn, because it would
>> avoid the need to reload the raster form scratch.
>>
>> What do you think? Does this make any sense?
>>
>> You can find attached to this e-mail:
>> - inside the OJClasess archive the AddRasterImageLayerWizard, the
>> RasterImageLayer and the SelectRasterImageFilesPanel class that I
>> modified, plus the GridFloat class that actually reads the flt file.
>> - inside the Flt_plugin archive: a small plug in that creates a button
>> tool to inspect raster cell values (jar + src). You can try it out by
>> loading an flt raster (I included one in the archive) as a "Sextante
>> Raster Image", it should display in b/w. You can then use the tool to
>> inspect its cell values. I didn't do much testing though...
>>
>> Alberto
>>
>>
>> On 07/07/2010 05:41, Stefan Steiniger wrote:
>>  
>>> Hei Alberto,
>>>
>>> late answer but something just came to my mind.
>>> There was an ESRI Grid plugin by Erwan Bocher for OpenJUMP that allowed
>>> to display different colors for a DEM. That should be something we want
>>> - right?
>>>
>>> I think the code is here:
>>> http://geosysin.iict.ch/irstv-trac/browser/openjump/plugin/gridCoverage/org/reso/openJump/raster?rev=96
>>>
>>>
>>> can you look into it?
>>>
>>> Not sure what would be needed to make it work with OpenJUMP and the
>>> Sextante Raster. But we can do changes to the core here...
>>>
>&

Re: [JPP-Devel] SextanteRasterLayer, pixel values and visualization

[Alberto De Luca]

Larry and Steven,

sorry for bothering you, I know you're both busy... I had a deeper look 
at the RasterImageLayer class. Apparently there is a scaling function 
there (as Stefan pointed out), but for what I can understand, the image 
is read, then rescaled, then added to a Layerable. This means that the 
Layerable stores the already scaled cell values and, if the actual cell 
values are needed, the image needs to be reloaded.


I don't see how this model can be tweaked to have on one side the cell 
values stored in memory and on the other a Layerable that can be 
rendered properly. What do you reckon? Please tell me I'm wrong.


Thanks
Alberto

On 29/06/2010 16:32, Larry Becker wrote:

Hi Alberto,

  I did take a look at the render architecture to see how it might be 
done, but unfortunately I don't have a lot of time right now to help 
with this effort so any advice I have is only a guess, but I think it 
might have to happen in the image layer's paint method.


Larry

On Tue, Jun 29, 2010 at 2:01 AM, Alberto De Luca 
mailto:i...@geomaticaeambiente.it>> wrote:


Stefan and Larry,

thank you for your help. Unfortunately I'm not an expert either,
so I'm
really not sure about what to do. I kind of like Larry's approach
(but I
need to think about it to see if I can work something out of it). I'll
have a deeper look at the pirol classes too...

Alberto

On 28/06/2010 21:49, Stefan Steiniger wrote:
> actually.. wasn't there a scaling function somewehere in the
pirol classes?
    > so the place to correct is in those?
>
> Alberto De Luca schrieb:
>
>> Dear OJ developers,
>>
>> I was working on the Sextante classes, trying to enhance raster
support
>> and visualization capabilities. Having a powerful raster
management is
>> important so we can port to OJ all the raster plugins we
developed for
>> the OJ-derived AdB-ToolBox (we exchanged some emails on the topic a
>> while ago).
>>
>> So, as a first attempt, I tried to add ESRI FLT raster support,
adding
>> some lines of code to the RasterImageLayer class. I am here
facing a
>> dilemma though.
>>
>> The loadImage method returns a planarimage, which is then
displayed on
>> the screen.
>> If I read the FLT file into a TiledImage whose SampleModel is
>> DataBuffer.TYPE_FLOAT (to match the data model of the FLT file) and
>> return it to be displayed, OJ loads it ok, but the raster
displayed is
>> completely blank. I know it's there because I can export its
envelope
>> and I can read cell values (using the OpenJUMPSextanteRasterLayer
>> class), values that exactly match the values stored in the FLT
file.
>> If after creating the TiledImage I rescale it into a 0-255 range
>> PlanarImage, I can display it ok (as a grayscale for example)
but then
>> when I read the cell values from the raster layer, they're clearly
>> different from the original FLT values.
>>
>> My question is: is there a way to have a correct visualization
while
>> maintaining access to the actual cell values? In
>> www.lac.inpe.br/JIPCookbook/2200-display-surrogate.jsp
<http://www.lac.inpe.br/JIPCookbook/2200-display-surrogate.jsp>
>> <http://www.lac.inpe.br/JIPCookbook/2200-display-surrogate.jsp>
 they
>> suggest the use of the javax.media.jai.iterator.RandomIter class to
>> access cell values after the image has been rescaled. Would this be
>> appropriate in OJ?
>>
>> In the attached GridFloat.java you can find the code used to
read the
>> FLT grid (see the readGrid and the getPlanarImage methods). Also
>> attached you can find my modified RasterImageLayer class (see in
>> particular the loadImage method).
>>
>> Please consider I'm not a good programmer, so I might just be on a
>> completely wrong track...
>> Thanks
>> Alberto
>>
>>
>>
>>
>>

>>
>>

--
>> This SF.net email is sponsored by Sprint
>> What will you do first with EVO, the first 4G phone?
>> Visit sprint.com/first <http://sprint.com/first> --
http://p.sf.net/sfu/sprint-com-first
>>
>>
>>

>>
>> _

Re: [JPP-Devel] SextanteRasterLayer, pixel values and visualization

[Alberto De Luca]

Stefan and Larry,

thank you for your help. Unfortunately I'm not an expert either, so I'm 
really not sure about what to do. I kind of like Larry's approach (but I 
need to think about it to see if I can work something out of it). I'll 
have a deeper look at the pirol classes too...

Alberto

On 28/06/2010 21:49, Stefan Steiniger wrote:
> actually.. wasn't there a scaling function somewehere in the pirol classes?
> so the place to correct is in those?
>
> Alberto De Luca schrieb:
>
>> Dear OJ developers,
>>
>> I was working on the Sextante classes, trying to enhance raster support
>> and visualization capabilities. Having a powerful raster management is
>> important so we can port to OJ all the raster plugins we developed for
>> the OJ-derived AdB-ToolBox (we exchanged some emails on the topic a
>> while ago).
>>
>> So, as a first attempt, I tried to add ESRI FLT raster support, adding
>> some lines of code to the RasterImageLayer class. I am here facing a
>> dilemma though.
>>
>> The loadImage method returns a planarimage, which is then displayed on
>> the screen.
>> If I read the FLT file into a TiledImage whose SampleModel is
>> DataBuffer.TYPE_FLOAT (to match the data model of the FLT file) and
>> return it to be displayed, OJ loads it ok, but the raster displayed is
>> completely blank. I know it's there because I can export its envelope
>> and I can read cell values (using the OpenJUMPSextanteRasterLayer
>> class), values that exactly match the values stored in the FLT file.
>> If after creating the TiledImage I rescale it into a 0-255 range
>> PlanarImage, I can display it ok (as a grayscale for example) but then
>> when I read the cell values from the raster layer, they're clearly
>> different from the original FLT values.
>>
>> My question is: is there a way to have a correct visualization while
>> maintaining access to the actual cell values? In
>> www.lac.inpe.br/JIPCookbook/2200-display-surrogate.jsp
>> <http://www.lac.inpe.br/JIPCookbook/2200-display-surrogate.jsp>  they
>> suggest the use of the javax.media.jai.iterator.RandomIter class to
>> access cell values after the image has been rescaled. Would this be
>> appropriate in OJ?
>>
>> In the attached GridFloat.java you can find the code used to read the
>> FLT grid (see the readGrid and the getPlanarImage methods). Also
>> attached you can find my modified RasterImageLayer class (see in
>> particular the loadImage method).
>>
>> Please consider I'm not a good programmer, so I might just be on a
>> completely wrong track...
>> Thanks
>> Alberto
>>
>>
>>
>>
>> 
>>
>> --
>> This SF.net email is sponsored by Sprint
>> What will you do first with EVO, the first 4G phone?
>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>>
>>
>> 
>>
>> ___
>> Jump-pilot-devel mailing list
>> Jump-pilot-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>  
> --
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] AdB-ToolBox: a word about future developments

[Alberto De Luca]

Stefan,

I had a look at the sextante classes you included in you sstein branch. 
They look promising. There is an easy way to access raster cell values, 
and I also had a go trying to adapt one of our plug-ins to use these 
classes. It worked. Actually, instead of modifying the plug-in code I 
created a method allowing the plug-in to read the cell values from the 
sextante layer. I know it's not an elegant solution, but it's the most 
practical and quick.


I still have some things I'd like to clarify: 1) to implement symbology 
management for raster, would it be needed to modify the sextante 
classes? Or can it be done in some other ways? 2) how could be added 
support for different raster formats?


And one more dumb question? How can I share files with the list members?

Cheers
Alberto


On 08/02/2010 23:51, Stefan Steiniger wrote:

Hei Michael, Alberto and Larry,

yep. What I was suggesting is to use IRasterLayer and the related 
generic classes and basically copy them with a slight name change to 
avoid confusion [1]. This way we could develop on raster functionality 
based on the sextante interfaces and access classes.
I.e. it was not just about loading raster files, because the sextante 
raster file is just a normal tiff image too, but loaded with Pirols 
plugin, which is what the Sextante-OJ interface needs as input.


With respect to Albertos question: yes, we may need to update them 
from time to time. But i think these classes will not have much 
changes in the future.


In case you want to have a look at the classes I did a commit of those 
to a new branch: /branches/sstein/


the classes are to be found in
org.openjump.core.rasterimage.sextante.*

stefan

[1] I think I changed only the name of the Sextante class 
OpenJUMPRasterLayer to OpenJUMPSextanteRasterLayer , which provides a 
way to convert openjump data (raster and vector) in (abstract) 
sextante datatypes.


Note, I also add an example plugin that for instance converts a loaded 
raster into a vector grid. So you can see how it works


PS: btw another option would be to look into GDMS

Michaël Michaud wrote:

Hi Stefan,

Sorry, my knowledge about raster managment is very poor.
I thought you already added Sextante raster classes (File> Open> 
Image raster (Sextante))

Isn't it enough to benefit from Sextante algorithm library ?
Could you briefly explain what is missing in OpenJUMP.
 From what you and Alberto said, I understand that OpenJUMP and 
AdbToolbox have their own loaders and renderers, but there is no OJ 
interface to define how to access raster data in a way independant 
from loader implementation (maybe like IRasterLayer from Sextante) ? 
Is that the point ?


Michaël

Larry Becker a écrit :

I actually asked a couple of months ago if other people would
accept if
I commit the basic Raster classes used in Sextante. There was 
not much

exitement/repsonse ;)


Sorry for the lack of response Stefan. I just haven't had time to 
study Sextante, and didn't feel qualified to comment.


Larry



--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com


___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
   
--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] AdB-ToolBox: a word about future developments

[Alberto De Luca]

Stefan, Peppe and all,

I've always looked at the Sextante extension with interest, considering 
the vast amount of tools it includes. But to be honest, I haven't had 
the chance to study it thoroughly.


I see that OpenJUMP can already open "Sextante Raster Images", including 
TIFF images. I think though we should extend image support to other 
formats, such as ASCII GRID. I'm not an experienced programmer or 
designer either, but what I'd really like to achieve is a product where 
the raster reading capability is an independent sub-system, where 
support for different formats can be added. Regardless from the input 
format, every raster would be translated into a vector grid (as you 
suggested), and this grid would be used by every tool working on the 
raster itself. Do you think this could be accomplished building upon 
Sextante? All the plug-ins we've written could be easily tuned to accept 
vector grids as inputs in place of the Floating Point grids they need 
now. And one more question: if Sextante is "ported" to OpenJUMP, what 
happens when new versions of Sextante are released? Would it be needed 
to do the porting again?


With regards to raster symbology, we've already got some code to handle 
ramps and coloring by intervals.


About internationalization, thank you Peppe for your offer for help. As 
soon as I have some time to dedicate to it I'll make sure you get some 
work to do! ;)


Alberto



On 06/02/2010 03:00, Stefan Steiniger wrote:

Hei all,

I actually asked a couple of months ago if other people would accept if
I commit the basic Raster classes used in Sextante. There was not much
exitement/repsonse ;) However, I still think it would be a good idea, so
we could with low efforts use/adapt Sextante raster functions. So far
Sextante uses the Pirol Image plugin which is based on a buffered image.
As my current interest is on raster analysis I am open for that.

So Alberto:
Would the Sextante interface/classes work for you too? If you want I
could make a new OpenJUMP branch so you can check what I have copied
over [by now all is local].
Unfortunately I am not a good programmer nor exprienced designer, but I
found the raster implementation used in Sextante quite interesting as it
allows easy access and manipulation of rasters. However, some display
stuff on OJ's side need improvement (i.e. a grey code look-up-table)

And yes, I also wished I could see what pixel has what value - so I
programmed a plugin which generates a vector grid out of the raster.
However, Erwan programmed once a cursor tool which can display pixel
values (I think the sources are in the OrbisGIS repository for the ASCII
grid reader).

so let me know if you think that we should build on the Sextante design
as well (also with respect to all their algorithms).

stefan

Larry Becker schrieb:
   

 once the raster
 is loaded, and "translated" into an RGB image to be shown in AdB, it
 loses the actual pixel data information (it's just an RGB image). We
 think that a step forward would be to load the raster values into an
 array to be kept in memory, whose values could be used by any plug in or
 tool that needs them.


I think it would be possible to create an adapter class that uses the
existing layer dataset drivers to return an accessible data structure of
that layer's pixels, probably in a buffered image.

regards,
Larry

On Fri, Feb 5, 2010 at 5:21 AM, Alberto De Luca
mailto:i...@geomaticaeambiente.it>>  wrote:

 Hello everyone.

 As a member of the team who has been working on AdB-ToolBox in the last
 months, I'd like to address a couple of issues regarding its future
 developments: internationalization, raster management and platform
 independence. By the way, AdB-ToolBox is a piece of software, part of
 the JUMP family, whose development was originally funded by the Italian
 ministry for the environment. Their goal was to expand OpenJUMP
 features, by adding raster handling capabilities and tools specialized
 for hydrological and geomorphological analysis.

 First of all: internationalization. We are aware that the Italian-only
 interface of AdB-ToolBox has been annoying for some of you.
 Unfortunately, due to limited resources, we couldn't afford to add
 international support in the first instance. Nevertheless, we plan to
 translate interfaces to English in the near future.

 Second: raster management. AdB-ToolBox can open and visualize several
 raster formats (ASCII grid, ESRI grid, ESRI floating point grid), but
 the various plug ins only accept the ESRI floating point grid as their
 input (and output) format. This was quite convenient from a developer's
 perspective, but not as good from a user's perspective. Ideally, every
 plug in needing a raster layer among its inputs, should be able to use
 ever

[JPP-Devel] AdB-ToolBox: a word about future developments

[Alberto De Luca]

Hello everyone.

As a member of the team who has been working on AdB-ToolBox in the last 
months, I'd like to address a couple of issues regarding its future 
developments: internationalization, raster management and platform 
independence. By the way, AdB-ToolBox is a piece of software, part of 
the JUMP family, whose development was originally funded by the Italian 
ministry for the environment. Their goal was to expand OpenJUMP 
features, by adding raster handling capabilities and tools specialized 
for hydrological and geomorphological analysis.

First of all: internationalization. We are aware that the Italian-only 
interface of AdB-ToolBox has been annoying for some of you. 
Unfortunately, due to limited resources, we couldn't afford to add 
international support in the first instance. Nevertheless, we plan to 
translate interfaces to English in the near future.

Second: raster management. AdB-ToolBox can open and visualize several 
raster formats (ASCII grid, ESRI grid, ESRI floating point grid), but 
the various plug ins only accept the ESRI floating point grid as their 
input (and output) format. This was quite convenient from a developer's 
perspective, but not as good from a user's perspective. Ideally, every 
plug in needing a raster layer among its inputs, should be able to use 
every raster format that OJ can open and visualize. In other terms, the 
reading capability should be part of OJ only and, once opened, a raster 
should be passed to the plug ins as an object (just like now we can pass 
an instance of the Layer class). Presently, every plug in that needs a 
raster as an input, has to reload it from scratch, regardless the raster 
being already loaded in AdB. This is a limit of the current 
implementation of the class managing the raster layers: once the raster 
is loaded, and "translated" into an RGB image to be shown in AdB, it 
loses the actual pixel data information (it's just an RGB image). We 
think that a step forward would be to load the raster values into an 
array to be kept in memory, whose values could be used by any plug in or 
tool that needs them.
In any case, raster support cannot be an independent plug in, but must 
be made part of OJ, so that raster layers can be managed inside projects 
and queried with the standard "info tool".

Third: platform independence. Many of the AdB-ToolBox plug ins still 
need DLLs. But their number is decreasing over time, as we gradually 
port parts of software from Fortran to Java. Presently (AdB-ToolBox 
version 1.6), there are already 2 (out of 5) AdB-ToolBox extensions that 
are DLL-free, one dedicated to topographic analyses (contour lines and 
sections extraction...) and the other including some raster tools (a 
raster calculator, zonal statistics, and many others). We plan to keep 
porting code to Java, but some plug ins (the ones that are too specific 
or too complex) will be left out, due to resources limitations.

Now, I think the raster management issue is probably the one needing 
more attention, planning, discussion, and collaboration!

Thanks for your your interest in AdB-ToolBox
Alberto

--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] RasterImageLayer: how to get full file name?

[Alberto De Luca]

Dear list members,

I'm new to OJ development, sorry if my question is trivial.

I'm trying to write a piece of code that iterates through the open 
layers in OJ and, when a a raster layer is found, returns the full file 
name of the layer data source.

Unfortunately getting the data source for raster layers (which I need to 
handle through the pirol plugin) doesn't seem as simple as getting it 
for vector layers...

Any suggestion would be appreciated. I'm using OJ 1.2F.

Thanks
Alberto



-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel