[JPP-Devel] SVN: [6494] core/trunk/scripts/oj_windows.bat

2020-09-17 Thread jump-pilot-svn--- via Jump-pilot-devel
Revision: 6494
  http://sourceforge.net/p/jump-pilot/code/6494
Author:   michaudm
Date: 2020-09-17 22:30:42 + (Thu, 17 Sep 2020)
Log Message:
---
Avoid error message due to the absence of mediaLib

Modified Paths:
--
core/trunk/scripts/oj_windows.bat

Modified: core/trunk/scripts/oj_windows.bat
===
--- core/trunk/scripts/oj_windows.bat   2020-09-17 19:35:40 UTC (rev 6493)
+++ core/trunk/scripts/oj_windows.bat   2020-09-17 22:30:42 UTC (rev 6494)
@@ -36,6 +36,9 @@
 rem --- if the proxy server requires authentication uncomment and edit also 
these
 rem set JAVA_OPTS=%JAVA_OPTS% -Dhttp.proxyUser=username 
-Dhttp.proxyPass=password
 
+rem --- avoid a NoClassDefFoundError when JAI is used
+JAVA_OPTS=%JAVA_OPTS% -Dcom.sun.media.jai.disableMediaLib=true
+
 rem -- dequote path entries, just to be sure --
 call :dequote %PATH%
 set "PATH=%unquoted%"



___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


[JPP-Devel] SVN: [6493] core/trunk

2020-09-17 Thread jump-pilot-svn--- via Jump-pilot-devel
Revision: 6493
  http://sourceforge.net/p/jump-pilot/code/6493
Author:   edso
Date: 2020-09-17 19:35:40 + (Thu, 17 Sep 2020)
Log Message:
---
move essential imageio-ext components and gdal bindings back into CORE as they 
actually needed during compile time

Modified Paths:
--
core/trunk/etc/mvn/cmp_core.xml

Added Paths:
---
core/trunk/lib/imageio-ext/
core/trunk/lib/imageio-ext/gdal-2.2.0.jar
core/trunk/lib/imageio-ext/imageio-ext-gdalframework-1.3.2.jar
core/trunk/lib/imageio-ext/imageio-ext-geocore-1.3.2.jar
core/trunk/lib/imageio-ext/imageio-ext-streams-1.3.2.jar
core/trunk/lib/imageio-ext/imageio-ext-utilities-1.3.2.jar

Removed Paths:
-
core/trunk/lib/plus/imageio-ext/gdal-2.2.0.jar
core/trunk/lib/plus/imageio-ext/imageio-ext-gdalframework-1.3.2.jar
core/trunk/lib/plus/imageio-ext/imageio-ext-geocore-1.3.2.jar
core/trunk/lib/plus/imageio-ext/imageio-ext-streams-1.3.2.jar
core/trunk/lib/plus/imageio-ext/imageio-ext-utilities-1.3.2.jar

Modified: core/trunk/etc/mvn/cmp_core.xml
===
--- core/trunk/etc/mvn/cmp_core.xml 2020-09-17 12:51:48 UTC (rev 6492)
+++ core/trunk/etc/mvn/cmp_core.xml 2020-09-17 19:35:40 UTC (rev 6493)
@@ -94,13 +94,13 @@
 *.txt
   
 
-
+
   
   
 

Copied: core/trunk/lib/imageio-ext/gdal-2.2.0.jar (from rev 6449, 
core/trunk/lib/plus/imageio-ext/gdal-2.2.0.jar)
===
(Binary files differ)

Copied: core/trunk/lib/imageio-ext/imageio-ext-gdalframework-1.3.2.jar (from 
rev 6441, core/trunk/lib/plus/imageio-ext/imageio-ext-gdalframework-1.3.2.jar)
===
(Binary files differ)

Copied: core/trunk/lib/imageio-ext/imageio-ext-geocore-1.3.2.jar (from rev 
6441, core/trunk/lib/plus/imageio-ext/imageio-ext-geocore-1.3.2.jar)
===
(Binary files differ)

Copied: core/trunk/lib/imageio-ext/imageio-ext-streams-1.3.2.jar (from rev 
6441, core/trunk/lib/plus/imageio-ext/imageio-ext-streams-1.3.2.jar)
===
(Binary files differ)

Copied: core/trunk/lib/imageio-ext/imageio-ext-utilities-1.3.2.jar (from rev 
6441, core/trunk/lib/plus/imageio-ext/imageio-ext-utilities-1.3.2.jar)
===
(Binary files differ)

Deleted: core/trunk/lib/plus/imageio-ext/gdal-2.2.0.jar
===
(Binary files differ)

Deleted: core/trunk/lib/plus/imageio-ext/imageio-ext-gdalframework-1.3.2.jar
===
(Binary files differ)

Deleted: core/trunk/lib/plus/imageio-ext/imageio-ext-geocore-1.3.2.jar
===
(Binary files differ)

Deleted: core/trunk/lib/plus/imageio-ext/imageio-ext-streams-1.3.2.jar
===
(Binary files differ)

Deleted: core/trunk/lib/plus/imageio-ext/imageio-ext-utilities-1.3.2.jar
===
(Binary files differ)



___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


Re: [JPP-Devel] Error message on Monoband raster loaded as ReferencedImage or as RasterImageLayer

2020-09-17 Thread Giuseppe Aruta
Thanks Ede

Il gio 17 set 2020, 16:47  ha scritto:

> let me have a look at it over the weekend. i am fairly certain that i can
> cut out some computing which is not necessary for sextante raster, which
> might already fix this issue.
>
> ..ede
>
> On 9/17/2020 15:34, Giuseppe Aruta wrote:
> > In any case I need compare the same errors with Roberto:
> > we are working around this "bug" since a couple of days and right now we
> > cannot perfectly duplicate the same errors:
> > I have errors only on one file, anyhowI can load and view all the file,
> > included the fault one)
> > Robberto verified the error in several files of the list and was not able
> > to load and view some of them
> > Peppe
> >
> > Il giorno gio 17 set 2020 alle ore 15:29 Giuseppe Aruta <
> > giuseppe.ar...@gmail.com> ha scritto:
> >
> >> Hi Ede,
> >> sorry, I sent the message just a microsecond I received yours
> >>
> >>> how about we modify the sources eg. TIFFUtil and others instead to fit
> >> your need instead?
> >> Yes
> >>
> >>> i don't understand. you mean retrieving georeferencing values, image
> >> dimensions, both?
> >> georeferencing values. In the way sextante load files there is a first
> >> step (in AddRasterImageWizard class to understand those values without
> >> loading the image (for TIFF files) - than all the process is activated
> >> through the other classes (excuse me for my very poor way to explain)
> >>
> >>
> >> Il giorno gio 17 set 2020 alle ore 15:22  ha
> scritto:
> >>
> >>> hey Peppe,
> >>>
> >>> On 9/17/2020 14:58, Giuseppe Aruta wrote:
>  Hi Ede,
>  the class
>  com.vividsolutions.jump.workbench.imagery.geoimg.GeoReferencedRaster
> >>> (and
>  related) work very well on loading raster in sextante.
>  In order to clean up from any message error belonging to classes non
> >>> used
>  by Sextante (ReferencedImage at similar and the method .paint. I made
> a
>  copy of it (and GeoRaster class), cleaned from all those unused
> method,
>  renamed (as SextanteReferencedRaster etc) and use it instead of the
>  original to load Raster as Sextante.
> >>>
> >>> while i understand your approach here, which is good for learning and
> >>> understanding things i really do not like duplicated code in
> production.
> >>> how about we modify the sources eg. TIFFUtil and others instead to fit
> your
> >>> need instead?
> >>>
>  My idea was also to modify the class in order to have a method that
>  calculate the location of a raster without computing the image/raster.
> >>>
> >>> i don't understand. you mean retrieving georeferencing values, image
> >>> dimensions, both?
> >>>
>  I was aware to have back the same error as Roberto. But the error was
>  limited to only one file (among the one Roberto sent: Adrena070.tif)
> >>> which
>  shows some values of the cells as doubles with many decimals, possibly
>  derived from irrational number?
> >>>
> >>> give me some time to check that out. i am currently not sure what's
> going
> >>> on, but suspect some JAI operations at fault here.
> >>>
>  Now I see your new mail about commons imaging: could it be that they
> are
>  used somehow by the class GeoRaster?
> >>>
> >>> somehow, yes. but with no regard to the use via TIFFUtil class if the
> >>> forced loader is used.
> >>>
>  And this explains the similar warning?
> >>>
> >>> should be completely unrelated. ArrayIndexOutOfBoundsException are the
> >>> NPEs of array handling. pretty common if not actually every
> possibility was
> >>> thought of before implementing the code.
> >>>
> >>> ..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] Error message on Monoband raster loaded as ReferencedImage or as RasterImageLayer

2020-09-17 Thread edgar . soldin
let me have a look at it over the weekend. i am fairly certain that i can cut 
out some computing which is not necessary for sextante raster, which might 
already fix this issue.

..ede

On 9/17/2020 15:34, Giuseppe Aruta wrote:
> In any case I need compare the same errors with Roberto:
> we are working around this "bug" since a couple of days and right now we
> cannot perfectly duplicate the same errors:
> I have errors only on one file, anyhowI can load and view all the file,
> included the fault one)
> Robberto verified the error in several files of the list and was not able
> to load and view some of them
> Peppe
>
> Il giorno gio 17 set 2020 alle ore 15:29 Giuseppe Aruta <
> giuseppe.ar...@gmail.com> ha scritto:
>
>> Hi Ede,
>> sorry, I sent the message just a microsecond I received yours
>>
>>> how about we modify the sources eg. TIFFUtil and others instead to fit
>> your need instead?
>> Yes
>>
>>> i don't understand. you mean retrieving georeferencing values, image
>> dimensions, both?
>> georeferencing values. In the way sextante load files there is a first
>> step (in AddRasterImageWizard class to understand those values without
>> loading the image (for TIFF files) - than all the process is activated
>> through the other classes (excuse me for my very poor way to explain)
>>
>>
>> Il giorno gio 17 set 2020 alle ore 15:22  ha scritto:
>>
>>> hey Peppe,
>>>
>>> On 9/17/2020 14:58, Giuseppe Aruta wrote:
 Hi Ede,
 the class
 com.vividsolutions.jump.workbench.imagery.geoimg.GeoReferencedRaster
>>> (and
 related) work very well on loading raster in sextante.
 In order to clean up from any message error belonging to classes non
>>> used
 by Sextante (ReferencedImage at similar and the method .paint. I made a
 copy of it (and GeoRaster class), cleaned from all those unused method,
 renamed (as SextanteReferencedRaster etc) and use it instead of the
 original to load Raster as Sextante.
>>>
>>> while i understand your approach here, which is good for learning and
>>> understanding things i really do not like duplicated code in production.
>>> how about we modify the sources eg. TIFFUtil and others instead to fit your
>>> need instead?
>>>
 My idea was also to modify the class in order to have a method that
 calculate the location of a raster without computing the image/raster.
>>>
>>> i don't understand. you mean retrieving georeferencing values, image
>>> dimensions, both?
>>>
 I was aware to have back the same error as Roberto. But the error was
 limited to only one file (among the one Roberto sent: Adrena070.tif)
>>> which
 shows some values of the cells as doubles with many decimals, possibly
 derived from irrational number?
>>>
>>> give me some time to check that out. i am currently not sure what's going
>>> on, but suspect some JAI operations at fault here.
>>>
 Now I see your new mail about commons imaging: could it be that they are
 used somehow by the class GeoRaster?
>>>
>>> somehow, yes. but with no regard to the use via TIFFUtil class if the
>>> forced loader is used.
>>>
 And this explains the similar warning?
>>>
>>> should be completely unrelated. ArrayIndexOutOfBoundsException are the
>>> NPEs of array handling. pretty common if not actually every possibility was
>>> thought of before implementing the code.
>>>
>>> ..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] Error message on Monoband raster loaded as ReferencedImage or as RasterImageLayer

2020-09-17 Thread Giuseppe Aruta
In any case I need compare the same errors with Roberto:
we are working around this "bug" since a couple of days and right now we
cannot perfectly duplicate the same errors:
I have errors only on one file, anyhowI can load and view all the file,
included the fault one)
Robberto verified the error in several files of the list and was not able
to load and view some of them
Peppe

Il giorno gio 17 set 2020 alle ore 15:29 Giuseppe Aruta <
giuseppe.ar...@gmail.com> ha scritto:

> Hi Ede,
> sorry, I sent the message just a microsecond I received yours
>
> >how about we modify the sources eg. TIFFUtil and others instead to fit
> your need instead?
> Yes
>
> >i don't understand. you mean retrieving georeferencing values, image
> dimensions, both?
> georeferencing values. In the way sextante load files there is a first
> step (in AddRasterImageWizard class to understand those values without
> loading the image (for TIFF files) - than all the process is activated
> through the other classes (excuse me for my very poor way to explain)
>
>
> Il giorno gio 17 set 2020 alle ore 15:22  ha scritto:
>
>> hey Peppe,
>>
>> On 9/17/2020 14:58, Giuseppe Aruta wrote:
>> > Hi Ede,
>> > the class
>> > com.vividsolutions.jump.workbench.imagery.geoimg.GeoReferencedRaster
>> (and
>> > related) work very well on loading raster in sextante.
>> > In order to clean up from any message error belonging to classes non
>> used
>> > by Sextante (ReferencedImage at similar and the method .paint. I made a
>> > copy of it (and GeoRaster class), cleaned from all those unused method,
>> > renamed (as SextanteReferencedRaster etc) and use it instead of the
>> > original to load Raster as Sextante.
>>
>> while i understand your approach here, which is good for learning and
>> understanding things i really do not like duplicated code in production.
>> how about we modify the sources eg. TIFFUtil and others instead to fit your
>> need instead?
>>
>> > My idea was also to modify the class in order to have a method that
>> > calculate the location of a raster without computing the image/raster.
>>
>> i don't understand. you mean retrieving georeferencing values, image
>> dimensions, both?
>>
>> > I was aware to have back the same error as Roberto. But the error was
>> > limited to only one file (among the one Roberto sent: Adrena070.tif)
>> which
>> > shows some values of the cells as doubles with many decimals, possibly
>> > derived from irrational number?
>>
>> give me some time to check that out. i am currently not sure what's going
>> on, but suspect some JAI operations at fault here.
>>
>> > Now I see your new mail about commons imaging: could it be that they are
>> > used somehow by the class GeoRaster?
>>
>> somehow, yes. but with no regard to the use via TIFFUtil class if the
>> forced loader is used.
>>
>> >And this explains the similar warning?
>>
>> should be completely unrelated. ArrayIndexOutOfBoundsException are the
>> NPEs of array handling. pretty common if not actually every possibility was
>> thought of before implementing the code.
>>
>> ..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] Error message on Monoband raster loaded as ReferencedImage or as RasterImageLayer

2020-09-17 Thread Giuseppe Aruta
Hi Ede,
sorry, I sent the message just a microsecond I received yours

>how about we modify the sources eg. TIFFUtil and others instead to fit
your need instead?
Yes

>i don't understand. you mean retrieving georeferencing values, image
dimensions, both?
georeferencing values. In the way sextante load files there is a first step
(in AddRasterImageWizard class to understand those values without loading
the image (for TIFF files) - than all the process is activated through the
other classes (excuse me for my very poor way to explain)


Il giorno gio 17 set 2020 alle ore 15:22  ha scritto:

> hey Peppe,
>
> On 9/17/2020 14:58, Giuseppe Aruta wrote:
> > Hi Ede,
> > the class
> > com.vividsolutions.jump.workbench.imagery.geoimg.GeoReferencedRaster
> (and
> > related) work very well on loading raster in sextante.
> > In order to clean up from any message error belonging to classes non used
> > by Sextante (ReferencedImage at similar and the method .paint. I made a
> > copy of it (and GeoRaster class), cleaned from all those unused method,
> > renamed (as SextanteReferencedRaster etc) and use it instead of the
> > original to load Raster as Sextante.
>
> while i understand your approach here, which is good for learning and
> understanding things i really do not like duplicated code in production.
> how about we modify the sources eg. TIFFUtil and others instead to fit your
> need instead?
>
> > My idea was also to modify the class in order to have a method that
> > calculate the location of a raster without computing the image/raster.
>
> i don't understand. you mean retrieving georeferencing values, image
> dimensions, both?
>
> > I was aware to have back the same error as Roberto. But the error was
> > limited to only one file (among the one Roberto sent: Adrena070.tif)
> which
> > shows some values of the cells as doubles with many decimals, possibly
> > derived from irrational number?
>
> give me some time to check that out. i am currently not sure what's going
> on, but suspect some JAI operations at fault here.
>
> > Now I see your new mail about commons imaging: could it be that they are
> > used somehow by the class GeoRaster?
>
> somehow, yes. but with no regard to the use via TIFFUtil class if the
> forced loader is used.
>
> >And this explains the similar warning?
>
> should be completely unrelated. ArrayIndexOutOfBoundsException are the
> NPEs of array handling. pretty common if not actually every possibility was
> thought of before implementing the code.
>
> ..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] Error message on Monoband raster loaded as ReferencedImage or as RasterImageLayer

2020-09-17 Thread Giuseppe Aruta
Ok,
I made this quick test:

a) I identified that in the class GeoImageFactory there is a method to
define the priority of the loader
public static int getPriority(...

b) I found this line (227, I think)

if (name.startsWith("com.vividsolutions.jump.workbench.imagery")) {
  return 10;
}
 and, following the other big ticket on commons imaging, I remembered that
one of the subpath/subclass
class com.vividsolutions.jump.workbench.imagery.graphic.CommonsImage and
similar are responsible  to read an image using Apache commons imaging.

c) I set the previous lines to
 // we've got some patched
if (name.startsWith("com.vividsolutions.jump.workbench.imagery")) {
return Prioritized.NOPRIORITY;
}
as the other JAI, imageIO etc are almost enough to load the rasters

d) I did again the test Roberto described (load the test shapefile and then
25 or 25 raster)

e) Everything was loaded with no problem. Including problematic rasters
which were giving that error message

f) I did various zooms on the problematic rasters and had no error message.
I can suppose, Watson, that the problem is that
GeoRaster/GeoReferencedRaster classes try anyhow to use Commons imaging
com.vividsolutions.jump.workbench.imagery, even if that is priorized as one
of the last, even if JAI/ImageIO etcetera can do that job even better.

I will send a modify version oj OpenJUMP (a separate
GeoRaster/GeoReferencedRaster classes for Sextante)


Il giorno gio 17 set 2020 alle ore 14:58 Giuseppe Aruta <
giuseppe.ar...@gmail.com> ha scritto:

> Hi Ede,
> the class
> com.vividsolutions.jump.workbench.imagery.geoimg.GeoReferencedRaster  (and
> related) work very well on loading raster in sextante.
> In order to clean up from any message error belonging to classes non used
> by Sextante (ReferencedImage at similar and the method .paint. I made a
> copy of it (and GeoRaster class), cleaned from all those unused method,
> renamed (as SextanteReferencedRaster etc) and use it instead of the
> original to load Raster as Sextante.
> My idea was also to modify the class in order to have a method that
> calculate the location of a raster without computing the image/raster.
> I was aware to have back the same error as Roberto. But the error was
> limited to only one file (among the one Roberto sent: Adrena070.tif) which
> shows some values of the cells as doubles with many decimals, possibly
> derived from irrational number?
>
> Now I see your new mail about commons imaging: could it be that they are
> used somehow by the class GeoRaster? And this explains the similar warning?
>
> best regards
> Peppe
>
>
>
>
> Il giorno mer 16 set 2020 alle ore 17:04 Roberto Rossi <
> roberto.ro...@unipd.it> ha scritto:
>
>> Hello Edgard,
>> here
>> you
>> can find the raster files, especially TIF+TFW
>> Usually the problem rises when I load the shapefiles
>> and
>> then several raster files.
>> Best regards
>> Roberto Rossi
>>
>> Il 16/09/2020 12:10, edgar.sol...@web.de ha scritto:
>>
>> hey Peppe,
>>
>> could you provide one or more of the problematic image files as well?
>>
>> ..ede
>>
>> On 9/16/2020 7:12, Giuseppe Aruta wrote:
>>
>> Hi Ede,
>> I also attached to this mail a more exhaustive error message.
>>
>> This is what the console shows sometimes when the error occurs in OpenJUMP. 
>> This message is not recorded into the log file.
>>  I attached to this mail 2 files: the openjump.log file generated by 
>> openjump in this moment (openjump2020Sept16.log) and the output recorded by 
>> the console (console2020Sept16.txt)
>>
>>
>> Note the yellow warning message on the bottom
>> image.png
>>
>> I didn't have problems to load/zoom etc on the raster layers except for this 
>> annoying error.
>> According to Roberrto, sometimes the error pops up when he load a raster 
>> file which  cannot be loaded or displayed into the view - this problem has 
>> never occurred to me.
>> Best regards
>> Peppe
>>
>> Il giorno mar 15 set 2020 alle ore 23:57 Giuseppe Aruta 
>> mailto:giuseppe.ar...@gmail.com> 
>> > ha scritto:
>>
>> Hi Ede,
>> I attached to this mail some of the log files.
>> The test was to load 24 raster and two vector. And zoom to the layers
>> openjump.log (provided by Roberto Rossi of University of Padua) - 
>> rasters were load as RasterImageLayers (Sextante)
>> openjump1.log is mady by me - rasters were load as RasterImageLayers 
>> (Sextante)
>> openjump2.log is mady by me - rasters were load as RefereceImageLayes 
>> (ImageIO EXT, JAI)
>> Peppe
>>
>> Il giorno mar 15 set 2020 alle ore 13:18 >  > ha scritto:
>>
>> Peppe,
>>
>> please provide the complete error stacks or even better the OJ log 
>> file ..ede
>>
>>
>> On 9/15/2020 13:14, Giuseppe Aruta wrote:
>> > Hi all
>> 

Re: [JPP-Devel] Error message on Monoband raster loaded as ReferencedImage or as RasterImageLayer

2020-09-17 Thread edgar . soldin
hey Peppe,

On 9/17/2020 14:58, Giuseppe Aruta wrote:
> Hi Ede,
> the class
> com.vividsolutions.jump.workbench.imagery.geoimg.GeoReferencedRaster  (and
> related) work very well on loading raster in sextante.
> In order to clean up from any message error belonging to classes non used
> by Sextante (ReferencedImage at similar and the method .paint. I made a
> copy of it (and GeoRaster class), cleaned from all those unused method,
> renamed (as SextanteReferencedRaster etc) and use it instead of the
> original to load Raster as Sextante.

while i understand your approach here, which is good for learning and 
understanding things i really do not like duplicated code in production. how 
about we modify the sources eg. TIFFUtil and others instead to fit your need 
instead?

> My idea was also to modify the class in order to have a method that
> calculate the location of a raster without computing the image/raster.

i don't understand. you mean retrieving georeferencing values, image 
dimensions, both?

> I was aware to have back the same error as Roberto. But the error was
> limited to only one file (among the one Roberto sent: Adrena070.tif) which
> shows some values of the cells as doubles with many decimals, possibly
> derived from irrational number?

give me some time to check that out. i am currently not sure what's going on, 
but suspect some JAI operations at fault here.

> Now I see your new mail about commons imaging: could it be that they are
> used somehow by the class GeoRaster?

somehow, yes. but with no regard to the use via TIFFUtil class if the forced 
loader is used.

>And this explains the similar warning?

should be completely unrelated. ArrayIndexOutOfBoundsException are the NPEs of 
array handling. pretty common if not actually every possibility was thought of 
before implementing the code.

..ede




___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


Re: [JPP-Devel] Error message on Monoband raster loaded as ReferencedImage or as RasterImageLayer

2020-09-17 Thread Giuseppe Aruta
Hi Ede,
the class
com.vividsolutions.jump.workbench.imagery.geoimg.GeoReferencedRaster  (and
related) work very well on loading raster in sextante.
In order to clean up from any message error belonging to classes non used
by Sextante (ReferencedImage at similar and the method .paint. I made a
copy of it (and GeoRaster class), cleaned from all those unused method,
renamed (as SextanteReferencedRaster etc) and use it instead of the
original to load Raster as Sextante.
My idea was also to modify the class in order to have a method that
calculate the location of a raster without computing the image/raster.
I was aware to have back the same error as Roberto. But the error was
limited to only one file (among the one Roberto sent: Adrena070.tif) which
shows some values of the cells as doubles with many decimals, possibly
derived from irrational number?

Now I see your new mail about commons imaging: could it be that they are
used somehow by the class GeoRaster? And this explains the similar warning?

best regards
Peppe




Il giorno mer 16 set 2020 alle ore 17:04 Roberto Rossi <
roberto.ro...@unipd.it> ha scritto:

> Hello Edgard,
> here
> you
> can find the raster files, especially TIF+TFW
> Usually the problem rises when I load the shapefiles
> and
> then several raster files.
> Best regards
> Roberto Rossi
>
> Il 16/09/2020 12:10, edgar.sol...@web.de ha scritto:
>
> hey Peppe,
>
> could you provide one or more of the problematic image files as well?
>
> ..ede
>
> On 9/16/2020 7:12, Giuseppe Aruta wrote:
>
> Hi Ede,
> I also attached to this mail a more exhaustive error message.
>
> This is what the console shows sometimes when the error occurs in OpenJUMP. 
> This message is not recorded into the log file.
>  I attached to this mail 2 files: the openjump.log file generated by openjump 
> in this moment (openjump2020Sept16.log) and the output recorded by the 
> console (console2020Sept16.txt)
>
>
> Note the yellow warning message on the bottom
> image.png
>
> I didn't have problems to load/zoom etc on the raster layers except for this 
> annoying error.
> According to Roberrto, sometimes the error pops up when he load a raster file 
> which  cannot be loaded or displayed into the view - this problem has never 
> occurred to me.
> Best regards
> Peppe
>
> Il giorno mar 15 set 2020 alle ore 23:57 Giuseppe Aruta 
> mailto:giuseppe.ar...@gmail.com> 
> > ha scritto:
>
> Hi Ede,
> I attached to this mail some of the log files.
> The test was to load 24 raster and two vector. And zoom to the layers
> openjump.log (provided by Roberto Rossi of University of Padua) - rasters 
> were load as RasterImageLayers (Sextante)
> openjump1.log is mady by me - rasters were load as RasterImageLayers 
> (Sextante)
> openjump2.log is mady by me - rasters were load as RefereceImageLayes 
> (ImageIO EXT, JAI)
> Peppe
>
> Il giorno mar 15 set 2020 alle ore 13:18   > ha scritto:
>
> Peppe,
>
> please provide the complete error stacks or even better the OJ log 
> file ..ede
>
>
> On 9/15/2020 13:14, Giuseppe Aruta wrote:
> > Hi all
> > Sometimes I try to load a monoband raster, like the one I attached 
> to this mail, and I get this message of error:
> >
> >  /(Referenced Image Exception)
> > com.vividsolutions.jump.workbench.imagery.ReferencedImageException: 
> java.lang.ArrayIndexOutOfBoundsException
> > at 
> com.vividsolutions.jump.workbench.imagery.geoimg.GeoImage.paint(GeoImage.java:293)
> > at 
> com.vividsolutions.jump.workbench.imagery.ReferencedImageStyle.paint(ReferencedImageStyle.java:61)
> > ./
> > The error points to class 
> com.vividsolutions.jump.workbench.imagery.geoimg.GeoImage
> >
> > The image is not displayed but the raster is at its right position 
> testified by the exact position of the envelope of the image.
> > I was not really interested about this bug: I usually load a dem 
> via Sextante. Until now.
> > On the newer OJ NB Roberto Rossi recognized a bug when loading 
> multiple raster dem into OpenJUMP as Sextante RasterImageLayer, with very 
> similar to the former:
> >
> > /[INFO] 2020-09-15_12:40:53.569 Avvertimento: 1048560
> > /
> > / (Array Index Out Of Bounds Exception)/
> >
> > Actually Sextante framework to load files as Sextante raster is 
> com.vividsolutions.jump.workbench.imagery.geoimg.GeoReferencedRaster
> > I wonder if the bugs are related to each other and can have a 
> common solution
> >
> > Best regards
> >
> > Peppe
> >
> >
> >
> > ___
> > 

[JPP-Devel] SVN: [6492] core/trunk/src/com/vividsolutions/jump/workbench/ui/ SplashWindow.java

2020-09-17 Thread jump-pilot-svn--- via Jump-pilot-devel
Revision: 6492
  http://sourceforge.net/p/jump-pilot/code/6492
Author:   edso
Date: 2020-09-17 12:51:48 + (Thu, 17 Sep 2020)
Log Message:
---
attach icon to SplashWindow early so the OJ icon is shown in task overview as 
opposed to the jdk default one

Modified Paths:
--
core/trunk/src/com/vividsolutions/jump/workbench/ui/SplashWindow.java

Modified: core/trunk/src/com/vividsolutions/jump/workbench/ui/SplashWindow.java
===
--- core/trunk/src/com/vividsolutions/jump/workbench/ui/SplashWindow.java   
2020-09-17 04:35:01 UTC (rev 6491)
+++ core/trunk/src/com/vividsolutions/jump/workbench/ui/SplashWindow.java   
2020-09-17 12:51:48 UTC (rev 6492)
@@ -40,7 +40,9 @@
 import javax.swing.JComponent;
 import javax.swing.JFrame;
 
+import com.vividsolutions.jump.workbench.JUMPWorkbench;
 
+
 /**
  * Based on "Java Tip 104: Make a splash with Swing" by Tony Colston
  * (http://www.javaworld.com/javaworld/javatips/jw-javatip104.html)
@@ -48,6 +50,10 @@
 public class SplashWindow extends JFrame {
 public SplashWindow(JComponent contents) {
 super();
+
+// attach icon early to prevent jdk default icon in task bar
+JUMPWorkbench.setIcon(this);
+
 setUndecorated(true);
 setCursor(new Cursor(Cursor.WAIT_CURSOR));
 if (SplashPanelV2.transparentSplash())



___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


[JPP-Devel] Fwd: [jira] [Commented] (IMAGING-265) ArrayIndexOutOfBoundsException on reading simple GeoTIFF

2020-09-17 Thread edgar . soldin
just fyi. there is an answer to the apache commons ticket

sounds like we should provide more "not working" samples?!. mono band tiffs 
come to mind. maybe on of you users could collect a sample set that is 
currently not loadable via apache commons imaging?

..ede


 Forwarded Message 
Subject: [jira] [Commented] (IMAGING-265) ArrayIndexOutOfBoundsException on 
reading simple GeoTIFF
Date: Thu, 17 Sep 2020 00:15:00 + (UTC)
From: Gary Lucas (Jira) 


[ 
https://issues.apache.org/jira/browse/IMAGING-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197298#comment-17197298
 ]

Gary Lucas commented on IMAGING-265:


It took a while, but I've identified the problem and I think that the original 
authors of TIFF were in love with complexity.

It turns out that there is a specification in the TIFF standard on how a file 
may store the RGB components in a file.  The arrangement is specified using a 
TIFF tag known as Planar Configuration and there are two variations:

You may specify them in a sequence of bytes such as
   R1, G1, B1, R2, G2, B2, R3, G3, B3,  ...  , Rn, Gn, Bn   (Planar 
Configuration 1)

But you can also split the data into separate "planes" such as
   R1, R1, R2,... Rn,G1, G2, G3,...Gn,B1, B2, B3, ...  Bn. (Planar 
Configuration 2)

The problematic image uses Planar Configuration 2.  Searching through the code, 
I don't find any evidence of Planar Configuration 2 implemented anywhere.  So 
it looks like this configuration is not currently supported by Commons Imaging.

The array bounds failure occurs because the small_world.tif file is organized 
into blocks of 8000 bytes representing strips of 20 rows 400 pixels wide.  In 
Planar Configuration 1, the code would expect to see 3 bytes per pixel, or 
24000 bytes per strip (block). In Planar Configuration 2, the data is split 
between 3 blocks of 8000 which have to be combined to get a full set of RGB 
values.  Since Commons Imaging does not recognize Planar Configuration 2 (at 
least, not yet), it thinks it has 24000 bytes to process and wackiness ensues.

THE USUAL PLEA FOR TEST DATA
I have a fix in mind that will address this particular file. But it will only 
work for files using the RGB color model and organized into strips with no data 
compression.  I could easily extend it for files organized with tiles, but I 
have no test data.   And that still leaves the issue of different photometric 
interpreters and data compression. I'm not sure that these options even matter, 
because I suspect that Planar Configuration 2 is unusual in modern data systems.

For the OpenJUMP folks:  As a temporary work-around, you can try to use 
interleaved RGB rather than the separate planes.  I know that's not much of a 
help if you're not in control of the format for the images you receive, but at 
least you will know what some images don't work.

And finally, just as a point of interest, I've attached a JPEG showing the 
3-plane content of the small world file.  I hacked Commons Imaging so that it 
wouldn't crash when I read the file.  But, clearly, I have more work to do to 
render it properly.
 !small_world_split.jpg!

> ArrayIndexOutOfBoundsException on reading simple GeoTIFF
> 
>
> Key: IMAGING-265
> URL: https://issues.apache.org/jira/browse/IMAGING-265
> Project: Commons Imaging
>  Issue Type: Bug
>  Components: Format: TIFF
>Affects Versions: 1.0-alpha2
>Reporter: edgar soldin
>Priority: Major
> Attachments: small_world.tif, small_world_split.jpg
>
>
> hi,
>  
> we on the OpenJUMP project cannot open some GeoTIFFs with commons.imaging . 
> for details you may find a ticket in our bug tracker 
> [https://sourceforge.net/p/jump-pilot/bugs/498/] .
>  
> the gist is: on loading the attached file getBufferedImage() fails with this 
> stack
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 8000Caused by: 
> java.lang.ArrayIndexOutOfBoundsException: 8000 at 
> org.apache.commons.imaging.formats.tiff.datareaders.DataReaderStrips.interpretStrip(DataReaderStrips.java:196)
>  at 
> org.apache.commons.imaging.formats.tiff.datareaders.DataReaderStrips.readImageData(DataReaderStrips.java:254)
>  at 
> org.apache.commons.imaging.formats.tiff.TiffImageParser.getBufferedImage(TiffImageParser.java:665)
>  at 
> org.apache.commons.imaging.formats.tiff.TiffDirectory.getTiffImage(TiffDirectory.java:254)
>  at 
> org.apache.commons.imaging.formats.tiff.TiffImageParser.getBufferedImage(TiffImageParser.java:469)
>  at org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1442) at 
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1335) at 
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1304) at 
> 

Re: [JPP-Devel] SVN: [6490] core/trunk/src/com/vividsolutions/jump/workbench/ui/ JTablePanel.java

2020-09-17 Thread Giuseppe Aruta
>it is as well cluttering our API
Do you mean to add a panel on JTablePanel and then to remove it on  a
plugin? I agree.
But honestly  in this moment I don't find another solution.
The time I added the class JTablePanel to OpenJUMP, I was thinking of an
easy (and uniform) way to manage data on a table  on OpenJUMP, with the
capability to export them as csv file, until now I limit the usage   to
statistics  tools (like raster histogram).
With this new tool I wanted to reuse it,  to analyze an area of a raster
and report it in table to investigate anomalies or errors on the DEM (this is
a very popular tool for students - inspired by ArcGIS Pixel Inspector

).
it should have  retained both possibilities of exporting the table  as csv
file or exporting the selection as an image layer.
(although this option duplicates the one on the Layer tree "Export part of
the image").
Feel free to do any modification you feel it can clean the code or to give
any suggestion: your opinion, as developer and custodian of the OpenJUMP
code, is immeasurably important to me, a simple geologist and teacher.
And above all, your ability to immediately identify our blunders due to
impatience and enthusiasm ;-)
Best regards
Peppe

Il giorno gio 17 set 2020 alle ore 12:40  ha scritto:

> Peppe,
>
> apart from the typo it is as well cluttering our API. let's find a cleaner
> way to achieve what you want! ..ede
>
> On 9/17/2020 6:32, jump-pilot-svn--- via Jump-pilot-devel wrote:
> > Revision: 6490
> >   http://sourceforge.net/p/jump-pilot/code/6490
> > Author:   ma15569
> > Date: 2020-09-17 04:32:14 + (Thu, 17 Sep 2020)
> > Log Message:
> > ---
> > Added a getter for all lower componets of the panel
> >
> > Modified Paths:
> > --
> > core/trunk/src/com/vividsolutions/jump/workbench/ui/JTablePanel.java
> >
> > Modified:
> core/trunk/src/com/vividsolutions/jump/workbench/ui/JTablePanel.java
> > ===
> > ---
> core/trunk/src/com/vividsolutions/jump/workbench/ui/JTablePanel.java
> 2020-09-16 22:12:30 UTC (rev 6489)
> > +++
> core/trunk/src/com/vividsolutions/jump/workbench/ui/JTablePanel.java
> 2020-09-17 04:32:14 UTC (rev 6490)
> > @@ -237,6 +237,17 @@
> >  }
> >
> >  /**
> > + * Gets all the lower components (save and query tools) of the
> > + * panel. Useful to deactivate all
> > + * @return JPanel
> > + */
> > +public JPanel getAllComponetsExceptTable() {
> > +return southPanel;
> > +}
> > +
> > +
> > +
> > +/**
> >   * Gets the FeatureCollection added to this panel. Useful if user
> want to
> >   * save it as a layer
> >   *
> >
> >
> >
> > ___
> > 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] SVN: [6490] core/trunk/src/com/vividsolutions/jump/workbench/ui/ JTablePanel.java

2020-09-17 Thread edgar . soldin
Peppe,

apart from the typo it is as well cluttering our API. let's find a cleaner way 
to achieve what you want! ..ede

On 9/17/2020 6:32, jump-pilot-svn--- via Jump-pilot-devel wrote:
> Revision: 6490
>   http://sourceforge.net/p/jump-pilot/code/6490
> Author:   ma15569
> Date: 2020-09-17 04:32:14 + (Thu, 17 Sep 2020)
> Log Message:
> ---
> Added a getter for all lower componets of the panel
>
> Modified Paths:
> --
> core/trunk/src/com/vividsolutions/jump/workbench/ui/JTablePanel.java
>
> Modified: core/trunk/src/com/vividsolutions/jump/workbench/ui/JTablePanel.java
> ===
> --- core/trunk/src/com/vividsolutions/jump/workbench/ui/JTablePanel.java  
> 2020-09-16 22:12:30 UTC (rev 6489)
> +++ core/trunk/src/com/vividsolutions/jump/workbench/ui/JTablePanel.java  
> 2020-09-17 04:32:14 UTC (rev 6490)
> @@ -237,6 +237,17 @@
>  }
>
>  /**
> + * Gets all the lower components (save and query tools) of the
> + * panel. Useful to deactivate all
> + * @return JPanel
> + */
> +public JPanel getAllComponetsExceptTable() {
> +return southPanel;
> +}
> +
> +
> +
> +/**
>   * Gets the FeatureCollection added to this panel. Useful if user want to
>   * save it as a layer
>   *
>
>
>
> ___
> 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] About CAD tool Draw a symmetric geometry

2020-09-17 Thread Rahkonen Jukka (MML)
Ok, it is the same issue that I have with some other tools with my work 
computer. The tool icons have some odd offset and clicks are not hitting the 
tooltip but a pixel that is at about 15 pixels distance. I must try to find out 
what makes just this computer to behave like that.

-Jukka-

Lähettäjä: Giuseppe Aruta 
Lähetetty: torstai 17. syyskuuta 2020 7.26
Vastaanottaja: OpenJump develop and use 
Aihe: Re: [JPP-Devel] About CAD tool Draw a symmetric geometry

Hi Jukka

the following steps work for me:
a) select the feature(s) you want to mirror
b) click on the tool "Draw a symmetric geometry"
c) in the next dialog select the option in the middle ("Select a line")
d) the cursor changes icon, put on the line you want to use and click once.
e) a small blue circle flashes on the selection point and the features are 
mirrored

Peppe

Il giorno mer 16 set 2020 alle ore 22:52 Rahkonen Jukka (MML) 
mailto:jukka.rahko...@maanmittauslaitos.fi>>
 ha scritto:
Hi,

I can mirror selected features by the line that I draw with the Draw a 
symmetric geometry tool but it should also be possible to select an existing 
line to be used as a mirror. However, I do not manage to make a selection. The 
message is always “Warning: No symmetric segment was selected”. Is there 
something special in making the selection right? I tried to use a line from the 
same layer than the features to be reflected and from another layer but the 
result is the same.

-Jukka Rahkonen-
___
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