Open tpilz opened 2 years ago
One thing to add here:
The output of m.swim.routing
, the outlets
and inlets
vector maps, still have a cat column and differently sorted attribute tables, also in comparison to the subbasins map, which then causes further problems.
Thanks @tpilz, I think the subbasinID
runs pretty deep through the entire m.swim.*
package. Changing this to cat
so the R API can deal with it seems not sensible. If the key column name ever presents a problem, you can copy it to a different name like this:
v.db.update subbasins col=cat query_col=subbasinID
That should ensure it works with both m.swim.* and R (or not?).
And the cat
s of the inlets and outlets vectors are not the same as subbasinIDs, they both have a column referring to the subbasinIDs (I believe). Obviously, there can be more than one inlet and it can also happen that more outlets are created, hence the break between their IDs.
The workaround with v.db.update
definitely works. The biggest problem is that one has to know this and function rgrass7::writeVECT()
in R to export a vector to GRASS doesn't tell you that a cat column is silently added.
I adapted m.swim.camaflood
in a way where I hope this confusion is now resolved (also with the inlets and outlets vectors).
Hi @mwort,
I wonder if it wouldn't be wise to keep the cat column in the subbasins' attribute table? In the current workflow of
m.swim.subbasins
it is removed andsubbasinID
used as key column. However, GRASS seems to be quite fond of the cat column. For instance, I imported the subbasins map into R for some subsequent analyses and when writing it back to GRASS the column was silently added which screwed up my following workflow. Namely,m.swim.camaflood
then uses automatically the cat instead of subbasinID column as now cat is used as key column.How do you think about that?