➡ Jump to: Movement ecology & tracking terms
A · B · C · D · E · F · G · H · I · J · K · L · M · N · O · P · Q · R · S · T · U · V · W · X · Y · Z
API: Short for Application Programming Interface. On MoveApps, each output artifact of a Workflow Instance can be retrieved via a stable, password-protected HTTPS API link, so data can be embedded in a website or fetched programmatically without going through the web UI. Combine the API with a scheduled Workflow and you have live plots, maps, or CSVs on your own webpage that refresh automatically after each scheduled run. Links are managed per Workflow Instance via the API Access button at the top of the Output window.
App: An analytical module that produces at least one conclusive result, for example an App that downloads tracking data from Movebank, or that plots the data on a map, or that calculates space use. Apps are written by volunteer developers in R, R-Shiny, or Python. Apps are chained together to create a Workflow; each App exposes configurable Settings that can be adjusted by the user. Each App declares its input and output IO types, which define the Workflow connectivity.
App Browser: The catalogue of every available App (App Browser) — searchable by title, description, or keywords. Apps can be filtered by App Category or developer. By clicking on an App, a window with more details will open. Deprecated Apps are hidden by default and revealed via the slider at the foot of the page.
App Category: A label assigned to each App to group them by topic and make the search easier in the App Browser. Categories are grouped into Classes, e.g. Location Data, Integration, Helper. New Categories can be requested by the App developer when an App fits none of the existing ones.
App Container: In a Workflow, the display of the App is called the App container. The App container provides access to the App Menu, the Cargo Agent, and the Output.
App Details: The App menu item (and pop-up) that lists every piece of metadata about an App — its description, runtime environment, IO types, version, author and email, suggested citation, GitHub repository, and any warning note from the developer. It can be accessed from the App Browser, or from the App Menu inside a Workflow (the three vertical dots on the top right corner of the App container).
App logs (log.txt): The text log every App writes during a Workflow run, accessible via Show Logs in the App menu (or, when an App errors, via the app logs link inside Error details). For interactive Shiny Apps the log file only becomes available in the outputs after the App goes idle (about 8 hours), but a per-run log overview is always reachable from Show Logs in the App Menu. Always check the log when an App fails or produces unexpected results; it is also useful when filing a GitHub issue against the App.
App Menu: The three vertical dots on the top right corner of each App container in a Workflow. This menu gives access to Settings, App Details, Pin to this App, Show logs, and Delete.
App UI (Open App UI): The interactive web interface of an R-Shiny App, opened via the Open App UI button on the App container after the App has run. Inside the UI a user examines results and can change parameters; choices made there can be persisted via Stored Settings for future runs, e.g. for scheduled Workflows. The UI stays available for 8 hours after the run. To make the UI available again, pin to the previous App and run the Workflow again.
App version (Tag / Release): A specific build of an App, tied to a GitHub Tag/Release the developer publishes. When you add an App to your Workflow it locks to whichever version was current at that moment; later, a warning icon on the App container indicates a newer version is available and you can pick it up via Update App in the App Menu or by clicking on the warning triangle. Public Workflows keep the App versions they had at the moment of sharing, for reproducibility.
Artifact: Any file an App produces during a Workflow run — for example a .pdf report, a .csv table, or a .zip file. All Artifacts can be downloaded from each App container directly or via the Output button. Artifacts can also be accessed via the API.
Attribute: Tracking data always contains associated information; these columns in the data are also known as attributes. Attributes can be associated with each location, referred to as 'event attributes' in the Cargo Agent (for example 'battery_voltage'), or with the tracks, referred to as 'track attributes' in the Cargo Agent (for example 'sex').
Auxiliary file: A file that a user can upload to an App. Some Apps have fallback or default files; in other Apps the upload is mandatory, in others optional. Most Apps currently do not need any auxiliary file to be uploaded.
Cargo Agent: Accessed via the green 'i' icon at the top right corner of any App container in a Workflow after the App has produced results. It contains a summary of the App's output data. Here you will also find the list of attributes associated with the data.
Dashboard: The page you land on after logging in to MoveApps. From the Dashboard you create and manage your Workflows, initialise new Apps, and access Public Workflows.
Deprecated App: An App whose author has marked it as no longer maintained — typically because it was replaced or can no longer be supported. Deprecation is permanent: a deprecated App cannot be added to new Workflows and cannot be reactivated, but it continues to run inside Workflows that already contain it. Public Workflows containing at least one deprecated App are flagged as "deprecated" in the catalogue but remain runnable for reproducibility.
DOI: Short for Digital Object Identifier. A MoveApps Workflow can be assigned a DOI via the "Archive with DOI" submission in the Workflow menu. The DOI makes the Workflow citable and permanently reproducible. A Workflow can only receive a DOI if it is associated with a paper; the DOI will be provided upon acceptance of the manuscript. The data used in an archived Workflow should be archived in the Movebank Data Repository or be publicly available on Movebank; if neither is possible, the authors need to add an instance to the Workflow that contains public data so that anyone can run the Workflow.
Error details: The diagnostic panel that opens when an App in a Workflow fails, reached by clicking Error details on the failed App container. It shows the error message and includes links to the App's App logs, the App's GitHub issues page, and a pre-filled email to MoveApps support. The error message is often enough to identify the problem (e.g. an invalid setting); when not, the App logs are the next thing to check. If these are not readable, please send the message to MoveApps support.
IO type: Short for input/output type. Every App declares one input IO type and one output IO type, fixed to its runtime environment (R, R-Shiny, or Python). Apps can only be chained in a Workflow when the upstream output type matches the downstream input type. To connect Apps with different IO types, Translator Apps are often available.
Notification of Completion: An email sent to the user when a Workflow run finishes, activated via the green "Notification" icon next to the Start button in the Workflow. The email contains links to the Workflow Instance and its outputs. This option is very useful when Workflows take a long time to run.
Output: The Output button next to a Workflow Instance opens a window listing every file (artifact) generated by every App in the run, downloadable individually or as a .zip (or bundled .pdf). The app-output.rds (R) or app-output.pickle (Python) file contains the output data of an App, which is used as input for the next App.
Pin: A Workflow control that freezes the output of one App and every App preceding it, so re-running the Workflow only re-executes the Apps after the pin. Pinning a Shiny App closes its UI but retains its data. Important for scheduled runs: pins block re-downloading of live data, so unpin before scheduling.
Public Workflow: A Workflow shared by a user with all MoveApps users. These Workflows serve as a starting point or inspiration for your own analysis. Public Workflows can be added to 'Your Workflows' via the '+ADD' button, and run without modifying anything, adjusting the settings for your own purposes, and/or adding more Apps to it. When making a Public Workflow, the data are not shared, only the settings of the Apps that access the data. Only if the user has access to that specific data set can they run the exact same Workflow. Therefore please ensure that at least one instance contains public data that can be accessed by anyone, and please make it clear in the description of the instance which is the one containing public data. A Public Workflow containing at least one deprecated App keeps the deprecated flag, but remains runnable for reproducibility.
Rerun: The Workflow control to re-start a Workflow after its first run — distinct from Start Workflow (which begins the first run) and from Stop Workflow (which halts a running Workflow). Any Pin you have set is honoured during the re-run: Apps up to and including the pinned App are skipped and their stored outputs are re-used, so only the Apps after the pin are actually re-executed.
Schedule Instance / Scheduled Run: An automated re-run of a Workflow Instance at a fixed daily, weekly, or monthly cadence, set up via Schedule Instance next to the Output button. To prevent forgotten Workflows running indefinitely, each scheduled Instance is allowed up to 30 (daily) or 12 (weekly/monthly) runs before the user has to renew the quota; a pinned App blocks live data downloads in scheduled runs.
SDK: (For App developers.) Software Development Kit — code shipped inside the MoveApps App templates that emulates the platform locally, so an App's RFunction.R, ShinyModule.R, or Python entry-point can be run on the developer's machine before submission.
Settings: The user-configurable parameters of an App — accessed from each App's Settings menu in the Workflow view, or, for Shiny Apps, inside the App UI itself. App developers declare which settings an App exposes; the user fills them in when configuring the App for a particular run. Shiny Apps can persist their UI parameters across runs via Stored Settings.
Shared Workflow: A Workflow shared via the Share menu with named users by nickname. Recipients receive a local copy they can edit independently. When sharing a Workflow, the data are not shared, only the settings of the Apps that access the data. Only if the user has access to that specific data set can they run the exact same Workflow.
Stored Settings: Click Store settings inside an R-Shiny App UI to remember your current parameter choices across future Workflow runs. The stored values appear as an item named "Stored Settings" in the App's outputs.
Translator: A category of helper App that converts data from one IO type to another, so that Apps with otherwise mismatched input and output types can still be combined in the same Workflow. Not all IO types can be translated into one another. In the near future this will happen automatically and the user will not have to worry about it.
Workflow: An ordered chain of Apps configured to ingest, process, and analyse movement data. Every Workflow begins with a data source App (e.g. Movebank Location, Upload File from Local System), and every subsequent App must accept the upstream App's output IO type — or be preceded by a Translator.
Workflow Category: A user-defined grouping label for Workflows in the dashboard's Your Workflows overview. Imported Workflows that the user has not yet recategorised land under reserved labels: Imported Public Shared Workflows or Imported Directly Shared Workflows.
Workflow Instance: A single named configuration of a Workflow — the same App sequence and order, but with its own settings values. Multiple instances let users compare parameter sets without rebuilding the Workflow; changes to the App selection or order propagate to all instances of that Workflow.
A · B · C · D · E · F · G · H · I · J · K · L · M · N · O · P · Q · R · S · T · U · V · W · X · Y · Z
Accelerometer: An on-tag sensor that records acceleration along three axes, either in high-frequency short bursts or continuously. The resulting data are not positions but a time series of g-forces, used to classify behaviour, calculate ODBA/VEDBA or to drive activity-based fix scheduling on the tag.
aKDE (Autocorrelated kernel density estimation): A UD estimator that extends KDE by accounting for the autocorrelation in tracking data. It produces a range distribution (long-term space requirements) and, unlike classical KDE, returns estimates whose areas remain comparable between individuals sampled at different frequencies.
ARGOS: A satellite tracking system originally meaning Advanced Research and Global Observation, relying on NOAA and EUMETSAT polar-orbiting weather satellites. Two flavours of ARGOS-compatible tag exist: passive GPS tags that use ARGOS only for relay, and active satellite tags that determine position from Doppler shift in the emitted signal — lower-accuracy than GPS but smaller and lower-power. Movebank provides ARGOS data filtering tools.
Autocorrelation: The statistical dependence between consecutive positions of a trajectory — successive locations are not independent because the animal cannot teleport. Most classical space-use and habitat-selection estimators assume independent observations; ignoring autocorrelation biases sample-size, bandwidth selection, and confidence intervals. Diagnose with a semi-variogram; account for it via continuous-time models (see ctmm) or aKDE.
Azimuth (also called bearing or direction of travel): The compass direction from one position to the next, measured in degrees clockwise from north (0°); e.g. an azimuth of 90° means the animal moved due east. It is the absolute direction of a segment, independent of any previous segment — contrast with the turning angle, which is the change in direction between two consecutive segments. Distinct from heading (body-axis orientation, which may differ under crosswind).
Bandwidth (h): The smoothing parameter of a kernel density estimator — the width of the kernel placed on each position. Too small a bandwidth produces a spiky surface that hugs the data; too large oversmooths it and inflates the estimated UD. Common automatic selectors include the Gaussian reference function (href) and least-squares cross-validation (LSCV); the latter often performs poorly with large or autocorrelated samples.
BCPA (Behavioural change point analysis): A parametric segmentation method that uses a sliding window and likelihood estimates to detect when a metric of the trajectory — usually persistence velocity — changes regime. The window size trades off detection of short-term shifts against false positives; penalisation typically follows the Bayesian Information Criterion.
Bearing: Synonym for azimuth — the compass direction from one position to the next, measured clockwise from north. The term is particularly common in radio tracking, where directional bearings from receiving stations are intersected by triangulation to fix the tag's location.
Bounding box: The smallest axis-aligned rectangle enclosing every position in a trajectory — the minimum and maximum X and Y coordinates of the data.
Continuous-time movement model (ctmm): A class of stochastic-process models that treat an animal's location as a continuous function of time rather than a sequence of discrete steps, so the model is no longer tied to the sampling schedule. Fitting a ctmm yields parameters such as a position autocorrelation timescale and (where applicable) a velocity autocorrelation timescale, which then feed into autocorrelation-aware estimators like aKDE and continuous-time speed/distance estimation.
Coordinate reference system (CRS) / projection: The mathematical framework that ties X/Y coordinates to a location on Earth. Geographic coordinate systems (e.g. EPSG:4326) use longitude and latitude on an unprojected sphere; projected systems (global or region-specific) flatten the sphere to preserve some of distance, angle, or area at the cost of the others. All Movebank uploads to MoveApps arrive in the geographic coordinate system EPSG:4326. Search for projections here: https://epsg.io
Correlated random walk (CRW): A statistical model of animal movement in which each step is drawn from distributions of step length and turning angle, with consecutive turning angles correlated — i.e. animals tend to keep going in roughly the same direction rather than turn at random. CRWs are the baseline against which many movement analyses compare observed data, including NSD interpretation, SSF random-step generation, and the two-state HMM for "travelling" behaviour.
Dead reckoning: A path-reconstruction technique that pieces together fine-scale movement between GPS fixes using on-board accelerometer, magnetometer, and (optionally) gyroscope data — heading from the magnetometer plus speed inferred from the accelerometer, integrated step by step. The reconstructed path drifts over time and is periodically anchored against absolute GPS positions to correct accumulated error.
Deployment: The act of attaching a tag to a specific individual for a specific period — and hence the unit of metadata that ties a tag's data records to one animal. One individual can have multiple deployments if e.g. the tag has been replaced or the animal has been recaptured and tagged multiple times over its life span.
Direction of travel: Synonym for azimuth — the absolute compass direction along a segment of a trajectory. Distinct from heading, the orientation of the animal's body axis, which under crosswind or current may differ from the direction it is actually moving in.
Dynamic Brownian Bridge Movement Model (dBBMM): An occurrence distribution estimator that incorporates the temporal sequence of locations — modelling the movement between consecutive positions as a conditional Brownian motion bridge. The "dynamic" extension allows the motion variance to change along the trajectory, capturing shifts between, say, directed travel and local foraging. Estimated areas shrink as sampling becomes denser, so cross-individual comparison requires caution.
Environmental annotation: The process of associating each location in a trajectory with the value of an environmental variable (elevation, temperature, land cover, NDVI, etc.) at that point in space and time.
First passage time (FPT): The time an animal takes to cross a circle of given radius along its trajectory. Sweeping the radius reveals the spatial scales at which behaviour changes — a maximum in the variance of log-FPT marks the scale of area-restricted search.
Geolocators: Light-level loggers that infer position from the timing of sunrise and sunset (day length plus solar noon). Accuracy is on the order of hundreds of kilometres but tags weigh under one gram and can record for over a year, making them indispensable for tracking small migratory species. Geolocators are passive: data must be retrieved by recapturing the animal.
GPS: The Global Positioning System — a passive receiver that determines its own location from the timing of signals from a constellation of orbiting satellites. State-of-the-art tags can sample at >1 Hz with metre-level accuracy; many tags use Kalman filters internally to improve precision and can also estimate instantaneous speed and heading from Doppler shift. Battery weight is the principal constraint on tag size.
Gyroscope: An on-tag sensor that records angular velocity around three axes (pitch, roll, yaw). Combined with an accelerometer and a magnetometer inside an IMU, gyroscope data resolve fine-scale orientation changes and are used in dead reckoning to reconstruct movement paths between GPS fixes.
Heading: The direction the animal's body axis is pointing. In the flight and swim literature it is distinguished from the direction of travel (the azimuth of the segment actually traversed): under crosswind or current the animal must point its body partly into the flow, so heading and direction of travel diverge. Standalone GPS data only resolve direction of travel; recovering heading requires a body-mounted magnetometer and (typically) an IMU. Some GPS devices record a "heading" value (present as a event attribute in the dataset), this value is an instantaneos recording of the body position when the gps location was recorded.
Hidden Markov Model (HMM): A statistical model widely used for segmentation of tracking data into discrete behavioural states (e.g. "encamped" vs "travelling") that are not directly observed in the data. The model is fit to step lengths and turning angles; each state has its own step-length and turning-angle distributions, and the most likely state sequence is decoded (typically via the Viterbi algorithm). Covariates such as day-of-year or habitat can be added to drive the transition probabilities.
Home range: The area an individual uses to maintain its energetic and behavioural needs — Burt's 1943 definition explicitly excludes migration corridors and dispersal. The term has no precise operational definition; in practice it is reported as a contour (commonly 95%) of a utilisation distribution, with the inner 50% often called the core area. Common estimators include MCP, KDE, dBBMM, and aKDE; they differ in their assumptions and in whether they estimate a range distribution ("how much space does the animal need?") or an occurrence distribution ("where was the animal during this tracking period?"). The precise terms range distribution and occurrence distribution are preferred over the less concise term home range.
IMU (Inertial Measurement Unit): A composite sensor package that bundles a tri-axial accelerometer, a tri-axial magnetometer, and (often) a tri-axial gyroscope, resolving motion along surge/sway/heave and rotation in pitch/roll/yaw. IMUs underpin behaviour classification, posture recovery, and dead-reckoning reconstruction of fine-scale paths.
Interpolation: Filling gaps in a trajectory by inserting estimated positions where the tag did not record. The simplest method distributes missing points evenly along the straight line between the two known endpoints; more sophisticated methods condition on the animal's movement statistics or on environmental context. Interpolation imposes assumptions on segments of unknown true shape and inflates apparent autocorrelation. It is mostly used for visualisations, mainly animations; doing this for analysis has to be done carefully, as interpolation effectively "makes up data".
Kernel density estimation (KDE): A UD estimator that produces a continuous probability surface — the utilisation distribution — by placing a small two-dimensional kernel (typically Gaussian) on each position and summing them. The crucial choice is the bandwidth, which controls how tightly the surface hugs the data. Classical KDE assumes the locations are statistically independent, which is incorrect for high-frequency tracking data (consecutive positions are autocorrelated); aKDE addresses this.
LoCoH (Local Convex Hulls): A family of UD estimators built by drawing a small convex hull around each location plus its nearest neighbours (chosen by fixed count k, fixed radius r, or fixed cumulative distance a), then merging and ranking the hulls by density. The result resolves sharp boundaries (coastlines, fences) better than KDE and is robust to outliers, but neighbour-count choice strongly affects the outcome.
Magnetometer: An on-tag sensor that records the Earth's magnetic-field vector along three axes (in Gauss). Inside an IMU, the magnetometer fixes heading relative to magnetic north, complementing the accelerometer which only resolves orientation relative to gravity; together they enable behaviour classification and dead reckoning. Tri-axial magnetometers require soft-iron and hard-iron calibration to remove tag-specific distortions.
Minimum convex polygon (MCP): The simplest and oldest estimator of an animal's range: the smallest convex polygon (a shape with no inward dents) that encloses all — or a specified percentage of — an animal's positions. A 95% MCP (the hull around the 95% of points closest to the centroid) is conventionally reported, to mitigate the effect of outliers. Limitations: every location has equal weight regardless of how long the animal stayed there, and the hull often includes large unused areas.
Movebank: A publicly accessible online database for animal-tracking data, hosted at movebank.org. It standardises tracking data, supports filtering, visualisation, and sharing, and serves as the primary data source for MoveApps via the Movebank Location and Movebank Non-Location data source Apps.
Net square displacement (NSD): The squared distance from each location to a reference point (preferably the nest, colony, den or other meaningful location, but often the start of the trajectory is used) plotted over time. Originally introduced for comparison against correlated random-walk models, NSD is a useful global summary of dispersal and migration phases; like most trajectory metrics, it is strongly scale-dependent on sampling frequency.
Occurrence distribution: A type of utilisation distribution that interpolates between observed positions in the past — it answers "where did the animal go during the period of observation?". Estimated areas (occurrence regions) shrink as sampling becomes denser and therefore should not be compared across individuals tracked at different frequencies and durations. Typical estimators are the dBBMM and the ctmm-based ocurrence. Contrast with the range distribution.
Outlier: A recorded position that does not represent the animal's true location — typically caused by a poor GPS fix, triangulation error, ARGOS Doppler-shift artefact, or signal-reception drop-out. Outliers can be spotted visually on a map, by implausibly high speeds between successive positions, or by statistical tests; on MoveApps several helper Apps are dedicated to outlier filtering. Removing or correcting them is usually one of the first analysis steps.
Position: A single recorded coordinate of an animal at a given timestamp. Synonyms in the literature include location, relocation, and GPS fix.
Radio tracking: The earliest tracking technology: the animal carries an active VHF transmitter that emits a signal received by directional antennae. Position is determined either by triangulation from two or more stationary receiving stations, or by homing in — approaching the signal until the animal is sighted. Transmitters can weigh as little as 200 mg (e.g. for bumblebees), keeping radio tracking the method of choice for the smallest study species.
Range distribution: A type of utilisation distribution that extrapolates space use into the future — it answers "how much space does the animal need over its life time?". The estimated area considers all realisations of the underlying movement process that could occur, so it is well suited to comparing UD areas across individuals or to deciding whether protected areas are sufficiently large. Typical estimators include KDE and aKDE. Contrast with the occurrence distribution.
Recursion (revisitation): Repeated return of an animal to the same place. Operationally measured by counting how many times the trajectory re-enters a circle of fixed radius around each position, together with the residence time per visit; the resulting maps highlight foraging sites, roosts, or watering holes.
Resource selection function (RSF): A class of model that estimates the probability of an animal occurring at a location as a function of environmental conditions there. Classical RSFs fit a logistic regression of used locations against random available locations sampled within the assumed accessible area (e.g. the UD or MCP). The model's coefficients give the relative probability of selection per covariate.
Segment: The line connecting two successive positions. Used to characterise attributes of the connection itself, such as its duration (a time lag), the distance or speed between the two positions.
Segmentation: Subsetting a trajectory into shorter, coherent sections — for example splitting a migration trajectory into "foraging", "migrating", and "resting" portions. Segmentation can be based on behavioural annotation, environmental boundaries (e.g. land vs. sea), or unsupervised algorithms.
Semi-variogram: A diagnostic plot of semi-variance in position as a function of time lag between locations, used to identify the autocorrelation structure of movement data. A flat variogram means no autocorrelation; a linear rise without plateau indicates Brownian motion (no finite range); a rise to a plateau (the sill) indicates resident range behaviour, with the time at the plateau giving the autocorrelation timescale (also called the range).
Sensor: An on-tag instrument that records a particular type of measurement — for example a GPS receiver, an accelerometer, a magnetometer, or a heart-rate sensor. A single tag can carry multiple sensors.
Speed: The step length divided by the time lag between two consecutive positions — usually reported in m/s or km/h. Despite its apparent simplicity, speed is strongly scale-dependent on the sampling frequency: at longer time lags the actual path between fixes is shortened to a straight line, so the same animal will appear "slower" at coarser sampling.
Step length: The straight-line distance between two consecutive positions — the spatial length of a segment. Step lengths and turning angles are the two primitive statistics that summarise local movement and underpin most fine-scale models such as Step Selection Functions, correlated random walks, and Hidden Markov Models. Like all movement metrics, step length is strongly sensitive to the time lag between fixes.
Step selection function (SSF): A model of habitat selection that compares each observed step (the move from one location to the next) against alternative steps the animal could have taken from the same starting position. Availability is therefore constrained by realistic step lengths and turning angles, making SSFs capture fine-scale movement decisions that an RSF cannot. The integrated SSF (iSSF) jointly estimates habitat selection and movement parameters.
Study: A Movebank-organised dataset corresponding to one investigation: one or more deployments of tags on one or more individuals, gathered under shared metadata (species, principal investigator, license, etc.). The unit imported into MoveApps by the Movebank Location and Movebank Non-Location data source Apps.
Tag: The hardware device carried by the animal that records or transmits position and other sensor data — a GPS collar, a VHF radio transmitter, an ARGOS satellite tag, a light-level geolocator, and so on. The tag is the hardware deployed in a deployment; for the GitHub-Tag / MoveApps platform meaning of "Tag", see App version (Tag / Release).
Thinning: Sub-sampling a trajectory so that consecutive positions are further apart in time — typically to obtain a regular sampling schedule or to reduce autocorrelation before applying methods that assume independent locations. Thinning discards data, however, and the resulting estimates are sensitive to the chosen interval.
Time lag: The time difference between two consecutive positions; equivalently, the temporal length of a segment. Irregular time lags complicate many trajectory analyses (e.g. speed and turning-angle estimation), which is why regularising or modelling the sampling schedule is a recurring concern.
Timestamp: The date-and-time recorded at each position. On MoveApps, all uploaded tracking data are stored in UTC and Apps must return outputs in UTC.
Track ID: The identifier that links each event to the track it belongs to, most often equivalent to individual name or deployment), but it could also be that tracks are e.g. split for each individual per season.
Trajectory: The full sequence of positions recorded from one tagged individual. Also called a track or path.
Triangulation: In radio tracking, computing an animal's position by intersecting two or more directional bearings taken from stations of known location. Accuracy depends on the geometry between stations and tag (intersect angles approaching 0° or 180° degrade precision) and on landscape effects on signal propagation.
Turning angle: The change in direction between two successive segments — 0° means continuing straight, +90° a right turn, −90° a left turn. Distinct from azimuth (the absolute compass direction of a single segment) and from heading (the direction the animal's body axis points). Computed in move2 via mt_turnangle().
Utilisation distribution (UD): A probability density describing how an animal's use of space is distributed across an area — at each location it gives the probability of finding the animal there. The UD underlies the modern, statistical concept of home range: the conventional reporting picks a probability contour (most often the 95% volume) to delimit a "range", with the inner 50% commonly called the core area. UDs come in two flavours that answer different questions: a range distribution extrapolates long-term space requirements ("how much space does the animal need?"), an occurrence distribution interpolates between observed positions ("where was the animal during this tracking period?").