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

[Larry Layne]

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

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