search

mablab / sftrack

sftrack: Modern classes for tracking and movement data
https://mablab.org/sftrack/
Other
53 stars 2 forks source link

Messing up steps with step_metrics? #27

Closed rociojoo closed 4 years ago

rociojoo commented 4 years ago

This is what I did: sim_sftrack <- as_sftrack( data = sim_tracks_df, coords = c("x","y"), time = "time", burst = "group_track" ) sim_metrics <- step_metrics(sim_sftrack)

then > head(sim_metrics) dx dy dist dt abs_angle speed sftrack_id 1 -4.552723 8.380473 2.0975096 9 2.068445 0.233056625 1-1_1 112 -8.925107 15.603843 0.7150057 18 2.090359 0.039722537 1-1_2 223 -16.392981 26.762819 0.8255781 27 2.120377 0.030576968 1-1_3 261 -20.730838 33.826227 0.0656693 36 2.120620 0.001824147 1-1_4 272 -28.143437 48.727325 0.3345839 45 2.094560 0.007435198 1-1_5 283 -31.249733 54.404988 0.3203247 54 2.092173 0.005931940 1-1_6

Matt has the dataset. I think that it is doing weird stuff, changing the order of rows unnecessarily, because the time variable/column is not in a posixct format as it is just a count. It's just a hunch. But I think that the function should account for a case like this one.

birderboone commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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).