[GRASS-stats] rgrass7 read/write SpatialPolygonsDataFrames errors

Eduardo Diez eduardodiez at gmx.com
Sun Oct 11 09:41:26 PDT 2015


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


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-stats/attachments/20151011/204e79ee/attachment.html>


More information about the grass-stats mailing list