Reconstruction files

[LewisAJones]

Reconstruction files

[LewisAJones]

I have produced reconstruction files at ~100 km x 100 km for all models. However, when testing the function with the new files, I realised there is a dramatic loss in efficiency. Previously it took around 6 seconds to rotate 5270 occurrence points (tetrapod dataset), but with the new files it takes over 1 minute. This is because distance now needs to be calculated between occurrence points and the reconstruction file coordinates. Previously, closest values in longitude and latitude could just be matched because numerically they were spaced evenly (even if the spatial grid itself is not even). Given this, I think it is best to still use the 1 x 1 degree grids. The only issue here is that higher latitudinal points will be rotated with greater spatial resolution than lower latitudinal points. Any thoughts @KEichenseer or @Buffan3369?

[willgearty]

Instead of calculating the pairwise distance (O(n^2ish)?), could you have the decimal lat/long range for each grid cell, then use cut on the lat/lng of the points (O(2n)?), then merge/match the points to the grid cells based on those cut values (not sure on the O here)?

[LewisAJones]

The problem here is that cells are not rectangular, they are hexagonal. So I don't think that is a viable solution if I am understanding your proposal correctly. In order to use the hexagonal equal-area grids, the solution would be to bring in the actual shapefile and bin spatially to identify the cells. The sf package would allow us to do this. I can explore this option. Considering we are already using the sf and h3jsr package in other functions, this won't be an issue with additional dependencies.

[willgearty]

Ah, yep, I thought they were rectangles, my proposal would not work for hexagons. But yeah, there should be a much easier way to do it using sf. Let me know if you need help, I just rewrote a bunch of my own code from sp functions to sf functions.