[GRASS-stats] Why does rgrass7::writeVECT() silently add a cat column if it doesn't exist?

[Tobias Pilz]

Hi Roger,

thanks for clarification. I understand why it happens but I still think 
this is somewhat unexpected behaviour.

However, to wrap it up, I guess it's always best to have a 'cat' column 
in the attribute table as then this won't happen.

Tobias


Am 21.10.21 um 09:55 schrieb Roger Bivand:
> On Thu, 21 Oct 2021, Tobias Pilz wrote:
>
>> Hi Vero,
>>
>> as I understand it, vector files in GRASS need a key column if they 
>> have an attribute table. But I don't see that this has to be a column 
>> named 'cat'. However, GRASS is quite inconsistent here. Some 
>> functions ensure the existence of a 'cat' column, such as 
>> v.db.dropcolumn (just gives an error if you try to remove the 'cat' 
>> column), whereas other functions let one define other columns as key 
>> column (e.g. manually in the GUI or v.db.addtable).
>>
>> The latter happened with my vector map, i.e. a different column was 
>> defined as key column. Therefore it is confusing why 
>> rgrass7::writeVECT() just adds the cat column and without any 
>> notification. This makes no sense to me and is annoying as my 
>> subsequent workflow produced unexpected results and I had to trace 
>> back the error which took a while.
>
> In sf vector objects, there is no concept of key column, I think. In 
> sp vector objects (used before, should be avoided from now on as sf is 
> actively maintained), the geometry ID is keyed to the row.names of the 
> data slot data.frame object, but is also not seen as a user-facing key 
> column.
>
> So you are adding (as a user) a concept not present  in the R-side 
> objects.
>
> In practice, cat can be useful where cleaning has split line or 
> polygon objects imported into GRASS into multiple features, which can 
> then be unioned back after exporting from GRASS to R, but this isn't a 
> concept, it is a pragmatic fix.
>
> Hope this clarifies,
>
> Roger
>
>
>>
>> From my perspective as user it would be great if a more consistent 
>> solution regarding the treatment of key columns could be found, i.e. 
>> either always ensure the existence of a column named 'cat' or just 
>> accept if the user specifies a different key column.
>>
>> Regards,
>>
>> Tobias
>>
>> Am 20.10.21 um 20:41 schrieb Veronica Andreo:
>>>  Hello Tobias,
>>>
>>>  The cat colum is the ID that GRASS uses for vectors, hence this is
>>>  expected
>>>  and right. The same happens if you import a gpgk or shape or any other
>>>  vector file into GRASS. See
>>>  https://grass.osgeo.org/grass78/manuals/vectorintro.html for 
>>> further info
>>>
>>>  HTH,
>>>  Vero
>>>
>>>
>>>
>>>  El mié, 20 oct 2021 a las 9:34, Tobias Pilz (<topilz at pik-potsdam.de>)
>>>  escribió:
>>>
>>>>  Dear list,
>>>>
>>>>  when I use in R the writeVECT() command the resulting map in GRASS 
>>>> got
>>>>  the 'cat' column silently added to its attribute table if it didn't
>>>>  exist.
>>>>
>>>>  The vector object in question was previously imported to R via
>>>>  readVECT() and had a different column defined as key column.
>>>>
>>>>  Is this behaviour of writeVECT() intentional? If yes, why so and
>>>>  wouldn't it make sense to give a warning?
>>>>
>>>>  Note: I used rgrass7 version 0.2-6 together with GRASS 7.8.5 under 
>>>> Linux
>>>>  (opensuse).
>>>>
>>>>  Regards,
>>>>
>>>>  Tobias
>>>>
>>>>
>>>>  _______________________________________________
>>>>  grass-stats mailing list
>>>>  grass-stats at lists.osgeo.org
>>>>  https://lists.osgeo.org/mailman/listinfo/grass-stats
>>>>
>>
>
-- 
Dr. Tobias Pilz

Climate Resilience - Research Department 2
Tel: +49 331 288 2539
E-mail: tobias.pilz at pik-potsdam.de

Potsdam Institute for Climate Impact Research
Telegraphenberg A 31
P.O. Box 60 12 03
D-14412 Potsdam
www.pik-potsdam.de/members/topilz

You are welcome to send me PGP/GnuPG encrypted messages. Please find my public key on the common servers.