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

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ā€.

Hi @bobmcd, Iā€™m thinking maybe you meant ā€œpopulateā€ instead of ā€œpropagateā€ in your request title and description?

2 Likes

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

4 Likes

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.

2 Likes

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

2 Likes

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

4 Likes

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.

5 Likes

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.

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

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.

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.

[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.

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.

1 Like

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.

1 Like

@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 :pray:t5: