First thoughts on spatio-temporal classes...
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