[R-sig-Geo] Exporting the SDF object created in spgwr to ESRI shapefile (shp)

[Roger Bivand]

On Tue, 1 Apr 2008, Jay Douillard wrote:

> Hello,
>
> So I have imported a shapefile into R, and ran the gw.cov function. Now 
> I wish to export a sub set of this information back to arcgis for 
> visualization.

Note that gw.cov() is just an (anti)-proof of concept, and likely tells 
you nothing whatsoever, especially with many variables, very much GIGO.

>
> 1805 variables were created, of which a need 30 or so. I have been 
> trying to just export the SDF with rgdal and writeOGR
>

You asked for the local correlation coefficients, you can set cor=FALSE. 
But you still get the covariance pairs. Subset by matching (or grepping) 
on the names of SDF). How many input variables were there, and why?

>
> writeOGR(gwls$SDF,td, "filename", driver="ESRI Shapefile")
>
> Which results in "Can't parse PROJ.4-style parameter string" is the 
> result

Why td? Do you really want to write to a temporary directory?

Where is the output of traceback()? Where is the output of summary() of 
your input SpatialPolygonsDataFrame object? Is proj4string(gwls$SDF) as it 
should be? Could you set it for x as input object:

proj4string(gwls$SDF) <- CRS(proj4string(x))

What was proj4string(x), was it as it should be? Did you read with 
readOGR() and was there a *.prj file?

>
> Alternatively I've considered that I could just export a subset of the 
> variables as a dbf, and join it to the original shapefile in arcgis.
>
> My imported object has a "n_code" column that is my key variable for 
> each polygon. Is there a way to carry this through the gw.cov function 
> so the object generated object still has the id column, which would 
> allow an easy textfile (or dbf) export?

If the input object was x, why not just say

gwls$SDF$n_code <- x$n_code

unless you are using the fp= argument. If you are, there is no match 
anyway, because your fit points and data points differ.

This looks suspiciously like real estate data mining. GWR generally and GW 
local statistics are (very) thin ice and crucially depend on the bandwidth 
and the actual model of the data. Unless you know your data very well, 
they may be very misleading, I'm afraid. If you do know where apparent 
non-stationarity is coming from, it is better to model it properly.

Roger

>
>
> Thanks!
> and please forgive me inexperience with R and spgwr!
>

Inexperience with R/spgwr isn't a problem, but using GWR as a data mining 
tool is a problem. It isn't proven, really.

> _______________________________________________
> R-sig-Geo mailing list
> R-sig-Geo at stat.math.ethz.ch
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

-- 
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: Roger.Bivand at nhh.no