wt_dd_summary with boundary returns projects with no species in that area

[see24]

When I was testing out the new feature of being able to download a list of project for a specific location (yay!) (#15) I noticed that for the aoi used in the example, which is in Northern Alberta, several CWS Ontario projects were included in the list that do not have any data in that area. Is the function incorrectly identifying them or is there some metadata from those projects that identifies them as being part of that area?

There is also a row with NA projectID and no name that shows a count of >3600. Is that a real project and why is it's name blank?

Also note that the example in the function docs didn't work, I just needed to delete the extra 5 in the last coordinate.

Finally, it would be great if the documentation had a bit more detail about the format of the boundary parameter and the format of the returned object. Currently it says: "The custom boundary you want to use. Defined as at least a four vertex polygon. Definition can also be a bbox". Something more detailed like: The custom boundary you want to use. Must be a list of at least four longitude and latitude points where the last point is a duplicate of the first, or an object of class "bbox" (as produced by sf::st_bbox).

library(wildrtrax)

wt_auth()
#> Authentication into WildTrax successful.

aoi <- list(
  c(-110.85438, 57.13472),
  c(-114.14364, 54.74858),
  c(-110.69368, 52.34150),
  c(-110.854385, 57.13472)
)
dd <- wt_dd_summary(sensor = 'ARU', species = 'White-throated Sparrow', boundary = aoi)
#> Error in wt_dd_summary(sensor = "ARU", species = "White-throated Sparrow", : Error: Boundary must form a closed polygon.

# fix extra digit in last coord
aoi <- list(
  c(-110.85438, 57.13472),
  c(-114.14364, 54.74858),
  c(-110.69368, 52.34150),
  c(-110.85438, 57.13472)
)

dd <- wt_dd_summary(sensor = 'ARU', species = 'White-throated Sparrow', boundary = aoi)

dd[[1]]
#> # A tibble: 11 × 5
#>    projectId project_name       count species_common_name species_scientific_n…¹
#>        <int> <chr>              <dbl> <chr>               <chr>                 
#>  1       686 "ABMI-Before-Afte…   193 White-throated Spa… ZONOTRICHIA ALBICOLLIS
#>  2       142 "ABMI-Ecosystem H…   280 White-throated Spa… ZONOTRICHIA ALBICOLLIS
#>  3        31 "BU-Community - C…  1232 White-throated Spa… ZONOTRICHIA ALBICOLLIS
#>  4      1070 "CWS-ONT-Ontario …   805 White-throated Spa… ZONOTRICHIA ALBICOLLIS
#>  5        19 "ABMI-Ecosystem H…   291 White-throated Spa… ZONOTRICHIA ALBICOLLIS
#>  6         1 "ABMI-Ecosystem H…   343 White-throated Spa… ZONOTRICHIA ALBICOLLIS
#>  7        34 "ABMI-Ecosystem H…   239 White-throated Spa… ZONOTRICHIA ALBICOLLIS
#>  8      1855 "CWS-ONT-Ontario …   981 White-throated Spa… ZONOTRICHIA ALBICOLLIS
#>  9        33 "ABMI-Ecosystem H…   261 White-throated Spa… ZONOTRICHIA ALBICOLLIS
#> 10       659 "CWS-ONT-Ontario …   528 White-throated Spa… ZONOTRICHIA ALBICOLLIS
#> 11        NA ""                  3644 White-throated Spa… ZONOTRICHIA ALBICOLLIS
#> # ℹ abbreviated name: ¹​species_scientific_name

^{Created on 2024-12-05 with reprex v2.1.1}

[alexmacphail]

@see24 Thanks for sending this! I'll work on a tweak to avoid sending the full bounds in the first tibble when boundary isn't NULL, and look into those documentation enhancements.

Regarding the behavior in the first tibble (NAs), it reflects Data Discover's current design. However, we have some ideas for making that API more accessible

[see24]

Thanks for the quick reply @alexmacphail!
One other documentation change is right now species says "(e.g. 'WTSP')." But you need to use the common english name for it to work.

While I am being greedy, would it be possible for it to work with species set to NULL and return all the projects in the boundary for all species? That would be the most useful thing for my use case! And I don't need the individual locations of surveys because I will need the metadata that goes with them anyway and will use the other download functions for that. So if that is costing time it might be worth having an option to skip that step.
Thanks!

[alexmacphail]

@see24 Yes it will be the common name at the moment so that we can support multiple sensors. Can always join on wt_get_species() if you need a common name for a code. We also had another user suggests we use the full species table instead of the faster API from Data Discover so all species all searchable.

Like I mentioned, we're looking to expand the functionality but as the API is driven in Data Discover, we need to consider changes in WildTrax as well, which is a more complex development task. You can currently use wt_dd_summary(sensor = 'ARU', species = NULL, boundary = aoi) and it should return multiple species, but again within the project limit