I’m working with detection data for the first time in R. I’ve worked through all the examples in the R book and now I’m importing data for our project that used 38 tags to look at spring depature from the wintering grounds.
I understand that I use:
sql.motus=tagme(projRecv=proj.num, new = TRUE, update = TRUE, dir=“C:/Users/allbyrddata”)
for my first time downloading project data (after specifying my project #).
I also plan to download data from each of our local motus stations by calling out the SG-####### (the code in section 3.5.4), where I have the highest expectation of tag detections.
My question is how do I see if OTHER sensorgnomes in the network detected my tags?
Will this information come through when I download the project # that contains all my tags?
I read through the R Book several times and I’m still not sure how I can be sure I include all the detections that have been uploaded by other users to date. I want to be sure I have as many as possible before I move on to subsequent steps.
Yes you are correct on project number queries and you are basically sling R to filter from Motus website whether you want your tag data or your station data. These two queries are different in that you are asking to retrieve two very different tag databases. Here’s hopefully the answer you may be looking for below but I would love to hear from anyone if am not correct on this:
I have found that if you enter your associated Motus project number (or group of project numbers), you will be able to access (depending on permissions granted by the lead Motus project investigators) all the detection data for your tags regarless of where they are in the world. Basically R let’s you query data directly from the Motus website databank, it narrows/filters onto your project data info, and then retrieves that entire tag data for you your project, including the false detections. Then it’s up to you to filter more what you want and make sure you eliminate through that process false detections. [Tangential: If you don’t filter further your data you will have erroneous data due to many false detections. Motus R book will help you to get to a good filtering level, so no worries there. The key is that once you think your tag data for that project is correct you should learn how to make a good coding system so that you don’t always have to manually refilter the same false detections over and over every time you open your R script; or else after time it will become a laborious long process to access your Motus detection data, believe me!]
If you enter your specific Motus station SG#, as long as it is registered in the Motus website, you will access all tag detection data from what your Motus station or SG was able to detect in the antennas range, including false detections of course. The data you see will again depend on your filtering criteria. This tag database compared to earlier is now showing you all associated tags to your project detected from this specific SG, but also all the “external tags” (tags of other researchers on other Motus projects) that were picked up by your SG. However in this case, it will not show you tag data from other SGs. If you now have multiple SGs registered and deployed in your network and want to query all tag detections from this SG group, then the Motus R book also shows you how to do it or I can send you my code.
Basically you do get all the tag data that is out there but it depends on which query you are asking R to retrieve, and what filters you have.
Thank you very much for this thorough explanation! That was very helpful!
Once I clean my data, and remove false positives, then I have a good dataset to work with myself. I didn’t come across any way to “tell” Bird Studies Canada which detections I’ve deemed false positives. I assume that’s not something they actually want to know or try to manage. All the uncleaned data stay in the “Motus databank” (so to speak) and we, as individuals, clean the data for ourselves, but don’t report back on detections to remove. Is that correct?
We have discussed a few times in the past the possibility of allowing project researchers to share their assessments of false positives, but we have not yet implemented any feature to do so. Part of the challenge is that in order to be useful for others, there probably needs to be some ways to assign probabilities and qualifiers to the detections, so others know how to interpret the information, rather than a crude yes/no kind of filter.
Our hope is that we will eventually be able to use modeling approaches to assign these probabilities, but I suspect there will always be some human elements in the decision making process that you want to apply within your project. In an ideal world, we’d be able to say: use only detections that have at least a 95% confidence level. In reality, there are many reasons why false positives may exist. I think that there is some value in being able to attach your assessments to your data in a way that becomes available to others, so we will likely allow that in a future version, but it may mostly be helpful if other people are using your project data, which we eventually want to encourage and facilitate.
There are a few initiatives that we have been slowly working on that will eventually get at these problems in a more quantitative way. Some of these models will likely be better applied on the entire database, since the local project database may not have all the information it needs. The addition of the activity table to the R package recently was a step towards some of that process, but I don’t have a timeline yet when these additional tools may become available.
So, in principle, it’s a good idea that we have also explored. In practice, we couldn’t figure out exactly how to make it work to be useful for others or to apply to the web outputs, for instance. That said, there are some very clear-cut cases that we know should be flagged, and we’ve been working to put in place at least a manual process by which we can flag those runs in the R package, or hide them from public outputs on the web site. Even then, a complication is that the data is periodically being re-running, so the flags would need to persist across versions that have distinct identifiers, but it’s feasible. Another aspect that we haven’t sorted out yet is whether and how this information will be gathered from the community.
That explanation helps SO much and all of it makes sense as to why this feature or feedback option does not exist yet! And yes, it would be great if there are some detections that we could “deem” absolutely false to save others who haven’t dug into the data from doing the same (or simply thinking they are true)… but I also understand why this might not persist as people continue to download the data raw. It’s quite an interesting problem and I appreciate you taking the time to explain all the thoughts that you and Motus are putting into it.