Incorrect length of return from get.checkerboard() ?

[PopGen33]

Hello,

I've run into a small issue with get.checkerboard(). The output that it generates for $occs.grp is 4 rows longer than the input. I also tried this with a single aggregation factor and got the same result.

> nrow(occ_data_summer)

[1] 35

> nrow(pseudo_data_summer_buffer500)

[1] 10000

> checkerboard_summer <- get.checkerboard(occs = occ_data_summer %>% select(x,y),
+                                         bg = pseudo_data_summer_buffer500 %>% select(x,y),
+                                         envs = explanatory_vars,
+                                         aggregation.factor = c(10,10))

Generating hierarchical checkerboard partitions...

> length(checkerboard_summer$occs.grp)

[1] 39

> length(checkerboard_summer$bg.grp)

[1] 10000

> nrow(occ_data_summer %>% select(x,y))

[1] 35

For context, the 10000 background points are drawn from within 500km of the occurrence points using the predicts::backgroundSample() function and a raster representing a 500km buffer around the occurrences. The 'explanatory_vars' are BioClim rasters at 30 second resolution from CHELSA. The partitioning of the background points works as expected; it's the partitioning o the occurrences themselves that seems to be the problem.

For further evaluation, here are evalplot.grps() plots to visualize the groups:
Background:

Occurences (to deal with the output from get.checkerboard() being the wrong length; I set grp = checkerboard_summer$occs.grp[1:nrow(occ_data_summer)]) ):

So, any insight into why get.checkerboard() is generating the extra rows? Is just ignoring the 4 extra rows (like for the plot above) an acceptable solution?

Thank you for your time. Any help is appreciated.

[bobmuscarella]

We have also encountered this. I have tracked it down to the following part of the get.checkerboard function that was updated since v 2.0.5.

occs.r.m <- merge(occs.r, occs.rn, by = c("x", "y"))

and

bg.r.m <- merge(bg.r, bg.rn, by = c("x", "y"))

If you have duplicate points (exactly equal x and y coords, and same partition group) but they have (obviously) different row numbers, this returns more rows.

Hope that helps isolate and fix the issue!

[jamiemkass]

Thanks for addressing this, Bob, and sorry for the late reply, @PopGen33. I just added a quick fix (bbfaf8d) to the code, so please test it out. It just forces removal of duplicate points. I don't think we typically want them anyway in the analysis, so I hope it's not an issue that it's so forceful.