[R-sig-Geo] auto-calcuations for Spatial objects

[Michael Sumner]

Thanks Edzer, just a quick follow up.

>> I don't have any clearer thoughts than that, just wanted to put
>> it out there for discussion. It's mostly relevant to trip objects
>> that can be subsetted or updated in different ways as a sort of
>> hybrid between a "point" and "line segment" interpretation, but
>> could be useful for SpatialPolygons/Lines - especially when rgeos
>> brings more capability for manipulating these objects?
>
> Subsetting is another interesting issue. When you compute distance,
> direction, speed etc from a trip of four points, what would you return,
> or what would the returned object mean when one selects the second and
> fourth point?
>

This is OK, IMO - if subsetting returns a valid trip, then that trip
can have metrics as any other, as if the second and fourth point were
actually the first and second.  It so happens that the trip class only
allows a minimum of 3 records per "trip event", and reverts to
SpatialPointsDataFrame. There's no reason 2-point trips can't be
sensible, I just decided they were not.

>> Another problem is the "specialness" of metrics, whether they are
>> protected from the general attribute data as coordinates are. This is
>> not so bad as long as it's clear to the user that any edits on these
>> attributes are likely to be lost!  I've long thought that I should similarly
>> protect the Time and ID attributes for trips, perhaps treat time as a
>> coordinate
>> and ID as a simple index identifier. I've tried this but haven't
>> committed anything
>> or investigated how disruptive it would be to the existing methods.
>>
>> A minor question regards whether to take a "to next" or "from
>> previous" line segment model.
>>
>> So, in summary:
>>
>>  - detect projection metadata and calculate metrics if this is set
>>  - if CRS is NA, do no calculations
>
> this requires you to check this and throw errors in any downstream
> function/method that uses a trip object - not convenient.

Yes, I realized this later - that is a real problem. I think it's
pretty much the end of the idea, and means the job must be done by
active functions called by the user as required. It seems dangerous to
assume that auto-calculations won't be used in error somehow.

>>  - consider ellipsoid distance, spherical bearing/angle, speed in m/s
>>    and options for user control over defaults
>>  - add distPrev, aziPrev, trackAngle, speedPrev with appropriate
>>   missing start/end values
>>
>> Thoughts?
>
> Have you looked at ljtraj objects in package adehabitat? It seems to be
> under active development. Clément Calenge sent me this reference:
>
> Calenge et al. 2009. The concept of animals' trajectories from a data
> analysis perspective - Ecological Informatics, 4, 34-41.

I have, it's very interesting, I've been aware of adehabitat for many
years - though it has some different goals and constraints to those of
trip, and it's far more advanced in terms of analytical tools. I'm
hoping my own writings for trip are not made completely redundant by
that work!

Finally, learning sp taught me the importance of coercion functions in
R, which I've only just added for ltraj to trip (along with
SpatialLinesDataFrame, and ppp and psp). It's clearly most productive
to allow transfer of data between environments rather than trying to
capture every need in one.

Thanks!

Cheers, Mike.

> --
> Edzer Pebesma
> Institute for Geoinformatics (ifgi), University of Münster
> Weseler Straße 253, 48151 Münster, Germany. Phone: +49 251
> 8333081, Fax: +49 251 8339763  http://ifgi.uni-muenster.de
> http://www.52north.org/geostatistics      e.pebesma at wwu.de
>
> _______________________________________________
> R-sig-Geo mailing list
> R-sig-Geo at stat.math.ethz.ch
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>



-- 
Michael Sumner
Institute for Marine and Antarctic Studies, University of Tasmania
Hobart, Australia
e-mail: mdsumner at gmail.com