Feature proposal : observations.org upload

[alexbelgium]

Thread used to aggregate ideas on upload to observations.org

[alexbelgium]

[Hiemstra87]

Would be real nice indeed. I personally know at least 3 B-PI users who would use this function on a daily basis. And of course holidays are important too. I'm not a real coder, but i will see were i can chip in, as this is highly interesting to me.

[alexbelgium]

Here is the branch where I'll start some ideas : https://github.com/alexbelgium/BirdNET-Pi/tree/observations_org - however Nachzuster is a much better coder than me so once I'll have something showable I'll give it to him so he can see how we can integrate it in a better way :-)

[alexbelgium]

Mmh I don't understand in their API if the client_id would be the same curl -X POST https://observation.org/api/v1/oauth2/token/ \ -d "client_id=<client_id>&grant_type=password&email=<email>&password=<passsword>" from https://observation.org/api/v1/docs/authentication-oauth2.md

[Hiemstra87]

When we have a bit of understanding of the API i can set something up to discuss with the observation.org devs

[alexbelgium]

easiest would be if they came to the github PR once we have something working ;-)
I'm no dev either but tinkerer enough to put in place something. I'm still working on code logic, then once it's done we can think about pulling them in the PR #142

[YvedD]

Hi !
I'm no coder, but i use observations on a daily basis.
Just thinking about "automated" upload ... would that not be tricky with false positives, where manual upload would leave room to check the recordings and then decide if it has to be uploaded?
Just thinking along.

Otherwise, i would be a great add-on for this Birdnet-Pi fork.

Grtz,
Yves

[alexbelgium]

Yes, probably much better. And easier to implement ;-) let's start with manual and then we'll see if we want to move it further. Already it will be a huge effort. Their API is actually excellent and can also upload the sound. My main issue for the moment is understanding how to authentificate in the API ;-)

[Hiemstra87]

Also, auto upload might be something Observations.org might not like, seen as how many uploads that might cause. Also they tend to moderate all observations (unless very common species). Their data is used in many research papers, so the data must remain somewhat reliable.
These are indeed some of the 'rules' we will discuss with them as well.

[alexbelgium]

Fully agree ; auto upload would not make initial sense. I've started a script in a branch, I'll do a PR to track work there : #142

[alexbelgium]

It's progressing - as far as I can go probably without a client_id to fetch a token.
What we would need as info from observation.org devs at this point :

• We need a client_ID (so I can try the code to fetch tokens)
• Can the same client_ID be used for all birdnet-pi (knowing each user will use his own password/username)
• Can it be distributed on github or is there a way to obscurize it (we can always think of something)

[alexbelgium]

@Hiemstra87 Forgot one thing : the push api script requires a "species id" field, but I don't know how to convert the Scientific Name into a observation.org species id. It seems a dictionary should be needed ?

[Hiemstra87]

Np, i'll discuss option with them on this. If this really needs a dict we could probably get a conversion table from them. But let's see what the requirements are for species identification.

[alexbelgium]

Thanks - all done in theory ; only remaining thing would be to get the "species id" conversion and a "client id" to be able to test an upload. I've added a notes field so that the user can append a custom note when he is posting to observation.org. I've also prepared the set for inaturalist (much more used in anglosaxon countries) but that will be a next step

[alexbelgium]

Dictionary is not needed anymore I've got the species id from the api

[Hiemstra87]

Very productive you've been. Much appreciate

[Hiemstra87]

Sorry for the late reaction here, but here is a reaction from the people at Observation.org:

We can provide you with the client ID. You absolutely must not publish this, so it will need to be recorded as a secret on GH. The client ID is our way of not giving unlimited access to resources (computing capacity).

I have briefly read the discussion. It seems like a good idea to have a short call about functionality and technology.

We also want any observations from BirdNET-PI to be categorized correctly in our system (as an automated observation, not as an observation made by a person in the field).

Please understand that the Dutch holiday period is approaching. In July and August, we are a bit slower than usual.

[alexbelgium]

Hi, thanks for your thoughts! Actually in the way the API works the upload will already be linked to the username and password of the observation.org user to this aim (those 2 infos will have to be encoded in the config of BirdNET pi). However, the client id is more a specific code that the obs.org admin use to identify which system is used to encoding, and they want this hidden

Br

[Hiemstra87]

Reply from Observation:
Due to the holidays they are limited in respons time. Expect a reply from them in the first half of august.

[alexbelgium]

Any movement from their side ?

Critical element will be the complexity of managing the client ID as observations would be sent from the local systems, and by definition in an open-code app everything is visible. Perhaps the php code could query the client ID from github

Or the easiest could be that each user requests a specific client ID, using grant_type=client_credentials

[roelvanderkraan]

Another way of handling secrets in open code is to have an intermediary worker (like a Cloudflare worker) which is a simple backend that handles the communication with observation.org. That way you keep the key out of the open source code and can limit interactions with the API to just the functions that are required for this functionality. Downside is that it adds a dependency on an outside service.

[Hiemstra87]

Just asked again to join the comm channel you set up @alexbelgium
I think this might have escaped their attention (and mine as well, sorry for that)

[alexbelgium]

As a note : it is possible to prefill an upload with https://observation.org/fieldwork/observations/create/?species=111&date=2024-05-12&time=11:11&lat=11&lng=12&notes=birdnet-pi&method=588&advanced=on for example ; the only missing thing is how to upload ! Otherwise we might imagine a new window that opens to upload an observation

Edit : method adapted to "automated recorder"

[Hiemstra87]

Great idea, I'm not sure how uploading would work that way without a download and upload from the user self though.

[alexbelgium]

What I could do is have a script to open the observation page prefilled, and initiate a download of the mp3. The user would therefore then manually upload the mp3.

It would significantly make the workflow easier, while making it long enough that people would not be tempted to upload tons of misidentified noisy recordings online ;)

[Hiemstra87]

I could live with that idea, although it would require a little bit of instruction for users.
And until we hear again from out friends at Observation.org, it might be the only way.

Would recommend to pre fill the method to sound recorder. Might be good to mention when we do have contact with them, they could add Birdnet-PI as a method there. Would make it easy to filter

[alexbelgium]

I would more say "automated recognition" in the sense that birdnet-pi so one declination of a wider field of AI based recognition

But the key idea is that it should be user validated based on the sound : so the method "heard" (or sound recorder) is indeed correct

[Hiemstra87]

True AR should be the best description.

I must admit, sometimes when i'm in doubt on a sound I upload it as well (marked as uncertain) to let the moderators make a final judgement.