Re: [JPP-Devel] OpenJUMP extensions migration - Cad Tools

[Giuseppe Aruta]

there are still some deprecated classes from JTS, for instance
LineString.clone in es.kosmo.desktop.tools.algorithms.bezierCurve class.
I need to find a way to find all these deprecated classes into the code in
one time
Peppe

Il giorno gio 29 apr 2021 alle ore 06:57 Giuseppe Aruta <
giuseppe.ar...@gmail.com> ha scritto:

> I decided to remove the Jython start up from CAD plugin.
> I added it only  to have an "easy" access to align tools, which are
> available opening a python console, anyhow. I will activate them again or
> find a pure java solution in the future (maybe).
> The new code of Cad plugin is available here, recompiled also substituting
> deprecated JTS classes
> https://sourceforge.net/projects/opensit/files/Openjump/CadTools/
> Peppe
>
> Il giorno mer 28 apr 2021 alle ore 18:15 Giuseppe Aruta <
> giuseppe.ar...@gmail.com> ha scritto:
>
>> I recompiled CAD tools substituting deprecated components with newer JTS
>> 1.8 one.
>> Everything seems to work fine except Python tools.
>> The problem is connected to classes AlignSelected$py.class and
>> UnionSelected$py.class located into OJ\ib/ext/jython.
>> The problem is that we don't have the original code of these classes, or
>> I was not able to find them into OJ repository.
>> I opened AlignSelected$py.class with a Java decompiler and might work to
>> rebuild it but It would be preferred if Larry could provide a copy of the
>> code.
>> Peppe
>>
>> Il giorno mer 28 apr 2021 alle ore 07:11 Giuseppe Aruta <
>> giuseppe.ar...@gmail.com> ha scritto:
>>
>>> Hi Michael,
>>> this is a start of migration of CadTools to JTS 1,18:
>>>
>>> https://sourceforge.net/projects/opensit/files/Openjump/CadTools/
>>>
>>> There are still some issue that I did not solved:
>>> a) Plugin still uses ToolboxPlugIn class which is deprecated
>>> (org.openjump.advancedtools.EditToolboxCADPlugIn)
>>> b) tools use some jts class which seems to be deprecated
>>> (org.locationtech.jts.algorithm.CGAlgorithms)
>>> c) Draw parallel line uses a Udig class
>>> (es.axios.udig.ui.editingtools.precisionparallels.internal.OffsetBuilder)
>>> embedded into CAD plugin.
>>> this class uses deprecated JTS classes which seems not used anymore
>>> (CentralEndpointIntersector). I left the class as it is as I feel that we
>>> can remove it and try to use your implementation in OffsetCurvePlugIn plugin
>>>
>>> Last year I did some modification in CAD plugin:
>>> - I added a dependency to VertexSymbols cadplan plugin:
>>> a) Cad tools can save geometries as Blocks
>>> b) blocks are saved into the same folder of vertexSymbols
>>> c) in the same session of OJ, users can use these blocks as vertex
>>> symbology
>>>
>>> - Cad plugin starts a session of Python, in order to activate all nice
>>> Larry python tools like the  align ones
>>>
>>> Peppe
>>>
>>> Il giorno dom 18 apr 2021 alle ore 22:44 Michaud Michael <
>>> m.michael.mich...@orange.fr> ha scritto:
>>>
>>>> Hi Jumpers,
>>>>
>>>> Some news about the migration :
>>>>
>>>> I have refactored most extensions included in OpenJUMP PLUS and
>>>> included them in the distribution (r4834). The work is still on-going but I
>>>> wanted to let you know so that you can begin to test and report any problem
>>>> (using the list or the github issue tracker) :
>>>>
>>>> https://sourceforge.net/projects/jump-pilot/files/OpenJUMP2_snapshots/
>>>>
>>>> Extensions which are supposed to be included are listed in the readme
>>>> on
>>>>
>>>> https://github.com/openjump-gis/openjump
>>>>
>>>> All of them have been uploaded to openjump-gis group and mavenized.
>>>>
>>>> I want to include some more extensions like color-chooser or
>>>> concave-hull, but for extensions which were not included in OJ-1.16-PLUS,
>>>> maybe I'll wait for someone to ask.
>>>>
>>>> For database, I'd like to avoid maintaining dbquery if the same work
>>>> can be achieved with openjump datastore framework. Maybe jukka or someone
>>>> else know better than me what dbquery can actually achieve which cannot be
>>>> done with the main framework.
>>>>
>>>>
>>>> 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] OpenJUMP extensions migration - Cad Tools

[Giuseppe Aruta]

I decided to remove the Jython start up from CAD plugin.
I added it only  to have an "easy" access to align tools, which are
available opening a python console, anyhow. I will activate them again or
find a pure java solution in the future (maybe).
The new code of Cad plugin is available here, recompiled also substituting
deprecated JTS classes
https://sourceforge.net/projects/opensit/files/Openjump/CadTools/
Peppe

Il giorno mer 28 apr 2021 alle ore 18:15 Giuseppe Aruta <
giuseppe.ar...@gmail.com> ha scritto:

> I recompiled CAD tools substituting deprecated components with newer JTS
> 1.8 one.
> Everything seems to work fine except Python tools.
> The problem is connected to classes AlignSelected$py.class and
> UnionSelected$py.class located into OJ\ib/ext/jython.
> The problem is that we don't have the original code of these classes, or I
> was not able to find them into OJ repository.
> I opened AlignSelected$py.class with a Java decompiler and might work to
> rebuild it but It would be preferred if Larry could provide a copy of the
> code.
> Peppe
>
> Il giorno mer 28 apr 2021 alle ore 07:11 Giuseppe Aruta <
> giuseppe.ar...@gmail.com> ha scritto:
>
>> Hi Michael,
>> this is a start of migration of CadTools to JTS 1,18:
>>
>> https://sourceforge.net/projects/opensit/files/Openjump/CadTools/
>>
>> There are still some issue that I did not solved:
>> a) Plugin still uses ToolboxPlugIn class which is deprecated
>> (org.openjump.advancedtools.EditToolboxCADPlugIn)
>> b) tools use some jts class which seems to be deprecated
>> (org.locationtech.jts.algorithm.CGAlgorithms)
>> c) Draw parallel line uses a Udig class
>> (es.axios.udig.ui.editingtools.precisionparallels.internal.OffsetBuilder)
>> embedded into CAD plugin.
>> this class uses deprecated JTS classes which seems not used anymore
>> (CentralEndpointIntersector). I left the class as it is as I feel that we
>> can remove it and try to use your implementation in OffsetCurvePlugIn plugin
>>
>> Last year I did some modification in CAD plugin:
>> - I added a dependency to VertexSymbols cadplan plugin:
>> a) Cad tools can save geometries as Blocks
>> b) blocks are saved into the same folder of vertexSymbols
>> c) in the same session of OJ, users can use these blocks as vertex
>> symbology
>>
>> - Cad plugin starts a session of Python, in order to activate all nice
>> Larry python tools like the  align ones
>>
>> Peppe
>>
>> Il giorno dom 18 apr 2021 alle ore 22:44 Michaud Michael <
>> m.michael.mich...@orange.fr> ha scritto:
>>
>>> Hi Jumpers,
>>>
>>> Some news about the migration :
>>>
>>> I have refactored most extensions included in OpenJUMP PLUS and included
>>> them in the distribution (r4834). The work is still on-going but I wanted
>>> to let you know so that you can begin to test and report any problem (using
>>> the list or the github issue tracker) :
>>>
>>> https://sourceforge.net/projects/jump-pilot/files/OpenJUMP2_snapshots/
>>>
>>> Extensions which are supposed to be included are listed in the readme on
>>>
>>> https://github.com/openjump-gis/openjump
>>>
>>> All of them have been uploaded to openjump-gis group and mavenized.
>>>
>>> I want to include some more extensions like color-chooser or
>>> concave-hull, but for extensions which were not included in OJ-1.16-PLUS,
>>> maybe I'll wait for someone to ask.
>>>
>>> For database, I'd like to avoid maintaining dbquery if the same work can
>>> be achieved with openjump datastore framework. Maybe jukka or someone else
>>> know better than me what dbquery can actually achieve which cannot be done
>>> with the main framework.
>>>
>>>
>>> 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] OpenJUMP extensions migration - Cad Tools

[Giuseppe Aruta]

I recompiled CAD tools substituting deprecated components with newer JTS
1.8 one.
Everything seems to work fine except Python tools.
The problem is connected to classes AlignSelected$py.class and
UnionSelected$py.class located into OJ\ib/ext/jython.
The problem is that we don't have the original code of these classes, or I
was not able to find them into OJ repository.
I opened AlignSelected$py.class with a Java decompiler and might work to
rebuild it but It would be preferred if Larry could provide a copy of the
code.
Peppe

Il giorno mer 28 apr 2021 alle ore 07:11 Giuseppe Aruta <
giuseppe.ar...@gmail.com> ha scritto:

> Hi Michael,
> this is a start of migration of CadTools to JTS 1,18:
>
> https://sourceforge.net/projects/opensit/files/Openjump/CadTools/
>
> There are still some issue that I did not solved:
> a) Plugin still uses ToolboxPlugIn class which is deprecated
> (org.openjump.advancedtools.EditToolboxCADPlugIn)
> b) tools use some jts class which seems to be deprecated
> (org.locationtech.jts.algorithm.CGAlgorithms)
> c) Draw parallel line uses a Udig class
> (es.axios.udig.ui.editingtools.precisionparallels.internal.OffsetBuilder)
> embedded into CAD plugin.
> this class uses deprecated JTS classes which seems not used anymore
> (CentralEndpointIntersector). I left the class as it is as I feel that we
> can remove it and try to use your implementation in OffsetCurvePlugIn plugin
>
> Last year I did some modification in CAD plugin:
> - I added a dependency to VertexSymbols cadplan plugin:
> a) Cad tools can save geometries as Blocks
> b) blocks are saved into the same folder of vertexSymbols
> c) in the same session of OJ, users can use these blocks as vertex
> symbology
>
> - Cad plugin starts a session of Python, in order to activate all nice
> Larry python tools like the  align ones
>
> Peppe
>
> Il giorno dom 18 apr 2021 alle ore 22:44 Michaud Michael <
> m.michael.mich...@orange.fr> ha scritto:
>
>> Hi Jumpers,
>>
>> Some news about the migration :
>>
>> I have refactored most extensions included in OpenJUMP PLUS and included
>> them in the distribution (r4834). The work is still on-going but I wanted
>> to let you know so that you can begin to test and report any problem (using
>> the list or the github issue tracker) :
>>
>> https://sourceforge.net/projects/jump-pilot/files/OpenJUMP2_snapshots/
>>
>> Extensions which are supposed to be included are listed in the readme on
>>
>> https://github.com/openjump-gis/openjump
>>
>> All of them have been uploaded to openjump-gis group and mavenized.
>>
>> I want to include some more extensions like color-chooser or
>> concave-hull, but for extensions which were not included in OJ-1.16-PLUS,
>> maybe I'll wait for someone to ask.
>>
>> For database, I'd like to avoid maintaining dbquery if the same work can
>> be achieved with openjump datastore framework. Maybe jukka or someone else
>> know better than me what dbquery can actually achieve which cannot be done
>> with the main framework.
>>
>>
>> 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] OpenJUMP extensions migration - Cad Tools

[Giuseppe Aruta]

Hi Michael,
this is a start of migration of CadTools to JTS 1,18:

https://sourceforge.net/projects/opensit/files/Openjump/CadTools/

There are still some issue that I did not solved:
a) Plugin still uses ToolboxPlugIn class which is deprecated
(org.openjump.advancedtools.EditToolboxCADPlugIn)
b) tools use some jts class which seems to be deprecated
(org.locationtech.jts.algorithm.CGAlgorithms)
c) Draw parallel line uses a Udig class
(es.axios.udig.ui.editingtools.precisionparallels.internal.OffsetBuilder)
embedded into CAD plugin.
this class uses deprecated JTS classes which seems not used anymore
(CentralEndpointIntersector). I left the class as it is as I feel that we
can remove it and try to use your implementation in OffsetCurvePlugIn plugin

Last year I did some modification in CAD plugin:
- I added a dependency to VertexSymbols cadplan plugin:
a) Cad tools can save geometries as Blocks
b) blocks are saved into the same folder of vertexSymbols
c) in the same session of OJ, users can use these blocks as vertex symbology

- Cad plugin starts a session of Python, in order to activate all nice
Larry python tools like the  align ones

Peppe

Il giorno dom 18 apr 2021 alle ore 22:44 Michaud Michael <
m.michael.mich...@orange.fr> ha scritto:

> Hi Jumpers,
>
> Some news about the migration :
>
> I have refactored most extensions included in OpenJUMP PLUS and included
> them in the distribution (r4834). The work is still on-going but I wanted
> to let you know so that you can begin to test and report any problem (using
> the list or the github issue tracker) :
>
> https://sourceforge.net/projects/jump-pilot/files/OpenJUMP2_snapshots/
>
> Extensions which are supposed to be included are listed in the readme on
>
> https://github.com/openjump-gis/openjump
>
> All of them have been uploaded to openjump-gis group and mavenized.
>
> I want to include some more extensions like color-chooser or concave-hull,
> but for extensions which were not included in OJ-1.16-PLUS, maybe I'll wait
> for someone to ask.
>
> For database, I'd like to avoid maintaining dbquery if the same work can
> be achieved with openjump datastore framework. Maybe jukka or someone else
> know better than me what dbquery can actually achieve which cannot be done
> with the main framework.
>
>
> 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] OpenJUMP extensions migration

[giuseppe . aruta]

Thanks Michael,
About other plugins:
I am going to upgrade CAD plugin. In the last version I added a depency to 
Cadplan vertex symbols plugin (cad tool saves a selected geometry as block 
which in turn can be used as point/line symbology.
I hope I will have a working plugin by the end of this week.
Peppe
--
Inviato da myMail per Android domenica, 18 aprile 2021, 10:44PM +02:00 da 
Michaud Michael  m.michael.mich...@orange.fr :

>Hi Jumpers,
>Some news about the migration :
>I have refactored most extensions included in OpenJUMP PLUS and included them 
>in the distribution (r4834). The work is still on-going but I wanted to let 
>you know so that you can begin to test and report any problem (using the list 
>or the github issue tracker) :
>https://sourceforge.net/projects/jump-pilot/files/OpenJUMP2_snapshots/
>Extensions which are supposed to be included are listed in the readme on 
>https://github.com/openjump-gis/openjump
>All of them have been uploaded to openjump-gis group and mavenized.
>I want to include some more extensions like color-chooser or concave-hull, but 
>for extensions which were not included in OJ-1.16-PLUS, maybe I'll wait for 
>someone to ask.
>For database, I'd like to avoid maintaining dbquery if the same work can be 
>achieved with openjump datastore framework. Maybe jukka or someone else know 
>better than me what dbquery can actually achieve which cannot be done with the 
>main framework. 
>
>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] OpenKlem

[Giuseppe Aruta]

Hi MIchael,
excuse me for my late answer. I agree with your proposal (splitting into
modules, group name etc...). You can pack it into OpenJUMP plus.
It is quite difficult for me to take time for GitHub. I think I will use
the time I have mainly to test the plugins. By the time you move OpenKLEM
into OpenJUMP I will start a set of tests on both Sextante and OpenKLEM and
report on a text which can be used in the future.
thanks again
Peppe


Il giorno dom 11 apr 2021 alle ore 12:36 Michaud Michael <
m.michael.mich...@orange.fr> ha scritto:

> Hi Peppe,
>
> I uploaded OpenKLEM. Here is what I did :
>
> - split the code into 3 modules. See
>
> https://github.com/openjump-gis/openklem-extension
>
> - to do this split and keep minimal dependencies. I had to move one class
> (Vectorizer) from the algo package to the openjump package as it depended
> on OpenJUMP classes.
>
> - I also removed commons-io dependency from openklem-openjump as it is
> just used for FileUtils.getExtension which is also available in OpenJUMP. I
> updated other dependencies as much as possible.
>
> - I mavenized the project and the modules. I used the same group id as for
> OpenJUMP. This is just a proposition as it is seems that there is no code
> in the central maven repository for klem/openklem (for Sextante, I kept the
> group id of sextante which already existed).
>
> - if you get a bit more familiar with maven, you should be able to use
> your IDE to choose a target and perform compilation, packaging or
> installation of the three modules in one click. Let me know if it does not
> work.
>
> - if you are ok with the general ideas (splitting into modules, group name
> etc...), I'll change the version number to 2 and include jar files and
> dependencies into OpenJUMP PLUS. Let me know.
>
> - I also did some cleaning in the code, generally following
> recommandations from my IDE. Hope I did not break anything.
>
> If you had other ideas to manage the code, let me know. I tried to package
> it to have something usable, but you will use it more than me, so you must
> be comfortable with it too.
>
> I thing that next week, I'll start to include extensions I already
> migrated into the main project to be able to have a compiled PLUS distro
> and to ease tests.
>
> 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] Java errors with OJ2

[giuseppe . aruta]

Hi Michael, do we have a build of OJ 2 core? Where can I download it? I made a 
version for my tests which I modified in order to work with JTS 1.18 but I it 
is quite out if date comparing to GitHub code.
Thanks
Peppe
--
Inviato da myMail per Android giovedì, 08 aprile 2021, 04:16PM +02:00 da 
Michaud Michael  m.michael.mich...@orange.fr :

>Hi Jukka,
>Thanks for the test.
>All your errors come from extensions that have not been migrated yet.
>OpenJUMP-Core should work and you're welcome to report any error from 
>OpenJUMP2-Core in the issue tracker.
>For extensions included in OpenJUMP-PLUS (or not included), the work is on 
>going. I added a list of the extensions which have been migrated in the 
>README, but event these extensions are not automatically included in the 
>OpenJUMP2-PLUS build.
>I'd like to migrate some more extensions, then we'll upgrade the OpenJUMP 2 - 
>PLUS build to include only the migrated extensions.
>Michaël
>
>>envoyé : 8 avril 2021 à 15:24
>>de : "Rahkonen Jukka (MML)" 
>>à : "jump-pilot-devel@lists.sourceforge.net" 
>>objet : [JPP-Devel] Java errors with OJ2
>>Hi,
>> 
>>I had a try with a new OpenJUMP 2 snapshot on Windows and with JRE 8 and 11.  
>>OJ starts but with a bunch of error messages. I wonder it is safe to do any 
>>real work with OJ 2 or should I use it only for testing. The errors look like 
>>this:
>>
>>java.lang.NoClassDefFoundError: com/vividsolutions/jts/io/ParseException
>>  at 
>>com.cadplan.jump.plugins.StylerMenuPlugIn.initialize(StylerMenuPlugIn.java:51)
>>  at 
>>com.cadplan.jump.VertexSymbolsExtension.configure(VertexSymbolsExtension.java:10)
>>  at 
>>com.vividsolutions.jump.workbench.plugin.PlugInManager.loadConfigurations(PlugInManager.java:209)
>>  at 
>>com.vividsolutions.jump.workbench.plugin.PlugInManager.load(PlugInManager.java:189)
>>  at 
>>com.vividsolutions.jump.workbench.JUMPWorkbench.main(JUMPWorkbench.java:449)
>>  at 
>>com.vividsolutions.jump.workbench.JUMPWorkbench.main(JUMPWorkbench.java:384)
>> 
>> 
>> 
>>java.lang.NoClassDefFoundError: com/vividsolutions/jts/index/SpatialIndex
>>  at 
>>fr.michaelm.jump.plugin.topology.TopologyExtension.configure(TopologyExtension.java:91)
>>  at 
>>com.vividsolutions.jump.workbench.plugin.PlugInManager.loadConfigurations(PlugInManager.java:209)
>>  at 
>>com.vividsolutions.jump.workbench.plugin.PlugInManager.load(PlugInManager.java:189)
>>  at 
>>com.vividsolutions.jump.workbench.JUMPWorkbench.main(JUMPWorkbench.java:449)
>>  at 
>>com.vividsolutions.jump.workbench.JUMPWorkbench.main(JUMPWorkbench.java:384)
>> 
>> 
>>java.lang.NoSuchMethodError: 
>>com.vividsolutions.jump.workbench.registry.Registry.createEntry(Ljava/lang/Object;Ljava/lang/Object;)Lcom/vividsolutions/jump/workbench/registry/Registry;
>>  at 
>>org.openjump.core.ui.plugin.file.osm.OsmDriverConfiguration.configure(OsmDriverConfiguration.java:63)
>>  at 
>>com.vividsolutions.jump.workbench.plugin.PlugInManager.loadConfigurations(PlugInManager.java:209)
>>  at 
>>com.vividsolutions.jump.workbench.plugin.PlugInManager.load(PlugInManager.java:189)
>>  at 
>>com.vividsolutions.jump.workbench.JUMPWorkbench.main(JUMPWorkbench.java:449)
>>  at 
>>com.vividsolutions.jump.workbench.JUMPWorkbench.main(JUMPWorkbench.java:384)
>> 
>>java.lang.NoClassDefFoundError: com/vividsolutions/jts/geom/Geometry
>>  at java.lang.Class.forName0(Native Method)
>>  at java.lang.Class.forName(Class.java:264)
>>  at 
>>es.unex.sextante.core.Sextante.loadLibraryAlgorithms(Sextante.java:372)
>>  at 
>>es.unex.sextante.core.Sextante.initialize(Sextante.java:74)
>>  at 
>>es.unex.sextante.openjump.extensions.SextanteToolboxPlugin.initialize(SextanteToolboxPlugin.java:76)
>>  at 
>>es.unex.sextante.openjump.extensions.SextanteExtension.configure(SextanteExtension.java:52)
>>  at 
>>com.vividsolutions.jump.workbench.plugin.PlugInManager.loadConfigurations(PlugInManager.java:209)
>>  at 
>>com.vividsolutions.jump.workbench.plugin.PlugInManager.load(PlugInManager.java:189)
>>  at 
>>com.vividsolutions.jump.workbench.JUMPWorkbench.main(JUMPWorkbench.java:449)
>>  at 
>>com.vividsolutions.jump.workbench.JUMPWorkbench.main(JUMPWorkbench.java:384)
>> 
>>java.lang.NoClassDefFoundError: com/vividsolutions/jts/geom/CoordinateFilter
>>  at com.isa.

Re: [JPP-Devel] OJ2 and Sextante

[Giuseppe Aruta]

Hi Michael

>I could not find the help directory in the 4 jar you sent me. I found it
in previous repository but I did not commit it yet. I suppose it should be
added to sextante-gui.jar.
The help files (mostly html type) are all located into a separate folder:
OJ/lib/ext/sextante/help.
There is no need to modify the sextante-gui.jar to read them. Sextante
offers also the possibility to "modify" the using the Sextante/help plugin.

>In the previous code, there was a sextante_new_algorithms_20200817.jar.
I did not check if it is included in the sextante-algorithms you sent me or
if I should do.
The only essential modifications I did were on two plugins: a) Rasterize a
vector in order to solve a very rare bug that was creating "islands" of
nodata. b) Remove pits which was not properly working in OpenJUMP. They
should be already upgraded to the version I sent

> I have still the following error at start (did not find where it comes
from)

Modeler plugin. This plugin has never worked well in OpenJUMP.  In the
forts versions of OJ it was deactivated by default. I activated it possibly
3 or 4 years ago in order to have some reports from users: you are the
first one! I think we can deactivate it again without remorse. (and I think I'm
the one who has used sextante most frequently in the last 10 years)

Peppe

Il giorno lun 29 mar 2021 alle ore 20:00 Michaud Michael <
m.michael.mich...@orange.fr> ha scritto:

> Hi Peppe,
>
> Hope you're fine.
>
> I mavenized Sextante and could compile it against OpenJUMP 2. I did not
> really test it though.
>
> I have still a few questions for you as you know Sextante better than I do
> :
>
> - I could not find the help directory in the 4 jar you sent me. I found it
> in previous repository but I did not commit it yet. I suppose it should be
> added to sextante-gui.jar.
>
> - In the previous code, there was a sextante_new_algorithms_20200817.jar.
> I did not check if it is included in the sextante-algorithms you sent me or
> if I should do.
>
> - I have still the following error at start (did not find where it comes
> from)
>
> es.unex.sextante.gui.exceptions.ModelIOException
> at
> es.unex.sextante.gui.modeler.ModelAlgorithmIO.open(ModelAlgorithmIO.java:283)
> at
> es.unex.sextante.gui.modeler.ModelAlgorithmIO.loadModelsAsAlgorithms(ModelAlgorithmIO.java:582)
> at
> es.unex.sextante.gui.modeler.ModelerAlgorithmProvider.initialize(ModelerAlgorithmProvider.java:71)
> 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:84)
> at
> es.unex.sextante.openjump.extensions.SextanteExtension.configure(SextanteExtension.java:52)
> at
> com.vividsolutions.jump.workbench.plugin.PlugInManager.loadConfigurations(PlugInManager.java:209)
> at
> com.vividsolutions.jump.workbench.plugin.PlugInManager.load(PlugInManager.java:189)
> at
> com.vividsolutions.jump.workbench.JUMPWorkbench.main(JUMPWorkbench.java:449)
> at
> com.vividsolutions.jump.workbench.JUMPWorkbench.main(JUMPWorkbench.java:384)
>
>
> Regards,
>
> 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] Sextante dependencies

[Giuseppe Aruta]

Hi Michael,
excuse me for the late answer: my school is in lock down since a couple of
weeks and it seems that working at home takes more time that working in the
classroom.

About Sextante
The original files to recompile are four:
sextante.jar,
sextante-gui.jar,
libMath.jar
sextante-algs.jar.

They are all related to each other with a sort of hierarchy dependency.
*In our distro here is also a sextante-new-algorithms.jar file that I
developed to integrate into Sextante my corrections to Sextante algorithm
which were not working (see later). *

Original source code
We have no code for our version of Sextante. II don't even know which
version we use: possibly version 1.00 or version 0.7
The more closest version of Sextante, that Victor Oyala (source code)
available on web is here: https://code.google.com/archive/p/sextante/
It has a MIT licence. This version is numbered 1.01.


Dependency
I recompile all the four jars to JTS 1.17-JTS 1.18 , solving also some
annoying bugs on Sextante and OpenJUMP.

The dependency for each jar is the following (in red jars in OJ core, blue
jars in OJ/lib/ext folder, in black jars in OJ/lib/ext/sextante folder

libMath.jar:   jama-1.0.2.jar, jts-core-1.18.1.jar, jts-io-common-1.18.1.jar,
trove-0.1.8.jar

sextante.jar: jts-core-1.18.1.jar, jts-io-common-1.18.1.jar,
jcommon-1.0.14.jar, jfreechart-1.0.11.jar, libMath.jar, kxml2.jar

sextante-gui.jar: jts-core-1.18.1.jar, jts-io-common-1.18.1.jar,
bsh-2.0b6.jar, TableLayout-bin-jdk1.5-2007-04-21.jar, sextante.jar,
kxml2.jar, japura-1.14.0.jar, jgraph.jar, jcommon-1.0.14.jar,
jfreechart-1.0.11.jar

sextante-algorithm: gishur_x.jar, gishur_core.jar, jama-1.0.2.jar,
japura-1.14.0.jar,jcommon-1.0.14.jar, jfreechart-1.0.11.jar, jep.jar,
jts-core-1.18.1.jar,
jts-io-common-1.18.1.jar,TableLayout-bin-jdk1.5-2007-04-21.jar,
sextante.jar, sextante-gui.jar

My Test:
I was able to recompile with no problems libMath.jar and sextante.jar and
sextante.algorithm.jar. I had some problems with sextante-gui.jar (export
was finalized with a warning of errors that I was not able to find.
Apparently everything went fine: recompiling, and launching Sextante via
GUI. But no algorithm was working. I did not investigate a lot about the
reason.

I have a project to substitute Sextante with a combination of OpenKLEM,
embedded raster plugin in OJ and a plugin I am developing. The reason is to
reuse embedded gui components and libraries of OpenJUMP base. I will give a
better detail in a new email

This is the folder where you can download jars and source codes of all four
sextante jar already recompiled with JTS 1.8
https://drive.google.com/drive/folders/1euXimnt1-RTO5Kkv7Ybt3uMPHTBQdInn?usp=sharing

Peppe



Il giorno mer 17 mar 2021 alle ore 18:50 Michaud Michael <
m.michael.mich...@orange.fr> ha scritto:

> Hi Peppe,
>
> I'd like to upload Sextante plugin into our new repo to test it against
> OpenJUMP 2, but our sourceforge repo include the two dependencies
> sextante.jar and sextante-gui.jar as compiled jars.
>
> Do you know if we have the source code corresponding to these jar ?
>
> By the way, did you progress with eclipse and the new repo ?
>
> 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] Fwd: Re: OJ 2.x Was:Re: JTS update: first experiments

[Giuseppe Aruta]

Hi Michael,
Right in this moment I am writing an email to answer your previous email
with more details about my tests on recompiling Sextante. In few minutes I
will send it to you

Il giorno ven 19 mar 2021 alle ore 10:14 Michaud Michael <
m.michael.mich...@orange.fr> ha scritto:

> Hi Peppe,
>
> I found this mail dating from 2020, august 10th about Sextante migration.
>
> Can you tell me how far you have gone in your investigation/work about
> migrating Sextante. It seems to be a difficult but important part of our
> migration process. I'd like to upload all the necessary code in the new
> openjump-gis/sextante-extension project so that we can work together on
> this topic.
>
> Regards,
>
> Michaël
>
> *envoyé :* 10 août 2020 à 21:02
> *de :* Giuseppe Aruta 
> *à :* eric.openj...@thefactory.io, OpenJump develop and use <
> jump-pilot-devel@lists.sourceforge.net>
> *objet :* Re: [JPP-Devel] OJ 2.x Was:Re: JTS update: first experiments
>
> >>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 W

Re: [JPP-Devel] OpenJUMP build

[giuseppe . aruta]

Hi Michael
> I'm tempted to abandon the svn history of our plugins to make the migration 
>process easier. I would be more encline to clean and uniformize how extensions 
>are managed than to keep all the bits from the previous repo
I am not really expert about it.
Anyhow It makes sense to migrate only the last working source code of each 
plugins and not all the history. 
Peppe
--
Inviato da myMail per Android giovedì, 18 febbraio 2021, 07:20PM +01:00 da 
Michaud Michael  m.michael.mich...@orange.fr :

>
>Hi Ede, jumpers,
>It seems that the whole build process can be managed from github with github 
>actions.
>https://docs.github.com/en/actions
>https://docs.github.com/en/actions/guides/building-and-testing-java-with-maven
>Do you ever used that ?
>As you know how the build was done from Sourceforge repository, you may have 
>your opinion about how to migrate it to github.
>Let me know if you want to take care of it or if I should try to initiate 
>something with github tools.
>Also, I'm a bit concerned by this page stating that the storage limit for a 
>free account is 500MB which is already the size of our source repository
>https://docs.github.com/en/github/getting-started-with-github/githubs-products
>Also, do you know if a maven repo of OpenJUMP jar file already exists 
>somewhere. Did you ever do that ? I think that we should mavenize our 
>extensions, but it will be easier if there is an official repo for 
>openjump2.0, even if it is a very early 2.0-alpha release.
>Last point (for today) : I'm tempted to abandon the svn history of our plugins 
>to make the migration process easier. I would be more encline to clean and 
>uniformize how extensions are managed than to keep all the bits from the 
>previous repo. What do you think ?
>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] Important bug on class RasterImageLayer on OpenJUMP 6669

[Giuseppe Aruta]

Hi Michael
here you can find the test image flt that I used (both .flt and hdr files)
https://sourceforge.net/projects/opensit/files/Test%20file/Test%20raster/flt/
Best regards
Peppe

Il giorno dom 7 feb 2021 alle ore 11:55 Michaud Michael <
m.michael.mich...@orange.fr> ha scritto:

> Hi,
>
> Peppe, could you provide me an image throwing an exception. I tried with a
> floating point image from R. Rossi but it worked well. I'd like to be able
> to reproduce the error before fixing. Proposition from Ede makes sense but
> I'll first check if image/io offers a more robust method to evaluate the
> number of bpp.
>
> Michaël
>
>
>
> envoyé : 4 février 2021 à 12:22
> de : edgar.sol...@web.de
> à : jump-pilot-devel@lists.sourceforge.net
> objet : Re: [JPP-Devel] Important bug on class RasterImageLayer on
> OpenJUMP 6669
>
>
> looks like a test like
>
> http://commons.apache.org/proper/commons-imaging/apidocs/org/apache/commons/imaging/Imaging.html#getFormatCompliance-byte:A-
>
> before running Imaging.getImageInfo() might make sense. but it'll likely
> just throw an Exception as well. didn't test it.
>
> ..ede
>
> On 2/4/2021 11:57, edgar.sol...@web.de wrote:
>
> the commit by Mike seems to have simply added the call
> Imaging.getImageInfo()
> https://sourceforge.net/p/jump-pilot/code/6643/
>
> try to wrap it in try/catch and it should work again. or leave it up to
> Mike who fixed the memory routine ;).. ede
>
> ps. All - are we set on the github branch now? if yes i suggest to name it
> "devel" or "trunk" as "master" seems to be out of fashion and "main" is to
> generic for my taste.
>
> On 2/4/2021 6:53, Giuseppe Aruta wrote:
>
> >> Note that GridFloat (FLT) and GridAscii (ASC) classes have their own
> methods to read cell size, GridFloat(string filename).readHdr and than
> getCellSize().>>
> >> Il giorno gio 4 feb 2021 alle ore 06:48 Giuseppe Aruta <
> giuseppe.ar...@gmail.com <mailto:giuseppe.ar...@gmail.com>> ha scritto:
> >>
> >> Hi all,
> >> it seems that we lost the ability to read and display FLT and ASC
> raster files using (Sextante) raster image layer framework. The bug is
> located into class RasterImageLayer,
> >> line 352:
> >>  bitsPerPixel = Imaging.getImageInfo(new
> File(imageFileName)).getBitsPerPixel();
> >>
> >> The reason is that classorg.apache.commons.imaging.Imaging
> >> cannot read ASC and FLT files
> >>
> >> 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
>
> ___
> 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] Important bug on class RasterImageLayer on OpenJUMP 6669

[Giuseppe Aruta]

Note that GridFloat (FLT) and GridAscii (ASC) classes have their own
methods to read cell size, GridFloat(string filename).readHdr and than
getCellSize().

Il giorno gio 4 feb 2021 alle ore 06:48 Giuseppe Aruta <
giuseppe.ar...@gmail.com> ha scritto:

> Hi all,
> it seems that we lost the ability to read and display FLT and ASC raster
> files using (Sextante) raster image layer framework. The bug is located
> into class RasterImageLayer,
> line 352:
>  bitsPerPixel = Imaging.getImageInfo(new
> File(imageFileName)).getBitsPerPixel();
>
> The reason is that class org.apache.commons.imaging.Imaging
> cannot read ASC and FLT files
>
> 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] Important bug on class RasterImageLayer on OpenJUMP 6669

[Giuseppe Aruta]

Hi all,
it seems that we lost the ability to read and display FLT and ASC raster
files using (Sextante) raster image layer framework. The bug is located
into class RasterImageLayer,
line 352:
 bitsPerPixel = Imaging.getImageInfo(new
File(imageFileName)).getBitsPerPixel();

The reason is that class org.apache.commons.imaging.Imaging
cannot read ASC and FLT files

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

Re: [JPP-Devel] new year, new OJ?

[giuseppe . aruta]

Ready for 1.16
--
Inviato da myMail per Android mercoledì, 30 dicembre 2020, 02:51PM +01:00 da  
edgar.sol...@web.de :

>time to release OJ 1.16. any blockers? with some luck we might get it on 
>OSGeoLive as well.
>
>..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] Ready fo 1.16 ?

[giuseppe . aruta]

I Will check Spanish and Italian l'abbiate today too.
--
Inviato da myMail per Android lunedì, 21 dicembre 2020, 07:41AM +01:00 da 
Rahkonen Jukka (MML)  jukka.rahko...@maanmittauslaitos.fi :

>Hi,
> 
>I will check the Finnish language file today.
> 
>-Jukka Rahkonen-
> 
>Lähettäjä: Michaud Michael < m.michael.mich...@orange.fr>
>Lähetetty: sunnuntai 20. joulukuuta 2020 19.11
>Vastaanottaja: OpenJump develop and use < 
>jump-pilot-devel@lists.sourceforge.net>
>Aihe: [JPP-Devel] Ready fo 1.16 ?
> 
> 
>Hi Jumpers,
>Ready for the1.16 release ?
>I just clean up a bit the distro by removing 2 jar files : hamcrest (junit 
>dependency) and rhino:js (batik dependency). If you think they may be useful 
>in some cases, please, speak now..
>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] New project/new plugin

[Giuseppe Aruta]

Hi Erik,
thanks for your comment.
In reality, the colors of the interpolations are the result of Alberto de
Luca's work to have a good style system for rasters. I just added some LUTs
with more colors to make the rasters more aesthetically beautiful, "Juicy"
as you wrote ;-)

I am interested in your proposal regarding the TSP code. It could be a
great integration to the interpolation plugin. Let me know where you will
put your code. Of course I will extend the copyright to thank your
cooperation. I will move all the stuff on GitHub later.

This plugin was born as a test to recover useful code of projects destined
to be abandoned. John Lindsey, the author of the excellent WhiteBox GAT GIS
for raster in java, wrote to me days ago that he considers his project to
be legacy and is not interested in renewing it. In fact Whitebox Gat no
longer works with the new javas. Kosmo and AdbToolbox, interesting clones
of OpenJUMP, are practically abandoned. I have worked with these software
for years and I feel I need to recover at least some of their functionality
on OpenJUMP. Since the raster management material is large, I will probably
have work for years.

Thanks again

Peppe

Il giorno mer 2 dic 2020 alle ore 18:25 Eric 
ha scritto:

> Congratulations for these great results and these ports Peppe! I really
> like the colours of your raster interpolations -- they are quite refreshing
> / juicy :)
>
> I don't know if this would be of interest to you but I developed in the
> past a TPS (Thin Plate Spline) interpolation [1] in order to create contour
> lines (vector) from a layer of XYZ points/coordinates for example. I even
> developed a quick OJ plugin to visually test the results but I never
> released it. If you're interested to add this kind of interpolation, I
> could release the code in open source somewhere. It should be relatively
> straightforward to compute an image from it, as once the TPS parameters
> have been estimated, it's possible to compute any z value for a given (x,
> y), and therefore to attach this value to your GridExtent / Raster. Just
> let me know if are interested.
>
> Best,
> Eric
>
> On 02/12/2020 13:14, Giuseppe Aruta wrote:
>
> Greetings OpenJUMPs
> I started a new project to create an interpolation plugin for OpenJUMP
> The plugin takes scattered points loaded in OpenJUMP which have a xyz
> coordinates and transform them into a raster grid, as Sextante raster.
>
> OpenJUMP has already some interpolation plugins via Sextante toolbox
> (linear regression, Nearest Neighbor, IDW and some Krigings).
>
> My plugin tries to extend this capability reusing external codes from
> other projects which recently are "starving" of development: AdbToolbox, a
> clone of OpenJUMP, and the good WhiteBox GAT from John Lindsey.
>
> Note that, among the others, the TIN interpolation algorithm is my first
> try to port an imageJ plugin to OpenJUMP with a with unexpected and fast
> results: it required few modification to port and it is the faster and less
> memory-eater among the others
>
> You can find detail of my project and a link to download the plugin here:
> https://sourceforge.net/p/opensit/wiki/Interpolation%20Tools/
>
> The plugin uses MultiInputDialog from OpenJUMP which allows to use part of
> the dialog for user information where you can find info on how to use each
> algorithm of interpolation.
>
> The project is an external plugin as it is still on developing and
> testing. The day that it will mature enough I plan to port it to OpenJUMP.
> Best regards
> Peppe
>
>
>
> ___
> Jump-pilot-devel mailing 
> listJump-pilot-devel@lists.sourceforge.nethttps://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:bugs] #511 CropWarp raster plugin can't overload existing file

[Giuseppe Aruta]

> Currently, a first dialog ask the user if he wants to overwrite the
existing file. If yes, the user is informed it is not possible.
GUIUtil.FileChooserWithOverwritePrompting() effect. Which has a priority on
the various EnableChecks acting on the panel. I will study another solution

Il giorno lun 30 nov 2020 alle ore 23:11 michael michaud via
Jump-pilot-devel  ha scritto:

>
>- *Milestone*: OJ_1.16 --> OJ_future
>- *Comment*:
>
> Thank Peppe,
> I let it opened as it may probably be fixed in a better way, but it can be
> postponed to version 2. Currently, a first dialog ask the user if he wants
> to overwrite the existing file. If yes, the user is informed it is not
> possible.
> --
>
> * [bugs:#511]  CropWarp
> raster plugin can't overload existing file*
>
> *Status:* open
> *Milestone:* OJ_future
> *Created:* Tue Nov 10, 2020 10:01 PM UTC by michael michaud
> *Last Updated:* Mon Nov 23, 2020 01:48 PM UTC
> *Owner:* nobody
>
> If one process an image with CropWarpPlugin and try to save the result
> with the name of an existing image (want to replace the former image),
> there is no warning as in other plugins, and it produces a weird image
> (looks like a mixt between the old and the new image).
> --
>
> 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] New project/new plugin

[Giuseppe Aruta]

Greetings OpenJUMPs
I started a new project to create an interpolation plugin for OpenJUMP
The plugin takes scattered points loaded in OpenJUMP which have a xyz
coordinates and transform them into a raster grid, as Sextante raster.

OpenJUMP has already some interpolation plugins via Sextante toolbox
(linear regression, Nearest Neighbor, IDW and some Krigings).

My plugin tries to extend this capability reusing external codes from other
projects which recently are "starving" of development: AdbToolbox, a clone
of OpenJUMP, and the good WhiteBox GAT from John Lindsey.

Note that, among the others, the TIN interpolation algorithm is my first
try to port an imageJ plugin to OpenJUMP with a with unexpected and fast
results: it required few modification to port and it is the faster and less
memory-eater among the others

You can find detail of my project and a link to download the plugin here:
https://sourceforge.net/p/opensit/wiki/Interpolation%20Tools/

The plugin uses MultiInputDialog from OpenJUMP which allows to use part of
the dialog for user information where you can find info on how to use each
algorithm of interpolation.

The project is an external plugin as it is still on developing and testing.
The day that it will mature enough I plan to port it to OpenJUMP.
Best regards
Peppe
___
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] Re: #515 Raster display in low memory situation

[Giuseppe Aruta]

ImageJ (https://imagej.nih.gov/ij/) manages in a very good way rasters,
including reading values and styling. Just a note to check an alternative
source for the future

Il giorno lun 30 nov 2020 alle ore 11:52  ha scritto:

> the bug is already tagged OJ_future so no hurry there.
>
> we still got 5 open OJ 1.16 bugs[1] which look like they might be solved
> already.. ede
>
> [1] https://t1p.de/oix8
>
> On 11/30/2020 10:40, giuseppe.ar...@gmail.com wrote:
> > Hi,
> > I agree with Michael that ij this step we can consider a good result to
> have a better RasterImageLayer framework for this three reasons: it if
> faster in opening images, it requires less ram, it can open more TIF
> versions than before.
> > Possibly we can postpone, as Michael suggests, to rewrite the code to
> make it simpler.
> > One idea could be to extend Referenced image framework to styling (only
> monoband raster) and give up with RasterImageLayer , even if this will
> require more and more job to rewrite plugins. Or Ede proposals which seems
> to be more interesting.
> > We can wait after migration to Openjump V.2
> > I want to really thank Ede and Michael to all of the efforts, work,
> ideas and discussion. All your contribution that surely many user will
> benefit in their work or course activities.
> > Thanks again
> > Giuseppe
> >
> > --
> > Inviato da myMail per Android
> >
> > domenica, 29 novembre 2020, 06:35PM +01:00 da michael michaud via
> Jump-pilot-devel jump-pilot-devel@lists.sourceforge.net  jump-pilot-devel@lists.sourceforge.net>:
> >
> >
> >
> > Hi Ede,
> >
> > Thank you for the overview of the main raster classes.
> >
> > I don't know if your proposition of saving the displayed image to
> disk would improve performance/memory usage. It would need tests. Anyway,
> let's postpone this to v2. From my point of view, making raster code more
> robust and simpler is more important, but making it faster or less greedy
> in memory would also be nice.
> >
> > Michaël
> >
> >
> >
> >> *envoyé :* 26 novembre 2020 à 14:43
> >> *de :* ede  e...@users.sourceforge.net>>
> >> *à :* "[jump-pilot:bugs] " <
> 5...@bugs.jump-pilot.p.re.sourceforge.net  5...@bugs.jump-pilot.p.re.sourceforge.net>>
> >> *objet :* [jump-pilot:bugs] Re: #515 Raster display in low memory
> situation
> >>
> >>
> >> On 11/25/2020 13:15, michael michaud wrote:
> >>
> >> Even after several bug fixes, I still not have a good
> understanding of the image framework.
> >> To be able to imagine improvements, I would need a more precise
> idea about when the image is read from disk and when/where/what is cached.
> >>
> >> for ReferencedImage(imagery.geoimg) it's pretty easy, albeit the
> class naming is maybe not optimal.
> >> GeoRaster - takes care of loading, provides a RenderedOp
> >> GeoReferencedRaster - adds Referencing, vulgo Envelop
> >> GeoImage - renders/paints a given GeoRaster (implements the whole
> rendering chain, the only place that caches)
> >>
> >> the Sextante Raster Image framework is a convoluted mess, not sure
> what's going on there. just contributed it reusing GeoReferencedRaster for
> a way to enforce the tif loader and reusing the same instance for
> performance. my current guess is it creates a buffered image once and
> caches that in memory.
> >>
> >> It would deserve a page on the wiki if it does not exists so
> that we know precisely what we are taking about.
> >>
> >> probably would. just shying away creating documentation that'll
> probably become obsolete fast because nobody maintains it. am pretty
> wikilazy myself ;(
> >>
> >> Not sure I understand your proposition. Can you explain what
> would be the benefit of reading a lossless compressed tiff image from a
> temp folder compared to reading it from the original file ?
> >>
> >> idea is to cache the visualization on disk instead in memory hence
> saving some.
> >>
> >> Or is it about saving the symbolization step ?
> >>
> >> if symbolization is the creation of the visualization of the values
> in the monoband, then yes.
> >>
> >> I have no idea if transforming rough data to the displayed
> image is cpu-intensive, but I think reading from disk is more time
> consuming.
> >>
> >> probably not, creation of the the visualization involves two times
> iterating over all pixels of the whole image, one go to find the
> lower/upper limit, second time to create the visualization based on that
> information.
> >>
> >> Also it seems that the cached displayed image is just the part
> of the image we want to display. It seems difficult to read/write on disk
> every time the envelope of the visible part of the image changes.
> >>
> >> it's what ReferencedImage(imagery.geoimg) does except for whole
> image overviews.
> >>
> >> There are also other ways to optimize like using tiled images
> or subsampled overviews (at least in geotiff). I don't think we are ready

[JPP-Devel] [jump-pilot:bugs] #512 Georeferenced RasterImage : useless dialog to create a worlfile

[Giuseppe Aruta via Jump-pilot-devel]

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



---

** [bugs:#512] Georeferenced RasterImage : useless dialog to create a worlfile**

**Status:** pending
**Milestone:** OJ_1.16
**Created:** Wed Nov 11, 2020 08:29 AM UTC by michael michaud
**Last Updated:** Mon Nov 30, 2020 07:53 PM UTC
**Owner:** nobody


Trying to open a georeferenced GeoTiff  as a (Sextante) RasterImage , I'm 
invited to define the worldfile through a dialog box. Whatever I enter in the 
diaog box, the image will be georeferenced using the geotags of the geotiff, 
which is fine, but the dialogbox is misleading and will create a tfw file which 
is inconsistant with the geotiff tags.


---

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] #512 Georeferenced RasterImage : useless dialog to create a worlfile

[Giuseppe Aruta via Jump-pilot-devel]

Michael- Will you close this ticket? Or shall I do?


---

** [bugs:#512] Georeferenced RasterImage : useless dialog to create a worlfile**

**Status:** open
**Milestone:** OJ_1.16
**Created:** Wed Nov 11, 2020 08:29 AM UTC by michael michaud
**Last Updated:** Mon Nov 23, 2020 01:47 PM UTC
**Owner:** nobody


Trying to open a georeferenced GeoTiff  as a (Sextante) RasterImage , I'm 
invited to define the worldfile through a dialog box. Whatever I enter in the 
diaog box, the image will be georeferenced using the geotags of the geotiff, 
which is fine, but the dialogbox is misleading and will create a tfw file which 
is inconsistant with the geotiff tags.


---

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] #513 displaying raster layers in a correct way

[Giuseppe Aruta via Jump-pilot-devel]

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



---

** [bugs:#513] displaying raster layers in a correct way**

**Status:** closed-fixed
**Milestone:** OJ_1.16
**Labels:** raster display 
**Created:** Wed Nov 11, 2020 12:35 PM UTC by Giuseppe Aruta
**Last Updated:** Mon Nov 30, 2020 07:52 PM UTC
**Owner:** nobody
**Attachments:**

- 
[correct_display.png](https://sourceforge.net/p/jump-pilot/bugs/513/attachment/correct_display.png)
 (27.4 kB; image/png)
- 
[wrong_display.png](https://sourceforge.net/p/jump-pilot/bugs/513/attachment/wrong_display.png)
 (169.1 kB; image/png)


This bug has been described by Roberto Rossi on post:
[JPP-Devel] 6506 loading raster test
It comes out when the RAM  used by OpenJUMP is largely engaged to load and 
display many raster (Sextante) layers, together with big shape files.
It affects only continuous raster layer with a single band (like DTM or DEM)
Roberto provided some test files and a video that discribes the bug.

The link for the video is provided here: 
https://mediaspace.unipd.it/id/1_varzgomj
The files to test the bug are available here:
https://drive.google.com/file/d/1sWFahWBxJnaEherHy3ywGEI5b-CYweOP/view?usp=sharing
In the zip file there 2 shapefile and 26 raster images.

description of the test bug:

1) load the shapefiles
2) load the rasters and wait that they are all displayed
3) zoom to an area that covers a part of the raster set
4) deactivate visibility to all the vector and raster layers
5) start to activate visibility to the layers one by one, starting from vectors 
(which should be the last below in the pile of layers)
6) when you reach at one of the continuous raster layer (DTMxx and Depitxx, 
Aspect, Slope) it may be show a wrong display (see wrong_display.png) instead 
of the right one (see right_display.png).

Note that, depending to the quantity of RAM that your OS uses you may or may 
not see the bug:
a) Roberto Rossi who uses Windows 10 with 8 Gb got the bug after reactivating 
visibility of few rasters
b) I use Ubuntu Mate with 6 RAM and I had to (re)load other 11 raster layersto 
GOT the bug.

Usually the bug disapears if the user zoom in to another area withing the same 
raster (not sure about zoom out). The bug disapears if RAM is free removing 
some layers (shapefiles) from the OpenJUMP project.



---

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] #513 displaying raster layers in a correct way

[Giuseppe Aruta via Jump-pilot-devel]

I am going to close this bug as it has already solved by Michael's last 
modification on RasterImageLayer framework. 


---

** [bugs:#513] displaying raster layers in a correct way**

**Status:** open
**Milestone:** OJ_1.16
**Labels:** raster display 
**Created:** Wed Nov 11, 2020 12:35 PM UTC by Giuseppe Aruta
**Last Updated:** Mon Nov 23, 2020 01:50 PM UTC
**Owner:** nobody
**Attachments:**

- 
[correct_display.png](https://sourceforge.net/p/jump-pilot/bugs/513/attachment/correct_display.png)
 (27.4 kB; image/png)
- 
[wrong_display.png](https://sourceforge.net/p/jump-pilot/bugs/513/attachment/wrong_display.png)
 (169.1 kB; image/png)


This bug has been described by Roberto Rossi on post:
[JPP-Devel] 6506 loading raster test
It comes out when the RAM  used by OpenJUMP is largely engaged to load and 
display many raster (Sextante) layers, together with big shape files.
It affects only continuous raster layer with a single band (like DTM or DEM)
Roberto provided some test files and a video that discribes the bug.

The link for the video is provided here: 
https://mediaspace.unipd.it/id/1_varzgomj
The files to test the bug are available here:
https://drive.google.com/file/d/1sWFahWBxJnaEherHy3ywGEI5b-CYweOP/view?usp=sharing
In the zip file there 2 shapefile and 26 raster images.

description of the test bug:

1) load the shapefiles
2) load the rasters and wait that they are all displayed
3) zoom to an area that covers a part of the raster set
4) deactivate visibility to all the vector and raster layers
5) start to activate visibility to the layers one by one, starting from vectors 
(which should be the last below in the pile of layers)
6) when you reach at one of the continuous raster layer (DTMxx and Depitxx, 
Aspect, Slope) it may be show a wrong display (see wrong_display.png) instead 
of the right one (see right_display.png).

Note that, depending to the quantity of RAM that your OS uses you may or may 
not see the bug:
a) Roberto Rossi who uses Windows 10 with 8 Gb got the bug after reactivating 
visibility of few rasters
b) I use Ubuntu Mate with 6 RAM and I had to (re)load other 11 raster layersto 
GOT the bug.

Usually the bug disapears if the user zoom in to another area withing the same 
raster (not sure about zoom out). The bug disapears if RAM is free removing 
some layers (shapefiles) from the OpenJUMP project.



---

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] Re: #515 Raster display in low memory situation

[giuseppe . aruta]

Hi,
I agree with Michael that ij this step we can consider a good result to have a 
better RasterImageLayer framework for this three reasons: it if faster in 
opening images, it requires less ram, it can open more TIF versions than before.
Possibly we can postpone, as Michael suggests, to rewrite the code to make it 
simpler.
One idea could be to extend Referenced image framework to styling (only 
monoband raster) and give up with RasterImageLayer , even if this will require 
more and more job to rewrite plugins. Or Ede proposals which seems to be more 
interesting. 
We can wait after migration to Openjump V.2
I want to really thank Ede and Michael to all of the efforts, work, ideas and 
discussion. All your contribution that surely many user will benefit in their 
work or course activities.
Thanks again
Giuseppe
--
Inviato da myMail per Android domenica, 29 novembre 2020, 06:35PM +01:00 da 
michael michaud via Jump-pilot-devel  jump-pilot-devel@lists.sourceforge.net :

>
>
>Hi Ede,
>Thank you for the overview of the main raster classes.
>I don't know if your proposition of saving the displayed image to disk would 
>improve performance/memory usage. It would need tests. Anyway, let's postpone 
>this to v2. From my point of view, making raster code more robust and simpler 
>is more important, but making it faster or less greedy in memory would also be 
>nice.
>Michaël
> 
>>envoyé : 26 novembre 2020 à 14:43
>>de : ede < e...@users.sourceforge.net>
>>à : " [jump-pilot:bugs] " < 5...@bugs.jump-pilot.p.re.sourceforge.net>
>>objet : [jump-pilot:bugs] Re: #515 Raster display in low memory situation
>>On 11/25/2020 13:15, michael michaud wrote:
>>>Even after several bug fixes, I still not have a good understanding of the 
>>>image framework.
>>>To be able to imagine improvements, I would need a more precise idea about 
>>>when the image is read from disk and when/where/what is cached.
>>for ReferencedImage(imagery.geoimg) it's pretty easy, albeit the class naming 
>>is maybe not optimal.
>>GeoRaster - takes care of loading, provides a RenderedOp
>>GeoReferencedRaster - adds Referencing, vulgo Envelop
>>GeoImage - renders/paints a given GeoRaster (implements the whole rendering 
>>chain, the only place that caches)
>>the Sextante Raster Image framework is a convoluted mess, not sure what's 
>>going on there. just contributed it reusing GeoReferencedRaster for a way to 
>>enforce the tif loader and reusing the same instance for performance. my 
>>current guess is it creates a buffered image once and caches that in memory.
>>>It would deserve a page on the wiki if it does not exists so that we know 
>>>precisely what we are taking about.
>>probably would. just shying away creating documentation that'll probably 
>>become obsolete fast because nobody maintains it. am pretty wikilazy myself ;(
>>>Not sure I understand your proposition. Can you explain what would be the 
>>>benefit of reading a lossless compressed tiff image from a temp folder 
>>>compared to reading it from the original file ?
>>idea is to cache the visualization on disk instead in memory hence saving 
>>some.
>>>Or is it about saving the symbolization step ?
>>if symbolization is the creation of the visualization of the values in the 
>>monoband, then yes.
>>>I have no idea if transforming rough data to the displayed image is 
>>>cpu-intensive, but I think reading from disk is more time consuming.
>>probably not, creation of the the visualization involves two times iterating 
>>over all pixels of the whole image, one go to find the lower/upper limit, 
>>second time to create the visualization based on that information.
>>>Also it seems that the cached displayed image is just the part of the image 
>>>we want to display. It seems difficult to read/write on disk every time the 
>>>envelope of the visible part of the image changes.
>>it's what ReferencedImage(imagery.geoimg) does except for whole image 
>>overviews.
>>>There are also other ways to optimize like using tiled images or subsampled 
>>>overviews (at least in geotiff). I don't think we are ready to take 
>>>advantage of it.
>>agreed. that's why i suggest the caching on disk approach.
>>..ede
>>--
>>[bugs:#515] Raster display in low memory situation
>>Status: open
>>Milestone: OJ_future
>>Created: Tue Nov 24, 2020 10:20 PM UTC by michael michaud
>>Last Updated: Wed Nov 25, 2020 12:15 PM UTC
>>Owner: michael michaud
>>This ticket follows ticket #513.
>>After correction of the bug reported by Roberto Rossi in #513 two problems 
>>are left over.
>>Images are not loaded permanently in memory, but when they must be shown, 
>>RasterImageLayer evaluates if they fit in memory before trying to display. To 
>>evaluate if the image fits in memory it multiplies the number of pixels by 4 
>>bytes (usual pixel deep for a color image). This evaluation should be more 
>>precise and take into account 1 bit images (b&w) or 64 bits float values.

Re: [JPP-Devel] SVN: [6636] core/trunk/src/language

[Giuseppe Aruta]

Hi Ede,
thanks for the suggestion.
Indeed we need a more generic code but, you were right, it is not this case.
I corrected to ui.GenericNames.cannot-overwrite-input-layer and the text:
Cannot overwrite selected  input layer
Peppe

Il giorno lun 23 nov 2020 alle ore 15:19  ha scritto:

> Peppe,
>
> this looks wrong
>
> ui.GenericNames.cannot-overwrite=Cannot overwrite input layer
>
> should be
>
> ui.GenericNames.cannot-overwrite-input-layer=Cannot overwrite input layer
>
> as you will not be able to use it to message simply "Cannot overwrite!" in
> a more generic context!
>
> also. is it possoble that "Cannot overwrite used input file!" would be
> more applicable in this case? (not sure, but looks like it at a glance)
>
> ..ede
>
>
> On 11/23/2020 14:25, jump-pilot-svn--- via Jump-pilot-devel wrote:
> > Revision: 6636
> >   http://sourceforge.net/p/jump-pilot/code/6636
> > Author:   ma15569
> > Date: 2020-11-23 13:25:58 + (Mon, 23 Nov 2020)
> > Log Message:
> > ---
> > Added language codes
> >
> > Modified Paths:
> > --
> > core/trunk/src/language/jump.properties
> > core/trunk/src/language/jump_cz.properties
> > core/trunk/src/language/jump_de.properties
> > core/trunk/src/language/jump_es.properties
> > core/trunk/src/language/jump_fi.properties
> > core/trunk/src/language/jump_fr.properties
> > core/trunk/src/language/jump_hu.properties
> > core/trunk/src/language/jump_it.properties
> > core/trunk/src/language/jump_ja_JP.properties
> > core/trunk/src/language/jump_ml.properties
> > core/trunk/src/language/jump_pt.properties
> > core/trunk/src/language/jump_pt_BR.properties
> > core/trunk/src/language/jump_ta_IN.properties
> > core/trunk/src/language/jump_te.properties
> > core/trunk/src/language/jump_zh_CN.properties
> > core/trunk/src/language/jump_zh_HK.properties
> >
> > Modified: core/trunk/src/language/jump.properties
> > ===
> > --- core/trunk/src/language/jump.properties   2020-11-23 13:16:01 UTC
> (rev 6635)
> > +++ core/trunk/src/language/jump.properties   2020-11-23 13:25:58 UTC
> (rev 6636)
> > @@ -2632,6 +2632,7 @@
> >  ui.plugin.imagery.ImageLayerManagerPlugIn.Image-Layer-Manager = Image
> Layer Manager
> >
> ui.plugin.imagery.ImageLayerManagerPlugIn.Layer-must-be-an-Imagery-layer =
> Layer must be an imagery layer.
> >  ui.GenericNames.check-field=Check field
> > +ui.GenericNames.cannot-overwrite=Cannot overwrite input layer
> >  ui.GenericNames.choose-an-action=Choose an action
> >  ui.plugin.raster.ManageDataPlugIn.Name=Manage raster data
> >  ui.plugin.raster.ManageDataPlugIn.change-nodata-and-tag-tip=Change both
> nodata values and reference number (nodata tag)
> >
> > Modified: core/trunk/src/language/jump_cz.properties
> > ===
> > --- core/trunk/src/language/jump_cz.properties2020-11-23
> 13:16:01 UTC (rev 6635)
> > +++ core/trunk/src/language/jump_cz.properties2020-11-23
> 13:25:58 UTC (rev 6636)
> > @@ -2929,6 +2929,7 @@
> >  ui.GenericNames.interval-of-data-analysis=\#T\:Interval of data analysis
> >  plugin.EnableCheckFactory.at-least-one-single-banded-layer-should-exist
> =\#T\:At least one single banded layer should exist
> >  ui.GenericNames.check-field=\#T\:Check field
> > +ui.GenericNames.cannot-overwrite=\#T\:Cannot overwrite input layer
> >  ui.GenericNames.choose-an-action=\#T\:Choose an action
> >  ui.plugin.raster.ManageDataPlugIn.Name=\#T\:Manage raster data
> >  ui.plugin.raster.ManageDataPlugIn.change-nodata-and-tag-tip=\#T\:Change
> both nodata values and reference number (nodata tag)
> >
> > Modified: core/trunk/src/language/jump_de.properties
> > ===
> > --- core/trunk/src/language/jump_de.properties2020-11-23
> 13:16:01 UTC (rev 6635)
> > +++ core/trunk/src/language/jump_de.properties2020-11-23
> 13:25:58 UTC (rev 6636)
> > @@ -2921,6 +2921,7 @@
> >  ui.GenericNames.interval-of-data-analysis=\#T\:Interval of data analysis
> >  plugin.EnableCheckFactory.at-least-one-single-banded-layer-should-exist
> =\#T\:At least one single banded layer should exist
> >  ui.GenericNames.check-field=\#T\:Check field
> > +ui.GenericNames.cannot-overwrite=\#T\:Cannot overwrite input layer
> >  ui.GenericNames.choose-an-action=\#T\:Choose an action
> >  ui.plugin.raster.ManageDataPlugIn.Name=\#T\:Manage raster data
> >  ui.plugin.raster.ManageDataPlugIn.change-nodata-and-tag-tip=\#T\:Change
> both nodata values and reference number (nodata tag)
> >
> > Modified: core/trunk/src/language/jump_es.properties
> > ===
> > --- core/trunk/src/language/jump_es.properties2020-11-23
> 13:16:01 UTC (rev 6635)
> > +++ core/trunk/src/language/jump_es.properties2020-11-23
> 13:25:58 UTC (rev 6636)
> 

[JPP-Devel] [jump-pilot:bugs] #513 displaying raster layers in a correct way

[Giuseppe Aruta via Jump-pilot-devel]

I was expecting Roberto's test to close the ticket. I am quite satisfied thanks 
to Michael's fix


---

** [bugs:#513] displaying raster layers in a correct way**

**Status:** open
**Milestone:** OJ_1.16
**Labels:** raster display 
**Created:** Wed Nov 11, 2020 12:35 PM UTC by Giuseppe Aruta
**Last Updated:** Mon Nov 23, 2020 11:50 AM UTC
**Owner:** nobody
**Attachments:**

- 
[correct_display.png](https://sourceforge.net/p/jump-pilot/bugs/513/attachment/correct_display.png)
 (27.4 kB; image/png)
- 
[wrong_display.png](https://sourceforge.net/p/jump-pilot/bugs/513/attachment/wrong_display.png)
 (169.1 kB; image/png)


This bug has been described by Roberto Rossi on post:
[JPP-Devel] 6506 loading raster test
It comes out when the RAM  used by OpenJUMP is largely engaged to load and 
display many raster (Sextante) layers, together with big shape files.
It affects only continuous raster layer with a single band (like DTM or DEM)
Roberto provided some test files and a video that discribes the bug.

The link for the video is provided here: 
https://mediaspace.unipd.it/id/1_varzgomj
The files to test the bug are available here:
https://drive.google.com/file/d/1sWFahWBxJnaEherHy3ywGEI5b-CYweOP/view?usp=sharing
In the zip file there 2 shapefile and 26 raster images.

description of the test bug:

1) load the shapefiles
2) load the rasters and wait that they are all displayed
3) zoom to an area that covers a part of the raster set
4) deactivate visibility to all the vector and raster layers
5) start to activate visibility to the layers one by one, starting from vectors 
(which should be the last below in the pile of layers)
6) when you reach at one of the continuous raster layer (DTMxx and Depitxx, 
Aspect, Slope) it may be show a wrong display (see wrong_display.png) instead 
of the right one (see right_display.png).

Note that, depending to the quantity of RAM that your OS uses you may or may 
not see the bug:
a) Roberto Rossi who uses Windows 10 with 8 Gb got the bug after reactivating 
visibility of few rasters
b) I use Ubuntu Mate with 6 RAM and I had to (re)load other 11 raster layersto 
GOT the bug.

Usually the bug disapears if the user zoom in to another area withing the same 
raster (not sure about zoom out). The bug disapears if RAM is free removing 
some layers (shapefiles) from the OpenJUMP project.



---

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] #511 CropWarp raster plugin can't overload existing file

[Giuseppe Aruta via Jump-pilot-devel]

I added a check in order not to overwrite input raster file with the new one. 
This patch together with Michael's unograde should avoid to have strange 
output, I hope


---

** [bugs:#511] CropWarp raster plugin can't overload existing file**

**Status:** open
**Milestone:** OJ_1.16
**Created:** Tue Nov 10, 2020 10:01 PM UTC by michael michaud
**Last Updated:** Mon Nov 23, 2020 11:51 AM UTC
**Owner:** nobody


If one process an image with CropWarpPlugin and try to save the result with the 
name  of an existing image (want to replace the former image), there is no  
warning as in other plugins, and it produces a weird image (looks like a mixt 
between the old and the new image).


---

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] #512 Georeferenced RasterImage : useless dialog to create a worlfile

[Giuseppe Aruta via Jump-pilot-devel]

This seems correct with newer upgrade fom Michael


---

** [bugs:#512] Georeferenced RasterImage : useless dialog to create a worlfile**

**Status:** open
**Milestone:** OJ_1.16
**Created:** Wed Nov 11, 2020 08:29 AM UTC by michael michaud
**Last Updated:** Fri Nov 20, 2020 11:15 PM UTC
**Owner:** nobody


Trying to open a georeferenced GeoTiff  as a (Sextante) RasterImage , I'm 
invited to define the worldfile through a dialog box. Whatever I enter in the 
diaog box, the image will be georeferenced using the geotags of the geotiff, 
which is fine, but the dialogbox is misleading and will create a tfw file which 
is inconsistant with the geotiff tags.


---

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: #512 Georeferenced RasterImage : useless dialog to create a worlfile

[Giuseppe Aruta via Jump-pilot-devel]

Hi Michael,
It is a geotiff image opened with Gimp and saved back as image. I tried to 
reproduce a most common mistake that users at their first approach to Gis do 
(open a geotiff with an image viewer and Dave it back loosing geotiff tags).
With a previous version of RasterImageLayer framework OJ was able to skip 
reading 
 tag 34735 if it was a string and classify the file as no geotiff (no tfw).   
Indeed everything works fine with other tiff files with no tag 34735. Maybe a 
simple check/warning solves the issue.
Peppe
Inviato da myMail per Android sabato, 21 novembre 2020, 00:15AM +01:00 da 
michael michaud  micha...@users.sourceforge.net :

>Peppe,
>Seems that your noWF.tif contains invalid geotags.
>ExifTools shows the following warning
>"Non-standard format (string) for IFD0 0x87af GeoTiffDirectory"
>which explains why OpenJUMP throws an exception when it tries to read tag 
>34735 (waiting for unisgned short array, find a string) 
>Can you explain how you made this file.
>If image is produced by a well-known gis tool, I'll try to throw a better 
>mesage or to read the tag anyway.
>--
>[bugs:#512] Georeferenced RasterImage : useless dialog to create a worlfile
>Status: open
>Milestone: OJ_1.16
>Created: Wed Nov 11, 2020 08:29 AM UTC by michael michaud
>Last Updated: Mon Nov 16, 2020 02:25 PM UTC
>Owner: nobody
>Trying to open a georeferenced GeoTiff  as a (Sextante) RasterImage , I'm 
>invited to define the worldfile through a dialog box. Whatever I enter in the 
>diaog box, the image will be georeferenced using the geotags of the geotiff, 
>which is fine, but the dialogbox is misleading and will create a tfw file 
>which is inconsistant with the geotiff tags.
>--
>Sent from sourceforge.net because you indicated interest in  
>https://sourceforge.net/p/jump-pilot/bugs/512/
>To unsubscribe from further messages, please visit  
>https://sourceforge.net/auth/subscriptions/



---

** [bugs:#512] Georeferenced RasterImage : useless dialog to create a worlfile**

**Status:** open
**Milestone:** OJ_1.16
**Created:** Wed Nov 11, 2020 08:29 AM UTC by michael michaud
**Last Updated:** Fri Nov 20, 2020 11:15 PM UTC
**Owner:** nobody


Trying to open a georeferenced GeoTiff  as a (Sextante) RasterImage , I'm 
invited to define the worldfile through a dialog box. Whatever I enter in the 
diaog box, the image will be georeferenced using the geotags of the geotiff, 
which is fine, but the dialogbox is misleading and will create a tfw file which 
is inconsistant with the geotiff tags.


---

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] #513 displaying raster layers in a correct way

[giuseppe . aruta]

No reports from Roberto yet. I will wait a few days and close it
Peppe
--
Inviato da myMail per Android sabato, 21 novembre 2020, 09:10AM +01:00 da 
michael michaud via Jump-pilot-devel  jump-pilot-devel@lists.sourceforge.net :

>All this ticket is about situations where memory consumption is high compared 
>to max available memory. 
>Original behaviour : symbolizing process was cut off and image was displayed 
>with a wrong appearance
>First fix : when available memory is too low, additional images are no more 
>displayed
>Now : when available memory is too low, additional images are not displayed 
>and a yellow warning is emitted
>Note : at the time where new images are loaded in OpenJUMP, memory maybe 
>sufficient (for example if other images are not visible because invisible 
>images do not use memory), this is why we must handle these low-memory 
>situation at render time.
>If the original problem is solved, let's close the ticket. If low level memory 
>situation handling still need improvement, let's open a new ticket.
>--
>[bugs:#513] displaying raster layers in a correct way
>Status: open
>Milestone: undecided
>Labels: raster display 
>Created: Wed Nov 11, 2020 12:35 PM UTC by Giuseppe Aruta
>Last Updated: Wed Nov 11, 2020 05:56 PM UTC
>Owner: nobody
>Attachments:
>*  correct_display.png (27.4 kB; image/png)
>*  wrong_display.png (169.1 kB; image/png)
>This bug has been described by Roberto Rossi on post:
>[JPP-Devel] 6506 loading raster test
>It comes out when the RAM  used by OpenJUMP is largely engaged to load and 
>display many raster (Sextante) layers, together with big shape files.
>It affects only continuous raster layer with a single band (like DTM or DEM)
>Roberto provided some test files and a video that discribes the bug.
>The link for the video is provided here:  
>https://mediaspace.unipd.it/id/1_varzgomj
>The files to test the bug are available here:
>https://drive.google.com/file/d/1sWFahWBxJnaEherHy3ywGEI5b-CYweOP/view?usp=sharing
>In the zip file there 2 shapefile and 26 raster images.
>description of the test bug:
>1) load the shapefiles
>2) load the rasters and wait that they are all displayed
>3) zoom to an area that covers a part of the raster set
>4) deactivate visibility to all the vector and raster layers
>5) start to activate visibility to the layers one by one, starting from 
>vectors (which should be the last below in the pile of layers)
>6) when you reach at one of the continuous raster layer (DTMxx and Depitxx, 
>Aspect, Slope) it may be show a wrong display (see wrong_display.png) instead 
>of the right one (see right_display.png).
>Note that, depending to the quantity of RAM that your OS uses you may or may 
>not see the bug:
>a) Roberto Rossi who uses Windows 10 with 8 Gb got the bug after reactivating 
>visibility of few rasters
>b) I use Ubuntu Mate with 6 RAM and I had to (re)load other 11 raster layersto 
>GOT the bug.
>Usually the bug disapears if the user zoom in to another area withing the same 
>raster (not sure about zoom out). The bug disapears if RAM is free removing 
>some layers (shapefiles) from the OpenJUMP project.
>--
>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] #510 Create Polygon From a Raster bug

[Giuseppe Aruta via Jump-pilot-devel]

Hi Michael, Jukka
I tested the plugin and everything seems to work file.
I suggest to close the ticket and I will postpone after OJ new real. Jukka's 
suggestion to make the plugin able to use histograms to define ranges of 
values. 
I will add some notes on the wiki
Peppe


---

** [bugs:#510] Create Polygon From a Raster bug**

**Status:** open
**Milestone:** OJ_1.16
**Created:** Tue Nov 10, 2020 12:59 PM UTC by michael michaud
**Last Updated:** Wed Nov 11, 2020 11:13 AM UTC
**Owner:** nobody


The plugin has two modes : AdbToolbox and Sextante. With tiff images of type 
float like DTM084 from Roberto Rossi, I can vectorize with Sextante, but Adb 
throws en exception :
java.lang.ArrayIndexOutOfBoundsException: Index - out of bounds for length 
1925123
at 
org.openjump.core.rasterimage.algorithms.VectorizeAlgorithm.toPolygonsAdbToolBox(VectorizeAlgorithm.java:113)
at 
org.openjump.core.ui.plugin.raster.VectorizeToPolygonsPlugIn.run(VectorizeToPolygonsPlugIn.java:170)
at 
com.vividsolutions.jump.workbench.ui.task.TaskMonitorManager$TaskWrapper.run(TaskMonitorManager.java:151)



---

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] #511 CropWarp raster plugin can't overload existing file

[Giuseppe Aruta via Jump-pilot-devel]

The bug seems to happen only if user tries to overwrite the input file.
One possible (hard) solution seems to make RasterImageLayer framework able to 
store modified datas into memory and give up to output file option into the 
dialog(s).
This seems to hard to work around that generates other problems to solve 
(warning to user to save layer when a project is closed, etc).
Another fast solution is am considering to extend EnableCheck of save-file 
action: actually it checks only if the field to put output file is empty (if 
so, the process is stopped with a warning). The extension will also check if 
output file is the same as input file.
I don't see other solutions in this moment
I am for the fast solution as it makes impossible to cancel/modify original data


---

** [bugs:#511] CropWarp raster plugin can't overload existing file**

**Status:** open
**Milestone:** undecided
**Created:** Tue Nov 10, 2020 10:01 PM UTC by michael michaud
**Last Updated:** Wed Nov 18, 2020 12:24 PM UTC
**Owner:** nobody


If one process an image with CropWarpPlugin and try to save the result with the 
name  of an existing image (want to replace the former image), there is no  
warning as in other plugins, and it produces a weird image (looks like a mixt 
between the old and the new image).


---

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] #511 CropWarp raster plugin can't overload existing file

[Giuseppe Aruta via Jump-pilot-devel]

I was able to reproduce the bug.  The warning message comes out but the output 
image either is not saved or it has a wierd look. I will give a look at the 
code on this weekend


---

** [bugs:#511] CropWarp raster plugin can't overload existing file**

**Status:** open
**Milestone:** undecided
**Created:** Tue Nov 10, 2020 10:01 PM UTC by michael michaud
**Last Updated:** Wed Nov 11, 2020 11:20 AM UTC
**Owner:** nobody


If one process an image with CropWarpPlugin and try to save the result with the 
name  of an existing image (want to replace the former image), there is no  
warning as in other plugins, and it produces a weird image (looks like a mixt 
between the old and the new image).


---

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] #512 Georeferenced RasterImage : useless dialog to create a worlfile

[Giuseppe Aruta via Jump-pilot-devel]

Hi Michael,
I added some files to this post to explain
I used OJ 6624
a) open GeoTIFF.tif (GeoTIFF file) now works fine thanks to your commit: no 
input dialog appears
b) open withWF.tif - this isn't a geotiff and all geographic info are written 
in the sidecar file withWF.tfw - Nothing happens. The file is not loaded and an 
error occurs
c) open noWF.tif - this isn't a geotiff, no geographic info are available. It 
was expecting that the input dialog appears to set coordinates -  Nothing 
happens. The file is not loaded and an error occurs
Best regards


Attachments:

- 
[withWF.tif](https://sourceforge.net/p/jump-pilot/bugs/_discuss/thread/563a4b21a6/3733/attachment/withWF.tif)
 (200.0 kB; image/tiff)
- 
[noWF.tif](https://sourceforge.net/p/jump-pilot/bugs/_discuss/thread/563a4b21a6/3733/attachment/noWF.tif)
 (211.0 kB; image/tiff)
- 
[GeoTIFF.tif](https://sourceforge.net/p/jump-pilot/bugs/_discuss/thread/563a4b21a6/3733/attachment/GeoTIFF.tif)
 (986.3 kB; image/tiff)
- 
[withWF.tfw](https://sourceforge.net/p/jump-pilot/bugs/_discuss/thread/563a4b21a6/3733/attachment/withWF.tfw)
 (26 Bytes; application/octet-stream)


---

** [bugs:#512] Georeferenced RasterImage : useless dialog to create a worlfile**

**Status:** open
**Milestone:** OJ_1.16
**Created:** Wed Nov 11, 2020 08:29 AM UTC by michael michaud
**Last Updated:** Sun Nov 15, 2020 09:48 AM UTC
**Owner:** nobody


Trying to open a georeferenced GeoTiff  as a (Sextante) RasterImage , I'm 
invited to define the worldfile through a dialog box. Whatever I enter in the 
diaog box, the image will be georeferenced using the geotags of the geotiff, 
which is fine, but the dialogbox is misleading and will create a tfw file which 
is inconsistant with the geotiff tags.


---

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] #512 Georeferenced RasterImage : useless dialog to create a worlfile

[Giuseppe Aruta via Jump-pilot-devel]

More info about the bug.


A)  when a TIFF is load  as Layer via GeoReferencedRaster, this class 
1.   first checks the geotags
2.  if no geotags are found, it checks a worlfile. 
3.   if no valid world file is found, the class creates a new geolocation 
(Envelope) to locate the image according to the width/heigh of the image and 
the origin loacted at (0,0) coordinate. No new worldfile is created

B) when a TIFF is load  as RasterImageLayer, AddRasterImageLayerWizard class 
was doing a similar job in this way:
1.first checks the geotags
2.   if no geotags are found, it checks a worlfile. 
3.if no valid world file is found, the class creates a dialog pops up 
letting the user to define north/south/east/west coordinates to define the new 
geolocation (Envelope) to locate the image.  A new worldfile is create.

In the method AddRasterImageLayerWizard.getGeoReferencing(...) all points 1,2,3 
have been deactivated to use new GeoReferencedRaster/TiffUtilsV2 framework. 
we can possibly partially restore the bug of unuseful dialog.

I observed a more severe bug: OJ cannot open anymore neither TIFF with 
worldfile nor TIFF with no geolocation (dialog pops up). Possibly we need to 
find a solution outside the class AddRasterImageLayerWizard
Peppe








---

** [bugs:#512] Georeferenced RasterImage : useless dialog to create a worlfile**

**Status:** open
**Milestone:** OJ_1.16
**Created:** Wed Nov 11, 2020 08:29 AM UTC by michael michaud
**Last Updated:** Wed Nov 11, 2020 04:07 PM UTC
**Owner:** nobody


Trying to open a georeferenced GeoTiff  as a (Sextante) RasterImage , I'm 
invited to define the worldfile through a dialog box. Whatever I enter in the 
diaog box, the image will be georeferenced using the geotags of the geotiff, 
which is fine, but the dialogbox is misleading and will create a tfw file which 
is inconsistant with the geotiff tags.


---

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] OpenJUMP Road map page

[Giuseppe Aruta]

"style from kosmo" came from an old request of mine. The time I
collaborated with Saig to translate Kosmo in Italian: I was attracted by
Kosmo way to define styles. In that time my experience with Java
programming was very low. It has not much increased nowadays but I
understand a little better to see that it is a long job (to port Kosmo
style to OpenJUMP) as it involves many classes and methods modified by Saig
developers. I will cancel it in the Road-map.
regarding "reviewing plugin architecture" I suppose it was before Ede did
the job FeatureInstaller class and to extend default-plugin.xml file usage.
We can consider it "closed" too


Il giorno mer 11 nov 2020 alle ore 17:50 Michaud Michael <
m.michael.mich...@orange.fr> ha scritto:

> Thanks for the update Peppe,
>
> I dispatched todos in subsections and added a few comments.
>
> Indeed, I think that Ede did a good job with ticket classification but we
> now have a bit of work
>
> if we want the roadmap and ticket classification to be consistent.
>
> I can't remember where bug identifiers of the roadmap come from. Seems
> that it has changed.
>
> I did not remove "reviewing plugin architecture" and "style from kosmo"
> yet, but I agree with you, they are not goals for v2.0.
>
> Michaël
>
> *envoyé :* 10 novembre 2020 à 15:51
> *de :* Giuseppe Aruta 
> *à :* OpenJump develop and use 
> *objet :* [JPP-Devel] OpenJUMP Road map page
>
> Hi all,
> I started to upgrade the road map page on our wiki:
>
> http://ojwiki.soldin.de/index.php?title=OpenJUMP_Roadmap#OpenJUMP_2.0_.282021.3F.29
> Please, if you can give a look and make your modifications and comments. I
> think some voices could be removed (see plugin architecture or Kosmo style
> implementation)
> Thanks
> peppe
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
___
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] #512 Georeferenced RasterImage : useless dialog to create a worlfile

[Giuseppe Aruta via Jump-pilot-devel]

AddRasterImageLayerWizard class
The dialog was used on original code in order to create a worldfile for raster 
(tif, gif, jpg, bmp) with no geolocation (=no worldfile). Reorganizing TIF 
import that part of code ended in a wrong position:, and dangerous because OJ 
creates a worldfile which is useless in this session od wirk. But it is read on 
the second or third session of work as the real geolocation. I prefer anyhow to 
deactivate the dialog or to reactivate the part of code ( protected Envelope 
getGeoReferencing(...)) for tiff into AddRasterImageLayerWizard.


---

** [bugs:#512] Georeferenced RasterImage : useless dialog to create a worlfile**

**Status:** open
**Milestone:** OJ_1.16
**Created:** Wed Nov 11, 2020 08:29 AM UTC by michael michaud
**Last Updated:** Wed Nov 11, 2020 08:29 AM UTC
**Owner:** nobody


Trying to open a georeferenced GeoTiff  as a (Sextante) RasterImage , I'm 
invited to define the worldfile through a dialog box. Whatever I enter in the 
diaog box, the image will be georeferenced using the geotags of the geotiff, 
which is fine, but the dialogbox is misleading and will create a tfw file which 
is inconsistant with the geotiff tags.


---

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] #513 displaying raster layers in a correct way

[Giuseppe Aruta via Jump-pilot-devel]

Test on OpenJUMP 6619.
I cannot reproduce Roberto's bug anymore but another problem comes out, 
possibly due to the memory.
a) when I load a raster (sextante) layers, if its position is outside the 
current view, I have an error message (yellow stripe) pointing to 
RasterImageLayer class, line 432, exception on method:
createImage(LayerViewPanel).
If I zoom to the layer, this is displayed in the correct way anyhow

b) Following Roberto's procedure, when I reach the maximum of RAM that OpenJUMP 
could use (supposing that the bug is connected to RAM)
- on previous version the raster was displayed in that B/W spaghetti mode
- on 6619 raster is not displayed.
- I have to zoom in an area of the raster to see datas. If I zoom out back to 
the previous display the raster disapears


---

** [bugs:#513] displaying raster layers in a correct way**

**Status:** open
**Milestone:** undecided
**Labels:** raster display 
**Created:** Wed Nov 11, 2020 12:35 PM UTC by Giuseppe Aruta
**Last Updated:** Wed Nov 11, 2020 12:35 PM UTC
**Owner:** nobody
**Attachments:**

- 
[correct_display.png](https://sourceforge.net/p/jump-pilot/bugs/513/attachment/correct_display.png)
 (27.4 kB; image/png)
- 
[wrong_display.png](https://sourceforge.net/p/jump-pilot/bugs/513/attachment/wrong_display.png)
 (169.1 kB; image/png)


This bug has been described by Roberto Rossi on post:
[JPP-Devel] 6506 loading raster test
It comes out when the RAM  used by OpenJUMP is largely engaged to load and 
display many raster (Sextante) layers, together with big shape files.
It affects only continuous raster layer with a single band (like DTM or DEM)
Roberto provided some test files and a video that discribes the bug.

The link for the video is provided here: 
https://mediaspace.unipd.it/id/1_varzgomj
The files to test the bug are available here:
https://drive.google.com/file/d/1sWFahWBxJnaEherHy3ywGEI5b-CYweOP/view?usp=sharing
In the zip file there 2 shapefile and 26 raster images.

description of the test bug:

1) load the shapefiles
2) load the rasters and wait that they are all displayed
3) zoom to an area that covers a part of the raster set
4) deactivate visibility to all the vector and raster layers
5) start to activate visibility to the layers one by one, starting from vectors 
(which should be the last below in the pile of layers)
6) when you reach at one of the continuous raster layer (DTMxx and Depitxx, 
Aspect, Slope) it may be show a wrong display (see wrong_display.png) instead 
of the right one (see right_display.png).

Note that, depending to the quantity of RAM that your OS uses you may or may 
not see the bug:
a) Roberto Rossi who uses Windows 10 with 8 Gb got the bug after reactivating 
visibility of few rasters
b) I use Ubuntu Mate with 6 RAM and I had to (re)load other 11 raster layersto 
GOT the bug.

Usually the bug disapears if the user zoom in to another area withing the same 
raster (not sure about zoom out). The bug disapears if RAM is free removing 
some layers (shapefiles) from the OpenJUMP project.



---

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] SVN: [6620] core/trunk/src/org/openjump/core/rasterimage/ RasterImageLayer.java

[Giuseppe Aruta]

Hi Michael,
I opened a bug ticket on RasterImage class following Roberto's description.
I will ad also some comments regarding your modifications

Il giorno mer 11 nov 2020 alle ore 11:31 jump-pilot-svn--- via
Jump-pilot-devel  ha scritto:

> Revision: 6620
>   http://sourceforge.net/p/jump-pilot/code/6620
> Author:   michaudm
> Date: 2020-11-11 10:30:58 + (Wed, 11 Nov 2020)
> Log Message:
> ---
> Remove a System.out.println which could cause NPE
>
> Modified Paths:
> --
> core/trunk/src/org/openjump/core/rasterimage/RasterImageLayer.java
>
> Modified:
> core/trunk/src/org/openjump/core/rasterimage/RasterImageLayer.java
> ===
> --- core/trunk/src/org/openjump/core/rasterimage/RasterImageLayer.java
> 2020-11-08 23:39:40 UTC (rev 6619)
> +++ core/trunk/src/org/openjump/core/rasterimage/RasterImageLayer.java
> 2020-11-11 10:30:58 UTC (rev 6620)
> @@ -418,11 +418,6 @@
>  } catch (Exception e){
>  Logger.warn(e);
>  }
> -System.out.println(
> -"" + getCommittedMemory() + " " + imageFileName + " " +
> -image.getWidth()+"x"+image.getHeight() + " - " +
> -
> scaledBufferedImage.getWidth()+"x"+scaledBufferedImage.getHeight()
> -);
>  if (imageToDraw != null) {
>  return imageToDraw;
>  } else {
>
>
>
> ___
> 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] #513 displaying raster layers in a correct way

[Giuseppe Aruta via Jump-pilot-devel]

---

** [bugs:#513] displaying raster layers in a correct way**

**Status:** open
**Milestone:** undecided
**Labels:** raster display 
**Created:** Wed Nov 11, 2020 12:35 PM UTC by Giuseppe Aruta
**Last Updated:** Wed Nov 11, 2020 12:35 PM UTC
**Owner:** nobody
**Attachments:**

- 
[correct_display.png](https://sourceforge.net/p/jump-pilot/bugs/513/attachment/correct_display.png)
 (27.4 kB; image/png)
- 
[wrong_display.png](https://sourceforge.net/p/jump-pilot/bugs/513/attachment/wrong_display.png)
 (169.1 kB; image/png)


This bug has been described by Roberto Rossi on post:
[JPP-Devel] 6506 loading raster test
It comes out when the RAM  used by OpenJUMP is largely engaged to load and 
display many raster (Sextante) layers, together with big shape files.
It affects only continuous raster layer with a single band (like DTM or DEM)
Roberto provided some test files and a video that discribes the bug.

The link for the video is provided here: 
https://mediaspace.unipd.it/id/1_varzgomj
The files to test the bug are available here:
https://drive.google.com/file/d/1sWFahWBxJnaEherHy3ywGEI5b-CYweOP/view?usp=sharing
In the zip file there 2 shapefile and 26 raster images.

description of the test bug:

1) load the shapefiles
2) load the rasters and wait that they are all displayed
3) zoom to an area that covers a part of the raster set
4) deactivate visibility to all the vector and raster layers
5) start to activate visibility to the layers one by one, starting from vectors 
(which should be the last below in the pile of layers)
6) when you reach at one of the continuous raster layer (DTMxx and Depitxx, 
Aspect, Slope) it may be show a wrong display (see wrong_display.png) instead 
of the right one (see right_display.png).

Note that, depending to the quantity of RAM that your OS uses you may or may 
not see the bug:
a) Roberto Rossi who uses Windows 10 with 8 Gb got the bug after reactivating 
visibility of few rasters
b) I use Ubuntu Mate with 6 RAM and I had to (re)load other 11 raster layersto 
GOT the bug.

Usually the bug disapears if the user zoom in to another area withing the same 
raster (not sure about zoom out). The bug disapears if RAM is free removing 
some layers (shapefiles) from the OpenJUMP project.



---

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] SVN: [6621] core/trunk/src/org/openjump/core/rasterimage/algorithms/ VectorizeAlgorithm.java

[Giuseppe Aruta]

Interesting. Thanks MIchael! I will study this modification... (Integer(ID)
was a left over from an old code.)
Peppe


Il giorno mer 11 nov 2020 alle ore 12:02 jump-pilot-svn--- via
Jump-pilot-devel  ha scritto:

> Revision: 6621
>   http://sourceforge.net/p/jump-pilot/code/6621
> Author:   michaudm
> Date: 2020-11-11 11:01:59 + (Wed, 11 Nov 2020)
> Log Message:
> ---
> Fix #510 + acceleration
>
> Modified Paths:
> --
>
> core/trunk/src/org/openjump/core/rasterimage/algorithms/VectorizeAlgorithm.java
>
> Modified:
> core/trunk/src/org/openjump/core/rasterimage/algorithms/VectorizeAlgorithm.java
> ===
> ---
> core/trunk/src/org/openjump/core/rasterimage/algorithms/VectorizeAlgorithm.java
>2020-11-11 10:30:58 UTC (rev 6620)
> +++
> core/trunk/src/org/openjump/core/rasterimage/algorithms/VectorizeAlgorithm.java
>2020-11-11 11:01:59 UTC (rev 6621)
> @@ -3,8 +3,7 @@
>  import java.awt.Point;
>  import java.awt.geom.Point2D;
>  import java.awt.image.DataBuffer;
> -import java.util.ArrayList;
> -import java.util.Collections;
> +import java.util.*;
>
>  import org.openjump.core.rasterimage.sextante.OpenJUMPSextanteRasterLayer;
>  import
> org.openjump.core.rasterimage.sextante.rasterWrappers.GridWrapperNotInterpolated;
> @@ -43,24 +42,21 @@
>
>  public static WorkbenchFrame frame =
> JUMPWorkbench.getInstance().getFrame();
>
> -private static int arrPos(int valIn, double[] arrayIn) {
> +//private static int arrPos(double valIn, double[] arrayIn) {
> +//for (int i = 0; i < arrayIn.length; i++) {
> +//if (arrayIn[i] == valIn) {
> +//return i;
> +//}
> +//}
> +//return -1;
> +//}
>
> -int valOut = -;
> -for (int i = 0; i < arrayIn.length; i++) {
> -if (arrayIn[i] == valIn) {
> -valOut = i;
> -break;
> -}
> -}
> -return valOut;
> -}
> -
>  /**
>   * Create a FeatureCollection of polygons defining a
> GridWrapperNotInterpolated and number of band
>   * AdbToolbox algorithm
> - * @param gwrapper. GridWrapperNotInterpolated
> - * @param explodeMultipolygons. Explode MultiPolygons in Polygons
> - * @param band. Number of band (0,1,2,etc)
> + * @param gwrapper GridWrapperNotInterpolated
> + * @param explodeMultipolygons Explode MultiPolygons in Polygons
> + * @param band Number of band (0,1,2,etc)
>   * @return
>   */
>  public static FeatureCollection toPolygonsAdbToolBox(
> @@ -74,11 +70,12 @@
>  // Find unique values
>  final double[] uniqueVals = findUniqueVals(gwrapper, noData,
> band);
>  final int uniqueValsCount = uniqueVals.length;
> +final Map index = index(uniqueVals);
>  // Scan lines
>  @SuppressWarnings("unchecked")
>  final ArrayList[] arrAll = new
> ArrayList[uniqueValsCount];
>  for (int i = 0; i < arrAll.length; i++) {
> -arrAll[i] = new ArrayList();
> +arrAll[i] = new ArrayList<>();
>  }
>  final Coordinate[] coords = new Coordinate[5];
>  final PackedCoordinateSequenceFactory pcsf = new
> PackedCoordinateSequenceFactory();
> @@ -110,7 +107,8 @@
>  final CoordinateSequence cs = pcsf.create(coords);
>  lr = new LinearRing(cs, geomFactory);
>  polygon = new Polygon(lr, null, geomFactory);
> -arrAll[arrPos((int) oldVal,
> uniqueVals)].add(polygon);
> +//arrAll[arrPos((int) oldVal,
> uniqueVals)].add(polygon);
> +arrAll[index.get(oldVal)].add(polygon);
>  }
>  oldVal = val;
>  cStart = c;
> @@ -134,7 +132,7 @@
>  for (int g = 0; g < geom.getNumGeometries(); g++) {
>  feature = new BasicFeature(featSchema);
>  feature.setGeometry(geom.getGeometryN(g));
> -feature.setAttribute(1, new Integer(ID));
> +feature.setAttribute(1, ID);
>  feature.setAttribute(2, uniqueVals[i]);
>  featColl.add(feature);
>  ID++;
> @@ -141,7 +139,7 @@
>  }
>  } else {
>  feature = new BasicFeature(featSchema);
> -feature.setAttribute(1, new Integer(ID));
> +feature.setAttribute(1, ID);
>  feature.setGeometry(geom);
>  feature.setAttribute(2, uniqueVals[i]);
>  featColl.add(feature);
> @@ -183,6 +181,14 @@
>  return uniqueVals;
>  }
>
> +private static Map index(double[] values) {
> +Map map = new HashMap<>(values.length);
> +for (int i = 0 ; i < values.length ; i++) {
> +map.pu

Re: [JPP-Devel] [jump-pilot:bugs] #511 CropWarp raster plugin can't overload existing file

[Giuseppe Aruta]

I will check too, later. Anyhow I was planning to make some changes on this
tool in order to save cell size whenever the tool is used on Crop mode.
Peppe

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

> maybe it's related to memory usage? ..ede
> --
>
> * [bugs:#511]  CropWarp
> raster plugin can't overload existing file*
>
> *Status:* open
> *Milestone:* undecided
> *Created:* Tue Nov 10, 2020 10:01 PM UTC by michael michaud
> *Last Updated:* Wed Nov 11, 2020 09:02 AM UTC
> *Owner:* nobody
>
> If one process an image with CropWarpPlugin and try to save the result
> with the name of an existing image (want to replace the former image),
> there is no warning as in other plugins, and it produces a weird image
> (looks like a mixt between the old and the new image).
> --
>
> 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] #512 Georeferenced RasterImage : useless dialog to create a worlfile

[Giuseppe Aruta]

Originally the worldfile dialog was activated only:
fist
a) if there were no georeference tag into the file (GeoTIFF)
than
b) if there is no worldfile

Possibly, when we move to new framework to read TIFF something was broken.

Peppe

Il giorno mer 11 nov 2020 alle ore 09:30 michael michaud via
Jump-pilot-devel  ha scritto:

> --
>
> * [bugs:#512] 
> Georeferenced RasterImage : useless dialog to create a worlfile*
>
> *Status:* open
> *Milestone:* OJ_1.16
> *Created:* Wed Nov 11, 2020 08:29 AM UTC by michael michaud
> *Last Updated:* Wed Nov 11, 2020 08:29 AM UTC
> *Owner:* nobody
>
> Trying to open a georeferenced GeoTiff as a (Sextante) RasterImage , I'm
> invited to define the worldfile through a dialog box. Whatever I enter in
> the diaog box, the image will be georeferenced using the geotags of the
> geotiff, which is fine, but the dialogbox is misleading and will create a
> tfw file which is inconsistant with the geotiff tags.
> --
>
> 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] OpenJUMP Road map page

[Giuseppe Aruta]

Hi all,
I started to upgrade the road map page on our wiki:
http://ojwiki.soldin.de/index.php?title=OpenJUMP_Roadmap#OpenJUMP_2.0_.282021.3F.29
Please, if you can give a look and make your modifications and comments. I
think some voices could be removed (see plugin architecture or Kosmo style
implementation)
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] #510 Create Polygon From a Raster bug

[Giuseppe Aruta via Jump-pilot-devel]

Hi Michael,
...even the time to vectorialize a raster with continuous data like DTM084 is 
incredibly long...
In theory in mostly case an user chooses one of Raster->Vector tool according 
to the type of the raster she/he wants to convert:
a) a continuous raster like a DTM. Data are scattered in a continuous interval 
descibing a measure that gradually changes, for instance the elevation or a map 
of temperatures. An user wonts to convert into a contour lines (Raster to 
contours) or trasform into a discrete raster (eg. defining intervals of the 
measure: 10-30% slope, 31-50% slope and so on
a) a discrete raster can be converted to a polygon layer (the case of Raster to 
Polygons. See file UsoSuolo.tif by Roberto: each number with 3 digits (512, 
111, etc) define a unique usage of the soil (forsets, cultivar, urban, etc). 
There is neither no uniform measurement (a forest is different from a city) nor 
a continuous gradually change (after 111 there would be a 231 in the scale, for 
instance): we use number because we get advance  (and the limit) that the Z 
value of a raster accept only a number (float, double, integer or whatever, but 
only a number not a string).
Of coarse, if we consider the limit of the interval and the cell size, all the 
raster are tecnically discrete (each output polygon can have a size of the cell 
size: see Stefan's tools, create a grid of points/of polygons).
When I added this plugin to OpenJUMP I wanted to bypass in one time two 
problems:
a) Sextante Raster to  Vector tool on discrete raster sometimes was giving 
wierd results: island of no data where it was supposed to have valid data
b) the version of Raster to Polygon tool in OpenKLEM, derived from AdbToolbox 
software, was taking a longer time and giving sometimes a strange outputs (like 
sometimes self intersection polygons).
This plugin seems to solve both situations. OpenKLEM now refers to 
VectorizeAlgorithm class, part AdbToolbox. While embedded OpenJUMP plugin can 
use both algorithm. They both work, except if user wants to convert a 
continuous raster to polygons with AdbToolbox.
I will give a look and atry to correct or to add some type of check, studing a 
way to distinguish in OpenJUMP a continuous vs discrete raster, not sure if it 
possible (an histogram is required and OJ raster histogram plugin can take a 
very long time according the intervals. 

Best regards
Peppe


---

** [bugs:#510] Create Polygon From a Raster bug**

**Status:** open
**Milestone:** OJ_1.16
**Created:** Tue Nov 10, 2020 12:59 PM UTC by michael michaud
**Last Updated:** Tue Nov 10, 2020 12:59 PM UTC
**Owner:** nobody


The plugin has two modes : AdbToolbox and Sextante. With tiff images of type 
float like DTM084 from Roberto Rossi, I can vectorize with Sextante, but Adb 
throws en exception :
java.lang.ArrayIndexOutOfBoundsException: Index - out of bounds for length 
1925123
at 
org.openjump.core.rasterimage.algorithms.VectorizeAlgorithm.toPolygonsAdbToolBox(VectorizeAlgorithm.java:113)
at 
org.openjump.core.ui.plugin.raster.VectorizeToPolygonsPlugIn.run(VectorizeToPolygonsPlugIn.java:170)
at 
com.vividsolutions.jump.workbench.ui.task.TaskMonitorManager$TaskWrapper.run(TaskMonitorManager.java:151)



---

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] #509 GeoImage and RasterImageLayer : why JAI

[Giuseppe Aruta]

Hi all,
following Michael's comment I did a test on RasterImageLayer substituting
JAI in
private BufferedImage scaleImage() method and associated ( protected
BufferedImage getScaledImageMatchingVisible()).
This is the method I used:

 private BufferedImage scaleImage(BufferedImage srcImg, int xScale, int
yScale){
BufferedImage resizedBuf = new BufferedImage(xScale,
yScale,srcImg.getType());
Graphics2D g2 = resizedBuf.createGraphics();
g2.drawImage(srcImg, 0, 0, xScale, yScale, null);
g2.dispose();
return resizedBuf;
}

instead of JAI

 protected BufferedImage scaleImage(BufferedImage im, float xScale, float
yScale) {
System.setProperty("com.sun.media.jai.disableMediaLib", "true");
ParameterBlock pb = new ParameterBlock();
 pb.addSource(im);
 pb.add(xScale);
 pb.add(yScale);
return JAI.create("Scale", pb, null).getAsBufferedImage();
}

I  did a test loading the set of rasters that Roberto provided (26 raster)
and I didn't recognized a difference of
timing to load and display all the raster, not even a difference of RAM
usage: at the end OJ used around 260-270 Mb.
Even the time to redraw single raster seems to be very random (sometimes
JAI is faster other time graphics2D is faster)
Maybe further test are required.
Peppe


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

> the use of JAI operations saves memory afaik. . it ideally creates a chain
> from loading over computing to rendering.
>
> the scaling you mention above seems to use BufferedImage in memory, which
> of course is faster but needs the whole source image in memory. for cases
> like Sextante, where images are currently held in memory anyway this may
> not be a limiting factor so i'm all for the faster solution.
>
> ReferencedImage uses JAI RenderedOP up to rendering the image and *should*
> be therefore able to show bigger source images. never tested though.
>
> ..ede
> --
>
> * [bugs:#509]  GeoImage
> and RasterImageLayer : why JAI*
>
> *Status:* open
> *Milestone:* OJ_future
> *Created:* Sat Nov 07, 2020 09:12 PM UTC by michael michaud
> *Last Updated:* Sat Nov 07, 2020 09:12 PM UTC
> *Owner:* michael michaud
>
> GeoImage and RasterImageLayer process image using JAI :
> It crops and scales the visible part of the image. See also ticket 507.
> This ticket is about the choice of JAI to rescale the image. Following
> baeldung post https://www.baeldung.com/java-resize-image i tried with awt
> and graphics2D and rescaling seems to be much faster.
> Maybe JAI has a richer api for those who want more complex processing, but
> graphics2D propose several kind of interpolation through the
> RenderingHints, which may be enough.
> To be tested further after the move to github.
> --
>
> 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] SVN: [6618] core/trunk/src

[Giuseppe Aruta]

548,7 @@
>
>  /**
>   * TODO: sstein test - 25.Sept.2013
> - * @return
> + * @return number of bands
>   */
>  public int getNumBands(){
> return numBands;
> @@ -1612,17 +1555,16 @@
>  }
>
>  public void dispose() {
> -// TODO: probably a good idea to remove resources when the layer is
> closed up
> -// dunno what is needed to clean up Sextante though, hence leave it
> for now
> +// TODO: probably a good idea to remove resources when the layer
> is closed up
> +// dunno what is needed to clean up Sextante though, hence leave
> it for now
>  }
>
> -public Double getCellValue(Coordinate coordinate, int band) throws
> RasterDataNotFoundException, IOException {
> +public Double getCellValue(Coordinate coordinate, int band) throws
> IOException {
>
>  return getCellValue(coordinate.x, coordinate.y, band);
> -
>  }
>
> -public Double getCellValue(int col, int row, int band) throws
> RasterDataNotFoundException, IOException {
> +public Double getCellValue(int col, int row, int band) throws
> IOException {
>
>  int pos = row * origImageWidth + col;
>  if(pos <0 || pos > origImageWidth * origImageHeight) return null;
> @@ -1631,7 +1573,7 @@
>
>  }
>
> -public Double getCellValue(double coordX, double coordY, int band)
> throws RasterDataNotFoundException, IOException {
> +public Double getCellValue(double coordX, double coordY, int band)
> throws IOException {
>
>  double cellSizeX = (originalImageEnvelope.getMaxX() -
> originalImageEnvelope.getMinX()) / origImageWidth;
>  double cellSizeY = (originalImageEnvelope.getMaxY() -
> originalImageEnvelope.getMinY()) / origImageHeight;
> @@ -1641,13 +1583,13 @@
>
>  if(col <0 || col >= origImageWidth || row <0 || row >=
> origImageHeight) return null;
>
> -int pos = row * origImageWidth + col;
> -double value;
> -int bands = stats.getBandCount();
> -value = RasterImageIO.readCellValue(imageFileName, col, row,
> band);
> -
> -
> -  /*  if (stats.getBandCount()<3) {
> +//int pos = row * origImageWidth + col;
> +    //double value;
> +//int bands = stats.getBandCount();
> +return RasterImageIO.readCellValue(imageFileName, col, row, band);
> +
> +/*
> +if (stats.getBandCount()<3) {
>  value = RasterImageIO.readCellValue(imageFileName, col, row,
> band);
>  } else {
> try {
> @@ -1657,11 +1599,9 @@
>  } catch (ArrayIndexOutOfBoundsException e) {
> value = RasterImageIO.readCellValue(imageFileName,
> col, row, band);
>  }
> -}*/
> -return  value;
> -  //  return RasterImageIO.readCellValue(imageFileName, col, row,
> band);
> -
> -}
> +}
> +*/
> +}
>
>  public boolean isNoData(double value) {
>  if(Double.isInfinite(noDataValue) && Double.isInfinite(value)) {
> @@ -1677,19 +1617,15 @@
>  return metadata;
>  }
>
> -public class RasterDataNotFoundException extends Exception {
> +public static class RasterDataNotFoundException extends Exception {}
>
> -}
> -
>  public static Rectangle getViewportRectangle(WorkbenchContext
> workbenchContext) {
>
> -Rectangle viewportRectangle = new Rectangle(
> +return new Rectangle(
>  0,
>  0,
>
>  workbenchContext.getLayerViewPanel().getVisibleRect().width,
>
>  workbenchContext.getLayerViewPanel().getVisibleRect().height);
> -return viewportRectangle;
> -
>  }
>
>  public RasterSymbology getSymbology() {
> @@ -1699,13 +1635,6 @@
>  public void setSymbology(RasterSymbology symbology) throws
> NoninvertibleTransformException {
>  this.symbology = symbology;
>  symbologyChanged = true;
> -//setImage(stretchImageValuesForDisplay());
> -
> -//forceTotalRepaint();
> -//if (isFiringAppearanceEvents()) {
> -//fireAppearanceChanged();
> -//}
> -imageProcessingStep2 = null;
>  LayerViewPanel layerViewPanel =
> getWorkbenchContext().getLayerViewPanel();
>  if(layerViewPanel != null) {
>  layerViewPanel.getViewport().update();
> @@ -1732,24 +1661,20 @@
>   * as "Temporary layers"
>   */
>  public boolean isTemporaryLayer() {
> - if (imageFileName.contains(System.getProperty("java.io.tmpdir")))
> {
&g

Re: [JPP-Devel] elevation raster and commons imaging

[Giuseppe Aruta]

Hi Michael,
Roberto and I contacted  Alberto De Luca (Bertazza)  regarding
"if(needFreeRAM == false)" code and this is his answer:

*When I made the changes to the code for reading the rasters I remember
having studied RasterImageLayer class for a long time, and some things
remained mysterious anyway.*

*I think that commenting on the line of code indicated by Michaël
eliminates an optimization designed to make the display of small images
faster, without recreating them every time by calling the setImage ()
method.*

*By removing that check, the image is recreated every time the users pan /
zoom / refresh. I don't think there will be any memory problems, because
code that once ran only if there was a lot of free memory (needFreeRAM =
false) now always runs. Rather perhaps there will be a decrease in display
performance.*

*Alberto*



Il giorno mer 28 ott 2020 alle ore 15:49 Giuseppe Aruta <
giuseppe.ar...@gmail.com> ha scritto:

> Hi Michael.
> thanks for the comment. I made again the test removing that part of the
> code and I had no evidence of that bug (no spaghetti like shape). I was
> expecting some out of memory message that I didn't have, maybe because
> 37-39 raster layers loaded still use lesser memory that OJ uses on my PC
> (currently 6 Gb but I use Ubuntu Mate).
> I have no idea why that code was made for. If the reason was to avoid OJ
> to use more than 50% of RAM available to draw raster into the view, we can
> increase it to 70%. Or to reduce memory consumption on that process.
> Peppe
>
>
> Il giorno mar 27 ott 2020 alle ore 23:02 Michaud Michael <
> m.michael.mich...@orange.fr> ha scritto:
>
>> Hi,
>>
>> Thanks for the video. I also could reroduce the problem.
>>
>> I reduced the test to its minimum by setting -Xmx100M and trying to load
>> the hillshade tif alone.
>>
>> Surprinsingly, the problem occurs when used memory is about half of the
>> available memory.
>>
>> By chance, I found some code in RasterImageLayer which test when 50% of
>> the available memory is used, and managed to eliminate the black and white
>> strip effect by removing the test line 390 if(needFreeRAM == false).
>>
>> But honestly, this is a part of the code I'm not familiar with, and it
>> will take some more time if I want to understand why this code change
>> eliminate the visual effect and to check if it has unwanted side effects.
>>
>> The code seems to be from Stefan, and modified by bertazza. If someone
>> wants to take the challenge (and explain to me), he's welcome. Otherwise,
>> I'll try to study the code and propose a fix within a few days.
>>
>> Michaël
>>
>>
>>
>> As it is related to memory but happens before available memory is
>> completely exhausted
>>
>> *envoyé :* 27 octobre 2020 à 20:00
>> *de :* giuseppe.ar...@gmail.com
>> *à :* OpenJump develop and use 
>> *objet :* Re: [JPP-Devel] elevation raster and commons imaging
>>
>> After Roberto's video I was able to reproduce the bug. I had to load 39
>> (!) raster layers together the huge shapefiles (I used the same rasters
>> that Roberto kindly provided) before I had that spagetti shape raster our.
>> I have no idea about the reason of it. I can image it could be related to
>> the delay between the time the Raster is loaded and the time it is
>> completely drawn in the view. More files are loaded, more memory is
>> engaged, more time it takes to drive display a file.
>> Peppe
>>
>> --
>> Inviato da myMail per Android
>> martedì, 27 ottobre 2020, 07:18PM +01:00 da edgar.sol...@web.de:
>>
>> hey Roberto,
>>
>> this seems to fall through the cracks ;(. please try and report on the
>> following when you find the time
>>
>> > additionally please try your routine with r6564+ but instead of
>> Sextante image use the "Open->File->(Select your tifs, click Next)->(keep
>> Use same settings for *.tif enabled, Select *Buffered Image (Commons
>> Imaging)*, Click Finished). this merely is a rendering test, raster tools
>> will not work on it. please comment on speed, memory usage and overall
>> performance incl. bugs.
>>
>> thx.. 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] elevation raster and commons imaging

[Giuseppe Aruta]

Hi Michael.
thanks for the comment. I made again the test removing that part of the
code and I had no evidence of that bug (no spaghetti like shape). I was
expecting some out of memory message that I didn't have, maybe because
37-39 raster layers loaded still use lesser memory that OJ uses on my PC
(currently 6 Gb but I use Ubuntu Mate).
I have no idea why that code was made for. If the reason was to avoid OJ to
use more than 50% of RAM available to draw raster into the view, we can
increase it to 70%. Or to reduce memory consumption on that process.
Peppe


Il giorno mar 27 ott 2020 alle ore 23:02 Michaud Michael <
m.michael.mich...@orange.fr> ha scritto:

> Hi,
>
> Thanks for the video. I also could reroduce the problem.
>
> I reduced the test to its minimum by setting -Xmx100M and trying to load
> the hillshade tif alone.
>
> Surprinsingly, the problem occurs when used memory is about half of the
> available memory.
>
> By chance, I found some code in RasterImageLayer which test when 50% of
> the available memory is used, and managed to eliminate the black and white
> strip effect by removing the test line 390 if(needFreeRAM == false).
>
> But honestly, this is a part of the code I'm not familiar with, and it
> will take some more time if I want to understand why this code change
> eliminate the visual effect and to check if it has unwanted side effects.
>
> The code seems to be from Stefan, and modified by bertazza. If someone
> wants to take the challenge (and explain to me), he's welcome. Otherwise,
> I'll try to study the code and propose a fix within a few days.
>
> Michaël
>
>
>
> As it is related to memory but happens before available memory is
> completely exhausted
>
> *envoyé :* 27 octobre 2020 à 20:00
> *de :* giuseppe.ar...@gmail.com
> *à :* OpenJump develop and use 
> *objet :* Re: [JPP-Devel] elevation raster and commons imaging
>
> After Roberto's video I was able to reproduce the bug. I had to load 39
> (!) raster layers together the huge shapefiles (I used the same rasters
> that Roberto kindly provided) before I had that spagetti shape raster our.
> I have no idea about the reason of it. I can image it could be related to
> the delay between the time the Raster is loaded and the time it is
> completely drawn in the view. More files are loaded, more memory is
> engaged, more time it takes to drive display a file.
> Peppe
>
> --
> Inviato da myMail per Android
> martedì, 27 ottobre 2020, 07:18PM +01:00 da edgar.sol...@web.de:
>
> hey Roberto,
>
> this seems to fall through the cracks ;(. please try and report on the
> following when you find the time
>
> > additionally please try your routine with r6564+ but instead of Sextante
> image use the "Open->File->(Select your tifs, click Next)->(keep Use same
> settings for *.tif enabled, Select *Buffered Image (Commons Imaging)*,
> Click Finished). this merely is a rendering test, raster tools will not
> work on it. please comment on speed, memory usage and overall performance
> incl. bugs.
>
> thx.. 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] elevation raster and commons imaging

[giuseppe . aruta]

After Roberto's video I was able to reproduce the bug. I had to load 39 (!) 
raster layers together the huge shapefiles (I used the same rasters that 
Roberto kindly provided) before I had that spagetti shape raster our. I have no 
idea about the reason of it. I can image it could be related to the delay 
between the time the Raster is loaded and the time it is completely drawn in 
the view. More files are loaded, more memory is engaged, more time it takes to 
drive display a file.
Peppe
--
Inviato da myMail per Android martedì, 27 ottobre 2020, 07:18PM +01:00 da  
edgar.sol...@web.de :

>hey Roberto,
>
>this seems to fall through the cracks ;(. please try and report on the 
>following when you find the time
>
> additionally please try your routine with r6564+ but instead of Sextante 
> image use the "Open-> File-> (Select your tifs, click Next)-> (keep Use same 
> settings for *.tif enabled, Select *Buffered Image (Commons Imaging)*, Click 
> Finished). this merely is a rendering test, raster tools will not work on it. 
> please comment on speed, memory usage and overall performance incl. bugs.
>
>thx.. 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] SVN: [6615] plug-ins/CADExtension/trunk/src/org/openjump/advancedtools/ utils/WorkbenchUtils.java

[Giuseppe Aruta]

The idea is to migrate python consolle into CAD toolbox. The advantage is
to group all together some useful tools that are available on the python
console (like align and distribute tools, see Cad toolbox bar).

A further  step is to activate a python console itself and make it more
evident, via Cad Toolbox, like a hide/show panel.


Il giorno mar 27 ott 2020 alle ore 14:47  ha scritto:

> works again. i'm wondering where this CAD specific python console can be
> activated?
>
> also. why does it exist in parallel to the normal one and why does it need
> to be initialized with totally different code? ..ede
>
> On 10/27/2020 13:52, Giuseppe Aruta wrote:
> > Yes.
> > The problem is on line
> > ClassLoader classLoader =
> context.getWorkbench().getPlugInManager().getClassLoader();
> > 
> >
> > After searching in the code I changed it with the method
> > ClassLoader classLoader = context.getWorkbench()
> > .getPlugInManager().getPlugInClassLoader()
> >
> > and it seems to work fine (see OJ 6617 "Cross Fingers")
> >
> >
> >
> > Il giorno mar 27 ott 2020 alle ore 13:41  edgar.sol...@web.de>> ha scritto:
> >
> > Peppe,
> >
> > could you reproduce the issue on your side? i could, but weird thing
> is, it complains about a missing method that is definitely there. are you
> compiling against the latest OJ-Core?
> >
> > ..ede
> >
> > On 10/27/2020 13:37, jump-pilot-svn--- via Jump-pilot-devel wrote:
> > > Revision: 6615
> > >   http://sourceforge.net/p/jump-pilot/code/6615
> > > Author:   ma15569
> > > Date: 2020-10-27 12:37:37 + (Tue, 27 Oct 2020)
> > > Log Message:
> > > ---
> > > changed method to avoid exception
> > >
> > > Modified Paths:
> > > --
> > >
>  
> plug-ins/CADExtension/trunk/src/org/openjump/advancedtools/utils/WorkbenchUtils.java
> > >
> > > Modified:
> plug-ins/CADExtension/trunk/src/org/openjump/advancedtools/utils/WorkbenchUtils.java
> > > ===
> > > ---
> plug-ins/CADExtension/trunk/src/org/openjump/advancedtools/utils/WorkbenchUtils.java
> 2020-10-26 19:40:44 UTC (rev 6614)
> > > +++
> plug-ins/CADExtension/trunk/src/org/openjump/advancedtools/utils/WorkbenchUtils.java
> 2020-10-27 12:37:37 UTC (rev 6615)
> > > @@ -1175,7 +1175,7 @@
> > >   //  toolbox.setTitle("Jython");
> > >   // setup the interpreter
> > >   ClassLoader classLoader = context.getWorkbench()
> > > - .getPlugInManager().getClassLoader();
> > > +
>  .getPlugInManager().getPlugInClassLoader();//.getClassLoader();
> > >   Properties preProperties = new
> Properties(System.getProperties());
> > >   String homepath =
> preProperties.getProperty("user.home");
> > >
> > >
> > >
> > >
> > > ___
> > > Jump-pilot-devel mailing list
> > > Jump-pilot-devel@lists.sourceforge.net  Jump-pilot-devel@lists.sourceforge.net>
> > > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> > >
> >
> >
> >
> > ___
> > Jump-pilot-devel mailing list
> > Jump-pilot-devel@lists.sourceforge.net  Jump-pilot-devel@lists.sourceforge.net>
> > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> >
> >
> >
> > ___
> > Jump-pilot-devel mailing list
> > Jump-pilot-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> >
>
>
>
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] SVN: [6615] plug-ins/CADExtension/trunk/src/org/openjump/advancedtools/ utils/WorkbenchUtils.java

[Giuseppe Aruta]

Yes.
The problem is on line
ClassLoader classLoader =
context.getWorkbench().getPlugInManager().getClassLoader();


After searching in the code I changed it with the method
ClassLoader classLoader = context.getWorkbench()
.getPlugInManager().getPlugInClassLoader()

and it seems to work fine (see OJ 6617 "Cross Fingers")



Il giorno mar 27 ott 2020 alle ore 13:41  ha scritto:

> Peppe,
>
> could you reproduce the issue on your side? i could, but weird thing is,
> it complains about a missing method that is definitely there. are you
> compiling against the latest OJ-Core?
>
> ..ede
>
> On 10/27/2020 13:37, jump-pilot-svn--- via Jump-pilot-devel wrote:
> > Revision: 6615
> >   http://sourceforge.net/p/jump-pilot/code/6615
> > Author:   ma15569
> > Date: 2020-10-27 12:37:37 + (Tue, 27 Oct 2020)
> > Log Message:
> > ---
> > changed method to avoid exception
> >
> > Modified Paths:
> > --
> >
>  
> plug-ins/CADExtension/trunk/src/org/openjump/advancedtools/utils/WorkbenchUtils.java
> >
> > Modified:
> plug-ins/CADExtension/trunk/src/org/openjump/advancedtools/utils/WorkbenchUtils.java
> > ===
> > ---
> plug-ins/CADExtension/trunk/src/org/openjump/advancedtools/utils/WorkbenchUtils.java
> 2020-10-26 19:40:44 UTC (rev 6614)
> > +++
> plug-ins/CADExtension/trunk/src/org/openjump/advancedtools/utils/WorkbenchUtils.java
> 2020-10-27 12:37:37 UTC (rev 6615)
> > @@ -1175,7 +1175,7 @@
> >   //  toolbox.setTitle("Jython");
> >   // setup the interpreter
> >   ClassLoader classLoader = context.getWorkbench()
> > - .getPlugInManager().getClassLoader();
> > +
>  .getPlugInManager().getPlugInClassLoader();//.getClassLoader();
> >   Properties preProperties = new
> Properties(System.getProperties());
> >   String homepath = preProperties.getProperty("user.home");
> >
> >
> >
> >
> > ___
> > Jump-pilot-devel mailing list
> > Jump-pilot-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> >
>
>
>
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] SVN: [6611] core/trunk/src/com/vividsolutions/jump/workbench

[Giuseppe Aruta]

Please try version 6614.

Il giorno lun 26 ott 2020 alle ore 19:58 Rahkonen Jukka (MML) <
jukka.rahko...@maanmittauslaitos.fi> ha scritto:

> Hi,
>
> What I see is different row number in the first error when I click the CAD
> tool.
>
> java.lang.NoSuchMethodError:
> 'com.vividsolutions.jump.workbench.plugin.PlugInClassLoader
> com.vividsolutions.jump.workbench.plugin.PlugInManager.getClassLoader()'
> at
> org.openjump.advancedtools.utils.WorkbenchUtils.loadPython(WorkbenchUtils.java:1178)
> at
> org.openjump.advancedtools.EditToolboxCADPlugIn.initializeToolbox(EditToolboxCADPlugIn.java:145)
> at
> com.vividsolutions.jump.workbench.ui.toolbox.ToolboxPlugIn.getToolbox(ToolboxPlugIn.java:69)
>
> ...
> -Jukka-
>
>
> -Alkuperäinen viesti-
> Lähettäjä: jump-pilot-svn--- via Jump-pilot-devel <
> jump-pilot-devel@lists.sourceforge.net>
> Lähetetty: maanantai 26. lokakuuta 2020 19.06
> Vastaanottaja: jump-pilot-devel@lists.sourceforge.net
> Kopio: jump-pilot-...@lists.sourceforge.net
> Aihe: [JPP-Devel] SVN: [6611]
> core/trunk/src/com/vividsolutions/jump/workbench
>
> Revision: 6611
>   http://sourceforge.net/p/jump-pilot/code/6611
> Author:   edso
> Date: 2020-10-26 17:05:35 + (Mon, 26 Oct 2020)
> Log Message:
> ---
> should fix
>
> java.lang.NoSuchMethodError: 'java.lang.ClassLoader
> com.vividsolutions.jump.workbench.plugin.PlugInManager.getClassLoader()'
> at
> org.openjump.advancedtools.utils.WorkbenchUtils.loadPython(WorkbenchUtils.java:1173)
> at
> org.openjump.advancedtools.EditToolboxCADPlugIn.initializeToolbox(EditToolboxCADPlugIn.java:145)
> at
> com.vividsolutions.jump.workbench.ui.toolbox.ToolboxPlugIn.getToolbox(ToolboxPlugIn.java:69)
> ...
>
> Modified Paths:
> --
> core/trunk/src/com/vividsolutions/jump/workbench/JUMPWorkbench.java
>
> core/trunk/src/com/vividsolutions/jump/workbench/plugin/PlugInManager.java
>
> Modified:
> core/trunk/src/com/vividsolutions/jump/workbench/JUMPWorkbench.java
> ===
> --- core/trunk/src/com/vividsolutions/jump/workbench/JUMPWorkbench.java
> 2020-10-26 16:23:31 UTC (rev 6610)
> +++ core/trunk/src/com/vividsolutions/jump/workbench/JUMPWorkbench.java
> 2020-10-26 17:05:35 UTC (rev 6611)
> @@ -332,7 +332,7 @@
>plugInManager.addExtensionDir(dir);
>  }
>  // debugging output of all urls in our classloader
> -Logger.debug("Classpath ->
> "+Arrays.toString(plugInManager.getClassLoader().getURLs()));
> +Logger.debug("Classpath ->
> "+Arrays.toString(plugInManager.getPlugInClassLoader().getURLs()));
>
>  // Load drivers before initializing the frame because part of the
> frame
>  // initialization is the initialization of the driver dialogs. [Jon
>
> Modified:
> core/trunk/src/com/vividsolutions/jump/workbench/plugin/PlugInManager.java
> ===
> ---
> core/trunk/src/com/vividsolutions/jump/workbench/plugin/PlugInManager.java
> 2020-10-26 16:23:31 UTC (rev 6610)
> +++
> core/trunk/src/com/vividsolutions/jump/workbench/plugin/PlugInManager.java
> 2020-10-26 17:05:35 UTC (rev 6611)
> @@ -512,12 +512,22 @@
>  /**
>   * To access extension classes, use this ClassLoader rather than the
> default
>   * ClassLoader. Extension classes will not be present in the latter.
> + *
> + * @deprecated use {@link #getPlugInClassLoader()} instead
>   */
> -public PlugInClassLoader getClassLoader() {
> +public ClassLoader getClassLoader() {
>  return classLoader;
>  }
>
>  /**
> + * To access extension classes, use this ClassLoader rather than the
> default
> + * ClassLoader. Extension classes will not be present in the latter.
> + */
> +public PlugInClassLoader getPlugInClassLoader() {
> +return classLoader;
> +}
> +
> +/**
>   * fetch a list of folders holding extension jars that were added
> during start
>   */
>  public List getExtensionDirs(){
>
>
>
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] SVN: [6608] core/trunk/lib/plus/CadTools-1.0.jar

[Giuseppe Aruta]

Hi Jukka,
It should have been fix on OJ 6609
Peppe

Il giorno lun 26 ott 2020 alle ore 17:52 Rahkonen Jukka (MML) <
jukka.rahko...@maanmittauslaitos.fi> ha scritto:

> Hi,
>
> With OJ 6608 I see too CAD toolbox icons in the main toolbar and they both
> produce an error when pressed:
>
>
> java.lang.NoSuchMethodError: 'java.lang.ClassLoader
> com.vividsolutions.jump.workbench.plugin.PlugInManager.getClassLoader()'
> at
> org.openjump.advancedtools.utils.WorkbenchUtils.loadPython(WorkbenchUtils.java:1173)
> at
> org.openjump.advancedtools.EditToolboxCADPlugIn.initializeToolbox(EditToolboxCADPlugIn.java:145)
> at
> com.vividsolutions.jump.workbench.ui.toolbox.ToolboxPlugIn.getToolbox(ToolboxPlugIn.java:69)
> at
> com.vividsolutions.jump.workbench.ui.toolbox.ToolboxPlugIn.execute(ToolboxPlugIn.java:86)
> at
> com.vividsolutions.jump.workbench.plugin.AbstractPlugIn$1.actionPerformed(AbstractPlugIn.java:344)
> at
> java.desktop/javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1967)
> at
> java.desktop/javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2308)
> at
> java.desktop/javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:405)
> at
> java.desktop/javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:262)
> at
> java.desktop/javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:279)
> at
> java.desktop/java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:297)
> at
> java.desktop/java.awt.Component.processMouseEvent(Component.java:6632)
> at
> java.desktop/javax.swing.JComponent.processMouseEvent(JComponent.java:3342)
> at
> java.desktop/java.awt.Component.processEvent(Component.java:6397)
> at
> java.desktop/java.awt.Container.processEvent(Container.java:2263)
> at
> java.desktop/java.awt.Component.dispatchEventImpl(Component.java:5008)
> at
> java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2321)
> at
> java.desktop/java.awt.Component.dispatchEvent(Component.java:4840)
> at
> java.desktop/java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4918)
> at
> java.desktop/java.awt.LightweightDispatcher.processMouseEvent(Container.java:4547)
> at
> java.desktop/java.awt.LightweightDispatcher.dispatchEvent(Container.java:4488)
> at
> java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2307)
> at java.desktop/java.awt.Window.dispatchEventImpl(Window.java:2772)
> at
> java.desktop/java.awt.Component.dispatchEvent(Component.java:4840)
> at
> java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:772)
> at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
> at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715)
> at java.base/java.security.AccessController.doPrivileged(Native
> Method)
> at
> java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
> at
> java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:95)
> at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:745)
> at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:743)
> at java.base/java.security.AccessController.doPrivileged(Native
> Method)
> at
> java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
> at
> java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742)
> at
> java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
> at
> java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
> at
> java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
> at
> java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
> at
> java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
> at
> java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)
>
> -Jukka Rahkonen-
>
> -Alkuperäinen viesti-
> Lähettäjä: jump-pilot-svn--- via Jump-pilot-devel <
> jump-pilot-devel@lists.sourceforge.net>
> Lähetetty: maanantai 26. lokakuuta 2020 18.09
> Vastaanottaja: jump-pilot-devel@lists.sourceforge.net
> Kopio: jump-pilot-...@lists.sourceforge.net
> Aihe: [JPP-Devel] SVN: [6608] core/trunk/lib/plus/CadTools-1.0.jar
>
> Revision: 6608
>   http://sourceforge.net/p/jump-pilot/code/6608
> Author:   ma15569
> Date: 2020-10-26 16:09:13 + (Mon, 26 Oct 2020)
> Log Message:
> ---
> Updated CadTools to version 1.0: activated Add and Remobe area plugin to
> test complementary editi

[JPP-Devel] [jump-pilot:bugs] #508 Possible bug on Interior Border, Basic Style

[Giuseppe Aruta via Jump-pilot-devel]

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



---

** [bugs:#508] Possible bug on Interior Border, Basic Style**

**Status:** closed-fixed
**Milestone:** undecided
**Created:** Sun Oct 25, 2020 11:41 AM UTC by Giuseppe Aruta
**Last Updated:** Mon Oct 26, 2020 05:54 AM UTC
**Owner:** nobody
**Attachments:**

- [Schermata a 2020-10-25 
12-36-24.png](https://sourceforge.net/p/jump-pilot/bugs/508/attachment/Schermata%20a%202020-10-25%2012-36-24.png)
 (486.4 kB; image/png)


I got this bug when I tried to save a project with two WMS and one layer 
without a style. I attached the screenshot. OpenJUMP  version I used is 6596.


com.vividsolutions.jump.util.java2xml.XMLBinder$XMLBinderException: Could not 
find getter named like 'interiorBorder' class 
com.vividsolutions.jump.workbench.ui.renderer.style.BasicStyle
at 
com.vividsolutions.jump.util.java2xml.Java2XML.getter(Java2XML.java:199)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.access$000(Java2XML.java:50)
at 
com.vividsolutions.jump.util.java2xml.Java2XML$1.attributeSpecFound(Java2XML.java:106)
at 
com.vividsolutions.jump.util.java2xml.XMLBinder.visit(XMLBinder.java:384)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.write(Java2XML.java:84)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.access$200(Java2XML.java:50)
at 
com.vividsolutions.jump.util.java2xml.Java2XML$1.tagSpecFound(Java2XML.java:101)
at 
com.vividsolutions.jump.util.java2xml.XMLBinder.visit(XMLBinder.java:379)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.write(Java2XML.java:84)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.writeChildTag(Java2XML.java:149)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.writeChildTags(Java2XML.java:163)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.access$100(Java2XML.java:50)
at 
com.vividsolutions.jump.util.java2xml.Java2XML$1.tagSpecFound(Java2XML.java:89)
at 
com.vividsolutions.jump.util.java2xml.XMLBinder.visit(XMLBinder.java:379)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.write(Java2XML.java:84)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.access$200(Java2XML.java:50)
at 
com.vividsolutions.jump.util.java2xml.Java2XML$1.tagSpecFound(Java2XML.java:101)
at 
com.vividsolutions.jump.util.java2xml.XMLBinder.visit(XMLBinder.java:379)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.write(Java2XML.java:84)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.writeChildTag(Java2XML.java:149)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.writeChildTags(Java2XML.java:163)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.access$100(Java2XML.java:50)
at 
com.vividsolutions.jump.util.java2xml.Java2XML$1.tagSpecFound(Java2XML.java:89)
at 
com.vividsolutions.jump.util.java2xml.XMLBinder.visit(XMLBinder.java:379)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.write(Java2XML.java:84)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.writeChildTag(Java2XML.java:149)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.writeChildTags(Java2XML.java:163)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.access$100(Java2XML.java:50)
at 
com.vividsolutions.jump.util.java2xml.Java2XML$1.tagSpecFound(Java2XML.java:89)
at 
com.vividsolutions.jump.util.java2xml.XMLBinder.visit(XMLBinder.java:379)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.write(Java2XML.java:84)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.access$200(Java2XML.java:50)
at 
com.vividsolutions.jump.util.java2xml.Java2XML$1.tagSpecFound(Java2XML.java:101)
at 
com.vividsolutions.jump.util.java2xml.XMLBinder.visit(XMLBinder.java:379)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.write(Java2XML.java:84)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.write(Java2XML.java:75)
at 
com.vividsolutions.jump.workbench.ui.plugin.AbstractSaveProjectPlugIn.save(AbstractSaveProjectPlugIn.java:105)
at 
com.vividsolutions.jump.workbench.ui.plugin.SaveProjectAsPlugIn.execute(SaveProjectAsPlugIn.java:130)
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.proc

[JPP-Devel] [jump-pilot:bugs] #508 Possible bug on Interior Border, Basic Style

[Giuseppe Aruta via Jump-pilot-devel]

It is solved. Thanks Michael


---

** [bugs:#508] Possible bug on Interior Border, Basic Style**

**Status:** open
**Milestone:** undecided
**Created:** Sun Oct 25, 2020 11:41 AM UTC by Giuseppe Aruta
**Last Updated:** Sun Oct 25, 2020 01:02 PM UTC
**Owner:** nobody
**Attachments:**

- [Schermata a 2020-10-25 
12-36-24.png](https://sourceforge.net/p/jump-pilot/bugs/508/attachment/Schermata%20a%202020-10-25%2012-36-24.png)
 (486.4 kB; image/png)


I got this bug when I tried to save a project with two WMS and one layer 
without a style. I attached the screenshot. OpenJUMP  version I used is 6596.


com.vividsolutions.jump.util.java2xml.XMLBinder$XMLBinderException: Could not 
find getter named like 'interiorBorder' class 
com.vividsolutions.jump.workbench.ui.renderer.style.BasicStyle
at 
com.vividsolutions.jump.util.java2xml.Java2XML.getter(Java2XML.java:199)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.access$000(Java2XML.java:50)
at 
com.vividsolutions.jump.util.java2xml.Java2XML$1.attributeSpecFound(Java2XML.java:106)
at 
com.vividsolutions.jump.util.java2xml.XMLBinder.visit(XMLBinder.java:384)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.write(Java2XML.java:84)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.access$200(Java2XML.java:50)
at 
com.vividsolutions.jump.util.java2xml.Java2XML$1.tagSpecFound(Java2XML.java:101)
at 
com.vividsolutions.jump.util.java2xml.XMLBinder.visit(XMLBinder.java:379)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.write(Java2XML.java:84)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.writeChildTag(Java2XML.java:149)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.writeChildTags(Java2XML.java:163)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.access$100(Java2XML.java:50)
at 
com.vividsolutions.jump.util.java2xml.Java2XML$1.tagSpecFound(Java2XML.java:89)
at 
com.vividsolutions.jump.util.java2xml.XMLBinder.visit(XMLBinder.java:379)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.write(Java2XML.java:84)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.access$200(Java2XML.java:50)
at 
com.vividsolutions.jump.util.java2xml.Java2XML$1.tagSpecFound(Java2XML.java:101)
at 
com.vividsolutions.jump.util.java2xml.XMLBinder.visit(XMLBinder.java:379)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.write(Java2XML.java:84)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.writeChildTag(Java2XML.java:149)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.writeChildTags(Java2XML.java:163)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.access$100(Java2XML.java:50)
at 
com.vividsolutions.jump.util.java2xml.Java2XML$1.tagSpecFound(Java2XML.java:89)
at 
com.vividsolutions.jump.util.java2xml.XMLBinder.visit(XMLBinder.java:379)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.write(Java2XML.java:84)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.writeChildTag(Java2XML.java:149)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.writeChildTags(Java2XML.java:163)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.access$100(Java2XML.java:50)
at 
com.vividsolutions.jump.util.java2xml.Java2XML$1.tagSpecFound(Java2XML.java:89)
at 
com.vividsolutions.jump.util.java2xml.XMLBinder.visit(XMLBinder.java:379)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.write(Java2XML.java:84)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.access$200(Java2XML.java:50)
at 
com.vividsolutions.jump.util.java2xml.Java2XML$1.tagSpecFound(Java2XML.java:101)
at 
com.vividsolutions.jump.util.java2xml.XMLBinder.visit(XMLBinder.java:379)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.write(Java2XML.java:84)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.write(Java2XML.java:75)
at 
com.vividsolutions.jump.workbench.ui.plugin.AbstractSaveProjectPlugIn.save(AbstractSaveProjectPlugIn.java:105)
at 
com.vividsolutions.jump.workbench.ui.plugin.SaveProjectAsPlugIn.execute(SaveProjectAsPlugIn.java:130)
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

[JPP-Devel] [jump-pilot:bugs] #508 Possible bug on Interior Border, Basic Style

[Giuseppe Aruta via Jump-pilot-devel]

I confirm the same bug with latest OJ version 6601


---

** [bugs:#508] Possible bug on Interior Border, Basic Style**

**Status:** open
**Milestone:** undecided
**Created:** Sun Oct 25, 2020 11:41 AM UTC by Giuseppe Aruta
**Last Updated:** Sun Oct 25, 2020 11:41 AM UTC
**Owner:** nobody
**Attachments:**

- [Schermata a 2020-10-25 
12-36-24.png](https://sourceforge.net/p/jump-pilot/bugs/508/attachment/Schermata%20a%202020-10-25%2012-36-24.png)
 (486.4 kB; image/png)


I got this bug when I tried to save a project with two WMS and one layer 
without a style. I attached the screenshot. OpenJUMP  version I used is 6596.


com.vividsolutions.jump.util.java2xml.XMLBinder$XMLBinderException: Could not 
find getter named like 'interiorBorder' class 
com.vividsolutions.jump.workbench.ui.renderer.style.BasicStyle
at 
com.vividsolutions.jump.util.java2xml.Java2XML.getter(Java2XML.java:199)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.access$000(Java2XML.java:50)
at 
com.vividsolutions.jump.util.java2xml.Java2XML$1.attributeSpecFound(Java2XML.java:106)
at 
com.vividsolutions.jump.util.java2xml.XMLBinder.visit(XMLBinder.java:384)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.write(Java2XML.java:84)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.access$200(Java2XML.java:50)
at 
com.vividsolutions.jump.util.java2xml.Java2XML$1.tagSpecFound(Java2XML.java:101)
at 
com.vividsolutions.jump.util.java2xml.XMLBinder.visit(XMLBinder.java:379)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.write(Java2XML.java:84)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.writeChildTag(Java2XML.java:149)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.writeChildTags(Java2XML.java:163)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.access$100(Java2XML.java:50)
at 
com.vividsolutions.jump.util.java2xml.Java2XML$1.tagSpecFound(Java2XML.java:89)
at 
com.vividsolutions.jump.util.java2xml.XMLBinder.visit(XMLBinder.java:379)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.write(Java2XML.java:84)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.access$200(Java2XML.java:50)
at 
com.vividsolutions.jump.util.java2xml.Java2XML$1.tagSpecFound(Java2XML.java:101)
at 
com.vividsolutions.jump.util.java2xml.XMLBinder.visit(XMLBinder.java:379)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.write(Java2XML.java:84)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.writeChildTag(Java2XML.java:149)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.writeChildTags(Java2XML.java:163)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.access$100(Java2XML.java:50)
at 
com.vividsolutions.jump.util.java2xml.Java2XML$1.tagSpecFound(Java2XML.java:89)
at 
com.vividsolutions.jump.util.java2xml.XMLBinder.visit(XMLBinder.java:379)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.write(Java2XML.java:84)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.writeChildTag(Java2XML.java:149)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.writeChildTags(Java2XML.java:163)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.access$100(Java2XML.java:50)
at 
com.vividsolutions.jump.util.java2xml.Java2XML$1.tagSpecFound(Java2XML.java:89)
at 
com.vividsolutions.jump.util.java2xml.XMLBinder.visit(XMLBinder.java:379)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.write(Java2XML.java:84)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.access$200(Java2XML.java:50)
at 
com.vividsolutions.jump.util.java2xml.Java2XML$1.tagSpecFound(Java2XML.java:101)
at 
com.vividsolutions.jump.util.java2xml.XMLBinder.visit(XMLBinder.java:379)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.write(Java2XML.java:84)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.write(Java2XML.java:75)
at 
com.vividsolutions.jump.workbench.ui.plugin.AbstractSaveProjectPlugIn.save(AbstractSaveProjectPlugIn.java:105)
at 
com.vividsolutions.jump.workbench.ui.plugin.SaveProjectAsPlugIn.execute(SaveProjectAsPlugIn.java:130)
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.process

[JPP-Devel] [jump-pilot:bugs] #508 Possible bug on Interior Border, Basic Style

[Giuseppe Aruta via Jump-pilot-devel]

---

** [bugs:#508] Possible bug on Interior Border, Basic Style**

**Status:** open
**Milestone:** undecided
**Created:** Sun Oct 25, 2020 11:41 AM UTC by Giuseppe Aruta
**Last Updated:** Sun Oct 25, 2020 11:41 AM UTC
**Owner:** nobody
**Attachments:**

- [Schermata a 2020-10-25 
12-36-24.png](https://sourceforge.net/p/jump-pilot/bugs/508/attachment/Schermata%20a%202020-10-25%2012-36-24.png)
 (486.4 kB; image/png)


I got this bug when I tried to save a project with two WMS and one layer 
without a style. I attached the screenshot. OpenJUMP  version I used is 6596.


com.vividsolutions.jump.util.java2xml.XMLBinder$XMLBinderException: Could not 
find getter named like 'interiorBorder' class 
com.vividsolutions.jump.workbench.ui.renderer.style.BasicStyle
at 
com.vividsolutions.jump.util.java2xml.Java2XML.getter(Java2XML.java:199)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.access$000(Java2XML.java:50)
at 
com.vividsolutions.jump.util.java2xml.Java2XML$1.attributeSpecFound(Java2XML.java:106)
at 
com.vividsolutions.jump.util.java2xml.XMLBinder.visit(XMLBinder.java:384)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.write(Java2XML.java:84)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.access$200(Java2XML.java:50)
at 
com.vividsolutions.jump.util.java2xml.Java2XML$1.tagSpecFound(Java2XML.java:101)
at 
com.vividsolutions.jump.util.java2xml.XMLBinder.visit(XMLBinder.java:379)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.write(Java2XML.java:84)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.writeChildTag(Java2XML.java:149)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.writeChildTags(Java2XML.java:163)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.access$100(Java2XML.java:50)
at 
com.vividsolutions.jump.util.java2xml.Java2XML$1.tagSpecFound(Java2XML.java:89)
at 
com.vividsolutions.jump.util.java2xml.XMLBinder.visit(XMLBinder.java:379)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.write(Java2XML.java:84)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.access$200(Java2XML.java:50)
at 
com.vividsolutions.jump.util.java2xml.Java2XML$1.tagSpecFound(Java2XML.java:101)
at 
com.vividsolutions.jump.util.java2xml.XMLBinder.visit(XMLBinder.java:379)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.write(Java2XML.java:84)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.writeChildTag(Java2XML.java:149)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.writeChildTags(Java2XML.java:163)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.access$100(Java2XML.java:50)
at 
com.vividsolutions.jump.util.java2xml.Java2XML$1.tagSpecFound(Java2XML.java:89)
at 
com.vividsolutions.jump.util.java2xml.XMLBinder.visit(XMLBinder.java:379)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.write(Java2XML.java:84)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.writeChildTag(Java2XML.java:149)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.writeChildTags(Java2XML.java:163)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.access$100(Java2XML.java:50)
at 
com.vividsolutions.jump.util.java2xml.Java2XML$1.tagSpecFound(Java2XML.java:89)
at 
com.vividsolutions.jump.util.java2xml.XMLBinder.visit(XMLBinder.java:379)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.write(Java2XML.java:84)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.access$200(Java2XML.java:50)
at 
com.vividsolutions.jump.util.java2xml.Java2XML$1.tagSpecFound(Java2XML.java:101)
at 
com.vividsolutions.jump.util.java2xml.XMLBinder.visit(XMLBinder.java:379)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.write(Java2XML.java:84)
at 
com.vividsolutions.jump.util.java2xml.Java2XML.write(Java2XML.java:75)
at 
com.vividsolutions.jump.workbench.ui.plugin.AbstractSaveProjectPlugIn.save(AbstractSaveProjectPlugIn.java:105)
at 
com.vividsolutions.jump.workbench.ui.plugin.SaveProjectAsPlugIn.execute(SaveProjectAsPlugIn.java:130)
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)

[JPP-Devel] [jump-pilot:bugs] #504 TODO: OJ2.x

[Giuseppe Aruta via Jump-pilot-devel]

Hi Ede,
OJ can inizialize a plugin via default-plugins.xml. Do you recommend to use it? 
Peppe


---

** [bugs:#504] TODO: OJ2.x**

**Status:** open
**Milestone:** OJ_2.x
**Created:** Mon Sep 14, 2020 11:44 AM UTC by ede
**Last Updated:** Mon Sep 14, 2020 11:44 AM UTC
**Owner:** nobody


this is not actually a bug ticket, but a notepad for backward compatible 
breaking things to do in OJ2.x

FeatureInstaller
privatize Constructor
replace  new FeatureInstaller() with FeatureInstaller.getInstance() projectwide

rework I18N, see extra ticket https://sourceforge.net/p/jump-pilot/bugs/501/


---

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] #385 Paste Layerable fails to work with RasterImageLayer class

[Giuseppe Aruta via Jump-pilot-devel]

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



---

** [bugs:#385] Paste Layerable fails to work with RasterImageLayer class**

**Status:** closed-fixed
**Milestone:** OJ_1.16
**Labels:** RasterImageLayer 
**Created:** Mon Jan 19, 2015 05:35 PM UTC by Giuseppe Aruta
**Last Updated:** Sun Oct 18, 2020 01:25 PM UTC
**Owner:** nobody


It seems that Paste Raster layer plugin (of Sextante Raster Image Layer - layer 
context menu) has no effects on paste a raster layer. It returns a null point 
exception. See below for error details
ava.lang.NullPointerException
at 
com.vividsolutions.jump.workbench.ui.plugin.clipboard.PasteLayersPlugIn.execute(PasteLayersPlugIn.java:96)
at 
com.vividsolutions.jump.workbench.plugin.AbstractPlugIn$1.actionPerformed(AbstractPlugIn.java:342)
at 
javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2018)
at 
javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2341)



---

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] #385 Paste Layerable fails to work with RasterImageLayer class

[Giuseppe Aruta via Jump-pilot-devel]

Confirm the bug is solved on newer version of OpenJUMP. I clos the ticket


---

** [bugs:#385] Paste Layerable fails to work with RasterImageLayer class**

**Status:** pending
**Milestone:** OJ_1.16
**Labels:** RasterImageLayer 
**Created:** Mon Jan 19, 2015 05:35 PM UTC by Giuseppe Aruta
**Last Updated:** Wed Oct 14, 2020 04:43 AM UTC
**Owner:** nobody


It seems that Paste Raster layer plugin (of Sextante Raster Image Layer - layer 
context menu) has no effects on paste a raster layer. It returns a null point 
exception. See below for error details
ava.lang.NullPointerException
at 
com.vividsolutions.jump.workbench.ui.plugin.clipboard.PasteLayersPlugIn.execute(PasteLayersPlugIn.java:96)
at 
com.vividsolutions.jump.workbench.plugin.AbstractPlugIn$1.actionPerformed(AbstractPlugIn.java:342)
at 
javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2018)
at 
javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2341)



---

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] #385 Paste Layerable fails to work with RasterImageLayer class

[Giuseppe Aruta via Jump-pilot-devel]

Hi Michael,
sorry for that. I was working to solve problems on visibility/query on raster 
layers and I inadvertently reverted your change. I restore it back to 6399 and 
today I will do some tests
Peppe


---

** [bugs:#385] Paste Layerable fails to work with RasterImageLayer class**

**Status:** pending
**Milestone:** OJ_1.16
**Labels:** RasterImageLayer 
**Created:** Mon Jan 19, 2015 05:35 PM UTC by Giuseppe Aruta
**Last Updated:** Tue Oct 13, 2020 09:10 PM UTC
**Owner:** nobody


It seems that Paste Raster layer plugin (of Sextante Raster Image Layer - layer 
context menu) has no effects on paste a raster layer. It returns a null point 
exception. See below for error details
ava.lang.NullPointerException
at 
com.vividsolutions.jump.workbench.ui.plugin.clipboard.PasteLayersPlugIn.execute(PasteLayersPlugIn.java:96)
at 
com.vividsolutions.jump.workbench.plugin.AbstractPlugIn$1.actionPerformed(AbstractPlugIn.java:342)
at 
javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2018)
at 
javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2341)



---

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] #385 Paste Layerable fails to work with RasterImageLayer class

[Giuseppe Aruta via Jump-pilot-devel]

Using Ubuntu. Loading an image as RasterImageLayer (Sextante). Using the coomad 
"Copy selected layer"

I have this warning:
com.vividsolutions.jts.util.AssertionFailedException: Should never reach here
at 
com.vividsolutions.jts.util.Assert.shouldNeverReachHere(Assert.java:122)
at 
com.vividsolutions.jts.util.Assert.shouldNeverReachHere(Assert.java:111)
at 
com.vividsolutions.jump.workbench.ui.plugin.clipboard.LayerableClipboardPlugIn.cloneLayerable(LayerableClipboardPlugIn.java:71)
at 
com.vividsolutions.jump.workbench.ui.plugin.clipboard.CopySelectedLayersPlugIn.clone(CopySelectedLayersPlugIn.java:85)
at 
com.vividsolutions.jump.workbench.ui.plugin.clipboard.CopySelectedLayersPlugIn.execute(CopySelectedLayersPlugIn.java:68)
at 
com.vividsolutions.jump.workbench.plugin.AbstractPlugIn$1.actionPerformed(AbstractPlugIn.java:344)
at 
java.desktop/javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1967)



---

** [bugs:#385] Paste Layerable fails to work with RasterImageLayer class**

**Status:** pending
**Milestone:** OJ_1.16
**Labels:** RasterImageLayer 
**Created:** Mon Jan 19, 2015 05:35 PM UTC by Giuseppe Aruta
**Last Updated:** Mon Aug 31, 2020 09:11 AM UTC
**Owner:** nobody


It seems that Paste Raster layer plugin (of Sextante Raster Image Layer - layer 
context menu) has no effects on paste a raster layer. It returns a null point 
exception. See below for error details
ava.lang.NullPointerException
at 
com.vividsolutions.jump.workbench.ui.plugin.clipboard.PasteLayersPlugIn.execute(PasteLayersPlugIn.java:96)
at 
com.vividsolutions.jump.workbench.plugin.AbstractPlugIn$1.actionPerformed(AbstractPlugIn.java:342)
at 
javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2018)
at 
javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2341)



---

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] #291 Problem on drop-down menus

[Giuseppe Aruta via Jump-pilot-devel]

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



---

** [bugs:#291] Problem on drop-down menus**

**Status:** closed-fixed
**Milestone:** OJ_1.16
**Labels:** General / Other 
**Created:** Sat Mar 16, 2013 08:20 PM UTC by Giuseppe Aruta
**Last Updated:** Tue Oct 13, 2020 11:14 AM UTC
**Owner:** nobody


I found this bug on Ubuntu \(12.04\) with OpenJDK 1.6.  This bug is not evident 
on Windows or Mac with Oracle Java.  I didn't test right now on Ubuntu with 
Oracle Java.
Description
Sometimes Drop-down menu of Open File \(or similar Open Project or Add Raster 
ayer\) seems to works fine: a\) click on the arrow, b\) drop-down menu remains 
on the screen and users can choose the type of file.
But after using some times "Open Files" or similar \(included Open Wizard\), 
randomly, drop-down menu stops to work. This is the behaviour: a\) click on the 
arrow, b\) drop-down menu cames out, c\) if user realise mouse menu, drop down 
disappears and user cannot do any choice. 
Drop-down menu remains evident on the screen only if user leaves the cursor on 
the arrow with left button \(of mouse\)  presse: the only way, in this case, to 
choose type of file is to use keyboard up-down keys with a hand \(using the 
other to press on the drop-down arrow of the menu.
By the time that this behaviour comes out it remains until user closes OJ and 
reopens it.
regards

Peppe



---

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] #291 Problem on drop-down menus

[Giuseppe Aruta via Jump-pilot-devel]

I cannot observe this behaviour any more. It seems that it was solved in the 
time
Closed fixed


---

** [bugs:#291] Problem on drop-down menus**

**Status:** open
**Milestone:** OJ_1.16
**Labels:** General / Other 
**Created:** Sat Mar 16, 2013 08:20 PM UTC by Giuseppe Aruta
**Last Updated:** Sun Sep 13, 2020 05:42 PM UTC
**Owner:** nobody


I found this bug on Ubuntu \(12.04\) with OpenJDK 1.6.  This bug is not evident 
on Windows or Mac with Oracle Java.  I didn't test right now on Ubuntu with 
Oracle Java.
Description
Sometimes Drop-down menu of Open File \(or similar Open Project or Add Raster 
ayer\) seems to works fine: a\) click on the arrow, b\) drop-down menu remains 
on the screen and users can choose the type of file.
But after using some times "Open Files" or similar \(included Open Wizard\), 
randomly, drop-down menu stops to work. This is the behaviour: a\) click on the 
arrow, b\) drop-down menu cames out, c\) if user realise mouse menu, drop down 
disappears and user cannot do any choice. 
Drop-down menu remains evident on the screen only if user leaves the cursor on 
the arrow with left button \(of mouse\)  presse: the only way, in this case, to 
choose type of file is to use keyboard up-down keys with a hand \(using the 
other to press on the drop-down arrow of the menu.
By the time that this behaviour comes out it remains until user closes OJ and 
reopens it.
regards

Peppe



---

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:feature-requests] #271 Extend capaiblities of Cadplan vertex symbology plugin

[Giuseppe Aruta via Jump-pilot-devel]

---

** [feature-requests:#271] Extend capaiblities of Cadplan vertex symbology 
plugin**

**Status:** open
**Created:** Tue Oct 13, 2020 11:11 AM UTC by Giuseppe Aruta
**Last Updated:** Tue Oct 13, 2020 11:11 AM UTC
**Owner:** nobody




see email by Geoff:
New Vertex Symbols Plugin : 11. July 2007: 3:31

Dear Giuseppe

Thank you for your comments. Please see my responses below:

geoff

Giuseppe Aruta wrote:

> Hi Geoff,
>
> I would like to ask you some questions about your
> plugins. These are not requests, but ideas that I had
> since I think your plugins is very important for OJ
> and I use them quite a lot.
>
> 1) Do you plan to add on your vertex plugin the
> possibility to change type of symbols according to an
> attribute value (saving rotate according to another
> attribute)?

Currently it is only possible to change the symbol orientation according to an 
attribute value. It might be possible to change the size according to value - 
though this is more problematical as the ability of the observer to distinguish 
relative size is less that distinguishing relative rotation (at least I think 
it is!).
Changing the symbol type is probably not practical as is is assumed that the 
same symbol type applies to all vertices in a layer. This would require (I 
suspect) a change to the core Jump code (comments from developers please?). 
Currently, as you know, the vertex label provides a way of showing a (numeric) 
value at the vertex.

> I found an alternative way to it using labels for
> symbols (with extra fonts); but I still think that, if
> this will nicelly completed your plugin which becomes
> extremely useful in OJ.
>
>
> 3) a vertex symbol plugin changed radically the idea
> of labels. If people want to use labels with their
> symbols they found the difficulties that labels will
> be always on the top of them (expecially with big
> sized symbols). The question is : how difficult is to
> influence the label style in order that labels always
> stay outside defined size of symbols?
>

This would require an option in the core to set an offset for the label, 
according to the size of the symbol. Developers - any ideas?

> I thank you in advance for the answer and thanks again
> for the good job you make (very good the idea of WKT
> symbols!)
>
>
> Peppe
>



---

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:bugs] #89 label offset should be set according to symbol size

[Giuseppe Aruta via Jump-pilot-devel]

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



---

** [bugs:#89] label offset should be set according to symbol size**

**Status:** closed-invalid
**Milestone:** OJ_1.16
**Created:** Fri Jul 13, 2007 08:51 AM UTC by Anonymous
**Last Updated:** Tue Oct 13, 2020 11:08 AM UTC
**Owner:** Giuseppe Aruta


see email by Geoff: 
New Vertex Symbols Plugin : 11. July 2007: 3:31

Dear Giuseppe

Thank you for your comments.  Please see my responses below:

geoff

Giuseppe Aruta wrote:

> Hi Geoff,
>
> I would like to ask you some questions about your
> plugins. These are not requests, but ideas that I had
> since I think your plugins is very important for OJ
> and I use them quite a lot.
>
> 1\) Do you plan to add on your vertex plugin the
> possibility to  change type of symbols according to an
> attribute value \(saving rotate according to another
> attribute\)?   

Currently it is only possible to change the symbol orientation according to an 
attribute value.  It might be possible to change the size according to value - 
though this is more problematical as the ability of the observer to distinguish 
relative size is less that distinguishing relative rotation \(at least I think 
it is\!\).
Changing the symbol type is probably not practical as is is assumed that the 
same symbol type applies to all vertices in a layer.  This would require \(I 
suspect\) a change to the core Jump code \(comments from developers please?\).  
Currently, as you know, the vertex label provides a way of showing a 
\(numeric\) value at the vertex.

> I found  an alternative way to it using labels for
> symbols \(with extra fonts\); but I still think that, if
> this will nicelly completed your plugin which  becomes
> extremely useful in OJ.
>
>
> 3\) a vertex symbol plugin changed radically the idea
> of labels. If people want to use labels with their
> symbols they found the difficulties that labels will
> be always on the top of them \(expecially with big
> sized symbols\). The question is : how difficult is to
> influence the label style in order that labels always
> stay outside defined size of symbols?
>   

This would require an option in the core to set an offset for the label, 
according to the size of the symbol. Developers - any ideas?

> I thank you in advance for the answer and thanks again
> for the good job you make \(very good the idea of WKT
> symbols\!\)
>
>
> Peppe
>



---

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] #89 label offset should be set according to symbol size

[Giuseppe Aruta via Jump-pilot-devel]

I thgink we can close it. It was more like a feature request than a bug. At 
that time I was in the need to have a tool like that. Not now. I am goung to 
save it as Feature request


---

** [bugs:#89] label offset should be set according to symbol size**

**Status:** open
**Milestone:** OJ_1.16
**Created:** Fri Jul 13, 2007 08:51 AM UTC by Anonymous
**Last Updated:** Sun Sep 13, 2020 06:31 PM UTC
**Owner:** nobody


see email by Geoff: 
New Vertex Symbols Plugin : 11. July 2007: 3:31

Dear Giuseppe

Thank you for your comments.  Please see my responses below:

geoff

Giuseppe Aruta wrote:

> Hi Geoff,
>
> I would like to ask you some questions about your
> plugins. These are not requests, but ideas that I had
> since I think your plugins is very important for OJ
> and I use them quite a lot.
>
> 1\) Do you plan to add on your vertex plugin the
> possibility to  change type of symbols according to an
> attribute value \(saving rotate according to another
> attribute\)?   

Currently it is only possible to change the symbol orientation according to an 
attribute value.  It might be possible to change the size according to value - 
though this is more problematical as the ability of the observer to distinguish 
relative size is less that distinguishing relative rotation \(at least I think 
it is\!\).
Changing the symbol type is probably not practical as is is assumed that the 
same symbol type applies to all vertices in a layer.  This would require \(I 
suspect\) a change to the core Jump code \(comments from developers please?\).  
Currently, as you know, the vertex label provides a way of showing a 
\(numeric\) value at the vertex.

> I found  an alternative way to it using labels for
> symbols \(with extra fonts\); but I still think that, if
> this will nicelly completed your plugin which  becomes
> extremely useful in OJ.
>
>
> 3\) a vertex symbol plugin changed radically the idea
> of labels. If people want to use labels with their
> symbols they found the difficulties that labels will
> be always on the top of them \(expecially with big
> sized symbols\). The question is : how difficult is to
> influence the label style in order that labels always
> stay outside defined size of symbols?
>   

This would require an option in the core to set an offset for the label, 
according to the size of the symbol. Developers - any ideas?

> I thank you in advance for the answer and thanks again
> for the good job you make \(very good the idea of WKT
> symbols\!\)
>
>
> Peppe
>



---

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] 6506 loading raster test

[Giuseppe Aruta]

I asked Roberto to do some tests using other raster tools on OpenJUMP in
order to limit the possible "bug" to other sectors of Rater management
rather than loading.
Roberto valuated on the Digital Terrain Model(DTM) file those tools
a) RasterPropertiesPlugin and Compare raster layers, as these ones activate
methods on RasterImageLayer/RasterImageIO to retrieve data and statistics
b) Raster style plugin as this one activates method to build the visual
aspect of a raster layer on OpenJUMP, particularly the method
RasterImageLayer.createImage(BufferedImage).
According to Roberto tools of group (a) work fine with no problem, while
Raster style (b) dialog seems to allow to change style but it has no
effects on the view. The bug could be correlated to this method and we may
exclude  the loading framework.
I will give a look in the next few days. We made few changes but recently
we (I) reverted some as there was no need anymore thanks to Ede's work.
I ask Roberto to do this test:
a) load the files until one shows the bug.
b) save it as new file (tif and asc or flt)
c) load the new saved file and check if it shows the same behaviour as the
original.
Peppe

Il giorno lun 12 ott 2020 alle ore 12:49  ha scritto:

> thanks will try to reproduce it. additionally could you please test the
> Commons-Image Rendering as outlined below? thx.. ede
>
>
> On 10/2/2020 14:33, edgar.sol...@web.de wrote:
> SNIP
> >
> > additionally please try your routine with r6564 but instead of Sextante
> image use the "Open->File->(Select your tifs, click Next)->(keep Use same
> settings for *.tif enabled, Select *Buffered Image (Commons Imaging)*,
> Click Finished). this merely is a rendering test, raster tools will not
> work on it. please comment on speed, memory usage and overall performance
> incl. bugs.
> >
> > thanks.. ede
>
>
>
> On 10/9/2020 19:28, Roberto Rossi wrote:
> > Here I am, sorry for he delay.
> > I tested the 6589 release.
> > After having loaded 2 shapefile (the bigger shp is 95 Mb), I load the
> rasters, the 3rd o 4th raster loaded, present the visualization problems:
> > This how the Digital Terrain Model appears
> >
> > This how it should appear
> >
> > I noticed that with the same dataset the release 1.15 at first (when the
> zoom is pointing to the whole raster) shows the Digital Terrain Model all
> white, when you zoom in draws the raster correctly.
> >
> > Do you need the log file?
> >
> > Roberto
> >
> > Il 09/10/2020 14:48, edgar.sol...@web.de ha scritto:
> >> hey Rob,
> >>
> >> any news wrt. the below? ..ede
> >>
> >> On 10/2/2020 14:33, edgar.sol...@web.de wrote:
> >>> no problemo Rob, got a day job still ;)
> >>>
> >>> please try the latest snapshot r6563+ with Peppe's change.
> >>>
> >>> additionally please try your routine with r6564 but instead of
> Sextante image use the "Open->File->(Select your tifs, click Next)->(keep
> Use same settings for *.tif enabled, Select *Buffered Image (Commons
> Imaging)*, Click Finished). this merely is a rendering test, raster tools
> will not work on it. please comment on speed, memory usage and overall
> performance incl. bugs.
> >>>
> >>> thanks.. ede
> >>>
> >>> On 10/2/2020 0:28, Roberto Rossi wrote:
>  Hi Ede,
>  sorry for the late answer.
>  I tested the release 6562, and I continue to have the visualization
> problems in the continuous file (just after having used 500-600 Mb of
> Memory, for example loading the big SHP and some rasters).
>  The continuos raster are all the ones called DTMxx and Depitxx,
> Aspect, Slope
>  What I see is something like this:
> 
>  While I should see something like this:
> 
>  I noticed that the discrete raster (like CN, rasterizza, UsoSuolo),
> when this problem arises, become white instead than something like this:
> 
> 
> 
>  Roberto
> 
>  Il 30/09/2020 13:10, edgar.sol...@web.de ha scritto:
> > On 9/29/2020 16:41, Roberto Rossi wrote:
> >> Il 29/09/2020 15:00, edgar.sol...@web.de ha scritto:
> >>> Rob,
> >>>
> >>> does that happen with all files or can you pinpoint a specific
> layer/image?
> >> Ede,
> >> I noticed it for the continuos raster ad Digital terrain models
> (DTM), slope, hillshade.
> > Rob,
> >
> > can you point out which files in your RasterRefrontolo test set are
> DTM or the other kinds files? i am actually not GIS-guy at all ;)
> >
> > also. please try snapshot r6562 wrt. the "discrete rendering look"
> issue.
> >
> > thx ..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-de

[JPP-Devel] Move Rasterize plugin form Tool>Generate menu to Raster>Rasterize menu

[Giuseppe Aruta]

Hi all,
I am considering moving the new plugin "Rasterize vector layer" from menu
Tool>Generate to menu Raster>Rasterize (rasterize submenu).
The reason is to make it more evident to students who need to use it in a
raster analysis. Raster tools are already scattered between the OJ Raster
menu, Sextante and OpenKLEM plugin. A fourth place to find an important
tool will be a bit confusing, I think.
Peppe
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Fwd: Reading elevation data using Apache Commons Imaging

[Giuseppe Aruta]

Hi all,
First of all, I would like to thank Gary for the help to solve an important
issue in OpenJUMP.
This project is the result of a collaborative work of many people coming
from different experiences and using OpenJUMP for different purposes: work,
teaching, research. Extending this collaboration with other people from
other projects surely extends our knowledge and ability to improve both
OpenJUMP projects and our vision of a collaborative project open to anyone.
Thinking of that at the beginning OJ was considered a *good but only basic
vector-oriented GIS software*, it is a good result that actually OJ is used
in the University of Padua as basic software *to teach hydrology* *via
raster analysis*, which usually requires a large capability to manage data
and computation. The authors of these results are very good developers who
contributed during the years, I just remember  Alberto, Ede, Michael, Stefan and many others. I should thank all of
them. And Gery for his collaboration.

Best regards

Peppe




Il giorno lun 12 ott 2020 alle ore 12:30  ha scritto:

> Jukka, Peppe,
>
> way above by payment grade :).. any comment?.. ede
>
>
>  Forwarded Message 
> Subject:[JPP-Devel] Reading elevation data using Apache Commons
> Imaging
> Date:   Sun, 11 Oct 2020 23:28:38 -0400
> From:   Gary Lucas 
> Reply-To:   OpenJump develop and use <
> jump-pilot-devel@lists.sourceforge.net>
> To: jump-pilot-devel@lists.sourceforge.net
>
>
>
> I first heard about OpenJUMP last month when one of your users posted a
> bug report on the Apache Commons Imaging JIRA system (see
> https://issues.apache.org/jira/browse/IMAGING-265). The bug is fixed now
> and I am grateful for the folks here who brought it to my attention.
>
> Anyway, based on that posting, and some of the JPP documentation, I get
> the impression that Commons Imaging is used in at least some capacity in
> OpenJUMP.  So I thought that I would mention another relatively new feature
> in the Commons Imaging API: the ability to read floating-point elevation
> data from USGS 3DEP Cloud-Optimized GeoTIFF files.  This capability was
> introduced in the latest release of Commons Imaging
> (commons-imaging-1.0-alpha2).  I don’t know if it is something the project
> can take advantage of, but I thought I would bring it to your attention.
>
> If you would like more information on the feature, I’ve just posted an
> article and some sample code showing how to use the API for creating
> shaded-relief imagery.  While OpenJUMP already has its own shaded-relief
> capability through its Sextante plugin, I think that the article might be
> of interest to folks on this mailing list because it provides background on
> the USGS GeoTIFF files as well as discussing the algorithms for
> shaded-relief rendering.  If you are interested, you may access it at
>
> https://gwlucastrig.github.io/gridfour/notes/ElevationGeoTiff1.html
>
> Thanks, and good luck on the JUMP Pilot Project.  It is an impressive
> project and I look forward to studying it further.
>
> Gary
>
>
>
>
> ___
> 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] Problems on OJ SVN builds

[Giuseppe Aruta]

Hi Ede,
not sure what is the problem. it seems since version 6591
Peppe
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] SVN: [6566] plug-ins/GraphToolboxPlugin/trunk

[giuseppe . aruta]

Thanks Michael. Interesting new featured
--
Inviato da myMail per Android sabato, 03 ottobre 2020, 07:59PM +02:00 da 
jump-pilot-svn--- via Jump-pilot-devel  jump-pilot-devel@lists.sourceforge.net :

>Revision: 6566
>   http://sourceforge.net/p/jump-pilot/code/6566
>Author:   michaudm
>Date: 2020-10-03 17:59:16 + (Sat, 03 Oct 2020)
>Log Message:
>---
>Add Shreve, Horton and Hack Orders to Stream Order plugin
>
>Modified Paths:
>--
>plug-ins/GraphToolboxPlugin/trunk/build.xml
>plug-ins/GraphToolboxPlugin/trunk/doc/GraphToolboxExtension4OJ.odt
>plug-ins/GraphToolboxPlugin/trunk/doc/GraphToolboxExtension4OJ_fr.odt
>
>plug-ins/GraphToolboxPlugin/trunk/src/fr/michaelm/jump/plugin/graph/GraphExtension.java
>
>plug-ins/GraphToolboxPlugin/trunk/src/fr/michaelm/jump/plugin/graph/StrahlerNumberPlugIn.java
>
>plug-ins/GraphToolboxPlugin/trunk/src/fr/michaelm/jump/plugin/graph/graph.properties
>
>plug-ins/GraphToolboxPlugin/trunk/src/fr/michaelm/jump/plugin/graph/graph_cz.properties
>
>plug-ins/GraphToolboxPlugin/trunk/src/fr/michaelm/jump/plugin/graph/graph_fi.properties
>
>plug-ins/GraphToolboxPlugin/trunk/src/fr/michaelm/jump/plugin/graph/graph_fr.properties
>
>plug-ins/GraphToolboxPlugin/trunk/src/fr/michaelm/jump/plugin/graph/graph_it.properties
>
>Added Paths:
>---
>plug-ins/GraphToolboxPlugin/trunk/lib/jump-jgrapht-0.7.1.jar
>
>Removed Paths:
>-
>plug-ins/GraphToolboxPlugin/trunk/lib/jump-jgrapht-0.7.jar
>
>Modified: plug-ins/GraphToolboxPlugin/trunk/build.xml
>===
>--- plug-ins/GraphToolboxPlugin/trunk/build.xml2020-10-02 14:29:59 UTC 
>(rev 6565)
>+++ plug-ins/GraphToolboxPlugin/trunk/build.xml2020-10-03 17:59:16 UTC 
>(rev 6566)
>@@ -17,7 +17,7 @@
> 
> 
> 
>- 
>+ 
> 
> 
> 
>
>Modified: plug-ins/GraphToolboxPlugin/trunk/doc/GraphToolboxExtension4OJ.odt
>===
>(Binary files differ)
>
>Modified: plug-ins/GraphToolboxPlugin/trunk/doc/GraphToolboxExtension4OJ_fr.odt
>===
>(Binary files differ)
>
>Added: plug-ins/GraphToolboxPlugin/trunk/lib/jump-jgrapht-0.7.1.jar
>===
>(Binary files differ)
>
>Index: plug-ins/GraphToolboxPlugin/trunk/lib/jump-jgrapht-0.7.1.jar
>===
>--- plug-ins/GraphToolboxPlugin/trunk/lib/jump-jgrapht-0.7.1.jar   
>2020-10-02 14:29:59 UTC (rev 6565)
>+++ plug-ins/GraphToolboxPlugin/trunk/lib/jump-jgrapht-0.7.1.jar   
>2020-10-03 17:59:16 UTC (rev 6566)
>
>Property changes on: 
>plug-ins/GraphToolboxPlugin/trunk/lib/jump-jgrapht-0.7.1.jar
>___
>Added: svn:mime-type
>## -0,0 +1 ##
>+application/octet-stream
>\ No newline at end of property
>Deleted: plug-ins/GraphToolboxPlugin/trunk/lib/jump-jgrapht-0.7.jar
>===
>(Binary files differ)
>
>Modified: 
>plug-ins/GraphToolboxPlugin/trunk/src/fr/michaelm/jump/plugin/graph/GraphExtension.java
>===
>--- 
>plug-ins/GraphToolboxPlugin/trunk/src/fr/michaelm/jump/plugin/graph/GraphExtension.java
>2020-10-02 14:29:59 UTC (rev 6565)
>+++ 
>plug-ins/GraphToolboxPlugin/trunk/src/fr/michaelm/jump/plugin/graph/GraphExtension.java
>2020-10-03 17:59:16 UTC (rev 6566)
>@@ -35,8 +35,9 @@
>  * 
>*  CycleFinderPlugIn : computes a graph from a linear network and find base 
>cycles
>  * 
>  * @author Michaël Michaud
>- * @version 0.7.0 (2020-09-18)
>+ * @version 0.8.0 (2020-10-03)
>  */
>+//version 0.8.0 (2020-10-03) Add Shreve, Horton and Hack Orders to Stream 
>Order plugin
> //version 0.7.0 (2020-09-23) Make strahlerNumber plugin more memory friendly 
>and way faster
> //version 0.6.3 (2019-06-24) SkeletonPlugIn : improve meanWidth calculation
> //version 0.6.2 (2019-05-22) fix bug in SkeletonPlugIn : incorrect 
>relativeMinForkLength
>@@ -64,7 +65,7 @@
> }
> 
> public String getVersion() {
>-return "0.7.0 (2020-09-23)";
>+return "0.8.0 (2020-10-03)";
> }
> 
> public void configure(PlugInContext context) throws Exception {
>
>Modified: 
>plug-ins/GraphToolboxPlugin/trunk/src/fr/michaelm/jump/plugin/graph/StrahlerNumberPlugIn.java
>===
>--- 
>plug-ins/GraphToolboxPlugin/trunk/src/fr/michaelm/jump/plugin/graph/StrahlerNumberPlugIn.java
>  2020-10-02 14:29:59 UTC (rev 6565)
>+++ 
>plug-ins/GraphToolboxPlugin/trunk/src/fr/michaelm/jump/plugin/graph/StrahlerNumberPlugIn.java
>  2020-10-03 17:59:16 UTC (rev 6566)
>@@ -8,6 +8,7 @@
> import com.vividsolutions.jump.workbench.model.Layer;
> import com.vividsolutions.jump.

Re: [JPP-Devel] 6506 loading raster test

[Giuseppe Aruta]

Ede, Roberto,
I reverted a change made on display raster . The changes was
made in order to bypass the bug described by Michael :
498  Most GeoTIFF drivers
fail with a simple GeoTIFF image

The change was related to how OJ tries to display a raster  related to the
usage of RAM.
With the new framework to load TIF this change is unnecessary.
I am not sure if this is the reason of the bug described by Roberto (I
still cannot reproduce it on my Linux PC).
Peppe

Il giorno ven 2 ott 2020 alle ore 00:36 Roberto Rossi <
roberto.ro...@unipd.it> ha scritto:

> Hi Ede,
> sorry for the late answer.
> I tested the release 6562, and I continue to have the visualization
> problems in the continuous file (just after having used 500-600 Mb of
> Memory, for example loading the big SHP and some rasters).
> The continuos raster are all the ones called DTMxx and Depitxx, Aspect,
> Slope
> What I see is something like this:
>
> While I should see something like this:
>
> I noticed that the discrete raster (like CN, rasterizza, UsoSuolo), when
> this problem arises, become white instead than something like this:
>
>
>
> Roberto
>
> Il 30/09/2020 13:10, edgar.sol...@web.de ha scritto:
>
> On 9/29/2020 16:41, Roberto Rossi wrote:
>
> Il 29/09/2020 15:00, edgar.sol...@web.de ha scritto:
>
> Rob,
>
> does that happen with all files or can you pinpoint a specific layer/image?
>
> Ede,
> I noticed it for the continuos raster ad Digital terrain models (DTM), slope, 
> hillshade.
>
> Rob,
>
> can you point out which files in your RasterRefrontolo test set are DTM or 
> the other kinds files? i am actually not GIS-guy at all ;)
>
> also. please try snapshot r6562 wrt. the "discrete rendering look" issue.
>
> thx ..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] Activated Rasterize Vector layer plugin

[Giuseppe Aruta]

Good morning OpenJUMPers
Today I activated a new Plugin that rasterize a vector layer, according to
an attribute value and a cell size. Optionally the extension of
rasterization can be defined by the limite (envelope) of another layer
The plugin is available under Tools>Generate menu
Best regards
Giuseppe Aruta
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] RasterizePlugIn

[Giuseppe Aruta]

Hi Michael,
thanks for the comment. Indeed my idea was to test and refine the plugin
before to make available.
*- plugin throws a NPE if selected attribute contains nulls*
Thanks, I corrected it

*- RasterizeAlgorithm class : why don't you stick to CamelCase conventions
for method names?*
I will change the names of he methods





*The layer combobox is added 2 times, one with the
MultiInputDialogframework and one is created manually and added with
MultiFormUtils.Why did you try to manage the LayerComboBox manually ?Try to
stick to MultiInputDialog as much as possible. Missing capabilitiesmay be
discussed on the list*
I changed. MultiInputDialog is more easy to use. I like anyhow the idea to
distinguish the type of target layer (vector or images or raster image)



*Making a geometry valid is a single method call : maybe it is notuseful to
iterate several times through the collection to make geometriesvalid, then
to union them*
Later I realized that valid operation is not really needed. In the next
RasterizePlugin it will be excluded saving some seconds




*Union is a costly operation : would be interesting to check thatunioning
before rasterizing is worthwhile (I suppose rasterizingeach single feature
would produce the same result, even in case or overlaps). Is it faster to
union before or do you get a different result *?
Sextante Rasterize algorithm is more efficient and faster also if there are
few geometries to rasterize, no matter if they are big or small. A union,
even if it takes some resources from memory, will drastically reduce memory
consumption and time during rasterization. I also realized that a
clipping/selection operation limited to the features to rasterize at the
beginning of the process will save time and resources.




*UnionByAttributeValue : you only need geometry and an attribute for the
result schema. Other attributes are undefined (null in your case). Not a
big problem though.- UnionByAttributeValue : line 141 do nothing
featureCollection.getFeatures(**).get(0).getGeometry().*



*getFactory();- UnionByAttributeValue : lines 146, 147 do nothing
useful(using newSchema after that is just like using schema) FeatureSchema
newSchema;newSchema = schema;*

Removed. Thanks.

Peppe


Il giorno mar 22 set 2020 alle ore 19:07 Michaud Michael <
m.michael.mich...@orange.fr> ha scritto:

> Peppe,
>
> RasterizePlugIn is an interesting addition. Maybe you have not completely
> finished, sorry,
> I saw this today and had some time in the train to make a quick review :
>
> - plugin is not activated yet (not in default-plugin.xml)
> - not fully internationalized (method getName)
> - would be nice to have more comments/javadoc
> - plugin throws a NPE if selected attribute contains nulls
> - RasterizeAlgorithm class : why don't you stick to CamelCase conventions
> for method names ?
>
> About the UI :
> The layer combobox is added 2 times, one with the MultiInputDialog
> framework and one is created manually and added with MultiFormUtils.
> Why did you try to manage the LayerComboBox manually ?
> Try to stick to MultiInputDialog as much as possible. Missing capabilities
> may be discussed on the list
>
> About design or code details
> You added new methods in FeatureCollectionUtil to validate and union
> features, but methods are 80% redundant with existing plugins.
> - Making a geometry valid is a single method call : maybe it is not
> useful to iterate several times through the collection to make geometries
> valid, then to union them
> - Union is a costly operation : would be interesting to check that
> unioning before rasterizing is worthwhile (I suppose rasterizing
> each single feature would produce the same result, even in case or
> overlaps).
> Is it faster to union before or do you get a different result ?
> - You make features valid without cloning them : it means you change
> actual geometries.
> Are you sure the user want to change its geometries ? Cannot be reverted.
> - UnionByAttributeValue : you only need geometry and an attribute for the
> result schema.
> Other attributes are undefined (null in your case). Not a big problem
> though.
> - UnionByAttributeValue : line 141 do nothing
> featureCollection.getFeatures().get(0).getGeometry().getFactory();
> - UnionByAttributeValue : lines 146, 147 do nothing useful
> (using newSchema after that is just like using schema)
> FeatureSchema newSchema;
> newSchema = schema;
>
> 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] SVN: [6526] core/trunk/src

[Giuseppe Aruta]

Hi Ede
I am going to partially revert no data reading
back to Apache Commons Imaging
The reason is that the actual method that uses JAI (I added yesterday)
still throws a
NumberFormatException with one of the 24 test files that Roberto provided.
While commons imaging works file with all.
Peppe

Il giorno mer 23 set 2020 alle ore 18:22 jump-pilot-svn--- via
Jump-pilot-devel  ha scritto:

> Revision: 6526
>   http://sourceforge.net/p/jump-pilot/code/6526
> Author:   edso
> Date: 2020-09-23 16:22:46 + (Wed, 23 Sep 2020)
> Log Message:
> ---
> rename getImage() to getRenderedOp() because it's what it does
> keep getImage() deprecated for now
>
> Modified Paths:
> --
>
> core/trunk/src/com/vividsolutions/jump/workbench/imagery/geoimg/GeoRaster.java
> core/trunk/src/org/openjump/core/rasterimage/TiffUtilsV2.java
>
> Modified:
> core/trunk/src/com/vividsolutions/jump/workbench/imagery/geoimg/GeoRaster.java
> ===
> ---
> core/trunk/src/com/vividsolutions/jump/workbench/imagery/geoimg/GeoRaster.java
> 2020-09-23 16:20:40 UTC (rev 6525)
> +++
> core/trunk/src/com/vividsolutions/jump/workbench/imagery/geoimg/GeoRaster.java
> 2020-09-23 16:22:46 UTC (rev 6526)
> @@ -279,7 +279,12 @@
>protected void normalize(RenderedOp image) {
>}
>
> +  @Deprecated // use getRenderedOP() instead
>public RenderedOp getImage() throws ReferencedImageException {
> +return getRenderedOp();
> +  }
> +
> +  public RenderedOp getRenderedOp() throws ReferencedImageException {
>  if (src == null)
>readRasterfile();
>  return src;
>
> Modified: core/trunk/src/org/openjump/core/rasterimage/TiffUtilsV2.java
> ===
> --- core/trunk/src/org/openjump/core/rasterimage/TiffUtilsV2.java
>  2020-09-23 16:20:40 UTC (rev 6525)
> +++ core/trunk/src/org/openjump/core/rasterimage/TiffUtilsV2.java
>  2020-09-23 16:22:46 UTC (rev 6526)
> @@ -42,13 +42,12 @@
>// a File -> RenderedOp cache mapping to prevent recreating inputs for
> the same file
>private static HashMap geoRasterCache = new
> HashMap();
>
> -
>public static RenderedOp getRenderedOp(File tiffFile) throws
> IOException {
>  GeoReferencedRaster geoRaster = getGeoReferencedRaster(tiffFile);
>  RenderedOp rop;
>  try {
> -  rop = geoRaster.getImage();
> -} catch (ReferencedImageException e) {
> +  rop = geoRaster.getRenderedOp();
> +} catch (Exception e) {
>// TODO: handle errors better, wrapping it in IOException here
>//   because that's what's handled up from here
>throw new IOException(e);
>
>
>
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Fwd: [jira] [Commented] (IMAGING-267) Colorful rendering of b/w Monoband TIF

[Giuseppe Aruta]

*First off, this TIFF appears to be geophysical data.  But there are no
GeoTIFF tags bundled with the image. Judging from the ModelTiepointTag, it
appears that the original image was configured using a projected coordinate
system, maybe a UTM zone.  It might help me understand this better if there
were more location information attached to the image. Do you have that
information?*

No. This image comes from image samples used by Victor Oyala to test
Sextante and had no attached crs . I think this image is related to an UTM
zone in Spain.

*Secondly, I note that this TIFF file is not strictly-speaking an image ,
but is actually numerical data stored using the TIFF standard
floating-point raster format.  My guess is that it's probably elevations.
The ability to process TIFF files containing floating point data was
introduced in the most recent release of Commons Imaging.*

Yes, Those are elevation data

*I've attached the image I produced (ISSUE_267.JPG).  However, to create
it, I had to know before hand what the range of values was.  So my
application does a few extra steps that I did not show in the example
above.  I was wondering how the software you used handles this issue.  Is
it all automatic?*

Yes. In OpenJUMP reads the range either in a aux.xml sidecar file or it
computes using JAI.create("extrema") method

*Also, a second question I had is that the PhotometricInterpretation tag
given with your image is 1, which means "0 is black".   In other words, the
palette should range from the darkest shading for the lowest numerical
values to the lightest shading for the highest values. However, in looking
at your image I notice that the lowest value pixels are drawn in the
lightest colors, which seems to contradict the setting in the source TIFF
file.  In the image I've attached, the lowest value pixels are draw in the
darkest colors, which is consistent with the specification in the TIFF
image.  Is there some setting in the application you used that overwrites
the settings from the TIFF file?*

The  buffered Image to display into the view of the monoband is
overwritten  in order to define a range of colours used to display it (I
think it is the method stretchImageValuesForDisplay() in RasterImage
class). This method defines the range of colour (Bloack to white) and saves
as RasterImageSymbology map (sorry for bad explanation). Thus we can change
the range of colours, creating a discrete range instead of continuous one,
set a subrange/value of the pixel to a specific colour

Il giorno mar 22 set 2020 alle ore 15:33  ha scritto:

> hey Gang,
>
> Gary at Apache-Commons-Imaging has some questions regarding a monoband TIF
> i provided. would one of you with a deeper knowledge of rasters (Peppe,
> Jukka, both?) answer him please in the ticket linked below (you need an
> account, so may have to register, but it's painless and fast).
>
> thanks.. ede
>
>
>  Forwarded Message 
> Subject: [jira] [Commented] (IMAGING-267) Colorful rendering of b/w
> Monoband TIF
> Date: Tue, 22 Sep 2020 00:06:00 + (UTC)
> From: Gary Lucas (Jira) 
> To: edgar.sol...@web.de
>
>
>  [
> https://issues.apache.org/jira/browse/IMAGING-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17199709#comment-17199709
> ]
>
> Gary Lucas commented on IMAGING-267:
> 
>
> Thank you for posting the images. They may help to answer some issues I've
> wondered about for awhile.  I've inspected their content and I have a few
> questions for you.
>
> First off, this TIFF appears to be geophysical data.  But there are no
> GeoTIFF tags bundled with the image. Judging from the ModelTiepointTag, it
> appears that the original image was configured using a projected coordinate
> system, maybe a UTM zone.  It might help me understand this better if there
> were more location information attached to the image. Do you have that
> information?
>
> Secondly, I note that this TIFF file is not strictly-speaking an image ,
> but is actually numerical data stored using the TIFF standard
> floating-point raster format.  My guess is that it's probably elevations.
> The ability to process TIFF files containing floating point data was
> introduced in the most recent release of Commons Imaging.
>
> One challenge of floating point images is how to map the range of values
> to gray scale. In this case, the following text gives the TIFF Tags
> attached to the image:
>
> Directory 0 Has TIFF Image Data, description: Root
>   256 (0x100: ImageWidth): 601 (1 Long)
>   257 (0x101: ImageLength): 410 (1 Long)
>   258 (0x102: BitsPerSample): 32 (1 Short)
>   259 (0x103: Compression): 1 (1 Short)
>   262 (0x106: PhotometricInterpretation): 1 (Indicates "zero is black")
>   277 (0x115: SamplesPerPixel): 1 (1 Short)
>   278 (0x116: RowsPerStrip): 8 (1 Long)
>   339 (0x153: SampleFormat): 3 (Indicates float-point format)
>   33550 (0x830e: ModelPixelScaleTag): 25.0, 25.0 (2 Double)
>   33922 

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

[Giuseppe Aruta]

Removing common imaging also "prodigiously" solved the problem on AsterDem
dimension that Michael described in a previous post

Il giorno mar 22 set 2020 alle ore 18:20 Giuseppe Aruta <
giuseppe.ar...@gmail.com> ha scritto:

> Hi Ede,
> The changes I did:
> a) remove the reading of overviews as you suggested
> b) removed the usage of commons imaging to compute some metadata
> the reason is that those metadata  are already computed by method
> GeoReferencedRaster getGeoReferencedRaster(File tiffFile), except NoData,
> I also removed dependency to common imaging to read NoData and used
> JAI for that purpose.
> TiFFField unofficially used by GDAL to store nodata is 42113 and it is
> basically an ASCII tag.
> https://gdal.org/drivers/raster/gtiff.html.
> I added (lefted) also the possibility that the tag is decode as byte or
> float to  prevent errors
> With the raster files that Roberto provided, only one throws a
> NumberFormatException (depit084) so I left a standard value (-9.0D) in
> case the reading of NoData fails.
>
>
> Il giorno mar 22 set 2020 alle ore 18:07 jump-pilot-svn--- via
> Jump-pilot-devel  ha scritto:
>
>> Revision: 6518
>>   http://sourceforge.net/p/jump-pilot/code/6518
>> Author:   ma15569
>> Date: 2020-09-22 16:07:41 + (Tue, 22 Sep 2020)
>> Log Message:
>> ---
>> Added a new method to read Image and Metadata for TIF.
>> It gets rid of using Commons Imaging that sometimes throws exception
>> on both reading resolution of the image. Metadata are now decoded
>> partially via loaded GeoRasterImage or by using JAI to read noData value.
>> Removed code to read overviews.
>>
>> Modified Paths:
>> --
>> core/trunk/src/org/openjump/core/rasterimage/RasterImageIO.java
>> core/trunk/src/org/openjump/core/rasterimage/TiffUtilsV2.java
>>
>> Modified: core/trunk/src/org/openjump/core/rasterimage/RasterImageIO.java
>> ===
>> --- core/trunk/src/org/openjump/core/rasterimage/RasterImageIO.java
>>  2020-09-22 14:56:54 UTC (rev 6517)
>> +++ core/trunk/src/org/openjump/core/rasterimage/RasterImageIO.java
>>  2020-09-22 16:07:41 UTC (rev 6518)
>> @@ -140,11 +140,14 @@
>>  // Overviews overviews =
>> OverviewsUtils.getOverviews(new File(
>>  // fileNameOrURL), imageEnvelope);
>>
>> -  Envelope imageEnvelope = TiffUtilsV2.getEnvelope(tiffFile);
>> -  Overviews overviews = OverviewsUtils.getOverviews(new
>> File(fileNameOrURL), imageEnvelope);
>> +//  Envelope imageEnvelope = TiffUtilsV2.getEnvelope(tiffFile);
>> + // Overviews overviews = OverviewsUtils.getOverviews(new
>> File(fileNameOrURL), imageEnvelope);
>>
>> -  return TiffUtilsV2.readImage(tiffFile, viewPortEnvelope,
>> requestedRes, overviews, stats);
>> -
>> +//  return TiffUtilsV2.readImage(tiffFile, viewPortEnvelope,
>> requestedRes, overviews, stats);
>> +
>> +  // [Giuseppe Aruta 2020-sept-22] added new method that remove
>> overviews and gets metadata
>> +  // directly from GeoRasterImage or using JAI
>> +  return TiffUtilsV2.readImageAndMetadata(tiffFile,
>> viewPortEnvelope, requestedRes, stats);
>>  } else if (fileNameOrURL.toLowerCase().endsWith(".flt")) {
>>
>> GridFloat gf = new GridFloat(fileNameOrURL);
>>
>> Modified: core/trunk/src/org/openjump/core/rasterimage/TiffUtilsV2.java
>> ===
>> --- core/trunk/src/org/openjump/core/rasterimage/TiffUtilsV2.java
>>  2020-09-22 14:56:54 UTC (rev 6517)
>> +++ core/trunk/src/org/openjump/core/rasterimage/TiffUtilsV2.java
>>  2020-09-22 16:07:41 UTC (rev 6518)
>> @@ -29,6 +29,9 @@
>>  import org.apache.commons.imaging.formats.tiff.TiffImageParser;
>>  import org.xml.sax.SAXException;
>>
>> +import com.sun.media.jai.codec.FileSeekableStream;
>> +import com.sun.media.jai.codec.TIFFDirectory;
>> +import com.sun.media.jai.codec.TIFFField;
>>  import com.vividsolutions.jts.geom.Coordinate;
>>  import com.vividsolutions.jts.geom.Envelope;
>>  import com.vividsolutions.jump.workbench.Logger;
>> @@ -90,6 +93,7 @@
>>  return JAI.create("scale", parameterBlock);
>>}
>>
>> +
>>/**
>> * Method to build an ImageAndMetadata file
>> * An ImageAndMetadata groups the Envelope, the Image, the Statistics
>> and
>> @@ -201,7 +205,134 @@
>> }
&

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

[Giuseppe Aruta]

Hi Ede,
The changes I did:
a) remove the reading of overviews as you suggested
b) removed the usage of commons imaging to compute some metadata
the reason is that those metadata  are already computed by method
GeoReferencedRaster getGeoReferencedRaster(File tiffFile), except NoData,
I also removed dependency to common imaging to read NoData and used
JAI for that purpose.
TiFFField unofficially used by GDAL to store nodata is 42113 and it is
basically an ASCII tag.
https://gdal.org/drivers/raster/gtiff.html.
I added (lefted) also the possibility that the tag is decode as byte or
float to  prevent errors
With the raster files that Roberto provided, only one throws a
NumberFormatException (depit084) so I left a standard value (-9.0D) in
case the reading of NoData fails.


Il giorno mar 22 set 2020 alle ore 18:07 jump-pilot-svn--- via
Jump-pilot-devel  ha scritto:

> Revision: 6518
>   http://sourceforge.net/p/jump-pilot/code/6518
> Author:   ma15569
> Date: 2020-09-22 16:07:41 + (Tue, 22 Sep 2020)
> Log Message:
> ---
> Added a new method to read Image and Metadata for TIF.
> It gets rid of using Commons Imaging that sometimes throws exception
> on both reading resolution of the image. Metadata are now decoded
> partially via loaded GeoRasterImage or by using JAI to read noData value.
> Removed code to read overviews.
>
> Modified Paths:
> --
> core/trunk/src/org/openjump/core/rasterimage/RasterImageIO.java
> core/trunk/src/org/openjump/core/rasterimage/TiffUtilsV2.java
>
> Modified: core/trunk/src/org/openjump/core/rasterimage/RasterImageIO.java
> ===
> --- core/trunk/src/org/openjump/core/rasterimage/RasterImageIO.java
>  2020-09-22 14:56:54 UTC (rev 6517)
> +++ core/trunk/src/org/openjump/core/rasterimage/RasterImageIO.java
>  2020-09-22 16:07:41 UTC (rev 6518)
> @@ -140,11 +140,14 @@
>  // Overviews overviews =
> OverviewsUtils.getOverviews(new File(
>  // fileNameOrURL), imageEnvelope);
>
> -  Envelope imageEnvelope = TiffUtilsV2.getEnvelope(tiffFile);
> -  Overviews overviews = OverviewsUtils.getOverviews(new
> File(fileNameOrURL), imageEnvelope);
> +//  Envelope imageEnvelope = TiffUtilsV2.getEnvelope(tiffFile);
> + // Overviews overviews = OverviewsUtils.getOverviews(new
> File(fileNameOrURL), imageEnvelope);
>
> -  return TiffUtilsV2.readImage(tiffFile, viewPortEnvelope,
> requestedRes, overviews, stats);
> -
> +//  return TiffUtilsV2.readImage(tiffFile, viewPortEnvelope,
> requestedRes, overviews, stats);
> +
> +  // [Giuseppe Aruta 2020-sept-22] added new method that remove
> overviews and gets metadata
> +  // directly from GeoRasterImage or using JAI
> +  return TiffUtilsV2.readImageAndMetadata(tiffFile, viewPortEnvelope,
> requestedRes, stats);
>  } else if (fileNameOrURL.toLowerCase().endsWith(".flt")) {
>
> GridFloat gf = new GridFloat(fileNameOrURL);
>
> Modified: core/trunk/src/org/openjump/core/rasterimage/TiffUtilsV2.java
> ===
> --- core/trunk/src/org/openjump/core/rasterimage/TiffUtilsV2.java
>  2020-09-22 14:56:54 UTC (rev 6517)
> +++ core/trunk/src/org/openjump/core/rasterimage/TiffUtilsV2.java
>  2020-09-22 16:07:41 UTC (rev 6518)
> @@ -29,6 +29,9 @@
>  import org.apache.commons.imaging.formats.tiff.TiffImageParser;
>  import org.xml.sax.SAXException;
>
> +import com.sun.media.jai.codec.FileSeekableStream;
> +import com.sun.media.jai.codec.TIFFDirectory;
> +import com.sun.media.jai.codec.TIFFField;
>  import com.vividsolutions.jts.geom.Coordinate;
>  import com.vividsolutions.jts.geom.Envelope;
>  import com.vividsolutions.jump.workbench.Logger;
> @@ -90,6 +93,7 @@
>  return JAI.create("scale", parameterBlock);
>}
>
> +
>/**
> * Method to build an ImageAndMetadata file
> * An ImageAndMetadata groups the Envelope, the Image, the Statistics
> and
> @@ -201,7 +205,134 @@
> }
>
>   }
> +
> +
> +
> +
> +
> +  /**
> +   * New method to build an ImageAndMetadata file
> +   * An ImageAndMetadata groups the Envelope, the Image, the Statistics
> and
> +   * NoData value of a TIF file
> +   * Removed reading overviews and dependency to commons imaging library
> +   * @param tiffFile
> +   * @param viewportEnvelope
> +   * @param requestedRes
> +   * @param stats
> +   * @return ImageAndMetadata
> +   * @throws NoninvertibleTransformException
> +   * @throws IOException
> +   * @throws FileNotFoundException
> +   * @throws TiffTags.TiffReadingExcep

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

[Giuseppe Aruta]

Let us wait  for Michael and Jukka's opinion about it.
I am not sure but possibly it was request by one of the member of the list
years ago to Alberto De Luca who implemented this part of the code.
I prefer to  comment out and build a new clean method

Il giorno mar 22 set 2020 alle ore 15:29  ha scritto:

>
>
> On 9/22/2020 13:49, Giuseppe Aruta wrote:
> >> +   private static ImageAndMetadata readImage(File tiffFile, int
> overviewIndex, int indexStart, Point originalSize,
> >> +   Resolution originalCellSize, Envelope wholeImageEnvelope,
> Envelope viewportEnvelope, double noDataValue,
> >> +   Stats stats) throws IOException,
> NoninvertibleTransformException {
> >> +
> >> + ImageInputStream imageInputStream =
> ImageIO.createImageInputStream(tiffFile);
> >> + Iterator iterator =
> ImageIO.getImageReaders(imageInputStream);
> >
> > this seems to be a leftover. we want to enforce a specific TIFF reader,
> which seems not to be done here.
> >
> > why exactly are there two readImage() methods needed anyway? one should
> suffice. can you remove it?
> >
> > Not sure. As it tries to read overviews of a file from an external .ovr
> file. I have never used or found it in projects. Once I tried to save a
> tiff with overviews using QGIS: I had back two files, a TIF and a OVR one.
> But when I tried to load this  couple into OpenJUMP, it took so long that I
> gave up. AFAIR this was a request of many years ago from someone of the list
>
> why not remove it then, if it's not used or working anyway? if you want to
> keep it, to have a go at it in the future, i'd suggest to at least to
> deactivate it, just to make sure it is no code path used accidentially.
>
> a hack i use sometimes is to add
>
> // explain why!
> if (true) throw new java.lang.UnsupportedOperationException();
>
> before some code i want to deactivate. this way the code does not have to
> be commented out and stays readable but will not be used anyway.
>
> ..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] SVN: [6507] core/trunk/src/org/openjump/core/rasterimage

[Giuseppe Aruta]

*we already have support for reading
GeoReferencedRaster.parseGDALM**etaData(URI
uri) (seems format agnostic too). but that is depending on GDAL installed,
while the implementaion in TiffUtils.calculateStats() seems be plain java
utilizing some apache commons imaging code but is limited to TIFF files*.

Note that, together with Statistics, also NoData value is read using apache
commons. Possibly it can be used JAI staff instead (as in
AddRasterImageLayerWizard class).


Il giorno mar 22 set 2020 alle ore 13:49 Giuseppe Aruta <
giuseppe.ar...@gmail.com> ha scritto:

> > +   private static ImageAndMetadata readImage(File tiffFile, int
> overviewIndex, int indexStart, Point originalSize,
> > +   Resolution originalCellSize, Envelope wholeImageEnvelope,
> Envelope viewportEnvelope, double noDataValue,
> > +   Stats stats) throws IOException,
> NoninvertibleTransformException {
> > +
> > + ImageInputStream imageInputStream =
> ImageIO.createImageInputStream(tiffFile);
> > + Iterator iterator =
> ImageIO.getImageReaders(imageInputStream);
>
> this seems to be a leftover. we want to enforce a specific TIFF reader,
> which seems not to be done here.
>
> why exactly are there two readImage() methods needed anyway? one should
> suffice. can you remove it?
>
> Not sure. As it tries to read overviews of a file from an external .ovr
> file. I have never used or found it in projects. Once I tried to save a
> tiff with overviews using QGIS: I had back two files, a TIF and a OVR one.
> But when I tried to load this  couple into OpenJUMP, it took so long that I
> gave up. AFAIR this was a request of many years ago from someone of the list
>
> Il giorno mar 22 set 2020 alle ore 13:07  ha scritto:
>
>> we already have support for reading
>> GeoReferencedRaster.parseGDALMetaData(URI uri) (seems format agnostic too).
>> but that is depending on GDAL installed, while the implementaion in
>> TiffUtils.calculateStats() seems be plain java utilizing some apache
>> commons imaging code but is limited to TIFF files.
>>
>> note the following comment in GeoRefRaster
>>/**
>> * initialize the img and try to parse geo infos via (in this order)
>> * worldfile, gdal or geotiff
>> */
>>protected void readRasterfile() throws ReferencedImageException {
>>
>> tl;dr i am good with keeping the addtional metadata reading within
>> TiffUtils generally. still you my want to consider a caching approach there
>> as well if the info is accessed more than once and expected not to change
>> over the course of the runtime.
>>
>> ..ede
>>
>> On 9/22/2020 12:32, Giuseppe Aruta wrote:
>> > I will make those changes. Statistics are calculated in order to reuse
>> on raster analysis (sextante). It is also saved into a special .aux.xml
>> sidecar file.
>> > At this moment there is no need to implement GeoReferencedRaster with
>> Statistic read as it is uìused only by Sextante.
>> >
>> > Il giorno mar 22 set 2020 alle ore 11:59 > edgar.sol...@web.de>> ha scritto:
>> >
>> > hey Peppe,
>> >
>> > nice try, but no dice. the reason i created an explicit TiffUtilsV2
>> was
>> > to make sure it contains no reference to RasterImageIO or TiffTags
>> > anymore. the idea is to wrap GeoReferencedRaster functionality to
>> reuse.
>> > GeoReferencedRaster includes all functionality for retrieving an
>> > Envelope or dimensions needed.
>> >
>> > If you are lacking functionality in GeoReferencedRaster we may add
>> it
>> > accordingly.
>> >
>> > i cut some code parts below and commented them which should be
>> replaced
>> > by using GeoReferencedRaster routines. ..ede
>> >
>> >
>> >
>> > On 9/22/2020 11:26, jump-pilot-svn--- via Jump-pilot-devel wrote:
>> >  > Revision: 6507
>> >  > http://sourceforge.net/p/jump-pilot/code/6507 <
>> http://sourceforge.net/p/jump-pilot/code/6507>
>> >  > Author:   ma15569
>> >  > Date: 2020-09-22 09:26:19 + (Tue, 22 Sep 2020)
>> >  > Log Message:
>> >  > ---
>> >  > Ported functionality from TiffUtils to TiffUtilsV2.
>> >  > Make TiffUtils deprecated
>> >  >
>> > SNIP
>>
>>
>>
>>
>> ___
>> 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: [6507] core/trunk/src/org/openjump/core/rasterimage

[Giuseppe Aruta]

> +   private static ImageAndMetadata readImage(File tiffFile, int
overviewIndex, int indexStart, Point originalSize,
> +   Resolution originalCellSize, Envelope wholeImageEnvelope,
Envelope viewportEnvelope, double noDataValue,
> +   Stats stats) throws IOException,
NoninvertibleTransformException {
> +
> + ImageInputStream imageInputStream =
ImageIO.createImageInputStream(tiffFile);
> + Iterator iterator =
ImageIO.getImageReaders(imageInputStream);

this seems to be a leftover. we want to enforce a specific TIFF reader,
which seems not to be done here.

why exactly are there two readImage() methods needed anyway? one should
suffice. can you remove it?

Not sure. As it tries to read overviews of a file from an external .ovr
file. I have never used or found it in projects. Once I tried to save a
tiff with overviews using QGIS: I had back two files, a TIF and a OVR one.
But when I tried to load this  couple into OpenJUMP, it took so long that I
gave up. AFAIR this was a request of many years ago from someone of the list

Il giorno mar 22 set 2020 alle ore 13:07  ha scritto:

> we already have support for reading
> GeoReferencedRaster.parseGDALMetaData(URI uri) (seems format agnostic too).
> but that is depending on GDAL installed, while the implementaion in
> TiffUtils.calculateStats() seems be plain java utilizing some apache
> commons imaging code but is limited to TIFF files.
>
> note the following comment in GeoRefRaster
>/**
> * initialize the img and try to parse geo infos via (in this order)
> * worldfile, gdal or geotiff
> */
>protected void readRasterfile() throws ReferencedImageException {
>
> tl;dr i am good with keeping the addtional metadata reading within
> TiffUtils generally. still you my want to consider a caching approach there
> as well if the info is accessed more than once and expected not to change
> over the course of the runtime.
>
> ..ede
>
> On 9/22/2020 12:32, Giuseppe Aruta wrote:
> > I will make those changes. Statistics are calculated in order to reuse
> on raster analysis (sextante). It is also saved into a special .aux.xml
> sidecar file.
> > At this moment there is no need to implement GeoReferencedRaster with
> Statistic read as it is uìused only by Sextante.
> >
> > Il giorno mar 22 set 2020 alle ore 11:59  edgar.sol...@web.de>> ha scritto:
> >
> > hey Peppe,
> >
> > nice try, but no dice. the reason i created an explicit TiffUtilsV2
> was
> > to make sure it contains no reference to RasterImageIO or TiffTags
> > anymore. the idea is to wrap GeoReferencedRaster functionality to
> reuse.
> > GeoReferencedRaster includes all functionality for retrieving an
> > Envelope or dimensions needed.
> >
> > If you are lacking functionality in GeoReferencedRaster we may add it
> > accordingly.
> >
> > i cut some code parts below and commented them which should be
> replaced
> > by using GeoReferencedRaster routines. ..ede
> >
> >
> >
> > On 9/22/2020 11:26, jump-pilot-svn--- via Jump-pilot-devel wrote:
> >  > Revision: 6507
> >  > http://sourceforge.net/p/jump-pilot/code/6507 <
> http://sourceforge.net/p/jump-pilot/code/6507>
> >  > Author:   ma15569
> >  > Date: 2020-09-22 09:26:19 + (Tue, 22 Sep 2020)
> >  > Log Message:
> >  > ---
> >  > Ported functionality from TiffUtils to TiffUtilsV2.
> >  > Make TiffUtils deprecated
> >  >
> > SNIP
>
>
>
>
> ___
> 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: [6513] core/trunk/src/org/openjump/sigle/utilities/geom/ FeatureCollectionUtil.java

[Giuseppe Aruta]

OK

2020-09-22 13:28 GMT+02:00, edgar.sol...@web.de :
> Peppe,
>
> just rephrased/formatted/typofixed some more. can you check that it
> describes what is done? ..thx ede
>
> On 9/22/2020 13:26, jump-pilot-svn--- via Jump-pilot-devel wrote:
>> Revision: 6513
>>http://sourceforge.net/p/jump-pilot/code/6513
>> Author:   edso
>> Date: 2020-09-22 11:26:31 + (Tue, 22 Sep 2020)
>> Log Message:
>> ---
>> some rephrasing/formatting
>>
>> Modified Paths:
>> --
>>
>> core/trunk/src/org/openjump/sigle/utilities/geom/FeatureCollectionUtil.java
>>
>> Modified:
>> core/trunk/src/org/openjump/sigle/utilities/geom/FeatureCollectionUtil.java
>> ===
>> ---
>> core/trunk/src/org/openjump/sigle/utilities/geom/FeatureCollectionUtil.java  
>> 2020-09-22
>> 10:25:35 UTC (rev 6512)
>> +++
>> core/trunk/src/org/openjump/sigle/utilities/geom/FeatureCollectionUtil.java  
>> 2020-09-22
>> 11:26:31 UTC (rev 6513)
>> @@ -105,15 +105,18 @@
>>  /**
>>   * Method to make valid all the geometries of a 
>> FeatureCollection
>>   * using the class MakeValidOp.
>> + *
>>   * A geometry is not valid if it is not simple:
>> - * This condition occurs when any of the following conditions 
>> are
>> true:
>> - * Incorrect ring orientation (polygon), self-intersection rings
>> (polygon)
>> - * self-intersection path (polyline), unclosed ring (polygon)
>> - * (see also
>> https://desktop.arcgis.com/en/arcmap/latest/extensions/data-reviewer/finding-invalid-geometry.htm
>> - * for the complete list).
>> - * This method should be applied before merge feature
>> - * [see method unionByAttributeValue(FeatureCollection
>> featureCollection, String attrbuteName)]
>> - * as not simple geometries will be not processed
>> + *  This condition occurs when any of the following conditions 
>> are
>> true:
>> + *  Incorrect ring orientation (polygon), self-intersection 
>> rings
>> (polygon)
>> + *  self-intersection path (polyline), unclosed ring (polygon)
>> + *  (see also
>> https://desktop.arcgis.com/en/arcmap/latest/extensions/data-reviewer/finding-invalid-geometry.htm
>> + *  for the complete list).
>> + *
>> + * This method should be applied before merging features via
>> + * {@link #unionByAttributeValue(FeatureCollection, String)
>> + * because not simple geometries will be not processed
>> + *
>>   * @param FeatureCollection fc
>>   */
>>  public static void validFeatureCollection(FeatureCollection fc) 
>> {
>> @@ -128,13 +131,14 @@
>> }
>>  
>>  /**
>> - * Mathod to merge geometries of a FeaureCollection according
>> - * to the values of an attribute name
>> + * Merge features and their geometries in the FeatureCollection
>> given
>> + * when the given attribute name contains identical values
>> + *
>>   * @param FeatureCollection fc
>> - * @param String attrbuteName
>> + * @param String attributeName
>>   * @throws Exception
>>   */
>> - public static void unionByAttributeValue(FeatureCollection
>> featureCollection, String attrbuteName) throws Exception {
>> + public static void unionByAttributeValue(FeatureCollection
>> featureCollection, String attributeName) throws Exception {
>>FeatureSchema schema = 
>> featureCollection.getFeatureSchema();
>>if (featureCollection.getFeatures().size() > 1 &&
>>  
>> featureCollection.getFeatures().get(0).getGeometry() !=
>> null) {
>> @@ -149,7 +153,7 @@
>>  newSchema = schema;
>>  Map map = new HashMap> FeatureCollection>();
>>  for (Feature feature  : featureCollection.getFeatures())
>> {
>> - Object key = feature.getAttribute(attrbuteName);
>> + Object key = feature.getAttribute(attributeName);
>>   if (!map.containsKey(key)) {
>>   FeatureCollection fd = new
>> FeatureDataset(featureCollection.getFeatureSchema());
>>   fd.add(feature);
>> @@ -164,7 +168,7 @@
>>  FeatureCollection fca = map.get(key);
>>  if (fca.size() > 0) {
>>Feature feature = union(fca);
>> -  feature.setAttribute(attrbuteName, key);
>> +  feature.setAttribute(attributeName, key);
>>Feature newFeature = new
>> Ba

Re: [JPP-Devel] SVN: [6508] core/trunk/src/org/openjump/sigle/utilities/geom/ FeatureCollectionUtil.java

[Giuseppe Aruta]

com.vividsolutions.jump.util.CollectionUtil seemed to me too generic to add
these method. The only class I found that could have been used was Sigle one

Il giorno mar 22 set 2020 alle ore 13:17  ha scritto:

> any specific reason why you added it to the class in the sigle package?
> ..ede
>
> On 9/22/2020 12:25, Giuseppe Aruta wrote:
> > Done
> >
> > Il giorno mar 22 set 2020 alle ore 12:06  edgar.sol...@web.de>> ha scritto:
> >
> > Peppe, some comments inline below ..ede
> >
> > On 9/22/2020 11:30, jump-pilot-svn--- via Jump-pilot-devel wrote:
> >  > Revision: 6508
> >  > http://sourceforge.net/p/jump-pilot/code/6508 <
> http://sourceforge.net/p/jump-pilot/code/6508>
> >  > Author:   ma15569
> >  > Date: 2020-09-22 09:30:06 + (Tue, 22 Sep 2020)
> >  > Log Message:
> >  > ---
> >  > added two method to valid and to union by attribute a
> FeatureCollection
> >  >
> >  > Modified Paths:
> >  > --
> >  >
> core/trunk/src/org/openjump/sigle/utilities/geom/FeatureCollectionUtil.java
> >  >
> >  > Modified:
> core/trunk/src/org/openjump/sigle/utilities/geom/FeatureCollectionUtil.java
> >  >
> ===
> >  > ---
> core/trunk/src/org/openjump/sigle/utilities/geom/FeatureCollectionUtil.java
>  2020-09-22 09:26:19 UTC (rev 6507)
> >  > +++
> core/trunk/src/org/openjump/sigle/utilities/geom/FeatureCollectionUtil.java
>  2020-09-22 09:30:06 UTC (rev 6508)
> >  > @@ -8,12 +8,23 @@
> >  >
> >  >
> > SNIP
> >  >
> >  >   /**
> >  >* This class can check if a FeatureCollection has only one
> Geometry Type
> >  > @@ -22,7 +33,8 @@
> >  >* @author Erwan Bocher
> >  >* @author Olivier Bedel
> >  >* @version 2005-08-10
> >  > - *
> >  > + * @author Giuseppe Aruta [2020-07-22]
> >  > + * added two method to valid and to union by attribute a
> FeatureCollection
> >  >*/
> >  >
> >  >   public class FeatureCollectionUtil {
> >  > @@ -90,4 +102,88 @@
> >  >   return AttributesList;
> >  >
> >  >   }
> >  > + /**
> >  > +  * Method to make a FeatureCollection valid
> >  > +  * @param fc
> >  > +  */
> >
> > can you add to the javadoc exactly what is the method doing to make
> it valid? why wasn't it valid before?
> >
> >  > + public static void
> validFeatureCollection(FeatureCollection fc) {
> >  > + MakeValidOp makeValidOp = new MakeValidOp();
> >  > +  makeValidOp.setPreserveGeomDim(true);
> >  > +  makeValidOp.setPreserveDuplicateCoord(false);
> >  > +  for (Feature feature  : fc.getFeatures()) {
> >  > +   Geometry validGeom =
> makeValidOp.makeValid(feature.getGeometry());
> >  > +   feature.setGeometry(validGeom);
> >  > + }
> >  > +   // return fc;
> >  > +}
> >  > +
> >  > + /**
> >  > +  * Mathod to merge geometries of a FeaureCollection
> according
> >
> > probably "Method to merge geometries of a FeatureCollection
> according"
> >
> >  > +  * to an attribute
> >  > +  * @param featureCollection
> >  > +  * @param value
> >
> > what is the value. looks like the attribute name to me. please
> javadoc it
> >
> >  > +  * @throws Exception
> >  > +  */
> >  > +  public static void
> unionByAttributeValue(FeatureCollection featureCollection, String value)
> throws Exception {
> >  > +   FeatureSchema schema =
> featureCollection.getFeatureSchema();
> >  > +   if (featureCollection.getFeatures().size() >
> 1 &&
> >  > +
>  featureCollection.getFeatures().get(0).getGeometry() != null) {
> >  > +
>  featureCollection.getFeatures().get(0).getGeometry().getFactory();
> >  > + }
> >

[JPP-Devel] New tool to rasterize vectors

[Giuseppe Aruta]

Hi all,
Roberto Rossi and I made a revision on Rasterize vector layer tools in
OpenJUMP.
This functionality is quite essential in raster analysis as it allows to
transfer info in a raster to reuse in so-called Raster algebra to get new
information.
Generally, in a raster analysis, the number of vector files that can be
transformed into rasters can be huge. So the user  needs a fast and exact
rasterization tool

OpenJUMP currently has two tools: one on sextante toolbox and the other on
OpenKLEM plugin.

a) The one of OpenKLEM is quite exact on transformation but it takes a
quite long time to convert a vector file to a raster. In a test, using a
layer with 6000 polygons, this tool takes almost 4 to 5 minutes. It is not
acceptable if the user needs to convert many layers.

b) The tool in Sextante is very fast, basically 6 to 7 seconds for a layer
of 6000 polygons. The problem of this tool is that it requires that the
vector layer should be first validated to correct non simple geometries and
then the geometries must be merged according to common values from an
attribute name. The second (merge) is sequential to the first (validate).
All those three processes (Validate, Merge and Rasterize) are located into
different plugins between OJ and Sextante. Using all to rasterize a vector
will enlarge the time and actions and it will again not be acceptable if
the files to convert are many.

In order to solve this problem, I developed a Raterization plugin for
OpenJUMP, mostly reusing Sextante code but adding also the other
preprocesses (Validate and Merge). This plugin shows a relatively short
time to do all the process until rasterization (10 to 12 seconds).
I will add this plugin in the next days after doing some cleaning of code
Best regards

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

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

[Giuseppe Aruta]

I will make those changes. Statistics are calculated in order to reuse on
raster analysis (sextante). It is also saved into a special .aux.xml
sidecar file.
At this moment there is no need to implement GeoReferencedRaster with
Statistic read as it is uìused only by Sextante.

Il giorno mar 22 set 2020 alle ore 11:59  ha scritto:

> hey Peppe,
>
> nice try, but no dice. the reason i created an explicit TiffUtilsV2 was
> to make sure it contains no reference to RasterImageIO or TiffTags
> anymore. the idea is to wrap GeoReferencedRaster functionality to reuse.
> GeoReferencedRaster includes all functionality for retrieving an
> Envelope or dimensions needed.
>
> If you are lacking functionality in GeoReferencedRaster we may add it
> accordingly.
>
> i cut some code parts below and commented them which should be replaced
> by using GeoReferencedRaster routines. ..ede
>
>
>
> On 9/22/2020 11:26, jump-pilot-svn--- via Jump-pilot-devel wrote:
> > Revision: 6507
> >http://sourceforge.net/p/jump-pilot/code/6507
> > Author:   ma15569
> > Date: 2020-09-22 09:26:19 + (Tue, 22 Sep 2020)
> > Log Message:
> > ---
> > Ported functionality from TiffUtils to TiffUtilsV2.
> > Make TiffUtils deprecated
> >
> SNIP
> >
> >
> > Modified: core/trunk/src/org/openjump/core/rasterimage/TiffUtils.java
> > ===
> > --- core/trunk/src/org/openjump/core/rasterimage/TiffUtils.java
>  2020-09-21 13:32:21 UTC (rev 6506)
> > +++ core/trunk/src/org/openjump/core/rasterimage/TiffUtils.java
>  2020-09-22 09:26:19 UTC (rev 6507)
> > @@ -5,7 +5,6 @@
> SNIP
> >
> > Modified: core/trunk/src/org/openjump/core/rasterimage/TiffUtilsV2.java
> > ===
> > --- core/trunk/src/org/openjump/core/rasterimage/TiffUtilsV2.java
>  2020-09-21 13:32:21 UTC (rev 6506)
> > +++ core/trunk/src/org/openjump/core/rasterimage/TiffUtilsV2.java
>  2020-09-22 09:26:19 UTC (rev 6507)
> > @@ -1,14 +1,37 @@
> >   package org.openjump.core.rasterimage;
> >
> SNIP
> >
> > @@ -66,4 +89,283 @@
> >   renderedOp = JAI.create("scale", parameterBlock);
> >   return JAI.create("scale", parameterBlock);
> > }
> > +  public static ImageAndMetadata readImage(File tiffFile, Envelope
> viewportEnvelope, Resolution requestedRes,
> > +   Overviews overviews, Stats stats) throws
> NoninvertibleTransformException, IOException, FileNotFoundException,
> > +   TiffTags.TiffReadingException, Exception {
> > +
> > + // Try to read geotiff tags
> > + TiffTags.TiffMetadata tiffMetadata =
> TiffTags.readMetadata(tiffFile);
> > + int originalImageWidth = tiffMetadata.getColsCount();
> > + int originalImageHeight = tiffMetadata.getRowsCount();
> > + Resolution cellSize = tiffMetadata.getResolution();
> > + Double noData = tiffMetadata.getNoData();
> > +
> > + // Now try with tfw
> > + if (cellSize == null) {
> > +   WorldFileHandler worldFileHandler = new
> WorldFileHandler(tiffFile.getAbsolutePath(), true);
> > +   Envelope envelope =
> worldFileHandler.readWorldFile(originalImageWidth, originalImageHeight);
> > +   cellSize = new Resolution(envelope.getWidth() /
> originalImageWidth, envelope.getHeight() / originalImageHeight);
> > + }
>
> not needed. should be retrievable from GeoReferencedRaster
>
> > + Envelope wholeImageEnvelope =
> RasterImageIO.getGeoReferencing(tiffFile.getAbsolutePath(), true,
> > + new Point(originalImageWidth, originalImageHeight));
>
> Envelope as well.
>
> > + if (requestedRes == null) {
> > +   requestedRes = cellSize;
> > + }
> > +
> > + int overviewLevel = overviews.pickOverviewLevel(requestedRes);
> > +
> > + if (stats == null) {
> > +   // Statistics on all pixels
> > +   stats = calculateStats(tiffFile, noData, tiffFile);
> > + }
> > +
> SNIP
> > +   return imageAndMetadata;
> > +
> > + }
> > +
> > +   }
> > +
> > +   private static ImageAndMetadata readImage(File tiffFile, int
> overviewIndex, int indexStart, Point originalSize,
> > +   Resolution originalCellSize, Envelope wholeImageEnvelope,
> Envelope viewportEnvelope, double noDataValue,
> > +   Stats stats) throws IOException,
> NoninvertibleTransformException {
> > +
> > + ImageInputStream imageInputStream =
> ImageIO.createImageInputStream(tiffFile);
> > + Iterator iterator =
> ImageIO.getImageReaders(imageInputStream);
>
> this seems to be a leftover. we want to enforce a specific TIFF reader,
> which seems not to be done here.
>
> why exactly are there two readImage() methods needed anyway? one should
> suffice. can you remove it?
>
> > + if (iterator != null && iterator.hasNext()) {
> > +
> > +   ImageReader imageReader = iterator.next();
> > +   imageReader.setInput(imag

Re: [JPP-Devel] SVN: [6508] core/trunk/src/org/openjump/sigle/utilities/geom/ FeatureCollectionUtil.java

[Giuseppe Aruta]

Done

Il giorno mar 22 set 2020 alle ore 12:06  ha scritto:

> Peppe, some comments inline below ..ede
>
> On 9/22/2020 11:30, jump-pilot-svn--- via Jump-pilot-devel wrote:
> > Revision: 6508
> >http://sourceforge.net/p/jump-pilot/code/6508
> > Author:   ma15569
> > Date: 2020-09-22 09:30:06 + (Tue, 22 Sep 2020)
> > Log Message:
> > ---
> > added two method to valid and to union by attribute a FeatureCollection
> >
> > Modified Paths:
> > --
> >
> core/trunk/src/org/openjump/sigle/utilities/geom/FeatureCollectionUtil.java
> >
> > Modified:
> core/trunk/src/org/openjump/sigle/utilities/geom/FeatureCollectionUtil.java
> > ===
> > ---
> core/trunk/src/org/openjump/sigle/utilities/geom/FeatureCollectionUtil.java
>  2020-09-22 09:26:19 UTC (rev 6507)
> > +++
> core/trunk/src/org/openjump/sigle/utilities/geom/FeatureCollectionUtil.java
>  2020-09-22 09:30:06 UTC (rev 6508)
> > @@ -8,12 +8,23 @@
> >
> >
> SNIP
> >
> >   /**
> >* This class can check if a FeatureCollection has only one Geometry
> Type
> > @@ -22,7 +33,8 @@
> >* @author Erwan Bocher
> >* @author Olivier Bedel
> >* @version 2005-08-10
> > - *
> > + * @author Giuseppe Aruta [2020-07-22]
> > + * added two method to valid and to union by attribute a
> FeatureCollection
> >*/
> >
> >   public class FeatureCollectionUtil {
> > @@ -90,4 +102,88 @@
> >   return AttributesList;
> >
> >   }
> > + /**
> > +  * Method to make a FeatureCollection valid
> > +  * @param fc
> > +  */
>
> can you add to the javadoc exactly what is the method doing to make it
> valid? why wasn't it valid before?
>
> > + public static void
> validFeatureCollection(FeatureCollection fc) {
> > + MakeValidOp makeValidOp = new MakeValidOp();
> > +  makeValidOp.setPreserveGeomDim(true);
> > +  makeValidOp.setPreserveDuplicateCoord(false);
> > +  for (Feature feature  : fc.getFeatures()) {
> > +   Geometry validGeom =
> makeValidOp.makeValid(feature.getGeometry());
> > +   feature.setGeometry(validGeom);
> > + }
> > +   // return fc;
> > +}
> > +
> > + /**
> > +  * Mathod to merge geometries of a FeaureCollection
> according
>
> probably "Method to merge geometries of a FeatureCollection according"
>
> > +  * to an attribute
> > +  * @param featureCollection
> > +  * @param value
>
> what is the value. looks like the attribute name to me. please javadoc it
>
> > +  * @throws Exception
> > +  */
> > +  public static void
> unionByAttributeValue(FeatureCollection featureCollection, String value)
> throws Exception {
> > +   FeatureSchema schema =
> featureCollection.getFeatureSchema();
> > +   if (featureCollection.getFeatures().size() > 1 &&
> > +
>  featureCollection.getFeatures().get(0).getGeometry() != null) {
> > +
>  featureCollection.getFeatures().get(0).getGeometry().getFactory();
> > + }
> > + else {
> > + Logger.error(
> > +
>  I18N.get("ui.plugin.analysis.DissolvePlugIn.needs-two-features-or-more"));
> > +   // return null;
> > + }
> > + FeatureSchema newSchema;
> > + newSchema = schema;
> > + Map map = new
> HashMap();
> > + for (Feature feature  :
> featureCollection.getFeatures()) {
> > +  Object key = feature.getAttribute(value);
> > +  if (!map.containsKey(key)) {
> > +  FeatureCollection fd = new
> FeatureDataset(featureCollection.getFeatureSchema());
> > +  fd.add(feature);
> > +  map.put(key, fd);
> > +  }  else {
> > +  map.get(key).add(feature);
> > +  }
> > +  }
> > +
>  featureCollection.removeAll(featureCollection.getFeatures());
> > + 

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

[Giuseppe Aruta]

OK. I will do

2020-09-21 18:31 GMT+02:00, edgar.sol...@web.de :
> On 21.09.2020 17:19, Giuseppe Aruta wrote:
>> Hi Ede,
>> it works fine. I was able to cut a selected part of the image. And also I
>> tested on some simple  tools form Sextante that generate raster (Rasterize
>> a vector layer, change no data value..).
>> Let us wait for Roberto's test. I think that it is fixed. Also it is nice
>> to reduce time raster display reusing a renderedOp cache mapping.
>
> yeah let's wait. anyway please advice him to use "-v trace" for delivering
> log messages. note that it is not debug but trace which is the most
> talkative setting.
>
>> The "colors" look different because a dem raster, with only one band, is
>> painted using a set of grey values between black and white for each cell
>> value. Those values are defined by the range of the cell values.  The
>> partial raster generated by the extracting tool has, of coarse, a
>> different range of values compared to the original dem. That's why the
>> different greys.
>> It is a way to graphically represent a group of datas (generally elevation
>> but also slope values, quantity of rain, insolation, etc) distributed (or
>> better reconstructed) as a grid on a surface.
>> Of course we can change the color schema (via Layer tree, Raster Style)
>> and we can omologate two rasters, with different ranges of values to the
>> same color schema (saving a color schema of one and importing it into the
>> second, always using via Layer tree, Raster Style).
>
> make total sense when explained like that :)
>
>> .
>> Very good job, Ede! I think, if no other problem came from Sextante tools
>> (and Roberto agree), this version will be used in the course.
>
> let's wait and see.
>
> homework for you is porting needed functionality from TiffUtils to
> TiffUtilsV2, so that in the end TiffUtils can be removed and only
> TiffUtilsV2 remains essentially wrapping GeoReferencedraster functionality.
>
> ..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] Fwd: [jump-pilot:bugs] Re: #498 Most GeoTIFF drivers fail with a simple GeoTIFF image

[Giuseppe Aruta]

Hi Ede,
it works fine. I was able to cut a selected part of the image. And also I
tested on some simple  tools form Sextante that generate raster (Rasterize
a vector layer, change no data value..).
Let us wait for Roberto's test. I think that it is fixed. Also it is nice
to reduce time raster display reusing a renderedOp cache mapping.
The "colors" look different because a dem raster, with only one band, is
painted using a set of grey values between black and white for each cell
value. Those values are defined by the range of the cell values.  The
partial raster generated by the extracting tool has, of coarse, a different
range of values compared to the original dem. That's why the different
greys.
It is a way to graphically represent a group of datas (generally elevation
but also slope values, quantity of rain, insolation, etc) distributed (or
better reconstructed) as a grid on a surface.
Of course we can change the color schema (via Layer tree, Raster Style) and
we can omologate two rasters, with different ranges of values to the same
color schema (saving a color schema of one and importing it into the
second, always using via Layer tree, Raster Style).
.
Very good job, Ede! I think, if no other problem came from Sextante tools
(and Roberto agree), this version will be used in the course.
Thanks again
Peppe


Il giorno lun 21 set 2020 alle ore 16:15  ha scritto:

> the "colors" look a little bit wrong though. different form the original
> image.. ede
>
> On 9/21/2020 16:02, ede wrote:
> > Peppe,
> >
> > please try r6506. extracting a part works for me now. tested on Ubuntu
> > 20. ..ede
> >
> > On 9/21/2020 11:03, Giuseppe Aruta wrote:
> >> OK.
> >>
> >> *First test*
> >> a) downloaded 6504
> >> b) uncomment JUMP_OPTS="-v DEBUG" on oj_linux.sh file
> >> c) launched OJ via oj_linux.sh.
> >> The program seems not to load all the plugin and it stops at this
> >> view. I cannot go on the test on raster files.
> >> d) the  log of this test is the file *openjump_1.log *attached to
> >> this mail**
> >> image.png
> >>
> >> *Second test*
> >>
> >> a) I copied into OpenJUMP-20200921-r6504-PLUS/bin folder oj_linux.sh
> >> *from OJ 6485 *with a new name: *oj_linux_modified.sh.
> >> *
> >> *
> >> *
> >> b) I added to *oj_linux_modified.sh* the lines
> >> /## uncomment and edit if you want some default OJ parameter set
> >> ## run OJ with '--help' argument to find out which are available
> >> JUMP_OPTS="-v DEBUG"/
> >> after the language group
> >>
> >> c) I clean up the file *openjump.log *in order to have a new one
> >>
> >> d) I launched OpenJUMP using *oj_linux_modified.sh*
> >>
> >> e) OpenJUMP loads and show the view. I can go on my test on raster
> >>
> >> f) I loaded as Sextante Raster one of Roberto sample files
> >> (Depit070.tif - attached also to this mail)
> >> g) I noted there is still an error on the console due to
> >> com/sun/medialib/mlib/Image. Eventually is corrected by Michael on
> >> ane of newer build
> >> h) I drew a fence on the raster
> >> g) On layer tree, selecting Depit070.tif, I clicked on tool "Extract
> >> selected part of the image"
> >> h) I had back this  message: "Uri is not absolute"
> >> image.png
> >> the log file of this test is attached as openjup_2.log
> >>
> >>
> >> *Third test*
> >> It is the one I described in my previous mail.
> >> I recompiled from SVN OpenJUMP 6504 substitutingon class RasterImageIO:
> >>   line 395 : renderedOp= TiffUtilsV2.getRenderedOp(new
> >> File(filenameOrURL));/
> >> with  Uri uri = new Uri(filenameOrURL);  renderedOp=
> >> TiffUtilsV2.getRenderedOp(new File(uri));
> >>
> >>
> >>
> >> Il giorno lun 21 set 2020 alle ore 10:26  >> <mailto:edgar.sol...@web.de>> ha scritto:
> >>
> >> On 21.09.2020 10:20, Giuseppe Aruta wrote:
> >> >>home/giuseppe/Desktop/GIS/OpenJUMP/OpenJUMP-20200915-r6484-PLUS
> >> is too old.
> >>  >>1. please make sure that you use the latest snapshot r6504
> >>  >
> >>  > That is only the folder where I save the OpenJUMP.jar file
> >> compiled  from SVN. I should change the name, your right. The
> >> OpenJUMP.jar is compiled at 6504 version
> >>
> >> maybe it's easier if you give me a step-by-step for me to reproduce
> >

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

[Giuseppe Aruta]

On the toolbar. The one that looks like a gray box
[image: image.png]


Il giorno lun 21 set 2020 alle ore 13:47  ha scritto:

> On 9/21/2020 11:03, Giuseppe Aruta wrote:
> > h) I drew a fence on the raster
> > g) On layer tree, selecting Depit070.tif, I clicked on tool "Extract
> > selected part of the image"
>
> where can i find the tool to draw a fence? ..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] Fwd: [jump-pilot:bugs] Re: #498 Most GeoTIFF drivers fail with a simple GeoTIFF image

[Giuseppe Aruta]

Hi Ede
>home/giuseppe/Desktop/GIS/OpenJUMP/OpenJUMP-20200915-r6484-PLUS is too old.
>1. please make sure that you use the latest snapshot r6504

That is only the folder where I save the OpenJUMP.jar file compiled  from
SVN. I should change the name, your right. The OpenJUMP.jar is compiled at
6504 version

>2. enable debugging as explained earlier '-v debug'
In the previous test I did on the openjump.sh file

I will do again the test with a downloaded 6504 and send back the log file

Peppe

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

> /home/giuseppe/Desktop/GIS/OpenJUMP/OpenJUMP-20200915-r6484-PLUS is too
> old.
>
> 1. please make sure that you use the latest snapshot r6504
> 2. enable debugging as explained earlier '-v debug'
> 3. disable the RasterImageIO patch beforehand. it should not be needed.
> repeat your tests and send the logfile
>
> ..ede
>
> On 21.09.2020 09:54, Giuseppe Aruta wrote:
> > Hi Ede, everything fine on my side to load view and zoom raster file.
> > I have problems on loading raster generated by OpenJUMP (ex. using
> "Extract selected part of the image" tool on Layerable tree - and all
> Sextante tools to generate raster I tested).
> > I got back this error (see   attached log for details):
> /java.lang.IllegalArgumentException: URI is not absolute/
> > Trying today to understand the reason, I modified, on class
> RasterImageIO:
> >
> > line 395
> > /renderedOp= TiffUtilsV2.getRenderedOp(new File(filenameOrURL));/
> > with
> > /Uri uri = new Uri(filenameOrURL);/
> > / renderedOp= TiffUtilsV2.getRenderedOp(new File(uri));/
> >
> > and everything worked fine again/
> > /
> > /
> > /
> > I also saw there are also other lines (renderedOp=
> TiffUtilsV2.getRenderedOp(new File(filenameOrURL)) used on the classes.
> They possibly don't throw errors because when they are called RenderedOp
> cache mapping is activated (?)/./
> >
> > Thank you
> >
> > Peppe/
> > /
> > /
> > /
> >
> > Il giorno lun 21 set 2020 alle ore 01:13  edgar.sol...@web.de>> ha scritto:
> >
> > On 20.09.2020 18:53, Giuseppe Aruta wrote:
> > > :-)
> > > Sorry for misunderstanding.
> >
> > nuhhh. no problemo.
> >
> > > Roberto starts the course at the 1 of October.
> > > He can use OJ 1.15, as well: apart from framework to read raster,
> there are no so many changes in raster tool, except the new pixel inspector
> capability.
> >
> > good to hear. anyway. just committed some changes that you guys
> should try out. for error reporting please set verbosity to debug!!! this
> can be done as runtime argument to the starter '-v debug' or by editing the
> start script (oj-windows.bat, oj_linux.sh) and adding it to the JUMP_OPTS
> variable in the header.
> >
> > ..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 <
> 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] Fwd: [jump-pilot:bugs] Re: #498 Most GeoTIFF drivers fail with a simple GeoTIFF image

[Giuseppe Aruta]

Hi Ede, everything fine on my side to load view and zoom raster file.
I have problems on loading raster generated by OpenJUMP (ex. using "Extract
selected part of the image" tool on Layerable tree - and all Sextante tools
to generate raster I tested).
I got back this error (see   attached log for details):
*java.lang.IllegalArgumentException:
URI is not absolute*
Trying today to understand the reason, I modified, on class RasterImageIO:

line 395
*renderedOp= TiffUtilsV2.getRenderedOp(new File(filenameOrURL));*
with
*Uri uri = new Uri(filenameOrURL);*
* renderedOp= TiffUtilsV2.getRenderedOp(new File(uri));*

and everything worked fine again

I also saw there are also other lines (renderedOp=
TiffUtilsV2.getRenderedOp(new File(filenameOrURL)) used on the classes.
They possibly don't throw errors because when they are called RenderedOp
cache mapping is activated (?)*.*

Thank you

Peppe


Il giorno lun 21 set 2020 alle ore 01:13  ha scritto:

> On 20.09.2020 18:53, Giuseppe Aruta wrote:
> > :-)
> > Sorry for misunderstanding.
>
> nuhhh. no problemo.
>
> > Roberto starts the course at the 1 of October.
> > He can use OJ 1.15, as well: apart from framework to read raster, there
> are no so many changes in raster tool, except the new pixel inspector
> capability.
>
> good to hear. anyway. just committed some changes that you guys should try
> out. for error reporting please set verbosity to debug!!! this can be done
> as runtime argument to the starter '-v debug' or by editing the start
> script (oj-windows.bat, oj_linux.sh) and adding it to the JUMP_OPTS
> variable in the header.
>
> ..ede
>
>
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
[INFO] 2020-09-21_09:42:24.932 Restore state from /home/giuseppe/Desktop/GIS/OpenJUMP/OpenJUMP-20200915-r6484-PLUS/workbench-state.xml
[INFO] 2020-09-21_09:42:26.931 Loading Plugin com.vividsolutions.jump.workbench.datasource.InstallStandardDataSourceQueryChoosersPlugIn took 0,05s 
[INFO] 2020-09-21_09:42:26.966 Loading Plugin org.openjump.core.ui.plugin.file.OpenFilePlugIn took 0,03s 
[INFO] 2020-09-21_09:42:26.974 Loading Plugin com.vividsolutions.jump.workbench.ui.plugin.FirstTaskFramePlugIn took 0,00s 
[INFO] 2020-09-21_09:42:27.000 Loading Plugin org.openjump.core.ui.plugin.file.FileDragDropPlugin took 0,02s 
[INFO] 2020-09-21_09:42:27.004 Loading Plugin org.openjump.core.ui.plugin.view.InstallKeyPanPlugIn took 0,00s 
[INFO] 2020-09-21_09:42:27.015 Loading Plugin org.openjump.core.ui.plugin.view.MapToolTipPlugIn took 0,01s 
[INFO] 2020-09-21_09:42:27.026 Loading Plugin org.openjump.core.ui.plugin.view.ShowFullPathPlugIn took 0,01s 
[INFO] 2020-09-21_09:42:27.044 Loading Plugin org.openjump.core.ui.plugin.datastore.postgis.SaveToPostGISPlugIn took 0,01s 
[INFO] 2020-09-21_09:42:27.050 Loading Plugin org.openjump.core.ccordsys.srid.EnsureAllLayersHaveSRIDStylePlugIn took 0,00s 
[INFO] 2020-09-21_09:42:27.062 Loading Plugin org.openjump.core.ui.plugin.view.helpclassescale.InstallShowScalePlugIn took 0,00s 
[INFO] 2020-09-21_09:42:27.067 Loading Plugin org.openjump.core.ui.plugin.view.NorthArrowInstallRenderer took 0,00s 
[INFO] 2020-09-21_09:42:27.074 Loading Plugin org.openjump.core.ui.plugin.view.showcenter.ShowViewCenterInstallRenderer took 0,00s 
[INFO] 2020-09-21_09:42:27.079 Loading Plugin com.vividsolutions.jump.workbench.ui.plugin.InstallStandardFeatureTextWritersPlugIn took 0,00s 
[INFO] 2020-09-21_09:42:27.092 Loading Plugin com.vividsolutions.jump.workbench.ui.plugin.datastore.InstallDatastoreLayerRendererHintsPlugIn took 0,00s 
[INFO] 2020-09-21_09:42:27.098 Loading Plugin com.vividsolutions.jump.workbench.ui.plugin.scalebar.InstallScaleBarPlugIn took 0,00s 
[INFO] 2020-09-21_09:42:27.151 Loading Plugin com.vividsolutions.jump.workbench.ui.snap.InstallGridPlugIn took 0,05s 
[INFO] 2020-09-21_09:42:27.178 Loading Plugin com.vividsolutions.jump.workbench.ui.zoom.InstallZoomBarPlugIn took 0,02s 
[INFO] 2020-09-21_09:42:27.373 Loading Plugin org.openjump.core.ui.plugin.datastore.postgis2.SaveToPostGIS2PlugIn took 0,19s 
[INFO] 2020-09-21_09:42:27.392 Loading Plugin com.vividsolutions.jump.workbench.ui.plugin.NewTaskPlugIn took 0,02s 
[INFO] 2020-09-21_09:42:27.401 Loading Plugin com.vividsolutions.jump.workbench.ui.plugin.AddNewLayerPlugIn took 0,01s 
[INFO] 2020-09-21_09:42:27.408 Loading Plugin com.vividsolutions.jump.workbench.ui.plugin.AddNewCategoryPlugIn took 0,00s 
[INFO] 2020-09-21_09:42:27.411 Loading Plugin org.openjump.core.ui.plugin.file.OpenWizardPlugIn took 0,00s 
[INFO] 2020-09-21_09:42:27.423 Loading Plugin org.openjump.core.ui.plugin.file.OpenProjectPlugIn took 0,01s 
[INFO] 2020-09-21_09:42:27.449 Loading Plugin org.openjump.core.ui.plugin.file.OpenRecentPlugIn took 0,03s 
[INFO] 2020-09-21_09:4

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

[Giuseppe Aruta]

:-)
Sorry for misunderstanding.
Roberto starts the course at the 1 of October.
He can use OJ 1.15, as well: apart from framework to read raster, there are
no so many changes in raster tool, except the new pixel inspector
capability.
Peppe


Il dom 20 set 2020, 18:42  ha scritto:

> Peppe,
>
> misunderstanding ;). my question is when do you need it working as stable
> or better as in OJ 1.15? when do the courses start? ..ede
>
> On 20.09.2020 18:19, Giuseppe Aruta wrote:
> > Hi Ede
> >>what was your time frame again?
> > TiffUtils ->6398  30/08/2020
> > RasterImageLayer  -> 6399   31/08/2020
> > RasterImageIO  -->5413  01/04/2017
> > AddRasterImageLayerWizard   --> 5916  18/08/2018
> >
> > All my modification started from 02/09/2020
> >
> > Il giorno dom 20 set 2020 alle ore 14:52  edgar.sol...@web.de>> ha scritto:
> >
> > Mike, Jukka,
> >
> > as you are far more knowledgeable wrt. to file formats you maybe
> want to come up with some tiled TIFFs or otherwise difficult formats that
> are currently not readable by Apache Commons Imaging as requested below?!
> >
> > tickets can be opened (after a short account creation) on
> https://issues.apache.org/jira/projects/IMAGING/summary <
> https://issues.apache.org/jira/projects/IMAGING/summary>
> >
> > ..ede
> >
> >  Forwarded Message 
> > Subject:[JPP-Devel] [jump-pilot:bugs] Re: #498 Most GeoTIFF
> drivers fail with a simple GeoTIFF image
> > Date:   Sat, 19 Sep 2020 03:15:16 -
> > From:   G. W. Lucas via Jump-pilot-devel <
> jump-pilot-devel@lists.sourceforge.net  jump-pilot-devel@lists.sourceforge.net>>
> > Reply-To:   [jump-pilot:bugs] <
> 4...@bugs.jump-pilot.p.re.sourceforge.net  4...@bugs.jump-pilot.p.re.sourceforge.net>>, OpenJump develop and use <
> jump-pilot-devel@lists.sourceforge.net  jump-pilot-devel@lists.sourceforge.net>>
> > To: jump-pilot-devel@lists.sourceforge.net  jump-pilot-devel@lists.sourceforge.net>
> > CC: G. W. Lucas  gwlu...@users.sourceforge.net>>
> >
> >
> >
> > The problem is due to a TIFF format that is not supported by
> Commons-Imaging. I posted some notes to your bug report. I completed a code
> change and the fix is in the pipeline.
> >
> > Thanks for the test file. It helped a lot. If you have others
> (particular examples using a tile-organization rather than strips), I'd
> welcome them.
> >
> > ___
> > 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 <
> 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] Fwd: [jump-pilot:bugs] Re: #498 Most GeoTIFF drivers fail with a simple GeoTIFF image

[Giuseppe Aruta]

Hi Ede
>what was your time frame again?
TiffUtils ->6398  30/08/2020
RasterImageLayer  -> 6399   31/08/2020
RasterImageIO  -->5413  01/04/2017
AddRasterImageLayerWizard   --> 5916  18/08/2018

All my modification started from 02/09/2020

Il giorno dom 20 set 2020 alle ore 14:52  ha scritto:

> Mike, Jukka,
>
> as you are far more knowledgeable wrt. to file formats you maybe want to
> come up with some tiled TIFFs or otherwise difficult formats that are
> currently not readable by Apache Commons Imaging as requested below?!
>
> tickets can be opened (after a short account creation) on
> https://issues.apache.org/jira/projects/IMAGING/summary
>
> ..ede
>
>  Forwarded Message 
> Subject:[JPP-Devel] [jump-pilot:bugs] Re: #498 Most GeoTIFF
> drivers fail with a simple GeoTIFF image
> Date:   Sat, 19 Sep 2020 03:15:16 -
> From:   G. W. Lucas via Jump-pilot-devel <
> jump-pilot-devel@lists.sourceforge.net>
> Reply-To:   [jump-pilot:bugs] <
> 4...@bugs.jump-pilot.p.re.sourceforge.net>, OpenJump develop and use <
> jump-pilot-devel@lists.sourceforge.net>
> To: jump-pilot-devel@lists.sourceforge.net
> CC: G. W. Lucas 
>
>
>
> The problem is due to a TIFF format that is not supported by
> Commons-Imaging. I posted some notes to your bug report. I completed a code
> change and the fix is in the pipeline.
>
> Thanks for the test file. It helped a lot. If you have others (particular
> examples using a tile-organization rather than strips), I'd welcome them.
>
> ___
> 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] Re: #498 Most GeoTIFF drivers fail with a simple GeoTIFF image

[Giuseppe Aruta]

Ede, MIchael,
regarding RasterImageLayers.
At this stage, even if I partially solved the problems of the warning from
my side, Roberto still finds them.
I also find a problem on Sextante. Whenever a raster is generated by a
Sextante tool, it is loaded but neither displayed nor readable on Openjump.
I am considering to restore RasterImageLayer framework at the previous
working version (OJ 1.15) with few modifications.

a) I will restore the modified classes AddRasterImageWizard, RasterImageIO,
RatserImageLayer and TiffUtils to version 1.15 depuring of any dependency
from GeoRasterImage.class

b) The original 1.15 RasterImageIO, RatserImageLayer and TiffUtils classes
use the method JAI("fileLoad"..) to read TIF.
I will substitute it with the method JAI("ImageRead"...).

Using ImageRead will solve the problem to read, display and query the
problematic raster like small_world.tif and the AsterDEMs

Before doing these modification, I would like to have your opinion
Best regards

Peppe



Il giorno sab 19 set 2020 alle ore 05:15 G. W. Lucas via Jump-pilot-devel <
jump-pilot-devel@lists.sourceforge.net> ha scritto:

> The problem is due to a TIFF format that is not supported by
> Commons-Imaging. I posted some notes to your bug report. I completed a code
> change and the fix is in the pipeline.
>
> Thanks for the test file. It helped a lot. If you have others (particular
> examples using a tile-organization rather than strips), I'd welcome them.
> --
>
> * [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 13, 2020 09:35 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.pain

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

[Giuseppe Aruta]

Thanks Ede

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

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

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

[Giuseppe Aruta]

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

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

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

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

[Giuseppe Aruta]

Hi Ede,
sorry, I sent the message just a microsecond I received yours

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

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


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

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