[GRASS-stats] rgrass7 read/write SpatialPolygonsDataFrames errors

[Roger Bivand]

On Sun, 11 Oct 2015, Eduardo Diez wrote:

> With today's development version it works with the warning you mentioned.
>
>> zm.fnl <- readVECT(zm.gnrl)Exporting 29 areas (may take some time)...
>
> VOUTOG~1 complete. 29 features (Polygon type) written to <dc2ad04>
> (ESRI_Shapefile format).
> OGR data source with driver: ESRI Shapefile
> Source: "C:/Users/ediez1/AppData/Local/Temp/RtmpW8PKp3/file2b88c7f0f107d/file2b88c71f92564/.tmp/unknown",
> layer: "dc2ad04"
> with 29 features
> It has 3 fieldsWarning message:In vColumns(vname) : vColumns: v.info
> -c output not all in two columns

Please try:

http://win-builder.r-project.org/miws6tzuLCCJ

for a new version that should report the !=2 columns lines, and 
accommodates a safety fix to use Markus' suggestion to retrieve the db 
type, and drop the fix for long file names if the GRASS db driver is nor 
sqlite.

Roger

>
>
> Thanks a lot for all the time invested in developing and mantaining these
> wonderful  tools everyone can use.
>
> A side question: is there a way of performing the same thing i'm trying to
> do from GRASS (i.e. removing specific sized polygons by including them into
> larger ones) from plain R without needing to call external functions?
>
> Thanks again
> Eduardo
>
>
> 2015-10-11 11:28 GMT-03:00 Roger Bivand <Roger.Bivand at nhh.no>:
>
>> 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
>>
>>
>

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