Last week

I spent most of the week with a head-cold or such (I'm not the right kind of doctor to figure that out), and so productivity was a little low.

STAR

Two major steps forward on my implementation of the IUCN's STAR metric this week.

Firstly, my extraction of species from the IUCN Red List database finally aligns with that of the official implementation in R that is built by Chess Ridley at Newcastle University. Chess has been helping me navigate the nuances of the Red List database for the last couple of months as either of us gets time to nudge things forward, and we finally got to parity this week.

Secondly, I took a first pass at implementing the post-AoH stages of the STAR pipeline, (see "STAR Calculation" in the Methods section of the original paper). This involves weighting all the AoH maps individually by the different threats assigned to them in the Red List. In my mind there was going to be more work to this, but it seems to be a simple enough thing to do algorithmically, but slow as you end up throwing a lot of data around (each species AoH * each threat, and then they build per threat class maps from these). I did a rough first cut, and it'll take a little polishing I imagine, but actually finally having a full STAR metric pipeline feels quite within reach.

This then leaves two main todo items left: currently I'm still using an elevation map from an older version of the official STAR pipeline that Chess has subsequently updated to use the more detailed FABDEM elevation map, and I need to automate downloading and patching together that elevation map. I also need to complete my implementation of the Dahal et al validation method which the IUCN use to check their AoHs with. I've implemented the model checking part of that, but not the point data part.

Yirgacheffe

I knew this day would come: I've hit the first time I've wished Yirgacheffe could support convolution matrices. The canonical example of a convolution matrix is a blur effect, where you want the pixel in the result to be an average of both the source pixel and all its neighbours. You express this as a matrix of weights usually, with the pixel of focus in the centre, and then surrounding it the other pixels that are pulled in.

It's not technically that hard, just a little harder to get to work well, and made a little more complex as I want to add both Metal and CUDA support to Yirgacheffe, and my guess is I'll end up with three different APIs I need to make work via one top level API from Yirgacheffe.

No action on this yet beyond making the ticket, and a realisation I need to do it real soon now.

Outreachy

Outreachy kicked off on the Sunday before last, and I have a project listed there that I'm a mentor for, looking for people to work on Claudius, my slightly odd graphics library for building generative art, games, and visualisations in OCaml.

So far there's been a great response, and it's been lovely to see all the eager folk getting stuck in trying to understand both OCaml and Claudius. I already know that if I did this again I'd spend more time getting a webpage set up explaining the lie of the land better, and I'd have better infrastructure in place to keep track of which applicants have made it through the prerequisite hurdles I put in place (thanks to guidance from Ourreachy old-hand Patrick), who has what ticket assigned to them, etc.

Next week

• Compare my STAR results with those by Chess and get that working
• Ponder how to deal with mixed habitat maps for LIFE some more
• Run a simple overview analysis of some plant data from a collaborator
• Read the paper behind the PNV habitat maps we use

Interesting links

I very much enjoyed this write up by Nick on how he made a set of detailed interactive maps for a video-game he's playing. Two reasons in particular, beyond Nick's writing alone:

• Although it's for a video game, the article could just as easily apply to those trying to visualise geospatial datasets. Yes, the specific tooling around the source data will be different, but the questions Nick has to ask along the way will be the same.
• The introduced me to the term "polydisciplinary", which I think is a nice description for a lot of what I do - both currently and just looking back generally over my career. It's rare that I get to be the person with the deep detail knowledge of a thing,, but rather my skill seems to be picking up enough from the fields I'm trying to tie together (aided of course by those who do know more than me) and getting some combined result the individual experts alone wouldn't been able to produce.