cat column of subbasins map

[tpilz]

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 and subbasinID 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?

[tpilz]

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.

[mwort]

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?).

[mwort]

And the cats 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.

[tpilz]

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).