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

[Dylan Beaudette]

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:

### code snippet:
writeVECT6(SDF=spatial.data, vname='pedons_grouped')


### errors:
Projection of input dataset and current location appear to match
Layer: pedons_g
WARNING: Column name changed: 'describer.' -> 'describer_'
WARNING: Column name changed: 'cat' -> 'cat_'
Importing map 103 features...
DBMI-DBF driver error:
SQL parser error: @@rror, unexpected NAME processing 'nan'
in statement:
insert into pedons_grouped values ( 1, 'd2g1', 'alex',
32.311427999999999,      252.434875000000005,     7227.804688000000169,
-0.000162000000000,           3,                      nan, 'NA',
-2147483648, 'NA', 'NA', -2147483648, -2147483648, 'NA',
nan, '1', 'NA' )
Error in db_execute_immediate()

ERROR: Cannot insert new row: insert into pedons_grouped values ( 1,
       'd2g1', 'alex', 32.311427999999999, 252.434875000000005,
       7227.804688000000169, -0.000162000000000, 3, nan, 'NA',
-2147483648,
       'NA', 'NA', -2147483648, -2147483648, 'NA', nan, '1', 'NA' )


### another self-contained example:


# load libs
library(sp)
library(rgdal)
library(foreign)

# read in xy data and promote to sp object
e <- read.csv(url('http://casoilresource.lawr.ucdavis.edu/drupal/files/elev.csv_.txt'))
coordinates(e) <- ~ x+y

# add a factor column
e at data$f <- factor(rep(letters[1:10], each=30))

# add some NA
e at data$elev[288:300] <- NA
e at data$f[288:300] <- NA

# save sp object to shapefile
writeOGR(e, driver='ESRI Shapefile', dsn='.', layer='pts')


# the results from dumping the DBF:
[...]
285,1543,j
286,1518,j
287,1656,j
288,-2147483648,NA
289,-2147483648,NA
[...]


# one more try with the foreign package's write.dbf()
write.dbf(e at data, file='second_try.dbf')

# results: look better, although the '******' isn't a legal int!
[...]
285,1543,j
286,1518,j
287,1656,j
288,*******,
289,*******,
[...]


Any ideas on how to work with missing data in numeric columns, when
the dreaded DBF file is involved??? This is a real show-stopper when
sending vector data back to GRASS, as it seems to rely on intermediate
files. Maybe it would be a good idea to send  the geometry first, and
then the attribute data. There would still be a problem if the DBF
back-end is in use...

Cheers,

Dylan