[GRASS-stats] Re: [R-sig-Geo] writing shapefiles / DBF files when input data contains NA

[Dylan Beaudette]

On Tuesday 07 October 2008, Roger Bivand wrote:
> On Mon, 6 Oct 2008, Dylan Beaudette wrote:
> > Hi,
> >
> > I have noticed that saving data to files that include a DBF, result in
> > bogus data where there were NA. Using the write.dbf() function from
> > the foreign package seems to work a little better, but I still get odd
> > results in numeric columns. Writing to GRASS with the methods in the
> > spgrass6 package results in some thing that looks like this:
>
> Dylan,
>
> I'm afraid that there is no good solution for this at all. DBF does not
> seem to have a clear and uniform NA treatment (or even !is.finite()
> treatment). The only work-around is to preprocess the data.frame in the
> output object to insert known NODATA values, and to replace those flags
> manually on the GRASS side. This could possibly be written as a wrapper
> around writeVECT6(). The help page does say:
>
>      "Please note that the OGR drivers used may not handle missing data
>       gracefully, and be prepared to have to correct for this manually.
>       For example use of the 'readOGR' PostGIS driver directly may
>       perform better than moving the data through the DBF driver used in
>       this function - or a PostgreSQL driver used directly or through
>       ODBC may be a solution. Do not rely on missing values of vector
>       data moving smoothly across the interface."
>
> I did try to look at the SQLite driver on the GRASS side, which might be
> more robust, but did not see how to proceed.
>
> One possibility is not to recode, but to build an NA mask on the R side,
> and then loop over fields on the GRASS side for the chosen driver
> inserting NAs in the correct rows (whatever the syntax for that might be).
> Would this be db.execute with an insertion of SQL NULL?
>
> Can we redirect this discussion to the statgrass list, because GRASS
> developers follow that list?
>
> Best wishes,
>
> Roger

Sorry for the cross-posting. Wanted to clarify where this thread is 
going/went.

Hi Roger--

It looks like the limiting factor in this equation is the code used in 
v.out.ogr. 

From the GRASS-dev + Frank W's help:

> > Sounds good :)
> > Does anyone know how to fix
> >  vector/v.out.ogr/main.c
> > to support NULLs? I see db_set_value_null() in
> >  lib/db/dbmi_base/value.c
> > which might be relevant.
>
> Markus,
>
> Once you establish which GRASS attributes are NULL, you can ensure they
> are pushed out to OGR as null by just skipping the step that sets them.
> Perhaps that will help a bit.


So, once v.out.ogr is fixed, this should clear up several issues:

1. import of vector data into R via spgrass6 methods
2. better compatibility of vector data exported from GRASS

I still do not know why writeOGR() does not create correct DBF files... it may 
be related to the code in v.out.ogr.... 

Cheers,

Dylan

-- 
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341