On 09/29/2010 04:27 AM, Michael Sumner wrote: > Hello, > > I've been experimenting with additions to the trip class to > automatically calculate metrics such as distance, bearing and > turning angle. It's pretty simple since the only function that > needs to know about this is the constructor, and it updates > automatically for subsetting and so on. The problem is in > decisions regarding which methods to calculate. If the data is > longitude / latitude then ellipsoid measurements can be applied, and > if projected, apply Euclidean methods. But this is not so obvious for > bearings and angles, since those calculations do really need to > be spherical. If the projection metadata is not set it seems > wrong to assume one way or the other, but if it is set then we > can always transform to long/lat in order to be consistent. The > other issue is that these things could be unit-based, especially > important for speed (we naturally use metres/second in most map > projections and R's base time class, but kilometres and hours? > when working in long/lat). > > I'm tempted to enforce the need for projection metadata - without it > there are just too many ambiguities.
I would not hesitate to enforce them. It is regrettable that R has, afaik, no semantics for units of measurements. The alternative would be to issue a warning that coordinates are assumed to be in metric space (or whatever you assume). > 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? > 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. > - 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. -- 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.pebe...@wwu.de _______________________________________________ R-sig-Geo mailing list R-sig-Geo@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-geo
