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 _______________________________________________ R-sig-Geo mailing list R-sig-Geo@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-geo