OmsBasinShape - Mandatory input missing

[Blal Adem Esmail]

Dear all,

First of all, I apologize if my question is trivial. Well, I'm using: Udig 1.4.0 with  * 0.7.7 snapshot.jar. in Windoes 8.

I've a problem creating the shapefile of the subbasins based on the netnumbering  using the "OmsBasinShape".

I've added all the necessary inputs, yet I get:

"ERROR

---------------------------------------------

 BasinShape: Mandatory input argument is missing. Check your syntax..."

What could be the problem? 

Please find attached the debug info. 

Thanks,

Blal

[Blal Adem Esmail]

I have talked with Leonardo and managed to solve the problem. I the first place I had to chose the "omsrasterreader" when providing the input data. 

Yet, I still got the error below, which we solved by editing the script (deleting 'rasterreader2.doLegacyGrass' 'false').

ERROR --------------------------------------------- No such field: doLegacyGrass

I hope this information will be of use.

Blal

[perleonardo]

I try to clarify the problems:

1) if you use an old oms* module you should use (select) also the omsRasterReader and omsRasterWriter
modules in order to give inputs and outputs to the command.

Otherwise the module can't read the inputs and you recive the obvious error:
"ERROR: Mandatory input argument is missing. Check your syntax..."

2) however in this case i've noticed that omsRasterReader try to use the option (flag) "doLegacyGrass",
I suppose this option is not for omsRaserReader, but only for the new RasterReader (non-oms).
Therefore you recive an error message because you try to use a non-existent option:
"ERROR: No such field: doLegacyGrass"

I've solved only by manually editing the script file for the command (autogenerated),
i've removed the line conteining 'rasterreader.doLegacyGrass' in the script.
Then you can launch the modified and saved script and it works well.


Leonardo

[andrea antonello]

Hi Blal, Leonardo,

> I try to clarify the problems:

I will clear up any doubt :-)

> 1) if you use an old oms* module you should use (select) also the

Why would you call them OLD??? The Oms* has nothing to do with old or
new. The Oms modules are kept, as the prefix says, to be in OMS
compatibility. They can be chained together as modules, without
intermediate IO.
The only old thing is the fact that in the past JGrasstools did
support ONLY this method, while with the scripting part (not the OMS3
one, which I find incredibly complex and overhead for most of everyday
work) we added the wrapper modules (the ones without Oms) to have a
nicer and simpler IO for any user.

> omsRasterReader and omsRasterWriter
> modules in order to give inputs and outputs to the command.
>
> Otherwise the module can't read the inputs and you recive the obvious error:
> "ERROR: Mandatory input argument is missing. Check your syntax..."

I solved this right now (change committed) by making the flag false if
it is not supplied.

Andrea

[andrea antonello]

Also, I just committed the BasinShape module, so from now on (given
you compile the new libs) BasinShape is also available.

Cheers,
Andrea

[perleonardo]

Thank you,

scuse me for the OLD descriptor, I used it only for the resons you
wrote, in the past there are only those and now there are the
"new" usefull wrapper.

Just an other question about omsBasinShape, in the "new" STAGE
I can no longer see the oms* modules, therefore omsBasinShape,
that exist only oms* and not with wrapper, is no longer present.
There is a way to use it yet in STAGE?

Thank you again,
Leonardo

[perleonardo]

Scuse me,

we are writing about the same thing in the same moment ;)

Great!

[andrea antonello]

[...]

> Just an other question about omsBasinShape, in the "new" STAGE
> I can no longer see the oms* modules, therefore omsBasinShape,
> that exist only oms* and not with wrapper, is no longer present.
> There is a way to use it yet in STAGE?

Not in the GUI, only in the scripting. It doesn't make much sense to
use them in the gui, since there is a wrapper that takes input and
output files instead of linking to readers and writers (i.e. one step
has been removed since unnecessary). Linking of modules has never been
supported from the GUI, only in scripting.
Therefore the GUI is simpler to use for anyone and advanced modellers
can go on doing what they were doing.

I hope I understood your question properly, since what you write
implies you want to do something *again*, which has never been
possible :-)

Cheers,
Andrea

>
> Thank you again,
> Leonardo
>
>
> On Monday, March 30, 2015 at 4:48:00 PM UTC+2, moovida wrote:
>>
>> Hi Blal, Leonardo,
>>
>> > I try to clarify the problems:
>>
>> I will clear up any doubt :-)
>>
>> > 1) if you use an old oms* module you should use (select) also the
>>
>> Why would you call them OLD??? The Oms* has nothing to do with old or
>> new. The Oms modules are kept, as the prefix says, to be in OMS
>> compatibility. They can be chained together as modules, without
>> intermediate IO.
>> The only old thing is the fact that in the past JGrasstools did
>> support ONLY this method, while with the scripting part (not the OMS3
>> one, which I find incredibly complex and overhead for most of everyday
>> work) we added the wrapper modules (the ones without Oms) to have a
>> nicer and simpler IO for any user.
>>
>> > omsRasterReader and omsRasterWriter
>> > modules in order to give inputs and outputs to the command.
>> >
>> > Otherwise the module can't read the inputs and you recive the obvious
>> > error:
>> > "ERROR: Mandatory input argument is missing. Check your syntax..."
>>
>> I solved this right now (change committed) by making the flag false if
>> it is not supplied.
>>
>> Andrea
>

> --
> 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.

[perleonardo]

Hi Andrea,

excuse me, another time I've bad explained myself,
of course what you explain is usefull,

but my problem is not strictly to use the oms* modules of BasinShape
from the GUI, that doesn't make much sense as you explained.

The point was to use BasinShape in STAGE becuse there was no
version non-oms of BasinShape (i.e. there wasn't the wrapper),
but in your previous post, if I well uderstand, you say that you
committed the BasinShape module.

I suppose this should solve the problem, in the next version of STAGE
I should see the BasinShape module?

Thank you for the explanation and excuse me for my previous bad question,
Leonardo

[andrea antonello]

Hi Leonardo,

> but my problem is not strictly to use the oms* modules of BasinShape
> from the GUI, that doesn't make much sense as you explained.
>
> The point was to use BasinShape in STAGE becuse there was no
> version non-oms of BasinShape (i.e. there wasn't the wrapper),
> but in your previous post, if I well uderstand, you say that you
> committed the BasinShape module.
>
> I suppose this should solve the problem, in the next version of STAGE
> I should see the BasinShape module?

ok, now I understand. Yes, that will solve it, but I am not sure when
that will happen right now. There is quite some work going on, also
with the Summer of Code at the doors.

So you can simply compile the libs and substitute the jars from your
STAGE installation.

Andrea

[perleonardo]

Ok, I've noticed that inside STAGE there are still the jar and is possible
to sobstitute it.

The problem is that I've no idea about compile tis type of libs,
have you any soggestion?..tutorial?..people in the univerity who couls teach?

Thank you,
Leonardo

[andrea antonello]

https://code.google.com/p/jgrasstools/wiki/Building
and
https://code.google.com/p/jgrasstools/wiki/JARExporting
will be a bit outdated but should still work pretty well.

Andrea