Compiled JARS from 0.7.9-SNAPSHOT not being loaded in uDig Spatial Toolbox

[Marco Foi]

Hi Andrea!

It's a while since we last get in contact: I hope I find you well.

I am trying to merge CISLAM into JGT master and I am not sure I am doing it right.

Following my own instruction dating  to GSoC 2014, I first tested a "git clone" of movida/jgrasstools,

launched a "mvn install" from root folder so to have all dependencies downloaded and packaged

and the build completed successfully.

The first problem is that the output files

- jgt-jgrassgears-0.7.9-SNAPSHOT.jar

- jgt-hortonmachine-0.7.9-SNAPSHOT.jar

seem to be ignored by the uDig Spatial Toolbox (1.4.0 both 32 & 64 bit): no module is recognised.

The same two versions of uDig work flawlessly with 0.7.7-SNAPSHOT from here:

https://code.google.com/p/jgrasstools/downloads/list

Any hint?

Thanks a lot, as usual, my great mentor! ;-)

Marco

[andrea antonello]

Hi Marco,

> It's a while since we last get in contact: I hope I find you well.

just got back from vacation, so I guess I am at my best right now :-)
Good to hear back from you in list. :)

> I am trying to merge CISLAM into JGT master and I am not sure I am doing it
> right.
> Following my own instruction dating to GSoC 2014, I first tested a "git
> clone" of movida/jgrasstools,
> launched a "mvn install" from root folder so to have all dependencies
> downloaded and packaged
> and the build completed successfully.
>
> The first problem is that the output files
>
> - jgt-jgrassgears-0.7.9-SNAPSHOT.jar
> - jgt-hortonmachine-0.7.9-SNAPSHOT.jar
>
> seem to be ignored by the uDig Spatial Toolbox (1.4.0 both 32 & 64 bit): no
> module is recognised.
>
> The same two versions of uDig work flawlessly with 0.7.7-SNAPSHOT from here:
> https://code.google.com/p/jgrasstools/downloads/list
>
> Any hint?

Oh yes.

uDig got really stalled lately, while from some project we had to move
on with the geotools version. The result is that the latest
JGrasstools versions don't work in uDig any more right now. Since we
do not know when a solid new version of uDig will be released, we
developed the old concept of the JConsole, which now is merged into
STAGE:
http://jgrasstechtips.blogspot.it/search/label/stage

That is right now the supported way (by us) to use the JGrasstools.
Obviously you need a GIS of your choice to see the results.

Obviously you can still use the commandline scripting way.

Also please remember to include the necessary testcases.

> Thanks a lot, as usual, my great mentor! ;-)

Thanks to you for coming back to merge in your work after all that
time without any push from above :-)

Cheers,
Andrea


>
> Marco
>
> --
> You received this message because you are subscribed to the Google Groups
> "jgrasstools" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jgrasstools...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Marco Foi]

Well.. ..actually I had a "side" push from the University of Trento that now wishes to schedule some real-case testing of the CISLAM Module vs. other existing shallow landslide models for scientific purposes.

Now the problems: I adopted a kind of test-driven development lifecycle as reproducing the output of the original R script by C. Lanni was the only way to proceed and to be sure of being on the right path. The bad news is that the dataset I used for testing is a real-case one, made of several uncompressed ASCII maps each containing one of the physical properties required by the model. They all sum up to 153Mb of raw data (6Mb compressed).

More, going through all my tests takes up to 70 seconds (using multiple threads in some I/O stages and algorithms): in short it can really slow down JGrassTools build (now it takes some 20 seconds)

I know is heresy merging modules with no test case.. ..but I didn't own the knowledge to create simpleer test maps at the time I was porting the tool.. ..and I would not be able also now (providing I have the time - not a sure thing).

What about marking it "experimental" (forever) ? Other ideas?

Let me know your last word.

Marco

P.S. I 'll write you in private for other things.

[Marco Foi]

Beside the issues related to the test case I reported in my previous post,

I also stumbled in another problem.

The CISLAM module does not appear in STAGE module tree.

As far as I can remember, advertising the modules in

org.jgrasstools.gears.libs.modules.JGTModel

was enough to make them appear in the UI of uDig's Spatial Toolbox.

Does this also apply to STAGE? Am I missing anything?

Marco

On 13 October 2014 11:10, andrea antonello <andrea.a...@gmail.com> wrote:

[andrea antonello]

> Well.. ..actually I had a "side" push from the University of Trento that now
> wishes to schedule some real-case testing of the CISLAM Module vs. other
> existing shallow landslide models for scientific purposes.

:-) Yes, I was being ironic.

> Now the problems: I adopted a kind of test-driven development lifecycle as
> reproducing the output of the original R script by C. Lanni was the only way
> to proceed and to be sure of being on the right path. The bad news is that
> the dataset I used for testing is a real-case one, made of several
> uncompressed ASCII maps each containing one of the physical properties
> required by the model. They all sum up to 153Mb of raw data (6Mb
> compressed).
> More, going through all my tests takes up to 70 seconds (using multiple
> threads in some I/O stages and algorithms): in short it can really slow down
> JGrassTools build (now it takes some 20 seconds)
> I know is heresy merging modules with no test case.. ..but I didn't own the
> knowledge to create simpleer test maps at the time I was porting the tool..
> ..and I would not be able also now (providing I have the time - not a sure
> thing).
>
> What about marking it "experimental" (forever) ? Other ideas?
> Let me know your last word.

Well, I assume they will stay experimental forever if there is no
other way to solve this. No problem for me.

> P.S. I 'll write you in private for other things.

Ok, will wait ;-)

Cheers,
Andrea

[andrea antonello]

> Beside the issues related to the test case I reported in my previous post,
> I also stumbled in another problem.
> The CISLAM module does not appear in STAGE module tree.
>
> As far as I can remember, advertising the modules in
> org.jgrasstools.gears.libs.modules.JGTModel
> was enough to make them appear in the UI of uDig's Spatial Toolbox.
>
> Does this also apply to STAGE? Am I missing anything?

Yes definitely. Consider that in STAGE only modules NOT-starting with
Oms* are imported though.
So you either have to name it differently, or, as I always try to do,
make a wrapper in the modules project which is simply the same module,
but with files in input and output, so that it is simpler for people
to use. The GridCoverage/SimpleFeatureCollection modules connections
were abandoned some time ago, since in any case if you do some complex
modelling, you need to do scripting (the visual modelling tool never
got funded).

If that doesn't apply, launch STAGE with the debug and consoleLog
option. it will tell you if there are issues.

Cheers,
Andrea

[Marco Foi]

I have been trying to check whether I forgot something but I could not find any piece missing:

- I have the Cislam.java wrapper is in the modules project

- the wrapper is registerd in org.jgrasstools.gears.libs.modules.JGTModel

- both Cislam.java and OmsCislam.java  are marked as EXPERIMENTAL (code 0x5)

A thing that may be a problem:

- the Cislam module and its sub-modules should appear in the subfolder HortonMachine/Hydro-Geomporphology/CI-slam/

..but this folder is empty at startup since is full of experimental modules. Can be this a problem?

No error is issued by STAGE with -debug and -consoleLog launch options.

The Cislam module extensively uses GridCoverage2D.. ..but I see this piece of framework is still widely used also by other modules.

Despite all this still I cannot get to the point.. ..and I am a bit clueless. The original code was working in uDig spatial toolbox with JGrassTools 0.7.7!!

The code is here, should you find 5 minutes to give it a look:

https://github.com/mcfoi/jgrasstools

Marco

[andrea antonello]

Hi Marco,

> I have been trying to check whether I forgot something but I could not find
> any piece missing:
>
> - I have the Cislam.java wrapper is in the modules project
> - the wrapper is registerd in org.jgrasstools.gears.libs.modules.JGTModel
> - both Cislam.java and OmsCislam.java are marked as EXPERIMENTAL (code 0x5)

looks good to me.

> A thing that may be a problem:
> - the Cislam module and its sub-modules should appear in the subfolder
> HortonMachine/Hydro-Geomporphology/CI-slam/
> ..but this folder is empty at startup since is full of experimental modules.
> Can be this a problem?

No. I find it quite ok. In case it is something that should be fixed
in STAGE/Spatial Toolbox.

> No error is issued by STAGE with -debug and -consoleLog launch options.
> The Cislam module extensively uses GridCoverage2D.. ..but I see this piece
> of framework is still widely used also by other modules.

You are aware that the modules wrappers should use string for input
and output, right?

> Despite all this still I cannot get to the point.. ..and I am a bit
> clueless. The original code was working in uDig spatial toolbox with
> JGrassTools 0.7.7!!

That is what they all say :-)

> The code is here, should you find 5 minutes to give it a look:
>
> https://github.com/mcfoi/jgrasstools

How about instead you open a pull request, which makes it simple for
me to check and test and in case discuss and add changes?

Cheers,
Andrea

[andrea antonello]

PS: make sure you added the @Execute annotation to the process method

On Thu, Oct 16, 2014 at 7:58 AM, andrea antonello

[Marco Foi]

Ok: I got it!

The problem was so trivial I am a bit ashamed to admit it.

Giving that STAGE browses the wrappers to build the list of modules displayed in the tree panel,

ALSO the jgt-modules-x.x.x.jar has to be copied in STAGE/spatialtoolbox/modules/ folder.

I was still stick to the uDig's Spatial Tool Box!

Anyway.. ..now I have to fix the wrapper as it was never tested and is NOT using strings.. ..but GridCoverage2D.

The path is a bit longer.. .but downhill!

Thank for the good suggestions.

Marco