Feature Request: "Saw it!" tag

[mcguirepr89]

I would love to have a thing like the lock icon but for "Saw it!" or "Visually verified" or something along those lines.

This is purely for UI/UX/excitement purposes, but perhaps it would be beneficial to add a table field (or some other database component) for "Verified_Presence" that defaults to 0 and then can be toggled to 1 for those species whose presence has been verified. This gets a little nuanced (or should be) when considering this is a different request from a table field that would indicate "Verified_Detection", i.e., that a human has listened to extraction and has used human reason to determine that the species chosen for the detection was accurate.

I don't know yet whether this makes sense, but I've been thinking about how BirdNET-Pi is somewhat replacing my birding journal insofar as I always have more data on my BirdNET-Pi than I typically collect elsewhere through other means.

This feature would act as a birding tool to supplement the data that is made available on the BirdNET-Pi with something akin to a birder's journal taking note of both the date a species is heard and then the date it is finally seen.

Anywho, I would love thoughts on how this might get implemented; thoughts on how this might be tweaked to be more elegant or functional; thoughts from more experienced birders on how the idea for this tool might more closely resemble a "standard" methodology ~~

My very best to everyone, Patrick

[ehpersonal38]

Hmm, this is interesting - crossing from being purely a sound detection and analysis platform into more of a birders journal territory. Yeah I'm not sure how that would best be done, but I think it's a good idea. Would love to hear others' thoughts too.

And just to be clear, this tag would be applied to the whole species, not just per detection right?

[mcguirepr89]

And just to be clear, this tag would be applied to the whole species, not just per detection right?

I think so :thinking: -- which is not super clear to me how that might work (since I'd imagine to make the database more intuitive it would be necessary to retroactively toggle those values for detections prior to its "visually verified" date). :thinking:

[mcguirepr89]

I could certainly come up with a few ways to implement this without touching the database, but I feel it belongs there. I'm not familiar with how disparate database tables can be logically linked, otherwise that might be a way to get this into the database without it needing to be a field that is attached to each detections table entry? Or maybe it does need to go alongside each detections table entry??

[ehpersonal38]

I could certainly come up with a few ways to implement this without touching the database, but I feel it belongs there. I'm not familiar with how disparate database tables can be logically linked, otherwise that might be a way to get this into the database without it needing to be a field that is attached to each detections table entry? Or maybe it does need to go alongside each detections table entry??

Wow you just made me realize I probably should've put disk_check_exclude in a new database table and not a .txt, totally forgot about that.

"I'm not familiar with how disparate database tables can be logically linked"

Oh, this is the fun part of SQLITE! You would just have a new table called "species" that would live alongside "detections," which would look something like:

Com_Name  | Verified_Presence
----------------------------------
Fish Crow | 1
Blue Jay  | 1
Barn Owl  | 0
...

And thennn when you click a button in the top right (for example) of a detection to verify it's presence, it would call like: UPDATE species SET Verified_Presence = 1 WHERE Com_Name = $this_detection["Com_Name"];

[dtibarra]

Yeah I agree about creating a separate table. I think we could get this to work, it would require a little elbow grease on the backend though. Since labels.txt could change over time, we can do a lazy import - only pull a species once it's detected. This would let us pull Sci_Name and Com_Name out of the detections table and replace it with a row id that can be joined with a species table. Then we can attach metadata to each species. The benefit of this approach is that it opens the door for attaching photos of your species and such.

[ehpersonal38]

Great ideas above ^

But yeah I'm still not sure the best way to implement this visually, I feel like shoving a button in the top right of a detection would feel half-baked and not true to the fact that this is per species, not detection. We almost would need to build BirdNET-Pi out to have more focus on species, ie a profile page for each one (though I recall reading Patrick wasn't keen on this idea :))

Anyways I'm probably over complicating this, so looking forward to what others have to say!

[DD4WH]

That is a wonderful idea ! This feature wish has been raised a few times in some other threads too.

May I suggest something like this:

• we need a new column in the detections database table: "manual ID" --> I am pretty confident that it is important that we can identify which recording is the reference recording for the secure ID of a bird species

• we need three states: "not yet looked at", "false positive", "true positive" --> I think it is important to also mark recordings that I have listened to, but that have been identified as a false detection/false positive

• then there could be a search through the database where only all the true positives are being counted as species IDs and we could display a "correct" / "verified" species list

• re separate species table: yes, we could do that, but we have to keep this separate from the detection table; we need a species ID: that is already there, it is the eBird ID that Stefan uses: however, this changes from time to time to include newest systematics and nomenclature. So not sure how to deal with this . . .

• your own photographs of your birds should not be entered into the species table, but into the detections table. That is, because it could be a misidentification, so maybe you would like to alter your opinion later, and then you would have to change your "reference species table": I would keep a species reference table well separated from detections/photographs etc. and only use the species ID from the reference table in other tables (eg. detection table) --> but that would mean to completely alter the way the detection database is set up and make older databases incompatible . . .

• for a first approach, I would just add one column to the detection table and enter the three states "not yet looked at", "false positive", "true positive"

• for entering "TP" or "FP", one could display two buttons whenever a spectrogram of a recording is displayed OR setup a new mode where I can choose recordings (listed by date or by highest confidence score) and only display these two buttons in this mode.

• The spectrogram / recording view should ALWAY display the "state" of the recording "not yet looked at", "FP" or "TP", so a user can immediately see the state of a recording whenever it is displayed

Thank you all for your immense and awesome input into the software !!!

[CaiusX]

Hi all

I've just pushed a WIP Species Verification idea to the main branch (@mcguirepr89 , roll it back if it doesnt work).

Choose a species on the species page,

The soundfile can be reviewed and marked true/false positive, if false a correct specie can be selected.

My job tomorrow will be to feed this back into the database.

Comments welcomed.

Best AP

[ehpersonal38]

That looks great!! Although that is more of a "Verified_Detection" implementation than a "Verified_Presence," I would think.

[avit]

Hi all, just my 2 cents:

For data that is representative of the detections themselves (false-positive flags), I agree it makes sense to add that directly to the detections table.

your own photographs of your birds should not be entered into the species table, but into the detections table

I would disagree on that, and say that this should be a new table, perhaps called "observations". This could then be related to a particular detection/recording, or just to a species ID.

Such observations are optional, so most of those columns would be recorded as null, and it doesn't make sense to make the table wider for that.

Observations are also not 1:1 with detections (saying "I saw one today" might not mean a particular recording). These can certainly be linked, but it might be helpful to select them independently.