v.distance linear matrix remove duplicate cat column & table associated without having map of distance lines

[Maellevd]

Hello, I would like to receive some details related to the v.distance module with the graphical interface in GRASS 7.4.1.

1) When I try to generate a linear matrix of distances using v.distance, I observe that the output contains a duplicate column (denoted “to_cat” and "cat" in the example below). Is there a reason for that ? Is there a way to generate a linear matrix of distances without that duplicated column ?

Here's an example command I ran:

v.distance -p -a from=hospitals@x to= hospitals@x upload=cat,dist

with the following output: from_cat | to_cat | cat | dist 1 | 1 | 1 | 0 1 | 2 | 2 | 7489.1043632983983 1 | 3 | 3 | 339112.17046729225 ...

2) When creating a table associated with the distance matrix:

a) why do my vector layers need to belong to the current mapsets while the goal is not to update the vector layers ?

Example:

Command:

v.distance -a from=hospitals@PERMANENT to= hospitals@PERMANENT output=map_connect_hospital_PERM upload=cat,dist column=to_cat,dist_min table=tabl_dist_PERM

Output: ERROR: Bug: tentative de mise à jour d'une couche qui n'est pas dans le jeu de cartes courant

b) why do you have to create a map of distance lines? Indeed, it seems to me that it would be interesting to generate the table without having this map.

Example:

Command:

v.distance -a from=hospitals@x to=hospitals@x output=map_connect_hospital upload=cat,dist column=to_cat,dist_min table=tabl_dist

How to get rid of this "output = map_connect_hospital" option and just get the table?

Thank you in advance for your feedback on these two concerns

[sbl]

Please try the p-flag for generating only the table. https://grass.osgeo.org/grass74/manuals/v.distance.html

As for the "duplicate" columns: Did you have a scroll down to from_cat 2? From there cat and to cat should no longer be duplicates...

In principle, such questions are better asked at the user-mailing list where you get more attention for the question. Closing this ticket as worksforme, as I think what you want to achieve is already possible. Please feel free to reopen if mailing list confirms lacking features or unintended behavior…

[sbl]

Sorry, I was a bit quick and see that

v.distance -p -a from=hospitals to= hospitals upload=cat,dist

indeed produce duplicate columns

Also,

ERROR: Bug: attempt to update map which is not in current mapset

should not happen. In addition, the resulting map also lacks an attribute table (which it should have). In more detail, the attribute table is produced, but not connected to the vector map...

Writing table-formated output from GRASS directy to the database is a different issue, and might be useful in more modules...

[mlennert]

Thanks for reopening the ticket as there are several elements that are real requests for enhancements or even bugs. However, I agree with sbl that the original bug post could be less in the form of questions and more in the form of a bug report / enhancement request. If you are not sure about how to use a module than ask a question on the list. If you are (pretty) sure that there is a problem with a module, post a ticket here with the description of the problem.

The duplicate cat values come from the fact that when you use -a a to_cat is automatically uploaded (otherwise how would one be able to use the resulting matrix ?), so upload=cat is redundant. But if a linear output is wanted, a second variable is needed. Try to run with upload=dist,to_x,to_y and you will see that there is no duplication.

Bug

• The fact that the creation of a table is only possible when the input maps are in the current mapset is a bug IMHO. It is due to the fact that in the code updating the table and creating a new table is treated as equal by calling Vect_set_db_updated(&From). Moving this to only the part where the existing table is updated solves this issue.

See r73272 for the fix. I'll backport to the other branches ASAP.

Enhancements

• Currently, when using the -ap flag combination with one single upload variable, the module automatically prints out a square matrix. However, in certain situations it might be very useful to be able to print out a linear matrix. This could handled by a flag, e.g. -s for square matrix, instead of automatically

• I do not understand why an output map should be necessary to create an output table. It can be useful to have such a table without a map.

• To add to this: when printing or creating a new table, one should be able to determine column names, not only for updating an existing table

I'll attach a patch with these enhancement (plus some attempt at cleaning up parser dependency instructions. This will partly change the module API, though, so we'll have to decide how to apply.

[sbl]

For a more general request of writing table-like results directly to database see: #3639

[mlennert]

patch for several issues identified in this ticket

[mlennert]

Replying to mlennert:

See r73272 for the fix. I'll backport to the other branches ASAP.

Done in r73273 and r73275.

I'll attach a patch with these enhancement (plus some attempt at cleaning up parser dependency instructions. This will partly change the module API, though, so we'll have to decide how to apply.

Also done. This patch creates a new (-s) flag which allows to output a square matrix if desired. By default the module will output a linear matrix, whatever the number of upload variables.

The patch also allows creating a table without creating a map and allows to determine column names in output, even when using -p or table=.

Please test.

[mlennert]

See ​https://github.com/OSGeo/grass/pull/601