search

orcasound / aifororcas-livesystem

Real-time AI-assisted killer whale notification system (model and moderator portal) :star:
http://orcahello.ai4orcas.net/
MIT License
35 stars 23 forks source link

Upon validation of a candidate, push an "acoustic detection event" to the Acartia.io data cooperative (holding visual and acoustic detections of animal locations across the range of the SRKWs) using the public API and a token specific to the OrcaHello system. #111

Open bdefoy opened 1 year ago

bdefoy commented 1 year ago

Acartia.io

micya commented 1 year ago

This should probably be part of the Notification System.

gaurimadhok commented 1 year ago

Idea for incorporating into notification system:

micya commented 1 year ago

Idea for incorporating into notification system:

  • We could add logic to the SendSubscriberEmail function so that when an item is taken off the srkwfound queue, we make a call to the API in addition to sending out the email OR
  • We could make another queue for sending out to the API (it would be the same as srkwfound queue)
  • We would make a new class similar to the send subscriber email that would make the requests

If it is possible to have multiple functions trigger off of the same queue, you could create a new function that also triggers off the srkwfound queue.

It might not be possible due to the way the trigger works (polling). If so, we should look to replace storage queue with service bus, which should support that functionality.

bdefoy commented 1 year ago

Current implementation

All of the OrcaHello whale detections are added to the srkwfound queue as they are confirmed with a moderator marking "Yes" in the moderator portal:

https://github.com/orcasound/aifororcas-livesystem/blob/cbe95262838fd54f04c3e60a3bdc501041361b34/NotificationSystem/DbToQueue.cs#L32-L34

This queue is used to send out the subscriber emails for example:

https://github.com/orcasound/aifororcas-livesystem/blob/cbe95262838fd54f04c3e60a3bdc501041361b34/NotificationSystem/SendSubscriberEmail.cs#L59

However, the queue could similarly be used to contribute to Acartia. The current implementation uses Queue Storage, which does not easily allow for multiple consumers of the same queue.

Suggested implementation

Using Service Bus is recommended, as it would allow for both the email system and the Acartia contributions to use the same Topic.

The mappings from OrcaHello's CosmosDB metadata documents to the Acartia/SSEMMI Sightings API are being determined and tracked with @scottveirs via this google sheet.

The authentication token that Acartia requires can be stored in app settings.

scottveirs commented 1 year ago

Working on setting up an Acartia.io token for user orcahello@orcasound.net

Once I have it, I'll work on adding it to app settings, @bdefoy ...

micya commented 1 year ago

@TruaShamu to lead this effort for 2023 hackathon.

scottveirs commented 1 month ago

@skanderm A topic we could discuss soon is whether the workflow proposed here still makes sense. We could ponder it first with @paulcretu on Monday, and then maybe circle back to @pastorep and @micowan before the hackathon.

I'm wondering if it would be strategic for the next year to continue public display of machine-based candidates and their moderation within OrcaHello's UI, but POST raw and confirmed candidates to the Orcasound API. Or should we bite the bullet sooner than later and figure out how to merge the machine and human moderation UIs ASAP?

An interim solution could be to merge the machine detection stream with the human detection stream to leverage the logic you've been developing to define candidates and bouts. The Orcasite backend could then handle all interactions with Acartia (i.e. POSTing only temporally or spatially unique presence/absence information) as well as all notifications. Until moderator UIs are unified, the notifications to moderators could just point them to the two different UIs based on the type of detection (human or machine).