Create a list with other people's observation

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

Have you tried using journal posts?

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?

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

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.