Point pattern add covariates
Note that there are some conversions already in maptools, at least for as(ppp, "SpatialPoints") and as(psp, "SpatialLines") - I use some of this in the trip package to convert to psp (a trip is implicitly a set of lines with marks). I'm also interested in conversions from/to adehabitat* classes and I'd like to see a good summary of what is already available and what is missing so we can identify where things have a clean translation and where they need more thought. I'll try to come back with more detail. Cheers, Mike. On Wed, Jul 25, 2012 at 2:43 AM, Edzer Pebesma
<edzer.pebesma at uni-muenster.de> wrote:
On 07/24/2012 09:00 AM, Barry Rowlingson wrote:
On Tue, Jul 24, 2012 at 3:53 AM, Adrian.Baddeley at csiro.au <Adrian.Baddeley at csiro.au> wrote:
I don't know why Barry Rowlingson is giving you advice about spatstat - he recently said no-one should be using spatstat anyway - maybe it's all part of a disinformation campaign!
??!??!! The original post didn't mention spatstat and neither did I! And I don't recall saying flat out that no-one should use spatstat. Everyone doing spatial point pattern analysis should be using spatstat, and *not* using splancs - I don't think there's anything (useful) that splancs does that spatstat doesn't do. If there is, then I suggest sometime we sort out a google summer of code project sometime to kill off splancs and graft anything useful into spatstat (hmmm didnt we try that ten years ago? :)) However I don't like the duplication of spatial data handling and manipulation between packages such as spatstat and sp. We have some very nice raster and vector data types now, and if spatstat could use them (natively without coercion) it would save a lot of unneccessary duplication. In one of the packages I'm involved in it seems that we're constantly converting from sp to ppp and back again in order to get some functionality from a package that only handles one! So I might have said 'Don't do X in spatstat', but I certainly didn't say 'Don't do K, F, or G in spatstat'. I more likely said 'Don't do K in splancs - do it in spatstat!'
I can only recall (but can't trace back) that Barry mentioned recently that the spatstat objects do not handle coordinate reference systems. The objects in sp are not tailored in particular for point pattern analysis (and neither for geostatistics) -- SpatialPoints objects for instance do not hold an observation window, which would be indispensible to compute a point density. The classes in sp do contain, I believe, the building blocks needed for spatstat objects, and one could easily subclass SpatialPoints for a SpatialPointsPattern (containing an observation window), and a SpatialPointsDataFrame to form a marked point pattern with observation window. By doing this, seemingly trivial mistakes could be caught, e.g. false matching of points, windows, or marks by ignoring coordinate reference systems, or doing Euclidian distances from long/lat coordinates. Seeing this as a benefit of course assumes that (the spatstat) code developers *want* to catch such errors. It would be good to also hear some response from spatstat users whether a tighter integration between spatstat and sp would be appreciated, or not. -- Edzer Pebesma Institute for Geoinformatics (ifgi), University of M?nster Weseler Stra?e 253, 48151 M?nster, Germany. Phone: +49 251 8333081, Fax: +49 251 8339763 http://ifgi.uni-muenster.de http://www.52north.org/geostatistics e.pebesma at wwu.de
_______________________________________________ R-sig-Geo mailing list R-sig-Geo at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Michael Sumner Hobart, Australia e-mail: mdsumner at gmail.com