[GRASS-user] v.net.steiner works in QGIS2 but not in QGIS3

Hello,

I am unable to figure out why a certain processing algorithm (v.net.steiner) works fine in QGIS2, but not in QGIS3. I am using the same line and point layer with the same cost column. The input data as well as the cost column are the only parameters that I define, the others remain the default ones.

In QGIS2 the processing history looks like this:

processing.runalg(“grass7:v.net.steiner”,“C:/xxx/linesLayer.shp”,“C:/xxx/nodeLayer.shp”,50,2,“1-100000”,“boundary”,-1,False,“794057.939937,794307.889937,9833916.58837,9834082.13837”,-1,0.0001,0,None)

The result looks the following connecting the 3 nodes via the line layer.

In QGIS3 the processing history looks like this:

processing.run(“grass7:v.net.steiner”, {‘input’:‘C:/xxx/linesLayer.shp’,‘points’:‘C:/xxx/nodeLayer.shp’,‘threshold’:50,‘arc_type’:[0,1],‘terminal_cats’:‘1-100000’,‘acolumn’:‘boundary’,‘npoints’:-1,‘-g’:False,‘output’:‘G:/1_QGIS_Temp_files/processing_f8ef30794232406cb21d5d7cc1d06809/4774808dfe284dafafd9a15a9879a5c1/output.shp’,‘GRASS_REGION_PARAMETER’:None,‘GRASS_SNAP_TOLERANCE_PARAMETER’:-1,‘GRASS_MIN_AREA_PARAMETER’:0.0001,‘GRASS_OUTPUT_TYPE_PARAMETER’:0})

No result is created. The error messages indicate that the point layer cannot be used:

FEHLER: v.net.steiner: Sorry, is not a valid parameter

Importing the data to GRASS7 directly and running v.net.steiner there indicates the same, as I get the following error message:

Number of terminals: 0, ERROR: Nicht genügend Stationen (< 2)

I uploaded the subset of the line and point layer that I used here (https://share4land.itc.utwente.nl:5566/sharing/pfjsbL9G8).

Both QGIS2 and QGIS3 versions use GRASS7.4.

Any ideas on how to figure out further what the problem might be?

Best,

Sophie

Hi Sophie,

···

On Tue, Jun 12, 2018 at 4:26 PM, Sophie Crommelinck <sophie.crommelinck@gmail.com> wrote:

Hello,

I am unable to figure out why a certain processing algorithm (v.net.steiner) works fine in QGIS2, but not in QGIS3. I am using the same line and point layer with the same cost column. The input data as well as the cost column are the only parameters that I define, the others remain the default ones.

In QGIS2 the processing history looks like this:

processing.runalg(“grass7:v.net.steiner”,“C:/xxx/linesLayer.shp”,“C:/xxx/nodeLayer.shp”,50,2,“1-100000”,“boundary”,-1,False,“794057.939937,794307.889937,9833916.58837,9834082.13837”,-1,0.0001,0,None)

… note that there are no parameter names coded.

But here:

[…]

In QGIS3 the processing history looks like this:

processing.run(“grass7:v.net.steiner”, {‘input’:‘C:/xxx/linesLayer.shp’,‘points’:‘C:/xxx/nodeLayer.shp’,‘threshold’:50,‘arc_type’:[0,1],‘terminal_cats’:‘1-100000’,‘acolumn’:‘boundary’,‘npoints’:-1,‘-g’:False,‘output’:‘G:/1_QGIS_Temp_files/processing_f8ef30794232406cb21d5d7cc1d06809/4774808dfe284dafafd9a15a9879a5c1/output.shp’,‘GRASS_REGION_PARAMETER’:None,‘GRASS_SNAP_TOLERANCE_PARAMETER’:-1,‘GRASS_MIN_AREA_PARAMETER’:0.0001,‘GRASS_OUTPUT_TYPE_PARAMETER’:0})

… here yes. And v.net.steiner does not have a “points” parameter, see

https://grass.osgeo.org/grass74/manuals/v.net.steiner.html

v.net.steiner [-g] input=name output=name [arc_type=string[,string,…]] [arc_layer=string] [node_layer=string] [acolumn=string] terminal_cats=range [npoints=integer] [–overwrite] [–help] [–verbose] [–quiet] [–ui]

Hence this error:

No result is created. The error messages indicate that the point layer cannot be used:

FEHLER: v.net.steiner: Sorry, is not a valid parameter

The bug seems to be in this file
https://github.com/qgis/QGIS/blob/master/python/plugins/processing/algs/grass7/description/v.net.steiner.txt

I’d suggest you open a bug report with QGIS on this.

best,

Markus

Markus Neteler, PhD
http://www.mundialis.de - free data with free software
http://grass.osgeo.org
http://courses.neteler.org/blog

(cc list)

On Wed, Jun 13, 2018 at 8:14 AM, Sophie Crommelinck
<sophie.crommelinck@gmail.com> wrote:

Hi Markus,

thanks for the advise. It would indeed have been more logical to ask the
QGIS community rather than the GRASS one about the issue.
I now opened a bug report issue: https://issues.qgis.org/issues/19186

Thanks for the upstream report.

Markus