[R-sig-Geo] First thoughts on spatio-temporal classes...

[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:
> On Sat, Sep 19, 2009 at 10:25 PM, Edzer Pebesma
> <edzer.pebesma at uni-muenster.de> 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.
>>
>
>  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
>