Add tags, observation fields, threatened (status), description choice(s) to populate Collection Projects

[bobmcd]

I believe it would be beneficial to allow tags, fields, threatened (status), and description choice(s) for populating projects. I am suggesting expanding the Collection Project filters to include choices that exist in Observation searches.

Users wishing to participate in a particular Project could also add specific known qualifiers such as a tag to an observation. This would cause that observation to be included in the Project as long as other filters (or none) are met.

Pre-existing noted factors such as leucistic, albino, infected, parasite, injured, marine, seaweed, UV, net, rust, gall, red, blue, banded, radio collar, unusual, cryptobiotic/cryptogamic and etc. could be used to build a Collection Project. As well, with this feature build in “and / or / excluding”.

[jdmore]

Hi @bobmcd, I’m thinking maybe you meant “populate” instead of “propagate” in your request title and description?

[apseregin]

I’d like to add licensing for project’s filters to promote open data in biodiversity studies.

[kmfret]

I definitely agree with this feature request! A colleague is looking to create an iNat project for camera trap images, and part of the purpose would be to discover new iNat users with camera traps to add to a British Columbia-Alberta camera trap network. Without the ability to filter by tag it seems like her only option is to create a traditional project and manually find people with camera trap images and request them to add their observations.

[upupa-epops]

I’m not sure I see the value from tags or description choices since that would likely result in including random irrelevant observations, but for sure I’d appreciate being able to use observation fields.
A couple other threads that seem to have requested them (not feature requests though): https://forum.inaturalist.org/t/make-fields-parameters-for-collection-projects-or-turn-some-fields-into-annotations/5724, https://forum.inaturalist.org/t/projects-restricted-by-observation-fields/12856

[tiwane]

I agree that tags and description would not be particularly useful, but fields and conservation status might.

[mich_croc]

I think including “tags” is useful. When I hit the “explore” button, I can filter observations that have a particular word:

In this case, I want to see observations that have the word: “atropello” which means roadkill in Spanish.

Its easier for people that are not very familiar with iNaturalist and want to collaborate with roadkill pictures to just type “atropello” in the notes section when they are uploading their pictures in the app. We will start teaching park rangers how to upload roadkill pictures in iNat and its easier for us to teach with this method. People often get confused when I ask them to include their observations in my traditional project.

What I end up doing is manually search every now and then and include observations with tags into our project.

[davidjcook]

I am looking for similar functionality in collection projects, basically the ability for a user to have certain of their observations be included in a Collection project. I have created a few collection projects that limit the collection to specific user ids. But I don’t really want every observation made be a user, I want the ones that the user wants to include in the collection.

I know this can be done with traditional projects and maybe that’s the best choice, but it seems like it would be helpful to add another query parameter to collection projects that would support this.

[bouteloua]

Do you mean like entering the observation IDs manually as a filter for the Collection project?

[xris]

Here’s my Use Case for Observation Fields in Collection Projects.

It would be valuable to automatically collect all the Interactions supported by a species, without requiring direct Observation of the species itself. For example: I can search for all the Observations where an insect visited the flowers of a specific species of milkweed. But I can’t search for “Interaction->Visited flower of: Asclepias” where “Asclepias” is recognized as a higher-level taxon in the search. I have to specify each milkweed species. If I could create a Collection Project with all these Observations Field+Value combinations, they would be available in one place automatically.

[bobmcd]

To @upupa-epops point regarding tags or description choices, I guess it would be better if there is the ability within the collection project to also be able to remove unsuitable observations.

[pratvmvmbrosvm]

[projectY] = SELECT ALL FROM [projectX] WHERE [custom field]>=a

Allow selection of observations for projectY from projectX by conditions applied to custom fields. For example select observations from https://www.inaturalist.org/projects/big-oaks-of-moscow where (trunk circumference) окружность>=300

generally:
project is a set of observations (table)
observation is a set of fields (row)
so it would be reasonable to select observations for project by any field: whether it genus or location or any tag or custom field value.

[geocookie]

Being able to use tags would be highly valuable with a project I am working on. Because observations are landholdings of private individuals, who do not want their specific location specified, we use obscured, countly-level locations. In doing so, we’ve found that ANY observation made within that county gets included, even when a specific city is set instead of the county. Initially, we thought my personal observations (outside of the project) could be excluded from the project by specifying the city location. But as it is, everything I post is included for the project. SO, I’ve been trying to figure out how to include all observations on private landowners’ properties within various counties without including all of the cities within that county. The best option I can think of is to specify a TAG that is [project name] and that will incude only items tagged for the project, regardless of the city or county level. The current way of including observations in a project is not working well for us because it’s including observations that aren’t really within the parameters fo the project.

[mycotoronto]

In a similar vein, we are requesting iNaturalist to enable projects to be set up to exclude observations with public geoprivacy automatically.

Right now it is not possible to automatically exclude observations with geoprivacy set to public from projects. We would like to set up some projects so that only observations with obscured or private geoprivacy can be added to them.

Rationale: we (the Mycological Society of Toronto) would like to set up some projects to keep track of taxa that our members have observed on forays/walks, but we want to ensure that the exact locations of our forays are not visible to the public. We also do not want to have the administrative burden of checking every submitted observation’s geoprivacy.

[talshaul]

@tiwane Do you know to say if this feature request was accepted please?
And if so, was it preferred?

I see the need in suggesting to add or requiring observation fields for collection projects as very important, for identification of observations, such as fungi, slime molds (by habitat/host for instance), but many others too.
Thank you

[cicadamania]

It blows my mind that this incredibly valuable feature is not available.

1. It would allow us to filter species by diseases or injuries.
   Fish with ulcers. Trees with insect damage. Deer with chronic wasting disease.
2. It would allow us to filter species by parasites.
   Oaks with galls. Wasps with wasp parasites. Magicicada cicadas with Massospora cicadina fungus.
   It’s bad enough when people who are interested in the host identify the observation as the host species, and then folks who are interested in the parasite re-indentify it as the parasite. Maddening.
3. It would allow us to filter species by morphological characteristics.
   If I want a project for piebald deer. I want a project for Magicicada with blue eyes. Bald cardinals.

[anneclewis]

I would like tags included. I am working on a set of projects that have very specific taxonomic criteria and often getting the observations identified at that level can be challenging. If we have people tag their observations with the project name, that would be a way for them to include their observations in the umbrella project without concerns about taxonomic accuracy.

[cthawley]

Even if tags were implemented as a project criterion, I don’t think they would allow adding an observation to an umbrella project - these only collate collection projects. The tag would need to be used as a criterion for a relevant collection project (and from there to the umbrella).

[anneclewis]

Yes, exactly. I didn’t make that clear that I would first set up a collection project with the tag as the filter and then add that project to the umbrella. It was late. I was tired. I didn’t feel like typing out all the steps. I totally shorthanded the process.