Checking event quality
Upon finishing the movement event creation, actel checks the movement events to look out for strange behaviour. If something looks odd, you are given a chance to invalidate specific movement events, so that invalid detections can be discarded.
- Note:
- Rendering a movement event invalid does not make it disappear. However, subsequent steps in the analysis will know that the event should not be considered (hence the “Valid” column).
Impassables
As you probably know by now, you can define unidirectional connections between arrays. This tells actel that something (e.g. a weir or dam) prevents the animal from moving in a particular direction. Let’s see the examples below, with arrays A, B and C:
In example 1, animals can pass from A to C and C to A freely. However, they can only pass from B to C, as the way in the opposite direction (C to B) is blocked by a weir. If a tag has a detection in C and then in B, actel will assume the animal passed through A undetected.
On the other hand, in example 2, the way from C to A is also blocked by a weir. If a tag is detected in C and afterwards either in A or B, actel will complain, as there is no viable way for the respective animal to move between both arrays.
This is the respective warning:
Warning: Tag R64K-1234 made an impassable jump: It is not possible to go from array C to A.
Please resolve this either by invalidating events or by adjusting your 'spatial.txt' file and restarting.
Opening valid movement table for inspection:
[...]
Note: You can select event ranges by separating them with a ':' and/or multiple events at once by separating them with a space or a comma.
Events to be rendered invalid: As the warning says, you then have two options: Invalidate events until the impassable exception is resolved, or re-structure your spatial.txt file.
Jumping arrays
If the tag has been jumping around (i.e. passing through multiple arrays undetected), actel will issue warnings and prompt user intervention, depending on the values set for jump.warning and jump.error.
Let’s have a look at the examples below:
Assuming jump.warning = 2 and jump.error = 3, examples 1 and 2 would pass through the analysis without raising any flags (1 as a perfect situation and 2 showing an efficiency flaw in array C).
However, in example 3, the jump size is equal to jump.warning, but lower than jump.error. When this happens, actel will display a warning:
Warning: Tag R64K-1234 jumped through 2 arrays in events 1 -> 2 (A -> D).Then, actel would continue the analysis. This warning is issued whenever the jump size equals or is greater than jump.warning. Lastly, in example 4, the jump size is equal to the jump.error. When this happens, actel issues a warning like the one above, and on top of that allows the user to intervene:
Warning: Tag R64K-1234 jumped through 3 arrays in events 1 -> 2 (A -> E).
M: Opening movement table of tag R64K-2791 for inspection:
[...]
Would you like to render any movement event invalid, or expand an event?(y/n/comment)From here, you can inspect the movement table and find out if some events should be removed from the analysis.
Average speed
If you include a distance matrix in the analysis, you can specify the maximum expected speed for your animals using speed.warning and speed.error. Doing so will trigger the speed checks, where the average speed between each movement event is compared to the specified arguments.
If the average speed is higher than speed.warning, a warning is triggered:
Warning: Tag R64K-1234 had an average speed of 1.3 m/s from valid event 3 to 4 (Array1 -> Array2).If, on top of this, any of the average speeds is higher than speed.error, user interaction is suggested:
Warning: Tag R64K-1234 had an average speed of 1.3 m/s from valid event 5 to 6 (Array4 -> Array5).
M: Opening valid movements table of tag R64K-1234 for inspection:
[...]
Would you like to render any movement event invalid, or expand an event?(y/n/comment) From here you can then decide whether or not some movement events should be excluded.
Inactiveness
Specifying a value for inactive.warning and/or inactive.error will trigger the inactiveness checks. These differ depending on whether or not you included a distance matrix in the analysis.
Inactiveness checks are performed in the tail of the movement events. That is, actel grabs the events in the last array and analyses those. Let’s have a look at the example below, and assume inactive.warning and inactive.error were both set to 3 days.
| Array | Detections | First station | Last station | First time | Last time | Time travelling | Time on array |
|---|---|---|---|---|---|---|---|
| A | 4 | St.1 | St.2 | 2019-05-15 12:00:00 | 2019-05-15 13:00:00 | NA | 1:00:00 |
| B | 3 | St.3 | St.4 | 2019-05-16 13:50:00 | 2019-05-16 14:40:00 | 24:50:00 | 0:50:00 |
| C | 2 | St.5 | St.6 | 2019-05-17 16:00:00 | 2019-05-17 16:20:00 | 25:20:00 | 0:20:00 |
| C | 4 | St.6 | St.5 | 2019-05-17 17:10:00 | 2019-05-17 18:00:00 | 0:50:00 | 0:50:00 |
| C | 1 | St.5 | St.5 | 2019-05-20 19:45:00 | 2019-05-20 19:45:00 | 73:45:00 | 0:00:00 |
In this case, the last three events are valid candidates for inactiveness. Actel will then check the time difference between the first detection at event 3 and the last detection at event 5. Should this difference be larger than inactive.warning, actel will proceed to the next step, which depends on whether the distances.matrix is present.
If a distances matrix is present
Actel will gather all the stations where these last detections occurred and check if they are less than 1500 metres a part. If this is true, then there is a valid case for inactivity, and a warning will be issued:
Warning: Tag R64K-1234 was detected 7 times at stations less than 1.5 km apart in array 'C' (St.5, St.6), over 3.07 days and then disappeared. Could it be inactive?If a distances matrix is NOT present
Actel will count the number of individual stations in which the tag was detected. If there are three or less individual stations, there is a valid case for inactivity, and a similar warning will be issued:
Warning: Tag R64K-1234 was detected 7 times at three or less stations of array 'C' (St.5, St.6) over 3.07 days and then disappeared. Could it be inactive?Since inactive.error was also set to three, this situation would trigger the possibility for user interaction:
M: Opening valid movement table of tag R64K-1234 for inspection. Inactiveness started on event [#] (2019-05-17):
[...]
Would you like to render any movement event invalid, or expand an event?(y/n/comment) From here you could then decide if some events should be removed.
What if the tag reached the array, moved about a bit, and only then stopped moving?
If the tag was active in array C, then it is possible that the initial detections will be in receivers located further away than 1500 metres, or in more than three unique receivers. To search for this cases, actel iterates the process above, removing one event from the top at a time, for as long as the period of residency at the array is higher than inactive.warning.
This means that, even if there are detections at many stations at the first events under scrutiny, potential inactiveness can still be detected at the trailing events.
Leaving comments for later
If a tag is causing doubts, you can attach a comment to it at any time. Just reply “comment” to a question when the word “comment” shows up between brackets and the comment dialogue will be triggered:
Continue editing last valid events?(y/N/comment) comment
New comment on tag R64K-4456: Was this animal eaten?
M: Comment successfully stored, returning to the previous interaction.
Continue editing last valid events?(y/N/comment) You can then find all your comments in the html report! Additionally, when you run migration() or residency(), the comments are also stored in the status.df object.