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

[Dylan Beaudette]

On Tuesday 07 October 2008, Dylan Beaudette wrote:
> 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

Some follow-up: the incorrect handling of NULL values appears to be related to 
the current implementation of v.out.ogr AND readOGR() / writeOGR().

Dylan

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