Clean reference data LBBG_SCHIERMONNIKOOG

[sannegovaert]

When we download the reference data from UvaBiTS, the data is automatically mapped to the Movebank data format.
Here is the reference data for LBBG_SCHIERMONNIKOOG in Movebank format.

Questions for @jshamoun and @sshinne

1. ses.start_date = deploy-on-timestamp and ses.end_date = deploy-off-timestamp

   • Can you confirm that the deploy-on-timestamp and deploy-off-timestamp is correct for alle deployments?

The deployment thus only starts when a bird is tagged and released. And the deployment ends when the bird has died or the tag has been removed. We do not want to publish measurements when the bird is in captivity (eg rehabilisation center) or the tag in somebody's car or office :)

2. ind.remarks = animal-comments
   This needs to be cleaned up.

   • 2.1 Remove alle text with logger xxxx - this information is already availble
   • 2.2 Preferentially remove text with tagged by K Oosterbeek - this is not a remark about the bird
   • 2.3 Remove text last bird of day - this is not a relevant remark about the bird

3. ses.remarks = deployment-comments

   • This needs to be cleaned up.
   • Please rephrase dead logger because the presence of the word "dead" now results in deployment-end-type set to "dead".

Be aware that deployment-end-type is filled in based on the presence of 3 words in session remarks. Other values from Movebank vocabulary cannot be consistently derived.

deployment-end-type set to	Session remarks contains the word
dead	dead
equipment failure	defect
equipment failure	malfunction

[sshinne]

1. deploy-on-timestamp is always correct for all deployments. Judy will update records where deploy-off-timestamp is blank.

2.1 Judy will clean this up in our database.

2.2 and 2.3 Similar to Issues #260/262: animal-comments and deployments-comments should only be used to populate other fields when that makes sense (e.g., to set a value in deployment-end-type), but otherwise these comments should not be passed to ind.remarks or ses.remarks. We need to leave this as is in our database, and the comments should not be uploaded to Movebank remarks fields.

3 We are willing to look into this, but we are wondering if you have any suggestions for language we should use to replace it.