Create a list with other people's observation

Feature Requests
1

I use “flags” to create lists with some of my observations, when I can’t give an ID while being convinced that these observations correspond to the same species. This will help a lot the day someone find an ID. For instance:
https://www.inaturalist.org/observations?q=JPB002&search_on=tags&subview=table&verifiable=any

But this is desirable also when dealing with other people observations. I am reviewing all the observations of some species of the Senna genus and I noticed that many observations in the Senna obtusifolia taxon page do not match, but match with each other. For instance:
https://www.inaturalist.org/observations/12435938

So, I put this comment in ALL of these observations:
image

And when I find one more that match with the others… I have to update all these comments, if I want to keep consistent and complete.

With a list, it would be much easier. (And I wouldn’t mind if other people are allowed to add/remove observations from such a list). A way to implement that would be a “public flag”, so that the present management of flags could be reused, the only change being the right for anyone to add/remove such a “public flag” from any observation (that he/she owns or not).

2

Have you tried using journal posts?

3

No, but I will search what it is and how to do it.

I have just created an experimental project, to see if this could be a solution to the need I expressed:
https://www.inaturalist.org/projects/similar-unidentified-fabaceae

Do you think a project could be a solution to the need I expressed?
More efficient than unrelated identification efforts on unrelated observations?

4

Probably not, partly because some users don’t allow other people to add their observations to traditional style projects.

Here’s where you can make journal posts: https://www.inaturalist.org/journal/jeanphilippeb

The journal post would allow you to edit the links and text in one place, rather than on separate comments.

3 Likes
5

Lists as they currently exist are old, buggy, and taxing on iNat’s infrastructure, and won’t be developed further in their current state, so I think @bouteloua’s suggestion is probably the best way to manage this.