Hi Barry, Roger, rsiggeo gang,
I just checked in updates to SpatialCls on http://sourceforge.net/projects/rspatial/  I completed documentation, added tests and examples. The whole package should pass R CMD check. Even the S4 classes are now documented, slots and all. No vignettes yet, still have to get into them. The interfaces used so far are: # The following three promote a data.frame to a SpatialDataFrame coordinates(meuse) = ~x+y # or coordinates(meuse) = c("x", "y") # or coordinates(meuse) = cbind(x,y) # after which coordinates(meuse) # retrieves coordinates; also: coordinates(meuse.grid) = ~x+y # followed by gridded(meuse.grid) = TRUE # promotes meuse.grid to a SpatialDataFrameGrid, which has # (and autodetects) grid topology; it has an image method. # then, polygons(x) = list(pol1, pol2, pol3) # promotes data.frame x to a SpatialPolygons, adding the # polygon information to it, doing some basic checks # (e.g. pol1..3 should be 2column matrix with at least 4 points, # first and last being the same); polygons(x) # retrieves the polygon list data.frame(x) # retrieves the attribute values data.frame # some elementary plot, show, formula and summary methods are present. What else do we need, when it comes to interfaces/methods? Enjoy the weekend,  Edzer 
Administrator

Dear Edzer,
Happy New Year! I'm just muddling, but would it be OK to try to put my proj4R CRS class in SpatialCls for proj4string? This may mean setting proj4string as NA until the CRS has been set, and as.projected as NULL until proj4string is identified as latlong or !latlong? How should we handle this with regard to commiting to sourceforge, is this a situation where I need to do this locally, and send you a tarball to avoid introducing changes you'd prefer not to have? A little question  does coordinates() preserve sdf row names as a way of keeping point IDs stuck to both objects? I'm a bit worried about holes too in the polygon setting, the original compiled code in maptools for finding ring direction seems buggy, and ring direction seems to be a typical way of flagging holes as against boundaries for fill. Best wishes, Roger On Fri, 28 Nov 2003, Edzer J. Pebesma wrote: > Hi Barry, Roger, rsiggeo gang, > > I just checked in updates to SpatialCls on > http://sourceforge.net/projects/rspatial/  > I completed documentation, added tests and examples. The > whole package should pass R CMD check. Even the S4 classes > are now documented, slots and all. No vignettes yet, > still have to get into them. > > The interfaces used so far are: > > # The following three promote a data.frame to a SpatialDataFrame > > coordinates(meuse) = ~x+y # or > coordinates(meuse) = c("x", "y") # or > coordinates(meuse) = cbind(x,y) > > # after which > > coordinates(meuse) > > # retrieves coordinates; also: > > coordinates(meuse.grid) = ~x+y # followed by > gridded(meuse.grid) = TRUE > > # promotes meuse.grid to a SpatialDataFrameGrid, which has > # (and autodetects) grid topology; it has an image method. > > # then, > > polygons(x) = list(pol1, pol2, pol3) > > # promotes data.frame x to a SpatialPolygons, adding the > # polygon information to it, doing some basic checks > # (e.g. pol1..3 should be 2column matrix with at least 4 points, > # first and last being the same); > > polygons(x) # retrieves the polygon list > data.frame(x) # retrieves the attribute values data.frame > > # some elementary plot, show, formula and summary methods are present. > > What else do we need, when it comes to interfaces/methods? > > Enjoy the weekend, >  > Edzer > >  Roger Bivand Economic Geography Section, Department of Economics, Norwegian School of Economics and Business Administration, Breiviksveien 40, N5045 Bergen, Norway. voice: +47 55 95 93 55; fax +47 55 95 93 93 email: Roger.Bivand at nhh.no
Roger Bivand
Department of Economics Norwegian School of Economics Helleveien 30 N5045 Bergen, Norway 
> I'm a bit worried about holes too in the polygon setting, the original > compiled code in maptools for finding ring direction seems buggy, and ring > direction seems to be a typical way of flagging holes as against > boundaries for fill. Typical it may be, but I think its the wrong way of doing things! This sort of complex geometry would be better represented as a tree of rings. Each ring may have child rings that represent islands or holes within the parent (depending on whether the parent is a hole or an island). In this way both the island/hole nature is preserved as well as the way each is embedded in the other. I think you can reconstruct this tree from the rings+holeflag form, but it involves doing pointinpoly tests using generated points guaranteed to be in a given ring. The tree structure leads to nice simple calculation of various properties of the rings. Consider a lake with islands with perhaps lakes  the area of water of the outer lake is the area(lake ring) minus area(child rings), whereas the amount of water within the outer lake is area(lake ring) minus amount of water within(child rings), a neat treebased algorithm. Given that the tree can be reconstructed from the ring+holeflag representation, I'd settle for that if a method for constructing the tree is made available. Of course in an objectoriented sense, the users shouldn't see the representation  there shouldn't be a method for 'area' that returns a negative number if the thing is a hole  there should be an 'isHole(x,y)' method or similar... Anyone notice a typo in a recent Rnews posting that referred to 'objection orientation' :) Baz 
> I'm a bit worried about holes too in the polygon setting, the original > compiled code in maptools for finding ring direction seems buggy, and ring > direction seems to be a typical way of flagging holes as against > boundaries for fill. If filling is the main concern, then it may not matter (which direction inner polygons are recorded). If, in this script, p < c( 1,1, 8,1, 8,8, 1,8, 1,1, 2,2, 7,2, 7,7, 2,7, 2,2, 1,1, 3,3, 6,3, 6,6, 3,6, 3,3, 1,1, 4,4, 5,4, 5,5, 4,5, 4,4, 1,1, NA,NA) p < matrix (p, nrow=2, ncol=length(p)/2) plot (p[1,], p[2,], type="n", axes=FALSE, xlab="", ylab="") polygon (p[1,], p[2,], col=1) the directions of the successive inner polygons are reversed, the graphic result is the same. The fill algorithm evidently uses the parity feature (fill on, fill off, while crossing successive boundaries in the direction of shading). The diagonal line showing from (2,2) to (3,3) is another matter. I wrote Paul Murrell about this a couple of years ago and he referred me to Ross Ihaka who, Paul said, was working on new polygon routines. For topological applications, the tree structure suggested by Barry Rowlingson seems like an elegant method. Denis 
In reply to this post by Barry Rowlingson
Hi Roger,
I thought I fixed the polygon direction code, but I may not have worked it in to the version I passed over to you. Sorry. I rember that the original code that came with the shapelib library in the contrib section did not work properly, and gave screwy results. I remember replacing it with an algorithm from O'Rourke (Comp Geom in C) that worked much better. Let me look in my backups (I think that was 3 computers and 2 jobs ago) and compare with the current maptools. If I didn't work it in I will send you the code. I think Barry's idea is great and not hard to implement. Essentially he is suggesting to store the polygons ' parts in a redblack tree. You can refrence the polygon parts by id's and just suck them right out of the array when plotting. Nicholas > > Today's Topics: > > 1. Re: Re: Holes (White.Denis at epamail.epa.gov) > > >  > > Message: 1 > Date: Mon, 12 Jan 2004 13:38:27 0800 > From: White.Denis at epamail.epa.gov > Subject: Re: [RsigGeo] Re: Holes > To: Roger.Bivand at nhh.no > Cc: rsiggeo at stat.math.ethz.ch > MessageID: > <OFA14AD050.0A53A95DON88256E19.0075ADAD88256E19.0076D9DC at epamail.epa.gov> > > ContentType: text/plain; charset=USASCII > > > > > > > I'm a bit worried about holes too in the polygon setting, the original > > compiled code in maptools for finding ring direction seems buggy, and > ring > > direction seems to be a typical way of flagging holes as against > > boundaries for fill. > > If filling is the main concern, then it may not matter (which direction > inner polygons are recorded). If, in this script, > > p < c( > 1,1, > 8,1, > 8,8, > 1,8, > 1,1, > 2,2, > 7,2, > 7,7, > 2,7, > 2,2, > 1,1, > 3,3, > 6,3, > 6,6, > 3,6, > 3,3, > 1,1, > 4,4, > 5,4, > 5,5, > 4,5, > 4,4, > 1,1, > NA,NA) > p < matrix (p, nrow=2, ncol=length(p)/2) > plot (p[1,], p[2,], type="n", axes=FALSE, xlab="", ylab="") > polygon (p[1,], p[2,], col=1) > > the directions of the successive inner polygons are reversed, the > graphic result is the same. The fill algorithm evidently uses the > parity feature (fill on, fill off, while crossing successive boundaries > in the direction of shading). The diagonal line showing from (2,2) to > (3,3) is another matter. I wrote Paul Murrell about this a couple of > years ago and he referred me to Ross Ihaka who, Paul said, was working > on new polygon routines. > > For topological applications, the tree structure suggested by Barry > Rowlingson seems like an elegant method. > > Denis > > > >  > > _______________________________________________ > RsigGeo mailing list > RsigGeo at stat.math.ethz.ch > https://www.stat.math.ethz.ch/mailman/listinfo/rsiggeo > > > End of RsigGeo Digest, Vol 5, Issue 2 > *************************************** 
In reply to this post by Roger Bivand
Roger Bivand wrote:
>Dear Edzer, > >Happy New Year! > >I'm just muddling, but would it be OK to try to put my proj4R CRS class in >SpatialCls for proj4string? This may mean setting proj4string as NA until >the CRS has been set, and as.projected as NULL until proj4string is >identified as latlong or !latlong? How should we handle this with regard >to commiting to sourceforge, is this a situation where I need to do this >locally, and send you a tarball to avoid introducing changes you'd prefer >not to have? > > The idea of using cvs is that you can go back to previous versions. >A little question  does coordinates() preserve sdf row names as a way of >keeping point IDs stuck to both objects? > Yes; it returns a data frame with only the (2 or 3) coordinate columns selected.  Edzer 
In reply to this post by Roger Bivand
Hello, Professor Bivand.
Currently I summaries GWR using Fotheringham et al. 's GWR book(Wiley). Although current spgwr has no support of adaptive spatial kernel, I'd like to add this kernel in it. But for me it's not enough to implement this only reading page 46's footnote in this books Could you give any hint for implementing adaptive spatial kernel to me? Regards. 
Hi, Mr. Hisaji Ono and all:
I think Fortheringham and collegues are using the crossvalidation to obtain an optimal number of nearest neighbor to replace the optimal bandwidth. This way, every data point will have the same number of observations participating the locally weighted regression. I cannot actually implement the code in R myself, but I would like to list my understanding of using the crossvalidation procedure to obtain the optimal number of nearest neighbors. If I am wrong in any aspect, please correct me: 1. Choose the weighting scheme (bisqure, or similar ones like tricube); 2. Set the minimum number of nearest neighbor as the number of explanatory variables plus 2, and the maximum number as the number of observations (I guess for large number of observations, this may be very computational intensive); 3. Loop through the minimum to the maximum, and obtain a CV score for each number of nearest neighbor; 4. The smallest CV yields the optimal number of nearest neighbor. I hope this will help. On Thu, 15 Jan 2004, Hisaji Ono wrote: > Hello, Professor Bivand. > > Currently I summaries GWR using Fotheringham et al. 's GWR book(Wiley). > > Although current spgwr has no support of adaptive spatial kernel, I'd like > to add this kernel in it. > > But for me it's not enough to implement this only reading page 46's footnote > in this books > > Could you give any hint for implementing adaptive spatial kernel to me? > > Regards. > > _______________________________________________ > RsigGeo mailing list > RsigGeo at stat.math.ethz.ch > https://www.stat.math.ethz.ch/mailman/listinfo/rsiggeo > Sincerely, Danlin Yu, Ph.D. Candidate Department of Geography University of Wisconsin, Milwaukee Tel: (414)2295818 Fax: (414)2293981 Email: danlinyu at uwm.edu 
Administrator

In reply to this post by hi_ono2001
> Hello, Professor Bivand.
> > Currently I summaries GWR using Fotheringham et al. 's GWR > book(Wiley). > > Although current spgwr has no support of adaptive spatial kernel, I'd > like to add this kernel in it. > > But for me it's not enough to implement this only reading page 46's > footnote in this books > When Chris Brunsdon and I were in Lucca last September, some coding was done, although it isn't yet ready for release. Some more work needs to be done, also to introduce geographically weighted statistical summary measures. The code does include the knearest neighbours adaptive kernel used in GWR in some cases. If others would like to join in, I could start a sourceforge project if you like. Roger > Could you give any hint for implementing adaptive spatial kernel to > me? > > Regards.  Roger Bivand NHH, Breiviksveien 40, N5045 Bergen, Norway
Roger Bivand
Department of Economics Norwegian School of Economics Helleveien 30 N5045 Bergen, Norway 
In reply to this post by Danlin Yu2
Thank you very much, Mr. Yu.
> > I think Fortheringham and collegues are using the crossvalidation to > obtain an optimal number of nearest neighbor to replace the optimal > bandwidth. This way, every data point will have the same number of > observations participating the locally weighted regression. > I cannot actually implement the code in R myself, but I would like to > list my understanding of using the crossvalidation procedure to obtain > the optimal number of nearest neighbors. If I am wrong in any aspect, > please correct me: > 1. Choose the weighting scheme (bisqure, or similar ones like > tricube); > 2. Set the minimum number of nearest neighbor as the number of > explanatory variables plus 2, and the maximum number as the number of > observations (I guess for large number of observations, this may be very > computational intensive); > 3. Loop through the minimum to the maximum, and obtain a CV score for > each number of nearest neighbor; > 4. The smallest CV yields the optimal number of nearest neighbor. > > I hope this will help. It's very helpful. 
Free forum by Nabble  Edit this page 