Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

# Example

# 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

share|improve this question
up vote 3 down vote accepted

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.

share|improve this answer
+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
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

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")


   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?

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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