-
Notifications
You must be signed in to change notification settings - Fork 3
Merging Tag registration & Tag release process #365
Comments
@xhoenner this has been approved by the ATF Data Committee as a necessary step to:
What is the likelihood of getting this implemented in the coming months? |
Fields that will need to be made mandatory: Registration: project, tag serial number, model, transmitter type, tag ID & ping code and code space for each sensor, slope and intercept (if sensor tags), and expected battery life (necessary for metadata exchange with OTN). Sensor units should be automatically pre-filled based on sensor type entered. Release: species, sex (incl. ‘unknown’), release location (lat and long), release date/time (if possible time should be entered in the user's local time zone and then converted in the back-end as UTC?), animal measurements (incl. ‘Not taken’) It could also be useful for users with writing/PI rights to be able to specify a recovery date for the tags they own in their project, in case one tag gets recovered and is to be re-deployed - in such case would there be a way to ensure a new detection data file is created for this tag for the following deployment? |
@fjaine this issue has now been added to the developers' list. As per your last comment:
I'm afraid this is a separate issue that will have to be dealt with separately.
This is currently automatically being taken care of by the web app. When users add a new tag release to a tag that's already been deployed detections are automatically matched to each release based on their respective tag release dates. Still, having an extra 'tag recovery date' field in the tag release page would be informative metadata to capture but that can't be dealt with as part of this issue. Can you create a new GitHub issue for this please? |
@fjaine wouldn't it also be useful to have a |
@xhoenner lifestage might not be easy to determine for all species but it wouldn't hurt to have the option to specify it (with a 'unknown' option). This said, I also think we should keep it simple as users always wish there was less to manually enter. I expect a lot of entries to be 'undertermined' or 'unknown'. But if you think a 'lifestage' field would be valuable, then why not. The question is - how valuable would such information be in addition to length measurements already collected? |
A large part of the issue of registered tags missing release metadata (https://github.com/aodn/aatams-content/issues/40 and https://github.com/aodn/aatams-content/issues/49) were due to the fact that, as one researcher explained, it took too much time and effort to register the tags and then have to enter the deployment information in a different process. This has often resulted in users starting to register their tags but then omitting to enter their release details later on.
Additionally, there is also the issue of some users registering their tags so they can access detection data from the IMOS AT community receivers, but not willing to share their release data.
The easiest way to solve both issues at once would be to merge the tag registration and release processes. In this case, a user would only have to action one process in the database once their tag has been successfully deployed on an animal, during which they would be required to enter both animal information (i.e. species, size, sex, etc.) and tag information (i.e. transmitter type, sensor type, code space, ping ID, slope, interval, unit).
With the proposed change, all the information required for the database to function without errors would be entered at once by the user, thus facilitating user experience and also reducing effort required by ATF/AODN staff to subsequently resolve the incumbent errors associated with missing release metadata.
The text was updated successfully, but these errors were encountered: