Skip to content

Point pattern add covariates

3 messages · Barry Rowlingson, Edzer Pebesma, Michael Sumner

Original
Barry Rowlingson
# 
On Tue, Jul 24, 2012 at 3:53 AM, Adrian.Baddeley at csiro.au
<Adrian.Baddeley at csiro.au> wrote:

            

      
      
      
    

        
??!??!!

 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!'

Barry

  
  


  


    

    

      
      

        


  

        

      Edzer Pebesma
    

    

      
      #
    

  


  

      
On 07/24/2012 09:00 AM, Barry Rowlingson wrote:

            

      
      
      
    

        
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.

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      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: