[R-sig-Geo] polygon identifiers and nb classes

[Roger Bivand]

On Thu, 13 Apr 2006, Larry Layne wrote:

> > Yes, if no row.names= argument is given to poly2nb(), this is what they
> > will default to.
> 
> FID + 1 is what I assume you to mean.
> 
> > You can choose your own row.names= in poly2nb(),
> 
> Which I did here:
> 
> NMnb <- poly2nb(NMpolylist,row.names="OBJECTID",queen=FALSE)
> 
> Now I know for sure which values are being used as polygon ids to define 
> the neighborhood list. (FYI, the shapefiles originally came from ArcGIS 
> geodatabase polygon feature classes and is the reason the field OBJECTID 
> exists in the shapefile DBF.)
> 
> > and setting oldstyle=FALSE, it should work.
> 
> ...oldstyle=FALSE in write.nb.gal. Actually this doesn't matter. oldstyle 
> can be either TRUE or FALSE - see below.
> 
> > You'll need to edit the first line, the ArcGIS format is not GAL as far as
> > I understand.
> 
> More than just the first line. As I understand the spatial weights matrix 
> file structure for ArcGIS there needs to be a complete rearrangement of the 
> GAL file. For instance, given the first 5 lines of a GAL file:
> 
> 0 49 unknown unknown
> 1 4
> 8 9 23 41
> 2 4
> 4 27 30 43
> 
> the information needs to be rearranged for an ArcGIS spatial weights file 
> as follows for a binary weights connectivity matrix (the first line of the 
> GAL file is discarded):

Right. Please look at write.sn2gwt() instead - it will need modification
to handle the IDs. I'll start looking at it - listw2sn() does carry 
through a region.id attribute, so changing the output function to 
substitute the IDs for the indices shouldn't be hard.

Roger


> 
> OBJECTID
> 1 8  1
> 1 9  1
> 1 23 1
> 1 41 1
> 2 4  1
> 2 27 1
> 2 30 1
> 2 43 1
> 
> The first line in the file is the name of the field in the DBF file used as 
> the polygon label ids. (I am using the work "line" to imply record, row, or 
> observation - take your pick.) This was specified above in poly2nb(). 
> Following the field name in the first line, each line in the text file 
> defines a weight for pairwise connections between polygons. Because polygon 
> #1 shares a boundary with 4 other polygons, the weights defining each of 
> these connections requires 4 lines in the ArcGIS spatial weights matrix 
> file. The same is true for polygon #2, etc. This is what I understand the 
> structure of the file to be for an ArcGIS spatial weights matrix file. I 
> convert the GAL structure to the ArcGIS spatial weights matrix file using a 
> SAS program. Any number of programming languages could be used to do the 
> same thing.
> 
> > For cross-checking in GeoDa, please set the shapefile= and ind=
> > arguments to the appropriate values.
> 
> I haven't used GeoDa to date. Maybe I should in the future? Maybe.
> 
> > A revision of write.nb.gal() is obviously possible here, I
> > would value feedback.
> 
> Once I figured out how to read the GAL structure I could convert it to any 
> other structure I wanted using SAS program code. For convenience, it might 
> be nice to have a function like write.nb.gal() but more general, like 
> write.nb() and allow the user to specify a parameter defining the structure 
> of the output. For instance, certainly one of the parameter settings would 
> be to write a GAL structure to a text file. Another might be to write one 
> for ArcGIS like that shown above. (This would also require defining the 
> weights in the output file, such as style = W, B, C, U, S.) I have a bunch 
> of SAS programs that use a neighbors structure like the following (using 
> the same poly ids for the GAL example from above):
> 
> 1 8 9 23 41
> 2 4 27 30 43
> 
> Structures for other popular spatial stats software? Might be useful to 
> different users.
> 
> > Please also crosscheck whether the variance of
> > Moran's I agrees with moran.test here in the randomisation=TRUE
> > row-standardised weights case - it is known not to agree for fixed range
> > and inverse distance weights in ArcGIS, the results here (and in Stata)
> > are consistent, but those in ArcGIS are not.
> > It will be interesting to hear what you find!
> 
> I plan to compare all of my results from ArcGIS spatial statistics 
> extension to those from spdep as it would be convenient to do a few more 
> things in ArcGIS than in spdep, and I would like to have some confidence in 
> the ArcGIS results. Generally, my experience with statistics anything in 
> ArcGIS is that its output always needs to be verified using some other 
> established software because ArcGIS is notorious for giving different 
> results. The one good thing about most of the spatial statistics extension 
> tools is that I can look at the algorithms they are implementing as most of 
> these tools are included as Python scripts. Anyway, I would be glad to send 
> you those comparisons right now but cannot because these particular tools 
> in the spatial statistics extension have suddenly decided to not work on 
> the computer I have the data on! What else could a person expect out of 
> such a high-quality software product? I'll send the ArcGIS comparison 
> results when I can.
> 
> Again, thanks for all your help.
> 
> Larry
> 

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