2

I´m writing an esri shapefile from R (2.14.1) on windows, using writeOGR in the rgdal package, in the resulting dbf file, NA values in the spatialpointdataframe (in numeric columns) are not translated to null values but to 0, and sometime the whole column results in 0 values.

I´ve seen this thread, but nothing more recent, can this be resolved in other ways, than converting NAs to a known value before and then back again after writing the .shp?

http://osgeo-org.1560.n6.nabble.com/GRASS-stats-Re-R-sig-Geo-writing-shapefiles-DBF-files-when-input-data-contains-NA-td4049981.html

# Example
require(sp)
require(rgdal)

# example dataframe
x <- data.frame(ID = 1:10, Lon = seq (-85,-76,1), Lat = seq(-9, 0, 1), Data=c(1:5, NA, NA, 7, 9, 10))

#create spatialpointsdataframe
coordinates(x) <- c("Lon", "Lat")
proj4string(x) <- CRS("+proj=longlat +datum=WGS84")

#write to esri shapefile
writeOGR(x, dsn=getwd(), layer="example", driver="ESRI Shapefile")

resulting dbf table: resulting dbf

3

You could transform the NAs to another value, such as -9999, but unfortunately shapefiles do not support null values (they're built on DBF IV) - by default null numeric values are set to zero, and null strings become zero length strings.

Depending on what you want to do with the file afterwards, I'd look at exporting to a format such as Spatiallite, which does support null values.

  • 4
    +1 Actually, dbf files are capable of supporting nulls, but (as it's not built into the dBase standard) almost no software respects the difference. Numeric fields in dbf files are stored as ASCII-encoded base-10 text strings. A field containing all blanks (or even all ASCII zeros) therefore differs from a zero, but most software automatically converts a blank field to a zero. Therefore, unless you can be assured only your custom-built dbf translation software is ever going to touch the file, you must adopt a conventional numeric value to represent NA. – whuber Feb 8 '12 at 16:12
  • 1
    Thanks for the answers here, seeing blank cells in the table views in arcgis made me think that this was possible. – CCID Feb 8 '12 at 17:37
1

I don't have a copy of Arc* on hand to test this but I get a different sort of result - it seems that writeOGR DOES preserve NAs? Carrying on the code from @CCID above:

# have a look at the dbf file
xf <- read.dbf("example.dbf")
xf

Gives:

   ID Data
1   1    1
...
5   5    5
6   6   NA
7   7   NA
...

In QGIS the attribute table also shows NAs:

enter image description here

Perhaps this is only an issue in ArcGIS?

0

Probably a bit late, but I ran into the same issue. My workaround solution that seems to work in ArcGIS is that I used numerical NA value (-9999) while I fiddled with the data in R, and after saving it with writeOGR() I would manually edit the .dbf file attached to a shapefile.

For example:

library(rgdal)
library(foreign)

# Shapefile with -9999 as NA/NoData value    
writeOGR(my_shape,dsn="folder",layer= "my_shape", driver="ESRI Shapefile")

My_shape <- read.dbf("folder\\my_shape.dbf") # Load DBF file
My_shape[,3:23][My_shape[,3:23]==-9999] <- "NoData" # Find and replace
write.dbf(My_shape, "my_shape.dbf") # Overwrite the DBF file

I had names and ID's in first two columns, hence indexing specific columns. I do realize that this changes all the values to character from numeric, but in my case it did the trick when I import the shapefile to ArcGIS

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.