

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


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


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?
>
>
Please go ahead and commit; that's the idea of you being a developer.
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


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

> 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


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.

