Let's make some data:
> pts = st_as_sf(data.frame(x=runif(50),y=runif(50)),coords=1:2)
> pts$S = factor(sample(c("Presence","Absence"),nrow(pts),TRUE))
To do join-counts, you need to decide where the joins are. For a grid that's usually the 4- or 8- nearest neighbours (rook or queen ...
Neither LAStools nor lidR understand the CRS properly. But lasinfo displays more information read in the header.
lidR uses the key 3072 in the GeoTiff Projection Keys which is exected to be the epsg code. In your case it contains 32767 which is not a valid epsg code.
sp::CRS(SRS_string = "ESPG:32767")
#> Error in sp::CRS(SRS_string = "ESPG:...
EPSG:4326 is an Earth based projection, so transforming Lunar data to it is not a good idea.
You need to set your project CRS to either your data CRS or another projection designed for Lunar data such as ESRI:104903.
As Vince noted, the raster has the wrong CRS attached to it. Looking at the extents, one can guess that the values are in degrees and not in meters and they actually correspond to the extents of Colorado which is 37 to 41 N and 102 to 109W. The solution is to attach a geographic coordinate system to the raster such as WGS84 (or GRS1980) and then reproject to ...
It looks like Schwarzeck Lo/22/17: https://epsg.io/29377
False Easting should be: 0 and unit: GLM (German Legal Meter).
You can also use meter as unit and use a scale factor of 1/GLM =0.9999864037
Here are the published PROJ.4 settings:
(+proj=tmerc +lat_0=-22 +lon_0=17 +k=1 +x_0=0 +y_0=0 +axis=wsu +ellps=bess_nam +towgs84=616,97,-251,0,0,0,0 +to_meter=1....