[GRASS-stats] rgrass7 read/write SpatialPolygonsDataFrames errors

[Eduardo Diez]

Here's the return from the latest version:

> zm.fnl <- readVECT(zm.gnrl)Exporting 29 areas (may take some time)...

VOUTOG~1 complete. 29 features (Polygon type) written to <k4610e1>
(ESRI_Shapefile format).
OGR data source with driver: ESRI Shapefile
Source: "C:/Users/ediez1/AppData/Local/Temp/Rtmp0MDfLZ/file2b9e445e7487a/file2b9e47fcf5925/.tmp/unknown",
layer: "k4610e1"
with 29 features
It has 3 fieldsWarning message:In vColumns(vname) : vColumns: v.info
-c output not in two columns:
Displaying column types/names for database connection of layer <1>:


Regards


2015-10-11 16:49 GMT-03:00 Roger Bivand <Roger.Bivand at nhh.no>:

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