Argos Satellite Tracking Data for Pacific Walrus (Odobenus rosmarus divergens) - Processed Data

The deployment attribute table (pacificWalrus_USGS_ASC_argosGPS_deploymentAttributes.csv) has been cross-checked with original deployment records for accuracy. We determined the deployment end times (recorded in the Deployment_End_Timestamp_UTC field) in this table by manual inspection of data derived from each deployment. If a tag produced telemetered chronologies about haulout, in-water and foraging behavior, we utilized the chronology to determine deployment end times. Specifically, we assigned the deployment end time to be one hour after the final behavior chronology interval if that hour was reported to be in water. If the telemetered behavior chronology reported a terminal haulout period (that is one or more contiguous behavior intervals all reported as being dry indicating that the walrus was hauled out of the water) we determined the tag deployment to end one hour after the first behavior chronology interval reported as dry in that terminal haulout period. We chose to terminate the deployment after the first behavioral interval in a terminal haulout because we reasoned that there is no way to determine if the tag remained on the walrus the duration of the terminal haulout period or if it detached from the walrus immediately after coming to shore. If the telemetered behavior chronology ended in a series of predominantly dry behaviors with sporadic or cyclical wet behavior intervals without further foraging behavior intervals reported, as would be observed for a tag removed from a walrus that is exposed to tides and storm surges, we determined the tag deployment to end one hour after the first behavior chronology interval reported as dry in this terminal period. For tags that did not produce behavior chronology records, we determined the deployment end time to be one hour after reception of the final plausible tracking location. Some deployments produced tracking locations at sea after the last behavior chronology interval. This may reasonably occur because collection of behavior chronologies requires reception of at least two sensor messages that pass the cyclical checksum validity test, whereas Argos locations may be determined from any set of receptions that properly encode the Argos ID and are repeatedly received during an Argos satellite overpass. For these uncommon cases of the reception of at sea locations after the last behavior chronology interval, we inspected the tracking data to determine if the track could plausibly be explained by the tracking of a tag that has been removed from the walrus on an ice floe or a tag drifting at sea on a walrus carcass. If either of those were plausible explanations of the tracking data, we terminated the deployment using our standard rules based on the behavior chronologies. If those explanations were implausible, we terminated the deployment when the tracking data ceased or when the tracking data came ashore. We indicate reasoning for deployment end times in the deployment comments (Deployment_Comments) field of the deployment attributes CSV file.

When a marked walrus traveled to shore and thereafter shucked the tag, the Argos tracking locations were often not obtained on shore until sometime after we had determined that the deployment had ended based on behavior data chronologies. This could happen due to duty-cycling of the tag transmissions and/or due to the orbitography of the Argos satellite constellation that result in a delay between the actual arrival on shore and the first locations obtained from shore. Those locations on shore in the hours, days, weeks or even months after the end of the deployment provide valid information about the location where the marked walrus came ashore. If we were to disregard all locations obtained after the end of a tag deployment (when based on behavior chronologies), we could lose this valuable tracking information regarding the coastal destination. For cases where it appeared that a tag became detached onshore, we provide a deployment end location (in the deployment attributes file) that we calculated as a weighted mean (based on Argos Location Class) of the Argos locations obtained up to seven days after the deployment was determined to have ended. These deployment end locations, as well as all deployment start locations, were added to the Argos tracking locations (in Movebank only) after which the Douglas filtering algorithm (see below) was applied (in Movebank) to all tracks.

We determined the plausibility of tracking locations with the Douglas filter (Douglas et al 2012). We parameterized the algorithm to retain all standard Argos class locations (3, 2, 1), and to retain all non-standard Argos class locations (0, A, B, and Z) within 2 km of a previous or subsequent retained location. Remaining locations were retained using a "distance angle rate" algorithm that accepted locations if they did not result in unreasonable speeds (>10km/hr) and did not result in acute out-and-back again movements that are characteristically generated by an erroneous outlier location estimate (Douglas filter rate coefficient value = 25). After the initial filtering, we examined each track and made a relatively small number (0.2%) of manual adjustments to the algorithm-based decisions. The most commonly made manual adjustments to the Douglas filter was to exclude locations that occurred far inland or to exclude standard Argos locations that nevertheless resulted in implausible rates of movement over large distances. This manual flagging of implausible locations in this data archive may differ slightly from filtering used in prior publications that used the tracking data in this release. Subtle differences in filtering outcomes may be due to (1) our assignment of a deployment end location for deployments that produced behavior chronologies that ended on shore; (2) variations in the manual overriding decisions; (3) manual extension of some deployment end dates to retain one or more plausible locations that were obtained after the behavior chronology end time (as discussed in the previous paragraph); and (4) some adjustments in deployment end dates identified for deployments that had no telemetered behavior data.

Data Collection. Argos raw data in both "DS" and "DIAG" legacy formats were extracted from monthly datasets provided by Service Argos (a.k.a. CLS America or Woods Hole Group) on CD-ROM. Beginning in July 2009, both DS and DIAG data were also obtained from Service Argos on CD-ROM in tabular format as Comma Separated Value (CSV) files. The tabular files contain all information reported in the Argos legacy file formats. The tabular DIAG files also include variables describing the Argos error ellipse (beginning in July 2009). Tabular DIAG data files before July 2009 (if applicable) were reformatted directly from the legacy DIAG files, and hence do not contain the error ellipse variables.

Data Flattening. The extracted GPS tabular file and the raw Argos tabular files have had additional attributes appended by the authors to each record (including 'Animal_ID', 'Animal_Species' and 'Tracking_Status').

Determination of Deployment Fate and Tracking Status. Location and sensor data were examined for each record to assign the value of the 'Deployment_Fate' and 'Tracking_Status' variables. Details are described in the attribute definitions, below.

Douglas Argos-Filter. Implausible location estimates were flagged using the Douglas Argos-filter (DAF) as implemented in Movebank. DAF is an ad hoc algorithm that identifies implausible Argos location estimates based on user-defined thresholds which allows the algorithm's performance to be tuned to species' movement, behaviors, and study objectives. Key thresholds define: 1) the distance within which sequential location estimates are retained by virtue of self-validating spatial redundancy, 2) a maximum rate of movement, and 3) the acuity of tight turning angles which are characteristically created by location estimates with large errors. Definitions of the DAF parameters can be found in the filtering help pages at Movebank.com and Douglas et al 2012. The user-defined DAF parameters applied to these data were: Filter Method = DAR; keep_lc=1; maxredun=2; offset by one second=True; keeplast=disabled; skiploc=disabled; minrate=10; r_only=disabled; ratecoef=25; xmigrate=2; xoverrun=1.5; xdirect=20; xangle=150; xpercent=20; testp_0a=2; testp_bz=2; Best of Day filter=disabled; pickday=disabled Each animal's track was visually examined to assess the algorithm-derived filtering decisions, and manually edited if warranted.

Raw sensor data are encoded for transmission. The specifics of encoding vary with transmitter manufacturer, model, and batch. We decoded raw (coded) sensor values, received from Service Argos, following procedures prescribed by transmitter manufactures.