Skip to content

How to find neighbor polygons and analysis of their attributes

8 messages · Roger Bivand, Debarchana Ghosh

Original
Roger Bivand
#
On Fri, 16 Feb 2007, Debarchana Ghosh wrote:

            

      
      
      
    

        
No, the underlying code for both of these is the same, shapelib, (but in
maptools has some extra tweaks for non-conforming shapefiles).

You can use getinfo.shape() in maptools to show what shapefile type is
being returned. The ones permitted in readShapePoly() are 1 (POINT), 8
(MULTIPOINT), 11 (POINTZ), 3 (ARC), 13 (ARCZ - 3rd dimension discarded), 5
(POLYGON), and 15 (POLYGONZ - 3rd dimension discarded). The readOGR()  
function using the current OGR shapefile driver appears to handle POLYGON
5, POLYGONM 25, and POLYGONZ 15, ARC 3, ARCM 23, and ARCZ 13, and
MULTIPATCH 31, as well as POINT 1, POINTM 21, POINTZ 11, and MULTIPOINT 8,
MULTIPOINTM 28, and MULTIPOINTZ 18.

The third dimensions are discarded from non-points.

The extra polygons for lakes and water bodies could be the problem, 
because there are no data for them, but it appears that the shape type is 
not among those supported. So the first question is what does 
getinfo.shape() say? Could the file (or a subset with the same problems) 
be made available (say on a website for a short time) for debugging? And 
how was the file created - were there options that could be turned off to 
make it simpler?

Hope this helps,

Roger

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Roger Bivand
    

    

      
      #
    

  


  

      
Debs:

Please diregard my previous message, the problem is that one of the 
columns in the DBF is of an unsupported type, so not the shapes, the 
problem is the data. readOGR() only supports Real, Integer, and String. 
orgInfo() on the file might help to show what is going on.

readShapePoly() uses read.dbf() from foreign, which is probably more 
robust. See if readShapePoly() works better fot the types of fields you 
have in your dbf file, or try:

library(foreign)
x <- read.dbf("parcels_scot.dbf", as.is = TRUE)

to see if it can read the file. If it can, readShapePoly() will work too. 
Are there for example any Date fields?

Roger

        
On Fri, 16 Feb 2007, Debarchana Ghosh wrote:

        

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    
2 days later

    

      
      

        
      

    

    

      
      

        
      

    

    

      
      

        


  

        

      Roger Bivand
    

    

      
      #
    

  


  

      
On Tue, 20 Feb 2007, Debarchana Ghosh wrote:

        

            

      
      
      
    

        
I don't think we can get to the cause of the warnings by remote debugging. 
Please try writeOGR() in rgdal instead, with the appropriate 
driver="ESRI Shapefile", probably:

writeOGR(scot, dsn=".", layer="scot", driver="ESRI Shapefile")

We may need to convert some data frame columns to other classes, but 
readOGR() is more restrictive than writeOGR().

If you'd like to get to the bottom of the warnings, please do save(scot, 
file="scot.RData", compress=TRUE) and put it on a temporary website. I 
can't see any obvious calls to max() that might not have suitable 
arguments, so it needs running under debug. 

Can readShapePoly() read the output shapefile?

Roger

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        
      

    

    

      
      

        


  

        

      Roger Bivand
    

    

      
      #
    

  


  

      
On Tue, 20 Feb 2007, Debarchana Ghosh wrote:

        

            

      
      
      
    

        
OK, thanks. The 21 warnings come from the fact that 21 of the DBF columns 
are just missing values (or are read by R as missing values). This is:

    max(nchar(x[!is.na(x)]))

in write.dbf(), in trying to work out the field width.

These include two of the three dates, only SALE_DATE has values, but they
likely ought to be checked, the highest value is long in the future. Many
of the others also have many missing values, but I suppose they are as
they should be.

            

      
      
      
    

        
character    factor   numeric 
        3        50        14

            

      
      
      
    

        
character    double   integer 
        3        14        50

            

      
      
      
    

        
now runs for me. So does:

            

      
      
      
    

        
There were 21 warnings (use warnings() to see them)

The writePolyShape() DBF was much smaller than the writeOGR() one, because 
writePolyShape uses write.dbf() to try to guess the width of fields, while 
writeOGR() - at the moment - just uses defaults. I read scot_1.shp into 
ArcMAP 9.1 successfully, I didn't try scot.shp because of the very large 
DBF - my Arc is on a laptop with 256M RAM. Your lagged values were 
present.

I hope you said save(scotnbs, "scotnbs.RData", compress=TRUE), to save 
repeating the generation of the neighbour lists. I feel that some of the 
lists will be rather strange, because I think your plots are separated by 
roads, etc., which will mean that many miss almost-contiguous neighbours 
across a road. However, that is how the data are.

Best wishes,

Roger