Re: [JPP-Devel] Macro recorder for OpenJUMP (work in progress)

2014-10-06 Thread Michael Michaud
Hi,

Macro recording an action on a selected layer :

There is an interesting question about plugins executed on a selected layer
or category (some are dialogless like delete or copy/paste)
User starts a macro, delete selected layer A and stop the macro.
What is the expected behaviour when the macro is run again ?
- should it delete the selected layer (whatever its name is)
- or should it delete layer A, regardless of whether it is selected or not.

Use cases are welcome to try to define a behaviour both consistent
and useful.

Michaël

--
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


[JPP-Devel] Static object in RasterImageLayer class

2014-10-06 Thread Alberto De Luca - GeA

Dear OJ developers,

after a break (of a few years...), I'm back on OJ development, still 
focussed on raster management and close to be ready to make available to 
the community an improved version of the "raster color editor", allowing 
the use of ramps, intervals, single colour values...


Nevertheless, there is a design issue in the class

org.openjump.core.rasterimage.RasterImageLayer

that is giving me some problems. The point is that the Raster variable 
"rasterData" is static. As a consequence, it gets shared across all the 
instances of RasterImageLayer, making thinks a bit awkward. Do you see 
any problem in turning rasterData into non-static? I've tested this 
change, and everything appears to be working alright. You can find 
attached the modified RasterImageLayer.java


Cheers
Alberto


RasterImageLayer.7z
Description: Binary data
--
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


Re: [JPP-Devel] Static object in RasterImageLayer class

2014-10-06 Thread edgar . soldin
On 06.10.2014 13:34, Alberto De Luca - GeA wrote:
> Dear OJ developers,
> 
> after a break (of a few years...), I'm back on OJ development, still focussed 
> on raster management and close to be ready to make available to the community 
> an improved version of the "raster color editor", allowing the use of ramps, 
> intervals, single colour values...

yippee.. \o/

> Nevertheless, there is a design issue in the class
> 
> org.openjump.core.rasterimage.RasterImageLayer
> 
> that is giving me some problems. The point is that the Raster variable 
> "rasterData" is static. As a consequence, it gets shared across all the 
> instances of RasterImageLayer, making thinks a bit awkward. Do you see any 
> problem in turning rasterData into non-static? I've tested this change, and 
> everything appears to be working alright. You can find attached the modified 
> RasterImageLayer.java

hmm.. usually one Layer object represents this layer's data. how did it work 
before, if more than one layer always overwrote the value of the static 
'rasterData' of the older layer?

making it unstatic could raise memory constraints, can you make a test with big 
images, before and after and see if there is a significant difference?

finally.. we have a second image framework, search class ReferencedImagesLayer 
. could you please have a look if your plugin might be able to handle those as 
well?

regards.. ede

--
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


Re: [JPP-Devel] Static object in RasterImageLayer class

2014-10-06 Thread Stefan Steiniger
Hi Alberto, don't think that this should be a problem.
Question is why was it static before? Maybe an error.

I am using raster stuff a bit with my HoRAE extension... so it would be 
necessary for me to test if still everything works "after" you made your 
changes. (I write "after", because I am actually not having time the 
next 2 weeks)

cheers,
stefan

Am 06.10.14 07:34, schrieb Alberto De Luca - GeA:
> Dear OJ developers,
>
> after a break (of a few years...), I'm back on OJ development, still
> focussed on raster management and close to be ready to make available to
> the community an improved version of the "raster color editor", allowing
> the use of ramps, intervals, single colour values...
>
> Nevertheless, there is a design issue in the class
>
> org.openjump.core.rasterimage.RasterImageLayer
>
> that is giving me some problems. The point is that the Raster variable
> "rasterData" is static. As a consequence, it gets shared across all the
> instances of RasterImageLayer, making thinks a bit awkward. Do you see
> any problem in turning rasterData into non-static? I've tested this
> change, and everything appears to be working alright. You can find
> attached the modified RasterImageLayer.java
>
> Cheers
> Alberto
>
>
> --
> Slashdot TV.  Videos for Nerds.  Stuff that Matters.
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
>
>
>
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>

--
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


Re: [JPP-Devel] Macro recorder for OpenJUMP (work in progress)

2014-10-06 Thread Larry Becker
Hi Michaël,

  A bold new feature!  One question: are you considering the use of
BeanShell as the macro language?  This would multiply the power of macro
recording by making it a first step in script writing.

regards,

Larry Becker

On Mon, Oct 6, 2014 at 6:28 AM, Michael Michaud  wrote:

> Hi,
>
> Macro recording an action on a selected layer :
>
> There is an interesting question about plugins executed on a selected layer
> or category (some are dialogless like delete or copy/paste)
> User starts a macro, delete selected layer A and stop the macro.
> What is the expected behaviour when the macro is run again ?
> - should it delete the selected layer (whatever its name is)
> - or should it delete layer A, regardless of whether it is selected or not.
>
> Use cases are welcome to try to define a behaviour both consistent
> and useful.
>
> Michaël
>
>
> --
> Slashdot TV.  Videos for Nerds.  Stuff that Matters.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
--
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


Re: [JPP-Devel] Macro recorder for OpenJUMP (work in progress)

2014-10-06 Thread edgar . soldin
good idea.. ede

On 06.10.2014 15:38, Larry Becker wrote:
> Hi Michaël,
> 
>   A bold new feature!  One question: are you considering the use of BeanShell 
> as the macro language?  This would multiply the power of macro recording by 
> making it a first step in script writing. 
> 
> regards,
> 
> Larry Becker
> 
> On Mon, Oct 6, 2014 at 6:28 AM, Michael Michaud  > wrote:
> 
> Hi,
> 
> Macro recording an action on a selected layer :
> 
> There is an interesting question about plugins executed on a selected 
> layer
> or category (some are dialogless like delete or copy/paste)
> User starts a macro, delete selected layer A and stop the macro.
> What is the expected behaviour when the macro is run again ?
> - should it delete the selected layer (whatever its name is)
> - or should it delete layer A, regardless of whether it is selected or 
> not.
> 
> Use cases are welcome to try to define a behaviour both consistent
> and useful.
> 
> Michaël
> 

--
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


Re: [JPP-Devel] Macro recorder for OpenJUMP (work in progress)

2014-10-06 Thread edgar . soldin
On 06.10.2014 13:28, Michael Michaud wrote:
> Hi,
> 
> Macro recording an action on a selected layer :
> 
> There is an interesting question about plugins executed on a selected layer
> or category (some are dialogless like delete or copy/paste)
> User starts a macro, delete selected layer A and stop the macro.
> What is the expected behaviour when the macro is run again ?
> - should it delete the selected layer (whatever its name is)
> - or should it delete layer A, regardless of whether it is selected or not.
> 
> Use cases are welcome to try to define a behaviour both consistent
> and useful.
> 

as the plugin works with selected layers i'd expect the recorded plugin to work 
on a selected layer as well. this, of course, raises the question how to 
control selection during macro playing.

..ede

--
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


Re: [JPP-Devel] Macro recorder for OpenJUMP (work in progress)

2014-10-06 Thread Michael Michaud

Hi Larry,

  A bold new feature!  One question: are you considering the use of 
BeanShell as the macro language?  This would multiply the power of 
macro recording by making it a first step in script writing.
I've thought about it (think it is doable), but I've not yet tried to 
implement it. Just started with plain xml.
Beanshell would have one drawback which could be raised by using groovy 
: all parameters will
need to be defined in Map (initialisation of maps is quite verbose in 
beanshell compared to groovy)


Michaël


regards,

Larry Becker

On Mon, Oct 6, 2014 at 6:28 AM, Michael Michaud 
mailto:m.michael.mich...@orange.fr>> wrote:


Hi,

Macro recording an action on a selected layer :

There is an interesting question about plugins executed on a
selected layer
or category (some are dialogless like delete or copy/paste)
User starts a macro, delete selected layer A and stop the macro.
What is the expected behaviour when the macro is run again ?
- should it delete the selected layer (whatever its name is)
- or should it delete layer A, regardless of whether it is
selected or not.

Use cases are welcome to try to define a behaviour both consistent
and useful.

Michaël


--
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel




--
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk


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


--
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


Re: [JPP-Devel] Static object in RasterImageLayer class

2014-10-06 Thread Michael Michaud

Hi Alberto,
after a break (of a few years...), I'm back on OJ development, still 
focussed on raster management and close to be ready to make available 
to the community an improved version of the "raster color editor", 
allowing the use of ramps, intervals, single colour values...

Good news ;-)


Nevertheless, there is a design issue in the class

org.openjump.core.rasterimage.RasterImageLayer

that is giving me some problems. The point is that the Raster variable 
"rasterData" is static. As a consequence, it gets shared across all 
the instances of RasterImageLayer, making thinks a bit awkward. Do you 
see any problem in turning rasterData into non-static? I've tested 
this change, and everything appears to be working alright. You can 
find attached the modified RasterImageLayer.java
Generally speaking, it seems a bad idea to put heavy structures in a 
static field.

Wonder how it could work. The best is to commit your code and to validate it
with some tests including heapsize measurement as suggested by Ede.

Michaël


Cheers
Alberto


--
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk


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


--
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


Re: [JPP-Devel] Macro recorder for OpenJUMP (work in progress)

2014-10-06 Thread Michael Michaud
Hi
>
>> Hi,
>>
>> Macro recording an action on a selected layer :
>>
>> There is an interesting question about plugins executed on a selected layer
>> or category (some are dialogless like delete or copy/paste)
>> User starts a macro, delete selected layer A and stop the macro.
>> What is the expected behaviour when the macro is run again ?
>> - should it delete the selected layer (whatever its name is)
>> - or should it delete layer A, regardless of whether it is selected or not.
>>
>> Use cases are welcome to try to define a behaviour both consistent
>> and useful.
>>
> as the plugin works with selected layers i'd expect the recorded plugin to 
> work on a selected layer as well. this, of course, raises the question how to 
> control selection during macro playing.
Yes, difficult question. I think it would be easier to rely on the layer 
name by default
(and it would make macro more independant from the UI),
But maybe it would be possible to add an option to switch from layerName to
selectedLayer during macro recording when it is really needed (the 
parameter value
would be changed from "MyLayer" to "${SelectedLayer}" for example.

The question becomes even more complex with selected features...

Michaël

>
> ..ede
>
> --
> Slashdot TV.  Videos for Nerds.  Stuff that Matters.
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>


--
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


Re: [JPP-Devel] Macro recorder for OpenJUMP (work in progress)

2014-10-06 Thread edgar . soldin
On 06.10.2014 20:39, Michael Michaud wrote:
> Hi
>>
>>> Hi,
>>>
>>> Macro recording an action on a selected layer :
>>>
>>> There is an interesting question about plugins executed on a selected layer
>>> or category (some are dialogless like delete or copy/paste)
>>> User starts a macro, delete selected layer A and stop the macro.
>>> What is the expected behaviour when the macro is run again ?
>>> - should it delete the selected layer (whatever its name is)
>>> - or should it delete layer A, regardless of whether it is selected or not.
>>>
>>> Use cases are welcome to try to define a behaviour both consistent
>>> and useful.
>>>
>> as the plugin works with selected layers i'd expect the recorded plugin to 
>> work on a selected layer as well. this, of course, raises the question how 
>> to control selection during macro playing.
> Yes, difficult question. I think it would be easier to rely on the layer 
> name by default
> (and it would make macro more independant from the UI),
> But maybe it would be possible to add an option to switch from layerName to
> selectedLayer during macro recording when it is really needed (the 
> parameter value
> would be changed from "MyLayer" to "${SelectedLayer}" for example.
> 

maybe just another argument to have the macrorecorder create an editable script 
(beanshell, groovy ...) to allow users to finetune their macro.

..ede

--
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


Re: [JPP-Devel] NaN; Save to PostGIS Table Write 3d

2014-10-06 Thread Michael Michaud
Hi Uwe,

New option to save a layer to PostGIS with NaN to valid z
conversion in r4063,

Please let me know if it works for you, and if you have some
screen capture or some public bundle of what you're developping,
I would be very curious to know more.

Michaël

> Hi Michaël,
>
> I am trying to develop a 2d- and 3d-GIS with JOGL
> and PostGIS (you can switch between 2d and 3d).
> The 3d-geometries are stored in PostGIS.
> With OpenJUMP I digitalise some geometries
> and stored them to PostGIS with:
> Save Dataset As>Write 3d geometries
> (PostGIS Table (new)).
> My program crashes because there is no valid z-coordinate.
>
> St_Force_3D ( ) crashes too:
> "POLYGON((60 180 1.#QNAN,75 290 1.#QNAN,300 300 1.#QNAN,361 170
> 1.#QNAN,200 60 1.#QNAN,60 180 1.#QNAN))"
>
> When I save the OpenJUMP layer without
> "Write 3d geometries" my program works,
> but the table has only 2d geometries.
> I can use then St_Force_3D ( ) to receive
> 3d coordinates (with z = 0.) but this is
> not comfortable.
>
> I understand your "abdominal pain" to write 0.
> instead NaN but I think the geometries I
> digitalise with OpenJUMP have always z = 0.
>
> Thank you for thinking about may problem!
>
> Greetings from Hamburg
>
> Uwe
>
>
> Am 02.10.2014 um 08:50 schrieb Michael Michaud:
>> Hi Uwe,
>>
>> I suppose you are refering to the Save to PostGIS table (New) loader
>> as the previous one has no 3D option.
>> Could you tell me what your use case is ?
>> I think it is not too complex to set the z to 0 while saving a dataset
>> into postgis, but I'm a bit reluctant as NaN may have a different
>> semantic (unknown, unset) which will be lost if the z is set to 0.
>> On the other hand, it seems that the posgis st_force3d function
>> set the z to 0 (I did not check though).
>>
>> Michaël
>>> Hi,
>>>
>>> Save Dataset As>Save to PostGIS Table>Write 3d geometries
>>> writes NaN for the z-coordinate.
>>> Is it possible to write 0.0 (zero) instead NaN
>>> for the z-coordinate?
>>>
>>> I use OJ Version 20140924 snapshot rev.4056
>>>
>>>
>>> Regards
>>>
>>> Uwe
>>>
>>> --
>>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>>> ___
>>> Jump-pilot-devel mailing list
>>> Jump-pilot-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>>
>>
>> --
>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>> ___
>> Jump-pilot-devel mailing list
>> Jump-pilot-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>
> --
> Slashdot TV.  Videos for Nerds.  Stuff that Matters.
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>


--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


Re: [JPP-Devel] Static object in RasterImageLayer class

2014-10-06 Thread Michael Michaud

Hi Alberto, Stefan,

Just commit Alberto's patch (r4064)
please test,

Michaël


Dear OJ developers,

after a break (of a few years...), I'm back on OJ development, still 
focussed on raster management and close to be ready to make available 
to the community an improved version of the "raster color editor", 
allowing the use of ramps, intervals, single colour values...


Nevertheless, there is a design issue in the class

org.openjump.core.rasterimage.RasterImageLayer

that is giving me some problems. The point is that the Raster variable 
"rasterData" is static. As a consequence, it gets shared across all 
the instances of RasterImageLayer, making thinks a bit awkward. Do you 
see any problem in turning rasterData into non-static? I've tested 
this change, and everything appears to be working alright. You can 
find attached the modified RasterImageLayer.java


Cheers
Alberto


--
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk


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


--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel