Should we do a minor version bump for this change?

Nice!

1. Any reasoning behind the position of the field?

2. Please also include the field in https://github.com/inbo/etn/blob/35e70f3d284cb64494313e667f238378564d494b/inst/assets/datapackage.json#L569-L572
    (there is currently no test for this, will create issue for that)

3. Minor version bump sounds good to me

1. Position of field

The documentation for get_acoustic_detections refers to the field definitions (which seem out of date), which refer to the following csv file: https://github.com/inbo/etn/blob/main/inst/assets/etn_fields.csv, in this csv on row 112, there is a field sensor_value_depth, which I suspect depth_in_meters is based on. I'm also reasoning that depth_in_meters is a property of the sensor, not the animal itself. Thus it should follow fields to do with the sensor rather than the animal.

I don't have strong feelings about this, apart that I didn't want to add it to the end. I'm fine with moving it to be grouped with the animal fields such as scientific_name

• Move depth_in_meters to after deploy_longitude

datapackage

• Add test to validate generated data package #275
• Add depth in meters to datapackage.json

Minor version bump

Will do! Thank you for the review

Thanks, I would suggest to have the field immediately after deploy_longitude then, as part of the "location" information.

Will do

datapackage.json is in the wrong order, and is missing 5 more fields from the tags table: length, diameter, weight, floating, and archive_memory.

However, I can't find any examples of these fields in use in the tables I have access to, apart from archive memory in these 3 examples:

[1] "shad_scheldt_dst"
# A tibble: 1 × 5
  length diameter weight floating archive_memory
   <dbl>    <dbl>  <dbl> <chr>    <chr>         
1     NA       NA     NA NA       2 MB          
[2] "FISHINTEL"
# A tibble: 2 × 5
  length diameter weight floating archive_memory
   <dbl>    <dbl>  <dbl> <chr>    <chr>         
1     NA       NA     NA NA       2             
2     NA       NA     NA NA       8             
[3] "2018_EC"
# A tibble: 1 × 5
  length diameter weight floating archive_memory
   <dbl>    <dbl>  <dbl> <chr>    <chr>         
1     NA       NA     NA NA       64 MB  

It seems like archive_memory should be a string, length, diameter and weight seem to be doubles in the returned table, but I have no values to make sure. floating seems to be a string as well.

This didn't come to light earlier because there was no test for this in test-download_acoustic_dataset.R

@PietrH these fields are directly taken from:

The data type for those fields in the database is:

DBI::dbGetQuery(con, "
  SELECT
    pg_typeof(archive_length) AS length,
    pg_typeof(archive_diameter) AS diameter,
    pg_typeof(archive_weight) AS weight,
    pg_typeof(archive_floating) AS floating,
    pg_typeof(device_internal_memory) AS memory
  FROM
    common.tag_device_limited
  LIMIT 1
")

            length         diameter           weight floating            memory
1 double precision double precision double precision  boolean character varying

Looks like dplyr interpreted the boolean as string 🤷‍♂️

So in frictionless:

• length: number
• diameter: number
• weight: number
• floating: boolean
• memory: string

@peterdesmet ready for review

• 1 test failing:

  etn/tests/testthat/test-get_acoustic_detections.R

  Line 19 in 7871292

  expect_identical(nrow(df), length(unique(df$detection_id)))

Sometimes it passes, sometimes it does not. Seems to fail when doing devtools::check() but pass in console or when running tests for a single file. The test itself seems fine, I suspect there might be duplicate detection_id's in the acoustic detentions table.

The object that we test here df could be different every run, because it uses a limit without an order by statement.

• Feel free to fix style issues directly, or just let me know.

Tests pass