QGIS » SEXTANTE

I have started to manually correct them and will send a diff.

Great! thanks for your help. I will commit all your changes once they are ready, which will greatly improve the SEXTANTE-GRASS conection

Please post the link to the current descriptions. As announced, I would like to
rework them again for the lacking module description in each file.

You mean this? http://sextante.googlecode.com/svn/trunk/soft/bindings/qgis-plugin/src/sextante/grass/description/

Hopefully not. It lacks all my fixes posted in

differences_part2.diff (85.3 kB) - Markus Neteler -, 05/29/2012 07:33 am

Sorry Markus, I thought that the patch that Markus Metz sent me had also all your corrections, so I just applied his one. I have just commited your changes as well. Current revision is r201. SVN trunk is here, as Paolo pointed out: http://sextante.googlecode.com/svn/trunk/soft/bindings/qgis-plugin/src/sextante/grass/description/

Great!

Some comments to your comments

- r.rescale + r.rescale.eq, and others:
ParameterRange: should not have 0,1 predefined, see r.rescale as
bad example since it ruins "default: full range of input map"
--> or, how to do that? please explain in sextante/grass/description/grass.txt

Having parameters that behave differently if they have a value or not is not currently supported. Until we find a way to do this cleanly and efficiently (without having to implement both behaviours explicitly for each algorithm...), I suggest in this case removing the parameter, so it works with the full range. a different range can be used just by reclassifing the layer before, which might not be optimal, but is an alternative option

- strange (uninterpreted by GUI) /file in r.recode and other files
--> ParameterString|rules|File containing recode rules|/file
should be: InputFile|rules|File containing recode rules|file

Can be fixed by using

ParameterFile|rules|File containing recode rules|False
(false indicates that is not a folder but a file)

- Overall bug: Progress bar remains at 0%

I am doing most of the coding and testing in windows, and it works. I test the output for string containing "GRASS_INFO_PERCENT", and with that I update the bar. Maybe in linux the console output is not the same? (I guess so, seeing the other comment you mention about the ugly console output...) Any tip about that?

Victor Olaya wrote:

Great!

Thanks for the quick response! About v.surf.rst split into two, that makes sense, I was just not up to date with my local copy and missed v.surf.rst.cvdev.txt.

Some comments to your comments

- r.rescale + r.rescale.eq, and others: ParameterRange: should not have 0,1 predefined, see r.rescale as bad example since it ruins "default: full range of input map" --> or, how to do that? please explain in sextante/grass/description/grass.txt

Having parameters that behave differently if they have a value or not is not currently supported. Until we find a way to do this cleanly and efficiently (without having to implement both behaviours explicitly for each algorithm...), I suggest in this case removing the parameter, so it works with the full range. a different range can be used just by reclassifing the layer before, which might not be optimal, but is an alternative option

About ParameterRange, how can you set a default range? Currently it seems hard-coded to 0,1, but some modules have different defaults, e.g. i.atcorr has 0,255 as default for both input and output rescaling.

- strange (uninterpreted by GUI) /file in r.recode and other files --> ParameterString|rules|File containing recode rules|/file should be: InputFile|rules|File containing recode rules|file

Can be fixed by using

ParameterFile|rules|File containing recode rules|False (false indicates that is not a folder but a file)

Does that mean that InputFile should be replaced by ParameterFile? I have added InputFile to a number of module descriptions.

- Overall bug: Progress bar remains at 0%

I am doing most of the coding and testing in windows, and it works. I test the output for string containing "GRASS_INFO_PERCENT", and with that I update the bar. Maybe in linux the console output is not the same? (I guess so, seeing the other comment you mention about the ugly console output...) Any tip about that?

Digging a bit in the code, I discovered that GrassUtils.createGrassScript() sets GRASS_MESSAGE_FORMAT=gui which toggles GRASS_INFO_PERCENT. On non-Windows platforms, GrassUtils.createGrassBatchJobFileFromGrassCommands() is called which does not set GRASS_MESSAGE_FORMAT=gui, i.e. no GRASS_INFO_PERCENT. I guess the reason why GrassUtils.createGrassScript() is not used on non-Windows platforms is that folder = GrassUtils.grassPath() which is $GISBASE is not (yet) available on non-Windows platforms. You could get $GISBASE by starting a GRASS batch job which only prints GISBASE to somewhere, then you have GISBASE and could use GrassUtils.createGrassScript() with some minor platform-specific modifications on all platforms. Or you could set GRASS_MESSAGE_FORMAT=gui in the GRASS batch file.

One of the last changes to svn broke some of those interfaces where a GRASS command has been split in two. The first line of the corresponding text file must still be the GRASS command name, i.e. v.surf.rst and not v.surf.rst.cvdev. The affected *.txt files are

v.buffer.column.txt
v.buffer.distance.txt
v.surf.rst.cvdev.txt
v.to.rast.attribute.txt
v.to.rast.value.txt

MArkus

Yes, ParameterFile must be used, InputFile is not a valid tag understood by SEXTANTE

Regarding the ParameterRange, I have seen that some descriptions have different default values set. Unfortunately, there was a bug in the ParameterRange class, and they were not correctly processed. I have fixed it (already in r207) and it should work now.

Linux and Windows version call GRASS differently, because in windows the GRASS_BATCH_JOB does not work so perfectly. It would be great to use the same approach for both, but windows is a bad platform in this case...so that's why there is that other method. i will change the GRASS_MESSAGE_FORMAT to gui in the linux version as well, so they behave the same, and the current system for parsing GRASS output can be used in both OSs

Victor: are our patches now available in 1.0.7? Thanks, MarkusN

I have just checked the current description files, and they contain your descriptions, so they should appear.

Just one randomly chosen:

r.patch
r.patch - Creates a composite raster map layer by using one (or more) map layer(s) to fill in areas of "no data" in another map layer.
Raster (r.*)
ParameterMultipleInput|input|Name of raster maps to be patched together|1.0|False
ParameterBoolean|-z|Use zero (0) for transparency instead of NULL|False
OutputRaster|output|Name for resultant raster map

Seems it is fine, right? It appears correct from the toolbox, as well.

Have you installed 1.0.7 without problems?

(sorry if I do not answer quickly in case you detect any problem, since i will be away this week...but hope to fix anything if needed once I am back...)

It looks good to me, thanks for the great work!

Markus Neteler - wrote:

It looks good to me, thanks for the great work!

can we close this ticket?