[GRASS-stats] rgrass7 read/write SpatialPolygonsDataFrames errors

[Roger Bivand]

On Sat, 10 Oct 2015, Roger Bivand wrote:

> On Sat, 10 Oct 2015, Eduardo Diez wrote:
>
>> This is what i got:
>>
>>> vinfo0 <- execGRASS("v.info", flags="c", map=zm.gnrl)INTEGER|cat
>> INTEGER|ID
>> INTEGER|GRIDCODE
>> Displaying column types/names for database connection of layer <1>:
>>
>>
>> And trying to read back the original polygon (without v.clean):
>>
>>> zm.fnl <- readVECT(zm.pol)Error in scan(file, what, nmax, sep, dec, quote, 
> skip, nlines, na.strings,  :
>>  line 4 did not have 2 elements
>>
>
> This is coming from:
>
>     G_message(_("Displaying column types/names for database connection of 
> layer <%s>:"), field_opt);
>
> line 134 in vector/v.info/print.c.
>
> For me in nc_basic, for schools, I do not see the message with:
>
> vinfo0 <- execGRASS("v.info", flags="c", map="schools", layer="1",
>  intern=TRUE)
>
> which is what is being used in vColumns. Is there an alternative to v.info 
> that may be less error-prone?

The development Windows binary of rgrass7 at:

http://win-builder.r-project.org/9YK08bQi1ldt

is an attempt to address a problem I cannot reproduce (with GRASS 7.0.1 
Windows standalone) - instead of assuming two-column output, it drops 
lines with != 2 columns and issues a warning if they were found.

There is a further weakness in the readVECT code involving a conditional 
assumption that the db driver is sqlite - is there any way to check from 
outside which driver is being used?

Roger

>
> Roger
>
>>
>>
>>
>>
>> 2015-10-10 13:12 GMT-03:00 Roger Bivand <Roger.Bivand at nhh.no>:
>>
>>> On Sat, 10 Oct 2015, Eduardo Diez wrote:
>>>
>>> Apparently "v.info" through execGRASS is expecting the "layer" argument to
>>>> be a string rather than an integer.
>>>>
>>>
>>> Yes, please re-run with "1"; this resulted from GRASS6 to GRASS7
>>> over-enthusiastic changing everything just for fun - this isn't the
>>> problem. Run (assuming that zm.gnrl contains a character string):
>>>
>>> vinfo0 <- execGRASS("v.info", flags="c", map=zm.gnrl)
>>>
>>> My guess is that v.info is saying that this map is broken, or suffering
>>> from something that vColumns does not know about.
>>>
>>> v.info -c map=
>>>
>>> should simply respond with "<storage type>|<name>" lines for the fields in
>>> the layer. Here, its fourth line (unlike the first three) does not have 
> two
>>> elements (the type/name pairs).
>>>
>>> Does readVECT() work if you do not use v.clean? Is v.clean having a side
>>> effect of causing v.info -c to "say" something else? How should the input
>>> columns of the object to be cleaned be turned into output columns (simply
>>> copy across the retained areas?)?
>>>
>>> Roger
>>>
>>>
>>
>
>

-- 
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; fax +47 55 95 91 00
e-mail: Roger.Bivand at nhh.no