I have had to deal with this a few different times and it is very annoying to track down all the locations and individually change them. Sometimes this can be done by simply applying to descendant places, but this doesn’t work very well for large custom places. The latest example of this is Geranium robertianum, discussed here. I have a question and a recommendation that I want to get opinions on.
First, does a listing of introduced get automatically applied to descendant places under any, some, or all cases? Second, since introduced status is indicated by a pink “!” and is applied whenever an observation is in that place (e.g., the species could be listed as introduced only in the US place, but the icon would apply to every observation within the US), can we remove the ability to apply to descendant taxa for introduced species? What kind of ramifications would that have?
Sometimes this can be done by simply applying to descendant places
Won’t this screw up various checklists for the descendant places? A species can be native to a place, but introduced to a descendant place. Whereas the opposite cannot be true: if a species is introduced in a place, it is also introduced in all descendant places. Maybe I’m misunderstanding.
Isn’t the problem here just that someone manually and incorrectly set the status of G. robertianum to introduced in the Newcomb’s place?
I don’t really understand the rest of your post - where do descendant taxa come into this?
If you mean descendant places, I would definitely like to know the definitive answer to that also. If I had to guess, I would imagine it is based on the user- or system-designated “parent” place (whether or not a user’s choice of parent is spatially correct or appropriate) when the place is created, and not on any purely spatial analysis, which I imagine would be pretty resource intensive. I would also like to know definitively whether “standard” and “community” places are treated any differently in this regard.
I can imagine some use cases where it would be very handy to have this ability for introduced status. It would help solve the opposite problem – someone has made a species native in various local areas based on erroneous interpretations, when it is in fact introduced to the entire continent. And @reuvenm is correct, the way we use the terms, if something is introduced to a parent place, it is by definition introduced in all of its child places.
The opposite situation is actually (somewhat) more dangerous – applying native to all descendant places. That needs to be done super-carefully, because something could always be introduced to a local area within a native range, and only people with local knowledge are likely to have that information.
I understand the concerns of applying to all descendent places, but when all descendent places for the US are marked as invasive when the species is native to the country, there’s not a lot than can be done to save the nuance without either starting over or manually editing every place in the US. The latter is not a very practical solution with the vast number of places in use on iNaturalist.
If every iNat place in the US is marked native for a species except for the US place itself and the US place is marked invasive, every observation within the US will be marked invasive. This applies to any place. If I make an observation as native to I-20 Wildlife Preserve, it doesn’t matter if it is marked as invasive for any one of the larger places that includes it including places like: Midland Co, Llano Estacado, West Texas, Texas, Southwestern US States, United States, North America, etc. That’s why this problem is so frustrating.
I agree, when there is a clear disconnect / inconsistency in the data like that, something absolutely needs to be done. The second case is an easy fix. If something is native in any part of a parent place, then it is native to that parent place also, so just change the parent place to native and that should stop overriding any existing native designations at lower levels. I don’t think changing a parent from native to introduced automatically changes all child places to introduced unless a curator intentionally uses that tool – it may just change how the child status is displayed. But correct me if I’m wrong there – not something I want to go experimenting with a lot
The first case is a tougher one, since some of the local introduced designations may have been intentional and accurate, and a blanket re-set to native would wipe out that work by other iNat users. If truly every single child place of a native parent is set to introduced, then yes, that was probably from a previous mis-use of the apply-to-all-child-places capability, and needs to be reversed, though if it were me I would definitely be consulting with other curators first to make sure I wasn’t missing something.
If it is something less than truly every single child place, then I would want to be even more circumspect about applying a blanket change.
And now that I think about the second case more, I do see where it could be helpful to have a curator tool to apply native status “up the chain” to parent places of a native child place.
I agree, I just wish I had encountered a situation like this. I’m actually kind of hoping this get’s enough attention so that these are the problems I run into in the future instead of the other.
This would be extremely helpful, though I’m still not sure it would entirely fix the problem that I’m talking about.
This is the crux of the issue and why I thought it important to bring this up. To be honest, I’m still not convinced that the “apply to descendent places” option is necessary or useful for invasive species considering how this is applied to observations. What I do know is that it has caused some trouble in at least a few taxa (I’m specifically remembering Solanum elaeagnifolium, Euphorbia dentata, Euphorbia davidii, and Geranium robertianum as linked to above). These were a pain to deal with.
To me it would make sense if Apply establishment means to descendant places could only be used (by general curators) for Introduced establishment means. And it should also be accompanied by a big red warning box saying something like, Are you sure that ALL occurrences of cheatgrass (Bromus tectorum) in >>North America (inc. ocean)<< are Introduced? Yes (proceed), No (cancel).
Even better if it could be limited to staff plus a small circle of experienced curators, but I’m afraid that would concentrate the workload in too small a group. But if we also keep the ability to apply Native status to descendant places (like you say, to help correct cases of previous misuse), that would definitely be good to restrict more.
Also, as mentioned earlier, I think it would make sense to add the ability for curators to Apply to Parent Places for Native establishment means, and maybe for Endemic also up to a certain geographic level (GADM 0 or 1?).
So, maybe a couple of different Feature Requests taking shape here…?
@nathantaylor OK, I just noticed in the very small print that pops up with the Apply establishment means to descendant places button, it says “Changing the establishment means to “introduced” will have roughly the same effect, but it won’t change existing values, just fill in blank ones.”
So if I’m reading that right, changing a parent place to Introduced does change child places to Introduced if they were previously blank (=Unknown), but not if they had some other status (Native, Endemic) already set.
Per previous discussion that behavior seems nonsensical to me. Instead, if someone attempts to change the parent of a Native child place to Introduced, it should throw an error and list the child place(s) where currently Native or Endemic. Then, still provide the option to change all descendant places to Introduced, per the restrictions I mentioned above.
Ugh. I was afraid that something like that was happening. Definitely looks like a feature request or two is needed to me. I’m really hoping to get some comments from staff to confirm this. That might help us specify exactly what we’d like to change in a feature request. @tiwane would you mind taking a look at this?
It does, but unless the system is changed, I would personally rather have this ability removed or severely limited (though, if your latest statement is true, it may not even matter). Having a species marked as invasive does functionally apply it down the place hierarchy even if the actual status for the individual places is left unchanged.
Ultimately though, I think the best fix would be as follows:
If a native status is applied to a low rung on the hierarchy and an invasive status is applied at a higher rung, the system should automatically detect the conflict, NOT change the status of places, treat it as an unknown rank to observations (i.e., no pink “!” and no green “N” when viewing thumbnails), and somehow flag it for curation.
I feel this would significantly help the problem. That in addition to stopping the automatic application of status to descendent places, the ability to apply changes up the hierarchy, and make changes only available to curators if it’s not already the case should serve as a good fix. If even only some of these were accomplished, keeping the apply to descendent places option would be much easier to work around even when misapplied.
The reason I’m still worried about applying to descendent places, is that I’m not sure how difficult these are to develop and how long it will be before these changes can be enacted. It kind of worries me that we have the ability to do this and ending up with such a roadblock to correcting the problem. When something is marked as invasive, the first thought that comes to my mind when I see that something is invasive is to eliminate on sight. I’m certainly not the only one and I really don’t like the idea of people ripping out natives based on the misinformation they got here.
Setting a species as “Native” does NOT descend to every downstream locality unless a curator manually chooses to have that establishment mean descend - and this is a tool only available to curators, not general users.
What is displayed on observations for a species that is marked as “native” in a descendant place but “introduced” in an ancestor place?
In what cases, currently, do statuses change when status is changed for an ancestor place and the “Apply to descendent places” option is selected? Can anyone confidently fill in the question marks in this table, for the what the new status will be in the descendent place? AP and DP mean ancestor place and descendent place.
Endemic, but throw error, as the AP should also be marked “endemic”
Unknown
Not listed
New status in DP when AP set to Endemic
Introduced
Native
Endemic
Unknown
Not listed
New status in DP when AP set to Unknown
Introduced
Native
Endemic
Unknown
Not listed
Or at the very least, make it even more obvious to curators what is going to happen when they hit that button. I don’t think there is ever going to be a good solution to undoing cases where it has been pressed mistakenly, other than the admins having some “undo” capability.
Which raises the same question - is the benefit of the option being available really worth the cost of people pressing it mistakenly and screwing up lots of other checklists? To responsibly press this button, I think you first need to be looking at each checklist where it currently has a status. At which point it isn’t really saving any time anyways.
There is actually an additional complication on top of this which is child taxonomy lists. To try and test #1, I made a change on the status of Canada Darner (I switched it back immediately) and set it to introduced in Canada. It is set as native in Ontario.
The results were:
on one of my observations it showed as introduced with Canada set to introduced and Ontario set to native.
on the taxa page however it shows as native to Canada which is coming from the ‘Odonata of Canada’ child list parked under the Canada list
and then in Canada at least we have the additional complication of a child list under Canada called NatureServe Canada list which also purports to cover the whole country and can get out of synch with the Canada list…
So in this particular case there are at least 5 possible checklists it could be referencing - Canada, Ontario, Odonata of Canada, NatureServe Canada and the Nipissing District (which is the county of the observation I was looking at) , with no guarantee of consistency among the 5.
As far as I can tell, this isn’t possible. I was unable to get a different status to show for the same taxon in two checklists for the same place. Checklists can have different subsets of species, but the establishment status is shared for shared species.
Is it possible that you only saw the native status on “Odonata of Canada” after you changed the status back to native?
@cmcheatle I wonder if this happened because it takes time to apply the changes. I have noticed there is often a substantial delay between changing the status and the display being made.
@reuvenm Thanks for the table. I think I’m going to play around with the place itself and come back to this as there are some aspects of your table that I don’t quite understand.
