We are doing a Bioblitz in about a month. We had tested out uploading a month ago, and we ran into issues. Therefore, we would like to set up a dummy project so that observers can test out uploading their observations before the actual Bioblitz. It seemed like uploaded observations were seen by iNat members, and there were comments and identifications. But we don’t want iNat members wasting their time on a dummy project. How do we set up a dummy project, prevent iNat members from viewing the observations and then deleting the dummy project? Or is there a better way to accomplish pre-Bioblitz uploading of observations?
2 Likes
you can just set up another collection project for the test period… however there’s no way to keep observations you upload from showing up for everyone.
There has been a proposal to create ‘draft observation mode’ from the app where you could delete or edit them before they are made public, but it doesn’t exist as of now
3 Likes
Creating the project is fine, it won’t impact on anyone. It would be “tidy” to delete it, but wouldn’t be a problem if you didn’t…
The test observations themselves, however, will have an impact on iNatters. The best way to approach it is to make legitimate observations as your tests… Rather than photographing a foot or a poster, make sure the photo is a real organism, and aim to make the observation accurate for pin location and date/time seen etc. It can help to put “test” in the description… just so that anyone noticing any probs can point them out for you!
and thankyou for actually asking about this, so many just steamroller into massive projects without testing their processes before hand!
2 Likes
I have run into a similar issue doing talks about iNaturalist where I demonstrate submitting an observation. When I used an old photo, it would get identified and I’d feel guilty. Adding “this is a demo, no need to ID” didn’t help. Now I just stop and take a new photo on the way to the talk, so it’s a real observation. You can always find something!
2 Likes
I don’t know if this is a solution because I have no experience with such things but would opting out of community ID on those observations work? Or marking them (the ID) as good as it gets?
Someone else with actual experience can surely point out why this will or won’t work but it’s the thought I had. Perhaps useful.
I think opting out of community ID would make it worse because the ID would be ‘stuck’ even if wrong. You could flag a data quality flag such as time wrong or location wrong, but by the time you do that you are already on the website and can just delete it (can’t do that from the app).
2 Likes
If you mark them as “captive” upon creation, get them IDed by 2 members to species, then unvote the “captive”, fewer will see it as it won’t be “Needs ID”. Only users wanting to verify specific records (whether by area or species) will see it.
1 Like
Opting out of CID is definitely not the way to go. Fudging on captive/cultivated would work, but I wouldn’t encourage using that flag in that way, it is a contentious flag at the best of times! Maybe marking it “ID is as good as it can be” which will drop it out of the Needs ID pool. That flag doesn’t stop anyone continuing to ID the observation.
I’m the opposite with our bioblitzes. I go in days ahead of time, and for the days afterward, to get as many different species from the area as I can, even if they don’t count toward the actual bioblitz. As an “organiser”, I find my day is spent more on interacting with the participants than actually making observations, and the pre-visits will give me an idea of where to head particpants to in order to get as much on the day as we can.
Test data can be good data to somebody, and particularly if it is isolated away from the bioblitz itself by being out of date/time range it won’t muddy the results of what you are working towards
1 Like
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.