Updating IUCN Red List conservation statuses

What is the criterion for deciding on “consensus”?

First, to clarify instructions to curators:

For existing defacto deviations where we are deviating from the default position (e.g. obscured_and_secure) and there’s no documentation regarding why:

  1. if someone opens a flag on the taxon concerning global geoprivacy, you can help by adding a link to the flag to conservation IUCN global conservation status description.

  2. if there’s consensus that we want to keep any flagged defacto deviations and the flags are already linked to in the conservation status description, close the flag

  3. if there’s consensus that we want to remove the deviation, close the flag, remove the link from the conservation status description, and revert the geoprivacy to the default position

If someone opens a flag requesting a deviation from the default position when we are currently not deviating:

  1. if there’s consensus to continue with the default position, close the flag.

  2. if there’s consensus to deviate, close the flag, add a link to the flag from the conservation status in question, alter the conservation status geoprivacy

Second, to answer the question about “consensus” also see here https://www.inaturalist.org/pages/help#geoprivacy the rules are similar to taxonomic deviations, let the flag sit for at least a week or month in the hopes other voices will chime in. Feel free to encourage this by mentioning people. If a few weeks or months have passed and no one else has chimed in go with the lone voice. If there are multiple voices, try to reach consensus. If consensus can’t be reached, decisions are made by iNat staff. To reiterate, this entire thread is about global conservation statuses an doesn’t apply to national statuses that are usually coordinated in collaboration with network node partners (e.g. CONABIO for naturalista.mx)

1 Like

So for clarity:
iNaturalist would prefer conservation status to be managed at national level, even for endemic species where the Global conservation status is the same as the National status. Any deviations should rather be made at national level, where there is a network partner.

Its not that we have a preference. This thread is about a process we’ve laid out for keeping IUCN global statuses up to date without squashing deviations in geoprivacy.

As you mention there’s a separate process for network nodes “batch uploading” national statuses. We don’t have a preference if people engage with these global statuses through the process described here or, within countries that have a network node thats maintaining national conservation statues, with the site admins coordinating the network related national status process.

However, you should be aware that national conservation statuses take precedence over global conservation statuses. So if you’re only concerned with what happens in Canada and engage in this process to make an “open but threatened” deviation for a taxon’s global status, you should be aware that if the iNat Canada site admins add an obscuring status for that taxon in Canada, observations in Canada will be obscured (and vice versa). The network “batch uploading” process needs to be standardized and streamlined but thats for another thread.

Did you mean, “If a taxon had no observations we altered the geoprivacy…” ? Otherwise these two sentences conflict.

1 Like

Fixed thanks

True, this thread is about maintaining global status, but users should be aware that after updates, if there are hundreds of changes (as is the case this weekend just in southern African Proteaceae), then the global option requires flagging, getting consensus and waiting on curators on a species by species basis, versus going via Network nodes by submitting a single spreadsheet of all corrections at the national or regional level.
Curators should also be aware of this and guide users appropriately.
Going via the Networks will speed the process, reduce the number of deviations, flags and links, and cut down on curator’s workloads.

We updated the IUCN Red List Arthropods last night, same drill as with plants. The tables behind the following summary stats can be found here
294 new obscuring statuses
44 obscure and secure
107 open and threatened
19 vestigial obscuring statuses
40 duplicate global statuses

1 Like

FYI when I reviewed the plants yesterday, some of these apparent duplicates were actually national level statuses - like U.S. Endangered Species Act listings - that just hadn’t had their nation specified. All I did with those was add United States for the place, update any outdated URLs, and saved them, rather than delete them. (And BTW I only reviewed a very small number of plants that were familiar to me, so much more review still needed!)


We updated the IUCN Red List Chordata last night, again same drill. The tables behind the following summary stats can be found here
1173 new obscuring statuses
474 obscure and secure
704 open and threatened
123 vestigial obscuring statuses
87 duplicate global statuses

We also updated everything remaining on the IUCN Red List outside of Chordates, Arthropods, and Plants (ie Fungi, Chromista, Mollusca, Nemertina, Annelida, Echinodermata, Cnidaria, Onychophora, Platyhelminthes) The tables behind the following summary stats can be found here
34 new obscuring statuses
24 obscure and secure
63 open and threatened
0 vestigial obscuring statuses
12 duplicate global statuses

This update is now done - to recap, the IUCN Red List usually updates ~2 times a year - its currently on version 2021-2. We uploaded statuses through the backend back in 2011 and haven’t been automatically maintaining them. The main reasons are complications with taxonomy and geoprivacy vs. status issues

This process lays out the taxonomic choices the automatic update uses and sets out clear rules for when the update messes with geoprivacy (when new obscuring statuses are created with <100 obs, or updating when statuses with no observations), summarizes the findings of the update in spreadsheets like those linked above, and provides instructions for curators to help with our desire to have deviations in geoprivacy explained and documented in closed flags linked tot he status description.

I’m pretty confident when the next Red List version comes out (2022-1?) it will be pretty straightforward now to rerun this update process and that we can commit to automatically keeping iNat in sync with these biannual Red List releases. One thing to note, is that this update process is only changing geoprivacy on statuses for taxa with few or no observations. Doing it this way is leading to a lot of undocumented deviations from the default position which may be too much for curators to document in flags (towards our goal of having all these deviations documented in flags). We could tweak the process to be more heavy handed about changing geoprivacy (ie change it unless there’s a flag etc.) but I suspect it might be unpopular to have this script automatically changing geoprivacy more than it is. Curious to hear feedback on how this process could be improved.



I’ve written some code for viewing CS data in tabular form by genus rather than using the web interface one species at a time. Whilst testing it I found that the info is presented differently depending on the queried API endpoint. Is there a rationale behind the two different object fields used to return the CS information?
Depending on the end point used the v1 API returns either partial info ( /v1/taxa?..) or a single and an array of CS objects (v1/taxa/{id}?..).

Just curious :)

The taxa/id endpoint is for screens that show a specific taxon whereas the taxa endpoint is for searching for taxa and returning a set which is used in screens that need different data


The code I referred to previously has now been reviewed, and improved, by @pisum and can found in the standard Github repository here:

page: https://jumear.github.io/stirfry/iNat_taxa_conservation_status.html
code: https://github.com/jumear/stirfry/blob/master/iNat_taxa_conservation_status.html

Instructions for use are provided on the initial page. I hope you find it useful.


1 Like

Re: “we’d like to have only one global conservation status on iNaturalist per taxon and for the IUCN Red List to be the primary source for these global statuses.”

I think that’s great. Even with the caveat that IUCN is outdated/incomplete for many countries/groups, it’s arguably no worse than NatureServe overall (or is it?). Apologies if this is explained above (I couldn’t find it) but in cases where the iNaturalist status is way out of date (e.g., Cooper’s hawk + California, US → “Vulnerable”; see: https://www.inaturalist.org/taxa/5112-Accipiter-cooperii) all of those references to NatureServe will go away, and Cooper’s hawk will be folded into a single IUCN status (Least Concern, 3.1)?

Yes, as mentioned, we’re planing to make a change enforcing only one global status per taxon. This thread is really just about global statuses. Things definitely get more complicated thinking regional statuses.

Any curator can make conservation statuses (global or otherwise), we we can’t really control what regional statuses are being made. Where we have network nodes there is a process for these networks to batch update/create/destroy all statuses within their nation annually. We’re working with nodes to figure out ways to make these plans clearly laid out to the community.

In the US we don’t have a network node, so - like IUCN global statuses - we the iNat staff have been in conversations with NatureServe about whether/how we should take on batch-maintaining NatureServe statuses in the US. We’ve been piloting that with Reptiles and Amphibians as you can read here:
https://forum.inaturalist.org/t/natureserve-conservation-status-pilot-united-states-amphibians-and-reptiles/25901 your questions such whether it would be beneficial to have NS statuses loaded up in iNat or not, are definitely on the table for discussion and great to hear feedback from community members if you want to comment on that thread


There appear to be a number of taxa that have had IUCN statuses added to automatically, and had their coordinates obscured when they have been assessed as Near Threatened (NT).

An example of this (I have seen several) is Eucalyptus tenuiramis, the dominant canopy species in mudstone soils in southeastern Tasmania. Despite its Near Threatened IUCN status, this species is dominant through its range, well conserved in many reserves, and under no threat from poaching or collecting.

Threats listed include population reduction, habitat fragmentation, urbanisation, and so on.

Can we please NOT automatically obscure the coordinates of taxa that are not at least vulnerable or endangered, and that are not under threat specifically from poaching, collecting or trampling, for example? What purpose does it serve?


This has reared its head again, so I’m looking for solutions.

If an IUCN status is overridden to unobscure the coordinates, will this automatically be undone next time there is an update?

If so what is the best way to remedy this? Species like E. tenuiramis are not considered in any way threatened, but since they are so abundant, it would be unlikely one would find a formal assessment to link to to override the IUCN status with a local one.

As described in this post, the update did not alter geoprivacy for existing global IUCN RedList statuses. But when we created new global IUCN RedList statuses when none existed we did set geoprivacy to match the default position indicated by the status (e.g. LC,DD=open, otherwise=obscured). I assume the latter is what you’re noticing?

Our ambition is to have all IUCN RedList global conservation status geoprivacy align with the ‘default position’ indicated by the status unless the status has a link to a flag in the description documenting the why we want geoprivacy to be ‘open despite being threatened’ or ‘obscured despite being secure’. But it will take lots of work by curators to get there - thanks for helping make this happen.

So the way we ran this update script this time around and plan to continue running it at least for the short term is:
For existing statuses, we will not change geoprivacy even when a status updates, but this is creating a big backlog of work that needs to be done by curators to go through theses situations where geoprivacy=default position indicated by status and either change the geoprivacy to the default position or document the ‘deviation’ in a flag.

For new statuses where none exist, we are automatically obscuring taxa, its up to curators to proactively open up these statuses when they want to deviate by changing the geoprivacy and documenting the change in a flag.

Thanks for not just documenting the decision to ‘deviate’ on IUCN global statuses in a flag but also linking to the flag in the status description as I’ve done here https://www.inaturalist.org/taxa/401767-Eucalyptus-tenuiramis

We’d like to get to a place where the update script is updating geoprivacy on existing statuses when there’s no documented deviation but we’re not doing that now and will raise that here before making that change. So Re: E. tenuiramis since there’s an existing status the update script won’t change geoprivacy. And even if we altered the update to start updating geoprivacy, now that it has a link to a flag in the conservation status description the geoprivacy would be left as is.

Lastly, when we ran this update ~Sept 2021, IUCN was in Version 2021-2. Our plan is to run this update when IUCN updates which is usually annually/biannually. I assume that will be whenever they release Version 2022-1

Does that help?


Very much so, thanks @loarie!

There will be a large number of taxa that are not threatened in any way, but that meet IUCN criteria for statuses such as NT due to their endemic status to a small area, relatively small population, etc. Many of these are adequately reserved, or threatened by processes such as habitat fragmentation or land clearing, and not by collecting, trapping, trampling, and so on.

I can see how this works, and I am happy to play along, but I’d like it recorded that, as a curator in an island where many non-threatened taxa are in the IUCN list for reasons mentioned above, this may increase my workload substantially, and I think it is wrong to automatically obscure a taxon that is not specifically threatened by making its location public.


This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.