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 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? 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 - 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? Cheers, Mike -- Michael Sumner Institute for Marine and Antarctic Studies, University of Tasmania Hobart, Australia e-mail: mdsum...@gmail.com _______________________________________________ R-sig-Geo mailing list R-sig-Geo@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-geo