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.biv...@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.biv...@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.biv...@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.biv...@nhh.no

_______________________________________________
grass-stats mailing list
grass-stats@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-stats

Reply via email to