Is this another way to say that I've stumbled onto one of the borders between the set of tasks that R does well and the set of tasks I should use a GIS for? Or should I persevere with R on this?
Second question: if I want to just do this assembly myself, so to keep some control over placement, is there an add-a-Polygon-to-my-Polygons method, or do you have an example of something like that? Thanks for the help, -tom Roger Bivand <roger.biv...@nhh.no> wrote: > > This doesn't, though. When I read in my data, the IDvar is supposed to > > be the column that is unique for each record, correct? But there are > > several records (closed polygons) for each town. These are linked by > > another variable. The coordinates(rep.map) gives me a list of 419 > > coordinates for all the closed shapes, not 75 coordinates for all the > > towns. How do I get the biggest polygons for each town? I have an Area > > attribute, so I guess I can just calculate it. Is that the right way to > > go, or is there some method already existing for this? > > > > I thought maybe my readSpatial... was done wrong, so I changed the IDvar > > to point to the iD for each town, but that gives me an error saying that > > duplicate row names are not allowed. Is there a step I needed to take > > to link the polygons? > > Yes, see the unionSpatialPolygons() function in maptools. It uses > functions in gpclib to dissolve boundaries between member entities if > they touch, so makes a Polygons object with possibly multiple member > Polygon objects from multiple Polygons objects with the same ID values > (towns for you). You then need to drop rows from the data.frame > (as(rep.map, "data.frame")), and re-assemble using > SpatialPolygonsDataFrame() with the row.names of the data.frame set to > the town IDs used in unionSpatialPolygons(). > > The mess is caused by the underlying data being kept in OGC SFS > (simple features) form, which does not store well in shapefiles (a > similar remark could be made about SpatialPolygons objects, which are > more like shapefiles than like SFS). > > The gpclib package should not be used if its license conditions are > inappropriate. A free software alternative is being prepared. > > Roger > > > > > Thank you, > > > > -tom > > > > > > -- > 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.biv...@nhh.no > -- -------------------------------------------------------- Check out "Ten Things You Don't Know About Rhode Island" http://whatcheer.net http://sgouros.com _______________________________________________ R-sig-Geo mailing list R-sig-Geo@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-geo