Alaska Science Center
Douglas Argos-Filter AlgorithmDouglas Argos-Filter Algorithm
Habitat Dynamics Home
PDF Version 8.50 Manual (November 2012)- file 706 kb
Documentation of The Douglas Argos-Filter, Version 7.02 (updated on June 12, 2006)
Table of Contents
Ingests any number of Argos DIAG files and reformats all information into ASCII comma-delimited files. Chooses the most plausible location between the ARGOS primary and alternate locations based on minimum distance from the previous chosen location. Flags implausible locations based on two different filtering methods:
A hybridization of the MRD and DAR filtered results is also created. The hybrid was specifically developed for avian tracking that includes relatively high-speed, directional, migratory events. Locations that passed the MRD filter are retained as ‘anchor points’, then chronologically intervening DAR locations are evaluated to determine if they adhere to directional movement when compared to the vector formed by their preceding and subsequent MRD anchor locations.
A) PC BASE SAS – Version 7 or later.
This SAS program requires PC SAS because it uses DOS commands to concatenate all your individual ARGOS DIAG files into a single file before ingestion. This concatenated file will be written into the same directory where your SAS program files reside, and will be named 'total.dia'. It can be considered a temporary file, which you may delete after the SAS program executes.
B) All your Argos ASCII-format DIAG data files in ONE directory. The SAS program has been written to accept DIAG files from CD-ROM, Telnet, and/or ADS (e-mail), in both compressed and uncompressed formats.
C) You must create an ASCII text-file that defines each of your ptt deployments. This file is comprised of IF-THEN-DO logic blocks relating each ptt-number to the respective animal upon which the ptt was deployed, and during what time interval.
D) You must modify the SAS program 'generic_run702.sas' to supply several user-defined thresholds that establish minimum distances, maximum rate of movement, etc., which largely dictate how conservative or liberal the filtering will be implemented. You must also define several directory pathnames (specific to your computer) that define where your input data are stored, the name and location of your deployment definition file, and the directories where results will be written.
If this program filters a location, it does not necessarily mean that the location was incorrect. Conversely, and more importantly, if this program does not filter a location, it does not necessarily mean the animal visited that precise location.
The underlying premise for the MRD filtering logic is: 'Argos does not make a significant error in the same place twice, consecutively.' In reality, bad Argos locations sometimes do occur at the same locale, consecutively, but with a low probability of occurrence. In about 2000 control relocations, I witnessed 3 consecutive pairs of locations that would have passed typical MRD threshold criteria. So, if you encounter suspicious results from this program – then question those results.
This program will quickly (and systematically) get about 95+% of your Argos data “cleaned-up” to your satisfaction, but you should definitely invest some QC time reviewing the results and getting any last anomalies taken care of before you make and publish biological interpretations.
You control how conservatively the filters behave through user-defined thresholds. How conservative (or liberal) the program is allowed to behave should be commensurate with the study's spatial scale-of-interpretation.
This program does not correct the inherent locational error of any single Argos location. The program strives to reduce the average error among all locations that pass the filtering criteria.
format weight 4.1;
*Directory where ArcView projects will be saved. ;
Please read carefully; most users misunderstand, and set this parameter wrong!
To assign a correct threshold for this parameter, ask yourself: “What is the minimum amount of time that needs to elapse without receiving any ptt transmissions to ensure that at least one duty cycle has incremented?”
If your ptt did not have a duty cycle (eg. it was on continuously), or if the ptt was “off” for LESS time than it was “on”, read the PICKDAY variable below first.
The SAS program attempts to group locations based on the ptt duty cycle during which they were obtained. Most ptts attached to animals have a preprogrammed duty cycle for conserving battery life. For example, 12 hours ‘on’ followed by 60 hours ‘off’, or 6 hours ‘on’ followed by 22 hours ‘off’. Therefore, if enough elapsed time has passed without reception of ANY Argos data, then we can assume that AT LEAST ONE duty cycle has elapsed. For example, consider a ptt that was programmed with the duty cycle below, which changes seasonally:
Season-1: 6h on / 18h off for 60 days
We can conclude that if there was a temporal gap between Argos overpasses (received ptt transmissions) that exceeded 8 hours during any of the 3 seasons above, that AT LEAST ONE duty cycle had transpired.
In the example above, I would suggest a value of 10 be assigned to the MINOFFH variable:
%let minoffh = 10;
That is, consider your ptt's duty cycle (across all seasons if applicable), ask what is the MAXIMUM on duration (units=hours), then add a couple of hours, but don’t add so many hours that the value begins to approach the minimum off time (across all seasons). I add some time because some ptt models do not use real clocks, and their estimates of elapsed time vary. I chose 10 hrs in my example above because it’s liberally above the maximum on time (8h) and conservatively below the minimum off time (18h).
Note that if the minimum OFF duration is less than the maximum ON duration, during any season of a ptt's duty cycle, this logic fails. It will not crash the SAS program, but it will mean that the output variables PICK and DUTY will not be valid (see variable definitions below). It’s less common that animal ptts are programmed to transmit with intense battery consumption, but some studies do. If your ptt transmitted continuously (24h/day), then using the 24-hour day would be a logical choice for defining temporal intervals. See the PICKDAY variable below.
NOTE: The 'DUTY' variable only increments when a location is actually acquired from Service Argos. The 'DUTY' variable DOES NOT NECESSARILY EQUAL the number of 'real' elapsed duty cycles. When a ptt fails to acquire a location during any given real duty cycle, the 'DUTY' variable does not increment, and thus falls behind the actual number of expired duty cycles.
This variable (units=km) is used to filter the Argos locations such that every retained location has a temporally near-consecutive location that is spatially within the defined distance. The premise for such a filter is that larger Argos locational errors rarely occur consecutively in the same place (although it does happen, it is relatively rare in most datasets). The program logic is constructed as follows: The dataset is evaluated chronologically for each animal. Three consecutive locations are evaluated simultaneously - call them locations A, B, and C (see Figure below). The 3 resulting between-location distances are calculated (A->B, B->C, and C->A). If any calculated distance is less than the user-defined threshold (MAXREDUN), then both locations (the 2 endpoints of the vector whose length is less than MAXREDUN) are retained (they are not filtered). The term 'near-consecutive' is used above, because in the typical situation, location 'B' will be the outlier, and locations 'A' and 'C' will be the pair of redundant, self-confirming locations, even though they are not exactly consecutive. If location-B is flagged for omission, then should it be considered in the next set (triplet) of evaluated locations? Good question - please read the SKIPLOC documentation below. If location-B was flagged for filtering but the SKIPLOC parameter is set to zero (0), then next set of evaluated locations would be: B->C, C->D, and D->B. If the user-defined variable KEEPLAST (see below) is set to a value of one (1), then the last location for each animal will NOT be filtered, regardless of distance to the prior location.
What value should be used for MAXREDUN? Very good question. It depends on several factors, but the most important one is 'At what spatial scale are you interpreting your location data?' For example, consider a bird tracked from Canada to Chile (very broad scale). Let's say that during migration, as the bird was travelling over northern regions of South America, 1 Argos location with a Location Class value of 'B' was obtained near the coast of Peru. If this was the ONLY location received after the bird left Cuba and arrived in Chile, then it shouldn't concluded that this individual used a migratory pathway along the coast of Peru. A single Class-B location could have a very large error. But, what if another location of Class-B quality was obtained that was consecutive to the aforementioned location, and they were within 30km of each other? Now, 2 Argos locations, albeit of low Class-quality, have self-confirmed the same general Peruvian area. Together, they provide a lot more credibility toward concluding that the animal used the coastal region of Peru during migration to Chile. So if you're investigating continental or hemispheric-scale movements, having an animal relocated within 30km is reassuring information.
In contrast, imagine a kangaroo study, and that the study animals really didn't go anywhere - they just stayed around an area of +/- 25km. The raw Argos data are probably spread over a large geographic area, a mixture of good and implausible locations. In this situation, a very conservative MAXREDUN value of perhaps 2km would be more appropriate. Such conservative values will filter a lot of locations, but it may be worth having a critical look at those locations that are not filtered.
There are other factors involved with the usefulness of the MAXREDUN filter, such as duty cycle, latitude, and the real rate of animal movement. For example, I have been using MAXREDUN = 10 for filtering polar bear data. The polar bear transmitters typically transmitted for 6 or 8 hours every 3 or 7 days. During their on-period in the northern latitudes, several locations were usually obtained, especially when the ptts were not near the end of their battery life. Because polar bears move relatively slowly, there were enough locations during the duty cycle that were within 10km of one another to provide redundancy, and the more implausible locations were fairly easy to identify. However, if you have a duty cycle that has a relatively short on-time, and/or your study area is near the equator where the frequency of satellite overpasses is minimal, then many or most of your duty cycles may have recovered only a single location. Or, if your animals are moving relatively large distances during (within) the duty cycle, your dataset will contain little locational redundancy, and the redundancy filter may not be very useful. This is typical of avian tracking when the birds are migrating. When birds are at their nesting, staging, or wintering grounds, MAXREDUN values of 5km or 10km may be satisfactory, but when the birds are migrating, the distance-angle-rate filter (described below) will be more useful. Merging the results of the redundancy filter and the distance-angle-rate filter, for animals like birds that nest, stage, molt, migrate, and over-winter, is also implemented in this Versions of this Program that are > 5.0 (see AZMARGIN, XMIGRATE, and XOVERRUN below).
The program sequentially evaluates 6 tests (shown in the above figure). Note that location-B will ALWAYS be retained if the distance A->B is less than MAXREDUN. In other words, if the animal did not move farther than the user-defined threshold for spatial redundancy, then further tests regarding rate of movement or direction are irrelevant. Two consecutive Argos locations with good accuracy can be associated with an extremely high rate of movement when the elapsed time between the two locations is very small. Note also that if the Location Class for Location-B is greater or equal to the user-defined KEEP_LC value, then Location-B is automatically retained. If the user has specified R_ONLY = 1 (see below), then Test #3 is not conducted.
The third step of the assessment evaluates the angle (alpha), and permits the angle to get bigger as the distance of the smaller of the 2 vectors (dist1 or dist2) increases. If the distances are relatively small, a tighter angle is required to cause a filtered result. If the distances are relatively large, then a larger angle will cause implausibility. This is necessary, in part, because the SAS program uses great circle aviation math to derive distance and direction, but it is also biologically reasonable to presume that the farther an animal moves, the less likely it is to have immediately returned back toward the originating region. The user has to define a value for RATECOEF, which has a logarithmic influence over the behavior of the angle assessment. RATECOEF is discussed in more detail below.
The last part of the assessment requires that at least one of the two vectors has a rate of movement that is suspect (above the user specified minimum MINRATE). If rate1 is gt MINRATE, then location-B is filtered. If rate2 is gt MINRATE (and rate1 lt MINRATE) then it becomes ambiguous whether Location-B or Location-C (or both) is implausible. Cumulative distances from Location-A to Location-D, either through Location-B or through Location-C, are compared to decide whether Location-B will be filtered.
The entire DAR filtering strategy is iterated 3 times, each successive iteration using only locations that passed the previous iteration. It is necessary to iterate the DAR strategy multiple times because filtering a location during one iteration may create implausible rates of movements or suspicious angles that need to be reevaluated by a subsequent iteration.
Finally, two more DAR iterations are performed using a slightly different set of decision rules that are documented in the figure below. These modified rules are identical to the rules used in all previous versions of this program (e.g. Versions 5 and below). In previous program versions, the DAR decisions documented in the figure below were iterated 5 times. In Version 6, slightly different sets of criteria were used in the first 3 iterations to try and improve decision about the fate of Location-B when only rate2 exceeded MINRATE (e.g. when it was ambiguous if Location-B, Location-C, or both were implausible).
This coefficient influences how the angle (alpha) is evaluated. Larger angles will be considered suspect as RATECOEF increases. Use of this coefficient needs further study and empirical testing. The figure below illustrates the behavior of RATECOEF. For example, if the shorter of the 2 vectors (A->B and B->C) was 30km and RATECOEF=10, then if the angle (alpha) was less than about 9-degrees, location B would be filtered. If RATECOEF=15, then angles less than about 26-degrees would be filtered, and for RATECOEF=25, angles less than about 60-degrees would be filtered. Assigning larger values to RATECOEF will result in more locations being filtered. More mobile animals should be assigned smaller RATECOEF values. I suggest you begin with RATECOEF=15 for birds, and RATECOEF=25 for mammals and reptiles, then review the filtering results, and adjust RATECOEF if you feel it's necessary or you want to experiment. I have used a RATECOEF value of 15 for oldsquaw, 20 for swans, and 25 for polar bears, with reasonable results. I experimented with even more aggressive (higher) RATECOEF values for some tracking data where the animals moved very little throughout the study. I concluded that distance-angle-rate filtering is less stable, and less intuitive for relatively sedentary animals, and that minimum-redundant-distance filtering is a better choice under such conditions.
One and only one choice should be flagged with a value of '1', the other must have a value of zero. The program will immediately abort if more than one choice (or no choice) is made. Filtering is made if:
In Case-1, either rate1 or rate2 must exceed the user defined MINRATE,
In Case-2, either rate1 or rate2 must exceed the user defined MINRATE
Most often, a user will select the 'rate or angle' (Case-2 above). A user might decide otherwise when tracking animals with particular behaviors. For example, consider sea birds such as murres or puffins that frequently travel from a colony to offshore feeding areas, and return. With this type of behavior, we might expect 'out-and-back' movements in the tracking data. The user should consider selecting the 'r_only' choice (rate only), such that locations would only be filtered if the rate of movement exceeded MINRATE, regardless of the angles formed. This strategy will likely leave a substantial number of erroneous locations unfiltered. I would suggest careful review of the 'r_only' results, searching for areas of repeated use (eg. look for temporal redundancy across days, or individuals). Repeated use of an area over time, or by multiple individuals serves to confirm, while single 'out-and-back' movements to areas that were never visited again should remain suspect.
You may change all date/time values in the output data sets to have values equal to 'local' time, rather than the GMT date/time that Argos disseminates. Unit for the GMT offset variable is hours. For example, tracking conducted in California might set GMTOFFST = -8. If GMTOFFST is set to zero, then all date/time values are left unchanged (GMT). If you use a value other than zero, it may become problematic to merge or compare the output data sets to the raw Argos data, or to other data summaries. Alternatively, it is easier to interpret diurnal animal behaviors in units resembling local solar time. If your animals moved extensively between time-zones (large east-west movements), it's best to keep GMTOFFST = 0.
GMTOFFST does not adjust the DEPLOYMENT Date/Time (dtime). Thus, it is important that the dtime variable (in the deployment logic-blocks) uses the same time zone defined by GMTOFFST.
If GMTOFFST is set to 0 (zero) then all date/time values in the output data sets will be the same as those in the raw Argos data. If GMTOFFST is not equal to zero, the GMT_DATE, GMT_HOUR, GMT_MIN, and GMT_SEC in the output data sets will continue to adhere to GMT time, while all other date/time values will have the offset applied.
latmin = -90. ;
These parameters form a rectangular geographic area-of-validity. Restricting this area of validity can sometimes be useful if you have received very aberrant locations in your raw Argos data. If a location falls outside the geographic rectangle, the record is simply removed from all outputs.
This variable must be set to either 3, 2, 1, any other value will cause the program to fail. This parameter establishes the minimum Argos Location Class that will NEVER be filtered by either the Minimum Redundant Distance (MRD) Filter or the Rate Angle Distance (DAR) filter. The value you choose should be commensurate with the spatial scale of data analysis. We have very rarely observed an Argos Location Class 3 to have accuracy worse than about 1km (usually they are within 0.5km). However, if you are studying continental or broad regional movements, then the larger location errors associated with LC2 and LC1 (+/- 5 or 10 km respectively) may be negligible compared to the overall movements you are studying. If this is the case, then you should consider keeping all LC1, LC2 and LC3 locations (prevent them from being filtered) - thus set KEEP_LC = 1. If you are studying more local scale movements, set the KEEP_LC value to 3, and let redundancy self-validate the Argos data. If you are studying broad-scale movements, use KEEP_LC = 1.
This variable allows the user to choose between 3 different equations that determine which location (within a duty cycle) will be identified as the ‘highest quality’, and carried forward into the ‘Pick’ (pk) datasets. The 'highest quality' location per duty-cycle is chosen based on the Argos Location Class (3,2,1,0,A,B,Z), and in the event of a tie, then the RANKMETH value will determine which equation is implemented to resolve the ambiguity. Valid RANKMETH values are 1, 2, or 3, where the value identifies one of three equations to resolve which location will be selected for the ‘pick’ datasets, GIVEN that the LC values are a TIE:
rankmeth = 1: The location with the highest IQX will prevail, else if a tie, the location with the highest IQY will prevail, else if a tie, the location with the most number of messages. This is equivalent to the method used in Versions 6.0-6.4.
Set this variable to 1 (one) if you want to retain the last location for each animal, within the minimum-redundant-distance filter, regardless of its location. Set the variable KEEPLAST to zero if you want the last location for each animal to be filtered if it is greater than MAXREDUN from the previous location. Recall that the last location for each animal is NEVER filtered by the distance-angle-rate (DAR) method.
Set this variable to 1 (one) if you want to select the location with the best Argos location class based on 24-hour periods instead of the ptt’s duty cycle. While duty-cycle is typically a better interval from which to pick the ‘best’ Argos location, sometimes a biologist builds ptts that do not have duty-cycles, e.g. the ptt is on continuously. In this case, by setting PICKDAY = 1, the location with the best Argos Class will be selected based 24-hour periods (eg. daily).
Important Note: If you use PICKDAY = 1, then set MINOFFH = 0.00001;
Consider 5 consecutive locations, and call them A, B, C, D, and E. The minimum-redundant-distance-filter considers consecutive triplets of locations; the first triplet would then be A, B, and C. Three distances are calculated: AB, BC, and AC. If any of the 3 distances are less than MAXREDUN, the two respective end-point locations are retained by the filter. A question arises in the event that location ‘B’ is rejected: should location ‘B’ be considered in the next triplet? If SKIPLOC=0, then location ‘B’ is considered, and the next triplet would be B, C, D; and the 3 distances BC, CD, AND BD would be evaluated. If SKIPLOC=1, then location ‘B’ is not considered (it is skipped), and the next triplet would be C, D, E; and the 3 distances CD, DE, and CE would be evaluated. Most feedback I’ve had indicates that users prefer SKIPLOC=0.
These variables are used to combine the minimum redundant distance filter results (MRD) with the distance angle rate filter results (DAR). When an animal is actively migrating, locational redundancy is difficult or impossible to obtain. Often, locations during active migration only pass the DAR filter. Beginning with Version 4.0 of this program, datasets are created that pool results from both filters. The logic assumes the MRD results are superior, and considers those locations that passed the MRD filter to be ‘anchor’ points. Ultimately, the merging routine supplements the MRD results with locations that passed the DAR filter, ONLY IF the DAR locations pass a user-defined number of directional movement tests (described in the next section). The user-defined variables XMIGRATE, and XOVERRUN control whether a MRD vector (a vector based on two consecutive MRD anchor locations) represents a ‘Migration Event’. If it represents a migration event, intervening DAR locations collected during that vector-period are evaluated and potentially amended to the output data set, if those intervening DAR locations adhere to the directional movement defined by the MRD vector. The ‘Migration Event’ test for a MRD-vector is passed if:
Thus, intervening DAR locations are not considered if the distance between two consecutive MRD locations was not representative of a ‘Migration Event’. The distance defining a migration event is calculated as: XMIGRATE*MAXREDUN. Therefore, if you had defined a relative small value for MAXREDUN, then the XMIGRATE factor would have to be adjusted larger in order to maintain the same threshold for defining a migratory movement.
The parameter XOVERRUN prevents a DAR location from being retained if that location results in a vector which exceeds the distance of the original MRD vector by an amount of XOVERUN*MAXREDUN. In other words, it attempts to prevent a bird from over-flying the MRD endpoint ‘anchor’ destination.
These variables are used when combining the minimum-redundant-distance filter results (MRD) with the distance-angle-rate filter results (DAR). These 3 parameters are used to make 3 independent tests of directionality. Using the MRD locations as anchor points, EACH intervening DAR location is INDEPENDENTLY assessed, as described below. Assuming that the XMIGRATE and XOVERRUN tests (above) were passed, 3 directionality tests are conducted: DIRECTION, ANGLE, and PERCENT.
In the figure below, consider two consecutive locations (A and B) that passed the MRD filter, and therefore have become anchor points. An intervening location (X) had passed the DAR filter, and will now be considered for amendment to the MRD results. Acceptance of rejection is based on results of three directionality tests.
TEST #1 - DIRECTION:
If the azimuth of A->X is within +/- XDIRECT-degrees (a user-defined threshold), location X passes the direction test. Units for XDIRECT are degrees, and the threshold in the figure above is illustrated by the angle j. In other words, if the azimuth of the vector A->X is within +/- XDIRECT degrees of the azimuth of A->B, then the direction test is passed.
TEST #2 – ANGLE:
This test evaluates the angle formed by A->X->B (angle a in the figure above). If XANGLE is greater than or equal to a, location X passes the angle test. XANGLE should not exceed 180.
TEST #3 – PERCENT DISTANCE:
If the total distance of travel along A->X->B is no greater than a user-defined percent (XPERCENT) of the anchor-distance A->B, then X passes the PERCENT DISTANCE test. That is, how much farther are you willing to let your animal ‘wander’ in order to pass through location X on its way to location B: 10%, 25%, 50%?
TESTPASS defines how many of the 3 tests above (1, 2, or 3) must be passed in order for the location in question (X in the Figure above) to be retained in the ‘Best Hybrid’ output data set. If TESTPASS is defined as ‘1’ (the most liberal), then only one (any one) of the three tests is required to pass. If TESTPASS is set equal to 2, then any two of the 3 tests must pass, and if TESTPASS is set equal to three (the most conservative), all 3 tests must pass.
Beginning in Version 6.5, TESTPASS was partitioned into two parts: 1) cases where the location in question is an LC=Z or LC=B; and cases where the location in question was an LC=A, LC=0, or better.
If the user wants to be more conservative with LC=Z and LC=B locations, then the user might assign, for example:
%let testp_0a = 2 ;
The above requires that LC B and Z locations pass all three directionality tests in order to be retained in the ‘Best Hybrid’ output, while LC A and 0 locations need only pass 2 directionality tests.
If the user has defined KEEP_LC = 2 or KEEP_LC = 3, then the TESETP_0a threshold also applies to number of affirmative directionality tests of any intervening LC1, or any LC1 and LC2 locations, respectively.
At the beginning of this program, a choice is made between the Argos primary and alternate locations using the entire data set of deployed ptts. Initially, the choice is made based on sequential minimum distance criteria starting with the deployment location. When CROSSVAL = 0, no further evaluation is made, and the SWITCH variable in the output data sets will be either 0 (primary location chosen) or 1 (alternate location chosen). But if you are tracking a highly mobile species (e.g. a migrating bird), then the animal can sometimes travel a great distance between locations (especially between duty cycles), and the “alternate” Argos solution is more likely to fall between the actual originating and destination locations and be incorrectly chosen in the first iteration. When CROSSVAL = 1, the program attempts to cross-validate its initial choice between the 2 solutions by evaluating the pair of locations from the subsequent overpass. The SWITCH variable can then contain a value of: 3, if the original choice to use the alternate location was reverted back to the primary; or 4, if the original choice to use the primary location was reverted to the alternate. Until program version 7.02, the condition was always CROSSVAL = 1 (internal default). But, if you are tracking a species that does not move great distances (perhaps several hundreds of kilometers) between locations (especially between duty cycles if applicable), then using CROSSVAL = 0 is probably more stable.
This parameter is set equal to 1, if and only if, you have received UNIX-format SAS datasets of your Argos data from David Douglas. Otherwise, it should remain equal to 0 (zero). Most users should ignore any references to UNIX and the parameter UNIXDATA. If you are a USGS Alaska Science Center biologist, you should coordinate with David Douglas to obtain UNIX-format SAS datasets fro this program that were derived from our CD-ROM archive, rather than using DIAG data obtained through TELNET or ADS.
The table below defines each of the variables that appear in the ASCII output files. Not all variables appear in each of the ASCII files that are created. “(DIAG)” denotes a parameter that is directly copied from the original Argos DIAG input data.
01. The program never filters Argos Class-3 locations. If the user defined variable KEEP_LC is set to 2 (two), then the program never filters Class-2 or Class-3 locations. If KEEP_LC is set to 1 (one), then the program never filters Class-1,2,or 3 locations. If the user defines MAXREDUN >10 km, then it would make sense to set KEEP_LC = 1, since Class 1, 2, and 3 locations usually have accuracy within 10 km (e.g. there is no reason to filter the Standard Location Class data).
02. In the DISTANCE-ANGLE-RATE (DAR) filter, the last location for each animal is NEVER filtered. In the MINIMUM-REDUNDANT-DISTANCE (MRD) filter, the last location for each animal may or may not be filtered, depending on its proximity to the previous location and the value you assign to the KEEPLAST parameter.
03. If an animal has ONLY 1 or 2 locations in the entire data set, no filtering is attempted.
04. If you are interested in a detailed analysis of ptt sensor data, this is not the program to use. The Argos DISPOSE file format contains your full set of sensor data; the DIAG format only contains ONE message of sensor data per overpass which simply serves as a solitary 'example' of your sensor data.
05. If you study the SAS program code, you should know that goodlat=latitude and goodlon=longitud. Most of the program code references goodlat/goodlon, but I changed the variable names at the end of the program to accommodate default entry into ARC/VIEW through TABLES.
06. Don't be alarmed by the series of 'INVALID DATA' errors that will appear in the SAS Log after reading in the input DIAG data file. The errors arise when the program tries to read a lat/lon in a DIAG overpass that only has '????' reported the lat/lon fields (No Argos location was reported). In this case, lat and lon are set to SAS missing values, which is correct.
07. CAUTION: The output ASCII files contain ONE DEPLOYMENT record for each animal. This was necessary to correctly choose and filter the very first ARGOS location. However, most variables for this deployment record are invalid, they are set to dummy values or they are just duplicate values of the first REAL Argos data for the respective animal. Before quantifying metrics about the ARGOS data, be sure to remove the deployment records. In the deployment records, the variable LC94 equals 'DP', so you can use this variable to selectively remove the deployment records.
08. The variable named 'switch' has a more detailed interpretation because I added code to re-evaluate the initial choice between the Argos primary and alternate locations that was based solely on minimum travel distance. The new code considers where the animal is located one overpass subsequent to the overpass being evaluated. I found that choices were more correct using this additional logic. Now, 'switch' has four categories:
switch = 0 Original choice of the primary location also passed 2nd test.
09. The choice of the best quality Argos location per duty cycle (variable 'pick') may vary between the output ASCII files that underwent filtering, because the location that was picked in one data set may have been filtered in another data set, e.g. the variable 'pick' is chosen independently for each data set.
10. You may find it necessary to 'override' this program's choice between the primary and alternate Argos location for some specific overpasses. This situation happens more frequently when an animal is moving large distances between duty cycles, and/or the ptt is near the end of its battery life. There is an accompanying ASCII text file named “hardcode_changes.txt” in which you can: 1) force the primary location to be chosen; 2) force the alternate location to be chosen; or 3) remove the entire overpass from all output data sets. The “hardcode_changes.txt” file contains further documentation. Obviously, you need to study the initial filtered results in a GIS (ArcView) to discover any aberrant overpasses that would benefit by forcing the choice between the primary and alternation location (or removing the overpass entirely). The examples I provide are commented, you must ‘uncomment’ the SAS code by removing the preceding * (asterisk) in column #1 of each line. Also, be very careful when you edit the “hardcode_changes.txt” file - ONLY USE an ASCII editor, and DO NOT CHANGE the file’s name: it must be named “hardcode_changes.txt”.
Example of 3 strategies using logic blocks to (respectively): 1) force selection of the alternate Argos location; 2) force selection of the Argos primary location; and 3) completely remove the overpass from all output data sets.
* if line = 'bhg0101162000:224848Z99' then do;
* if line = 'bhg0303182000:201439Z99' then do;
* if line = 'bhg0303182000:201439Z99' then do;