cleanTagRegistrations: Fix systematic problems with the tag registration database.

In jbrzusto/motusServer: Operate a server to process data for http://motus.org

Description

Some tag registrations had problems. The list of all registered tags is obtained from the motus-wts.org server. A cleaned-up database suitable for the find_tags_motus program is generated, including an events table which indicates when tags were activated and inactivated. This allows the database to be used against any receiver dataset, regardless of the dates.

Usage

cleanTagRegistrations(m, s, cleanBI = FALSE)

Arguments

m	data.frame with full tag info from motus, as returned by motusSearchTags()
s	safeSQL object; database where tables "tags" and "events" will be created.
cleanBI	logical; if TRUE, attempt to clean the burst interval; otherwise, leave it as-is. Default: FALSE.

Value

returns modified m. Side effect:

• creates or overwrite the table "tags" in s, which will contain cleaned tag registrations

• creates or overwrites table "events" in s, which contains activation / deactivation timestamps for each tag deployment.

• updates the file "tags.csv" in the metadata history repository

The events table looks like this: events:

• ts timestamp for event

• tagID motus tag ID for event

• event integer: 1 is activation; 0 is deactivation

path to an sqlite database usable by the tag finder; it will have these tables:

tags:

• tagID motus tag ID

• nomFreq nominal frequency, in MHz e.g. 166.38

• offsetFreq offset from nominal, in kHz

• param1 first interpulse gap

• param2 second interpulse gap

• param3 third interpulse gap

• period burst interval

• mfgID lotek ID code

• codeSet Lotek codeset name

Note

:

For Lotek coded ID tags, the registrations are cleaned up like so:

• empirical gap values are replaced with nominal values from the Lotek codeset

• burst intervals are replaced by the mean of nearby good values. Nearby means within 0.05s, and good means no more than 0.0005 s shorter than the longest nearby BI.

Registration problems appear to be mainly from dropped USB packets, when the computer used to make tag recordings has not been able to keep up with the full funcubedongle sampling rate. The result is overly variable estimates of gap values and burst intervals, with a bias downward from the true values (since dropped packets represent lost time).

The tag activation events are generated using these items from the motus database, in order of preference (i.e. the first available item is used):

1. tsStart - the starting date for a tag deployment record; tsStartCode = 1L

2. dateBin - the start of the quarter year in which the tag was expected to be deployed; tsStartCode = 2L

3. ts - the date the tag was registered; tsStartCode = 3L

Tag deactivation events are generated using these items, again in order of preference:

1. tsEnd - the ending date for a tag deployment; e.g. if a tag was found, or manually deactivated; tsEndCode = 1L

2. tsStart for a different deployment of the same tag; tsEndCode = 2L

3. tsStart + predictTagLifespan(model, BI) * marginOfError if the tag model is known; tsEndCode = 3L

4. tsStart + predictTagLifespan(guessTagModel(speciesID), BI) * marginOfError if the species is known; tsEndCode = 4L

5. 90 days if no other information is available; tsEndCode = 5L

Also, as of 6 April 2016, we're using a lifetime of 700 days for tags in the Taylr 2013 project (gulls)

Author(s)

John Brzustowski jbrzusto@REMOVE_THIS_PART_fastmail.fm

jbrzusto/motusServer documentation built on May 19, 2019, 8:19 a.m.