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 -- Dylan Beaudette Soil Resource Laboratory http://casoilresource.lawr.ucdavis.edu/ University of California at Davis 530.754.7341 _______________________________________________ grass-stats mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-stats
