mhq_terr_popunits has duplicates of grts_ranking x type, with different point codes for the same location

[florisvdh]

Using current master; d29cd9b.

This issue only considers assessed population units which are assessed at the cell center.

Code to reproduce objects

> mhq_terr_datapath <- file.path(dirname(gitroot), "n2khab-sample-admin/data/mhq_terr/rapportage2025")
> 
> mhq_terr_popunits <-
    read_vc("mhq_terr_popunits", root = mhq_terr_datapath) %>%
    as_tibble()
> 
> mhq_terr_refpoints <-
    read_vc("mhq_terr_refpoints", root = mhq_terr_datapath) %>%
    as_tibble() %>% 
    select(-grts_ranking)
> 
> mhq_terr_assessments <-
    read_vc("mhq_terr_assessments", root = mhq_terr_datapath) %>%
    as_tibble()
> 
> mhq_terr_popunits_cellcenter_assessed <- 
    mhq_terr_popunits %>% 
    filter(str_detect(source, "assessment")) %>% 
    inner_join(
      mhq_terr_refpoints,
      join_by(point_code),
      relationship = "many-to-one",
      unmatched = c("error", "drop")
    ) %>%
    filter(is_centroid)
> 
> mhq_terr_popunits_cellcenter_assessed_duplicate_typeranking <- 
    mhq_terr_popunits_cellcenter_assessed %>% 
    count(grts_ranking, type) %>% 
    filter(n > 1) %>% 
    semi_join(
      mhq_terr_popunits_cellcenter_assessed, 
      .,
      join_by(grts_ranking, type)
    ) %>% 
    arrange(grts_ranking, point_code)

The following object shows duplicates of grts_ranking x type.

> mhq_terr_popunits_cellcenter_assessed_duplicate_typeranking
# A tibble: 8 × 12
  point_code grts_ranking grts_ranking_draw sac   legacy_site type  polygon_id    phab source                     is_centroid       x       y
  <chr>             <dbl>             <dbl> <lgl> <lgl>       <chr> <fct>        <int> <chr>                      <lgl>         <dbl>   <dbl>
1 46006_2           50102             46006 TRUE  FALSE       4030  639351_v2020    90 assessment/habitatmap 2023 TRUE        215934. 201295.
2 50102_1           50102             50102 TRUE  FALSE       4030  639351_v2020    90 assessment/habitatmap 2023 TRUE        215934. 201295.
3 256177_2         501937            256177 TRUE  FALSE       2180  532082_v2023   100 assessment/habitatmap 2023 TRUE         26398. 199982.
4 501937_1         501937            501937 TRUE  FALSE       2180  532082_v2023   100 assessment/habitatmap 2023 TRUE         26398. 199982.
5 304305_2         861361            304305 TRUE  FALSE       2160  532176_v2023    90 assessment/habitatmap 2023 TRUE         25054. 199086 
6 861361_1         861361            861361 TRUE  FALSE       2160  532176_v2023    90 assessment/habitatmap 2023 TRUE         25054. 199086.
7 1630385_2       1892529           1630385 TRUE  FALSE       2180  NA              NA assessment                 TRUE         24254. 196110.
8 1892529_1       1892529           1892529 TRUE  FALSE       2180  NA              NA assessment                 TRUE         24254. 196110.

From the relationship between grts_ranking_draw and grts_ranking, it appears that locations have been replaced by a location that is part of the sample.

@ToonHub is this interpretation right, and if so, is this intended? My current understanding here is that the above replacement rows (where grts_ranking_draw != grts_ranking) can actually be ignored. Should they remain in mhq_terr_popunits?

(Maybe this is about dropping a unit and 'replacing it' with a spare unit from the GRTS series? But then I wouldn't call it a replacement with an actual reference to the original unit.)

I was also confused that these duplicated point locations actually exist as two different point_code values; their code seems to be derived from grts_ranking_draw (8 different addresses above), but in fact these represent only 4 points.

Below object shows that these different point codes relate to (mostly) different assessment dates.

> mhq_terr_assessments %>% 
    semi_join(
      mhq_terr_popunits_cellcenter_assessed_duplicate_typeranking,
      join_by(point_code, type)
    ) %>% 
    arrange(type, assessment_date)
# A tibble: 9 × 10
  assessment_date point_code type  is_present no_habitat assessment_source inaccessible not_measurable change_location db_ref 
  <date>          <chr>      <fct> <lgl>      <lgl>      <chr>             <chr>        <chr>          <lgl>           <chr>  
1 2021-08-26      304305_2   2160  TRUE       FALSE      field assessment  NA           NA             TRUE            304305 
2 2022-09-09      861361_1   2160  TRUE       FALSE      field assessment  NA           NA             FALSE           861361 
3 2022-09-07      256177_2   2180  TRUE       FALSE      field assessment  NA           NA             TRUE            256177 
4 2022-09-08      501937_1   2180  TRUE       FALSE      field assessment  NA           NA             FALSE           501937 
5 2022-09-30      1630385_2  2180  TRUE       FALSE      field assessment  NA           NA             TRUE            1630385
6 2022-09-30      1892529_1  2180  TRUE       FALSE      field assessment  NA           NA             FALSE           1892529
7 2014-09-02      50102_1    4030  TRUE       FALSE      field assessment  NA           NA             FALSE           NA     
8 2019-08-22      46006_2    4030  TRUE       FALSE      field assessment  NA           NA             TRUE            NA     
9 2022-10-13      50102_1    4030  TRUE       FALSE      field assessment  NA           NA             FALSE           NA     

[ToonHub]

This seams to be an error in INBOVEG where the wrong point_code (of a nearby sampling unit) was recorded.

I will have to check this in more detail.

[ToonHub]

I checked it in more detail. These inconsistensies are caused by import errors in INBOVEG, mainly by adding the wrong coordinates to a measurement.

I will correct this?