Re: [JPP-Devel] SVN: [6461] core/trunk/src/org/openjump/core/rasterimage

[Giuseppe Aruta]

Hi Ede,
can you check if this modification fits memory problems?
a) On loading TIF (RasterImageIO and TiFFUtils class) I get the envelope
directly tiff metadata
b) on the other tools I reuse the previous method

Il giorno lun 14 set 2020 alle ore 10:49  ha scritto:

> Peppe,
>
> i noticed earlier that your image reading implementation creates a new
> Reader on every render call but thought you will notice when this becomes a
> performance issue.
>
> seeing you continue this trend with code like below i become a little
> worried ;) and suggest you try to model your approach using class instances
> keeping the reference to be reused hence saving additional file access.
> easiest would be a "caching" holding the ReferencedImageReader object in a
> HashMap with the path value as key. remember to close it properly if the
> layer is removed!
>
> this also may become a memory issue as i am not sure that all file handles
> are closed automatically this way. ..sunshine ede
>
>
> On 9/14/2020 9:51, jump-pilot-svn--- via Jump-pilot-devel wrote:
> > + /**
> > +  * Get Envelope  from file
> > +  * @param fileName
> > +  * @return Envelope
> > +  * @throws ReferencedImageException
> > +  */
> > +
> > + public static Envelope getGeoReferencing(String fileName) throws
> ReferencedImageException {
> > + GeoReferencedRaster geoRaster = new
> GeoReferencedRaster(new File(fileName).toURI().toString());
> > + return geoRaster.getEnvelope();
> > +
>
>
>
> ___
> 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] [jump-pilot:bugs] #175 Bug random behavior of Save Image to Raster

[Giuseppe Aruta via Jump-pilot-devel]

- **status**: open --> closed-fixed
- **Comment**:

It is already solved. Fixed



---

** [bugs:#175] Bug random behavior of Save Image to Raster**

**Status:** closed-fixed
**Milestone:** OJ_1.16
**Labels:** General / Other 
**Created:** Wed Feb 09, 2011 07:32 AM UTC by Anonymous
**Last Updated:** Sun Sep 13, 2020 06:33 PM UTC
**Owner:** nobody


in Sextante popup menu there is a "Save raster to image" tool. This tool has a 
random strange behaviour:

1\)  using on any color image,
It works fine and the saved file can be reopen with no problems.

2\) using on a TIF file black and white file, where white is a NO-DATA area.
it saves the file as a negative. When I try to reload the saved file, it is not 
displayed.

3\) Using on a grid file \(tested on TIF or ASC\). The file is saved with 0 
byte dimension and
It shows this error message:
\-
ava.lang.NullPointerException
at org.libtiff.jai.util.PropertyUtil.getString\(PropertyUtil.java:54\)
at org.libtiff.jai.util.JaiI18N.getString\(JaiI18N.java:28\)
at 
org.libtiff.jai.codecimpl.XTIFFImageEncoder.getImageFields\(XTIFFImageEncoder.java:246\)
at 
org.libtiff.jai.codecimpl.XTIFFImageEncoder.encode\(XTIFFImageEncoder.java:142\)
at 
org.openjump.core.ui.plugin.layer.pirolraster.SaveRasterImageAsImagePlugIn.execute\(SaveRasterImageAsImagePlugIn.java:135\)
at 
com.vividsolutions.jump.workbench.plugin.AbstractPlugIn$1.actionPerformed\(AbstractPlugIn.java:130\)
at javax.swing.AbstractButton.fireActionPerformed\(AbstractButton.java:1995\)
at 
javax.swing.AbstractButton$Handler.actionPerformed\(AbstractButton.java:2318\)
at 
javax.swing.DefaultButtonModel.fireActionPerformed\(DefaultButtonModel.java:387\)
at javax.swing.DefaultButtonModel.setPressed\(DefaultButtonModel.java:242\)
at javax.swing.AbstractButton.doClick\(AbstractButton.java:357\)
at javax.swing.plaf.basic.BasicMenuItemUI.doClick\(BasicMenuItemUI.java:1223\)
at 
javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased\(BasicMenuItemUI.java:1264\)
at java.awt.Component.processMouseEvent\(Component.java:6267\)
at javax.swing.JComponent.processMouseEvent\(JComponent.java:3267\)
at java.awt.Component.processEvent\(Component.java:6032\)
at java.awt.Container.processEvent\(Container.java:2041\)
at java.awt.Component.dispatchEventImpl\(Component.java:4630\)
at java.awt.Container.dispatchEventImpl\(Container.java:2099\)
at java.awt.Component.dispatchEvent\(Component.java:4460\)
at java.awt.LightweightDispatcher.retargetMouseEvent\(Container.java:4577\)
at java.awt.LightweightDispatcher.processMouseEvent\(Container.java:4238\)
at java.awt.LightweightDispatcher.dispatchEvent\(Container.java:4168\)
at java.awt.Container.dispatchEventImpl\(Container.java:2085\)
at java.awt.Window.dispatchEventImpl\(Window.java:2478\)
at java.awt.Component.dispatchEvent\(Component.java:4460\)
at java.awt.EventQueue.dispatchEvent\(EventQueue.java:599\)
at 
java.awt.EventDispatchThread.pumpOneEventForFilters\(EventDispatchThread.java:269\)
at 
java.awt.EventDispatchThread.pumpEventsForFilter\(EventDispatchThread.java:184\)
at 
java.awt.EventDispatchThread.pumpEventsForHierarchy\(EventDispatchThread.java:174\)
at java.awt.EventDispatchThread.pumpEvents\(EventDispatchThread.java:169\)
at java.awt.EventDispatchThread.pumpEvents\(EventDispatchThread.java:161\)
at java.awt.EventDispatchThread.run\(EventDispatchThread.java:122\)


---

Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/jump-pilot/bugs/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/jump-pilot/admin/bugs/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] [jump-pilot:bugs] #422 Bug in jython tools

[Giuseppe Aruta via Jump-pilot-devel]

- **status**: pending --> closed-fixed



---

** [bugs:#422] Bug in jython tools**

**Status:** closed-fixed
**Milestone:** OJ_1.16
**Created:** Wed Jun 01, 2016 06:13 AM UTC by michael michaud
**Last Updated:** Mon Sep 14, 2020 07:26 AM UTC
**Owner:** nobody


Some jython tools like Road arc tool and Oval tool are broken. Trying to use it 
one time also break other OpenJUMP cursor tools.
These jython tools inherit OpenJUMP ConstrainedNClickTool. I suspect a conflict 
between general cursor tools which have been reworked and improved by ede a few 
years ago, and the internal of jython tools, but I did not see any obvious 
problem. It will need more investigation or we'll have to deactivate jython 
tools.


---

Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/jump-pilot/bugs/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/jump-pilot/admin/bugs/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] [jump-pilot:bugs] #422 Bug in jython tools

[Giuseppe Aruta via Jump-pilot-devel]

OK. I will close it. No complain for the absence of Road Tool


---

** [bugs:#422] Bug in jython tools**

**Status:** pending
**Milestone:** OJ_1.16
**Created:** Wed Jun 01, 2016 06:13 AM UTC by michael michaud
**Last Updated:** Sun Sep 13, 2020 06:37 PM UTC
**Owner:** nobody


Some jython tools like Road arc tool and Oval tool are broken. Trying to use it 
one time also break other OpenJUMP cursor tools.
These jython tools inherit OpenJUMP ConstrainedNClickTool. I suspect a conflict 
between general cursor tools which have been reworked and improved by ede a few 
years ago, and the internal of jython tools, but I did not see any obvious 
problem. It will need more investigation or we'll have to deactivate jython 
tools.


---

Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/jump-pilot/bugs/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/jump-pilot/admin/bugs/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] [jump-pilot:bugs] #496 OpenJUMP 1.15 freezes on loading project files from differing versions

[Giuseppe Aruta]

I will test tomorrow and give back a report

Il dom 13 set 2020, 18:32 ede via Jump-pilot-devel <
jump-pilot-devel@lists.sourceforge.net> ha scritto:

> as i wrote directly above your post. nope.
> --
>
> * [bugs:#496]  OpenJUMP
> 1.15 freezes on loading project files from differing versions*
>
> *Status:* open
> *Milestone:* OJ_future
> *Created:* Tue Aug 11, 2020 10:35 AM UTC by ede
> *Last Updated:* Sun Sep 13, 2020 04:22 PM UTC
> *Owner:* nobody
>
> as described by Peppe on the mailing list
> "
> *On loading project files saved with different versions of OpenJUMP*.
> There is a break after OpenJUMP 1.5 and before OpenJUMP 6363 on
> saving/loading project files.
> a) OpenJUMP 1.5 freezes on loading project files saved at least with
> OpenJUMP 6363 and 6370
> The console (I use Linux) doesn't show any warning.
> b) OpenJUMP 6363 and 6370 cannot load project files saved at least with
> OpenJUMP 1.5 .
> The console doesn't show any warning.
> c) OpenJUMP 6363 can load project files saved with OpenJUMP 6370 and vice
> versa
> "
> --
>
> Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net
> is subscribed to https://sourceforge.net/p/jump-pilot/bugs/
>
> To unsubscribe from further messages, a project admin can change settings
> at https://sourceforge.net/p/jump-pilot/admin/bugs/options. Or, if this
> is a mailing list, you can unsubscribe from the mailing list.
> ___
> 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] [jump-pilot:bugs] #430 JP2 reader does not read all jp2 files

[Giuseppe Aruta]

The only problem is to define gdal libraries at least for Windows, Linux
and Mac

Il dom 13 set 2020, 18:31 ede via Jump-pilot-devel <
jump-pilot-devel@lists.sourceforge.net> ha scritto:

> we should probably thinking about adding a MEGA distro containing GDAL as
> most users are probably completely unaware of this OJ functionality
> --
>
> * [bugs:#430]  JP2 reader
> does not read all jp2 files*
>
> *Status:* open
> *Milestone:*
> *Created:* Sat Oct 01, 2016 09:56 AM UTC by michael michaud
> *Last Updated:* Sun Sep 13, 2020 04:21 PM UTC
> *Owner:* nobody
>
> Orthophotographies produced by IGN are not read correctly (see maling list
> on 2016-10-01).
> One is read with a very bad resolution, anotherone freeze the application
> and does not load.
> --
>
> Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net
> is subscribed to https://sourceforge.net/p/jump-pilot/bugs/
>
> To unsubscribe from further messages, a project admin can change settings
> at https://sourceforge.net/p/jump-pilot/admin/bugs/options. Or, if this
> is a mailing list, you can unsubscribe from the mailing list.
> ___
> 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] [jump-pilot:bugs] #498 Most GeoTIFF drivers fail with a simple GeoTIFF image

[Giuseppe Aruta]

Hi Michael,
you are right. I didn't see it.
Sextante raster uses a separate way to calculate image dimension,  while
class com.vividsolutions.jump.workbench.imagery.geoimg.GeoReferencedRaster
is used only for the image.
Possibly the proble could be in the class AddRasterImageLayerWizard. I will
give a look.
Peppe

Il giorno dom 13 set 2020 alle ore 13:14 Michaud Michael <
m.michael.mich...@orange.fr> ha scritto:

> Hi Peppe,
>
> Your experiment just prove that Sextant Raster reader read geotif tag and
> world file in a consistant way (whic is not so bad ;-), but not that it
> displays the image with the right coordinates.
>
> If I read the metadata (either geotiff tags or tfw), the image is 3601 x
> 3601 pixels with a pixel size of  2.79E-4, it means it should
> be about 1.0 degree wide.
>
> If I read the image with the ImageIO[ext], jai reader, it is actually
> about 1.0 wide, but with Sextant Raster reader it is only  0.0126 wide
> (note that the upper left corner is correct)
>
> What do you think ?
>
> Michaël
>
> *envoyé :* 13 septembre 2020 à 11:55
> *de :* Giuseppe Aruta 
> *à :* "[jump-pilot:bugs]" <4...@bugs.jump-pilot.p.re.sourceforge.net>,
> OpenJump develop and use 
> *objet :* Re: [JPP-Devel] [jump-pilot:bugs] #498 Most GeoTIFF drivers
> fail with a simple GeoTIFF image
>
> Actually Image Raster (Sextante) uses class
> com.vividsolutions.jump.workbench.imagery.geoimg.GeoReferencedRaster to
> read an image.
>
> @Michael ASTGTMV003_N08W084_de file is a geotiff  even it has a tfw file:
> everythimes that OJ loads a till image,  even geotiff,  it creates a new
> worldfile
>
> I made this test:
> a) load ASTGTMV003_N08W084_dem with tfw on the view as Sextante
> b) create its envelope (via tool on Layer tree). This gives me the right
> position of the image. Remember that everytimes that a TIFF image, even
> geotiff, is loaded as SExtante a new worldfile is created
> c) remove ASTGTMV003_N08W084_dem from the view
> d) delate ASTGTMV003_N08W084_dem worldfile
> e) reload ASTGTMV003_N08W084_dem and verify that it has a  correct
> position into the envelope
>
> Using the other image loaded,
> all fails to load either they don't find tags (even if they are embedded
> into the file) or they cannot read a worldfile
>
> Il giorno dom 13 set 2020 alle ore 11:35 michael michaud via
> Jump-pilot-devel  ha scritto:
>
> I did mor eextensive tests with 4 types of image :
> *small world* : seems that the problem with commons-imaging is the
> combination of multi-bands and interleave=band (an image with same
> characteristics but with interleave=pixel can be read correctly)
> *peppe's dem (ASTGTMV003_N08W084_dem)* : this is a int16 monoband raster.
> I found two kind of problems : some readers fail with an IAE beacuse of the
> absence of ColorModel (JAI TIFF and JAI XTIFF). Other have problems with
> geotags : if I remove tfw, JAI Tiff Reader (v1.4.0) can georeference th
> eimage, Sextant Raster reader read the image with good position (upper left
> corner) but a wrong size, GeoTIFF PLUS does not find geotags. Commons
> imaging read the image without georeferencement (image coordinates), and
> image is black.
> *peppe's geotiff* : this is a float32 monoband raster. I could only read
> it with Sextant Raster and with Commons Imaging (strange psychedelic
> apperance with Commons Imaging though). Other readers through exception
> (IOOBE) while reading, not while loading. No stacktrace in the log file
> about the error.
> Attached, an document with the characteristics of each image and the
> success/failure with each driver.
>
> Attachments:
>
>- image_readers.ods
>
> <https://sourceforge.net/p/jump-pilot/bugs/_discuss/thread/e45ff882e3/724f/attachment/image_readers.ods>
>(14.0 kB; application/vnd.oasis.opendocument.spreadsheet)
>
> --
>
> * [bugs:#498] <https://sourceforge.net/p/jump-pilot/bugs/498/> Most
> GeoTIFF drivers fail with a simple GeoTIFF image*
>
> *Status:* open
> *Milestone:* OJ_future
> *Created:* Sun Aug 30, 2020 08:02 AM UTC by michael michaud
> *Last Updated:* Sat Sep 12, 2020 02:15 PM UTC
> *Owner:* nobody
> *Attachments:*
>
>- small_world.tif
><https://sourceforge.net/p/jump-pilot/bugs/498/attachment/small_world.tif>
>(240.6 kB; image/tiff)
>
> I often have a bad experience trying to read simple geotiff. To have a
> more objective view of the situation, I get a very simple image from the
> test directory of GDAL library and tested it against all our drivers.
> Image is attached. Here are its main characteristics (I think they are
> very common one) :
> small_world.tif
> size : 400 x 200
> Coordin

Re: [JPP-Devel] [jump-pilot:bugs] Re: #451 Add image layer throwing exception

[Giuseppe Aruta]

Regarding 0.5 pixel
see comments of Stefan
org.openjump.core.rasterimage.AddRasterImageLayerWizard
line  237

Il giorno dom 13 set 2020 alle ore 12:08 ede via Jump-pilot-devel <
jump-pilot-devel@lists.sourceforge.net> ha scritto:

> On 13.09.2020 11:48, michael michaud wrote:
>
> Ede, can you tell me why this error (NoClassDefFoundError) is expected ?
>
> some JAI internal thing connected to hardware acceleration not available
> that is thrown on the first use and has not negative impact that i know of.
>
> Anyway, if it is, I suggest that we close the ticket.
>
> funny enough. now i could instantly replicate the initial NPE, probably
> because no node in layertree was selected after deleting an image layer.
> will have a look.
>
> java.lang.NullPointerException
> at
> com.vividsolutions.jump.workbench.ui.plugin.imagery.ImageLayerManagerPlugIn$ImageLayerManagerDialog.updateImages(ImageLayerManagerPlugIn.java:150)
> at
> com.vividsolutions.jump.workbench.ui.plugin.imagery.ImageLayerManagerPlugIn$ImageLayerManagerDialog.(ImageLayerManagerPlugIn.java:138)
> at
> com.vividsolutions.jump.workbench.ui.plugin.imagery.ImageLayerManagerPlugIn.execute(ImageLayerManagerPlugIn.java:94)
> at
> com.vividsolutions.jump.workbench.ui.plugin.imagery.AddImageLayerPlugIn.execute(AddImageLayerPlugIn.java:47)
> at
> com.vividsolutions.jump.workbench.plugin.AbstractPlugIn$1.actionPerformed(AbstractPlugIn.java:344)
> at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2022)
> at
> javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2348)
> at
> javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402)
> at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259)
> at javax.swing.AbstractButton.doClick(AbstractButton.java:376)
> at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:842)
> at
> javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:886)
> at java.awt.Component.processMouseEvent(Component.java:6539)
> at javax.swing.JComponent.processMouseEvent(JComponent.java:3324)
> at java.awt.Component.processEvent(Component.java:6304)
> at java.awt.Container.processEvent(Container.java:2239)
> at java.awt.Component.dispatchEventImpl(Component.java:4889)
> at java.awt.Container.dispatchEventImpl(Container.java:2297)
> at java.awt.Component.dispatchEvent(Component.java:4711)
> at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4904)
> at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4535)
> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4476)
> at java.awt.Container.dispatchEventImpl(Container.java:2283)
> at java.awt.Window.dispatchEventImpl(Window.java:2746)
> at java.awt.Component.dispatchEvent(Component.java:4711)
> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:760)
> at java.awt.EventQueue.access$500(EventQueue.java:97)
> at java.awt.EventQueue$3.run(EventQueue.java:709)
> at java.awt.EventQueue$3.run(EventQueue.java:703)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
> at
> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:84)
> at java.awt.EventQueue$4.run(EventQueue.java:733)
> at java.awt.EventQueue$4.run(EventQueue.java:731)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
> at java.awt.EventQueue.dispatchEvent(EventQueue.java:730)
> at
> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205)
> at
> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
> at
> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
> at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
> --
>
> * [bugs:#451]  Add image
> layer throwing exception*
>
> *Status:* open
> *Milestone:*
> *Created:* Fri Jan 06, 2017 07:25 AM UTC by michael michaud
> *Last Updated:* Sun Sep 13, 2020 09:48 AM UTC
> *Owner:* nobody
>
> Add image layer... (in Layer menu) throws an exception if the layer
> currently selected when the plugin is executed has no attribute. The image
> layer is still created
> --
>
> Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net
> is subscribed to https://sourceforge.net/p/jump-pilot/bugs/
>
> To unsubscribe from further messages, a project admin can change settings
> at https://sourceforge.net/p/jump-pilot/admin/bugs/options. Or, if this
> is a mailing list, you can unsubscribe from the mailing 

Re: [JPP-Devel] [jump-pilot:bugs] #503 1/2 pixel shift in image georeferencement

[Giuseppe Aruta]

>There is still 1/2 pixel difference between image georeferenced with
Sextant Raster reader and images georeferenced with other readers. I have
not investigated yet and don't know which one is correct.

AFAIR that was a quite old issue in Sextante. Eventually (if I am not
wrong) Stefan corrected many years ago.

Il giorno dom 13 set 2020 alle ore 11:52 michael michaud via
Jump-pilot-devel  ha scritto:

> --
>
> * [bugs:#503]  1/2 pixel
> shift in image georeferencement*
>
> *Status:* open
> *Milestone:* undecided
> *Created:* Sun Sep 13, 2020 09:52 AM UTC by michael michaud
> *Last Updated:* Sun Sep 13, 2020 09:52 AM UTC
> *Owner:* nobody
>
> There is still 1/2 pixel difference between image georeferenced with
> Sextant Raster reader and images georeferenced with other readers. I have
> not investigated yet and don't know which one is correct.
> --
>
> Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net
> is subscribed to https://sourceforge.net/p/jump-pilot/bugs/
>
> To unsubscribe from further messages, a project admin can change settings
> at https://sourceforge.net/p/jump-pilot/admin/bugs/options. Or, if this
> is a mailing list, you can unsubscribe from the mailing list.
> ___
> 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] [jump-pilot:bugs] #498 Most GeoTIFF drivers fail with a simple GeoTIFF image

[Giuseppe Aruta]

Actually Image Raster (Sextante) uses class
com.vividsolutions.jump.workbench.imagery.geoimg.GeoReferencedRaster to
read an image.

@Michael ASTGTMV003_N08W084_de file is a geotiff  even it has a tfw file:
everythimes that OJ loads a till image,  even geotiff,  it creates a new
worldfile

I made this test:
a) load ASTGTMV003_N08W084_dem with tfw on the view as Sextante
b) create its envelope (via tool on Layer tree). This gives me the right
position of the image. Remember that everytimes that a TIFF image, even
geotiff, is loaded as SExtante a new worldfile is created
c) remove ASTGTMV003_N08W084_dem from the view
d) delate ASTGTMV003_N08W084_dem worldfile
e) reload ASTGTMV003_N08W084_dem and verify that it has a  correct position
into the envelope

Using the other image loaded,
all fails to load either they don't find tags (even if they are embedded
into the file) or they cannot read a worldfile

Il giorno dom 13 set 2020 alle ore 11:35 michael michaud via
Jump-pilot-devel  ha scritto:

> I did mor eextensive tests with 4 types of image :
> *small world* : seems that the problem with commons-imaging is the
> combination of multi-bands and interleave=band (an image with same
> characteristics but with interleave=pixel can be read correctly)
> *peppe's dem (ASTGTMV003_N08W084_dem)* : this is a int16 monoband raster.
> I found two kind of problems : some readers fail with an IAE beacuse of the
> absence of ColorModel (JAI TIFF and JAI XTIFF). Other have problems with
> geotags : if I remove tfw, JAI Tiff Reader (v1.4.0) can georeference th
> eimage, Sextant Raster reader read the image with good position (upper left
> corner) but a wrong size, GeoTIFF PLUS does not find geotags. Commons
> imaging read the image without georeferencement (image coordinates), and
> image is black.
> *peppe's geotiff* : this is a float32 monoband raster. I could only read
> it with Sextant Raster and with Commons Imaging (strange psychedelic
> apperance with Commons Imaging though). Other readers through exception
> (IOOBE) while reading, not while loading. No stacktrace in the log file
> about the error.
> Attached, an document with the characteristics of each image and the
> success/failure with each driver.
>
> Attachments:
>
>- image_readers.ods
>
> 
>(14.0 kB; application/vnd.oasis.opendocument.spreadsheet)
>
> --
>
> * [bugs:#498]  Most
> GeoTIFF drivers fail with a simple GeoTIFF image*
>
> *Status:* open
> *Milestone:* OJ_future
> *Created:* Sun Aug 30, 2020 08:02 AM UTC by michael michaud
> *Last Updated:* Sat Sep 12, 2020 02:15 PM UTC
> *Owner:* nobody
> *Attachments:*
>
>- small_world.tif
>
>(240.6 kB; image/tiff)
>
> I often have a bad experience trying to read simple geotiff. To have a
> more objective view of the situation, I get a very simple image from the
> test directory of GDAL library and tested it against all our drivers.
> Image is attached. Here are its main characteristics (I think they are
> very common one) :
> small_world.tif
> size : 400 x 200
> Coordinate System : wgs84 (4326)
> Metadata : AREA_OR_POINT=AREA
> Image Structure Metadata : INTERLEAVE=BAND
> 3 bands, Block=400x20, Type=Byte, ColorInterp=RGB
>
> I tried to import it with all the image drivers we propose (8 from Open
> File + ImageRaster Sextante). 3 drivers only could import the image. All
> others fail throughing a rough java exception. Image Raster don't fail
> immediately, but it does not display the image and throws NPE if one try to
> get more information.
>
> List of success/failures and exceptions thrown
>
> Referenced Image (ImageIO[ext],JAI) : OK
> ImageIO TIFF Image Reader version 1.0 : OK
> ImageIO TIFF Image Reader version 1.1 : OK
> Standard TIFF Image Reader
> java.lang.IllegalAccessException: class
> com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset cannot access
> class com.sun.imageio.plugins.tiff.TIFFImageReaderSpi (in module
> java.desktop) because module java.desktop does not export
> com.sun.imageio.plugins.tiff to unnamed module @12405818
> at
> java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:361)
> at
> java.base/jdk.internal.reflect.Reflection.ensureMemberAccess(Reflection.java:99)
> at java.base/java.lang.Class.newInstance(Class.java:579)
> at
> com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.createFeatureFactory(ImageryLayerDataset.java:236)
> at
> com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.attachImage(ImageryLayerDataset.java:117)
> Referenced Image (JAI TIF)
> java.lang.NullPointerException java.lang.NullPointerException at
> com.sun.media.jai.util.SunCachedTile.(SunCachedTile.java:80)
> at com.sun.media.jai.util.SunTileCache.add(SunTileCache.java:257)
> at 

Re: [JPP-Devel] RasterQueryCursorTool

[Giuseppe Aruta]

Hi MIchael, thanks for the correction.
I have to revise my copy of OJ on Eclipse
Peppe

Il giorno dom 13 set 2020 alle ore 00:07 Michaud Michael <
m.michael.mich...@orange.fr> ha scritto:

> Peppe,
>
> The commited code did not compile. I fixed it in 6454, but please, check
> I commented the right line.
>
> Michaël
> ___
> 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] [jump-pilot:bugs] #498 Most GeoTIFF drivers fail with a simple GeoTIFF image

[Giuseppe Aruta via Jump-pilot-devel]

I made several tests opening the test files attached to this post in several 
combinations.
I used:
OJ 6445 core - OJ 6445 PLUS

**OJ 6445 core** 
It opens all the files without any problem. the DEM (*AsterDEM, geotif *and 
*mdt25a*) are displayed wella nd also tool (like pixel inspection) works fine.
Before opening files. On loading OJ I recognized this new error message:

[ERROR] 13:24:49.553 Can't register JP2GDAL readers.
java.lang.NoClassDefFoundError: 
it/geosolutions/imageio/gdalframework/GDALImageReaderSpi
at java.lang.ClassLoader.defineClass1(Native Method).

*small-world *file is opened displayed well. Pixel inspection tool is not 
working but other tools (extract part of image, Raster properties etc) seems to 
work fine

**OJ 6445 PLUS**
*small-world *file is opened displayed well. Pixel inspection tool is not 
working but other tools (extract part of image, Raster properties etc) seems to 
work fine
*AsterDem* is opened and displayed wll with no problem to use tools
*mdta25a* is not displayed in the view even if an icon (not the correct one) is 
displayed on the layer tree. None of the tools work.
The behaviour of *geotiff *file is random. Sometimes is correctly opened and 
displayed into the view and the tools work. Other times it is not displayed  
and the tools don't work.
The most common error is this:
java.lang.ClassCastException: [B cannot be cast to [Ljava.lang.String;
related to imageIO classes

NB *geotiff *and *mdta25a *are basically the same files. I got geotiff loading 
mdt25a into QGIS and saving back with a different name.

--*With all the files and version of OpenJUMP if the file is loaded and 
displayed well*--

a) if the layer is displayed into the view. Raster info tool works well and 
displays all the info about the raste into a table
b) if the later is outside the current view. Raster info tool gives back an 
error possibly due to the matter that Raster Color dept is checked into 
(displayed) BufferedImage (which actually is created whenever we zoom to a 
Sextante Layer. 

java.lang.NullPointerException
at 
org.openjump.core.ui.plugin.raster.RasterImageLayerPropertiesPlugIn.getColorDepth(RasterImageLayerPropertiesPlugIn.java:629)

I suspect that the methods getColorDepth(BufferedImage..) and 
getDPI(BufferedImage..) in the class RasterImageLayerPropertiesPlugin have to 
be rewritten.
Any suggestion? I know that IIOMetadata class can do it but I have never tried. 
Or Commons imaging? 






---

** [bugs:#498] Most GeoTIFF drivers fail with a simple GeoTIFF image**

**Status:** open
**Milestone:** OJ_future
**Created:** Sun Aug 30, 2020 08:02 AM UTC by michael michaud
**Last Updated:** Sat Sep 12, 2020 10:44 AM UTC
**Owner:** nobody
**Attachments:**

- 
[small_world.tif](https://sourceforge.net/p/jump-pilot/bugs/498/attachment/small_world.tif)
 (240.6 kB; image/tiff)


I often have a bad experience trying to read simple geotiff. To have a more 
objective view of the situation, I get a very simple image from the test 
directory of GDAL library and tested it against all our drivers.
Image is attached. Here are its main characteristics (I think they are very 
common one) :
small_world.tif 
size : 400 x 200
Coordinate System : wgs84 (4326)
Metadata : AREA_OR_POINT=AREA
Image Structure Metadata : INTERLEAVE=BAND
3 bands, Block=400x20, Type=Byte, ColorInterp=RGB

I tried to import it with all the image drivers we propose (8 from Open File + 
ImageRaster Sextante). 3 drivers only could import the image. All others fail 
throughing a rough java exception. Image Raster don't fail immediately, but it 
does not display the image and throws NPE if one try to get more information. 

List of success/failures and exceptions thrown

  Referenced Image (ImageIO[ext],JAI) : OK
  ImageIO TIFF Image Reader version 1.0 : OK
  ImageIO TIFF Image Reader version 1.1 : OK
  Standard TIFF Image Reader 
java.lang.IllegalAccessException: class 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset cannot access 
class com.sun.imageio.plugins.tiff.TIFFImageReaderSpi (in module java.desktop) 
because module java.desktop does not export com.sun.imageio.plugins.tiff to 
unnamed module @12405818
at 
java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:361)
at 
java.base/jdk.internal.reflect.Reflection.ensureMemberAccess(Reflection.java:99)
at java.base/java.lang.Class.newInstance(Class.java:579)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.createFeatureFactory(ImageryLayerDataset.java:236)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.attachImage(ImageryLayerDataset.java:117)
  Referenced Image (JAI TIF)
java.lang.NullPointerException java.lang.NullPointerException at 
com.sun.media.jai.util.SunCachedTile.(SunCachedTile.java:80) 
at com.sun.media.jai.util.SunTileCache.add(SunTileCache.java:257) 
at 

[JPP-Devel] [jump-pilot:bugs] #498 Most GeoTIFF drivers fail with a simple GeoTIFF image

[Giuseppe Aruta via Jump-pilot-devel]

I see that there is a newer version  OJ 6344, I will test it. 
Just to check it is not a OS problem, I use Ubuntu with OpenJDK 1.8


---

** [bugs:#498] Most GeoTIFF drivers fail with a simple GeoTIFF image**

**Status:** open
**Milestone:** OJ_future
**Created:** Sun Aug 30, 2020 08:02 AM UTC by michael michaud
**Last Updated:** Sat Sep 12, 2020 10:33 AM UTC
**Owner:** nobody
**Attachments:**

- 
[small_world.tif](https://sourceforge.net/p/jump-pilot/bugs/498/attachment/small_world.tif)
 (240.6 kB; image/tiff)


I often have a bad experience trying to read simple geotiff. To have a more 
objective view of the situation, I get a very simple image from the test 
directory of GDAL library and tested it against all our drivers.
Image is attached. Here are its main characteristics (I think they are very 
common one) :
small_world.tif 
size : 400 x 200
Coordinate System : wgs84 (4326)
Metadata : AREA_OR_POINT=AREA
Image Structure Metadata : INTERLEAVE=BAND
3 bands, Block=400x20, Type=Byte, ColorInterp=RGB

I tried to import it with all the image drivers we propose (8 from Open File + 
ImageRaster Sextante). 3 drivers only could import the image. All others fail 
throughing a rough java exception. Image Raster don't fail immediately, but it 
does not display the image and throws NPE if one try to get more information. 

List of success/failures and exceptions thrown

  Referenced Image (ImageIO[ext],JAI) : OK
  ImageIO TIFF Image Reader version 1.0 : OK
  ImageIO TIFF Image Reader version 1.1 : OK
  Standard TIFF Image Reader 
java.lang.IllegalAccessException: class 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset cannot access 
class com.sun.imageio.plugins.tiff.TIFFImageReaderSpi (in module java.desktop) 
because module java.desktop does not export com.sun.imageio.plugins.tiff to 
unnamed module @12405818
at 
java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:361)
at 
java.base/jdk.internal.reflect.Reflection.ensureMemberAccess(Reflection.java:99)
at java.base/java.lang.Class.newInstance(Class.java:579)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.createFeatureFactory(ImageryLayerDataset.java:236)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.attachImage(ImageryLayerDataset.java:117)
  Referenced Image (JAI TIF)
java.lang.NullPointerException java.lang.NullPointerException at 
com.sun.media.jai.util.SunCachedTile.(SunCachedTile.java:80) 
at com.sun.media.jai.util.SunTileCache.add(SunTileCache.java:257) 
at javax.media.jai.OpImage.addTileToCache(OpImage.java:1087) 
at javax.media.jai.OpImage.getTile(OpImage.java:1142) 
at javax.media.jai.PlanarImage.getData(PlanarImage.java:2085) 
at 
javax.media.jai.RenderedImageAdapter.getData(RenderedImageAdapter.java:158) 
at javax.media.jai.ScaleOpImage.computeTile(ScaleOpImage.java:1099) 
at 
com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java:904) 
at javax.media.jai.OpImage.getTile(OpImage.java:1129) 
at com.sun.media.jai.opimage.CropOpImage.getTile(CropOpImage.java:122) 
at 
com.sun.media.jai.opimage.TranslateIntOpImage.getTile(TranslateIntOpImage.java:132)
 at javax.media.jai.PlanarImage.copyData(PlanarImage.java:2343) 
at javax.media.jai.RenderedOp.copyData(RenderedOp.java:2299) 
at 
javax.media.jai.PlanarImage.getAsBufferedImage(PlanarImage.java:2525) 
at 
javax.media.jai.PlanarImage.getAsBufferedImage(PlanarImage.java:2546) 
at 
com.vividsolutions.jump.workbench.imagery.geoimg.GeoImage.paint(GeoImage.java:285)
 
at 
com.vividsolutions.jump.workbench.imagery.ReferencedImageStyle.paint(ReferencedImageStyle.java:61)
  Referenced Image (JAI TIF) : same error
  
  Buffered Image (common) : 
com.vividsolutions.jump.workbench.imagery.ReferencedImageException: 
java.lang.ArrayIndexOutOfBoundsException: Index 8000 out of bounds for length 
8000
at 
com.vividsolutions.jump.workbench.imagery.graphic.CommonsImage.initImage(CommonsImage.java:112)
at 
com.vividsolutions.jump.workbench.imagery.graphic.AbstractGraphicImage.computeEnvelope(AbstractGraphicImage.java:122)
at 
com.vividsolutions.jump.workbench.imagery.graphic.AbstractGraphicImage.getEnvelope(AbstractGraphicImage.java:114)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.attachImage(ImageryLayerDataset.java:125)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.attachImage(ImageryLayerDataset.java:106)
at 
com.vividsolutions.jump.workbench.imagery.ReferencedImageFactoryFileLayerLoader.createImageFeature(ReferencedImageFactoryFileLayerLoader.java:199)
at 
com.vividsolutions.jump.workbench.imagery.ReferencedImageFactoryFileLayerLoader.open(ReferencedImageFactoryFileLayerLoader.java:102)
at 

[JPP-Devel] [jump-pilot:bugs] #498 Most GeoTIFF drivers fail with a simple GeoTIFF image

[Giuseppe Aruta via Jump-pilot-devel]

I would like to find a solution with I imageio-ext 1.3.2. It seems to work 
faster and to use less memory. Otherwise I am OK to downgrade to the last 
working version (1.1.13)


Attachments:

- 
[mdt25a.tif](https://sourceforge.net/p/jump-pilot/bugs/_discuss/thread/e45ff882e3/ff7b/attachment/mdt25a.tif)
 (986.3 kB; image/tiff)


---

** [bugs:#498] Most GeoTIFF drivers fail with a simple GeoTIFF image**

**Status:** open
**Milestone:** OJ_future
**Created:** Sun Aug 30, 2020 08:02 AM UTC by michael michaud
**Last Updated:** Sat Sep 12, 2020 10:20 AM UTC
**Owner:** nobody
**Attachments:**

- 
[small_world.tif](https://sourceforge.net/p/jump-pilot/bugs/498/attachment/small_world.tif)
 (240.6 kB; image/tiff)


I often have a bad experience trying to read simple geotiff. To have a more 
objective view of the situation, I get a very simple image from the test 
directory of GDAL library and tested it against all our drivers.
Image is attached. Here are its main characteristics (I think they are very 
common one) :
small_world.tif 
size : 400 x 200
Coordinate System : wgs84 (4326)
Metadata : AREA_OR_POINT=AREA
Image Structure Metadata : INTERLEAVE=BAND
3 bands, Block=400x20, Type=Byte, ColorInterp=RGB

I tried to import it with all the image drivers we propose (8 from Open File + 
ImageRaster Sextante). 3 drivers only could import the image. All others fail 
throughing a rough java exception. Image Raster don't fail immediately, but it 
does not display the image and throws NPE if one try to get more information. 

List of success/failures and exceptions thrown

  Referenced Image (ImageIO[ext],JAI) : OK
  ImageIO TIFF Image Reader version 1.0 : OK
  ImageIO TIFF Image Reader version 1.1 : OK
  Standard TIFF Image Reader 
java.lang.IllegalAccessException: class 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset cannot access 
class com.sun.imageio.plugins.tiff.TIFFImageReaderSpi (in module java.desktop) 
because module java.desktop does not export com.sun.imageio.plugins.tiff to 
unnamed module @12405818
at 
java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:361)
at 
java.base/jdk.internal.reflect.Reflection.ensureMemberAccess(Reflection.java:99)
at java.base/java.lang.Class.newInstance(Class.java:579)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.createFeatureFactory(ImageryLayerDataset.java:236)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.attachImage(ImageryLayerDataset.java:117)
  Referenced Image (JAI TIF)
java.lang.NullPointerException java.lang.NullPointerException at 
com.sun.media.jai.util.SunCachedTile.(SunCachedTile.java:80) 
at com.sun.media.jai.util.SunTileCache.add(SunTileCache.java:257) 
at javax.media.jai.OpImage.addTileToCache(OpImage.java:1087) 
at javax.media.jai.OpImage.getTile(OpImage.java:1142) 
at javax.media.jai.PlanarImage.getData(PlanarImage.java:2085) 
at 
javax.media.jai.RenderedImageAdapter.getData(RenderedImageAdapter.java:158) 
at javax.media.jai.ScaleOpImage.computeTile(ScaleOpImage.java:1099) 
at 
com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java:904) 
at javax.media.jai.OpImage.getTile(OpImage.java:1129) 
at com.sun.media.jai.opimage.CropOpImage.getTile(CropOpImage.java:122) 
at 
com.sun.media.jai.opimage.TranslateIntOpImage.getTile(TranslateIntOpImage.java:132)
 at javax.media.jai.PlanarImage.copyData(PlanarImage.java:2343) 
at javax.media.jai.RenderedOp.copyData(RenderedOp.java:2299) 
at 
javax.media.jai.PlanarImage.getAsBufferedImage(PlanarImage.java:2525) 
at 
javax.media.jai.PlanarImage.getAsBufferedImage(PlanarImage.java:2546) 
at 
com.vividsolutions.jump.workbench.imagery.geoimg.GeoImage.paint(GeoImage.java:285)
 
at 
com.vividsolutions.jump.workbench.imagery.ReferencedImageStyle.paint(ReferencedImageStyle.java:61)
  Referenced Image (JAI TIF) : same error
  
  Buffered Image (common) : 
com.vividsolutions.jump.workbench.imagery.ReferencedImageException: 
java.lang.ArrayIndexOutOfBoundsException: Index 8000 out of bounds for length 
8000
at 
com.vividsolutions.jump.workbench.imagery.graphic.CommonsImage.initImage(CommonsImage.java:112)
at 
com.vividsolutions.jump.workbench.imagery.graphic.AbstractGraphicImage.computeEnvelope(AbstractGraphicImage.java:122)
at 
com.vividsolutions.jump.workbench.imagery.graphic.AbstractGraphicImage.getEnvelope(AbstractGraphicImage.java:114)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.attachImage(ImageryLayerDataset.java:125)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.attachImage(ImageryLayerDataset.java:106)
at 
com.vividsolutions.jump.workbench.imagery.ReferencedImageFactoryFileLayerLoader.createImageFeature(ReferencedImageFactoryFileLayerLoader.java:199)
 

[JPP-Devel] [jump-pilot:bugs] #498 Most GeoTIFF drivers fail with a simple GeoTIFF image

[Giuseppe Aruta via Jump-pilot-devel]

 we lost the ability (version OJ 6443) to load TIFF DEM (mono band rasters). 
 I tested with several TIFF DEM, including the one I attached here. None is 
load.
 AFAIR  we had the same problem when we moved to imageIO-ext 1.1.13 to 1.1.16 
(OJ 1.15). So we had to downgrade to imageio-ext-tiff-1.1.13.jar.
 I tried to cancel  imageio-ext-tiff-1.3.2.jar and substitute it with 
imageio-ext-tiff-1.1.13.jar on version OJ 6443 (keeping the others to ver. 
1.3.2) and everything goes fine.
 
 I suggest to keep this bug ticket open until  we solve this problem
 
 This is the message of error that I recognized:
 java.lang.ClassCastException: [B cannot be cast to [Ljava.lang.String;
at 
it.geosolutions.imageio.plugins.tiff.TIFFField.getAsString(TIFFField.java:1164)
at 
it.geosolutions.imageioimpl.plugins.tiff.TIFFImageReader.initializeFromMetadata(TIFFImageReader.java:1286)
at 
it.geosolutions.imageioimpl.plugins.tiff.TIFFImageReader.seekToImage(TIFFImageReader.java:831)
at 
it.geosolutions.imageioimpl.plugins.tiff.TIFFImageReader.seekToImage(TIFFImageReader.java:788)
at 
it.geosolutions.imageioimpl.plugins.tiff.TIFFImageReader.getWidth(TIFFImageReader.java:1046)
at 
org.openjump.core.rasterimage.OverviewsUtils.addOverviews(OverviewsUtils.java:65)
at 
org.openjump.core.rasterimage.OverviewsUtils.getOverviews(OverviewsUtils.java:45)
at 
org.openjump.core.rasterimage.RasterImageIO.loadImage(RasterImageIO.java:142)
at 
org.openjump.core.rasterimage.RasterImageLayer.reLoadImage(RasterImageLayer.java:548)
at 
org.openjump.core.rasterimage.RasterImageLayer.createImage(RasterImageLayer.java:385)
at 
org.openjump.core.rasterimage.RasterImageRenderer.renderHook(RasterImageRenderer.java:107)

 


---

** [bugs:#498] Most GeoTIFF drivers fail with a simple GeoTIFF image**

**Status:** open
**Milestone:** OJ_future
**Created:** Sun Aug 30, 2020 08:02 AM UTC by michael michaud
**Last Updated:** Sat Sep 12, 2020 09:31 AM UTC
**Owner:** nobody
**Attachments:**

- 
[small_world.tif](https://sourceforge.net/p/jump-pilot/bugs/498/attachment/small_world.tif)
 (240.6 kB; image/tiff)


I often have a bad experience trying to read simple geotiff. To have a more 
objective view of the situation, I get a very simple image from the test 
directory of GDAL library and tested it against all our drivers.
Image is attached. Here are its main characteristics (I think they are very 
common one) :
small_world.tif 
size : 400 x 200
Coordinate System : wgs84 (4326)
Metadata : AREA_OR_POINT=AREA
Image Structure Metadata : INTERLEAVE=BAND
3 bands, Block=400x20, Type=Byte, ColorInterp=RGB

I tried to import it with all the image drivers we propose (8 from Open File + 
ImageRaster Sextante). 3 drivers only could import the image. All others fail 
throughing a rough java exception. Image Raster don't fail immediately, but it 
does not display the image and throws NPE if one try to get more information. 

List of success/failures and exceptions thrown

  Referenced Image (ImageIO[ext],JAI) : OK
  ImageIO TIFF Image Reader version 1.0 : OK
  ImageIO TIFF Image Reader version 1.1 : OK
  Standard TIFF Image Reader 
java.lang.IllegalAccessException: class 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset cannot access 
class com.sun.imageio.plugins.tiff.TIFFImageReaderSpi (in module java.desktop) 
because module java.desktop does not export com.sun.imageio.plugins.tiff to 
unnamed module @12405818
at 
java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:361)
at 
java.base/jdk.internal.reflect.Reflection.ensureMemberAccess(Reflection.java:99)
at java.base/java.lang.Class.newInstance(Class.java:579)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.createFeatureFactory(ImageryLayerDataset.java:236)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.attachImage(ImageryLayerDataset.java:117)
  Referenced Image (JAI TIF)
java.lang.NullPointerException java.lang.NullPointerException at 
com.sun.media.jai.util.SunCachedTile.(SunCachedTile.java:80) 
at com.sun.media.jai.util.SunTileCache.add(SunTileCache.java:257) 
at javax.media.jai.OpImage.addTileToCache(OpImage.java:1087) 
at javax.media.jai.OpImage.getTile(OpImage.java:1142) 
at javax.media.jai.PlanarImage.getData(PlanarImage.java:2085) 
at 
javax.media.jai.RenderedImageAdapter.getData(RenderedImageAdapter.java:158) 
at javax.media.jai.ScaleOpImage.computeTile(ScaleOpImage.java:1099) 
at 
com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java:904) 
at javax.media.jai.OpImage.getTile(OpImage.java:1129) 
at com.sun.media.jai.opimage.CropOpImage.getTile(CropOpImage.java:122) 
at 
com.sun.media.jai.opimage.TranslateIntOpImage.getTile(TranslateIntOpImage.java:132)
 at 

Re: [JPP-Devel] How to use com.vividsolutions.jump.workbench.imagery.geoimg.GeoRaster

[Giuseppe Aruta]

Hi Ede,
thanks for the answer. I found that GeoReferencedRaster is more versatile
to read TIFF than simple JAI. I used this class to modify
TiFFUtils.readImage(..) method, used by Sextante RasterImage framework to
load TIFF.

Peppe

Il giorno dom 6 set 2020 alle ore 16:44  ha scritto:

> On 03.09.2020 09:33, Giuseppe Aruta wrote:
> > Hi Ede,is it possible to use
> > com.vividsolutions.jump.workbench.imagery.geoimg.GeoRaster
> > to read an image file?
> > And how?
>
> same as GeoReferencedRaster
>
> but as
>
>   public class GeoReferencedRaster extends GeoRaster
>
> you don't really gain anything, because GeoRaster is essentially
> GeoReferencedRaster without some fancy geo metadata processing. look at
> it's load routine
>
>   protected void readRasterfile() throws ReferencedImageException {
> super.readRasterfile();
> ...
>
>
> > I can easily use GeoReferencedRaster(File file)
> > but not GeoRaster(File file)
>
> hmm the class seems to be abstract although no methods or members are
> abstract. probably because of that. we can make it public, but as said. it
> merely a base class to create a JAI object to be rendered. the referenced
> (geo data enriched) image will be provided by GeoReferencedRaster.
>
> hope i confused you some more :) ..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

[JPP-Devel] [jump-pilot:bugs] #498 Most GeoTIFF drivers fail with a simple GeoTIFF image

[Giuseppe Aruta via Jump-pilot-devel]

(Sextante) RasterImage. I had to revert some changes I did in these days. 
Mostly connected to cell query. The reason: Roberto Rossi, from Univ, of Padua, 
who worked as my tester found some blurring on display discrete DEMs (Dem with 
classes) and the cell query was quite slow and displaying wrong info (possibily 
due to a delay on the reading process, the read values were "jumping" from the 
original position to the click point. To summerize with these last modification
a) OJ opens and display both test tiff (small_earth.tif and AsterDEM). In some 
cases, large file, user needs to zoom one or two times to the layer to 
accellerate the display process. If I load several big files and then I load 
AsterDEM, this is not displayed (the reasons? Memory, ImageIO readers?). 
Blurring was solved
b) info tools on the cell finally works well on AsterDEM fine, they don't work 
fine with  small_earth.tif). 
c) in both cases I cannot extract a part of the image (draw fence-extract part 
of image). I didn't explore the reason. AFAIR this tool at the beginning had 
problems when Alberto de Luca changed RasterImage framework.

I think I will stop making changes. Roberto goes on to do few test as his 
course (where he uses OJ)  starts the 1 of October  - to late to move to OJ 
1.16.

The essential change on the Raster Framework

-  OJ 1.15, on decoding TIF file, was using JAI. Actual NB version is using JAI 
Image I/O and takes advance of Ede's class GeoReferencedRaster which iseems to 
be quite versatile (JAI, SUN and Geosolutions ImageIO, GDAL)
- I understood that to display an Image on the view depends on the quantity of 
memory available (see method RasterImageLayer.create(..). BufferedImage 
RasterImageLayer.stretchImageValuesForDisplay() seemed to fail with 
small_earth.tif so I added a try/catch statement on RasterImageLayer.create(..) 
that, in case of stretchImageValuesForDisplay() failure it uses 
getImageForDisplay() for BufferedImage




---

** [bugs:#498] Most GeoTIFF drivers fail with a simple GeoTIFF image**

**Status:** open
**Milestone:** OJ_future
**Created:** Sun Aug 30, 2020 08:02 AM UTC by michael michaud
**Last Updated:** Sun Sep 06, 2020 10:02 PM UTC
**Owner:** nobody
**Attachments:**

- 
[small_world.tif](https://sourceforge.net/p/jump-pilot/bugs/498/attachment/small_world.tif)
 (240.6 kB; image/tiff)


I often have a bad experience trying to read simple geotiff. To have a more 
objective view of the situation, I get a very simple image from the test 
directory of GDAL library and tested it against all our drivers.
Image is attached. Here are its main characteristics (I think they are very 
common one) :
small_world.tif 
size : 400 x 200
Coordinate System : wgs84 (4326)
Metadata : AREA_OR_POINT=AREA
Image Structure Metadata : INTERLEAVE=BAND
3 bands, Block=400x20, Type=Byte, ColorInterp=RGB

I tried to import it with all the image drivers we propose (8 from Open File + 
ImageRaster Sextante). 3 drivers only could import the image. All others fail 
throughing a rough java exception. Image Raster don't fail immediately, but it 
does not display the image and throws NPE if one try to get more information. 

List of success/failures and exceptions thrown

  Referenced Image (ImageIO[ext],JAI) : OK
  ImageIO TIFF Image Reader version 1.0 : OK
  ImageIO TIFF Image Reader version 1.1 : OK
  Standard TIFF Image Reader 
java.lang.IllegalAccessException: class 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset cannot access 
class com.sun.imageio.plugins.tiff.TIFFImageReaderSpi (in module java.desktop) 
because module java.desktop does not export com.sun.imageio.plugins.tiff to 
unnamed module @12405818
at 
java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:361)
at 
java.base/jdk.internal.reflect.Reflection.ensureMemberAccess(Reflection.java:99)
at java.base/java.lang.Class.newInstance(Class.java:579)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.createFeatureFactory(ImageryLayerDataset.java:236)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.attachImage(ImageryLayerDataset.java:117)
  Referenced Image (JAI TIF)
java.lang.NullPointerException java.lang.NullPointerException at 
com.sun.media.jai.util.SunCachedTile.(SunCachedTile.java:80) 
at com.sun.media.jai.util.SunTileCache.add(SunTileCache.java:257) 
at javax.media.jai.OpImage.addTileToCache(OpImage.java:1087) 
at javax.media.jai.OpImage.getTile(OpImage.java:1142) 
at javax.media.jai.PlanarImage.getData(PlanarImage.java:2085) 
at 
javax.media.jai.RenderedImageAdapter.getData(RenderedImageAdapter.java:158) 
at javax.media.jai.ScaleOpImage.computeTile(ScaleOpImage.java:1099) 
at 
com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java:904) 
at javax.media.jai.OpImage.getTile(OpImage.java:1129) 
at 

Re: [JPP-Devel] SVN: [6432] core/trunk/src/org/openjump/core/rasterimage/ RasterImageIO.java

[Giuseppe Aruta]

It should work on OJ 6435

Il lun 7 set 2020, 3:53 PM Giuseppe Aruta  ha
scritto:

> I Will check. Possibile I missed up a line. Thanks
>
>
> Il lun 7 set 2020, 2:19 PM  ha scritto:
>
>> Peppe,
>>
>> this does not compile on my side. are there changes missing? ..ede
>>
>> Description ResourcePathLocationType
>> band cannot be resolved to a variable   RasterImageIO.java
>> /proj_oj-core/src/org/openjump/core/rasterimage line 387Java Problem
>> col cannot be resolved to a variableRasterImageIO.java
>> /proj_oj-core/src/org/openjump/core/rasterimage line 387Java Problem
>> rectangle cannot be resolved to a variable  RasterImageIO.java
>> /proj_oj-core/src/org/openjump/core/rasterimage line 386Java Problem
>> renderedOp cannot be resolved   RasterImageIO.java
>> /proj_oj-core/src/org/openjump/core/rasterimage line 386Java Problem
>> renderedOp cannot be resolved to a variable RasterImageIO.java
>> /proj_oj-core/src/org/openjump/core/rasterimage line 384Java Problem
>> row cannot be resolved to a variableRasterImageIO.java
>> /proj_oj-core/src/org/openjump/core/rasterimage line 387Java Problem
>> subset cannot be resolved to a variable RasterImageIO.java
>> /proj_oj-core/src/org/openjump/core/rasterimage line 330Java Problem
>>
>>
>> On 9/7/2020 9:44, jump-pilot-svn--- via Jump-pilot-devel wrote:
>> > Revision: 6432
>> >   http://sourceforge.net/p/jump-pilot/code/6432
>> > Author:   ma15569
>> > Date: 2020-09-07 07:44:45 + (Mon, 07 Sep 2020)
>> > Log Message:
>> > ---
>> > Optimized code
>> >
>> > Modified Paths:
>> > --
>> > core/trunk/src/org/openjump/core/rasterimage/RasterImageIO.java
>> >
>> > Modified:
>> core/trunk/src/org/openjump/core/rasterimage/RasterImageIO.java
>> > ===
>> > --- core/trunk/src/org/openjump/core/rasterimage/RasterImageIO.java
>>  2020-09-07 07:40:36 UTC (rev 6431)
>> > +++ core/trunk/src/org/openjump/core/rasterimage/RasterImageIO.java
>>  2020-09-07 07:44:45 UTC (rev 6432)
>> > @@ -322,27 +322,13 @@
>> >
>> >renderedOp =
>> javax.media.jai.JAI.create("fileload",
>> >   filenameOrURL);
>> > -
>> > -
>> > - return renderedOp.getData(rectangle)
>> > + return renderedOp.getData(rectangle)
>> >   .getSampleDouble(col, row, band);
>> > - }else if (filenameOrURL.toLowerCase().endsWith(".tif")
>> > + }
>> > + else if (filenameOrURL.toLowerCase().endsWith(".tif")
>> >   ||
>> filenameOrURL.toLowerCase().endsWith(".tiff")) {
>> > -
>> > - GeoReferencedRaster geoRaster;
>> > -
>> > - try {
>> > - geoRaster = new  GeoReferencedRaster(new
>> File(filenameOrURL).toURI().toString());
>> > -  renderedOp = geoRaster.getImage();
>> > - } catch (ReferencedImageException e) {
>> > - // TODO Auto-generated catch block
>> > -  renderedOp = JAI.create("fileload", filenameOrURL);
>> > - }
>> > -
>> > - return renderedOp.getData(rectangle)
>> > - .getSampleDouble(col, row, band);
>> > -
>> > -
>> > + return TiffUtils.getRenderedOp(new
>> File(filenameOrURL)).getAsBufferedImage(subset, null).getData();
>> > +
>> >   } else if (filenameOrURL.toLowerCase().endsWith(".jpg")) {
>> >   // PlanarImage pimage;
>> >
>> > @@ -395,19 +381,11 @@
>> >
>> >   } else if (filenameOrURL.toLowerCase().endsWith(".tif")
>> >   ||
>> filenameOrURL.toLowerCase().endsWith(".tiff")) {
>> > - GeoReferencedRaster geoRaster;
>> > - RenderedOp  renderedOp;
>> > - try {
>> > - geoRaster = new  GeoReferencedRaster(new
>> File(filenameOrURL).toURI().toString());
>> >

Re: [JPP-Devel] SVN: [6432] core/trunk/src/org/openjump/core/rasterimage/ RasterImageIO.java

[Giuseppe Aruta]

I Will check. Possibile I missed up a line. Thanks


Il lun 7 set 2020, 2:19 PM  ha scritto:

> Peppe,
>
> this does not compile on my side. are there changes missing? ..ede
>
> Description ResourcePathLocationType
> band cannot be resolved to a variable   RasterImageIO.java
> /proj_oj-core/src/org/openjump/core/rasterimage line 387Java Problem
> col cannot be resolved to a variableRasterImageIO.java
> /proj_oj-core/src/org/openjump/core/rasterimage line 387Java Problem
> rectangle cannot be resolved to a variable  RasterImageIO.java
> /proj_oj-core/src/org/openjump/core/rasterimage line 386Java Problem
> renderedOp cannot be resolved   RasterImageIO.java
> /proj_oj-core/src/org/openjump/core/rasterimage line 386Java Problem
> renderedOp cannot be resolved to a variable RasterImageIO.java
> /proj_oj-core/src/org/openjump/core/rasterimage line 384Java Problem
> row cannot be resolved to a variableRasterImageIO.java
> /proj_oj-core/src/org/openjump/core/rasterimage line 387Java Problem
> subset cannot be resolved to a variable RasterImageIO.java
> /proj_oj-core/src/org/openjump/core/rasterimage line 330Java Problem
>
>
> On 9/7/2020 9:44, jump-pilot-svn--- via Jump-pilot-devel wrote:
> > Revision: 6432
> >   http://sourceforge.net/p/jump-pilot/code/6432
> > Author:   ma15569
> > Date: 2020-09-07 07:44:45 + (Mon, 07 Sep 2020)
> > Log Message:
> > ---
> > Optimized code
> >
> > Modified Paths:
> > --
> > core/trunk/src/org/openjump/core/rasterimage/RasterImageIO.java
> >
> > Modified: core/trunk/src/org/openjump/core/rasterimage/RasterImageIO.java
> > ===
> > --- core/trunk/src/org/openjump/core/rasterimage/RasterImageIO.java
>  2020-09-07 07:40:36 UTC (rev 6431)
> > +++ core/trunk/src/org/openjump/core/rasterimage/RasterImageIO.java
>  2020-09-07 07:44:45 UTC (rev 6432)
> > @@ -322,27 +322,13 @@
> >
> >renderedOp =
> javax.media.jai.JAI.create("fileload",
> >   filenameOrURL);
> > -
> > -
> > - return renderedOp.getData(rectangle)
> > + return renderedOp.getData(rectangle)
> >   .getSampleDouble(col, row, band);
> > - }else if (filenameOrURL.toLowerCase().endsWith(".tif")
> > + }
> > + else if (filenameOrURL.toLowerCase().endsWith(".tif")
> >   ||
> filenameOrURL.toLowerCase().endsWith(".tiff")) {
> > -
> > - GeoReferencedRaster geoRaster;
> > -
> > - try {
> > - geoRaster = new  GeoReferencedRaster(new
> File(filenameOrURL).toURI().toString());
> > -  renderedOp = geoRaster.getImage();
> > - } catch (ReferencedImageException e) {
> > - // TODO Auto-generated catch block
> > -  renderedOp = JAI.create("fileload", filenameOrURL);
> > - }
> > -
> > - return renderedOp.getData(rectangle)
> > - .getSampleDouble(col, row, band);
> > -
> > -
> > + return TiffUtils.getRenderedOp(new
> File(filenameOrURL)).getAsBufferedImage(subset, null).getData();
> > +
> >   } else if (filenameOrURL.toLowerCase().endsWith(".jpg")) {
> >   // PlanarImage pimage;
> >
> > @@ -395,19 +381,11 @@
> >
> >   } else if (filenameOrURL.toLowerCase().endsWith(".tif")
> >   ||
> filenameOrURL.toLowerCase().endsWith(".tiff")) {
> > - GeoReferencedRaster geoRaster;
> > - RenderedOp  renderedOp;
> > - try {
> > - geoRaster = new  GeoReferencedRaster(new
> File(filenameOrURL).toURI().toString());
> > -  renderedOp = geoRaster.getImage();
> > - } catch (ReferencedImageException e) {
> > - // TODO Auto-generated catch block
> > -  renderedOp = JAI.create("fileload", filenameOrURL);
> > - }
> > - if (renderedOp != null) {
> > - return new Point(renderedOp.getWidth(),
> renderedOp.getHeight());
> > - }
> > -
> > + renderedOp= TiffUtils.getRenderedOp(new
> File(filenameOrURL));
> > +
> > + return renderedOp.getData(rectangle)
> > + .getSampleDouble(col, row, band);
> > +
> >
> >   } else if (filenameOrURL.toLowerCase().endsWith(".flt")) {
> >
> >
> >
> >
> > ___
> > Jump-pilot-devel mailing list
> > Jump-pilot-devel@lists.sourceforge.net
> > 

[JPP-Devel] [jump-pilot:bugs] #498 Most GeoTIFF drivers fail with a simple GeoTIFF image

[Giuseppe Aruta via Jump-pilot-devel]

OpenJUMP 6430 . Almost solved reading pixel data (Info tool , pixel inspection 
and raster profile) for test image small_word.tif (not for Aster dem file). 
Removed also warnings substituting GeoReferencedRaster.getImage() method  to 
read PlanarImage of TIFF (instead of JAI.create("fileload"..)


---

** [bugs:#498] Most GeoTIFF drivers fail with a simple GeoTIFF image**

**Status:** open
**Milestone:** OJ_future
**Created:** Sun Aug 30, 2020 08:02 AM UTC by michael michaud
**Last Updated:** Sun Sep 06, 2020 04:47 PM UTC
**Owner:** nobody
**Attachments:**

- 
[small_world.tif](https://sourceforge.net/p/jump-pilot/bugs/498/attachment/small_world.tif)
 (240.6 kB; image/tiff)


I often have a bad experience trying to read simple geotiff. To have a more 
objective view of the situation, I get a very simple image from the test 
directory of GDAL library and tested it against all our drivers.
Image is attached. Here are its main characteristics (I think they are very 
common one) :
small_world.tif 
size : 400 x 200
Coordinate System : wgs84 (4326)
Metadata : AREA_OR_POINT=AREA
Image Structure Metadata : INTERLEAVE=BAND
3 bands, Block=400x20, Type=Byte, ColorInterp=RGB

I tried to import it with all the image drivers we propose (8 from Open File + 
ImageRaster Sextante). 3 drivers only could import the image. All others fail 
throughing a rough java exception. Image Raster don't fail immediately, but it 
does not display the image and throws NPE if one try to get more information. 

List of success/failures and exceptions thrown

  Referenced Image (ImageIO[ext],JAI) : OK
  ImageIO TIFF Image Reader version 1.0 : OK
  ImageIO TIFF Image Reader version 1.1 : OK
  Standard TIFF Image Reader 
java.lang.IllegalAccessException: class 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset cannot access 
class com.sun.imageio.plugins.tiff.TIFFImageReaderSpi (in module java.desktop) 
because module java.desktop does not export com.sun.imageio.plugins.tiff to 
unnamed module @12405818
at 
java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:361)
at 
java.base/jdk.internal.reflect.Reflection.ensureMemberAccess(Reflection.java:99)
at java.base/java.lang.Class.newInstance(Class.java:579)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.createFeatureFactory(ImageryLayerDataset.java:236)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.attachImage(ImageryLayerDataset.java:117)
  Referenced Image (JAI TIF)
java.lang.NullPointerException java.lang.NullPointerException at 
com.sun.media.jai.util.SunCachedTile.(SunCachedTile.java:80) 
at com.sun.media.jai.util.SunTileCache.add(SunTileCache.java:257) 
at javax.media.jai.OpImage.addTileToCache(OpImage.java:1087) 
at javax.media.jai.OpImage.getTile(OpImage.java:1142) 
at javax.media.jai.PlanarImage.getData(PlanarImage.java:2085) 
at 
javax.media.jai.RenderedImageAdapter.getData(RenderedImageAdapter.java:158) 
at javax.media.jai.ScaleOpImage.computeTile(ScaleOpImage.java:1099) 
at 
com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java:904) 
at javax.media.jai.OpImage.getTile(OpImage.java:1129) 
at com.sun.media.jai.opimage.CropOpImage.getTile(CropOpImage.java:122) 
at 
com.sun.media.jai.opimage.TranslateIntOpImage.getTile(TranslateIntOpImage.java:132)
 at javax.media.jai.PlanarImage.copyData(PlanarImage.java:2343) 
at javax.media.jai.RenderedOp.copyData(RenderedOp.java:2299) 
at 
javax.media.jai.PlanarImage.getAsBufferedImage(PlanarImage.java:2525) 
at 
javax.media.jai.PlanarImage.getAsBufferedImage(PlanarImage.java:2546) 
at 
com.vividsolutions.jump.workbench.imagery.geoimg.GeoImage.paint(GeoImage.java:285)
 
at 
com.vividsolutions.jump.workbench.imagery.ReferencedImageStyle.paint(ReferencedImageStyle.java:61)
  Referenced Image (JAI TIF) : same error
  
  Buffered Image (common) : 
com.vividsolutions.jump.workbench.imagery.ReferencedImageException: 
java.lang.ArrayIndexOutOfBoundsException: Index 8000 out of bounds for length 
8000
at 
com.vividsolutions.jump.workbench.imagery.graphic.CommonsImage.initImage(CommonsImage.java:112)
at 
com.vividsolutions.jump.workbench.imagery.graphic.AbstractGraphicImage.computeEnvelope(AbstractGraphicImage.java:122)
at 
com.vividsolutions.jump.workbench.imagery.graphic.AbstractGraphicImage.getEnvelope(AbstractGraphicImage.java:114)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.attachImage(ImageryLayerDataset.java:125)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.attachImage(ImageryLayerDataset.java:106)
at 
com.vividsolutions.jump.workbench.imagery.ReferencedImageFactoryFileLayerLoader.createImageFeature(ReferencedImageFactoryFileLayerLoader.java:199)
at 

[JPP-Devel] [jump-pilot:bugs] #498 Most GeoTIFF drivers fail with a simple GeoTIFF image

[Giuseppe Aruta via Jump-pilot-devel]

@edso
>maybe you want to take a peek how other JUMPSs/Java apps access those and 
>implement it in OJ?
Kosmo used Gdal to access to raster data, I think with GvSIG framework
Possibly a pure Java solution that works with many TIFF types could be on ImageJ

>if it used to work earlier try to identify the patchset that broke it and fix 
>that.
No. It was not working in the past, see page : 
http://ojwiki.soldin.de/index.php?title=Display_ASTER_DEM_TIF_files_in_OpenJUMP


---

** [bugs:#498] Most GeoTIFF drivers fail with a simple GeoTIFF image**

**Status:** open
**Milestone:** OJ_1.16
**Created:** Sun Aug 30, 2020 08:02 AM UTC by michael michaud
**Last Updated:** Sat Sep 05, 2020 04:19 PM UTC
**Owner:** nobody
**Attachments:**

- 
[small_world.tif](https://sourceforge.net/p/jump-pilot/bugs/498/attachment/small_world.tif)
 (240.6 kB; image/tiff)


I often have a bad experience trying to read simple geotiff. To have a more 
objective view of the situation, I get a very simple image from the test 
directory of GDAL library and tested it against all our drivers.
Image is attached. Here are its main characteristics (I think they are very 
common one) :
small_world.tif 
size : 400 x 200
Coordinate System : wgs84 (4326)
Metadata : AREA_OR_POINT=AREA
Image Structure Metadata : INTERLEAVE=BAND
3 bands, Block=400x20, Type=Byte, ColorInterp=RGB

I tried to import it with all the image drivers we propose (8 from Open File + 
ImageRaster Sextante). 3 drivers only could import the image. All others fail 
throughing a rough java exception. Image Raster don't fail immediately, but it 
does not display the image and throws NPE if one try to get more information. 

List of success/failures and exceptions thrown

  Referenced Image (ImageIO[ext],JAI) : OK
  ImageIO TIFF Image Reader version 1.0 : OK
  ImageIO TIFF Image Reader version 1.1 : OK
  Standard TIFF Image Reader 
java.lang.IllegalAccessException: class 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset cannot access 
class com.sun.imageio.plugins.tiff.TIFFImageReaderSpi (in module java.desktop) 
because module java.desktop does not export com.sun.imageio.plugins.tiff to 
unnamed module @12405818
at 
java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:361)
at 
java.base/jdk.internal.reflect.Reflection.ensureMemberAccess(Reflection.java:99)
at java.base/java.lang.Class.newInstance(Class.java:579)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.createFeatureFactory(ImageryLayerDataset.java:236)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.attachImage(ImageryLayerDataset.java:117)
  Referenced Image (JAI TIF)
java.lang.NullPointerException java.lang.NullPointerException at 
com.sun.media.jai.util.SunCachedTile.(SunCachedTile.java:80) 
at com.sun.media.jai.util.SunTileCache.add(SunTileCache.java:257) 
at javax.media.jai.OpImage.addTileToCache(OpImage.java:1087) 
at javax.media.jai.OpImage.getTile(OpImage.java:1142) 
at javax.media.jai.PlanarImage.getData(PlanarImage.java:2085) 
at 
javax.media.jai.RenderedImageAdapter.getData(RenderedImageAdapter.java:158) 
at javax.media.jai.ScaleOpImage.computeTile(ScaleOpImage.java:1099) 
at 
com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java:904) 
at javax.media.jai.OpImage.getTile(OpImage.java:1129) 
at com.sun.media.jai.opimage.CropOpImage.getTile(CropOpImage.java:122) 
at 
com.sun.media.jai.opimage.TranslateIntOpImage.getTile(TranslateIntOpImage.java:132)
 at javax.media.jai.PlanarImage.copyData(PlanarImage.java:2343) 
at javax.media.jai.RenderedOp.copyData(RenderedOp.java:2299) 
at 
javax.media.jai.PlanarImage.getAsBufferedImage(PlanarImage.java:2525) 
at 
javax.media.jai.PlanarImage.getAsBufferedImage(PlanarImage.java:2546) 
at 
com.vividsolutions.jump.workbench.imagery.geoimg.GeoImage.paint(GeoImage.java:285)
 
at 
com.vividsolutions.jump.workbench.imagery.ReferencedImageStyle.paint(ReferencedImageStyle.java:61)
  Referenced Image (JAI TIF) : same error
  
  Buffered Image (common) : 
com.vividsolutions.jump.workbench.imagery.ReferencedImageException: 
java.lang.ArrayIndexOutOfBoundsException: Index 8000 out of bounds for length 
8000
at 
com.vividsolutions.jump.workbench.imagery.graphic.CommonsImage.initImage(CommonsImage.java:112)
at 
com.vividsolutions.jump.workbench.imagery.graphic.AbstractGraphicImage.computeEnvelope(AbstractGraphicImage.java:122)
at 
com.vividsolutions.jump.workbench.imagery.graphic.AbstractGraphicImage.getEnvelope(AbstractGraphicImage.java:114)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.attachImage(ImageryLayerDataset.java:125)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.attachImage(ImageryLayerDataset.java:106)
at 

[JPP-Devel] [jump-pilot:bugs] #498 Most GeoTIFF drivers fail with a simple GeoTIFF image

[Giuseppe Aruta via Jump-pilot-devel]

If you agree I will keep this ticket open for OpenJUMP 2.0


---

** [bugs:#498] Most GeoTIFF drivers fail with a simple GeoTIFF image**

**Status:** open
**Milestone:** OJ_1.16
**Created:** Sun Aug 30, 2020 08:02 AM UTC by michael michaud
**Last Updated:** Fri Sep 04, 2020 09:46 PM UTC
**Owner:** nobody
**Attachments:**

- 
[small_world.tif](https://sourceforge.net/p/jump-pilot/bugs/498/attachment/small_world.tif)
 (240.6 kB; image/tiff)


I often have a bad experience trying to read simple geotiff. To have a more 
objective view of the situation, I get a very simple image from the test 
directory of GDAL library and tested it against all our drivers.
Image is attached. Here are its main characteristics (I think they are very 
common one) :
small_world.tif 
size : 400 x 200
Coordinate System : wgs84 (4326)
Metadata : AREA_OR_POINT=AREA
Image Structure Metadata : INTERLEAVE=BAND
3 bands, Block=400x20, Type=Byte, ColorInterp=RGB

I tried to import it with all the image drivers we propose (8 from Open File + 
ImageRaster Sextante). 3 drivers only could import the image. All others fail 
throughing a rough java exception. Image Raster don't fail immediately, but it 
does not display the image and throws NPE if one try to get more information. 

List of success/failures and exceptions thrown

  Referenced Image (ImageIO[ext],JAI) : OK
  ImageIO TIFF Image Reader version 1.0 : OK
  ImageIO TIFF Image Reader version 1.1 : OK
  Standard TIFF Image Reader 
java.lang.IllegalAccessException: class 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset cannot access 
class com.sun.imageio.plugins.tiff.TIFFImageReaderSpi (in module java.desktop) 
because module java.desktop does not export com.sun.imageio.plugins.tiff to 
unnamed module @12405818
at 
java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:361)
at 
java.base/jdk.internal.reflect.Reflection.ensureMemberAccess(Reflection.java:99)
at java.base/java.lang.Class.newInstance(Class.java:579)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.createFeatureFactory(ImageryLayerDataset.java:236)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.attachImage(ImageryLayerDataset.java:117)
  Referenced Image (JAI TIF)
java.lang.NullPointerException java.lang.NullPointerException at 
com.sun.media.jai.util.SunCachedTile.(SunCachedTile.java:80) 
at com.sun.media.jai.util.SunTileCache.add(SunTileCache.java:257) 
at javax.media.jai.OpImage.addTileToCache(OpImage.java:1087) 
at javax.media.jai.OpImage.getTile(OpImage.java:1142) 
at javax.media.jai.PlanarImage.getData(PlanarImage.java:2085) 
at 
javax.media.jai.RenderedImageAdapter.getData(RenderedImageAdapter.java:158) 
at javax.media.jai.ScaleOpImage.computeTile(ScaleOpImage.java:1099) 
at 
com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java:904) 
at javax.media.jai.OpImage.getTile(OpImage.java:1129) 
at com.sun.media.jai.opimage.CropOpImage.getTile(CropOpImage.java:122) 
at 
com.sun.media.jai.opimage.TranslateIntOpImage.getTile(TranslateIntOpImage.java:132)
 at javax.media.jai.PlanarImage.copyData(PlanarImage.java:2343) 
at javax.media.jai.RenderedOp.copyData(RenderedOp.java:2299) 
at 
javax.media.jai.PlanarImage.getAsBufferedImage(PlanarImage.java:2525) 
at 
javax.media.jai.PlanarImage.getAsBufferedImage(PlanarImage.java:2546) 
at 
com.vividsolutions.jump.workbench.imagery.geoimg.GeoImage.paint(GeoImage.java:285)
 
at 
com.vividsolutions.jump.workbench.imagery.ReferencedImageStyle.paint(ReferencedImageStyle.java:61)
  Referenced Image (JAI TIF) : same error
  
  Buffered Image (common) : 
com.vividsolutions.jump.workbench.imagery.ReferencedImageException: 
java.lang.ArrayIndexOutOfBoundsException: Index 8000 out of bounds for length 
8000
at 
com.vividsolutions.jump.workbench.imagery.graphic.CommonsImage.initImage(CommonsImage.java:112)
at 
com.vividsolutions.jump.workbench.imagery.graphic.AbstractGraphicImage.computeEnvelope(AbstractGraphicImage.java:122)
at 
com.vividsolutions.jump.workbench.imagery.graphic.AbstractGraphicImage.getEnvelope(AbstractGraphicImage.java:114)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.attachImage(ImageryLayerDataset.java:125)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.attachImage(ImageryLayerDataset.java:106)
at 
com.vividsolutions.jump.workbench.imagery.ReferencedImageFactoryFileLayerLoader.createImageFeature(ReferencedImageFactoryFileLayerLoader.java:199)
at 
com.vividsolutions.jump.workbench.imagery.ReferencedImageFactoryFileLayerLoader.open(ReferencedImageFactoryFileLayerLoader.java:102)
at 
org.openjump.core.ui.plugin.file.open.OpenFileWizard.run(OpenFileWizard.java:164)
  GeoTIFF plus (JAI) :

[JPP-Devel] [jump-pilot:bugs] #495 Warp panel shows a vertical toolba instead of horizontal on Ubuntu

[Giuseppe Aruta via Jump-pilot-devel]

No'It is amazing that the class was never modified. That means the good 
experience of the developer


---

** [bugs:#495] Warp panel shows a vertical toolba instead of horizontal on 
Ubuntu**

**Status:** closed-works-for-me
**Milestone:** OJ_future
**Created:** Fri Jul 31, 2020 07:40 AM UTC by Giuseppe Aruta
**Last Updated:** Fri Sep 04, 2020 09:58 AM UTC
**Owner:** Giuseppe Aruta
**Attachments:**

- 
[Senzanome.png](https://sourceforge.net/p/jump-pilot/bugs/495/attachment/Senzanome.png)
 (45.0 kB; image/png)


On Ubuntu Mate.
Warp Plugin. The toolbar of the panel sets all vector tools icon in a vertical 
position, as shown in the attached picture. 



---

Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/jump-pilot/bugs/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/jump-pilot/admin/bugs/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] [jump-pilot:bugs] #495 Warp panel shows a vertical toolba instead of horizontal on Ubuntu

[Giuseppe Aruta via Jump-pilot-devel]

Thanks Ede,
I did the modification and tested everything fine
WarpingPanelPlugin moved from version 9 (2005) to verison 6423 (2020)  :-(


---

** [bugs:#495] Warp panel shows a vertical toolba instead of horizontal on 
Ubuntu**

**Status:** open
**Milestone:** OJ_future
**Created:** Fri Jul 31, 2020 07:40 AM UTC by Giuseppe Aruta
**Last Updated:** Fri Sep 04, 2020 09:44 AM UTC
**Owner:** Giuseppe Aruta
**Attachments:**

- 
[Senzanome.png](https://sourceforge.net/p/jump-pilot/bugs/495/attachment/Senzanome.png)
 (45.0 kB; image/png)


On Ubuntu Mate.
Warp Plugin. The toolbar of the panel sets all vector tools icon in a vertical 
position, as shown in the attached picture. 



---

Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/jump-pilot/bugs/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/jump-pilot/admin/bugs/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] [jump-pilot:bugs] #495 Warp panel shows a vertical toolba instead of horizontal on Ubuntu

[Giuseppe Aruta via Jump-pilot-devel]

- **status**: open --> closed-works-for-me



---

** [bugs:#495] Warp panel shows a vertical toolba instead of horizontal on 
Ubuntu**

**Status:** closed-works-for-me
**Milestone:** OJ_future
**Created:** Fri Jul 31, 2020 07:40 AM UTC by Giuseppe Aruta
**Last Updated:** Fri Sep 04, 2020 09:57 AM UTC
**Owner:** Giuseppe Aruta
**Attachments:**

- 
[Senzanome.png](https://sourceforge.net/p/jump-pilot/bugs/495/attachment/Senzanome.png)
 (45.0 kB; image/png)


On Ubuntu Mate.
Warp Plugin. The toolbar of the panel sets all vector tools icon in a vertical 
position, as shown in the attached picture. 



---

Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/jump-pilot/bugs/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/jump-pilot/admin/bugs/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] [jump-pilot:bugs] #429 CRS transformation

[Giuseppe Aruta via Jump-pilot-devel]

- **status**: open --> closed
- **Milestone**:  --> undecided
- **Comment**:

Closed since november 2017. See discussion



---

** [bugs:#429] CRS transformation**

**Status:** closed
**Milestone:** undecided
**Created:** Thu Sep 29, 2016 07:43 PM UTC by michael michaud
**Last Updated:** Mon Dec 31, 2018 09:41 AM UTC
**Owner:** michael michaud


When a vector dataset is transformed with CTS and saved into a new shapefile, 
OpenJUMP does not produce a prj file (I think that CTS includes the code to 
make that possible), 


---

Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/jump-pilot/bugs/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/jump-pilot/admin/bugs/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] [jump-pilot:bugs] #495 Warp panel shows a vertical toolba instead of horizontal on Ubuntu

[Giuseppe Aruta via Jump-pilot-devel]

Hi Ede,
the problem is only on warp plugin toolbar.
The proposed modification (toolbox.getToolBar().setLayout(new FlowLayout())) 
should fix it without affect on other toolbars (Editing, CAD and Measure 
Plugin) which seems to work file.



---

** [bugs:#495] Warp panel shows a vertical toolba instead of horizontal on 
Ubuntu**

**Status:** open
**Milestone:** OJ_future
**Created:** Fri Jul 31, 2020 07:40 AM UTC by Giuseppe Aruta
**Last Updated:** Fri Aug 28, 2020 08:24 PM UTC
**Owner:** Giuseppe Aruta
**Attachments:**

- 
[Senzanome.png](https://sourceforge.net/p/jump-pilot/bugs/495/attachment/Senzanome.png)
 (45.0 kB; image/png)


On Ubuntu Mate.
Warp Plugin. The toolbar of the panel sets all vector tools icon in a vertical 
position, as shown in the attached picture. 



---

Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/jump-pilot/bugs/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/jump-pilot/admin/bugs/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] [jump-pilot:bugs] #498 Most GeoTIFF drivers fail with a simple GeoTIFF image

[Giuseppe Aruta via Jump-pilot-devel]

I attached the Aster DEM tif file. 
Once loaded into OpenJUMP, to display it, click on "Zoom to layer"
Then try to use the tools Raster>Pixel inspection or Raster>Profile
The output is always "0.0" 

Peppe


Attachments:

- 
[ASTGTMV003_N08W084_dem.tif](https://sourceforge.net/p/jump-pilot/bugs/_discuss/thread/e45ff882e3/f329/attachment/ASTGTMV003_N08W084_dem.tif)
 (8.2 MB; image/tiff)


---

** [bugs:#498] Most GeoTIFF drivers fail with a simple GeoTIFF image**

**Status:** open
**Milestone:** OJ_1.16
**Created:** Sun Aug 30, 2020 08:02 AM UTC by michael michaud
**Last Updated:** Fri Sep 04, 2020 07:01 AM UTC
**Owner:** nobody
**Attachments:**

- 
[small_world.tif](https://sourceforge.net/p/jump-pilot/bugs/498/attachment/small_world.tif)
 (240.6 kB; image/tiff)


I often have a bad experience trying to read simple geotiff. To have a more 
objective view of the situation, I get a very simple image from the test 
directory of GDAL library and tested it against all our drivers.
Image is attached. Here are its main characteristics (I think they are very 
common one) :
small_world.tif 
size : 400 x 200
Coordinate System : wgs84 (4326)
Metadata : AREA_OR_POINT=AREA
Image Structure Metadata : INTERLEAVE=BAND
3 bands, Block=400x20, Type=Byte, ColorInterp=RGB

I tried to import it with all the image drivers we propose (8 from Open File + 
ImageRaster Sextante). 3 drivers only could import the image. All others fail 
throughing a rough java exception. Image Raster don't fail immediately, but it 
does not display the image and throws NPE if one try to get more information. 

List of success/failures and exceptions thrown

  Referenced Image (ImageIO[ext],JAI) : OK
  ImageIO TIFF Image Reader version 1.0 : OK
  ImageIO TIFF Image Reader version 1.1 : OK
  Standard TIFF Image Reader 
java.lang.IllegalAccessException: class 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset cannot access 
class com.sun.imageio.plugins.tiff.TIFFImageReaderSpi (in module java.desktop) 
because module java.desktop does not export com.sun.imageio.plugins.tiff to 
unnamed module @12405818
at 
java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:361)
at 
java.base/jdk.internal.reflect.Reflection.ensureMemberAccess(Reflection.java:99)
at java.base/java.lang.Class.newInstance(Class.java:579)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.createFeatureFactory(ImageryLayerDataset.java:236)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.attachImage(ImageryLayerDataset.java:117)
  Referenced Image (JAI TIF)
java.lang.NullPointerException java.lang.NullPointerException at 
com.sun.media.jai.util.SunCachedTile.(SunCachedTile.java:80) 
at com.sun.media.jai.util.SunTileCache.add(SunTileCache.java:257) 
at javax.media.jai.OpImage.addTileToCache(OpImage.java:1087) 
at javax.media.jai.OpImage.getTile(OpImage.java:1142) 
at javax.media.jai.PlanarImage.getData(PlanarImage.java:2085) 
at 
javax.media.jai.RenderedImageAdapter.getData(RenderedImageAdapter.java:158) 
at javax.media.jai.ScaleOpImage.computeTile(ScaleOpImage.java:1099) 
at 
com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java:904) 
at javax.media.jai.OpImage.getTile(OpImage.java:1129) 
at com.sun.media.jai.opimage.CropOpImage.getTile(CropOpImage.java:122) 
at 
com.sun.media.jai.opimage.TranslateIntOpImage.getTile(TranslateIntOpImage.java:132)
 at javax.media.jai.PlanarImage.copyData(PlanarImage.java:2343) 
at javax.media.jai.RenderedOp.copyData(RenderedOp.java:2299) 
at 
javax.media.jai.PlanarImage.getAsBufferedImage(PlanarImage.java:2525) 
at 
javax.media.jai.PlanarImage.getAsBufferedImage(PlanarImage.java:2546) 
at 
com.vividsolutions.jump.workbench.imagery.geoimg.GeoImage.paint(GeoImage.java:285)
 
at 
com.vividsolutions.jump.workbench.imagery.ReferencedImageStyle.paint(ReferencedImageStyle.java:61)
  Referenced Image (JAI TIF) : same error
  
  Buffered Image (common) : 
com.vividsolutions.jump.workbench.imagery.ReferencedImageException: 
java.lang.ArrayIndexOutOfBoundsException: Index 8000 out of bounds for length 
8000
at 
com.vividsolutions.jump.workbench.imagery.graphic.CommonsImage.initImage(CommonsImage.java:112)
at 
com.vividsolutions.jump.workbench.imagery.graphic.AbstractGraphicImage.computeEnvelope(AbstractGraphicImage.java:122)
at 
com.vividsolutions.jump.workbench.imagery.graphic.AbstractGraphicImage.getEnvelope(AbstractGraphicImage.java:114)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.attachImage(ImageryLayerDataset.java:125)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.attachImage(ImageryLayerDataset.java:106)
at 

[JPP-Devel] [jump-pilot:bugs] #498 Most GeoTIFF drivers fail with a simple GeoTIFF image

[Giuseppe Aruta via Jump-pilot-devel]

Since I have problems  to display Aster tiff files, possibily due to  the 
precence of overviews, I am considering to add a plugin to convert a file image 
(TIFF in this case) directly without loading into OJ view


---

** [bugs:#498] Most GeoTIFF drivers fail with a simple GeoTIFF image**

**Status:** open
**Milestone:** OJ_1.16
**Created:** Sun Aug 30, 2020 08:02 AM UTC by michael michaud
**Last Updated:** Fri Sep 04, 2020 06:57 AM UTC
**Owner:** nobody
**Attachments:**

- 
[small_world.tif](https://sourceforge.net/p/jump-pilot/bugs/498/attachment/small_world.tif)
 (240.6 kB; image/tiff)


I often have a bad experience trying to read simple geotiff. To have a more 
objective view of the situation, I get a very simple image from the test 
directory of GDAL library and tested it against all our drivers.
Image is attached. Here are its main characteristics (I think they are very 
common one) :
small_world.tif 
size : 400 x 200
Coordinate System : wgs84 (4326)
Metadata : AREA_OR_POINT=AREA
Image Structure Metadata : INTERLEAVE=BAND
3 bands, Block=400x20, Type=Byte, ColorInterp=RGB

I tried to import it with all the image drivers we propose (8 from Open File + 
ImageRaster Sextante). 3 drivers only could import the image. All others fail 
throughing a rough java exception. Image Raster don't fail immediately, but it 
does not display the image and throws NPE if one try to get more information. 

List of success/failures and exceptions thrown

  Referenced Image (ImageIO[ext],JAI) : OK
  ImageIO TIFF Image Reader version 1.0 : OK
  ImageIO TIFF Image Reader version 1.1 : OK
  Standard TIFF Image Reader 
java.lang.IllegalAccessException: class 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset cannot access 
class com.sun.imageio.plugins.tiff.TIFFImageReaderSpi (in module java.desktop) 
because module java.desktop does not export com.sun.imageio.plugins.tiff to 
unnamed module @12405818
at 
java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:361)
at 
java.base/jdk.internal.reflect.Reflection.ensureMemberAccess(Reflection.java:99)
at java.base/java.lang.Class.newInstance(Class.java:579)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.createFeatureFactory(ImageryLayerDataset.java:236)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.attachImage(ImageryLayerDataset.java:117)
  Referenced Image (JAI TIF)
java.lang.NullPointerException java.lang.NullPointerException at 
com.sun.media.jai.util.SunCachedTile.(SunCachedTile.java:80) 
at com.sun.media.jai.util.SunTileCache.add(SunTileCache.java:257) 
at javax.media.jai.OpImage.addTileToCache(OpImage.java:1087) 
at javax.media.jai.OpImage.getTile(OpImage.java:1142) 
at javax.media.jai.PlanarImage.getData(PlanarImage.java:2085) 
at 
javax.media.jai.RenderedImageAdapter.getData(RenderedImageAdapter.java:158) 
at javax.media.jai.ScaleOpImage.computeTile(ScaleOpImage.java:1099) 
at 
com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java:904) 
at javax.media.jai.OpImage.getTile(OpImage.java:1129) 
at com.sun.media.jai.opimage.CropOpImage.getTile(CropOpImage.java:122) 
at 
com.sun.media.jai.opimage.TranslateIntOpImage.getTile(TranslateIntOpImage.java:132)
 at javax.media.jai.PlanarImage.copyData(PlanarImage.java:2343) 
at javax.media.jai.RenderedOp.copyData(RenderedOp.java:2299) 
at 
javax.media.jai.PlanarImage.getAsBufferedImage(PlanarImage.java:2525) 
at 
javax.media.jai.PlanarImage.getAsBufferedImage(PlanarImage.java:2546) 
at 
com.vividsolutions.jump.workbench.imagery.geoimg.GeoImage.paint(GeoImage.java:285)
 
at 
com.vividsolutions.jump.workbench.imagery.ReferencedImageStyle.paint(ReferencedImageStyle.java:61)
  Referenced Image (JAI TIF) : same error
  
  Buffered Image (common) : 
com.vividsolutions.jump.workbench.imagery.ReferencedImageException: 
java.lang.ArrayIndexOutOfBoundsException: Index 8000 out of bounds for length 
8000
at 
com.vividsolutions.jump.workbench.imagery.graphic.CommonsImage.initImage(CommonsImage.java:112)
at 
com.vividsolutions.jump.workbench.imagery.graphic.AbstractGraphicImage.computeEnvelope(AbstractGraphicImage.java:122)
at 
com.vividsolutions.jump.workbench.imagery.graphic.AbstractGraphicImage.getEnvelope(AbstractGraphicImage.java:114)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.attachImage(ImageryLayerDataset.java:125)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.attachImage(ImageryLayerDataset.java:106)
at 
com.vividsolutions.jump.workbench.imagery.ReferencedImageFactoryFileLayerLoader.createImageFeature(ReferencedImageFactoryFileLayerLoader.java:199)
at 

[JPP-Devel] [jump-pilot:bugs] #498 Most GeoTIFF drivers fail with a simple GeoTIFF image

[Giuseppe Aruta via Jump-pilot-devel]

Hi Michael,
I confirm newer OJ MB can load and display simple geotiff.

The changes I did:

a) TiFFUtils class. Method getRenderedOp(File tiffFile) which was using 
JAI.create method to load a file. I added as main method 
GeoReferencedRaster.getRenderedOp which seems more robust and able to open more 
tiff (and more image types) files. 

b) RasterImageLayer.createImage pointed to the method 
RasterImageLayer.stretchImageValuesForDisplay() . This method rebuilds the 
BufferedImageLayer to display on the view. It was created by Alberto De Luca to 
give the right colors (BW and symbology) for monoband rasters but I observed 
that sometimes it fails to display raster which have more than 3 bands (4th the 
transparency). 
The change I did: In case stretchImageValuesForDisplay() fails, it returns the 
original loaded BufferedImageLayer

I still cannot solve problems connected to the tool Raster>pixel inspection 
(method RasterImageLayer.getCellValue...) that return a null poiter exception 
on your file


---

** [bugs:#498] Most GeoTIFF drivers fail with a simple GeoTIFF image**

**Status:** open
**Milestone:** OJ_1.16
**Created:** Sun Aug 30, 2020 08:02 AM UTC by michael michaud
**Last Updated:** Wed Sep 02, 2020 09:29 AM UTC
**Owner:** nobody
**Attachments:**

- 
[small_world.tif](https://sourceforge.net/p/jump-pilot/bugs/498/attachment/small_world.tif)
 (240.6 kB; image/tiff)


I often have a bad experience trying to read simple geotiff. To have a more 
objective view of the situation, I get a very simple image from the test 
directory of GDAL library and tested it against all our drivers.
Image is attached. Here are its main characteristics (I think they are very 
common one) :
small_world.tif 
size : 400 x 200
Coordinate System : wgs84 (4326)
Metadata : AREA_OR_POINT=AREA
Image Structure Metadata : INTERLEAVE=BAND
3 bands, Block=400x20, Type=Byte, ColorInterp=RGB

I tried to import it with all the image drivers we propose (8 from Open File + 
ImageRaster Sextante). 3 drivers only could import the image. All others fail 
throughing a rough java exception. Image Raster don't fail immediately, but it 
does not display the image and throws NPE if one try to get more information. 

List of success/failures and exceptions thrown

  Referenced Image (ImageIO[ext],JAI) : OK
  ImageIO TIFF Image Reader version 1.0 : OK
  ImageIO TIFF Image Reader version 1.1 : OK
  Standard TIFF Image Reader 
java.lang.IllegalAccessException: class 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset cannot access 
class com.sun.imageio.plugins.tiff.TIFFImageReaderSpi (in module java.desktop) 
because module java.desktop does not export com.sun.imageio.plugins.tiff to 
unnamed module @12405818
at 
java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:361)
at 
java.base/jdk.internal.reflect.Reflection.ensureMemberAccess(Reflection.java:99)
at java.base/java.lang.Class.newInstance(Class.java:579)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.createFeatureFactory(ImageryLayerDataset.java:236)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.attachImage(ImageryLayerDataset.java:117)
  Referenced Image (JAI TIF)
java.lang.NullPointerException java.lang.NullPointerException at 
com.sun.media.jai.util.SunCachedTile.(SunCachedTile.java:80) 
at com.sun.media.jai.util.SunTileCache.add(SunTileCache.java:257) 
at javax.media.jai.OpImage.addTileToCache(OpImage.java:1087) 
at javax.media.jai.OpImage.getTile(OpImage.java:1142) 
at javax.media.jai.PlanarImage.getData(PlanarImage.java:2085) 
at 
javax.media.jai.RenderedImageAdapter.getData(RenderedImageAdapter.java:158) 
at javax.media.jai.ScaleOpImage.computeTile(ScaleOpImage.java:1099) 
at 
com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java:904) 
at javax.media.jai.OpImage.getTile(OpImage.java:1129) 
at com.sun.media.jai.opimage.CropOpImage.getTile(CropOpImage.java:122) 
at 
com.sun.media.jai.opimage.TranslateIntOpImage.getTile(TranslateIntOpImage.java:132)
 at javax.media.jai.PlanarImage.copyData(PlanarImage.java:2343) 
at javax.media.jai.RenderedOp.copyData(RenderedOp.java:2299) 
at 
javax.media.jai.PlanarImage.getAsBufferedImage(PlanarImage.java:2525) 
at 
javax.media.jai.PlanarImage.getAsBufferedImage(PlanarImage.java:2546) 
at 
com.vividsolutions.jump.workbench.imagery.geoimg.GeoImage.paint(GeoImage.java:285)
 
at 
com.vividsolutions.jump.workbench.imagery.ReferencedImageStyle.paint(ReferencedImageStyle.java:61)
  Referenced Image (JAI TIF) : same error
  
  Buffered Image (common) : 
com.vividsolutions.jump.workbench.imagery.ReferencedImageException: 
java.lang.ArrayIndexOutOfBoundsException: Index 8000 out of bounds for length 
8000
at 

[JPP-Devel] removed dependency to LoadSextanteRasterImage plugin

[Giuseppe Aruta]

Hi all,
today I removed all dependencies to
org.openjump.core.ui.plugin.layer.pirolraster.LoadSextanteRasterImagePlugIn.
The only code used of this class was the  public static String KEY_PATH =
"path";

This class was used many years ago to load image files as RasterImagelayers
but it was almost substituted by Alberto De Luca when he extended
RasterImageLayer framework to ESRI ascii and float file types and added all
the raster style methods.
The "new" class that substituted LoadSextanteRasterImagePlugIn is
org.openjump.core.raster.AddRasterImageLayerWizard.

I kept the code of LoadSextanteRasterImagePlugIn and made the class
deprecated
Peppe
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] How to use com.vividsolutions.jump.workbench.imagery.geoimg.GeoRaster

[Giuseppe Aruta]

Ops!
Maybe I was wrong.
The question is if
com.vividsolutions.jump.workbench.imagery.geoimg.GeoReferencedRaster can
read png, gif, bmp and jpg too ( not only Tiff it GeiTiff)
Thanks


Il gio 3 set 2020, 09:33 Giuseppe Aruta  ha
scritto:

> Hi Ede,is it possible to use
> com.vividsolutions.jump.workbench.imagery.geoimg.GeoRaster
> to read an image file?
> And how?
>
> I can easily use GeoReferencedRaster(File file)
> but not GeoRaster(File file)
>
> Thanks
> Peppe
>
>
>
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] How to use com.vividsolutions.jump.workbench.imagery.geoimg.GeoRaster

[Giuseppe Aruta]

Hi Ede,is it possible to use
com.vividsolutions.jump.workbench.imagery.geoimg.GeoRaster
to read an image file?
And how?

I can easily use GeoReferencedRaster(File file)
but not GeoRaster(File file)

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

[JPP-Devel] [jump-pilot:bugs] #498 Most GeoTIFF drivers fail with a simple GeoTIFF image

[Giuseppe Aruta]

Hi Mihael,
please, wait to test: I found that I need to make an extra
modification on the library (in was on my local OJ but not on the SVN
upgrade)
I will do other tests and  upgrade the new version tomorrow
Peppe

>  Thanks for your effort Peppe, I'll try it soon and I'll come back to you. 
> Michaël envoyé : 2 septembre 2020 à 11:29 de : Giuseppe Aruta  à : 
> "[jump-pilot:bugs] "  objet : [jump-pilot:bugs] #498 Most GeoTIFF drivers 
> fail with a simple GeoTIFF image Sent from sourceforge.net because you 
> indicated interest in https://sourceforge.net/p/jump-pilot/bugs/498/ To 
> unsubscribe from further messages, please visit 
> https://sourceforge.net/auth/subscriptions/ Last Updated: Wed Sep 02, 2020 
> 09:29 AM UTC Owner: nobody Attachments: 
> ___ 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] [jump-pilot:bugs] #498 Most GeoTIFF drivers fail with a simple GeoTIFF image

[Giuseppe Aruta via Jump-pilot-devel]

Please try OJ 6410


---

** [bugs:#498] Most GeoTIFF drivers fail with a simple GeoTIFF image**

**Status:** open
**Milestone:** OJ_1.16
**Created:** Sun Aug 30, 2020 08:02 AM UTC by michael michaud
**Last Updated:** Wed Sep 02, 2020 09:28 AM UTC
**Owner:** nobody
**Attachments:**

- 
[small_world.tif](https://sourceforge.net/p/jump-pilot/bugs/498/attachment/small_world.tif)
 (240.6 kB; image/tiff)


I often have a bad experience trying to read simple geotiff. To have a more 
objective view of the situation, I get a very simple image from the test 
directory of GDAL library and tested it against all our drivers.
Image is attached. Here are its main characteristics (I think they are very 
common one) :
small_world.tif 
size : 400 x 200
Coordinate System : wgs84 (4326)
Metadata : AREA_OR_POINT=AREA
Image Structure Metadata : INTERLEAVE=BAND
3 bands, Block=400x20, Type=Byte, ColorInterp=RGB

I tried to import it with all the image drivers we propose (8 from Open File + 
ImageRaster Sextante). 3 drivers only could import the image. All others fail 
throughing a rough java exception. Image Raster don't fail immediately, but it 
does not display the image and throws NPE if one try to get more information. 

List of success/failures and exceptions thrown

  Referenced Image (ImageIO[ext],JAI) : OK
  ImageIO TIFF Image Reader version 1.0 : OK
  ImageIO TIFF Image Reader version 1.1 : OK
  Standard TIFF Image Reader 
java.lang.IllegalAccessException: class 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset cannot access 
class com.sun.imageio.plugins.tiff.TIFFImageReaderSpi (in module java.desktop) 
because module java.desktop does not export com.sun.imageio.plugins.tiff to 
unnamed module @12405818
at 
java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:361)
at 
java.base/jdk.internal.reflect.Reflection.ensureMemberAccess(Reflection.java:99)
at java.base/java.lang.Class.newInstance(Class.java:579)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.createFeatureFactory(ImageryLayerDataset.java:236)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.attachImage(ImageryLayerDataset.java:117)
  Referenced Image (JAI TIF)
java.lang.NullPointerException java.lang.NullPointerException at 
com.sun.media.jai.util.SunCachedTile.(SunCachedTile.java:80) 
at com.sun.media.jai.util.SunTileCache.add(SunTileCache.java:257) 
at javax.media.jai.OpImage.addTileToCache(OpImage.java:1087) 
at javax.media.jai.OpImage.getTile(OpImage.java:1142) 
at javax.media.jai.PlanarImage.getData(PlanarImage.java:2085) 
at 
javax.media.jai.RenderedImageAdapter.getData(RenderedImageAdapter.java:158) 
at javax.media.jai.ScaleOpImage.computeTile(ScaleOpImage.java:1099) 
at 
com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java:904) 
at javax.media.jai.OpImage.getTile(OpImage.java:1129) 
at com.sun.media.jai.opimage.CropOpImage.getTile(CropOpImage.java:122) 
at 
com.sun.media.jai.opimage.TranslateIntOpImage.getTile(TranslateIntOpImage.java:132)
 at javax.media.jai.PlanarImage.copyData(PlanarImage.java:2343) 
at javax.media.jai.RenderedOp.copyData(RenderedOp.java:2299) 
at 
javax.media.jai.PlanarImage.getAsBufferedImage(PlanarImage.java:2525) 
at 
javax.media.jai.PlanarImage.getAsBufferedImage(PlanarImage.java:2546) 
at 
com.vividsolutions.jump.workbench.imagery.geoimg.GeoImage.paint(GeoImage.java:285)
 
at 
com.vividsolutions.jump.workbench.imagery.ReferencedImageStyle.paint(ReferencedImageStyle.java:61)
  Referenced Image (JAI TIF) : same error
  
  Buffered Image (common) : 
com.vividsolutions.jump.workbench.imagery.ReferencedImageException: 
java.lang.ArrayIndexOutOfBoundsException: Index 8000 out of bounds for length 
8000
at 
com.vividsolutions.jump.workbench.imagery.graphic.CommonsImage.initImage(CommonsImage.java:112)
at 
com.vividsolutions.jump.workbench.imagery.graphic.AbstractGraphicImage.computeEnvelope(AbstractGraphicImage.java:122)
at 
com.vividsolutions.jump.workbench.imagery.graphic.AbstractGraphicImage.getEnvelope(AbstractGraphicImage.java:114)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.attachImage(ImageryLayerDataset.java:125)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.attachImage(ImageryLayerDataset.java:106)
at 
com.vividsolutions.jump.workbench.imagery.ReferencedImageFactoryFileLayerLoader.createImageFeature(ReferencedImageFactoryFileLayerLoader.java:199)
at 
com.vividsolutions.jump.workbench.imagery.ReferencedImageFactoryFileLayerLoader.open(ReferencedImageFactoryFileLayerLoader.java:102)
at 
org.openjump.core.ui.plugin.file.open.OpenFileWizard.run(OpenFileWizard.java:164)
  GeoTIFF plus (JAI) :
java.lang.NullPointerException 

[JPP-Devel] [jump-pilot:bugs] #498 Most GeoTIFF drivers fail with a simple GeoTIFF image

[Giuseppe Aruta via Jump-pilot-devel]

Hi Michael,
I added a small patch to RasterImageLayer.class (Sextante) which should 
partially solve the display for tiff loaded via this class. 
Not sure about the reason (TIFF drivers? Appling symbology?). I still have 
Error output whenever I use a pixel querry ([ERROR] 11:11:45.369 Planar 
(band-sequential) format TIFF is not supported.) which works randomly


---

** [bugs:#498] Most GeoTIFF drivers fail with a simple GeoTIFF image**

**Status:** open
**Milestone:** OJ_1.16
**Created:** Sun Aug 30, 2020 08:02 AM UTC by michael michaud
**Last Updated:** Sun Aug 30, 2020 08:02 AM UTC
**Owner:** nobody
**Attachments:**

- 
[small_world.tif](https://sourceforge.net/p/jump-pilot/bugs/498/attachment/small_world.tif)
 (240.6 kB; image/tiff)


I often have a bad experience trying to read simple geotiff. To have a more 
objective view of the situation, I get a very simple image from the test 
directory of GDAL library and tested it against all our drivers.
Image is attached. Here are its main characteristics (I think they are very 
common one) :
small_world.tif 
size : 400 x 200
Coordinate System : wgs84 (4326)
Metadata : AREA_OR_POINT=AREA
Image Structure Metadata : INTERLEAVE=BAND
3 bands, Block=400x20, Type=Byte, ColorInterp=RGB

I tried to import it with all the image drivers we propose (8 from Open File + 
ImageRaster Sextante). 3 drivers only could import the image. All others fail 
throughing a rough java exception. Image Raster don't fail immediately, but it 
does not display the image and throws NPE if one try to get more information. 

List of success/failures and exceptions thrown

  Referenced Image (ImageIO[ext],JAI) : OK
  ImageIO TIFF Image Reader version 1.0 : OK
  ImageIO TIFF Image Reader version 1.1 : OK
  Standard TIFF Image Reader 
java.lang.IllegalAccessException: class 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset cannot access 
class com.sun.imageio.plugins.tiff.TIFFImageReaderSpi (in module java.desktop) 
because module java.desktop does not export com.sun.imageio.plugins.tiff to 
unnamed module @12405818
at 
java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:361)
at 
java.base/jdk.internal.reflect.Reflection.ensureMemberAccess(Reflection.java:99)
at java.base/java.lang.Class.newInstance(Class.java:579)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.createFeatureFactory(ImageryLayerDataset.java:236)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.attachImage(ImageryLayerDataset.java:117)
  Referenced Image (JAI TIF)
java.lang.NullPointerException java.lang.NullPointerException at 
com.sun.media.jai.util.SunCachedTile.(SunCachedTile.java:80) 
at com.sun.media.jai.util.SunTileCache.add(SunTileCache.java:257) 
at javax.media.jai.OpImage.addTileToCache(OpImage.java:1087) 
at javax.media.jai.OpImage.getTile(OpImage.java:1142) 
at javax.media.jai.PlanarImage.getData(PlanarImage.java:2085) 
at 
javax.media.jai.RenderedImageAdapter.getData(RenderedImageAdapter.java:158) 
at javax.media.jai.ScaleOpImage.computeTile(ScaleOpImage.java:1099) 
at 
com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java:904) 
at javax.media.jai.OpImage.getTile(OpImage.java:1129) 
at com.sun.media.jai.opimage.CropOpImage.getTile(CropOpImage.java:122) 
at 
com.sun.media.jai.opimage.TranslateIntOpImage.getTile(TranslateIntOpImage.java:132)
 at javax.media.jai.PlanarImage.copyData(PlanarImage.java:2343) 
at javax.media.jai.RenderedOp.copyData(RenderedOp.java:2299) 
at 
javax.media.jai.PlanarImage.getAsBufferedImage(PlanarImage.java:2525) 
at 
javax.media.jai.PlanarImage.getAsBufferedImage(PlanarImage.java:2546) 
at 
com.vividsolutions.jump.workbench.imagery.geoimg.GeoImage.paint(GeoImage.java:285)
 
at 
com.vividsolutions.jump.workbench.imagery.ReferencedImageStyle.paint(ReferencedImageStyle.java:61)
  Referenced Image (JAI TIF) : same error
  
  Buffered Image (common) : 
com.vividsolutions.jump.workbench.imagery.ReferencedImageException: 
java.lang.ArrayIndexOutOfBoundsException: Index 8000 out of bounds for length 
8000
at 
com.vividsolutions.jump.workbench.imagery.graphic.CommonsImage.initImage(CommonsImage.java:112)
at 
com.vividsolutions.jump.workbench.imagery.graphic.AbstractGraphicImage.computeEnvelope(AbstractGraphicImage.java:122)
at 
com.vividsolutions.jump.workbench.imagery.graphic.AbstractGraphicImage.getEnvelope(AbstractGraphicImage.java:114)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.attachImage(ImageryLayerDataset.java:125)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.attachImage(ImageryLayerDataset.java:106)
at 

[JPP-Devel] [jump-pilot:bugs] #500 possible important bug on Batik 1.6.1

[Giuseppe Aruta via Jump-pilot-devel]

Export is fine for Vector and ReferenceImageLayer at any scale.

Export RasterImageLayer:  it is rescales and sometimes lost if we rescale the 
view using saving options:
The difference:

a) Embedded Save view>to SVG and change current scale box  on "Scale 1:" 
option. 
1) If I leave the scale box at the default options (scale of the current view), 
RasterImageLayer is exported at the right size
2) If I lchange the export scale the scale box  RasterImageLayer is rescaled 
loosing proportion to the rest of the map

b) CadPlan Print plugin Save Image (SVG). In this case it is almost difficult 
save RasterImageLayer. whatever scale I define on the printing view (including 
scale from OJ view), the raster layer always loose proportion or is lost.

Note that this "bug" was already on previous versions of OpenJUMP but it was 
never evident


---

** [bugs:#500] possible important bug on Batik 1.6.1**

**Status:** closed-fixed
**Milestone:** OJ_1.16
**Created:** Sun Aug 30, 2020 03:17 PM UTC by Giuseppe Aruta
**Last Updated:** Tue Sep 01, 2020 03:27 PM UTC
**Owner:** nobody
**Attachments:**

- 
[geotiff.tfw](https://sourceforge.net/p/jump-pilot/bugs/500/attachment/geotiff.tfw)
 (42 Bytes; application/octet-stream)
- 
[geotiff.tif](https://sourceforge.net/p/jump-pilot/bugs/500/attachment/geotiff.tif)
 (986.3 kB; image/tiff)
- 
[geotiff.tif.aux.xml](https://sourceforge.net/p/jump-pilot/bugs/500/attachment/geotiff.tif.aux.xml)
 (374 Bytes; text/xml)


Hi all,
(Layerable: RasterImageLayer) whenever I try to create a new raster I get  an 
error message due to matter that OJ cannot read (or create) a aux.xml file 
(file where some statistics are stored). 
The bug  is important because OJ cannot read the whole raster if it doesn't 
recognize that statistics and it affects basically all Sextante algorithms that 
create rasters
To reproduce the bug (I used OpenJUMP-20200828-r6395-PLUS - Batik 1.6 and 
OpenJUMP-20200731-r6363-PLUS - Batik 1.6.1, Ubuntu, OpenJDK 64bit 1.8.0.252)
a) open a monoband tiff file (I have just attached a sample)
b) dray a fence on it
c) click on Layer tree > extract part of the image

I tried to understand the reason. 
What I discover is that OJs with Batik 1.6 are not affected by the problem, 
while newer OJ with Batik 1.6.1 show the bug.
That is strange for me as I don't have any error messages on compiling OpenJUMP 
with either Batik 1.6 or Batik 1.6.1.
On the other hand I discovered that OJ shipping Batik 1.6.1 have one Batik 
class with different serial number (batik-1.5-fop-0.20-5.jar).
Any suggestions?
Peppe

This is the error message
javax.xml.transform.TransformerException: java.io.FileNotFoundException: 
file:/tmp/Parte%20-dialwdgg_4390.tif.aux.xml (File o directory non esistente)
at 
org.apache.xalan.transformer.TransformerIdentityImpl.createResultContentHandler(TransformerIdentityImpl.java:263)
at 
org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:296)
at 
org.openjump.core.rasterimage.GDALPamDataset.writeStatistics(GDALPamDataset.java:131)
at 
org.openjump.core.rasterimage.TiffUtils.createStatsXml(TiffUtils.java:302)
at 
org.openjump.core.rasterimage.TiffUtils.calculateStats(TiffUtils.java:251)
at org.openjump.core.rasterimage.TiffUtils.readImage(TiffUtils.java:68)
at 
org.openjump.core.rasterimage.RasterImageIO.loadImage(RasterImageIO.java:143)
at 
org.openjump.core.ui.plugin.layer.pirolraster.ExtractSelectedPartOfImage.execute(ExtractSelectedPartOfImage.java:182)
at 
com.vividsolutions.jump.workbench.plugin.AbstractPlugIn$1.actionPerformed(AbstractPlugIn.java:344)
at 
javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2022)
at 
javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2348)
at 
javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402)
at 
javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259)
at javax.swing.AbstractButton.doClick(AbstractButton.java:376)
at 
javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:842)
at 
javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:886)
at java.awt.Component.processMouseEvent(Component.java:6539)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3324)
at java.awt.Component.processEvent(Component.java:6304)
at java.awt.Container.processEvent(Container.java:2239)
at java.awt.Component.dispatchEventImpl(Component.java:4889)
at java.awt.Container.dispatchEventImpl(Container.java:2297)
at java.awt.Component.dispatchEvent(Component.java:4711)
at 
java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4904)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4535)
at java.awt.LightweightDispatcher.dispatc

[JPP-Devel] [jump-pilot:bugs] #500 possible important bug on Batik 1.6.1

[Giuseppe Aruta via Jump-pilot-devel]

- **status**: open --> closed-fixed



---

** [bugs:#500] possible important bug on Batik 1.6.1**

**Status:** closed-fixed
**Milestone:** OJ_1.16
**Created:** Sun Aug 30, 2020 03:17 PM UTC by Giuseppe Aruta
**Last Updated:** Tue Sep 01, 2020 03:26 PM UTC
**Owner:** nobody
**Attachments:**

- 
[geotiff.tfw](https://sourceforge.net/p/jump-pilot/bugs/500/attachment/geotiff.tfw)
 (42 Bytes; application/octet-stream)
- 
[geotiff.tif](https://sourceforge.net/p/jump-pilot/bugs/500/attachment/geotiff.tif)
 (986.3 kB; image/tiff)
- 
[geotiff.tif.aux.xml](https://sourceforge.net/p/jump-pilot/bugs/500/attachment/geotiff.tif.aux.xml)
 (374 Bytes; text/xml)


Hi all,
(Layerable: RasterImageLayer) whenever I try to create a new raster I get  an 
error message due to matter that OJ cannot read (or create) a aux.xml file 
(file where some statistics are stored). 
The bug  is important because OJ cannot read the whole raster if it doesn't 
recognize that statistics and it affects basically all Sextante algorithms that 
create rasters
To reproduce the bug (I used OpenJUMP-20200828-r6395-PLUS - Batik 1.6 and 
OpenJUMP-20200731-r6363-PLUS - Batik 1.6.1, Ubuntu, OpenJDK 64bit 1.8.0.252)
a) open a monoband tiff file (I have just attached a sample)
b) dray a fence on it
c) click on Layer tree > extract part of the image

I tried to understand the reason. 
What I discover is that OJs with Batik 1.6 are not affected by the problem, 
while newer OJ with Batik 1.6.1 show the bug.
That is strange for me as I don't have any error messages on compiling OpenJUMP 
with either Batik 1.6 or Batik 1.6.1.
On the other hand I discovered that OJ shipping Batik 1.6.1 have one Batik 
class with different serial number (batik-1.5-fop-0.20-5.jar).
Any suggestions?
Peppe

This is the error message
javax.xml.transform.TransformerException: java.io.FileNotFoundException: 
file:/tmp/Parte%20-dialwdgg_4390.tif.aux.xml (File o directory non esistente)
at 
org.apache.xalan.transformer.TransformerIdentityImpl.createResultContentHandler(TransformerIdentityImpl.java:263)
at 
org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:296)
at 
org.openjump.core.rasterimage.GDALPamDataset.writeStatistics(GDALPamDataset.java:131)
at 
org.openjump.core.rasterimage.TiffUtils.createStatsXml(TiffUtils.java:302)
at 
org.openjump.core.rasterimage.TiffUtils.calculateStats(TiffUtils.java:251)
at org.openjump.core.rasterimage.TiffUtils.readImage(TiffUtils.java:68)
at 
org.openjump.core.rasterimage.RasterImageIO.loadImage(RasterImageIO.java:143)
at 
org.openjump.core.ui.plugin.layer.pirolraster.ExtractSelectedPartOfImage.execute(ExtractSelectedPartOfImage.java:182)
at 
com.vividsolutions.jump.workbench.plugin.AbstractPlugIn$1.actionPerformed(AbstractPlugIn.java:344)
at 
javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2022)
at 
javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2348)
at 
javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402)
at 
javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259)
at javax.swing.AbstractButton.doClick(AbstractButton.java:376)
at 
javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:842)
at 
javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:886)
at java.awt.Component.processMouseEvent(Component.java:6539)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3324)
at java.awt.Component.processEvent(Component.java:6304)
at java.awt.Container.processEvent(Container.java:2239)
at java.awt.Component.dispatchEventImpl(Component.java:4889)
at java.awt.Container.dispatchEventImpl(Container.java:2297)
at java.awt.Component.dispatchEvent(Component.java:4711)
at 
java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4904)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4535)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4476)
at java.awt.Container.dispatchEventImpl(Container.java:2283)
at java.awt.Window.dispatchEventImpl(Window.java:2746)
at java.awt.Component.dispatchEvent(Component.java:4711)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:760)
at java.awt.EventQueue.access$500(EventQueue.java:97)
at java.awt.EventQueue$3.run(EventQueue.java:709)
at java.awt.EventQueue$3.run(EventQueue.java:703)
at java.security.AccessController.doPrivileged(Native Method)
at 
java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
at 
java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:84)
at java.awt.EventQueue$4.run(EventQueue.ja

[JPP-Devel] [jump-pilot:bugs] #500 possible important bug on Batik 1.6.1

[Giuseppe Aruta via Jump-pilot-devel]

Hi Ede, 
I didi some test, now everything works fine, thanks.
The cryses is over. OpenJUMP Raster analysis is heavily used in the cource of 
GIS analysis at the Univ. of Padua by Roberto Rossi 
(https://persone.csia.unipd.it/off/2020/LM/AV/AG0062/000ZZ/AG01122459/N0) which 
starts in a months
I am going to close the bug ticket
Peppe



---

** [bugs:#500] possible important bug on Batik 1.6.1**

**Status:** open
**Milestone:** OJ_1.16
**Created:** Sun Aug 30, 2020 03:17 PM UTC by Giuseppe Aruta
**Last Updated:** Tue Sep 01, 2020 01:38 PM UTC
**Owner:** nobody
**Attachments:**

- 
[geotiff.tfw](https://sourceforge.net/p/jump-pilot/bugs/500/attachment/geotiff.tfw)
 (42 Bytes; application/octet-stream)
- 
[geotiff.tif](https://sourceforge.net/p/jump-pilot/bugs/500/attachment/geotiff.tif)
 (986.3 kB; image/tiff)
- 
[geotiff.tif.aux.xml](https://sourceforge.net/p/jump-pilot/bugs/500/attachment/geotiff.tif.aux.xml)
 (374 Bytes; text/xml)


Hi all,
(Layerable: RasterImageLayer) whenever I try to create a new raster I get  an 
error message due to matter that OJ cannot read (or create) a aux.xml file 
(file where some statistics are stored). 
The bug  is important because OJ cannot read the whole raster if it doesn't 
recognize that statistics and it affects basically all Sextante algorithms that 
create rasters
To reproduce the bug (I used OpenJUMP-20200828-r6395-PLUS - Batik 1.6 and 
OpenJUMP-20200731-r6363-PLUS - Batik 1.6.1, Ubuntu, OpenJDK 64bit 1.8.0.252)
a) open a monoband tiff file (I have just attached a sample)
b) dray a fence on it
c) click on Layer tree > extract part of the image

I tried to understand the reason. 
What I discover is that OJs with Batik 1.6 are not affected by the problem, 
while newer OJ with Batik 1.6.1 show the bug.
That is strange for me as I don't have any error messages on compiling OpenJUMP 
with either Batik 1.6 or Batik 1.6.1.
On the other hand I discovered that OJ shipping Batik 1.6.1 have one Batik 
class with different serial number (batik-1.5-fop-0.20-5.jar).
Any suggestions?
Peppe

This is the error message
javax.xml.transform.TransformerException: java.io.FileNotFoundException: 
file:/tmp/Parte%20-dialwdgg_4390.tif.aux.xml (File o directory non esistente)
at 
org.apache.xalan.transformer.TransformerIdentityImpl.createResultContentHandler(TransformerIdentityImpl.java:263)
at 
org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:296)
at 
org.openjump.core.rasterimage.GDALPamDataset.writeStatistics(GDALPamDataset.java:131)
at 
org.openjump.core.rasterimage.TiffUtils.createStatsXml(TiffUtils.java:302)
at 
org.openjump.core.rasterimage.TiffUtils.calculateStats(TiffUtils.java:251)
at org.openjump.core.rasterimage.TiffUtils.readImage(TiffUtils.java:68)
at 
org.openjump.core.rasterimage.RasterImageIO.loadImage(RasterImageIO.java:143)
at 
org.openjump.core.ui.plugin.layer.pirolraster.ExtractSelectedPartOfImage.execute(ExtractSelectedPartOfImage.java:182)
at 
com.vividsolutions.jump.workbench.plugin.AbstractPlugIn$1.actionPerformed(AbstractPlugIn.java:344)
at 
javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2022)
at 
javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2348)
at 
javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402)
at 
javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259)
at javax.swing.AbstractButton.doClick(AbstractButton.java:376)
at 
javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:842)
at 
javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:886)
at java.awt.Component.processMouseEvent(Component.java:6539)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3324)
at java.awt.Component.processEvent(Component.java:6304)
at java.awt.Container.processEvent(Container.java:2239)
at java.awt.Component.dispatchEventImpl(Component.java:4889)
at java.awt.Container.dispatchEventImpl(Container.java:2297)
at java.awt.Component.dispatchEvent(Component.java:4711)
at 
java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4904)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4535)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4476)
at java.awt.Container.dispatchEventImpl(Container.java:2283)
at java.awt.Window.dispatchEventImpl(Window.java:2746)
at java.awt.Component.dispatchEvent(Component.java:4711)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:760)
at java.awt.EventQueue.access$500(EventQueue.java:97)
at java.awt.EventQueue$3.run(EventQueue.java:709)
at java.awt.EventQueue$3.run(EventQueue.java:703)
at java.security.AccessController.doPrivileged(Native Met

[JPP-Devel] [jump-pilot:bugs] #500 possible important bug on Batik 1.6.1

[Giuseppe Aruta via Jump-pilot-devel]

tested on newer OJ 6400


---

** [bugs:#500] possible important bug on Batik 1.6.1**

**Status:** open
**Milestone:** OJ_1.16
**Created:** Sun Aug 30, 2020 03:17 PM UTC by Giuseppe Aruta
**Last Updated:** Tue Sep 01, 2020 09:50 AM UTC
**Owner:** nobody
**Attachments:**

- 
[geotiff.tfw](https://sourceforge.net/p/jump-pilot/bugs/500/attachment/geotiff.tfw)
 (42 Bytes; application/octet-stream)
- 
[geotiff.tif](https://sourceforge.net/p/jump-pilot/bugs/500/attachment/geotiff.tif)
 (986.3 kB; image/tiff)
- 
[geotiff.tif.aux.xml](https://sourceforge.net/p/jump-pilot/bugs/500/attachment/geotiff.tif.aux.xml)
 (374 Bytes; text/xml)


Hi all,
(Layerable: RasterImageLayer) whenever I try to create a new raster I get  an 
error message due to matter that OJ cannot read (or create) a aux.xml file 
(file where some statistics are stored). 
The bug  is important because OJ cannot read the whole raster if it doesn't 
recognize that statistics and it affects basically all Sextante algorithms that 
create rasters
To reproduce the bug (I used OpenJUMP-20200828-r6395-PLUS - Batik 1.6 and 
OpenJUMP-20200731-r6363-PLUS - Batik 1.6.1, Ubuntu, OpenJDK 64bit 1.8.0.252)
a) open a monoband tiff file (I have just attached a sample)
b) dray a fence on it
c) click on Layer tree > extract part of the image

I tried to understand the reason. 
What I discover is that OJs with Batik 1.6 are not affected by the problem, 
while newer OJ with Batik 1.6.1 show the bug.
That is strange for me as I don't have any error messages on compiling OpenJUMP 
with either Batik 1.6 or Batik 1.6.1.
On the other hand I discovered that OJ shipping Batik 1.6.1 have one Batik 
class with different serial number (batik-1.5-fop-0.20-5.jar).
Any suggestions?
Peppe

This is the error message
javax.xml.transform.TransformerException: java.io.FileNotFoundException: 
file:/tmp/Parte%20-dialwdgg_4390.tif.aux.xml (File o directory non esistente)
at 
org.apache.xalan.transformer.TransformerIdentityImpl.createResultContentHandler(TransformerIdentityImpl.java:263)
at 
org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:296)
at 
org.openjump.core.rasterimage.GDALPamDataset.writeStatistics(GDALPamDataset.java:131)
at 
org.openjump.core.rasterimage.TiffUtils.createStatsXml(TiffUtils.java:302)
at 
org.openjump.core.rasterimage.TiffUtils.calculateStats(TiffUtils.java:251)
at org.openjump.core.rasterimage.TiffUtils.readImage(TiffUtils.java:68)
at 
org.openjump.core.rasterimage.RasterImageIO.loadImage(RasterImageIO.java:143)
at 
org.openjump.core.ui.plugin.layer.pirolraster.ExtractSelectedPartOfImage.execute(ExtractSelectedPartOfImage.java:182)
at 
com.vividsolutions.jump.workbench.plugin.AbstractPlugIn$1.actionPerformed(AbstractPlugIn.java:344)
at 
javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2022)
at 
javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2348)
at 
javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402)
at 
javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259)
at javax.swing.AbstractButton.doClick(AbstractButton.java:376)
at 
javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:842)
at 
javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:886)
at java.awt.Component.processMouseEvent(Component.java:6539)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3324)
at java.awt.Component.processEvent(Component.java:6304)
at java.awt.Container.processEvent(Container.java:2239)
at java.awt.Component.dispatchEventImpl(Component.java:4889)
at java.awt.Container.dispatchEventImpl(Container.java:2297)
at java.awt.Component.dispatchEvent(Component.java:4711)
at 
java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4904)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4535)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4476)
at java.awt.Container.dispatchEventImpl(Container.java:2283)
at java.awt.Window.dispatchEventImpl(Window.java:2746)
at java.awt.Component.dispatchEvent(Component.java:4711)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:760)
at java.awt.EventQueue.access$500(EventQueue.java:97)
at java.awt.EventQueue$3.run(EventQueue.java:709)
at java.awt.EventQueue$3.run(EventQueue.java:703)
at java.security.AccessController.doPrivileged(Native Method)
at 
java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
at 
java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:84)
at java.awt.EventQueue$4.run(EventQueue.java:733)
at java.awt.EventQueue$4.

[JPP-Devel] [jump-pilot:bugs] #500 possible important bug on Batik 1.6.1

[Giuseppe Aruta via Jump-pilot-devel]

I found the reason,
a)   missing class serializer-2.7.2.jar
b) obsolete  class xalan-2.4.1.jar

How to solve:
in the LIB folder 
a) substitute xalan-2.4.1.jar witn newer xalan-2.7.2.jar
b) copy lib serializer-2.7.2.jar

with this modification opening TIF files without aux.xml sidecar files works 
fine

Note that both xalan and serializer are part of Apache libraries. I used newer 
xalan and serializer but I am not sure if these classes 2.7.2 are compatible 
with Batik 1.6.1



---

** [bugs:#500] possible important bug on Batik 1.6.1**

**Status:** open
**Milestone:** OJ_1.16
**Created:** Sun Aug 30, 2020 03:17 PM UTC by Giuseppe Aruta
**Last Updated:** Mon Aug 31, 2020 05:19 AM UTC
**Owner:** nobody
**Attachments:**

- 
[geotiff.tfw](https://sourceforge.net/p/jump-pilot/bugs/500/attachment/geotiff.tfw)
 (42 Bytes; application/octet-stream)
- 
[geotiff.tif](https://sourceforge.net/p/jump-pilot/bugs/500/attachment/geotiff.tif)
 (986.3 kB; image/tiff)
- 
[geotiff.tif.aux.xml](https://sourceforge.net/p/jump-pilot/bugs/500/attachment/geotiff.tif.aux.xml)
 (374 Bytes; text/xml)


Hi all,
(Layerable: RasterImageLayer) whenever I try to create a new raster I get  an 
error message due to matter that OJ cannot read (or create) a aux.xml file 
(file where some statistics are stored). 
The bug  is important because OJ cannot read the whole raster if it doesn't 
recognize that statistics and it affects basically all Sextante algorithms that 
create rasters
To reproduce the bug (I used OpenJUMP-20200828-r6395-PLUS - Batik 1.6 and 
OpenJUMP-20200731-r6363-PLUS - Batik 1.6.1, Ubuntu, OpenJDK 64bit 1.8.0.252)
a) open a monoband tiff file (I have just attached a sample)
b) dray a fence on it
c) click on Layer tree > extract part of the image

I tried to understand the reason. 
What I discover is that OJs with Batik 1.6 are not affected by the problem, 
while newer OJ with Batik 1.6.1 show the bug.
That is strange for me as I don't have any error messages on compiling OpenJUMP 
with either Batik 1.6 or Batik 1.6.1.
On the other hand I discovered that OJ shipping Batik 1.6.1 have one Batik 
class with different serial number (batik-1.5-fop-0.20-5.jar).
Any suggestions?
Peppe

This is the error message
javax.xml.transform.TransformerException: java.io.FileNotFoundException: 
file:/tmp/Parte%20-dialwdgg_4390.tif.aux.xml (File o directory non esistente)
at 
org.apache.xalan.transformer.TransformerIdentityImpl.createResultContentHandler(TransformerIdentityImpl.java:263)
at 
org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:296)
at 
org.openjump.core.rasterimage.GDALPamDataset.writeStatistics(GDALPamDataset.java:131)
at 
org.openjump.core.rasterimage.TiffUtils.createStatsXml(TiffUtils.java:302)
at 
org.openjump.core.rasterimage.TiffUtils.calculateStats(TiffUtils.java:251)
at org.openjump.core.rasterimage.TiffUtils.readImage(TiffUtils.java:68)
at 
org.openjump.core.rasterimage.RasterImageIO.loadImage(RasterImageIO.java:143)
at 
org.openjump.core.ui.plugin.layer.pirolraster.ExtractSelectedPartOfImage.execute(ExtractSelectedPartOfImage.java:182)
at 
com.vividsolutions.jump.workbench.plugin.AbstractPlugIn$1.actionPerformed(AbstractPlugIn.java:344)
at 
javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2022)
at 
javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2348)
at 
javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402)
at 
javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259)
at javax.swing.AbstractButton.doClick(AbstractButton.java:376)
at 
javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:842)
at 
javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:886)
at java.awt.Component.processMouseEvent(Component.java:6539)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3324)
at java.awt.Component.processEvent(Component.java:6304)
at java.awt.Container.processEvent(Container.java:2239)
at java.awt.Component.dispatchEventImpl(Component.java:4889)
at java.awt.Container.dispatchEventImpl(Container.java:2297)
at java.awt.Component.dispatchEvent(Component.java:4711)
at 
java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4904)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4535)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4476)
at java.awt.Container.dispatchEventImpl(Container.java:2283)
at java.awt.Window.dispatchEventImpl(Window.java:2746)
at java.awt.Component.dispatchEvent(Component.java:4711)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:760)
at java.awt.EventQueue.access$500(EventQueue.java:97)
at java.awt.EventQueue$3.run(EventQueue.java:

Re: [JPP-Devel] [jump-pilot:bugs] #498 Most GeoTIFF drivers fail with a simple GeoTIFF image

[Giuseppe Aruta]

Regarding RasterImageLayer. It has a quite good method to read geospatial
position of GeoTiff, even if fails to read raster. And it automatically
generated a world file. This is a good as I can reopen the GeoTiff with
external software (I prefer imagej) and save back in a format readable by
RasterImageLayer, even loosing position tags. World file will provide back
those info.
The problem comes if original GeoTiff has other important info embedded,
like nodata.

Il dom 30 ago 2020, 10:02 michael michaud via Jump-pilot-devel <
jump-pilot-devel@lists.sourceforge.net> ha scritto:

> --
>
> * [bugs:#498]  Most
> GeoTIFF drivers fail with a simple GeoTIFF image*
>
> *Status:* open
> *Milestone:* OJ_1.16
> *Created:* Sun Aug 30, 2020 08:02 AM UTC by michael michaud
> *Last Updated:* Sun Aug 30, 2020 08:02 AM UTC
> *Owner:* nobody
> *Attachments:*
>
>- small_world.tif
>
>(240.6 kB; image/tiff)
>
> I often have a bad experience trying to read simple geotiff. To have a
> more objective view of the situation, I get a very simple image from the
> test directory of GDAL library and tested it against all our drivers.
> Image is attached. Here are its main characteristics (I think they are
> very common one) :
> small_world.tif
> size : 400 x 200
> Coordinate System : wgs84 (4326)
> Metadata : AREA_OR_POINT=AREA
> Image Structure Metadata : INTERLEAVE=BAND
> 3 bands, Block=400x20, Type=Byte, ColorInterp=RGB
>
> I tried to import it with all the image drivers we propose (8 from Open
> File + ImageRaster Sextante). 3 drivers only could import the image. All
> others fail throughing a rough java exception. Image Raster don't fail
> immediately, but it does not display the image and throws NPE if one try to
> get more information.
>
> List of success/failures and exceptions thrown
>
> Referenced Image (ImageIO[ext],JAI) : OK
> ImageIO TIFF Image Reader version 1.0 : OK
> ImageIO TIFF Image Reader version 1.1 : OK
> Standard TIFF Image Reader
> java.lang.IllegalAccessException: class
> com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset cannot access
> class com.sun.imageio.plugins.tiff.TIFFImageReaderSpi (in module
> java.desktop) because module java.desktop does not export
> com.sun.imageio.plugins.tiff to unnamed module @12405818
> at
> java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:361)
> at
> java.base/jdk.internal.reflect.Reflection.ensureMemberAccess(Reflection.java:99)
> at java.base/java.lang.Class.newInstance(Class.java:579)
> at
> com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.createFeatureFactory(ImageryLayerDataset.java:236)
> at
> com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.attachImage(ImageryLayerDataset.java:117)
> Referenced Image (JAI TIF)
> java.lang.NullPointerException java.lang.NullPointerException at
> com.sun.media.jai.util.SunCachedTile.(SunCachedTile.java:80)
> at com.sun.media.jai.util.SunTileCache.add(SunTileCache.java:257)
> at javax.media.jai.OpImage.addTileToCache(OpImage.java:1087)
> at javax.media.jai.OpImage.getTile(OpImage.java:1142)
> at javax.media.jai.PlanarImage.getData(PlanarImage.java:2085)
> at
> javax.media.jai.RenderedImageAdapter.getData(RenderedImageAdapter.java:158)
> at javax.media.jai.ScaleOpImage.computeTile(ScaleOpImage.java:1099)
> at
> com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java:904)
>
> at javax.media.jai.OpImage.getTile(OpImage.java:1129)
> at com.sun.media.jai.opimage.CropOpImage.getTile(CropOpImage.java:122)
> at
> com.sun.media.jai.opimage.TranslateIntOpImage.getTile(TranslateIntOpImage.java:132)
> at javax.media.jai.PlanarImage.copyData(PlanarImage.java:2343)
> at javax.media.jai.RenderedOp.copyData(RenderedOp.java:2299)
> at javax.media.jai.PlanarImage.getAsBufferedImage(PlanarImage.java:2525)
> at javax.media.jai.PlanarImage.getAsBufferedImage(PlanarImage.java:2546)
> at
> com.vividsolutions.jump.workbench.imagery.geoimg.GeoImage.paint(GeoImage.java:285)
>
> at
> com.vividsolutions.jump.workbench.imagery.ReferencedImageStyle.paint(ReferencedImageStyle.java:61)
> Referenced Image (JAI TIF) : same error
>
> Buffered Image (common) :
> com.vividsolutions.jump.workbench.imagery.ReferencedImageException:
> java.lang.ArrayIndexOutOfBoundsException: Index 8000 out of bounds for
> length 8000
> at
> com.vividsolutions.jump.workbench.imagery.graphic.CommonsImage.initImage(CommonsImage.java:112)
> at
> com.vividsolutions.jump.workbench.imagery.graphic.AbstractGraphicImage.computeEnvelope(AbstractGraphicImage.java:122)
> at
> com.vividsolutions.jump.workbench.imagery.graphic.AbstractGraphicImage.getEnvelope(AbstractGraphicImage.java:114)
> at
> com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.attachImage(ImageryLayerDataset.java:125)
> at
> 

Re: [JPP-Devel] [jump-pilot:bugs] Re: #501 I18N from extension

[Giuseppe Aruta]

>I18N.getInstance("my.great.extension").get(String)

seems more logical and easy to use


Il lun 31 ago 2020, 18:58 ede via Jump-pilot-devel <
jump-pilot-devel@lists.sourceforge.net> ha scritto:

> On 8/31/2020 18:19, michael michaud wrote:
>
> String getText(Syting label)
> String getText(Syting label, Object...objects)
> static String get(Syting label) // legacy
> static String getMessage(Syting label)
> static String getMessage(Syting label, Object...objects)
>
> must remove :
> static getText(String,String)
> could remove
> static getMessage(File,String,Object...objects)
>
> don't like getText() vs getMessage(). i suppose that is going to confuse
> developers, because actually there is no difference between text and
> Message here.
>
> we have the rare chance of breaking backward compatibility with OJ2 let's
> take advantage of it as we will have to touch every extension anyway!
>
> let me propose something logically more sound, even if it'll be a little
> bit more work for us
>
> static (we could hide these, but i don't see why. when first argument is
> null the default resourcebundles are used)
> get(File,String,Object...objects)
> get(String,String,Object...objects)
>
> instance
> get(String,Object...objects) //this notation includes get(String) without
> objects as well
>
> this'll allow for OJ Core
> I18N.getInstance().get(String)
>
> for instances
> I18N.getInstance("my.great.extension").get(String)
> or
> I18N i18n = I18N.getInstance("my.great.extension");
> i18n.get(String)
> i18n.get(String, Object, Object)
> i18n.get(String, new Object[]{ o1, o2, o3})
> --
>
> * [bugs:#501]  I18N from
> extension*
>
> *Status:* open
> *Milestone:* undecided
> *Created:* Mon Aug 31, 2020 10:32 AM UTC by michael michaud
> *Last Updated:* Mon Aug 31, 2020 04:19 PM UTC
> *Owner:* nobody
>
> Ede, I prefer to document the usage of I18N in Extension in a separate
> ticket.
> Here are two reasons which drove me to use a hack instead of the I18N
> class (indeed there is a third : I have been too lazy to try to fix the two
> former reasons) :
> - using categoryPrefixOrPath with properties files in the classpath means
> files are in a subdirectory named language/jump (generally possible, but no
> much reason to be constrained like that);
> - the only public method you can use to get a key in this case is
> getText(final String categoryPrefix, final String key). Currently,
> getMessage(final Object categoryPrefixOrPathOrI18n,
> final String label, final Object... objects) is private. Not sure if we
> must make it public or if we must use I18N instances in extensions instead
> of static methods. A class instance could avoid repeating the
> categoryPrefixOrPathOrI18n parameter again and again).
> - indeed, we can create an instance of I18 for a particular extension, but
> we cannot really use it as most methods are static. For example, if I
> create an instance for myExtension, calling getMessage(final String label,
> final Object... objects) will not search keys in myExtension but in main
> openjump properties file
> --
>
> Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net
> is subscribed to https://sourceforge.net/p/jump-pilot/bugs/
>
> To unsubscribe from further messages, a project admin can change settings
> at https://sourceforge.net/p/jump-pilot/admin/bugs/options. Or, if this
> is a mailing list, you can unsubscribe from the mailing list.
> ___
> 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] [jump-pilot:bugs] #322 OJ stops without warnings on system shutdown

[Giuseppe Aruta]

Regarding Linux, OJ can be launched by console. Closing the console shuts
down Openjump with no saving. Sometimes it can be useful for processes
-Sextante- that can basically divore all memory and freeze OJ . Having a
warning like Kosmo that advice user's that OS is going to shut could be
useful but not a priority (at least in my experience )
I suggest to leave this bug open for the future
Peppe

Il lun 31 ago 2020, 19:33 michael michaud via Jump-pilot-devel <
jump-pilot-devel@lists.sourceforge.net> ha scritto:

> I could not see much effect either (same environment as yours).
> Seems that the saving dialog appears a fraction of second, but the task
> killer is not one to be very patient.
> Also I dicovered that tasks in the taskmanager can show their subprocesses
> : killing OpenJDK kill the whole process, but shuting OpenJUMP down open
> the save dialog (it already did it in the previous versions).
>
> Attachments:
>
>- taskmanager.png
>
> 
>(3.3 kB; image/png)
>
> --
>
> * [bugs:#322]  OJ stops
> without warnings on system shutdown*
>
> *Status:* pending
> *Milestone:* OJ_1.16
> *Created:* Fri May 24, 2013 08:44 PM UTC by Jukka Rahkonen
> *Last Updated:* Mon Aug 31, 2020 12:26 PM UTC
> *Owner:* ede
>
> Tested with version 1.6.1 release on Windows.
> If there are layers with unsaved edits in OpenJUMP and user ask computer
> to shut down, OpenJUMP is closed without any warnings and unsaved edits are
> lost. For comparison, Kosmo GIS 3.0 is keeping the computer in such a state
> that operating system sends a message that Kosmo prevents the shutdown and
> asks if user wants to cancel or do a forced shutdown.
> --
>
> Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net
> is subscribed to https://sourceforge.net/p/jump-pilot/bugs/
>
> To unsubscribe from further messages, a project admin can change settings
> at https://sourceforge.net/p/jump-pilot/admin/bugs/options. Or, if this
> is a mailing list, you can unsubscribe from the mailing list.
> ___
> 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] [jump-pilot:bugs] #482 OpenJUMP Style - "Style">"Import ArcMap Style" seems hard to work

[Giuseppe Aruta]

I sugest to keep the code and plugin into the repository but not the
plugin into OJ 1.16

> I prepared an extension in the plug-ins section of the repo. I did not solve 
> the previous problem but the extension compiles, it is loaded and it produces 
> the exact same error as the internal version (see above). I extracted 
> translations for en, de, es, fi, fr and it from the main language file. Not 
> sure it is worth keeping the current version in 1.16 if we don't 
> solve/document the problem before migration: Last Updated: Sat Aug 29, 2020 
> 08:20 PM UTC Owner: Giuseppe Aruta 
> ___ 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] [jump-pilot:bugs] #500 possible important bug on Batik 1.6.1

[Giuseppe Aruta]

Hi Ede, see the answers below

*>one of the reasons apart from the stack that i don't believe it's batik.
there's no svg involved here.*
OpenJUMP doesn't use Batik to export SVG but also to write/read XML files

1.
* >is "Extract selected part" the only way it fails? so open/saving
RasterImageLayers inkl. their aux file works?*

No. As I wrote in a previous post, it happens in *every tools* (embedded in
OJ and Sextante) which save/load raster image files. Extract part is one
among all.


*2. how do you draw the fence? sorry, non user :). it's not the polygon
tool nor the selection cursor.*

See answer 1
*. *


*3. to make sure it is batik. take the latest snapshot and replace
everything batik*.jar in lib/ and replace it with the jars from a
snapshot/release that works. is the error gone then?*

Already done. It is almost the same

I also tested with a different PC with Linux Mint 20 with fresh setups of
OpenJUMP (Batik 1.6, Batik 1.13 and Batik 1.6.1) and had the same bug

Peppe

Il giorno lun 31 ago 2020 alle ore 08:47  ha scritto:

> On 31.08.2020 07:19, Giuseppe Aruta via Jump-pilot-devel wrote:
> > I remember we downgrade from Batik 1.13 to Batik 1.6.1 because of
> problems to export to SVG
>
> one of the reasons apart from the stack that i don't believe it's batik.
> there's no svg involved here.
>
> 1.
> is "Extract selected part" the only way it fails? so open/saving
> RasterImageLayers inkl. their aux file works?
>
> 2.
> how do you draw the fence? sorry, non user :). it's not the polygon tool
> nor the selection cursor.
>
> 3.
> to make sure it is batik. take the latest snapshot and replace everything
> batik*.jar in lib/ and replace it with the jars from a snapshot/release
> that works. is the error gone then?
>
> sorry, still can't reproduce it. will try on Ubuntu later.
>
> ..ede
>
> > ---
> >
> > ** [bugs:#500] possible important bug on Batik 1.6.1**
> >
> > **Status:** open
> > **Milestone:** OJ_1.16
> > **Created:** Sun Aug 30, 2020 03:17 PM UTC by Giuseppe Aruta
> > **Last Updated:** Mon Aug 31, 2020 05:18 AM UTC
> > **Owner:** nobody
> > **Attachments:**
> >
> > - [geotiff.tfw](
> https://sourceforge.net/p/jump-pilot/bugs/500/attachment/geotiff.tfw) (42
> Bytes; application/octet-stream)
> > - [geotiff.tif](
> https://sourceforge.net/p/jump-pilot/bugs/500/attachment/geotiff.tif)
> (986.3 kB; image/tiff)
> > - [geotiff.tif.aux.xml](
> https://sourceforge.net/p/jump-pilot/bugs/500/attachment/geotiff.tif.aux.xml)
> (374 Bytes; text/xml)
> >
> >
> > Hi all,
> > (Layerable: RasterImageLayer) whenever I try to create a new raster I
> get  an error message due to matter that OJ cannot read (or create) a
> aux.xml file (file where some statistics are stored).
> > The bug  is important because OJ cannot read the whole raster if it
> doesn't recognize that statistics and it affects basically all Sextante
> algorithms that create rasters
> > To reproduce the bug (I used OpenJUMP-20200828-r6395-PLUS - Batik 1.6
> and OpenJUMP-20200731-r6363-PLUS - Batik 1.6.1, Ubuntu, OpenJDK 64bit
> 1.8.0.252)
> > a) open a monoband tiff file (I have just attached a sample)
> > b) dray a fence on it
> > c) click on Layer tree > extract part of the image
> >
> > I tried to understand the reason.
> > What I discover is that OJs with Batik 1.6 are not affected by the
> problem, while newer OJ with Batik 1.6.1 show the bug.
> > That is strange for me as I don't have any error messages on compiling
> OpenJUMP with either Batik 1.6 or Batik 1.6.1.
> > On the other hand I discovered that OJ shipping Batik 1.6.1 have one
> Batik class with different serial number (batik-1.5-fop-0.20-5.jar).
> > Any suggestions?
> > Peppe
> >
> > This is the error message
> > javax.xml.transform.TransformerException: java.io.FileNotFoundException:
> file:/tmp/Parte%20-dialwdgg_4390.tif.aux.xml (File o directory non
> esistente)
> >   at
> org.apache.xalan.transformer.TransformerIdentityImpl.createResultContentHandler(TransformerIdentityImpl.java:263)
> >   at
> org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:296)
> >   at
> org.openjump.core.rasterimage.GDALPamDataset.writeStatistics(GDALPamDataset.java:131)
> >   at
> org.openjump.core.rasterimage.TiffUtils.createStatsXml(TiffUtils.java:302)
> >   at
> org.openjump.core.rasterimage.TiffUtils.calculateStats(TiffUtils.java:251)
> >   at
> org.openjump.core.rasterimage.TiffUtils.readImage(TiffUtils.java:68)
> >   at
> org.openjump.core.rasterimage.RasterImageIO.loadImage(RasterImageIO.java:143)
> >

[JPP-Devel] [jump-pilot:bugs] #500 possible important bug on Batik 1.6.1

[Giuseppe Aruta via Jump-pilot-devel]

I remember we downgrade from Batik 1.13 to Batik 1.6.1 because of problems to 
export to SVG


---

** [bugs:#500] possible important bug on Batik 1.6.1**

**Status:** open
**Milestone:** OJ_1.16
**Created:** Sun Aug 30, 2020 03:17 PM UTC by Giuseppe Aruta
**Last Updated:** Mon Aug 31, 2020 05:18 AM UTC
**Owner:** nobody
**Attachments:**

- 
[geotiff.tfw](https://sourceforge.net/p/jump-pilot/bugs/500/attachment/geotiff.tfw)
 (42 Bytes; application/octet-stream)
- 
[geotiff.tif](https://sourceforge.net/p/jump-pilot/bugs/500/attachment/geotiff.tif)
 (986.3 kB; image/tiff)
- 
[geotiff.tif.aux.xml](https://sourceforge.net/p/jump-pilot/bugs/500/attachment/geotiff.tif.aux.xml)
 (374 Bytes; text/xml)


Hi all,
(Layerable: RasterImageLayer) whenever I try to create a new raster I get  an 
error message due to matter that OJ cannot read (or create) a aux.xml file 
(file where some statistics are stored). 
The bug  is important because OJ cannot read the whole raster if it doesn't 
recognize that statistics and it affects basically all Sextante algorithms that 
create rasters
To reproduce the bug (I used OpenJUMP-20200828-r6395-PLUS - Batik 1.6 and 
OpenJUMP-20200731-r6363-PLUS - Batik 1.6.1, Ubuntu, OpenJDK 64bit 1.8.0.252)
a) open a monoband tiff file (I have just attached a sample)
b) dray a fence on it
c) click on Layer tree > extract part of the image

I tried to understand the reason. 
What I discover is that OJs with Batik 1.6 are not affected by the problem, 
while newer OJ with Batik 1.6.1 show the bug.
That is strange for me as I don't have any error messages on compiling OpenJUMP 
with either Batik 1.6 or Batik 1.6.1.
On the other hand I discovered that OJ shipping Batik 1.6.1 have one Batik 
class with different serial number (batik-1.5-fop-0.20-5.jar).
Any suggestions?
Peppe

This is the error message
javax.xml.transform.TransformerException: java.io.FileNotFoundException: 
file:/tmp/Parte%20-dialwdgg_4390.tif.aux.xml (File o directory non esistente)
at 
org.apache.xalan.transformer.TransformerIdentityImpl.createResultContentHandler(TransformerIdentityImpl.java:263)
at 
org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:296)
at 
org.openjump.core.rasterimage.GDALPamDataset.writeStatistics(GDALPamDataset.java:131)
at 
org.openjump.core.rasterimage.TiffUtils.createStatsXml(TiffUtils.java:302)
at 
org.openjump.core.rasterimage.TiffUtils.calculateStats(TiffUtils.java:251)
at org.openjump.core.rasterimage.TiffUtils.readImage(TiffUtils.java:68)
at 
org.openjump.core.rasterimage.RasterImageIO.loadImage(RasterImageIO.java:143)
at 
org.openjump.core.ui.plugin.layer.pirolraster.ExtractSelectedPartOfImage.execute(ExtractSelectedPartOfImage.java:182)
at 
com.vividsolutions.jump.workbench.plugin.AbstractPlugIn$1.actionPerformed(AbstractPlugIn.java:344)
at 
javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2022)
at 
javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2348)
at 
javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402)
at 
javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259)
at javax.swing.AbstractButton.doClick(AbstractButton.java:376)
at 
javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:842)
at 
javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:886)
at java.awt.Component.processMouseEvent(Component.java:6539)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3324)
at java.awt.Component.processEvent(Component.java:6304)
at java.awt.Container.processEvent(Container.java:2239)
at java.awt.Component.dispatchEventImpl(Component.java:4889)
at java.awt.Container.dispatchEventImpl(Container.java:2297)
at java.awt.Component.dispatchEvent(Component.java:4711)
at 
java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4904)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4535)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4476)
at java.awt.Container.dispatchEventImpl(Container.java:2283)
at java.awt.Window.dispatchEventImpl(Window.java:2746)
at java.awt.Component.dispatchEvent(Component.java:4711)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:760)
at java.awt.EventQueue.access$500(EventQueue.java:97)
at java.awt.EventQueue$3.run(EventQueue.java:709)
at java.awt.EventQueue$3.run(EventQueue.java:703)
at java.security.AccessController.doPrivileged(Native Method)
at 
java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
at 
java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java

[JPP-Devel] [jump-pilot:bugs] #500 possible important bug on Batik 1.6.1

[Giuseppe Aruta via Jump-pilot-devel]

*can you check, is your folder /tmp existing and writable by you?*

Yes. It is both existing and writable. But the problem is neither the status of 
tmp folder nor a space in the path: on my machine it happens on every folder I 
try to use. 

*i just committed a line, you can check the surrounding code as well. it reads 
like the reader wants to read the stats, but in case it fails (on any error!) 
it will automatically try to create an aux.xml file.*  

See the new error message at the end of this post when I tried to save part of 
the file in the desktop (using Raster>cut/deform raster plugin). 

Again. I have no problem with OpenJUMP shipping Batik 1.6 
(OpenJUMP-20200731-r6363-PLUS) and OBatik 1.13 (OpenJUMP-20200805-r6370-PLUS)
The bug starts from when OpenJUMP ships 1.6.1. (OpenJUMP-20200816-r6375-PLUS).

---
javax.xml.transform.TransformerException: java.io.FileNotFoundException: 
file:/home/giuseppe/Desktop/13.tif.aux.xml (File o directory non esistente)
at 
org.apache.xalan.transformer.TransformerIdentityImpl.createResultContentHandler(TransformerIdentityImpl.java:263)
at 
org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:296)
at 
org.openjump.core.rasterimage.GDALPamDataset.writeStatistics(GDALPamDataset.java:131)
at 
org.openjump.core.rasterimage.TiffUtils.createStatsXml(TiffUtils.java:305)
at 
org.openjump.core.rasterimage.TiffUtils.calculateStats(TiffUtils.java:254)
at org.openjump.core.rasterimage.TiffUtils.readImage(TiffUtils.java:70)
at 
org.openjump.core.rasterimage.RasterImageIO.loadImage(RasterImageIO.java:143)
at 
org.openjump.core.rasterimage.algorithms.GenericRasterAlgorithm.load(GenericRasterAlgorithm.java:393)
at 
org.openjump.core.ui.plugin.raster.CropWarpPlugIn.run(CropWarpPlugIn.java:273)
at 
com.vividsolutions.jump.workbench.ui.task.TaskMonitorManager$TaskWrapper.run(TaskMonitorManager.java:151)
Caused by: java.io.FileNotFoundException: 
file:/home/giuseppe/Desktop/13.tif.aux.xml (File o directory non esistente)
at java.io.FileOutputStream.open0(Native Method)
at java.io.FileOutputStream.open(FileOutputStream.java:270)
at java.io.FileOutputStream.(FileOutputStream.java:213)
at java.io.FileOutputStream.(FileOutputStream.java:101)
at 
org.apache.xalan.transformer.TransformerIdentityImpl.createResultContentHandler(TransformerIdentityImpl.java:253)
... 9 more
-
java.io.FileNotFoundException: file:/home/giuseppe/Desktop/13.tif.aux.xml (File 
o directory non esistente)
at java.io.FileOutputStream.open0(Native Method)
at java.io.FileOutputStream.open(FileOutputStream.java:270)
at java.io.FileOutputStream.(FileOutputStream.java:213)
at java.io.FileOutputStream.(FileOutputStream.java:101)
at 
org.apache.xalan.transformer.TransformerIdentityImpl.createResultContentHandler(TransformerIdentityImpl.java:253)
at 
org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:296)
at 
org.openjump.core.rasterimage.GDALPamDataset.writeStatistics(GDALPamDataset.java:131)
at 
org.openjump.core.rasterimage.TiffUtils.createStatsXml(TiffUtils.java:305)
at 
org.openjump.core.rasterimage.TiffUtils.calculateStats(TiffUtils.java:254)
at org.openjump.core.rasterimage.TiffUtils.readImage(TiffUtils.java:70)
at 
org.openjump.core.rasterimage.RasterImageIO.loadImage(RasterImageIO.java:143)
at 
org.openjump.core.rasterimage.algorithms.GenericRasterAlgorithm.load(GenericRasterAlgorithm.java:393)
at 
org.openjump.core.ui.plugin.raster.CropWarpPlugIn.run(CropWarpPlugIn.java:273)
at 
com.vividsolutions.jump.workbench.ui.task.TaskMonitorManager$TaskWrapper.run(TaskMonitorManager.java:151)



---

** [bugs:#500] possible important bug on Batik 1.6.1**

**Status:** open
**Milestone:** OJ_1.16
**Created:** Sun Aug 30, 2020 03:17 PM UTC by Giuseppe Aruta
**Last Updated:** Sun Aug 30, 2020 08:50 PM UTC
**Owner:** nobody
**Attachments:**

- 
[geotiff.tfw](https://sourceforge.net/p/jump-pilot/bugs/500/attachment/geotiff.tfw)
 (42 Bytes; application/octet-stream)
- 
[geotiff.tif](https://sourceforge.net/p/jump-pilot/bugs/500/attachment/geotiff.tif)
 (986.3 kB; image/tiff)
- 
[geotiff.tif.aux.xml](https://sourceforge.net/p/jump-pilot/bugs/500/attachment/geotiff.tif.aux.xml)
 (374 Bytes; text/xml)


Hi all,
(Layerable: RasterImageLayer) whenever I try to create a new raster I get  an 
error message due to matter that OJ cannot read (or create) a aux.xml file 
(file where some statistics are stored). 
The bug  is important because OJ cannot read the whole raster if it doesn't 
recognize that statistics and it affects basically all Sextante algorithms that 
create rasters
To reproduce the bug (I used OpenJUMP-20200828-r6395-PLUS - Ba

[JPP-Devel] [jump-pilot:bugs] #500 possible important bug on Batik 1.6.1

[Giuseppe Aruta via Jump-pilot-devel]

Hi Ede,
> did you rename the samples before you uploaded them?
No. file:/tmp/Parte%20-dialwdgg_4390.tif.aux.xml should be automatically 
created by OJ when it load the new generated file.

>the files you attached open and save fine incl. the aux file on windows within 
>eclipse current trunk revision
If I try to load the TIFF file, located into a folder without the aux.xml file, 
I have the same message error (java.io.FileNotFoundException). And OJ can read 
only the extension of the tif, not the raster: de facto it is not displayed 
into the view


---

** [bugs:#500] possible important bug on Batik 1.6.1**

**Status:** open
**Milestone:** OJ_1.16
**Created:** Sun Aug 30, 2020 03:17 PM UTC by Giuseppe Aruta
**Last Updated:** Sun Aug 30, 2020 03:19 PM UTC
**Owner:** nobody
**Attachments:**

- 
[geotiff.tfw](https://sourceforge.net/p/jump-pilot/bugs/500/attachment/geotiff.tfw)
 (42 Bytes; application/octet-stream)
- 
[geotiff.tif](https://sourceforge.net/p/jump-pilot/bugs/500/attachment/geotiff.tif)
 (986.3 kB; image/tiff)
- 
[geotiff.tif.aux.xml](https://sourceforge.net/p/jump-pilot/bugs/500/attachment/geotiff.tif.aux.xml)
 (374 Bytes; text/xml)


Hi all,
(Layerable: RasterImageLayer) whenever I try to create a new raster I get  an 
error message due to matter that OJ cannot read (or create) a aux.xml file 
(file where some statistics are stored). 
The bug  is important because OJ cannot read the whole raster if it doesn't 
recognize that statistics and it affects basically all Sextante algorithms that 
create rasters
To reproduce the bug (I used OpenJUMP-20200828-r6395-PLUS - Batik 1.6 and 
OpenJUMP-20200731-r6363-PLUS - Batik 1.6.1, Ubuntu, OpenJDK 64bit 1.8.0.252)
a) open a monoband tiff file (I have just attached a sample)
b) dray a fence on it
c) click on Layer tree > extract part of the image

I tried to understand the reason. 
What I discover is that OJs with Batik 1.6 are not affected by the problem, 
while newer OJ with Batik 1.6.1 show the bug.
That is strange for me as I don't have any error messages on compiling OpenJUMP 
with either Batik 1.6 or Batik 1.6.1.
On the other hand I discovered that OJ shipping Batik 1.6.1 have one Batik 
class with different serial number (batik-1.5-fop-0.20-5.jar).
Any suggestions?
Peppe

This is the error message
javax.xml.transform.TransformerException: java.io.FileNotFoundException: 
file:/tmp/Parte%20-dialwdgg_4390.tif.aux.xml (File o directory non esistente)
at 
org.apache.xalan.transformer.TransformerIdentityImpl.createResultContentHandler(TransformerIdentityImpl.java:263)
at 
org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:296)
at 
org.openjump.core.rasterimage.GDALPamDataset.writeStatistics(GDALPamDataset.java:131)
at 
org.openjump.core.rasterimage.TiffUtils.createStatsXml(TiffUtils.java:302)
at 
org.openjump.core.rasterimage.TiffUtils.calculateStats(TiffUtils.java:251)
at org.openjump.core.rasterimage.TiffUtils.readImage(TiffUtils.java:68)
at 
org.openjump.core.rasterimage.RasterImageIO.loadImage(RasterImageIO.java:143)
at 
org.openjump.core.ui.plugin.layer.pirolraster.ExtractSelectedPartOfImage.execute(ExtractSelectedPartOfImage.java:182)
at 
com.vividsolutions.jump.workbench.plugin.AbstractPlugIn$1.actionPerformed(AbstractPlugIn.java:344)
at 
javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2022)
at 
javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2348)
at 
javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402)
at 
javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259)
at javax.swing.AbstractButton.doClick(AbstractButton.java:376)
at 
javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:842)
at 
javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:886)
at java.awt.Component.processMouseEvent(Component.java:6539)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3324)
at java.awt.Component.processEvent(Component.java:6304)
at java.awt.Container.processEvent(Container.java:2239)
at java.awt.Component.dispatchEventImpl(Component.java:4889)
at java.awt.Container.dispatchEventImpl(Container.java:2297)
at java.awt.Component.dispatchEvent(Component.java:4711)
at 
java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4904)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4535)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4476)
at java.awt.Container.dispatchEventImpl(Container.java:2283)
at java.awt.Window.dispatchEventImpl(Window.java:2746)
at java.awt.Component.dispatchEvent(Component.java:4711)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:760)
at java.awt.EventQueu

[JPP-Devel] [jump-pilot:bugs] #500 possible important bug on Batik 1.6.1

[Giuseppe Aruta via Jump-pilot-devel]

- Description has changed:

Diff:



--- old
+++ new
@@ -1,6 +1,15 @@
-Hi all,(Layerable: RasterImageLayer) whenever I try to create a new raster I 
get  an error message due to matter that OJ cannot read (or create) a aux.xml 
file (file where some statistics are stored). The bug  is important because OJ 
cannot read the whole raster if it doesn't recognize that statistics and it 
affects basically all Sextante algorithms that create rastersTo reproduce the 
bug (I used OpenJUMP-20200828-r6395-PLUS - Batik 1.6 and 
OpenJUMP-20200731-r6363-PLUS - Batik 1.6.1, Ubuntu, OpenJDK 64bit 1.8.0.252):a) 
open a monoband tiff file (a have just attached a sample)b) dray a fence on 
itc) click on Layer tree > extract part of the image
+Hi all,
+(Layerable: RasterImageLayer) whenever I try to create a new raster I get  an 
error message due to matter that OJ cannot read (or create) a aux.xml file 
(file where some statistics are stored). 
+The bug  is important because OJ cannot read the whole raster if it doesn't 
recognize that statistics and it affects basically all Sextante algorithms that 
create rasters
+To reproduce the bug (I used OpenJUMP-20200828-r6395-PLUS - Batik 1.6 and 
OpenJUMP-20200731-r6363-PLUS - Batik 1.6.1, Ubuntu, OpenJDK 64bit 1.8.0.252)
+a) open a monoband tiff file (I have just attached a sample)
+b) dray a fence on it
+c) click on Layer tree > extract part of the image
 
-I tried to understand the reason. What I discover is that OJs with Batik 1.6 
are not affected by the problem, while newer OJ with Batik 1.6.1 show the 
bug.That is strange for me as I don't have any error messages on compiling 
OpenJUMP with either Batik 1.6 or Batik 1.6.1.On the other hand I discovered 
that OJ shipping Batik 1.6.1 have one Batik class with different serial number 
(batik-1.5-fop-0.20-5.jar).I don't know what to do. I open a bug.
+I tried to understand the reason. 
+What I discover is that OJs with Batik 1.6 are not affected by the problem, 
while newer OJ with Batik 1.6.1 show the bug.
+That is strange for me as I don't have any error messages on compiling 
OpenJUMP with either Batik 1.6 or Batik 1.6.1.
+On the other hand I discovered that OJ shipping Batik 1.6.1 have one Batik 
class with different serial number (batik-1.5-fop-0.20-5.jar).
 Any suggestions?
 Peppe
 






---

** [bugs:#500] possible important bug on Batik 1.6.1**

**Status:** open
**Milestone:** OJ_1.16
**Created:** Sun Aug 30, 2020 03:17 PM UTC by Giuseppe Aruta
**Last Updated:** Sun Aug 30, 2020 03:17 PM UTC
**Owner:** nobody
**Attachments:**

- 
[geotiff.tfw](https://sourceforge.net/p/jump-pilot/bugs/500/attachment/geotiff.tfw)
 (42 Bytes; application/octet-stream)
- 
[geotiff.tif](https://sourceforge.net/p/jump-pilot/bugs/500/attachment/geotiff.tif)
 (986.3 kB; image/tiff)
- 
[geotiff.tif.aux.xml](https://sourceforge.net/p/jump-pilot/bugs/500/attachment/geotiff.tif.aux.xml)
 (374 Bytes; text/xml)


Hi all,
(Layerable: RasterImageLayer) whenever I try to create a new raster I get  an 
error message due to matter that OJ cannot read (or create) a aux.xml file 
(file where some statistics are stored). 
The bug  is important because OJ cannot read the whole raster if it doesn't 
recognize that statistics and it affects basically all Sextante algorithms that 
create rasters
To reproduce the bug (I used OpenJUMP-20200828-r6395-PLUS - Batik 1.6 and 
OpenJUMP-20200731-r6363-PLUS - Batik 1.6.1, Ubuntu, OpenJDK 64bit 1.8.0.252)
a) open a monoband tiff file (I have just attached a sample)
b) dray a fence on it
c) click on Layer tree > extract part of the image

I tried to understand the reason. 
What I discover is that OJs with Batik 1.6 are not affected by the problem, 
while newer OJ with Batik 1.6.1 show the bug.
That is strange for me as I don't have any error messages on compiling OpenJUMP 
with either Batik 1.6 or Batik 1.6.1.
On the other hand I discovered that OJ shipping Batik 1.6.1 have one Batik 
class with different serial number (batik-1.5-fop-0.20-5.jar).
Any suggestions?
Peppe

This is the error message
javax.xml.transform.TransformerException: java.io.FileNotFoundException: 
file:/tmp/Parte%20-dialwdgg_4390.tif.aux.xml (File o directory non esistente)
at 
org.apache.xalan.transformer.TransformerIdentityImpl.createResultContentHandler(TransformerIdentityImpl.java:263)
at 
org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:296)
at 
org.openjump.core.rasterimage.GDALPamDataset.writeStatistics(GDALPamDataset.java:131)
at 
org.openjump.core.rasterimage.TiffUtils.createStatsXml(TiffUtils.java:302)
at 
org.openjump.core.rasterimage.TiffUtils.calculateStats(TiffUtils.java:251)
at org.openjump.core.rasterimage.TiffUtils.readImage(TiffUtils.java:68)
at 
org.openjump.core.rasterimage.RasterImageIO.loadImage(RasterImageIO.java:143)
at 
org.openjump.core.ui.plugin.layer.pirolraster.ExtractSelectedPartOfImag

[JPP-Devel] [jump-pilot:bugs] #500 possible important bug on Batik 1.6.1

[Giuseppe Aruta via Jump-pilot-devel]

---

** [bugs:#500] possible important bug on Batik 1.6.1**

**Status:** open
**Milestone:** OJ_1.16
**Created:** Sun Aug 30, 2020 03:17 PM UTC by Giuseppe Aruta
**Last Updated:** Sun Aug 30, 2020 03:17 PM UTC
**Owner:** nobody
**Attachments:**

- 
[geotiff.tfw](https://sourceforge.net/p/jump-pilot/bugs/500/attachment/geotiff.tfw)
 (42 Bytes; application/octet-stream)
- 
[geotiff.tif](https://sourceforge.net/p/jump-pilot/bugs/500/attachment/geotiff.tif)
 (986.3 kB; image/tiff)
- 
[geotiff.tif.aux.xml](https://sourceforge.net/p/jump-pilot/bugs/500/attachment/geotiff.tif.aux.xml)
 (374 Bytes; text/xml)


Hi all,(Layerable: RasterImageLayer) whenever I try to create a new raster I 
get  an error message due to matter that OJ cannot read (or create) a aux.xml 
file (file where some statistics are stored). The bug  is important because OJ 
cannot read the whole raster if it doesn't recognize that statistics and it 
affects basically all Sextante algorithms that create rastersTo reproduce the 
bug (I used OpenJUMP-20200828-r6395-PLUS - Batik 1.6 and 
OpenJUMP-20200731-r6363-PLUS - Batik 1.6.1, Ubuntu, OpenJDK 64bit 1.8.0.252):a) 
open a monoband tiff file (a have just attached a sample)b) dray a fence on 
itc) click on Layer tree > extract part of the image

I tried to understand the reason. What I discover is that OJs with Batik 1.6 
are not affected by the problem, while newer OJ with Batik 1.6.1 show the 
bug.That is strange for me as I don't have any error messages on compiling 
OpenJUMP with either Batik 1.6 or Batik 1.6.1.On the other hand I discovered 
that OJ shipping Batik 1.6.1 have one Batik class with different serial number 
(batik-1.5-fop-0.20-5.jar).I don't know what to do. I open a bug.
Any suggestions?
Peppe

This is the error message
javax.xml.transform.TransformerException: java.io.FileNotFoundException: 
file:/tmp/Parte%20-dialwdgg_4390.tif.aux.xml (File o directory non esistente)
at 
org.apache.xalan.transformer.TransformerIdentityImpl.createResultContentHandler(TransformerIdentityImpl.java:263)
at 
org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:296)
at 
org.openjump.core.rasterimage.GDALPamDataset.writeStatistics(GDALPamDataset.java:131)
at 
org.openjump.core.rasterimage.TiffUtils.createStatsXml(TiffUtils.java:302)
at 
org.openjump.core.rasterimage.TiffUtils.calculateStats(TiffUtils.java:251)
at org.openjump.core.rasterimage.TiffUtils.readImage(TiffUtils.java:68)
at 
org.openjump.core.rasterimage.RasterImageIO.loadImage(RasterImageIO.java:143)
at 
org.openjump.core.ui.plugin.layer.pirolraster.ExtractSelectedPartOfImage.execute(ExtractSelectedPartOfImage.java:182)
at 
com.vividsolutions.jump.workbench.plugin.AbstractPlugIn$1.actionPerformed(AbstractPlugIn.java:344)
at 
javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2022)
at 
javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2348)
at 
javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402)
at 
javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259)
at javax.swing.AbstractButton.doClick(AbstractButton.java:376)
at 
javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:842)
at 
javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:886)
at java.awt.Component.processMouseEvent(Component.java:6539)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3324)
at java.awt.Component.processEvent(Component.java:6304)
at java.awt.Container.processEvent(Container.java:2239)
at java.awt.Component.dispatchEventImpl(Component.java:4889)
at java.awt.Container.dispatchEventImpl(Container.java:2297)
at java.awt.Component.dispatchEvent(Component.java:4711)
at 
java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4904)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4535)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4476)
at java.awt.Container.dispatchEventImpl(Container.java:2283)
at java.awt.Window.dispatchEventImpl(Window.java:2746)
at java.awt.Component.dispatchEvent(Component.java:4711)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:760)
at java.awt.EventQueue.access$500(EventQueue.java:97)
at java.awt.EventQueue$3.run(EventQueue.java:709)
at java.awt.EventQueue$3.run(EventQueue.java:703)
at java.security.AccessController.doPrivileged(Native Method)
at 
java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
at 
java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:84)
at java.awt.EventQueue$4.run(EventQueue.java:

Re: [JPP-Devel] SVN: [6391] core/trunk/src/org/openjump/core/ui/plugin/raster/ RasterImageLayerPropertiesPlugIn.java

[Giuseppe Aruta]

Another observation:
org.openjump.core.rasterimage framework is qable anyhow to load the geo
position of (almost) any TIFF files, even if they are not displayed on the
view. Sextante seems to correctly read and analyze  these file even if they
are not displayed


Il giorno sab 29 ago 2020 alle ore 17:59 Giuseppe Aruta <
giuseppe.ar...@gmail.com> ha scritto:

> Hi Ede,
> It is such an euphemism to refer to big files with
> org.openjump.core.rasterimage framework as it takes a quite long time to
> load big files.
> Anyhow I did some tests, using basically TIFF files with no compression
> of different color depth:
> the memory usually increases than goes back at the same level when I
> activate RasterImageLayerpropertiesPlugin (the one which mostly use that
> modification in the source). I did not recognize differences on OpenJUMP
> before and after this modification.
> On the other hand I can load on OJ TIFF file not bigger that 100Mb-150Mb,
> than org.openjump.core.rasterimage framework fails  - I mostly have errors
> on calculate statistics of the file, class GDALPamDataset, or on
> RasterImageLayer.loadfile. So I can not evaluate bigger files.
> On the other hand:
> a) org.openjump.core.rasterimage is basically used to load files which in
> turn are analysed using Sextante toolbox (or OpenKLEM). The few tools which
> are embedded on OJ (and to be used on RasterImageLayers, see Raster menu)
> are basically enhanced versions of Sextante and OpenKLEM. Since all these
> tools are specifically for DEM analysis, users use
> org.openjump.core.rasterimage framework to load single band raster files,
> including TIFF. And these files are usually small
> b) if I want to display a color TIFF map I will use ReferencedImage
> framework, it if far longer better than RasterImageLayer framework as to
> load and display TIFF in a shorter time and lesser memory. All
> ReferenceImageLayer (JAI, ImageIO and GeoSolutions) seems to load files
> which are not possible to load with RasterImageLayer framework.
> c) considering point b), sometimes it is frustrating to work with DEM as
> RasterImageLayer framework seems to fail with some types of TIF, like Aster
> DEM which are quite useful, or (as I discovered recently) with some TIFF
> made using QGIS. I still don't know if  the effect of the libraries, of the
> way TIFF RasterImageLayer framework works (in some files it uses ImageIO in
> other JAI.
>
> I thought the problem was on JAI, but now I am not sure. One day I would
> like to explore com.vividsolutions.jump.workbench.imagery, some of the
> implements have getEnvelope and getImage method which is basically what
> RasterImageLayer needs.
> But this is a job for the future ;-)
>
> Peppe
>
>
> I did a quick test using
>
> Il giorno ven 28 ago 2020 alle ore 16:43  ha scritto:
>
>> hey Peppe,
>>
>> hmm these changes create a copy of the image in memory. can you check
>> with a really big file that this does not "explode" in memory? ..ede
>>
>> On 8/27/2020 10:07 AM, jump-pilot-svn--- via Jump-pilot-devel wrote:
>> > Revision: 6391
>> >   http://sourceforge.net/p/jump-pilot/code/6391
>> > Author:   ma15569
>> > Date: 2020-08-27 08:07:43 + (Thu, 27 Aug 2020)
>> > Log Message:
>> > ---
>> > Workaround to read color depth and DPI from Aster dem files. Previous
>> methods (based on JAI) seem to fail with 32DPI/ 4bpp tiff files
>> >
>> > Modified Paths:
>> > --
>> >
>>  
>> core/trunk/src/org/openjump/core/ui/plugin/raster/RasterImageLayerPropertiesPlugIn.java
>> >
>> > Modified:
>> core/trunk/src/org/openjump/core/ui/plugin/raster/RasterImageLayerPropertiesPlugIn.java
>> > ===
>> > ---
>> core/trunk/src/org/openjump/core/ui/plugin/raster/RasterImageLayerPropertiesPlugIn.java
>>  2020-08-26 16:02:28 UTC (rev 6390)
>> > +++
>> core/trunk/src/org/openjump/core/ui/plugin/raster/RasterImageLayerPropertiesPlugIn.java
>>  2020-08-27 08:07:43 UTC (rev 6391)
>> > @@ -4,6 +4,7 @@
>> >  import java.awt.Dimension;
>> >  import java.awt.GridBagLayout;
>> >  import java.awt.event.ActionEvent;
>> > +import java.awt.image.BufferedImage;
>> >  import java.awt.image.ColorModel;
>> >  import java.awt.image.DataBuffer;
>> >  import java.awt.image.Raster;
>> > @@ -16,7 +17,7 @@
>> >  import java.util.Hashtable;
>> >  import java.util.Locale;
>> >
>> > -import javax.media.jai.PlanarImage;
>> > +//import javax.media.jai.PlanarImage;
>> >  impo

Re: [JPP-Devel] SVN: [6391] core/trunk/src/org/openjump/core/ui/plugin/raster/ RasterImageLayerPropertiesPlugIn.java

[Giuseppe Aruta]

Hi Ede,
It is such an euphemism to refer to big files with
org.openjump.core.rasterimage framework as it takes a quite long time to
load big files.
Anyhow I did some tests, using basically TIFF files with no compression  of
different color depth:
the memory usually increases than goes back at the same level when I
activate RasterImageLayerpropertiesPlugin (the one which mostly use that
modification in the source). I did not recognize differences on OpenJUMP
before and after this modification.
On the other hand I can load on OJ TIFF file not bigger that 100Mb-150Mb,
than org.openjump.core.rasterimage framework fails  - I mostly have errors
on calculate statistics of the file, class GDALPamDataset, or on
RasterImageLayer.loadfile. So I can not evaluate bigger files.
On the other hand:
a) org.openjump.core.rasterimage is basically used to load files which in
turn are analysed using Sextante toolbox (or OpenKLEM). The few tools which
are embedded on OJ (and to be used on RasterImageLayers, see Raster menu)
are basically enhanced versions of Sextante and OpenKLEM. Since all these
tools are specifically for DEM analysis, users use
org.openjump.core.rasterimage framework to load single band raster files,
including TIFF. And these files are usually small
b) if I want to display a color TIFF map I will use ReferencedImage
framework, it if far longer better than RasterImageLayer framework as to
load and display TIFF in a shorter time and lesser memory. All
ReferenceImageLayer (JAI, ImageIO and GeoSolutions) seems to load files
which are not possible to load with RasterImageLayer framework.
c) considering point b), sometimes it is frustrating to work with DEM as
RasterImageLayer framework seems to fail with some types of TIF, like Aster
DEM which are quite useful, or (as I discovered recently) with some TIFF
made using QGIS. I still don't know if  the effect of the libraries, of the
way TIFF RasterImageLayer framework works (in some files it uses ImageIO in
other JAI.

I thought the problem was on JAI, but now I am not sure. One day I would
like to explore com.vividsolutions.jump.workbench.imagery, some of the
implements have getEnvelope and getImage method which is basically what
RasterImageLayer needs.
But this is a job for the future ;-)

Peppe


I did a quick test using

Il giorno ven 28 ago 2020 alle ore 16:43  ha scritto:

> hey Peppe,
>
> hmm these changes create a copy of the image in memory. can you check with
> a really big file that this does not "explode" in memory? ..ede
>
> On 8/27/2020 10:07 AM, jump-pilot-svn--- via Jump-pilot-devel wrote:
> > Revision: 6391
> >   http://sourceforge.net/p/jump-pilot/code/6391
> > Author:   ma15569
> > Date: 2020-08-27 08:07:43 + (Thu, 27 Aug 2020)
> > Log Message:
> > ---
> > Workaround to read color depth and DPI from Aster dem files. Previous
> methods (based on JAI) seem to fail with 32DPI/ 4bpp tiff files
> >
> > Modified Paths:
> > --
> >
>  
> core/trunk/src/org/openjump/core/ui/plugin/raster/RasterImageLayerPropertiesPlugIn.java
> >
> > Modified:
> core/trunk/src/org/openjump/core/ui/plugin/raster/RasterImageLayerPropertiesPlugIn.java
> > ===
> > ---
> core/trunk/src/org/openjump/core/ui/plugin/raster/RasterImageLayerPropertiesPlugIn.java
>  2020-08-26 16:02:28 UTC (rev 6390)
> > +++
> core/trunk/src/org/openjump/core/ui/plugin/raster/RasterImageLayerPropertiesPlugIn.java
>  2020-08-27 08:07:43 UTC (rev 6391)
> > @@ -4,6 +4,7 @@
> >  import java.awt.Dimension;
> >  import java.awt.GridBagLayout;
> >  import java.awt.event.ActionEvent;
> > +import java.awt.image.BufferedImage;
> >  import java.awt.image.ColorModel;
> >  import java.awt.image.DataBuffer;
> >  import java.awt.image.Raster;
> > @@ -16,7 +17,7 @@
> >  import java.util.Hashtable;
> >  import java.util.Locale;
> >
> > -import javax.media.jai.PlanarImage;
> > +//import javax.media.jai.PlanarImage;
> >  import javax.swing.BorderFactory;
> >  import javax.swing.Box;
> >  import javax.swing.Icon;
> > @@ -442,9 +443,10 @@
> >  raster_bands = df.format(rLayer.getNumBands());// Get raster
> number of
> > // bands
> >  Raster raster = rLayer.getRasterData(null);
> > +BufferedImage bImage = rLayer.getImage();
> >  raster_datatype = getDataType(raster); // Get raster data type
> > -raster_colordepth = getColorDepth(raster); // Get raster color
> depth
> > -raster_dpi = getDPI(raster); // Get raster DPI
> > +raster_colordepth = getColorDepth(bImage); // Get raster color
> depth
> > +raster_dpi = getDPI(bImage); // Get raster DPI
> >  extent = rLayer.getWholeImageEnvelope(); // Get Envelope
> >  extent_cellSizeX = df.format(cellSizeX(raster, extent));// Get
> X Cell
> >  // size
> > @@ -616,22 +618,33 @@
> >  /*
> 

[JPP-Devel] [jump-pilot:bugs] #479 OpenJUMp doen't recognize RasterImageLayer SRS on loading anymore

[Giuseppe Aruta via Jump-pilot-devel]

- **status**: open --> closed-fixed
- **Milestone**:  --> undecided



---

** [bugs:#479] OpenJUMp doen't recognize RasterImageLayer SRS on loading 
anymore**

**Status:** closed-fixed
**Milestone:** undecided
**Labels:** SRS 
**Created:** Sat Aug 18, 2018 10:08 AM UTC by Giuseppe Aruta
**Last Updated:** Sat Aug 29, 2020 01:03 PM UTC
**Owner:** Giuseppe Aruta


OpenJUMp doen't recognize RasterImageLayer SRS on loading anymore

The problem is partially connected to AddRasterImageLayerWizard and to 
ProjUtils classes


---

Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/jump-pilot/bugs/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/jump-pilot/admin/bugs/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] [jump-pilot:bugs] #479 OpenJUMp doen't recognize RasterImageLayer SRS on loading anymore

[Giuseppe Aruta via Jump-pilot-devel]

It has been fixed but tag has not been changed yet


---

** [bugs:#479] OpenJUMp doen't recognize RasterImageLayer SRS on loading 
anymore**

**Status:** open
**Milestone:** 
**Labels:** SRS 
**Created:** Sat Aug 18, 2018 10:08 AM UTC by Giuseppe Aruta
**Last Updated:** Sat Aug 29, 2020 08:49 AM UTC
**Owner:** Giuseppe Aruta


OpenJUMp doen't recognize RasterImageLayer SRS on loading anymore

The problem is partially connected to AddRasterImageLayerWizard and to 
ProjUtils classes


---

Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/jump-pilot/bugs/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/jump-pilot/admin/bugs/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] [jump-pilot:bugs] #480 SLD import/export problems

[Giuseppe Aruta via Jump-pilot-devel]

- **Milestone**:  --> OJ_future
- **Comment**:

Tagged ad posted. Maybe it can be fix



---

** [bugs:#480] SLD import/export problems**

**Status:** open
**Milestone:** OJ_future
**Created:** Sun Dec 02, 2018 02:47 PM UTC by Giuseppe Aruta
**Last Updated:** Sat Aug 29, 2020 08:47 AM UTC
**Owner:** nobody


it seems that sld import/export has some faults. 
- Save: vertex symbology from external image file is not saved into the xml 
file. The tag  is not recorded even if it is present into 
the layerstyle2sld.xsl file template
- Load: vertex symbologies applied as ColorThemingStyle are decoded as multiple 
BasicStyle instead. Thus is not easy to apply a styling according to an 
attribute classification
- Load. ColorThemingStyle for polygon works only if user uses base fill colors.
ColorThemingStyle for polygons with some fill patterns seems not working
-Polygon fill pattern samples are saved as temp image files like 
"ojp5731593574799380314pti.png"
On saving to SLD file the relative path of the file is saved as tag (in windows)
. When I try to load, the SLD import cannot 
recognize it and throws an error message in the log file (An ogc:filter could 
not be found while trying to parse a color theming style)

Generally QGIS and Kosmo can easely read and apply SLD files created by 
OpenJUMP if those files are related to simple fill color classification (no 
patterns, no images). 


---

Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/jump-pilot/bugs/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/jump-pilot/admin/bugs/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] [jump-pilot:bugs] #483 RasterStyleDialog freezes if the selected raster has only one value (raster used as mask)

[Giuseppe Aruta via Jump-pilot-devel]

- **status**: pending --> closed-fixed
- **Milestone**:  --> undecided



---

** [bugs:#483] RasterStyleDialog freezes if the selected raster has only one 
value (raster used as mask)**

**Status:** closed-fixed
**Milestone:** undecided
**Created:** Thu Dec 20, 2018 11:25 AM UTC by Giuseppe Aruta
**Last Updated:** Sat Aug 29, 2020 08:31 AM UTC
**Owner:** Giuseppe Aruta


RasterStyleDialog freezes if the selected raster has only one value. Raster 
layers where cells can have only one value are typically used as mask on other 
raster layer. Tecnically these raster have only cells with a defined unique 
value (generally 1) and other cells that have a nodata value. 

The problem seems connected to the metter that OpenJUMP sextante raster defines 
by defaut a stretched classification as style on a raster ( 
RasterSymbology.TYPE_RAMP). It is required at least 2 values (ex. 1 and 0) dor 
a stretched classification while mask raster layer could have only one.

The solution which I am going to apply on SVN

a) RasterLayer.class. Make a default classification (only for such mask raster) 
as single interval (RasterSymbology.TYPE_SINGLE) so that the layer tree legend 
is obliged to show only one value

b) RasterSymbologyDialog.class. Create a dummy panel that substitutes stretched 
classification panel  (only for such mask raster) and shown a message that 
selected raster has only one value


---

Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/jump-pilot/bugs/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/jump-pilot/admin/bugs/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] [jump-pilot:bugs] Re: #479 OpenJUMp doen't recognize RasterImageLayer SRS on loading anymore

[Giuseppe Aruta via Jump-pilot-devel]

AFAIR. Possibly It is already fixed.

Il sab 29 ago 2020, 10:49 michael michaud 
ha scritto:

> Do you have any tiff / tiff.aux.xml to reproduce the problem ?
> --
>
> * [bugs:#479] <https://sourceforge.net/p/jump-pilot/bugs/479/> OpenJUMp
> doen't recognize RasterImageLayer SRS on loading anymore*
>
> *Status:* open
> *Milestone:*
> *Labels:* SRS
> *Created:* Sat Aug 18, 2018 10:08 AM UTC by Giuseppe Aruta
> *Last Updated:* Sun Aug 19, 2018 04:12 PM UTC
> *Owner:* Giuseppe Aruta
>
> OpenJUMp doen't recognize RasterImageLayer SRS on loading anymore
>
> The problem is partially connected to AddRasterImageLayerWizard and to
> ProjUtils classes
> --
>
> Sent from sourceforge.net because you indicated interest in
> https://sourceforge.net/p/jump-pilot/bugs/479/
>
> To unsubscribe from further messages, please visit
> https://sourceforge.net/auth/subscriptions/
>



---

** [bugs:#479] OpenJUMp doen't recognize RasterImageLayer SRS on loading 
anymore**

**Status:** open
**Milestone:** 
**Labels:** SRS 
**Created:** Sat Aug 18, 2018 10:08 AM UTC by Giuseppe Aruta
**Last Updated:** Sat Aug 29, 2020 08:49 AM UTC
**Owner:** Giuseppe Aruta


OpenJUMp doen't recognize RasterImageLayer SRS on loading anymore

The problem is partially connected to AddRasterImageLayerWizard and to 
ProjUtils classes


---

Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/jump-pilot/bugs/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/jump-pilot/admin/bugs/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] [jump-pilot:bugs] #480 SLD import/export problems

[Giuseppe Aruta]

No. None has complained about (possibly nobody use that function)

Il sab 29 ago 2020, 10:47 michael michaud via Jump-pilot-devel <
jump-pilot-devel@lists.sourceforge.net> ha scritto:

> Peppe, do we tag that as OJ_Future ?
> --
>
> * [bugs:#480] <https://sourceforge.net/p/jump-pilot/bugs/480/> SLD
> import/export problems*
>
> *Status:* open
> *Milestone:*
> *Created:* Sun Dec 02, 2018 02:47 PM UTC by Giuseppe Aruta
> *Last Updated:* Sun Dec 02, 2018 02:47 PM UTC
> *Owner:* nobody
>
> it seems that sld import/export has some faults.
> - Save: vertex symbology from external image file is not saved into the
> xml file. The tag  is not recorded even if it is
> present into the layerstyle2sld.xsl file template
> - Load: vertex symbologies applied as ColorThemingStyle are decoded as
> multiple BasicStyle instead. Thus is not easy to apply a styling according
> to an attribute classification
> - Load. ColorThemingStyle for polygon works only if user uses base fill
> colors.
> ColorThemingStyle for polygons with some fill patterns seems not working
> -Polygon fill pattern samples are saved as temp image files like
> "ojp5731593574799380314pti.png"
> On saving to SLD file the relative path of the file is saved as tag (in
> windows)
>  xlink:href="file:/C:/Users/Urer/AppData/Local/Temp/
> jp5731593574799380314pti.png " it="" an="" parse="" not="" file="" in=""
> message="" style)<="" load,="" .="" ogc:filter="" when="" to=""
> import="" be="" cannot="" xlink:type="simple" trying="" log="" a="" (an=""
> i="" could="" theming="" try="" p="" while="" error="" sld="" found=""
> the="" throws=""> 
>
> Generally QGIS and Kosmo can easely read and apply SLD files created by
> OpenJUMP if those files are related to simple fill color classification (no
> patterns, no images).
> --
>
> Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net
> is subscribed to https://sourceforge.net/p/jump-pilot/bugs/
>
> To unsubscribe from further messages, a project admin can change settings
> at https://sourceforge.net/p/jump-pilot/admin/bugs/options. Or, if this
> is a mailing list, you can unsubscribe from the mailing list.
> ___
> 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] [jump-pilot:bugs] #483 RasterStyleDialog freezes if the selected raster has only one value (raster used as mask)

[Giuseppe Aruta]

Yes. It Is solved in my tests. No feedback from whom pointed out the bug

Il sab 29 ago 2020, 10:31 AM michael michaud via Jump-pilot-devel <
jump-pilot-devel@lists.sourceforge.net> ha scritto:

> Peppe, is thi salready fixed in 1.15?
> --
>
> * [bugs:#483] <https://sourceforge.net/p/jump-pilot/bugs/483/>
> RasterStyleDialog freezes if the selected raster has only one value (raster
> used as mask)*
>
> *Status:* pending
> *Milestone:*
> *Created:* Thu Dec 20, 2018 11:25 AM UTC by Giuseppe Aruta
> *Last Updated:* Thu Dec 20, 2018 05:25 PM UTC
> *Owner:* Giuseppe Aruta
>
> RasterStyleDialog freezes if the selected raster has only one value.
> Raster layers where cells can have only one value are typically used as
> mask on other raster layer. Tecnically these raster have only cells with a
> defined unique value (generally 1) and other cells that have a nodata
> value.
>
> The problem seems connected to the metter that OpenJUMP sextante raster
> defines by defaut a stretched classification as style on a raster (
> RasterSymbology.TYPE_RAMP). It is required at least 2 values (ex. 1 and 0)
> dor a stretched classification while mask raster layer could have only one.
>
> The solution which I am going to apply on SVN
>
> a) RasterLayer.class. Make a default classification (only for such mask
> raster) as single interval (RasterSymbology.TYPE_SINGLE) so that the layer
> tree legend is obliged to show only one value
>
> b) RasterSymbologyDialog.class. Create a dummy panel that substitutes
> stretched classification panel (only for such mask raster) and shown a
> message that selected raster has only one value
> --
>
> Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net
> is subscribed to https://sourceforge.net/p/jump-pilot/bugs/
>
> To unsubscribe from further messages, a project admin can change settings
> at https://sourceforge.net/p/jump-pilot/admin/bugs/options. Or, if this
> is a mailing list, you can unsubscribe from the mailing list.
> ___
> 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] [jump-pilot:bugs] #482 OpenJUMP Style - "Style">"Import ArcMap Style" seems hard to work

[Giuseppe Aruta]

I agree

Il sab 29 ago 2020, 10:40 AM michael michaud via Jump-pilot-devel <
jump-pilot-devel@lists.sourceforge.net> ha scritto:

> I think that such a plugin using native windows tools should be proposed
> as an external extension, not wrapped in OpenJUMP core what do you think ?
> --
>
> * [bugs:#482] <https://sourceforge.net/p/jump-pilot/bugs/482/> OpenJUMP
> Style - "Style">"Import ArcMap Style" seems hard to work*
>
> *Status:* open
> *Milestone:*
> *Created:* Mon Dec 10, 2018 09:41 AM UTC by Giuseppe Aruta
> *Last Updated:* Mon Dec 10, 2018 11:23 AM UTC
> *Owner:* Giuseppe Aruta
>
> The plugin "Style">"Import ArcMap Style" needs an extra software called
> "ArcGIS-map to SLD Converter" available only for windows, downloadable
> here: https://arcmap2sld.i3mainz.hs-mainz.de/ArcMap2SLDConverter_Eng.htm
>
> The software is downloadable with no installer while the OJ loading
> process requires the software to be installed at a specific folder: see
> method
> org.openjump.core.ui.plugin.style.ImportArcMapStylePlugIn.findArcMap2SLD(WorkbenchFrame
> wbframe, Blackboard bb).
>
> It is possible to solve it (changing tthe method to link at a specific
> folder and adding a warning that informs user to create a folder, download
> the file and put in that folder).
>
> The question is also complex as this additional software works only with
> Windows/requires a windows/Visual basic software. No support for Linux or
> OSX.
> --
>
> Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net
> is subscribed to https://sourceforge.net/p/jump-pilot/bugs/
>
> To unsubscribe from further messages, a project admin can change settings
> at https://sourceforge.net/p/jump-pilot/admin/bugs/options. Or, if this
> is a mailing list, you can unsubscribe from the mailing list.
> ___
> 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] sqlite database

[Giuseppe Aruta]

Thanks  Michael

Il sab 22 ago 2020, 22:25 Michaud Michael  ha
scritto:

> Hi,
>
> Slowdown due to FlexibleDateParser seems almost solved.
>
> I reactivated the code parsing Date
>


attributes as dates during data loading. The slowdown observed during
> saving should be moved to loading, but thanks to Ede's fix,
> FlexibleDateParser is now much more efficient (exploration to find the
> right parser is done only once).
>
> Tested with a dataset of 200 000 features
>
> 1.15 : most read/write operation last about 2s, but saving a shp from
> flexiblefeature (where dates are stored as string) lasts 2 minutes
>
> now : read and write operations take about 2s
>
> Also fixed a problem preventing read of files exported from qgis in
> spatialite format,
>
> and reported a problem with date/timestamp parsing in the sqlite driver
> (sql datatype returned for timestamp type is ok if the timestamp is stored
> as integer but it is not recognized if the timestamp is stored as
> character)
>
> Michaël
>
>
>
>
> envoyé : 21 août 2020 à 10:58
> de : edgar.sol...@web.de
> à : Michaud Michael , OpenJump develop and
> use 
> objet : Re: [JPP-Devel] sqlite database
>
>
> On 21.08.2020 10:52, Michaud Michael wrote:
>
> Sorry, I think my test base was empty or something like that
>
> hehe, yeah the feeling you get after you spend hours fixing something and
> wonder why it still does not work that you are are editing the wrong
> repo/code path, that you were dead sure was the correct one ;)
>
> I'll have more time tonight or tomorrow do re-test and give you more
> elements if
> it still not work.
>
> I'm quite confident it will work. It may just miss better error handling
> for
> "beginners" ;-)
>
> yeah, NPEs should never be exposed to the user!.. cloudy but warm
> greetings ede
>
> Michaël
>
> >> envoyé : 21 août 2020 à 10:28>> de : edgar.sol...@web.de
> >> à : jump-pilot-devel@lists.sourceforge.net
> >> objet : Re: [JPP-Devel] sqlite database
> >>
> >>
> >> Nico, maybe Mike can provide you the sqlite file he created to test
> against?.. ede
> >>
> >> On 21.08.2020 10:25, Nicolas Ribot wrote:
> >>
> >>> Hi,
> >>>
> >>> It was supposed to work.
> >>> I will have a look
> >>>
> >>> Nicolas
> >>>
> >>> On Thu, 20 Aug 2020 at 20:24, Michaud Michael <
> m.michael.mich...@orange.fr>
> >>> wrote:
> >>>
> >> >> Hi Jukka, Nicolas>>
> >> >> Do you know the state of sqlite in OpenJUMP ? I've tried to load a
> table
> >> >> from a sqlite database for a few hours without success.
> >> >>
> >> >> I tried with OJ 1.14, 1.15, last snapshot, and I tried to load from a
> >> >> database created from a shapefile with spatialite-gui or from a
> database
> >> >> created from QGis as a spatialite or as geopackage. Maybe I omitted
> >> >> something obvious, I'm not familiar with sqlite.
> >> >>
> >> >> For all my tests, I get the same error after I have choosen the
> table and
> >> >> clicked on finish. The error seems related to geometry retrieval or
> index
> >> >> retrieval :
> >> >>
> >> >> java.lang.NullPointerException
> >> >> at
> >> >>
> >>
> com.vividsolutions.jump.datastore.spatialite.SpatialiteSQLBuilder.buildSpatialIndexFilter(SpatialiteSQLBuilder.java:157)
> >> >> at
> >> >>
> >>
> com.vividsolutions.jump.datastore.spatialite.SpatialiteSQLBuilder.buildBoxFilter(SpatialiteSQLBuilder.java:116)
> >> >> at
> >> >>
> >>
> com.vividsolutions.jump.datastore.spatialite.SpatialiteSQLBuilder.getSQL(SpatialiteSQLBuilder.java:39)
> >> >>
> >> >> Thanks for the help,
> >> >>
> >> >> Michaël
> >> >> ___
> >> >> 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
>
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] OpenJUMP migration documentation

[Giuseppe Aruta]

Thanks Eric, next week I will take sometime to study the repository and all
the page you sent.
Some questions, proposals.

A) Regarding plugins,
Do you think that grouping together  plugins iwith similar technical
aspects into one source could help to simplify/speed the transition to Git?
For instance, I am considering to group together CAD toolbox, Advanced
Measure and Color chooser plugins. Of coarse thus should be done before
porting everything to Git.

B) WFS could be shipped as external plug-in. Anyhow.

C) good news from Sextante GIS planet.
https://joinup.ec.europa.eu/svn/sextante/ has also source code from
Sextante vers. 1.0 which seems to be the one we shipped. I recompiled it
with JTS 1.7 and used a OJ core adapted with JTS 1.7 to test various raster
plugins with success.
I am considering to open a repository on Git to store the Sextante lib
source and OJ binding.

Peppe



Il ven 21 ago 2020, 12:37 Eric  ha scritto:

> Hi,
>
> On 20/08/2020 19:22, edgar.sol...@web.de wrote:
> > On 20.08.2020 19:08, Michaud Michael wrote:
> >> Hi,
> >>
> >> Big thanks for this work Eric, seems to be very well documented.
> > yup, impressively well documented!
>
> Thanks. No problem.
>
> >> I think we should take advantage of this work and proceed to a more
> definitive
> >> migration without waiting too much.
> > true. but we should still put out a final "stable" because it'll
> probably take some time to adapt all those missing extensions.
>
>  From a technical point of view, the migration process is still going to
> work in a couple of months.
>
> As written in my previous message, this article highlights what needs to
> be done before the final migration:
> https://docs.microsoft.com/en-us/azure/devops/learn/git/centralized-to-git
>
> It is often advised to avoid adding binary files. I wrote a bit about
> that in the OpenJUMP context:
>
> https://github.com/openjump-gis/openjump-migration-doc/blob/master/MIGRATION.md#2-convert-the-subversion-repository
>
> The migration of the OpenJUMP core repository has been relatively easy but:
> - the WFS functionalities have been lost along the way. What to do?,
> - some decisions need to be taken about the way(s) to migrate all the
> plug-ins (individual repositories? a couple of global ones -- core,
> plus, experimental, etc. --? a global one?). Their SVN structures
> differ, so it isn't going to be necessarily easy to deal with that,
> - would it be easier to create the plug-in manager before the migration?
> Could it help answering the last questions?,
> - there are all the questions about the different builds, especially for
> those which are related to the plug-ins,
> - is there a better way to link SVN authors with Git authors, rather
> than using the SourceForge user addresses? (historical commits would
> thus refer to current Git accounts)
> - etc.
>
> After migration, the current size of the OpenJUMP core as a Git
> repository is around 540MB.
>
> The 'docs' folder size alone is 70MB without the revision history, and
> 108MB if considered. By externalising it into another Git repository
> (the revision history would be kept as well), this would reduce the
> global size of the main core repository by already 20%. Some other
> folders could be considered. In the long term, this would probably make
> the global project easier to manage.
>
> I just did a quick test to create a private repository for the 'docs'
> folder. See (you need to be logged in to access it):
> https://github.com/openjump-gis/doc-test
> I used a tool directly provided by GitHub to automate the migration
> (https://github.com/new/import). It is quite handy but it is relatively
> difficult to create a proper mapping between the SVN and the Git
> users/authors.
>
> So what I would suggest is to create some wiki pages in the newly
> created openjump-migration-doc repository
> (https://github.com/openjump-gis/openjump-migration-doc) to write and
> discuss about the different options. A wiki is an easy way of
> communication, or issues could be created as well. Once
> discussed/closed, I could add some proper documentation to crystallise
> what has been decided.
>
> This suggestion, even if first perceived as time consuming, could allow
> us to migrate most the OJ repositories/components, if not all, in an
> easier way, and to save some a lot of time in the future. This would
> also allow, if needed, to restructure some parts of the project now
> (probably not the code itself, such as the tests, etc., but such as
> previously described based on the 'docs' folder) rather than later,
> especially if one goal is to reduce the global size of the repository.
>
> Once again, these are just suggestions, open to discussion.
>
> Eric
>
> >> What about listing the tickets or tasks we want to fix before migration
> (if
> >> possible something we can achieve within a few weeks). Then we could
> make a new
> >> release and concentrate on the migration.
> > agreed. we should at least prioritize. let me try to set 

Re: [JPP-Devel] batik upgraded

[Giuseppe Aruta]

It is fine, Ede, thanks.
SVG export works either with embedded Export view to SVG or with CadPlan
print plugin.
Everything works if I don't change the output scale  (Export view to SVG,
scale 1:... for instance, or, using the zoom tols and then export to svg).
In these case RasterImageLayer is not export in the proper dimension or it
disappear.

I did a test using using a plugin that use JFreeSVG instead of Batik lib to
export to SVG and had the same problems os scaling Sextante rasters.

To resume: everything works as OJ 1.15 ;-)
Peppe

Il giorno dom 16 ago 2020 alle ore 18:50  ha scritto:

> done in r6375. to batik 1.6.1 instead of 1.6 though. would you mind
> doublechecking that it works as expected again? ..ede
>
> On 16.08.2020 16:01, Giuseppe Aruta wrote:
> > I suggest to move back to Batik 1.6 and to keep the option to move either
> > to smaller SVG lib or a newer Batik for OpenJUMP JTS+15
> >
> > Il giorno dom 16 ago 2020 alle ore 14:47 Michaud Michael <
> > m.michael.mich...@orange.fr> ha scritto:
> >
> >> Hi,
> >>
> >> It would be nice to know exactly what is wrong with batik1.13.
> Sometimes,
> >> third party libraries just become more strict,
> >>
> >> and in that case, it can be useful to fix the code on OpenJUMP side
> >> whatever the final solution choosen.
> >>
> >> Michaël
> >>
> >> envoyé : 16 août 2020 à 14:31
> >> de : edgar.sol...@web.de
> >> à : OpenJump develop and use ,
> >> Giuseppe Aruta 
> >> objet : Re: [JPP-Devel] batik upgraded
> >>
> >>
> >> On 16.08.2020 13:07, Giuseppe Aruta wrote:
> >>
> >> Hi all,
> >> this issue was not closed: moving to newer batik broke SVG export for
> both
> >> embedded OpeJUMP "Export view" and CadPlan Printer view plugin.
> >>
> >> yeah, didn't hear back from you guys. so we are agreed thta i'll roll
> back
> >> the upgrade to the latest working batik 1.6 .
> >>
> >> also Peppe is totally right, batik is a big (in terms of space)
> dependency
> >> for a very small feat (svg export). we should probably change that.
> >>
> >> ..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] batik upgraded

[Giuseppe Aruta]

I suggest to move back to Batik 1.6 and to keep the option to move either
to smaller SVG lib or a newer Batik for OpenJUMP JTS+15

Il giorno dom 16 ago 2020 alle ore 14:47 Michaud Michael <
m.michael.mich...@orange.fr> ha scritto:

> Hi,
>
> It would be nice to know exactly what is wrong with batik1.13. Sometimes,
> third party libraries just become more strict,
>
> and in that case, it can be useful to fix the code on OpenJUMP side
> whatever the final solution choosen.
>
> Michaël
>
> envoyé : 16 août 2020 à 14:31
> de : edgar.sol...@web.de
> à : OpenJump develop and use ,
> Giuseppe Aruta 
> objet : Re: [JPP-Devel] batik upgraded
>
>
> On 16.08.2020 13:07, Giuseppe Aruta wrote:
>
> Hi all,
> this issue was not closed: moving to newer batik broke SVG export for both
> embedded OpeJUMP "Export view" and CadPlan Printer view plugin.
>
> yeah, didn't hear back from you guys. so we are agreed thta i'll roll back
> the upgrade to the latest working batik 1.6 .
>
> also Peppe is totally right, batik is a big (in terms of space) dependency
> for a very small feat (svg export). we should probably change that.
>
> ..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] batik upgraded

[Giuseppe Aruta]

Hi all,
this issue was not closed: moving to newer batik broke SVG export for both
embedded OpeJUMP "Export view" and CadPlan Printer view plugin.
I was thinking that 16 jar files and 2.6 Mb (Apache NBatiks)  was a large
amount if we consider that these libraries are only used for 3 plugins.
I found this page http://www.object-refinery.com/blog/blog-20140423.html
where  Batik lib vs JFreeSVG libraries are compared. And I realize that:
a) we possibly don't need all Batik classes. According to the page only
these file are needed:

   - batik-dom.jar (173,750 bytes);
   - batik-svggen.jar (215,802 bytes);
   - batik-awt-util.jar (403,287 bytes);
   - batik-util.jar (128,334 bytes);
   - batik-ext.jar (10,261 bytes);
   - batik-xml.jar (30,862 bytes)

For around 1 Mb

b) Is there a way to migrate to JFreeSVG? I realize that we use Apache
Batik only to export to SVG
Batik classes are involved in these classes:

-Export objects to SVG

   - SaveImageAsPlugIn
   - SaveVImageAsSVGPlugIn  ha scritto:

> hey All,
>
> had to touch batik, as it was missing some classes in trunk/lib/batik.jar
> after Peppe added AdditionalResultsIO. maven already had the proper batik
> components defined that's why the snapshot builds went fine.
>
> while at it i noticed that we were using a quite old batik version and
> upgraded it. looks good to me but please test and come back if something
> breaks horribly.
>
> sunshine all over.. (sweating) ede
>
>  Forwarded Message 
> Subject: [JPP-Devel] SVN: [6369] core/trunk
> Date: Wed, 05 Aug 2020 12:50:50 +
> From: jump-pilot-svn--- via Jump-pilot-devel <
> jump-pilot-devel@lists.sourceforge.net>
> Reply-To: OpenJump develop and use  >
> To: jump-pilot-devel@lists.sourceforge.net
> CC: jump-pilot-...@lists.sourceforge.net
>
> Revision: 6369
>   http://sourceforge.net/p/jump-pilot/code/6369
> Author:   edso
> Date: 2020-08-05 12:50:49 + (Wed, 05 Aug 2020)
> Log Message:
> ---
> upgrade batik to latest greatest v1.13
> minimal fixup of AdditonalResultsIO
> fingers crossed, let's see if it breaks something more
>
> Modified Paths:
> --
> core/trunk/pom.xml
>
> core/trunk/src/org/openjump/sextante/gui/additionalResults/AdditionalResultsIO.java
>
> Added Paths:
> ---
> core/trunk/lib/batik-all-1.13.jar
>
> Removed Paths:
> -
> core/trunk/lib/batik-all.jar
>
> Added: core/trunk/lib/batik-all-1.13.jar
> ===
> (Binary files differ)
>
> Index: core/trunk/lib/batik-all-1.13.jar
> ===
> --- core/trunk/lib/batik-all-1.13.jar   2020-08-05 12:45:12 UTC (rev 6368)
> +++ core/trunk/lib/batik-all-1.13.jar   2020-08-05 12:50:49 UTC (rev 6369)
>
> Property changes on: core/trunk/lib/batik-all-1.13.jar
> ___
> Added: svn:mime-type
> ## -0,0 +1 ##
> +application/octet-stream
> \ No newline at end of property
> Deleted: core/trunk/lib/batik-all.jar
> ===
> (Binary files differ)
>
> Modified: core/trunk/pom.xml
> ===
> --- core/trunk/pom.xml  2020-08-05 12:45:12 UTC (rev 6368)
> +++ core/trunk/pom.xml  2020-08-05 12:50:49 UTC (rev 6369)
> @@ -924,25 +924,25 @@
>  
>  batik
>  batik-awt-util
> -1.6
> +1.13
>  compile
>  
>  
>  batik
>  batik-dom
> -1.6
> +1.13
>  compile
>  
>  
>  batik
>  batik-svggen
> -1.6
> +1.13
>  compile
>  
>  
>  batik
>  batik-squiggle
> -1.6
> +1.13
>  compile
>  
>  
>
> Modified:
> core/trunk/src/org/openjump/sextante/gui/additionalResults/AdditionalResultsIO.java
> ===
> ---
> core/trunk/src/org/openjump/sextante/gui/additionalResults/AdditionalResultsIO.java
> 2020-08-05 12:45:12 UTC (rev 6368)
> +++
> core/trunk/src/org/openjump/sextante/gui/additionalResults/AdditionalResultsIO.java
> 2020-08-05 12:50:49 UTC (rev 6369)
> @@ -27,7 +27,7 @@
>  import javax.swing.tree.TreePath;
>  import javax.xml.namespace.QName;
>
> -import org.apache.batik.dom.svg.SVGDOMImplementation;
> +import org.apache.batik.anim.dom.SVGDOMImplementation;
>  import org.apache.batik.svggen.SVGGraphics2D;
>  import org.apache.log4j.Logger;
>  import org.math.plot.PlotPanel;
> @@ -37,7 +37,7 @@
>  import org.openjump.core.ui.util.LayerableUtil;
>  import org.openjump.sextante.core.ObjectAndDescription;
>  import org.w3c.dom.DOMImplementation;
> -import org.w3c.dom.svg.SVGDocument;
> +import org.w3c.dom.Document;
>
>  import 

[JPP-Devel] [jump-pilot:bugs] #496 OpenJUMP 1.15 freezes on loading project files from differing versions

[Giuseppe Aruta via Jump-pilot-devel]

Hi Michael, can you send me the files you used as first test? I will try on my 
side


---

** [bugs:#496] OpenJUMP 1.15 freezes on loading project files from differing 
versions**

**Status:** open
**Created:** Tue Aug 11, 2020 10:35 AM UTC by ede
**Last Updated:** Fri Aug 14, 2020 12:19 PM UTC
**Owner:** nobody


as described by Peppe on the mailing list
"
*On loading project files saved with different versions of OpenJUMP*.
There is a break after OpenJUMP 1.5 and before OpenJUMP 6363 on
saving/loading project files.
   a) OpenJUMP 1.5 freezes on loading project files saved at least with
OpenJUMP 6363 and 6370
  The console (I use Linux) doesn't show any warning.
   b) OpenJUMP 6363 and 6370  cannot load project files saved at least with
OpenJUMP 1.5 .
The console doesn't show any warning.
  c) OpenJUMP 6363 can load project files saved with OpenJUMP 6370 and vice
versa
"


---

Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/jump-pilot/bugs/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/jump-pilot/admin/bugs/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] OJ 2.x Was:Re: JTS update: first experiments

[Giuseppe Aruta]

openjump-gis ok for me too

2020-08-14 12:03 GMT+02:00, edgar.sol...@web.de :
> oj-devs
> oj-developers
> oj-team
> or jump instead of oj
>
> so many possibilieits ..ede:))
>
> On 14.08.2020 11:53, Giuseppe Aruta wrote:
>> jump-pilot
>> or
>> openjump-pilot
>> or
>> openjump2
>>
>> 2020-08-14 11:50 GMT+02:00, Eric :
>>> Hi,
>>>
>>> The GitHub support team answered me this morning, stating that the
>>> ownership transfer of the 'openjump' username or organisation is not
>>> possible at the moment:
>>>
>>>> While I'd love to help, I'm afraid we won't be able to release that
>>>> username for you today as it's not dormant (not all activity on GitHub
>>>> is public) or available for release under our name-squatting policy
>>>> (https://docs.github.com/en/github/site-policy/github-username-policy).
>>>> Sorry I don't have better news to share with you on this.
>>>>
>>>> Though it may not apply here, it's worth mentioning that we have a
>>>> trademark policy that could allow you to obtain a username that's
>>>> already been claimed. If the username you're interested in is a
>>>> trademark you hold, I'd recommend taking a look at that policy for
>>>> more information about potentially filing a violation report:
>>>>
>>>> https://docs.github.com/github/site-policy/github-trademark-policy
>>>
>>> I just created an organisation named 'openjump-gis' for the time being
>>> (hyphens are allowed), according to the title of the openjump.org index
>>> page and as it gives an idea of what the project is about. The following
>>> options are also available at the moment:
>>> - open-jump,
>>> - openjumpgis
>>> - openjump-project / openjumpproject
>>> - oj-gis / ojgis
>>> - jump-pilot / jumppilot
>>> - openjump-pilot / openjumppilot
>>> - geopenjump
>>>
>>> Note that openjump is available on GitLab for the moment, if you wish to
>>> create a mirror repository there.
>>>
>>> It's always possible to rename an organisation later on (see
>>> https://docs.github.com/en/github/setting-up-and-managing-organizations-and-teams/renaming-an-organization).
>>> This process automatically updates everything from link redirection to
>>> commit attribution.
>>>
>>> I already added Ede (edeso) and Michaël (mukoki) as owners of this
>>> organisation.
>>>
>>> I also just created an 'openjump-migration' repository as previously
>>> discussed and I am now tuning the settings of both the organisation and
>>> the repository.
>>>
>>> Feel free to modify the content / info / settings about these.
>>>
>>> I should be able to push a first working version for next Monday, maybe
>>> before but as schools reopened on Wednesday here in Scotland (children
>>> don't attend it on a daily basis during this first week), I can't
>>> promise anything.
>>>
>>> Eric
>>>
>>> On 12/08/2020 13:38, edgar.sol...@web.de wrote:
>>>> no worries. i'm pretty sure we are not fixed on that name. for years we
>>>> have been known as /jump-pilot/ (anybody know why?) and it worked as
>>>> well.
>>>> how about you work with a private repo in the mean time and we'll deal
>>>> with name and organisation when we are ready to branch which is not
>>>> going
>>>> to be tomorrow ;)
>>>>
>>>> ..ede
>>>>
>>>> On 12.08.2020 13:19, Eric wrote:
>>>>> Hi all,
>>>>>
>>>>> Thanks to all of you.
>>>>>
>>>>> According to your answers, I'm in the process of creating a GitHub
>>>>> organisation named 'openjump', containing a public repository named
>>>>> 'openjump-migration'. The current problem is that someone created an
>>>>> account or an organisation with this name last April
>>>>> (https://github.com/openjump), but with no activity since then. I just
>>>>> contacted the GitHub support team to see if it was possible to have a
>>>>> transfer of ownership for this name -- so, of course, with the
>>>>> agreement
>>>>> of the current owner), as it isn't allowed to directly contact the
>>>>> owner
>>>>> for obvious reasons.
>>>>>
>>>>> Apart from that, everything is ready.
>>>>>
>>>>> 

Re: [JPP-Devel] OJ 2.x Was:Re: JTS update: first experiments

[Giuseppe Aruta]

jump-pilot
or
openjump-pilot
or
openjump2

2020-08-14 11:50 GMT+02:00, Eric :
> Hi,
>
> The GitHub support team answered me this morning, stating that the
> ownership transfer of the 'openjump' username or organisation is not
> possible at the moment:
>
>> While I'd love to help, I'm afraid we won't be able to release that
>> username for you today as it's not dormant (not all activity on GitHub
>> is public) or available for release under our name-squatting policy
>> (https://docs.github.com/en/github/site-policy/github-username-policy).
>> Sorry I don't have better news to share with you on this.
>>
>> Though it may not apply here, it's worth mentioning that we have a
>> trademark policy that could allow you to obtain a username that's
>> already been claimed. If the username you're interested in is a
>> trademark you hold, I'd recommend taking a look at that policy for
>> more information about potentially filing a violation report:
>>
>> https://docs.github.com/github/site-policy/github-trademark-policy
>
> I just created an organisation named 'openjump-gis' for the time being
> (hyphens are allowed), according to the title of the openjump.org index
> page and as it gives an idea of what the project is about. The following
> options are also available at the moment:
> - open-jump,
> - openjumpgis
> - openjump-project / openjumpproject
> - oj-gis / ojgis
> - jump-pilot / jumppilot
> - openjump-pilot / openjumppilot
> - geopenjump
>
> Note that openjump is available on GitLab for the moment, if you wish to
> create a mirror repository there.
>
> It's always possible to rename an organisation later on (see
> https://docs.github.com/en/github/setting-up-and-managing-organizations-and-teams/renaming-an-organization).
> This process automatically updates everything from link redirection to
> commit attribution.
>
> I already added Ede (edeso) and Michaël (mukoki) as owners of this
> organisation.
>
> I also just created an 'openjump-migration' repository as previously
> discussed and I am now tuning the settings of both the organisation and
> the repository.
>
> Feel free to modify the content / info / settings about these.
>
> I should be able to push a first working version for next Monday, maybe
> before but as schools reopened on Wednesday here in Scotland (children
> don't attend it on a daily basis during this first week), I can't
> promise anything.
>
> Eric
>
> On 12/08/2020 13:38, edgar.sol...@web.de wrote:
>> no worries. i'm pretty sure we are not fixed on that name. for years we
>> have been known as /jump-pilot/ (anybody know why?) and it worked as well.
>> how about you work with a private repo in the mean time and we'll deal
>> with name and organisation when we are ready to branch which is not going
>> to be tomorrow ;)
>>
>> ..ede
>>
>> On 12.08.2020 13:19, Eric wrote:
>>> Hi all,
>>>
>>> Thanks to all of you.
>>>
>>> According to your answers, I'm in the process of creating a GitHub
>>> organisation named 'openjump', containing a public repository named
>>> 'openjump-migration'. The current problem is that someone created an
>>> account or an organisation with this name last April
>>> (https://github.com/openjump), but with no activity since then. I just
>>> contacted the GitHub support team to see if it was possible to have a
>>> transfer of ownership for this name -- so, of course, with the agreement
>>> of the current owner), as it isn't allowed to directly contact the owner
>>> for obvious reasons.
>>>
>>> Apart from that, everything is ready.
>>>
>>> Eric
>>>
>>> On 12/08/2020 10:06, edgar.sol...@web.de wrote:
 yup indenting is clearly broken in this reply, maybe better not reply
 inline with that client Mike ;).. ede

 On 12.08.2020 09:17, Michaud Michael wrote:
> Hi,
>
>    >>> On 07.08.2020 20:55, Eric wrote:
>     Then I checked which OJ lib dependencies rely on JTS and it
> seems that
> there is only deegree 2,
>     without considering here the plethora of extensions/plugins.
>    >>> which is the main obstacle. the only clean solution i see is to
> branch out
> a new OJ 2.x that initially will break compatibility to all external
> plugins.
> that's the bad news.
>    >>> the good news is that this forces us to retouch pretty much all
> of them and
> during this effort we might eventually come up with a working plugin
> manager
> after all.
>    >> Less than a day of work should be required (if not less) to
> update all the
> plugins which do not rely on a dependency which relies itself on JTS.
> I'm going
> to test it, to see if it's the case.
>    >> I tried with my plugins and I just needed a couple of seconds to
> do it.
>
> again. we don't have sources for all extensions in OJ Plus at hand or
> setup to
> build at all. the challenge won't be the modding but the finding and
> setting up
> plugin repos.
>
> I wasn't aware of 

Re: [JPP-Devel] [jump-pilot:bugs] #496 OpenJUMP 1.15 freezes on loading project files from differing versions

[Giuseppe Aruta]

Hi MIchael,
all the file I used, including jml files, are located here:
https://sourceforge.net/projects/opensit/files/Test%20file/Export%20to%20SVG/
Peppe

Il giorno mer 12 ago 2020 alle ore 19:59 michael michaud via
Jump-pilot-devel  ha scritto:

> I could open a project saved with 1.15 with r6370 and viceversa. My
> project contained a few vectors, and a geotif imported as an image and
> imported a second time as a sextante image.
> On the other hand, I get some problems if csv data is included in the
> project due to a breaking change I did. Not sure I can fix the bug about
> saving a csv in the project without breaking, but I'll have a deaper look.
> Before, I'd like to have more precision about your or Peppe test. What kind
> of datasources did they include ? csv/wkt ? Could you share the jmp files ?
> --
>
> * [bugs:#496]  OpenJUMP
> 1.15 freezes on loading project files from differing versions*
>
> *Status:* open
> *Created:* Tue Aug 11, 2020 10:35 AM UTC by ede
> *Last Updated:* Tue Aug 11, 2020 10:35 AM UTC
> *Owner:* nobody
>
> as described by Peppe on the mailing list
> "
> *On loading project files saved with different versions of OpenJUMP*.
> There is a break after OpenJUMP 1.5 and before OpenJUMP 6363 on
> saving/loading project files.
> a) OpenJUMP 1.5 freezes on loading project files saved at least with
> OpenJUMP 6363 and 6370
> The console (I use Linux) doesn't show any warning.
> b) OpenJUMP 6363 and 6370 cannot load project files saved at least with
> OpenJUMP 1.5 .
> The console doesn't show any warning.
> c) OpenJUMP 6363 can load project files saved with OpenJUMP 6370 and vice
> versa
> "
> --
>
> Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net
> is subscribed to https://sourceforge.net/p/jump-pilot/bugs/
>
> To unsubscribe from further messages, a project admin can change settings
> at https://sourceforge.net/p/jump-pilot/admin/bugs/options. Or, if this
> is a mailing list, you can unsubscribe from the mailing list.
> ___
> 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] OJ 2.x Was:Re: JTS update: first experiments

[Giuseppe Aruta]

*>So for OpenJUMP I would suggest:- openjump for the organisation / group,-
openjump for the main code,- openjump-test for the temporary project we are
talking about here, toavoid any confusion.*

Since Sextante java libraries have the potentiality to be extended to many
other gis projects (the original list was quite large: geotools, Openjump,
GvSig, Kosmo only to talk about gis which share the same Sextante libraries
with no modifications)
- in case we fork Sextante libraries in order to work with newer JTS
- in case that GvSig CE folks won't/cannot take care if the project
- in case that everyone of us agree

I will suggest to add to the former list also
- Sextante-test (or Sextante) to leave the door open to any other external
contributions. I know at least a couple of developer  in Italy who have
interest in raster analysis in java but are not focused specifically on
Openjump. They may be interested to partecipate to the project.
One is Alberto Bertazza who contributed on  raster framework in Openjump
and he is the developer of OpenKlem hydrologic raster analysis toolbox
plugin, Integrated in Openjump plus.
Kindly regards
Peppe

Il mer 12 ago 2020, 09:17 Michaud Michael  ha
scritto:

> Hi,
>
> >>> On 07.08.2020 20:55, Eric wrote:
>  Then I checked which OJ lib dependencies rely on JTS and it seems
> that there is only deegree 2,
>  without considering here the plethora of extensions/plugins.
> >>> which is the main obstacle. the only clean solution i see is to branch
> out a new OJ 2.x that initially will break compatibility to all external
> plugins. that's the bad news.
> >>> the good news is that this forces us to retouch pretty much all of
> them and during this effort we might eventually come up with a working
> plugin manager after all.
> >> Less than a day of work should be required (if not less) to update all
> the plugins which do not rely on a dependency which relies itself on JTS.
> I'm going to test it, to see if it's the case.
> >> I tried with my plugins and I just needed a couple of seconds to do it.
>
> again. we don't have sources for all extensions in OJ Plus at hand or
> setup to build at all. the challenge won't be the modding but the finding
> and setting up plugin repos.
>
> I wasn't aware of this situation. All of a sudden, it seems to be
> another challenge to migrate all the plugins...
>
> Could we decide to norrow openjump-plus to extensions hosted by the
> project only, and revide the idea of a plugin manager (could be a student
> project ?).
>
>
> there is a critical bug opening JMP project files which should be fixed
> before we branch
> https://sourceforge.net/p/jump-pilot/bugs/496/
>
> The idea here is to test the migration based on the OJ 1.15 release, to
> know if it works and to see what could be improved during the final
> migration. Nothing definitive.
>
> We'll try to fix this bug before the definitive migration.
>
> Any format preference for this document? MD (Markdown) or RST
> (reStructuredText)? Both are easily and directly readable from GitHub /
> GitLab. I would probably suggest Markdown as it's slightly more common
> and because we don't need the specificities of RST at this stage.
>
> I also suggest markdown for the same reasons
>
>
> >> - (Bonus) Upgrading the Log4j dependency to v2 and therefore removing
> the current security issue in link with it.
>
> the reason that this was not done before is that some extensions were
> compiled against it. as we are doing a clean break anyway i am not opposed
> anymore. note: we have our "own" com.vividsolutions.jump.workbench.Logger
> which is supposed to be the one stop solution for extension but internally
> uses Log4J again.
>
> What I could do is, once JTS and the OJ code have been updated on the
> master branch, to create another branch (based on the latter) to test a
> Log4j update. What do you think?
>
> It is good for me,
>
> >> Open discussion:
> >> - Preliminary remark: I don't want at any point of this process, acting
> as if I was taking this project under my umbrella/name. As I wrote to
> Michaël, you're the drivers/guardians of this project, I'm just a
> passenger. Therefore, just let me know what you prefer, the way you want to
> do things, and I'll act accordingly. Thanks,
>
> thanks for contributing your time and effort!
>
> It's the least I can do after having used OJ for years.
>
> I this migration to github and jts 1.17 succeeds, it will be a major
> step in the evolution of the project, thanks for your effort,
>
> >> - Would you prefer an open or a private repository? Why do I consider
> the private option here? To avoid any confusion with the current OpenJUMP
> repository on sourceforge and to avoid some possible premature forks,
>
> we can easily add notes in the Readme pointing out the provisional status
> of the OJ2 development. anyone wanting to fork still i have no objections.
> after all it's not called open source for nothing ;)
>
> I'm waiting some other answers (from Peppe, 

Re: [JPP-Devel] OJ 2.x Was:Re: JTS update: first experiments

[Giuseppe Aruta]

Hi Eric

Open discussion:

*>>- The idea is to create a temporary Git project/repository as Ede
mentioned too. There are two main platforms for that, GitHub and GitLab.
Let me know which one you prefer, knowing that it is possible to have both
solutions, working only on one, with a mirroring for the other using this
solution (this includes automated
push/pull): 
https://docs.gitlab.com/ee/user/project/repository/repository_mirroring.html
*

No preference for me. As I can see GitLab offers a free Continuous
Integration which could be useful in a project like Openjump where Night
builds are very frequent and, sometime,  preferred by users more than the
stable realize.

*>>Would you prefer an open or a private repository? Why do I consider the
private option here? To avoid any confusion with the current OpenJUMP
repository on sourceforge and to avoid some possible premature forks,*

I am not afraid if forks: it is a part of the surviving life of Jump. Right
now Openjump is the only (as far as I know) survivor of Jump family. Anyhow
I agree to a private repository only for the time of migration. And to make
it public when we are sure that everything is working.

- >>*Where do I need to create this project? In my personal account, or an
OpenJUMP organisation is created, and the project takes place there (I
would personally prefer this option, in link with my preliminary remark)?
If an OpenJUMP organisation is created, do you want to create it yourself
or is it OK if I create it?*

Openjump organization seems in continuity with the "philosophy" of the
project.

- >>*Have you already got some GitHub/GitLab accounts that I could use to
let you access the project as administrators?*

Not yet. I will open one in these days

Peppe


Il mar 11 ago 2020, 23:59 Eric  ha scritto:

> Hi Ede,
>
> Thanks. I let the licencing issue aside as it seems to be resolved. See
> my inline answers.
>
> On 11/08/2020 12:01, edgar.sol...@web.de wrote:
> > tl;dr let's wait how the licensing issue (other email) turns out, apart
> from that my answers below.
> >
> > On 10.08.2020 15:42, Eric wrote:
> >> Hi Ede,
> >>
> >> Thanks for your welcome and for your answers. See my inline replies for
> some of them (I deleted the other parts).
> >>
> >> On 09/08/2020 16:40, edgar.sol...@web.de wrote:
> >>> hey Eric,
> >>>
> >>> welcome to the team! see my answers below
> >>>
> >>> On 07.08.2020 20:55, Eric wrote:
>  Then I checked which OJ lib dependencies rely on JTS and it seems
> that there is only deegree 2,
>  without considering here the plethora of extensions/plugins.
> >>> which is the main obstacle. the only clean solution i see is to branch
> out a new OJ 2.x that initially will break compatibility to all external
> plugins. that's the bad news.
> >>> the good news is that this forces us to retouch pretty much all of
> them and during this effort we might eventually come up with a working
> plugin manager after all.
> >> Less than a day of work should be required (if not less) to update all
> the plugins which do not rely on a dependency which relies itself on JTS.
> I'm going to test it, to see if it's the case.
> >> I tried with my plugins and I just needed a couple of seconds to do it.
> > again. we don't have sources for all extensions in OJ Plus at hand or
> setup to build at all. the challenge won't be the modding but the finding
> and setting up plugin repos.
>
> I wasn't aware of this situation. All of a sudden, it seems to be
> another challenge to migrate all the plugins...
>
>  This is quite a good news because
>  if the deegree dependency is updated to its latest version (3.x.x),
> which relies on JTS 1.15,
>  then, theoretically, only the import statements and a few other
> com.vividsolutions directly used in the code
>  need to be modified.
> >>> yeah, probably not. deegree2 is afaics used primarily or exclusively
> for the WFS extension and i remember checking out deegree3 as a drop in for
> deegree2 but failing miserably. that's why i stuck with deegree2 happy to
> have at least a working WFS extension for the time being.
> >>>
> >>> but again, we can remove WFS from core for OJ 2.x and come up with a
> working extension later (if at all).
> >> It seems to be a good compromise for the time being as the migration
> from deegree-core 2 to deegree-core 3 isn't straightforward.
> > agreed
>
> So I'll do that.
>
>  - the GeoJSON part (com.vividsolutions.jump.io.geojson) is
> problematic due to the jts-io
>  pom type only, but once imported, this part of the code will be
> functional again,
> >>> how do you figure? com.vividsolutions.jump.io.geojson was written by
> myself from scratch utilizing google's json-simple . it holds no dependency
> apart from the jts geometry code. maybe myself placing it in this package
> has mislead you
> >> Have a look at the GeoJsonReader class for example, and the method
> 

[JPP-Devel] [jump-pilot:bugs] #496 OpenJUMP 1.15 freezes on loading project files from differing versions

[Giuseppe Aruta]

Thanks Ede, you were faster ;-)

> [bugs:#496] OpenJUMP 1.15 freezes on loading project files from differing 
> versions Status: open Created: Tue Aug 11, 2020 10:35 AM UTC by ede Last 
> Updated: Tue Aug 11, 2020 10:35 AM UTC Owner: nobody as described by Peppe on 
> the mailing list " On loading project files saved with different versions of 
> OpenJUMP. There is a break after OpenJUMP 1.5 and before OpenJUMP 6363 on 
> saving/loading project files. a) OpenJUMP 1.5 freezes on loading project 
> files saved at least with OpenJUMP 6363 and 6370 The console (I use Linux) 
> doesn't show any warning. b) OpenJUMP 6363 and 6370 cannot load project files 
> saved at least with OpenJUMP 1.5 . The console doesn't show any warning. c) 
> OpenJUMP 6363 can load project files saved with OpenJUMP 6370 and vice versa 
> " Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net is 
> subscribed to https://sourceforge.net/p/jump-pilot/bugs/ To unsubscribe from 
> further messages, a project admin can change settings at 
> https://sourceforge.net/p/jump-pilot/admin/bugs/options. Or, if this is a 
> mailing list, you can unsubscribe from the mailing list. 
> ___ 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] OJ 2.x Was:Re: JTS update: first experiments

[Giuseppe Aruta]

Hi Eric

- This is the link to GvSIG CE SVN of Sextante:
https://svn.code.sf.net/p/gvsigce/code/trunk/sextante

- Regarding OJ binding we use. You will find the source code in  OpenJUMP
Plugin SVN.
It has been modified during these years in order to a better integration
wof both Software (OpnJUMP and Sextante)
 a quick list of main changes:

   - better recognize of nodata values
   - activation of modeler, and other sextante tool
   - integration of output results interface to OpenJUMP in order to have
   all output not vector or raster (diagrams, tables, html, etc)
   - from OpenJUMP e from Sextante into an unique space (see classes in
   org.openjump.sextante.gui.additionalResults from OJ SVN)


- As far as I remember the version of Sextante we ship is "1.0". Actual
GvSIG version is named "1.0.0"

Best regards

Peppe

Il giorno lun 10 ago 2020 alle ore 22:16 Eric 
ha scritto:

> I also found the sources for the 0.6 version here, directly exported from
> code.google.com/p/sextante: https://github.com/danieldupre/sextante
> The OpenJUMP bindings are included.
>
> Víctor Olaya could also be contacted to help if needed:
> https://github.com/volaya
>
> Finally, I found a version 1.0 of Sextante in the 52°North project but
> only the compiled code is accessible (in their own Maven repository). It
> seems to be a Maven refactoring based on the 0.6 version:
> https://github.com/52North/WPS/tree/dev/52n-wps-sextante
>
> Eric
>
> On 10/08/2020 20:44, Eric wrote:
>
> Thanks.
>
> Is it different from this repository:
> - https://joinup.ec.europa.eu/svn/sextante/soft/sextante_lib/
> - (OpenJUMP bindings)
> https://joinup.ec.europa.eu/svn/sextante/soft/bindings/openjump/
>
> I tried to find the source code of GvSig CE but I failed. Could you please
> send us a link to their SVN repository? Thanks.
>
> Eric
>
> On 10/08/2020 20:02, Giuseppe Aruta wrote:
>
> >>Less than a day of work should be required (if not less) to update all
> the plugins which do not rely on a dependency which relies itself on JTS.
> I'm going to test it, to see if it's the case.
>
> Possibly Sextante Will be a problem as we don't have the source code of
> the project (it is available on GvSig CE svn repository). And Sextante.jar,
> Sextante-gui.jar and Sextante-algorithms.jar partially rely on JTS.
> I gave a look at the source code: the versione available on GvSig CE is a
> bit different from the one embedded into Openjump: there are some
> enhancements and few depencies to GvSig class: nothing serious as I tested
> their version with Openjump and it works fine. Right now my tested version
> of Openjump for raster analysis  uses GvSig CE sextante.
>
> My idea is to download Sextante source code from GvSig CE and try to
> recompile it with new JTS. And prepare some tests following Sextante
> documentation and user's notes (Openjump with all raster tools is used in a
> couple of courses at the University of Padua) .
> I will also mail to GvSig CE folks. GVSIG CE (at least sextante) seems
> not have activity since a couple of years.
> Peppe
>
>
>
>
>
> Il lun 10 ago 2020, 15:52 Eric  ha scritto:
>
>> Here is the list of all the SVN authors (and their number of
>> contributions) according to the logs:
>> beckerl 197
>> bertazza 29
>> bgudehus 6
>> clark 6
>> edso 1305
>> elnico 54
>> eric.lemesre 4
>> infinityedge 2
>> jammerhund 47
>> javamap 10
>> jratike80 22
>> kdneufeld 2
>> lreeder 1
>> ma15569 602
>> mentaer 465
>> michaudm 1619
>> paul_d_austin 38
>> s-l-teichmann 1
>> stranger 87
>>
>> If you want to keep track of them in the possible future Git repository,
>> a conversion file needs to be created, for example (with one author per
>> line):
>> michaudm = Michael Michaud  
>>
>> We should maybe do this outside this mailing list to avoid creating a
>> list of public email addresses.
>>
>> For info, I easily managed to locally create a Git repository containing
>> the 1.15 release of OpenJUMP, using the 6242 revision. I'm waiting for your
>> different answers to move to the next step.
>>
>> Best,
>> Eric
>>
>> On 10/08/2020 14:42, Eric wrote:
>>
>> Hi Ede,
>>
>> Thanks for your welcome and for your answers. See my inline replies for
>> some of them (I deleted the other parts).
>>
>> On 09/08/2020 16:40, edgar.sol...@web.de wrote:
>>
>> hey Eric,
>>
>> welcome to the team! see my answers below
>>
>> On 07.08.2020 20:55, Eric wrote:
>>
>> Then I checked which OJ lib dependencies rely on JTS and it seems that
>> there 

Re: [JPP-Devel] OJ 2.x Was:Re: JTS update: first experiments

[Giuseppe Aruta]

>>Less than a day of work should be required (if not less) to update all
the plugins which do not rely on a dependency which relies itself on JTS.
I'm going to test it, to see if it's the case.

Possibly Sextante Will be a problem as we don't have the source code of the
project (it is available on GvSig CE svn repository). And Sextante.jar,
Sextante-gui.jar and Sextante-algorithms.jar partially rely on JTS.
I gave a look at the source code: the versione available on GvSig CE is a
bit different from the one embedded into Openjump: there are some
enhancements and few depencies to GvSig class: nothing serious as I tested
their version with Openjump and it works fine. Right now my tested version
of Openjump for raster analysis  uses GvSig CE sextante.

My idea is to download Sextante source code from GvSig CE and try to
recompile it with new JTS. And prepare some tests following Sextante
documentation and user's notes (Openjump with all raster tools is used in a
couple of courses at the University of Padua) .
I will also mail to GvSig CE folks. GVSIG CE (at least sextante) seems not
have activity since a couple of years.
Peppe





Il lun 10 ago 2020, 15:52 Eric  ha scritto:

> Here is the list of all the SVN authors (and their number of
> contributions) according to the logs:
> beckerl 197
> bertazza 29
> bgudehus 6
> clark 6
> edso 1305
> elnico 54
> eric.lemesre 4
> infinityedge 2
> jammerhund 47
> javamap 10
> jratike80 22
> kdneufeld 2
> lreeder 1
> ma15569 602
> mentaer 465
> michaudm 1619
> paul_d_austin 38
> s-l-teichmann 1
> stranger 87
>
> If you want to keep track of them in the possible future Git repository, a
> conversion file needs to be created, for example (with one author per line):
> michaudm = Michael Michaud  
>
> We should maybe do this outside this mailing list to avoid creating a list
> of public email addresses.
>
> For info, I easily managed to locally create a Git repository containing
> the 1.15 release of OpenJUMP, using the 6242 revision. I'm waiting for your
> different answers to move to the next step.
>
> Best,
> Eric
>
> On 10/08/2020 14:42, Eric wrote:
>
> Hi Ede,
>
> Thanks for your welcome and for your answers. See my inline replies for
> some of them (I deleted the other parts).
>
> On 09/08/2020 16:40, edgar.sol...@web.de wrote:
>
> hey Eric,
>
> welcome to the team! see my answers below
>
> On 07.08.2020 20:55, Eric wrote:
>
> Then I checked which OJ lib dependencies rely on JTS and it seems that
> there is only deegree 2,
> without considering here the plethora of extensions/plugins.
>
> which is the main obstacle. the only clean solution i see is to branch out
> a new OJ 2.x that initially will break compatibility to all external
> plugins. that's the bad news.
> the good news is that this forces us to retouch pretty much all of them
> and during this effort we might eventually come up with a working plugin
> manager after all.
>
>
> Less than a day of work should be required (if not less) to update all the
> plugins which do not rely on a dependency which relies itself on JTS. I'm
> going to test it, to see if it's the case.
> I tried with my plugins and I just needed a couple of seconds to do it.
>
> This is quite a good news because
> if the deegree dependency is updated to its latest version (3.x.x), which
> relies on JTS 1.15,
> then, theoretically, only the import statements and a few other
> com.vividsolutions directly used in the code
> need to be modified.
>
> yeah, probably not. deegree2 is afaics used primarily or exclusively for
> the WFS extension and i remember checking out deegree3 as a drop in for
> deegree2 but failing miserably. that's why i stuck with deegree2 happy to
> have at least a working WFS extension for the time being.
>
> but again, we can remove WFS from core for OJ 2.x and come up with a
> working extension later (if at all).
>
>
> It seems to be a good compromise for the time being as the migration from
> deegree-core 2 to deegree-core 3 isn't straightforward.
>
> - the GeoJSON part (com.vividsolutions.jump.io.geojson) is problematic due
> to the jts-io
> pom type only, but once imported, this part of the code will be functional
> again,
>
> how do you figure? com.vividsolutions.jump.io.geojson was written by
> myself from scratch utilizing google's json-simple . it holds no dependency
> apart from the jts geometry code. maybe myself placing it in this package
> has mislead you
>
>
> Have a look at the GeoJsonReader class for example, and the method
> MapGeoJsonGeometryReader (see the comment), or the
> GeoJSONFeatureCollectionWrapper class. You will see that there is a
> dependency to JTS io.
> It doesn't mean that there is a real dependency in the way it works, but
> JTS io (now jts-io-common which includes the GeoJSON code) is needed for
> the code to compile.
>
> - some classes have been deprecated, removed, or simply moved in the new
> JTS versions,
> such as com.vividsolutions.jts.geom.DefaultCoordinateSequenceFactory. New
> 

Re: [JPP-Devel] batik upgraded

[Giuseppe Aruta]

Yes 1.5 ->1.15

Il giorno dom 9 ago 2020 alle ore 14:25  ha scritto:

> On 09.08.2020 14:06, Giuseppe Aruta wrote:
> > I will open a bug ticket for the problem about /loading project files
> saved with different versions of OpenJUMP./ It looks quite severe
>
> just to make sure. you're talking about OJ 1.15 (latest release) vs.
> latest snapshot right?
>
> ..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] batik upgraded

[Giuseppe Aruta]

For CadPlan SVG export. I only used ISA renderer

Il giorno dom 9 ago 2020 alle ore 14:03 Giuseppe Aruta <
giuseppe.ar...@gmail.com> ha scritto:

> Hi Ede, Michaël
>
> Following Michaël's test I also was able to do a test using 3 versions of
> OpenJUMP
> a) OpenJUMP 1.5 last stable realize
> b) OpenJUMP 6363. I choose this version because I grouped "Save view"
> plugins into a unique menu
> ("Save view") with the option to choose type (TIFF, PNG and SVG). I
> extended to svg the
> option to save at a defined scale
> c) OpenJUMP 6370, the last NB realize where Ede upgraded batik libraries
>
> I used as test files one vector file, one image file,loaded as
> referencedImageLayer (both
> using Open->file menu), and one DEM file loaded as RasterImageLayer (using
> Open->Raster Image (sextante)
> menu.
> Test files and SVG output are available here:
>
> https://sourceforge.net/projects/opensit/files/Test%20file/Export%20to%20SVG/
>
> These are the problems (the first one already known) and bugs that I found
> (not only on SVG).
>
> *On saving a project file*.
> ReferencedImageLayer must be saved as a vector layer (SHP or JML)
> otherwise it will not be saved into the project file.
>
> *On loading project files saved with different versions of OpenJUMP*.
> There is a break after OpenJUMP 1.5 and before OpenJUMP 6363 on
> saving/loading project files.
>a) OpenJUMP 1.5 freezes on loading project files saved at least with
> OpenJUMP 6363 and 6370
>   The console (I use Linux) doesn't show any warning.
>b) OpenJUMP 6363 and 6370  cannot load project files saved at least
> with OpenJUMP 1.5 .
> The console doesn't show any warning.
>   c) OpenJUMP 6363 can load project files saved with OpenJUMP 6370 and
> vice versa
>
> 3)* On saving SVG*
>
> a) *Saving SVG using embedded Save view plugin*
> OpenJUMP 1.5 and OpenJUMP 6363 save the view with all the three layers if
> I don't modify any
> parameters on Save dialog. On the other hand, modifing the scale
> parameters on save dialog,
> RasterImageLayer is not saved on SVG file
> OpenJUMP 6370 saves an empty SVG file (none of the layers are displayed)
>
> b)* Saving SVG using CadPlann print plugin*
> OpenJUMP 1.5 and OpenJUMP 6363. While ReferencedImageLayers and
> VectorLayers are
> saved at the correct scale and position, RasterImageLayers are rescaled
> and, possibly, shifted
>  from their original position, compared to OpenJUMP view.
>  OpenJUMP 6370 saves an empty SVG file (none of the layers are displayed)
>
> Saving SVG with OpenJUMP 6370 can be corrected using the newer batik
> libraries. I which approach we need to fix the scaling problems
> of RasterImageLayers.
> I will open a bug ticket for the problem about *loading project files
> saved with different versions of OpenJUMP.* It looks quite severe
> Best regards
> Peppe
>
> Il giorno sab 8 ago 2020 alle ore 22:16 Michaud Michael <
> m.michael.mich...@orange.fr> ha scritto:
>
>> Hi Ede,
>>
>> I finally found some time and get noticeable differences between last
>> revision and 1.15.
>>
>> I just tested export image to svg and export map to svg from cadplan (I
>> don't know other places where svg is used).
>>
>> Prepare a map wit a sextante raster and some vectors
>>
>> Export the view to a file, choose svg :
>>
>> - get the same thing on 1.15 and last revision : vectors but no image
>>
>> Export map from cadplan
>>
>> - cadplan with external renderer : get nothing, file is even not exported
>> (neither in 1.15 nor with last revision)
>>
>> - cadplan ISA renderer : get vector and raster with a scale problem on
>> 1.15, get nothing with last release
>>
>> - cadplan core renderer : get vector and raster on 1.15, get nothing with
>> last release
>>
>> => I couldn't get svg map from cadplan plugin from last release, did you ?
>>
>>
>> Michaël
>>
>>
>>
>> envoyé : 6 août 2020 à 14:46
>> de : edgar.sol...@web.de
>> à : jump-pilot-devel@lists.sourceforge.net
>> objet : Re: [JPP-Devel] batik upgraded
>>
>>
>> a quick test of both did not reveal any bugs. how about on your sides?
>> ..ede
>>
>> On 05.08.2020 16:14, Giuseppe Aruta wrote:
>>
>> Thanks Ede,
>> AFAIR also both print plugins have dependencies  to batik classes
>> Peppe
>>
>> Il giorno mer 5 ago 2020 alle ore 15:19 > edgar.sol...@web.de>> ha scritto:
>>
>> hey All,
>>
>> had to touch batik, as it was missing some classes in trunk/lib/batik.jar
>> after Peppe added

Re: [JPP-Devel] batik upgraded

[Giuseppe Aruta]

Hi Ede, Michaël

Following Michaël's test I also was able to do a test using 3 versions of
OpenJUMP
a) OpenJUMP 1.5 last stable realize
b) OpenJUMP 6363. I choose this version because I grouped "Save view"
plugins into a unique menu
("Save view") with the option to choose type (TIFF, PNG and SVG). I
extended to svg the
option to save at a defined scale
c) OpenJUMP 6370, the last NB realize where Ede upgraded batik libraries

I used as test files one vector file, one image file,loaded as
referencedImageLayer (both
using Open->file menu), and one DEM file loaded as RasterImageLayer (using
Open->Raster Image (sextante)
menu.
Test files and SVG output are available here:
https://sourceforge.net/projects/opensit/files/Test%20file/Export%20to%20SVG/

These are the problems (the first one already known) and bugs that I found
(not only on SVG).

*On saving a project file*.
ReferencedImageLayer must be saved as a vector layer (SHP or JML) otherwise
it will not be saved into the project file.

*On loading project files saved with different versions of OpenJUMP*.
There is a break after OpenJUMP 1.5 and before OpenJUMP 6363 on
saving/loading project files.
   a) OpenJUMP 1.5 freezes on loading project files saved at least with
OpenJUMP 6363 and 6370
  The console (I use Linux) doesn't show any warning.
   b) OpenJUMP 6363 and 6370  cannot load project files saved at least with
OpenJUMP 1.5 .
The console doesn't show any warning.
  c) OpenJUMP 6363 can load project files saved with OpenJUMP 6370 and vice
versa

3)* On saving SVG*

a) *Saving SVG using embedded Save view plugin*
OpenJUMP 1.5 and OpenJUMP 6363 save the view with all the three layers if I
don't modify any
parameters on Save dialog. On the other hand, modifing the scale parameters
on save dialog,
RasterImageLayer is not saved on SVG file
OpenJUMP 6370 saves an empty SVG file (none of the layers are displayed)

b)* Saving SVG using CadPlann print plugin*
OpenJUMP 1.5 and OpenJUMP 6363. While ReferencedImageLayers and
VectorLayers are
saved at the correct scale and position, RasterImageLayers are rescaled
and, possibly, shifted
 from their original position, compared to OpenJUMP view.
 OpenJUMP 6370 saves an empty SVG file (none of the layers are displayed)

Saving SVG with OpenJUMP 6370 can be corrected using the newer batik
libraries. I which approach we need to fix the scaling problems
of RasterImageLayers.
I will open a bug ticket for the problem about *loading project files saved
with different versions of OpenJUMP.* It looks quite severe
Best regards
Peppe

Il giorno sab 8 ago 2020 alle ore 22:16 Michaud Michael <
m.michael.mich...@orange.fr> ha scritto:

> Hi Ede,
>
> I finally found some time and get noticeable differences between last
> revision and 1.15.
>
> I just tested export image to svg and export map to svg from cadplan (I
> don't know other places where svg is used).
>
> Prepare a map wit a sextante raster and some vectors
>
> Export the view to a file, choose svg :
>
> - get the same thing on 1.15 and last revision : vectors but no image
>
> Export map from cadplan
>
> - cadplan with external renderer : get nothing, file is even not exported
> (neither in 1.15 nor with last revision)
>
> - cadplan ISA renderer : get vector and raster with a scale problem on
> 1.15, get nothing with last release
>
> - cadplan core renderer : get vector and raster on 1.15, get nothing with
> last release
>
> => I couldn't get svg map from cadplan plugin from last release, did you ?
>
>
> Michaël
>
>
>
> envoyé : 6 août 2020 à 14:46
> de : edgar.sol...@web.de
> à : jump-pilot-devel@lists.sourceforge.net
> objet : Re: [JPP-Devel] batik upgraded
>
>
> a quick test of both did not reveal any bugs. how about on your sides?
> ..ede
>
> On 05.08.2020 16:14, Giuseppe Aruta wrote:
>
> Thanks Ede,
> AFAIR also both print plugins have dependencies  to batik classes
> Peppe
>
> Il giorno mer 5 ago 2020 alle ore 15:19  edgar.sol...@web.de>> ha scritto:
>
> hey All,
>
> had to touch batik, as it was missing some classes in trunk/lib/batik.jar
> after Peppe added AdditionalResultsIO. maven already had the proper batik
> components defined that's why the snapshot builds went fine.
>
> while at it i noticed that we were using a quite old batik version and
> upgraded it. looks good to me but please test and come back if something
> breaks horribly.
>
> sunshine all over.. (sweating) ede
>
>  Forwarded Message 
> Subject: [JPP-Devel] SVN: [6369] core/trunk
> Date: Wed, 05 Aug 2020 12:50:50 +
> From: jump-pilot-svn--- via Jump-pilot-devel <
> jump-pilot-devel@lists.sourceforge.net  jump-pilot-devel@lists.sourceforge.net>>
> Reply-To: OpenJump develop and use  <mailto:jump-pilot-devel@lists.sourcefo

Re: [JPP-Devel] OpenJUMP new contributor

[Giuseppe Aruta]

Welcome Eric. It is really nice to see you back on the list and to
have your contribution to the project.
Peppe

2020-08-07 19:39 GMT+02:00, Eric :
> Hi everyone,
>
> Note: I just changed the email address I'd like to use to contribute on
> this list.
>
>
> Thank you Michael for your welcome on this list and your kind message.
>
> As Michaël pointed out, I started updating some former OpenJUMP
> extensions that I created years ago, and I've recently been in touch
> with him to know a bit more about the evolution of OpenJUMP. We talked
> about the dependencies, including JTS and deegree, the best way to
> import the project, a possible move to Git (Gitlab, Github, etc.), etc.
>
> So yes, I know OpenJUMP in a certain extent but I'm far from being an
> expert despite the fact that I developed these extensions. To be totally
> honest, I didn't code much in Java during the last 3 or 4 years, so I'm
> probably a bit rusty. For these reasons, I am quite happy to talk about
> what I experimented with during the recent days, including a possible
> update to a "new" version of JTS (com.vividsolutions renamed into
> org.locationtech), etc., but I don't feel confident, at least for now,
> to modify the Maven configuration and to commit these changes. Michaël
> said that Ede was really good at it, and I would prefer relying on his
> skills rather than my mine at the moment to push the commit
> button/command line. That said, I'm quite happy to discuss what could
> possibly be updated, and to update/commit some of the code, for example
> to improve all the generic types such as HashMap.
>
> Rather than writing more about it in this introductory message, I'll
> write another message tonight about what I just did today.
>
> Best wishes to all of you.
> Take care,
> Eric
>
> On 07/08/2020 16:21, Michaud Michaël wrote:
>>
>> Hi all,
>>
>> I reconnected with Eric Grosso, a former colleague who is also an
>> OpenJUMP expert as he wrote the MorphAl extension
>> (https://alpage.huma-num.fr/extension-sig/), the concave hull
>> extension (now incorporated in OJ-PLUS) and probably some other useful
>> contributions.
>>
>> He already noticed several outdated repositories in the pom an we
>> talked a little bit about the future of OpenJUMP (including some
>> recurrent questions like migration to github,
>> org.locationtech.jts...). I invited him to continue the discussion on
>> this list and want to welcome him.
>>
>> Michaël
>>
>
>
> ___
> 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] batik upgraded

[Giuseppe Aruta]

Thanks Ede,
AFAIR also both print plugins have dependencies  to batik classes
Peppe

Il giorno mer 5 ago 2020 alle ore 15:19  ha scritto:

> hey All,
>
> had to touch batik, as it was missing some classes in trunk/lib/batik.jar
> after Peppe added AdditionalResultsIO. maven already had the proper batik
> components defined that's why the snapshot builds went fine.
>
> while at it i noticed that we were using a quite old batik version and
> upgraded it. looks good to me but please test and come back if something
> breaks horribly.
>
> sunshine all over.. (sweating) ede
>
>  Forwarded Message 
> Subject: [JPP-Devel] SVN: [6369] core/trunk
> Date: Wed, 05 Aug 2020 12:50:50 +
> From: jump-pilot-svn--- via Jump-pilot-devel <
> jump-pilot-devel@lists.sourceforge.net>
> Reply-To: OpenJump develop and use  >
> To: jump-pilot-devel@lists.sourceforge.net
> CC: jump-pilot-...@lists.sourceforge.net
>
> Revision: 6369
>   http://sourceforge.net/p/jump-pilot/code/6369
> Author:   edso
> Date: 2020-08-05 12:50:49 + (Wed, 05 Aug 2020)
> Log Message:
> ---
> upgrade batik to latest greatest v1.13
> minimal fixup of AdditonalResultsIO
> fingers crossed, let's see if it breaks something more
>
> Modified Paths:
> --
> core/trunk/pom.xml
>
> core/trunk/src/org/openjump/sextante/gui/additionalResults/AdditionalResultsIO.java
>
> Added Paths:
> ---
> core/trunk/lib/batik-all-1.13.jar
>
> Removed Paths:
> -
> core/trunk/lib/batik-all.jar
>
> Added: core/trunk/lib/batik-all-1.13.jar
> ===
> (Binary files differ)
>
> Index: core/trunk/lib/batik-all-1.13.jar
> ===
> --- core/trunk/lib/batik-all-1.13.jar   2020-08-05 12:45:12 UTC (rev 6368)
> +++ core/trunk/lib/batik-all-1.13.jar   2020-08-05 12:50:49 UTC (rev 6369)
>
> Property changes on: core/trunk/lib/batik-all-1.13.jar
> ___
> Added: svn:mime-type
> ## -0,0 +1 ##
> +application/octet-stream
> \ No newline at end of property
> Deleted: core/trunk/lib/batik-all.jar
> ===
> (Binary files differ)
>
> Modified: core/trunk/pom.xml
> ===
> --- core/trunk/pom.xml  2020-08-05 12:45:12 UTC (rev 6368)
> +++ core/trunk/pom.xml  2020-08-05 12:50:49 UTC (rev 6369)
> @@ -924,25 +924,25 @@
>  
>  batik
>  batik-awt-util
> -1.6
> +1.13
>  compile
>  
>  
>  batik
>  batik-dom
> -1.6
> +1.13
>  compile
>  
>  
>  batik
>  batik-svggen
> -1.6
> +1.13
>  compile
>  
>  
>  batik
>  batik-squiggle
> -1.6
> +1.13
>  compile
>  
>  
>
> Modified:
> core/trunk/src/org/openjump/sextante/gui/additionalResults/AdditionalResultsIO.java
> ===
> ---
> core/trunk/src/org/openjump/sextante/gui/additionalResults/AdditionalResultsIO.java
> 2020-08-05 12:45:12 UTC (rev 6368)
> +++
> core/trunk/src/org/openjump/sextante/gui/additionalResults/AdditionalResultsIO.java
> 2020-08-05 12:50:49 UTC (rev 6369)
> @@ -27,7 +27,7 @@
>  import javax.swing.tree.TreePath;
>  import javax.xml.namespace.QName;
>
> -import org.apache.batik.dom.svg.SVGDOMImplementation;
> +import org.apache.batik.anim.dom.SVGDOMImplementation;
>  import org.apache.batik.svggen.SVGGraphics2D;
>  import org.apache.log4j.Logger;
>  import org.math.plot.PlotPanel;
> @@ -37,7 +37,7 @@
>  import org.openjump.core.ui.util.LayerableUtil;
>  import org.openjump.sextante.core.ObjectAndDescription;
>  import org.w3c.dom.DOMImplementation;
> -import org.w3c.dom.svg.SVGDocument;
> +import org.w3c.dom.Document;
>
>  import com.vividsolutions.jump.I18N;
>  import com.vividsolutions.jump.feature.FeatureCollection;
> @@ -401,7 +401,7 @@
> // Get a SVGDOMImplementation and create an XML document
> DOMImplementation domImpl =
> SVGDOMImplementation.getDOMImplementation();
> String svgNS = "http://www.w3.org/2000/svg;;
> -   SVGDocument svgDocument = (SVGDocument)
> domImpl.createDocument(svgNS, "svg", null);
> +   Document svgDocument = domImpl.createDocument(svgNS,
> "svg", null);
>
> // Create an instance of the SVG Generator
> SVGGraphics2D svgGenerator = new
> SVGGraphics2D(svgDocument);
>
>
>
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>
> 

Re: [JPP-Devel] bsh sextante NPE in latest checkout

[Giuseppe Aruta]

 It Is connected to sextante toolbar initialize process, I think. As I can
see It seems not to affect any funcionality. But It is not fine. I Will
give a look.
Peppe

Il mar 4 ago 2020, 12:47 PM  ha scritto:

> hey Mike, Peppe,
>
> i'm getting the below when running the latest checkout in eclipse. the
> snapshot build runs fine though. any idea? ..ede
>
> [ERROR] 12:34:05.862 java.lang.NullPointerException at
> com.vividsolutions.jump.workbench.ui.WorkbenchFrame.handleThrowable(WorkbenchFrame.java:1258)
> java.lang.NullPointerException
> at
> bsh.classpath.ClassManagerImpl.classForName(ClassManagerImpl.java:181)
> at bsh.NameSpace.classForName(NameSpace.java:1389)
> at bsh.NameSpace.getClassImpl(NameSpace.java:1289)
> at bsh.NameSpace.getClass(NameSpace.java:1230)
> at bsh.Name.consumeNextObjectField(Name.java:295)
> at bsh.Name.toObject(Name.java:196)
> at bsh.Name.toObject(Name.java:179)
> at bsh.NameSpace.get(NameSpace.java:233)
> at bsh.Interpreter.get(Interpreter.java:841)
> at bsh.Interpreter.getu(Interpreter.java:853)
> at bsh.Interpreter.(Interpreter.java:206)
> at bsh.Interpreter.(Interpreter.java:221)
> at bsh.Interpreter.(Interpreter.java:255)
> at
> es.unex.sextante.gui.cmd.ScriptAlgorithm.resetInterpreter(ScriptAlgorithm.java:208)
> at
> es.unex.sextante.gui.cmd.ScriptAlgorithmProvider.initialize(ScriptAlgorithmProvider.java:70)
> at
> es.unex.sextante.gui.core.SextanteGUI._initialize(SextanteGUI.java:288)
> at
> es.unex.sextante.gui.core.SextanteGUI.initialize(SextanteGUI.java:271)
> at
> es.unex.sextante.openjump.extensions.SextanteToolboxPlugin.initialize(SextanteToolboxPlugin.java:85)
> at
> es.unex.sextante.openjump.extensions.SextanteExtension.configure(SextanteExtension.java:52)
> at
> com.vividsolutions.jump.workbench.plugin.PlugInManager.loadConfigurations(PlugInManager.java:214)
> at
> com.vividsolutions.jump.workbench.plugin.PlugInManager.load(PlugInManager.java:194)
> at
> com.vividsolutions.jump.workbench.JUMPWorkbench.main(JUMPWorkbench.java:457)
> at
> com.vividsolutions.jump.workbench.JUMPWorkbench.main(JUMPWorkbench.java:386)
> [INFO] 12:34:05.864 es.unex.sextante.openjump.extensions.SextanteExtension
> could not be initialized at
> com.vividsolutions.jump.workbench.plugin.PlugInManager.loadConfigurations(PlugInManager.java:223)
>
>
> ___
> 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] [jump-pilot:bugs] #495 Warp panel shows a vertical toolba instead of horizontal on Ubuntu

[Giuseppe Aruta via Jump-pilot-devel]

One possible solution is to change LayoutManager of the toolbar.
This line works: 
toolbox.getToolBar().setLayout(new FlowLayout());


---

** [bugs:#495] Warp panel shows a vertical toolba instead of horizontal on 
Ubuntu**

**Status:** open
**Created:** Fri Jul 31, 2020 07:40 AM UTC by Giuseppe Aruta
**Last Updated:** Fri Jul 31, 2020 07:40 AM UTC
**Owner:** Giuseppe Aruta
**Attachments:**

- 
[Senzanome.png](https://sourceforge.net/p/jump-pilot/bugs/495/attachment/Senzanome.png)
 (45.0 kB; image/png)


On Ubuntu Mate.
Warp Plugin. The toolbar of the panel sets all vector tools icon in a vertical 
position, as shown in the attached picture. 



---

Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/jump-pilot/bugs/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/jump-pilot/admin/bugs/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] [jump-pilot:bugs] #495 Warp panel shows a vertical toolba instead of horizontal on Ubuntu

[Giuseppe Aruta via Jump-pilot-devel]

---

** [bugs:#495] Warp panel shows a vertical toolba instead of horizontal on 
Ubuntu**

**Status:** open
**Created:** Fri Jul 31, 2020 07:40 AM UTC by Giuseppe Aruta
**Last Updated:** Fri Jul 31, 2020 07:40 AM UTC
**Owner:** Giuseppe Aruta
**Attachments:**

- 
[Senzanome.png](https://sourceforge.net/p/jump-pilot/bugs/495/attachment/Senzanome.png)
 (45.0 kB; image/png)


On Ubuntu Mate.
Warp Plugin. The toolbar of the panel sets all vector tools icon in a vertical 
position, as shown in the attached picture. 



---

Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/jump-pilot/bugs/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/jump-pilot/admin/bugs/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Some enhencements on Openjump

[Giuseppe Aruta]

Thank Michael.
I still have to check your observations about vertex style plugin.
Hopefully I will I'll work around your n the next weeks.
Peppe

Il sab 18 lug 2020, 12:57 Michaud Michael  ha
scritto:

> Thanks Peppe,
>
> Nice to see that you're still active on the project. I'll check your
> enhancement soon, especially the one related to FR 235.
>
> Michaël
>
> *envoyé :* 16 juillet 2020 à 18:00
> *de :* Giuseppe Aruta 
> *à :* OpenJump develop and use 
> *objet :* [JPP-Devel] Some enhencements on Openjump
>
> Greatings to all Jumpers,
> today I made some small changes in the editing section of openjump.
> EditOptionPanel: I added an option that automatically opens the InfoFrame
> of the attributes immediately after digitizing a geometry.  This option
> allows you to enter attribute values during digitization and responds (in
> part) to the feature request "235" (Create form to edit attribute values)
> of a few years ago.
> CAD plugin: the new version also loads a python console and tools (python
> console and tools plugin), for now I have activated only a few tools, such
> as the align and arrange tools. Hopefully thks section could be expanded in
> the future.
> This changes are already available on Openjump snapshot 6361.
> 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
>
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] Some enhencements on Openjump

[Giuseppe Aruta]

Greatings to all Jumpers,
today I made some small changes in the editing section of openjump.
EditOptionPanel: I added an option that automatically opens the InfoFrame
of the attributes immediately after digitizing a geometry.  This option
allows you to enter attribute values ​​during digitization and responds (in
part) to the feature request "235" (Create form to edit attribute values)
of a few years ago.
CAD plugin: the new version also loads a python console and tools (python
console and tools plugin), for now I have activated only a few tools, such
as the align and arrange tools. Hopefully thks section could be expanded in
the future.
This changes are already available on Openjump snapshot 6361.
Best regards
Peppe
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] [jump-pilot:feature-requests] #245 Create form to edit attribute values

[Giuseppe Aruta via Jump-pilot-devel]

- **status**: open --> pending
- **Comment**:

OJ 6352 2020-07-16. added to  EditOptionPanel an option to automatically open a 
feature Info Frame  after a new feature is created. This allows user to input 
attribute values directly after digitalizing a feature



---

** [feature-requests:#245] Create form to edit attribute values**

**Status:** pending
**Created:** Mon Oct 24, 2016 09:16 PM UTC by michael michaud
**Last Updated:** Mon Oct 24, 2016 09:16 PM UTC
**Owner:** michael michaud


Create a form to edit attribute values like QGIS.


---

Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/jump-pilot/feature-requests/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/jump-pilot/admin/feature-requests/options.  Or, if 
this is a mailing list, you can unsubscribe from the mailing list.___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Updating extension

[Giuseppe Aruta]

Hi Michaël,
thanks for the comments.

*interaction with "display vertex symbol" in Basic Style panel and "display
vertex symbol" in Color Theming panel is difficult to understand. I think
that the option is supposed to be driven by the checkbox of the color
theming panel, but it also interacts with the one of basic style. I tried
without success to understand why sometimes I get both the small square and
the symbol defined in the vertex color theming displayed*.

Yes. That is not fine to have two symbols overlapping. While simple method
removing vertex style (whenever user sets a new single/classification
cadplan symbology) works in many common situation. In other case it throws
some severe exceptions and XBasicStyle class seems not accept a VertexStyle
null. I will give a look in the next days. I think I will have to rewrite
some codes and eventually see if there are some "left over" on ColorTheming
classes of Open jump.

*if i check the option to resize the symbol according to the map scale, I
loose the color-theming symbols*

I think the option resizes symbols to their real dimension without taking
into account the scale of the view, which is possibly the main option that
the user would consider (for instance, zoom to 1, consider that the
size of the symbols are accurate for that scale, than define that symbols
will be smaller or bigger whenever the zoom is changed). I didn't touch
this part of the original code. I will give a look.

*when line decoration is activate is checked, double click on a symbol open
the symbol chooser, not the line decoration chooser*

This is not intuitive. Cadplan line decoratorion is made by the standard
line decoration (driven by Standard OJ symbol plugin) with associated
vertex symbols.
Whenever the user click on the (line) symbol it pops up a symbol chooser
only, may I should add to this chiiser also some commands to choose also
line thinkness and strike: this will be more intuitive and useful.

*about labels : i think it is fine to have added a panel inside the cadplan
extension for that, but it would be nice to have the same options in the
standard style panel and in the cadplan panel. Currently, there are
additional options in the standard panel (overlapping labels, halo,
vertical alignment...) and other options in the cadplan plugin like
labeling point/lines/polygons. What about adding the missing option in the
standard panel and reusing it as is in the cadplan panel ?*

This is another part that I didn't touch, only reorganized the menu.
Labeling on cadplan plugin are integrated into the class
ExternalSymbolsStyle (an extension of VertexStyle.class) and associated.
While OJ labeling use other classes, as far as U renember. Indeed it would
be fine to have all these option in one java container and to make simpler
and more intuitive commands.

In these days I am traveling. I will give a look to the code of the plugin
in a week or two.

BTW. The new cadplan plugin has had ad will have so many changing and
add-ons that I am considering to move out as a separate project, like an
"Advanced Style" plugin

Peppe


Il giorno sab 13 giu 2020 alle ore 16:51 Michaud Michael <
m.michael.mich...@orange.fr> ha scritto:

> Hi Peppe,
>
> Hope you're fine. I noticed that most extensions you recently updated are
> duplicated. I think you just forgot to remove old versions, or you removed
> them in a way which is not detected by you're svn client. I did the same
> mistake today, and had to update the  project to get the file back and
> remove it properly through my IDE so that it is removed by the following
> commit.
>
> At the moment, I just had a quick look on vertex symbol classification.
> This is a nice addition. Here are a few remarks :
>
> - interaction with "display vertex symbol" in Basic Style panel and
> "display vertex symbol" in Color Theming panel is difficult to understand.
> I think that the option is supposed to be driven by the checkbox of the
> color theming panel, but it also interacts with the one of basic style. I
> tried without success to understand why sometimes I get both the small
> square and the symbol defined in the vertex color theming displayed.
>
> - if i check the option to resize the symbol according to the map scale, I
> loose the color-theming symbols
>
> - when line decoration is activate is checked, double click on a symbol
> open the symbol chooser, not the line decoration chooser
>
> - about labels : i think it is fine to have added a panel inside the
> cadplan extension for that, but it would be nice to have the same options
> in the standard style panel and in the cadplan panel. Currently, there are
> additional options in the standard panel (overlapping labels, halo,
> vertical alignment...) and other options in the cadplan plugin like
> labeling point/lines/polygons. What about adding the missing option in the
> standard panel and reusing it as is in the cadplan panel ?
>
> Anyway, sorry if my remarks are premature. I know you're still 

Re: [JPP-Devel] [jump-pilot:feature-requests] #268 Translation of Map Coloring plugin to Hungarian

[Giuseppe Aruta]

Sorry, I did a mistake on build it.
Try version 6323
Peppe

Il giorno gio 11 giu 2020 alle ore 13:22 "János Tamás Kis" via
Jump-pilot-devel  ha scritto:

> Hi,
> I have tried to use the last snapshot but I am afraid it has a bit
> misstake.
> There is a "ojmapcoloring-0.5.2.jar" file but it contains the cadplan
> pluguin maybe and doesn't the mapcoloring plugin.
> BR,
> János
> --
>
> * [feature-requests:#268]
> <https://sourceforge.net/p/jump-pilot/feature-requests/268/> Translation of
> Map Coloring plugin to Hungarian*
>
> *Status:* closed
> *Labels:* localisation ojmapcoloring
> *Created:* Wed Jun 10, 2020 07:31 AM UTC by János Tamás Kis
> *Last Updated:* Wed Jun 10, 2020 12:06 PM UTC
> *Owner:* Giuseppe Aruta
> *Attachments:*
>
>- mapcolorstrings_hu.properties
>
> <https://sourceforge.net/p/jump-pilot/feature-requests/268/attachment/mapcolorstrings_hu.properties>
>(347 Bytes; text/plain)
>
> When I starting the Openjump, I got the next message always:
>
> [ERROR] ... Can't find bundle for base name 
> /org/freevoice/mapcoloring/mapcolorstrings, locale hu_HU
>
> So I have prepared a "mapcolorstrings_hu.properties" file and I put into
> my ojmapcoloring-0.5.jar.
> It works so it would by nice to add it to "official release".
>
> *Important: the file must be have ISO8859-2 codepage*
> --
>
> Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net
> is subscribed to https://sourceforge.net/p/jump-pilot/feature-requests/
>
> To unsubscribe from further messages, a project admin can change settings
> at https://sourceforge.net/p/jump-pilot/admin/feature-requests/options.
> Or, if this is a mailing list, you can unsubscribe from the mailing list.
> ___
> 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] [jump-pilot:feature-requests] #268 Translation of Map Coloring plugin to Hungarian

[Giuseppe Aruta]

Sorry, I did a mistake. Let me rebuid it
Peppe

> Hi, I have tried to use the last snapshot but I am afraid it has a bit 
> misstake. There is a "ojmapcoloring-0.5.2.jar" file but it contains the 
> cadplan pluguin maybe and doesn't the mapcoloring plugin. BR, János 
> [feature-requests:#268] Translation of Map Coloring plugin to Hungarian 
> Status: closed Labels: localisation ojmapcoloring Created: Wed Jun 10, 2020 
> 07:31 AM UTC by János Tamás Kis Last Updated: Wed Jun 10, 2020 12:06 PM UTC 
> Owner: Giuseppe Aruta Attachments: mapcolorstrings_hu.properties (347 Bytes; 
> text/plain) When I starting the Openjump, I got the next message always: 
> [ERROR] ... Can't find bundle for base name 
> /org/freevoice/mapcoloring/mapcolorstrings, locale hu_HU So I have prepared a 
> "mapcolorstrings_hu.properties" file and I put into my ojmapcoloring-0.5.jar. 
> It works so it would by nice to add it to "official release". Important: the 
> file must be have ISO8859-2 codepage Sent from sourceforge.net because 
> jump-pilot-devel@lists.sourceforge.net is subscribed to 
> https://sourceforge.net/p/jump-pilot/feature-requests/ To unsubscribe from 
> further messages, a project admin can change settings at 
> https://sourceforge.net/p/jump-pilot/admin/feature-requests/options. Or, if 
> this is a mailing list, you can unsubscribe from the mailing list. 
> ___ 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] [jump-pilot:feature-requests] #268 Translation of Map Coloring plugin to Hungarian

[Giuseppe Aruta via Jump-pilot-devel]

- **status**: open --> closed
- **assigned_to**: Giuseppe Aruta



---

** [feature-requests:#268] Translation of Map Coloring plugin to Hungarian**

**Status:** closed
**Labels:** localisation ojmapcoloring 
**Created:** Wed Jun 10, 2020 07:31 AM UTC by kjt
**Last Updated:** Wed Jun 10, 2020 12:06 PM UTC
**Owner:** Giuseppe Aruta
**Attachments:**

- 
[mapcolorstrings_hu.properties](https://sourceforge.net/p/jump-pilot/feature-requests/268/attachment/mapcolorstrings_hu.properties)
 (347 Bytes; text/plain)


When I starting the Openjump, I got the next message always:
~~~
[ERROR] ... Can't find bundle for base name 
/org/freevoice/mapcoloring/mapcolorstrings, locale hu_HU
~~~
So I have prepared a "mapcolorstrings_hu.properties" file and I put into my 
ojmapcoloring-0.5.jar.
It works so it would by nice to add it to "official release".

*Important: the file must be have ISO8859-2 codepage*



---

Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/jump-pilot/feature-requests/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/jump-pilot/admin/feature-requests/options.  Or, if 
this is a mailing list, you can unsubscribe from the mailing list.___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] [jump-pilot:feature-requests] #268 Translation of Map Coloring plugin to Hungarian

[Giuseppe Aruta via Jump-pilot-devel]

Janos,
your hungarian file has been uploaded into OpenJUMP dist and will be available 
on next build.
If you are interested to translate OpenJUMP to Hungarian, as suggested by Ede, 
and need a help, fill free to write to the group list
Bets regards
Peppe


---

** [feature-requests:#268] Translation of Map Coloring plugin to Hungarian**

**Status:** open
**Labels:** localisation ojmapcoloring 
**Created:** Wed Jun 10, 2020 07:31 AM UTC by kjt
**Last Updated:** Wed Jun 10, 2020 10:24 AM UTC
**Owner:** nobody
**Attachments:**

- 
[mapcolorstrings_hu.properties](https://sourceforge.net/p/jump-pilot/feature-requests/268/attachment/mapcolorstrings_hu.properties)
 (347 Bytes; text/plain)


When I starting the Openjump, I got the next message always:
~~~
[ERROR] ... Can't find bundle for base name 
/org/freevoice/mapcoloring/mapcolorstrings, locale hu_HU
~~~
So I have prepared a "mapcolorstrings_hu.properties" file and I put into my 
ojmapcoloring-0.5.jar.
It works so it would by nice to add it to "official release".

*Important: the file must be have ISO8859-2 codepage*



---

Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/jump-pilot/feature-requests/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/jump-pilot/admin/feature-requests/options.  Or, if 
this is a mailing list, you can unsubscribe from the mailing list.___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] [jump-pilot:feature-requests] #268 Translation of Map Coloring plugin to Hungarian

[Giuseppe Aruta]

Hi János,
I updated OpenJUMP Night Snapshot with a new build of Map coloring plugin
with Hungarian translation.
It should be available from version 6317
Thanks again
Peppe

Il giorno mer 10 giu 2020 alle ore 12:24 ede via Jump-pilot-devel <
jump-pilot-devel@lists.sourceforge.net> ha scritto:

> hey Janos,
>
> would you by any chance be willing to translate some more? the hungarian
> translation needs a lot of love and attention by now.
>
> if you are willing find the latest language file here
>
> https://sourceforge.net/p/jump-pilot/code/HEAD/tree/core/trunk/src/language/jump_hu.properties
> simply edit it and send it back in. we will do the rest.
> hint: every entry starting with '#T:' is currently untranslated ;)
>
> thanks!.. ede
> --
>
> * [feature-requests:#268]
>  Translation of
> Map Coloring plugin to Hungarian*
>
> *Status:* open
> *Labels:* localisation ojmapcoloring
> *Created:* Wed Jun 10, 2020 07:31 AM UTC by kjt
> *Last Updated:* Wed Jun 10, 2020 07:31 AM UTC
> *Owner:* nobody
> *Attachments:*
>
>- mapcolorstrings_hu.properties
>
> 
>(347 Bytes; text/plain)
>
> When I starting the Openjump, I got the next message always:
>
> [ERROR] ... Can't find bundle for base name 
> /org/freevoice/mapcoloring/mapcolorstrings, locale hu_HU
>
> So I have prepared a "mapcolorstrings_hu.properties" file and I put into
> my ojmapcoloring-0.5.jar.
> It works so it would by nice to add it to "official release".
>
> *Important: the file must be have ISO8859-2 codepage*
> --
>
> Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net
> is subscribed to https://sourceforge.net/p/jump-pilot/feature-requests/
>
> To unsubscribe from further messages, a project admin can change settings
> at https://sourceforge.net/p/jump-pilot/admin/feature-requests/options.
> Or, if this is a mailing list, you can unsubscribe from the mailing list.
> ___
> 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: [6312] plug-ins/ojmapcoloring/readme.txt

[Giuseppe Aruta]

OK,  that makes sense: I downgrade to 0.5.2.


Il giorno mer 10 giu 2020 alle ore 13:02  ha scritto:

> hey Peppe,
>
> just some days ago i added a language file to the ojmapcoloring dist jar
> and put the sources in our repo.
>
> raised the version from 0.5 to 0.5.1 only because there were no changes i
> functionality.
>
> maybe you want to do the same.. ede
>
> On 10.06.2020 12:53, jump-pilot-svn--- via Jump-pilot-devel wrote:
> > Revision: 6312
> >   http://sourceforge.net/p/jump-pilot/code/6312
> > Author:   ma15569
> > Date: 2020-06-10 10:53:21 + (Wed, 10 Jun 2020)
> > Log Message:
> > ---
> > Updated readme file
> >
> > Modified Paths:
> > --
> > plug-ins/ojmapcoloring/readme.txt
> >
> > Modified: plug-ins/ojmapcoloring/readme.txt
> > ===
> > --- plug-ins/ojmapcoloring/readme.txt 2020-06-10 10:51:12 UTC (rev 6311)
> > +++ plug-ins/ojmapcoloring/readme.txt 2020-06-10 10:53:21 UTC (rev 6312)
> > @@ -7,6 +7,11 @@
> >  Release Notes
> >  =
> >
> > +Release 0.6
> > +-
> > +
> > +Added Hungarian translation by János Kis
> > +
> >  Release 0.5
> >  -
> >
> >
> >
> >
> > ___
> > 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] [jump-pilot:feature-requests] #268 Translation of Map Coloring plugin to Hungarian

[Giuseppe Aruta]

Thanks Jànos,
I will upgrade sourcecode and plugin
Peppe

Il giorno mer 10 giu 2020 alle ore 09:31 János Kis via Jump-pilot-devel <
jump-pilot-devel@lists.sourceforge.net> ha scritto:

> --
>
> * [feature-requests:#268]
>  Translation of
> Map Coloring plugin to Hungarian*
>
> *Status:* open
> *Labels:* localisation ojmapcoloring
> *Created:* Wed Jun 10, 2020 07:31 AM UTC by János Kis
> *Last Updated:* Wed Jun 10, 2020 07:31 AM UTC
> *Owner:* nobody
> *Attachments:*
>
>- mapcolorstrings_hu.properties
>
> 
>(347 Bytes; text/plain)
>
> When I starting the Openjump, I got the next message always:
>
> [ERROR] ... Can't find bundle for base name 
> /org/freevoice/mapcoloring/mapcolorstrings, locale hu_HU
>
> So I have prepared a "mapcolorstrings_hu.properties" file and I put into
> my ojmapcoloring-0.5.jar.
> It works so it would by nice to add it to "official release".
>
> *Important: the file must be have ISO8859-2 codepage*
> --
>
> Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net
> is subscribed to https://sourceforge.net/p/jump-pilot/feature-requests/
>
> To unsubscribe from further messages, a project admin can change settings
> at https://sourceforge.net/p/jump-pilot/admin/feature-requests/options.
> Or, if this is a mailing list, you can unsubscribe from the mailing list.
> ___
> 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] CAD plugin. Add new library (as depency)

[Giuseppe Aruta]

OK

2020-06-08 13:50 GMT+02:00, edgar.sol...@web.de :
> yeah, it's a little more complex. your way is fine as well. maybe you should
> point out where the developer can find/download the needed jar file?!.. ede
>
> On 08.06.2020 13:31, Giuseppe Aruta wrote:
>> Hi Ede, I tried in this way but it doesn't work for me. I had a some
>> exceptions even within try/catch blocks.
>> I will use the option to save a howto_compile.txt file into src folder
>> Peppe
>>
>> Il giorno gio 4 giu 2020 alle ore 12:05 > <mailto:edgar.sol...@web.de>> ha scritto:
>>
>> On 04.06.2020 10:19, Giuseppe Aruta wrote:
>> > Indeed I was planning this way: from user's point of view there is
>> no difference.
>>
>> yup. exactly my point.
>>
>> > On the other hand, I was thinking about developers who have a
>> project in their eclipse connected to svn (or not) and have a warning that
>> a library is missing whenever they want to compile (right now, a very rare
>> situation)
>>
>> this would be solved via reflection meaning instantiating classes from
>> a string name and running methods derived from string names as well e.g.
>> like
>>
>>
>> https://stackoverflow.com/questions/3574065/instantiate-a-class-object-with-constructor-that-accepts-a-string-parameter
>>
>> https://stackoverflow.com/questions/1782598/with-java-reflection-how-to-instantiate-a-new-object-then-call-a-method-on-it
>>
>> so in your case (just written, down not compiled) roughly
>>
>> Class cl = Class.forName("com.cadplan.jump.utils.LoadSymbolFiles");
>> // find constructor with the context argument
>> Constructor cons = cl.getConstructor(WorkbenchContext.class);
>> // this is your instance
>> Object o = cons.newInstance(context);
>> // find & run the method
>> Method method = cl.getDeclaredMethod("start");
>> method.invoke(o);
>>
>> this way the classes accessed do not have to be present during compile
>> but only during runtime. this may throw a lot of exceptions, so make sure
>> to catch them properly, easiest with one catches all.
>>
>> > I can add a readme text file on SVN>CAD plugin>dist folder
>> explaining that VertexSymbol.jar library is required to compile
>>
>> better put a howto_compile.txt or such in the src folder ;) where devs
>> will stumble over it.
>>
>> > Best regards
>> > Peppe
>>
>> ditto.. sunny regards from rainy germany, ede
>>
>> >
>> >
>> > Il giorno mer 3 giu 2020 alle ore 22:20 > <mailto:edgar.sol...@web.de> <mailto:edgar.sol...@web.de
>> <mailto:edgar.sol...@web.de>>> ha scritto:
>> >
>> >     On 03.06.2020 17:32, Giuseppe Aruta wrote:
>> >     > Hi all,
>> >     > I want to add VertexSymbolsXXX.jar as depency to CAD plugin.
>> >     > This is the reason:
>> >     > Currently, whenever the user saves a new block (CAD
>> toolbar>Block>Save
>> >     > geometry as block) as file, this can be used also as a
>> point/line symbol
>> >     > for styling. But, to do that, the user needs to close/restart
>> again OJ.
>> >     > Adding this dependency and using a few lines of code, a new
>> block will be
>> >     > automatically available as a symbol without restarting
>> OpenJUMP.
>> >     > I would like your opinion before to to this change
>> >
>> >     could you explain why you want to make it a dependency rather
>> than just detecting if the other extension is installed and run some code
>> only when it is detected?
>> >
>> >     ..ede
>> >
>> >
>> >     ___
>> >     Jump-pilot-devel mailing list
>> >     Jump-pilot-devel@lists.sourceforge.net
>> <mailto:Jump-pilot-devel@lists.sourceforge.net>
>> <mailto:Jump-pilot-devel@lists.sourceforge.net
>> <mailto: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
>> <mailto:Jump-pilot-devel@lists.sourceforge.net>
>> > https://lists.sourceforge.net/lists

Re: [JPP-Devel] CAD plugin. Add new library (as depency)

[Giuseppe Aruta]

Hi Ede, I tried in this way but it doesn't work for me. I had a some
exceptions even within try/catch blocks.
I will use the option to save a howto_compile.txt file into src folder
Peppe

Il giorno gio 4 giu 2020 alle ore 12:05  ha scritto:

> On 04.06.2020 10:19, Giuseppe Aruta wrote:
> > Indeed I was planning this way: from user's point of view there is no
> difference.
>
> yup. exactly my point.
>
> > On the other hand, I was thinking about developers who have a project in
> their eclipse connected to svn (or not) and have a warning that a library
> is missing whenever they want to compile (right now, a very rare situation)
>
> this would be solved via reflection meaning instantiating classes from a
> string name and running methods derived from string names as well e.g. like
>
>
> https://stackoverflow.com/questions/3574065/instantiate-a-class-object-with-constructor-that-accepts-a-string-parameter
>
> https://stackoverflow.com/questions/1782598/with-java-reflection-how-to-instantiate-a-new-object-then-call-a-method-on-it
>
> so in your case (just written, down not compiled) roughly
>
> Class cl = Class.forName("com.cadplan.jump.utils.LoadSymbolFiles");
> // find constructor with the context argument
> Constructor cons = cl.getConstructor(WorkbenchContext.class);
> // this is your instance
> Object o = cons.newInstance(context);
> // find & run the method
> Method method = cl.getDeclaredMethod("start");
> method.invoke(o);
>
> this way the classes accessed do not have to be present during compile but
> only during runtime. this may throw a lot of exceptions, so make sure to
> catch them properly, easiest with one catches all.
>
> > I can add a readme text file on SVN>CAD plugin>dist folder explaining
> that VertexSymbol.jar library is required to compile
>
> better put a howto_compile.txt or such in the src folder ;) where devs
> will stumble over it.
>
> > Best regards
> > Peppe
>
> ditto.. sunny regards from rainy germany, ede
>
> >
> >
> > Il giorno mer 3 giu 2020 alle ore 22:20  edgar.sol...@web.de>> ha scritto:
> >
> > On 03.06.2020 17:32, Giuseppe Aruta wrote:
> > > Hi all,
> > > I want to add VertexSymbolsXXX.jar as depency to CAD plugin.
> > > This is the reason:
> > > Currently, whenever the user saves a new block (CAD
> toolbar>Block>Save
> > > geometry as block) as file, this can be used also as a point/line
> symbol
> > > for styling. But, to do that, the user needs to close/restart
> again OJ.
> > > Adding this dependency and using a few lines of code, a new block
> will be
> > > automatically available as a symbol without restarting OpenJUMP.
> > > I would like your opinion before to to this change
> >
> > could you explain why you want to make it a dependency rather than
> just detecting if the other extension is installed and run some code only
> when it is detected?
> >
> > ..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
> > 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] CAD plugin. Add new library (as depency)

[Giuseppe Aruta]

OK. I found a solution. No dependency required. Thank Ede
Peppe

Il giorno gio 4 giu 2020 alle ore 10:19 Giuseppe Aruta <
giuseppe.ar...@gmail.com> ha scritto:

> Indeed I was planning this way: from user's point of view there is no
> difference.
> On the other hand, I was thinking about developers who have a project in
> their eclipse connected to svn (or not) and have a warning that a library
> is missing whenever they want to compile (right now, a very rare situation)
> I can add a readme text file on SVN>CAD plugin>dist folder explaining that
> VertexSymbol.jar library is required to compile
> Best regards
> Peppe
>
>
> Il giorno mer 3 giu 2020 alle ore 22:20  ha scritto:
>
>> On 03.06.2020 17:32, Giuseppe Aruta wrote:
>> > Hi all,
>> > I want to add VertexSymbolsXXX.jar as depency to CAD plugin.
>> > This is the reason:
>> > Currently, whenever the user saves a new block (CAD toolbar>Block>Save
>> > geometry as block) as file, this can be used also as a point/line symbol
>> > for styling. But, to do that, the user needs to close/restart again OJ.
>> > Adding this dependency and using a few lines of code, a new block will
>> be
>> > automatically available as a symbol without restarting OpenJUMP.
>> > I would like your opinion before to to this change
>>
>> could you explain why you want to make it a dependency rather than just
>> detecting if the other extension is installed and run some code only when
>> it is detected?
>>
>> ..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] CAD plugin. Add new library (as depency)

[Giuseppe Aruta]

Indeed I was planning this way: from user's point of view there is no
difference.
On the other hand, I was thinking about developers who have a project in
their eclipse connected to svn (or not) and have a warning that a library
is missing whenever they want to compile (right now, a very rare situation)
I can add a readme text file on SVN>CAD plugin>dist folder explaining that
VertexSymbol.jar library is required to compile
Best regards
Peppe


Il giorno mer 3 giu 2020 alle ore 22:20  ha scritto:

> On 03.06.2020 17:32, Giuseppe Aruta wrote:
> > Hi all,
> > I want to add VertexSymbolsXXX.jar as depency to CAD plugin.
> > This is the reason:
> > Currently, whenever the user saves a new block (CAD toolbar>Block>Save
> > geometry as block) as file, this can be used also as a point/line symbol
> > for styling. But, to do that, the user needs to close/restart again OJ.
> > Adding this dependency and using a few lines of code, a new block will be
> > automatically available as a symbol without restarting OpenJUMP.
> > I would like your opinion before to to this change
>
> could you explain why you want to make it a dependency rather than just
> detecting if the other extension is installed and run some code only when
> it is detected?
>
> ..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

[JPP-Devel] CAD plugin. Add new library (as depency)

[Giuseppe Aruta]

Hi all,
I want to add VertexSymbolsXXX.jar as depency to CAD plugin.
This is the reason:
Currently, whenever the user saves a new block (CAD toolbar>Block>Save
geometry as block) as file, this can be used also as a point/line symbol
for styling. But, to do that, the user needs to close/restart again OJ.
Adding this dependency and using a few lines of code, a new block will be
automatically available as a symbol without restarting OpenJUMP.
I would like your opinion before to to this change
Best regards
Peppe
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] Updated VertexSymbols plugin

[Giuseppe Aruta]

Hi all OpenJumpers,
for the up-to-come OpenJUMP NB I updated Geoff's VertexSymbols plugin to
version 0.20.
This new version extends OpenJUMP style capabilities on vertex and
Linestrings.
These are the main aspects:

   - Extended capability of the plugin to feature classification by
   attribute value.
   - Added capability to style linestrings with symbols at user-defined
   distance between each other, offset to the line, and rotation according
   line (segments) orientation

Other aspects of this new realize are:

   - better visual and command organization
   - improved panels and GUI
   - activated capability to read/use pure WKT files as symbols (already
   embedded by Geoff)
   - integration with some basic style parameters (line/fill colors, global
   transparency,..)

Regarding development, I rewrite some parts of the original code in order
to use more OpenJUMP libraries omologate to OpenJUMP  structure.
In a few days (I hope) I will upgrade also user documentation about the
plugin.

Note that there must be some code break between previous version of
VertexSymbols plugin and this new one. So the compatibility between the two
version of the plugin is not garanteeded 100%. Test are still under
development

Best regards

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