Issues with selectors on species photo page

Platform Website
Browser Firefox on Linux

After a lengthy discussion involving procedures for uploading development stages of an organism reared in captivity for the purpose of documenting those stages, I feel that one or two things on the “Browse photos” page of a species should be considered a bug.

Here is the issue:

I upload various images of development stages of a rare species. As discussed I tag these as “Captive”. This results in the unique series of images/observations never ever being shown or used otherwise. It seems that’s all “by design”. Not my design choice, but fine, let’s take that for granted.

In order for the images to get any usage at all (as in site visitors being able to see them), I’m advised to use the “Curation: Edit photos” dialogue on the main species page and push my work forward into the “chosen” images for this species.

Now the images are presented in the set on the main page and maybe also the observation can be found, not sure, let’s stick to the images. My image of eggs is showing bottom right, just left of the “View more” link:

Next I go to the “View more” (/browse_photos) page. At the top, there is a number of selectors for Life Stage, Sex, Quality Grade etc. - all set to “Any” by default.

But when I click “Life Stage” it doesn’t let me select eggs. Seems there would be no images of eggs in the system. But there are. After all, they’re showing on the main page.

To be clear: The Life Stage is set on the observations. Initially the selector only showed “Adult”, not even “Nymph” like it does now, but that was due to the nymphs of the other observations not having the Life Stage set properly. I fixed that meantime.

So, Bug 1 : The selector for Life Stage is not offering eggs, even if these are available.

Bug 2 is the obvious other issue:
The selector for “Quality grade” is set to “Any”, suggesting all available images, no matter what, would be showing. They aren’t - none of my “Captive” development series are showing.

I could understand if you would have this default to something that would exclude “Captive” images from showing, but if it is set to “Any” it is my perception that any available images of the species are being displayed. This is not the case.

Thank you for looking into this and above all respect for building this system the way it works in the first place - AWESOME job!

Cheers, Arp


Even in cases where all life stages appear selecting one doesn’t do anything:

I’m choosing larva stage, it stays on “any” while I never chose it.

1 Like

I agree this appears to be a bug. I went to curate the photos and saw your egg photos, but clicked “see more” and they don’t appear no matter what combinations of filters I chose. I even went and added another photo of a nymph to the selected photos and it does not appear on the more photos page either.

1 Like

The annotations filter is drawing only from verifiable observations, which is why egg doesn’t appear there. Not really a bug as it’s a choice we made, but we plan to make a change that shows all possible values there, which should “fix” this. Should be out in a day or two.

Hi Tony,

thanks for looking into this and very happy to hear that a “fix” is in the makings :o)

Probably not important, but I don’t quite understand the message about “verifiable” and “eggs”.

My suspicion is that the problem is caused by the system doing its utmost to not ever do anything useful with “Captive” observations and hence hicking up here with some images that are “chosen” (someone must have thought they are verifiable) and thus showing them on the main page, but still ignoring them big time anywhere else.

As for “verifiable” and eggs - neither applies. In this case the eggs are verifiable due to the mother being known. Other than that, eggs are often identifiable by themselves. It is quite possible to identify/verify the eggs of many species of Pentatomidae, as long as they have been documented before, which is exactly what I’m trying to do here by uploading them to iNat.

But obviously, by the choices made here due to this being documented in captivity, iNat doesn’t care much for documenting so far unknown development stages this way. That’s the real “problem” I think.

The (seemingly) erratic behaviour of the selectors not selecting things that are obviously present is - in my perception - a result of that basic “intentional” choice.

I’m just saying this, because in my experience “workarounds” for bad initial choices always tend to keep coming back and bite you where it hurts. Often better to rethink the initial design choice that may have a better solution/implementation.

Like I pointed out in the linked long discussion: Captive != captive. The choices made to marginalize “captive” obs are completely understandable when it comes to documenting animals in zoos, cats, dog, kept parrots, cows and garden plants. But IMHO it is a very bad choice to treat “temporary rearing of wild creatures under (sem-)controlled circumstances for research and documenting purposes” the same way. You might want to rethink that bit, as opposed to creating/enabling another workaround… just sayin’ …

Sorry for the rant. Let’s see what gives with the upcoming fix :o)

Thanks again!

Just a heads up that when Tony says ‘verifiable’, it’s nothing to do with identifiability. iNaturalist has a specific definition of ‘verifiable’, i.e. that verifiable observations:

  • have a date
  • are georeferenced
  • have a photo/sound file
  • are not captive/cultivated

Your observation was captive/cultivated, and therefore is not ‘verifiable’ (using verifiable in the specific context of what iNat uses it as)

It also has more to do about trying to hide bad data rather than captive observations specifically. Unfortunately captive observations are wrapped up into the same category as observations created by spambots, copyright infringements, or where the date/location is incorrect, but there’s already strong community support to change that. It’s just a big effort to do so, since it would affect just about every part of the website and apps, and takes some careful thought to rethink through it as well.

Okay, thanks for clearing up that special meaning of a common term mate :o)

@melodi_96 It worked for me on the nymphs that are being shown (“verifiable”)

It’s all locality that I “x”-ed long ago but it’s still there!

Okay, just to be ahead of that - I see a second issue coming up:
I decided not to geotag the “Captive” obs as I didn’t want to falsify the locations where the organism would occur in the wild. Seems to me that would be good practice. Of course one could geotag all these with the location of the original capture, but that would also be “lying”.

This is what I’m getting:

Note that the nymphs from my observations are not showing (as per this bug report).

1 Like