Testing for Acacia aneura - mismatch with ALA spatial labs

[dfalster]

Hi folks, I tested the app to see what records of Acacia aneura had been sampled in the vicinity of Naree station, where I recently visited. The app performed beautifully but I was surprsied by the limited number of records reported.

I used the following location (-29.1931632, 145.0549249) and setup:

I tried filtering down to genus Acacia and was very surprised that there was only one location with A aneura sampled nearby.

To compare, I looked at the ALA spatial portal and this showed a bunch more in the area

For example, here are some of the points in the ALA data but missing in infinitylists

• https://biocache.ala.org.au/occurrences/31ca1b12-b2bc-4254-8244-03cddf7a6c66
• https://biocache.ala.org.au/occurrences/13308b4e-d887-4e57-9e0f-21ee4982efbf
• https://biocache.ala.org.au/occurrences/01abfc48-0db8-4956-9dd6-205345b2338e

Any idea why infinitylists is showing fewer points?

Daniel

[wcornwell]

Cool thanks!

The mapping only shows the most recent point for each species within the prescribed polygon, not all the collections, which is what the ALA/AVH portals are good at.

So you should get one point (the most recent) per species in each polygon. It does say in the text that there are 38 total records in that circle from 9 species. Also for completeness, you can get all 38 locations in a csv if you click download.

This behavior is good for some applications and bad for others, but it also avoids competing in functionality with ALA and MoL and other existing tools.

Ideally if you want all Mulga collection locations mapped, ALA is going to be a better tool. If you want a list of the Acacia species at a place to help narrow down your field ID process, then this should be better?

[dfalster]

Ok thanks, but I'm still confused. I did download the records, it shows 5 individuals only for A aneura, and only one of the of the bionet ones (https://biocache.ala.org.au/occurrences/e6d6a7b2-9350-41d1-aeb2-73a716f59e06). here's the file I received:

Fowlers Gap, UNSW-0m-buffer-Plantae-2024-07-01.csv

(BTW - the downloaded file still had the default name fowlers gap, even though I changed the location. )

The mapping only shows the most recent point for each species within the prescribed polygon,

Ok, that wasn't at all obvious in the docs or anywhere, so you might want to provide more guidance on what is returned. I wrongly thought it was clustering all obs in the area

[wcornwell]

Cool!

Thomas wants to add a toggle (#93) to show all records, but I think it may crash the app in certain use cases with too many points, but yeah if we leave it that way we need to label it clearly somewhere. There are thousands of iNat records flooding in for popular species in popular places.

I think that a bunch of the ALA mulgas are getting dropped because they aren't vouchered collections or photographs. eg this one is a bush heritage survey: https://biocache.ala.org.au/occurrences/31ca1b12-b2bc-4254-8244-03cddf7a6c66 . They are all probably reliable in this case--plenty of mulga out there, but there are lots of uncheckable (possible) errors in ALA from consultants who don't document anything.

Circle download naming bug is on the to do list (#85).

[fontikar]

Hey @dfalster thanks for testing it out! I hope the app is somewhat useful to Team Mulga 🌳

Very intriguing question indeed and I have just been on a galah bender with this!!

@wcornwell is correct, the app only keens records that are photographed via iNat or have an associated preserved specimen.

This reprex shows that the basisOfRecord for the records you flagged above are "human observations" and are therefore dropped based on infinitylists' scope criteria:

library(galah)
#> galah: version 2.0.2
#> ℹ Default node set to ALA (ala.org.au).
#> ℹ See all supported GBIF nodes with `show_all(atlases)`.
#> ℹ To change nodes, use e.g. `galah_config(atlas = "GBIF")`.
#> Attaching package: 'galah'
#> 
#> The following object is masked from 'package:stats':
#> 
#>     filter

library(stringr)

galah_config(email = Sys.getenv("ALA_EMAIL"))

a_aneura <- galah_call() |>
  galah_filter(species == "Acacia aneura") |>
  galah_select(recordID,
               species,
               genus,
               family,
               decimalLatitude,
               decimalLongitude,
               coordinateUncertaintyInMeters,
               eventDate,
               datasetName,
               basisOfRecord,
               references,
               institutionCode,
               recordedBy,
               outlierLayerCount,
               isDuplicateOf,
               sounds,
               year,
               basisOfRecord,
               spatiallyValid) |>
  atlas_occurrences()
#> Request for 11028 occurrences placed in queue
#> Current queue length: 1
#> -----
#> Downloading

# Record ID: 31ca1b12-b2bc-4254-8244-03cddf7a6c66
# Record ID: 13308b4e-d887-4e57-9e0f-21ee4982efbf
# Record ID: 01abfc48-0db8-4956-9dd6-205345b2338e
record_ids <- c('31ca1b12-b2bc-4254-8244-03cddf7a6c66',
                '13308b4e-d887-4e57-9e0f-21ee4982efbf',
                '01abfc48-0db8-4956-9dd6-205345b2338e')

a_aneura |> 
  filter(str_detect(recordID, 
           pattern = regex(paste(record_ids,collapse = "|"))
)
) |> 
  select(recordID:species, eventDate,basisOfRecord, starts_with("decimal"),  spatiallyValid)
#> # A tibble: 3 × 7
#>   recordID             species eventDate           basisOfRecord decimalLatitude
#>   <chr>                <chr>   <dttm>              <chr>                   <dbl>
#> 1 01abfc48-0db8-4956-… Acacia… 2008-12-16 00:00:00 HUMAN_OBSERV…           -29.1
#> 2 13308b4e-d887-4e57-… Acacia… 2017-05-07 00:00:00 HUMAN_OBSERV…           -29.2
#> 3 31ca1b12-b2bc-4254-… Acacia… 2015-04-27 00:00:00 HUMAN_OBSERV…           -29.3
#> # ℹ 2 more variables: decimalLongitude <dbl>, spatiallyValid <lgl>

^{Created on 2024-07-02 with reprex v2.1.0}

@tmesaglio perhaps we have this very clearly stated in our FAQs section?

Hope this answers your question @dfalster

[dfalster]

@wcornwell is correct, the app only keens records that are photographed via iNat or have an associated preserved specimen.

Ok, is see it now, in point 8 under the FAQ. I think you need a few dots points on the front page (not just in the FAQ) summarising what the app does I just gave you a possibly typical experience from a user who didn't read all the docs in the other page.

There is very little info available in the app and if you happen to arrive here without reading the paper, there's limited guidance. So you need a way to head of inquiries like this.

[dfalster]

Will close this now as you've answered my queries. Though I suggest an issue arising - better info on what infinitylists does!

[tmesaglio]

Hi all, sorry for no reply today, was at the herbarium all day sorting out specimens

Thanks for the feedback Dan, will aim to add more info up front

And just to triple confirm the above, all the records you expected to be retrieved but weren't are non-vouchered. We wanted to maintain the app such that for every single record it retrieves, the user can always inspect it and be able to assess the evidence/ID for themselves, whether that be a herbarium sheet or a photo set/audio recording.