Point pattern add covariates

[Jose Funes]

Dear list,
I have point pattern data and would like to attach/add covariates as raster
(image or grid) to it. For example as the case of the bei data with
bei.extra with covariates.
Thanks,
Jose Funes
IFPRI

        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

[Barry Rowlingson]

On Mon, Jul 23, 2012 at 2:26 PM, Jose Funes <[hidden email]> wrote:
> Dear list,
> I have point pattern data and would like to attach/add covariates as raster
> (image or grid) to it. For example as the case of the bei data with
> bei.extra with covariates.

 You want to get the values of a raster at a set of points?

 Try extract(points,raster) from the raster package. [or it might be
extract(raster,points)].

 'points' is a SpatialPoints object (or SPDataFrame) and 'raster' is a
raster or stack object from the raster package.

Barry

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

[Rolf Turner]

On 24/07/12 01:26, Jose Funes wrote:
> Dear list,
> I have point pattern data and would like to attach/add covariates as raster
> (image or grid) to it. For example as the case of the bei data with
> bei.extra with covariates.

I'm afraid I don't understand what it is that you need to do.
What do you mean by "attach/add"?  In the example of the
"bei" data that you refer to, the images (covariates) "elev"
and "grad" are components of the list "bei.extra" which is
a separate object from the point pattern "bei".  The object
"bei.extra" is not "attached" to the object "bei" in any way.

Barry Rowlingson suggested that you might want to find the
values of a covariate associated with each point of a point
pattern.   The easiest way to do this is to use the (undocumented)
function "lookup.im()".

E.g.:

     em <- with(bei.extra,lookup.im(elev,bei$x,bei$y))
     gm <- with(bei.extra,lookup.im(grad,bei$x,bei$y))

Then you could "attach" these values to the point pattern as
*marks*:

     marks(bei) <- data.frame(elev=em,grad=gm)

Is this (anything like) what you want to do?

     cheers,

         Rolf Turner

P. S.  Adrian:  Do you think we should make "lookup.im()" into a
*documented*
function?  I have found myself recommending its use to inquirers on more
than
one occasion.

         R.

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

[Jose Funes]

Dear Rolf,
Barry suggestion addressed my question and the function lookup.img as well.
Thanks
Jose

On Mon, Jul 23, 2012 at 5:29 PM, Rolf Turner <[hidden email]>wrote:

> On 24/07/12 01:26, Jose Funes wrote:
>
>> Dear list,
>> I have point pattern data and would like to attach/add covariates as
>> raster
>> (image or grid) to it. For example as the case of the bei data with
>> bei.extra with covariates.
>>
>
> I'm afraid I don't understand what it is that you need to do.
> What do you mean by "attach/add"?  In the example of the
> "bei" data that you refer to, the images (covariates) "elev"
> and "grad" are components of the list "bei.extra" which is
> a separate object from the point pattern "bei".  The object
> "bei.extra" is not "attached" to the object "bei" in any way.
>
> Barry Rowlingson suggested that you might want to find the
> values of a covariate associated with each point of a point
> pattern.   The easiest way to do this is to use the (undocumented)
> function "lookup.im()".
>
> E.g.:
>
>     em <- with(bei.extra,lookup.im(elev,**bei$x,bei$y))
>     gm <- with(bei.extra,lookup.im(grad,**bei$x,bei$y))
>
> Then you could "attach" these values to the point pattern as
> *marks*:
>
>     marks(bei) <- data.frame(elev=em,grad=gm)
>
> Is this (anything like) what you want to do?
>
>     cheers,
>
>         Rolf Turner
>
> P. S.  Adrian:  Do you think we should make "lookup.im()" into a
> *documented*
> function?  I have found myself recommending its use to inquirers on more
> than
> one occasion.
>
>         R.
>

        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

[Adrian.Baddeley]

To read the pixel values of an image at the points of a point pattern (in spatstat), use
           "[.im"

If Z is your image and X is a point pattern, then Z[X] is a vector containing the pixel values of Z at the locations of X.

To attach these values to the point pattern, type
    marks(X) <- Z[X]

for example
     with(bei.extra, elev[bei])

This will deal safely with exceptional cases, avoids using undocumented functions that might change, and is also neater to write and read.

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!

Adrian

Prof Adrian Baddeley FAA
CSIRO Mathematics, Informatics & Statistics
Leeuwin Centre, 65 Brockway Road, Floreat WA 6014, Australia
Tel: [phone] | Fax: [phone] | Skype: adrian.baddeley

________________________________
From: Jose Funes [mailto:[hidden email]]
Sent: Tuesday, 24 July 2012 9:13 AM
To: Rolf Turner
Cc: [hidden email]; Baddeley, Adrian (CMIS, Floreat)
Subject: Re: [R-sig-Geo] Point pattern add covariates

Dear Rolf,
Barry suggestion addressed my question and the function lookup.img as well.
Thanks
Jose

On Mon, Jul 23, 2012 at 5:29 PM, Rolf Turner <[hidden email]<mailto:[hidden email]>> wrote:
On 24/07/12 01:26, Jose Funes wrote:
Dear list,
I have point pattern data and would like to attach/add covariates as raster
(image or grid) to it. For example as the case of the bei data with
bei.extra with covariates.

I'm afraid I don't understand what it is that you need to do.
What do you mean by "attach/add"?  In the example of the
"bei" data that you refer to, the images (covariates) "elev"
and "grad" are components of the list "bei.extra" which is
a separate object from the point pattern "bei".  The object
"bei.extra" is not "attached" to the object "bei" in any way.

Barry Rowlingson suggested that you might want to find the
values of a covariate associated with each point of a point
pattern.   The easiest way to do this is to use the (undocumented)
function "lookup.im<http://lookup.im>()".

E.g.:

    em <- with(bei.extra,lookup.im<http://lookup.im>(elev,bei$x,bei$y))
    gm <- with(bei.extra,lookup.im<http://lookup.im>(grad,bei$x,bei$y))

Then you could "attach" these values to the point pattern as
*marks*:

    marks(bei) <- data.frame(elev=em,grad=gm)

Is this (anything like) what you want to do?

    cheers,

        Rolf Turner

P. S.  Adrian:  Do you think we should make "lookup.im<http://lookup.im>()" into a *documented*
function?  I have found myself recommending its use to inquirers on more than
one occasion.

        R.


        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

[Barry Rowlingson]

On Tue, Jul 24, 2012 at 3:53 AM, [hidden email]
<[hidden email]> 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!'

Barry

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

[Edzer Pebesma-2]

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

> On Tue, Jul 24, 2012 at 3:53 AM, [hidden email]
> <[hidden email]> 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: [phone]  http://ifgi.uni-muenster.de
http://www.52north.org/geostatistics      [hidden email]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

[Michael Sumner-2]

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
<[hidden email]> wrote:

>
>
> On 07/24/2012 09:00 AM, Barry Rowlingson wrote:
>> On Tue, Jul 24, 2012 at 3:53 AM, [hidden email]
>> <[hidden email]> 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: [phone]  http://ifgi.uni-muenster.de
> http://www.52north.org/geostatistics      [hidden email]
>
> _______________________________________________
> R-sig-Geo mailing list
> [hidden email]
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo

--
Michael Sumner
Hobart, Australia
e-mail: [hidden email]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo