-
-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Processing: v.net tools (GRASS) return empty outputs #27728
Comments
Author Name: Nyall Dawson (@nyalldawson) Hi Giovanni, Are you able to attach some layers which I can use to test this? I've hit issues with this algorithm too, but couldn't work out the magic formula to get it to work in 2.18 either...
|
Author Name: kajo kaji (kajo kaji) Seems a more general issue with GRASS output generation (see another case in #27747) |
Author Name: Giovanni Manghi (@gioman) Nyall Dawson wrote:
here (test data and screenshot courtesy of Pedro Venancio): https://drive.google.com/file/d/1zkK6BRU1OWElqadHAXI6uIrzPsrm0z5l/view?usp=sharing |
Author Name: Jürgen Fischer (@jef-n)
|
Author Name: Pedro Venâncio (Pedro Venâncio) This issue still happen in QGIS 3.4.4. I attach log files of v.net.distance in QGIS 2.18.28 and 3.4.4. The differences are mainly in
A complete dataset for testing v.net.* tools can be found here: http://qgis.pt/workshops_qgis2016/dados_exercicio_analise_redes.zip
|
Author Name: Giovanni Manghi (@gioman)
|
Author Name: Alexander Bruy (@alexbruy) Am I right that empty output produced only when executed via Processing and correct results produced when executing same commands in GRASS directly?
|
Author Name: Pedro Venâncio (Pedro Venâncio) Hi Alex, It works with same data in QGIS 2.18.28, using same GRASS version (now 7.6.0). I was looking more carefully, and the problem only happens when using +arc_column+ and +arc_backward_column+ parameters. This works in QGIS 3.4.4:
And this does not work (gives empty output), using exactly the same input data:
Running both commands directly in GRASS 7.6.0, with intermediary data generated by QGIS 3.4.4 (v.in.ogr, g.region, v.net, v.db.connect - data saved in tmp folder) the output is the same, that is, an empty file using arc_column and arc_backward_column parameters, and the message:
So, given that all this works in QGIS 2.18.28 (with same data and same GRASS version), the problem must be somewhere in v.net / v.db.connect intermediary operations? The order is different, I don't know if this is relevant, but could be here:
|
Author Name: Giovanni Manghi (@gioman)
|
Author Name: Pedro Venâncio (Pedro Venâncio) Ok, it seems the order is not relevant for this issue, because the same happens with v.net.iso, and there we have only one v.net + v.db.connect. I was looking to the temporary grass mapsets created both by QGIS 2.18.28 and 3.4.4, and I think I've found the source of the problem. For instance, in v.net.iso from QGIS 3.4.4, v.net + v.db.connect creates a network layer that have a new line, connecting the point layer to the lines (network) layer. This new line has no data in the attribute table. Please, see the image attached. In QGIS 2.18.28, this new line is not created. Then, when running v.net.* algorithms with arc_column and arc_backward_column parameters, this new line has null data, when numeric data are expected. And the error is shown:
Temporary mapsets can be downloaded from here, if you need test: https://cld.pt/dl/download/3dbf4723-66df-44ed-9424-0cf2d495812e/grassdata_21828.zip https://cld.pt/dl/download/4f3fef72-bdac-424c-a5f5-891324db3833/grassdata_344.zip So, why is this new line created in QGIS 3.4.4?
|
Author Name: Pedro Venâncio (Pedro Venâncio) I found it! v.net needs the -s flag to snap points to network for operation connect. By default, v.net add a new line from the point to the network. In 2.18.28, the -s flag is present. |
Author Name: Pedro Venâncio (Pedro Venâncio) Simply changing \python\plugins\processing\algs\grass7\ext\v_net.py line 61 to
\python\plugins\processing\algs\grass7\ext\v_net_distance.py lines 51 and 56 to
do the work. Other v.net.* algorithms needs to be checked also. Can someone apply this changes to master and backport to 3.4.x? Thanks! |
Author Name: Alexander Bruy (@alexbruy) Pedro Venâncio wrote:
Thanks for your work! I will take care about updating code and backporting
|
Author Name: Alexander Bruy (@alexbruy)
|
Author Name: Alexander Bruy (@alexbruy)
|
Author Name: Giovanni Manghi (@gioman)
Original Redmine Issue: 19904
Affected QGIS version: 3.4.4
Redmine category:processing/grass
Assignee: Alexander Bruy
The tools do run, they produce an output but this is always empty.
This set of tools works ok on 2.18.
The text was updated successfully, but these errors were encountered: