Messing up steps with step_metrics? about sftrack

[birderboone]

Correct, we have to order the data.frame to do these calculations which we then return the order to its original state afterwards, and it was using the newly created sftrack_id as an ordering vector, which would return the correct dataframe order for posix items but incorrect for integers. Its now just using the original burst and time columns instead.

Should be fixed now

[basille]

Side question: Is the computation the same for sftrack and sftraj objects? For the former, there is a need indeed to temporally order locations so steps can be computed (and possibly throw a warning about it). But for the later, all parameters should come directly from the step geometry itself, regardless of order and other considerations. The only caveat would be for turn angles, for which there needs to be a check that the current step's start point is the same as the previous step's end point.

[basille]

Forget my last comment, the doc explicitely says: "sftrack objects will be converted to sftraj internally for calculation". I still think that if there is some ordering happening, it should throw a warning (but no ordering should happen, at least by default, for sftraj objects).