Skip to content

First thoughts on spatio-temporal classes...

7 messages · Blair Christian, Virgilio Gomez Rubio, Edzer Pebesma +3 more

Original
Virgilio Gomez Rubio
# 
Hi Blair,

I am visiting SAMSI this fall and I would like to get involved in  
this. Is there any working group discussing this? If not, perhaps we  
could have a chat with all the people interested in the area (samsi,  
duke, unc, ncsu,...) and talk about this.

Best wishes,

Virgilio

Sent from my iPhone

On 18/09/2009, at 12:25, "Blair Christian" <blair.christian at gmail.com>  
wrote:
Michael Sumner
# 
Hi, I just want to let you know that I'm hoping to update the trip
(and tripEstimation) packages over the next few months so I'm very
open to suggestions if you are interested.

The main thing I want to do is to ensure that the capacity in sp for
use of 3 or more coordinates (X, Y, Z, T,...) is well supported, and
then simplify the implementation of trip on top of
SpatialPointsDataFrame. It would be nice to make it less of a special
case, and perhaps it would be best to apply it as a multipoint type
(as presented in the ASDAR book). That might be a good way to handle
collections (such as sets of individual trips).


Regards, Mike


On Sat, Sep 19, 2009 at 8:15 AM, VIRGILIO GOMEZ RUBIO
<Virgilio.Gomez at uclm.es> wrote:
Edzer Pebesma
#
Michael Sumner wrote:
Mike, I'm not sure if this would fit your needs. In the multipoint type,
I believe a collection of points corresponds to a single feature,
meaning that the set corresponds to a single record in the attribute
table. This means that if your sensor in addition to x,y,t records e.g.
temperature and pressure, there's no place for that.

Best wishes,
--
Edzer

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Barry Rowlingson
    

    

      
      #
    

  


  

      
On Sat, Sep 19, 2009 at 10:25 PM, Edzer Pebesma

        
<edzer.pebesma at uni-muenster.de> wrote:

        

            

      
      
      
    

        
I think you need a special class for a set of trips. It would inherit
from SpatialPointsDataFrame, so each observation is a point at (x,y)
with a T variable and its measurement(s) Z1, Z2, etc, and also a trip
identifier I. Then you could have another data frame object with
per-trip data - perhaps the name of the ship that did the surveys and
so on, or the start/end date of the trip (useful if your data only
records the three days whales were seen out of the 250 people were
looking for them). This data frame could be part of the same object.

 Then you'd have a method that created a SpatialLinesDataFrame object,
with one row per trip, on your trip set object. You'd use this for
plotting tracks, and it would get columns from the trip metadata table
so you could colour it by ship name or trip number. You might also
have some kind of tripApply function for computing per-trip
statistics, such as the total or mean measurements.

 Perhaps what you might want is a Spatial{Lines,Points}List data
structure? Each element having a Line geometry and a number of
measurements (the same number of measurements as points in the Line
geometry). This is a bit of a weird thing that I don't think exists in
the OGC Simple Features system since it's a bit "ragged" and so not a
straightforward thing for a RDBMS to support.

  When thinking about spatial data in R, I consider how it would be
done in PostGIS. I think you'd do as above - have a table of each
measurement with a linking identifier, and then on-the-fly compute
track geometry. It might even be possible to do it as a VIEW in
PostGIS, something like:

CREATE VIEW tracks as select area,MakeLine(the_geom) as the_geom from
(select * from observations order by time) as m group by trip

 - but that's a bit of a guess.... and it's late...

 I think you'd need a different structure if your locations are fixed
(such as fixed sampling stations) and your measurements are taken over
time...

Barry

  
  


  


      

    

    

      
      

        


  

        

      Michael Sumner
    

    

      
      #
    

  


  

      
That's true, mulitpoints require every attribute to be a coordinate,
and the lines aspect is a bit of a red herring. There is an unknown
geometry that underlies the points, and presenting them as if movement
was linear and constant between them is a lie. They really are point
samples from an otherwise unknown continuous process - the functions
in tripEstimation attempt to provide a more realistic representation
by constraining the movements to a region in space - I have some code
in there that handles a set of density estimations as if they were the
points in a trip, but it's not obvious to me how to usefully convert
that to sp objects.

I like Barry's idea of allowing conversion to lines, which could be
used only as an explicit step for visualization or analysis. Trip
currently plots a trip object as a set of lines, and that's probably
not the right thing to do. I think the general rule should be to make
trip as simple an extension as possible, and add helper functions for
conversions to more derived classes.

Thanks for the thoughts!

Regards, Mike.

On Sun, Sep 20, 2009 at 8:20 AM, Barry Rowlingson

        
<b.rowlingson at lancaster.ac.uk> wrote:

            

      
      
      
    

  
  


  


      

    

    
10 days later

    

      
      

        


  

        

      Mauricio Zambrano-Bigiarini
    

    

      
      #
    

  


  

      
Hi Blair,

I'm sorry but my late answer, but this is a complicated period for me ...

2009/9/18 Blair Christian <blair.christian at gmail.com>:

            

      
      
      
    

        
I want to analyse long-term daily/monthly/annual hydrological time
series of temperature and precipitation, measured in point gauging
stations.

            

      
      
      
    

        
I'm developing a package for management and interpolation of this type
of data, in which the temporal functions use the zoo package as
building block, and the spatial functions are mainly wrappers to the
krige function of the 'gstat' package and the autoKrige function of
the 'automap' package, aiming at easing this tasks to people with good
knowledge in hydrology and GIS, but little or no experience in R.

            

      
      
      
    

        
I'm interested in writing classes, but I have some experience with S3
classes and no experience with S4 classes, and I would appreciate if
you could share any material for reading about this.

            

      
      
      
    

        
The very basic idea that I have in mind for implementing the
spatio-temporal classes for regular time series located in point
objects is to add a slot of 'zoo' and/or 'xts' type to the
'SpatialPointsDataFrame' class, but I have no idea about how to do it.

            

      
      
      
    

        

      
      
    

        
So, if I can help in some way, you can count on me.

Kinds,

Mauricio Zambrano B.
--