Acoustic sensor enabled tracking of blue sharks
By Jon Pye
OTN Project Page https://members.oceantrack.org/project?ccode=NSBS
OTN IPT dataset: https://members.oceantrack.org/ipt/resource?r=otndalnsbluesharktracking
- Fred Whoriskey - Principal Investigator ([email protected])
- Brendal Townsend - Point of Contact ([email protected])
Project abstract: In the Northwest Atlantic, the Ocean Tracking Network (OTN), in collaboration with Dalhousie University, is using an acoustic telemetry infrastructure to monitor the habitat use, movements, and survival of juvenile blue sharks (Prionace glauca). This infrastructure includes state-of-the-art acoustic receivers and oceanographic monitoring equipment, and autonomous marine vehicles carrying oceanographic sensors and mobile acoustic receivers. Long-life acoustic tags (n=40) implanted in the experimental animals will provide long-term spatial resolution of shark movements and distribution, trans-boundary migrations, site fidelity, and the species’ response to a changing ocean. This study will facilitate interspecific comparisons, documentation of intra- and interspecific interactions, and permit long-term monitoring of this understudied predator in the Northwest Atlantic. The study will also provide basic and necessary information to better inform fisheries managers and policy makers. This is pertinent given the recent formulation of the Canadian Plan of Action for Shark Conservation.
Data Sources:
Tagging Events: Individual animals are implanted with coded acoustic pingers that can be individually identified by acoustic receivers according to the pattern of their transmission.
Receiver Deployments: Acoustic receivers are deployed at stationary locations to detect the presence of these tags, and information including their location, instrument model and serial number, and names for the station at which they are deployed are recorded.
Detection Occurrences: Data on the observed pinger codes can subsequently be recovered from these receivers.
This dataset covers a large range both spatially and between other receiver projects and are equipped with sensor-enabled tags. This example will apply well to any acoustic tracking project with sensor tags, or projects that are detected across many different receiver deployments.
Tagged animals released for future detection should have an Occurrence record representing each capture. In Event Core archives, the location and time information will be part of the Event record and the Occurrence record will link to that tagging Event. Below are some guidelines for how to populate each field of this capture Occurrence (and possibly Event).
| Term | Usage |
|---|---|
| basisOfRecord | HumanObservation - a human observed the animal in this position |
| occurrenceID | URN-style notation with datacenter, a short code for project identification within the datacenter or institution, and a dataset-wide unique identifier for the animal (often organismName). Can append the term release for the first release, and increment on subsequent re-releases of the individual E.g.: otn:OTN.NSBS:NSBS:Brandy-release
|
| organismID | a unique animal identifier within that domain E.g.:NSBS:Brandy
|
| eventDate | The date and time the animal was captured. Format is ISO 8601 w/ timezone clearly represented. |
| decimalLatitude & decimalLongitude | Location the animal was captured. |
| geodeticDatum | What coordinate reference system to use when locating the occurrence using the decimalLatitude and decimalLongitude. Prefer EPSG:4326 |
| scientificName | Required |
| scientificNameID | URN denoting the authority from which the species identification is derived, and an identifier for that species. e.g.: urn:lsid:marinespecies.org:taxname:105801 for Blue Shark |
| samplingProtocol | Link, preferably a DOI, of a description of the capture and tagging methods used for equipping the animal with tracking information. E.g. White Sharks (US) , White Sharks(AU) |
| kingdom | Kingdom to which this species belongs. Can be important for disambiguation in some cases. |
| taxonRank | The accuracy to which this taxon has been identified. Ideally species
|
| coordinateUncertaintyInMeters | Share, if known, how accurately your capture location was measured. |
The release of the animal would be classified as an Event. Guidance on completing the fields for this 'release' Event:
| Term | Usage |
|---|---|
| eventID | URN-style notation with sufficient identifiers to create a unique value representing the release event, in the form: [datacenter]:[project shortcode]:[datacenter-specific-ID] At OTN, the datacenter-specific ID is a combination of the animal's identifier, project affiliation, and the date of release. e.g. otn:OTN.NSBS:NSBS-Hops:20170722053000-release All contributing datacenters must ensure that the [project shortcode][datacenter-specific-ID] is unique to their datacenter, then subsequent combination with the [datacenter] component of this field will guarantee a globally unique eventID. Re-captures and re-releases can be distinguished and guaranteed unique using the date component, though this field should not be used as the source of date information. Any other indicator may be included for distinguishing different releases of a single animal. |
| occurrenceID | Defined by the capture event, Relates this record to the prior capture event of this animal |
| eventDate | ISO 8601 date representing the time of release. |
| decimalLatitude & decimalLongitude | Location of the release |
| geodeticDatum | Recommend EPSG:4326 |
| locationID | Term describing the location of release. If all animals in this project were released in one location, 'Release' could be sufficient. |
| footprintWKT | Share if available |
| modified | Date the record was last modified |
**NB: the release Event record does not represent a distinct Occurrence record from the capture event. Holding periods, movement of the animal while captured, and other confounding circumstances preclude this record from being considered a natural occurrence of the animal. See: Béguer-Pon et al. ...
Receiver or other listening station deployments should be categorized as Events, with the following guidelines
| Term | Usage |
|---|---|
| eventID | URN-style notation with sufficient identifiers to create a unique value representing the deployment event, in the form: [datacenter]:[project shortcode]:[datacenter-specific-ID] At OTN, the datacenter-specific ID is a combination of station name, instrument model and serial number, and consecutive deployment number. e.g. otn:OTN.CBS:CBS-271-VR2W-128545-4 All contributing datacenters must ensure that the [institution][project shortcode][datacenter-specific-ID] is unique to their datacenter, then subsequent combination with the [datacenter] component of the ID will guarantee a globally unique eventID. |
| eventDate | Date range expressed in ISO 8601 format, representing the period when the receiver was on location and able to register detections. e.g.: 2013-07-29T05:34:17Z/2017-06-16T16:21:00Z. For still-active receivers, a single date indicating the beginning of the receiver deployment. (FUTURE: when ISO 8601 accepts open-ended date ranges, consider [start-date]/.. as per their recommendation.) |
| decimalLatitude & decimalLongitude | Location of receiver deployment. |
| geodeticDatum | What coordinate reference system to use when locating the deployment event using the decimalLatitude and decimalLongitude. Prefer EPSG:4326 |
| locationID | The project-specific location of this receiver or group of receivers. Often analogous to stationID. |
| maximumDepthInMeters & minimumDepthInMeters | Depth range of the instrument deployed. May be the same value for fixed deployments |
| footprintWKT | The WKT for this location / path. e.g. POINT(-60.19669 47.33837) |
| modified | ISO 8601 datetime representing the date and time when this deployment record was last modified in the source database. |
| ... |
| Term | Usage |
|---|---|
| measurementDeterminedBy | The name (or other identifier such as ORCID) of the person making the measurement. Often the 'tagger' in OTN metadata sheet parlance. |
| measurementDeterminedDate | ISO 8601 datetime for the measurement. Fallback to the tagging event if no specific recorded measurement time. |
| measurementRemarks | Tagging remarks may be appropriate here. |
| measurementType | Fairly free field, corresponding to the measurementTypeID field. Eg: weight, length (various types: Fork, Total, Carapace), lifestage, sex, etc. |
| measurementTypeID | BODC NERC vocabulary code URI for the measurement type. See P01 (https://www.bodc.ac.uk/resources/vocabularies/vocabulary_search/P01/) for guidance. Eg: weight (http://vocab.nerc.ac.uk/collection/P01/current/SPWGXX01/) and standard length (http://vocab.nerc.ac.uk/collection/P01/current/SL01XX01/) |
| measurementUnit | The unit of measurement, as specified in measurementUnitID |
| measurementUnitID | BODC NERC vocabulary code URI for the measurement unit. See P06 () for guidance. Eg: m = ttp://vocab.nerc.ac.uk/collection/P06/current/ULAA/ and kg = http://vocab.nerc.ac.uk/collection/P06/current/KGXX/ |
| measurementValue | The value of the measurement |
| occurrenceID | The occurrenceID for the capture event that led to the measurement. |
This is a paradigm that is common in acoustic telemetry. The sensor will not likely be recovered, so a snapshot of the measurement is transmitted to the stationary acoustic receiver and located by that receiver's position. Oxygen, temperature, salinity, pressure sensors are all commonly used in this paradigm. Other sensors, optical, accelerometry, etc, that are recorded on the attachment and recovered after deployment or transmitted via satellite, might not use this paradigm to record the measurement events.
| Term | Usage |
|---|---|
| eventID | The deployment event for the receiver that 'saw' the measurement. |
| measurementDeterminedDate | ISO 8601 datetime for the measurement. Fallback to the tagging event if no specific recorded measurement time. |
| measurementType | Measurement type corresponding to the measurementTypeID. Eg. temperature, depth |
| measurementTypeID | BODC NERC vocabulary code URI for the measurement type. See P01 for guidance. |
| measurementUnit | The unit of measurement, as specified in measurementUnitID |
| measurementUnitID | BODC NERC vocabulary code URI for the measurement unit. See P06 for guidance. |
| measurementValue | The value of the measurement |
| occurrenceID | The machine observation of the animal at the receiver that allowed for this measurement |
In acoustic telemetry, detection data is often retrieved and added to the archive well after the tagging and receiver deployment events have occurred. So it is not improbable to have a DwC archive with only release information for some time before augmenting it periodically with new detection data that has been contributed by various researchers to the Network data system.
Acoustic telemetry studies using PPM to communicate individual tag codes, when operated in dynamic environments or environments having many active tags at the same time, are susceptible to producing false detections (see Simpfendorfer et al 2015 for an explanation of the issue). In order to provide an appropriate volume of Occurrences and Events to the OBIS data system, we first seek to filter out false detections, and then create hourly detection summary entries in the Occurrence dataset. One popular algorithm used to filter false detections in acoustic telemetry is known as the Pincock filter, where multiple detections of the same tag code within a specified time frame is used as confirmation of a true detection of that tag code.
OTN builds archives from the global database of animal detections, and so must use an algorithm like the Pincock filter to remove as many likely false detections as possible. OTN uses the Pincock filter as it is implemented in the Python module resonATe to remove single detections from any receiver in the data system, and then summarizes the remaining detections into Occurrence entries as follows.
The time of first detection at each receiver per hour is recorded as the eventDate, the organismID is set to the unique identifier for the organism in the OTN database, and the individualCount is set to 1. This approach is modeled after the example used for creating occurrence records from satellite detections in the movePub package here and creates entries in the DwC field dataGeneralizations that reads 'subsampled by hour: first of # record(s)' for each occurrence.
In this way, individual animal movement patterns captured in acoustic telemetry studies can be represented in OBIS, while ensuring hundreds of records are not created for highly resident species that remain near listening equipment for long periods of time.
| Term | Usage |
|---|---|
| eventDate | Date of the first detection at a receiver location of this individual. |
| decimalLatitude & decimalLongitude | Location of the detecting receiver's deployment. |
| geodeticDatum | What coordinate reference system to use when locating the deployment event using the decimalLatitude and decimalLongitude. Prefer EPSG:4326 |
| coordinateUncertaintyInMeters | set to 1000 representing a rough estimate of maximum range of acoustic detections, not instrument-specific. Can be expanded in cases where contributors do not provide fully-accurate locations for their instrument deployments (e.g. networks that round their lat/lon to 2 decimal places before publication will have a larger coordinateUncertainty for their contributed detections) |
| Term | Usage |
|---|---|
| basisOfRecord | MachineObservation - as the individual was detected by a listening station decoding its tagged ping |
| occurrenceID | A unique identifier for this detection 'bucket', compiled by OTN using the authority and contributing project, the listening station that recorded the occurrence, and the organismID and time-bin for this summary. E.g.: otn:OTN.CBS:CBS-180-VR4-250528-2_NSBS-Daisy_2019-08-04T6
|
| organismID | a unique animal identifier within that domain. OTN includes the project code in order to ensure this uniqueness between projects. Default value when no researcher-supplied organismID exists is to use the tag's unique ID and the date of attachment to build a unique entry. E.g.:NSBS-Daisy, V16-123443_2020-05-05T15:10:00
|
| dataGeneralizations | How the data were summarized, in this example subsampled by hour: first of # record(s)
|
| scientificName | Required |
| scientificNameID | URN denoting the authority from which the species identification is derived, and an identifier for that species. e.g.: urn:lsid:marinespecies.org:taxname:105801 for Blue Shark |
| samplingProtocol | Link, preferably a DOI, of a description of the capture and tagging methods used for equipping the animal with tracking information. E.g. White Sharks (US) , White Sharks(AU) |
| kingdom | Kingdom to which this species belongs. Can be important for disambiguation in some cases. |
| taxonRank | The accuracy to which this taxon has been identified. Ideally species
|
| coordinateUncertaintyInMeters | Share, if known, how accurately your capture location was measured. |
Note that we do not include measurements, including lifestage and sex, in the occurrence records for machine observations. Measurements are not valid except at the time of the occurrence at which they were measured.
| Term | Usage |
|---|---|
| basisOfRecord | MachineObservation - as the individual was detected by a listening station decoding its tagged ping |
| occurrenceID | A unique identifier for this detection 'bucket', compiled by OTN using the authority and contributing project, the listening station that recorded the occurrence, and the organismID and time-bin for this summary. E.g.: otn:OTN.CBS:CBS-180-VR4-250528-2_NSBS-Daisy_2019-08-04T6
|
| organismID | a unique animal identifier within that domain. OTN includes the project code in order to ensure this uniqueness between projects. Default value when no researcher-supplied organismID exists is to use the tag's unique ID and the date of attachment to build a unique entry. E.g.:NSBS-Daisy, V16-123443_2020-05-05T15:10:00
|
| eventDate | Date of the first detection at a receiver location of this individual. |
| decimalLatitude & decimalLongitude | Location of the detecting receiver's deployment. |
| geodeticDatum | What coordinate reference system to use when locating the deployment event using the decimalLatitude and decimalLongitude. Prefer EPSG:4326 |
| dataGeneralizations | How the data were summarized, in this example subsampled by hour: first of # record(s)
|
| coordinateUncertaintyInMeters | In this example, set to 1000 representing a rough estimate of maximum range of acoustic detections, not instrument-specific. Can be expanded in cases where contributors do not provide fully-accurate locations for their instrument deployments (e.g. networks that round their lat/lon to 2 decimal places before publication will have a larger coordinateUncertainty for their contributed detections), or contracted (where range testing has placed the detection range for a given tag and power level to a shorter range) by information provided by the researcher or array operator. |
| scientificName | Required |
| scientificNameID | URN denoting the authority from which the species identification is derived, and an identifier for that species. e.g.: urn:lsid:marinespecies.org:taxname:105801 for Blue Shark |
| samplingProtocol | Link, preferably a DOI, of a description of the capture and tagging methods used for equipping the animal with tracking information. E.g. White Sharks (US) , White Sharks(AU) |
| kingdom | Kingdom to which this species belongs. Can be important for disambiguation in some cases. |
| taxonRank | The accuracy to which this taxon has been identified. Ideally species
|
Note that we do not include measurements, including lifestage and sex, in the occurrence records for machine observations. Measurements are not valid except at the time of the occurrence at which they were measured.
Participants in the Network necessarily contribute data to one another's studies. OTN considers the tagged animals from any study to be the indivisible unit of that study, and builds DwC archives that are focused on the tagging data first. If a project deploys no receivers and only has tags, a simplified Occurrence Core archive can be created instead of an Event Core archive detailing their receiver deployment efforts.
When datasets include detections from external projects and partners from other parts of the Network, OTN aggregates the PIs of these projects and includes them in the eml.xml for the DwC archives using the EML-defined role Content Provider. Their contributing receiver deployments are also necessarily included in the Event data for the archive. Internal project members will have priority over any external contributor added in this manner, but this method ensures the attribution of all contributors to any animal movement dataset.
See this Occurrence-core project from Georgia Aquarium for an example of how external partners can be included in the project metadata when they contribute detection data to a repository. See the Contact list for this Blue Shark project for examples of external contributors to this wider-ranging species being included as Content Providers at the project level.