Message-ID: <200810071815.42637.dylan.beaudette@gmail.com>
Date: 2008-10-08T01:15:42Z
From: Dylan Beaudette
Subject: writing shapefiles / DBF files when input data contains NA
In-Reply-To: <Pine.LNX.4.64.0810070857510.11660@reclus.nhh.no>
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.