[R-sig-Geo] Point pattern add covariates

[Michael Sumner]

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