4.2 KDE with least-squares cross validation bandwidth selection (hlscv)

Both the least squares cross-validation (h_lscv) and bias crossed validation (h_bcv) have been suggested instead of href in attempts to prevent over-smoothing of KDE (Rodgers and Kie 2010). However, (h_lscv) and (h_bcv) have been minimally evaluated on GPS datasets because previous literature only evaluated datasets collected on VHF sampling protocols or simulated data that included at most 1,000 locations. Least-squares cross validation, suggested as the most reliable bandwidth for KDE was considered better than plug-in bandwidth selection (hplug-in; for description see section 3.3) at identifying distributions with tight clumps but risk of failure increases with hlscv when a distribution has a "very tight cluster of points" or very large sample sizes (Gitzen et al. 2006, Pellerin et al. 2008, Walter et al. 2011).

1. Exercise 4.2 - Download and extract zip folder into your preferred location
2. Set working directory to the extracted folder in R under File - Change dir...

3. First we need to load the packages needed for the exercise
   library(adehabitatHR)
   library(sp)

4. Now open the script "HlscvScript.R" and run code directly from the script
   panther <-read.csv("pantherjitter.csv", header=T)
   str(panther)
   loc <- data.frame("x"=panther$X,"y"=panther$Y)
   proj4string <- CRS("+proj=utm +zone=17N +ellps=WGS84")
   pantherspdf <- SpatialPointsDataFrame(loc,panther, proj4string = proj4string)
   plot(pantherspdf, col=pantherspdf$CatID)

5. Now we can run fixed kernel home range with hlscv bandwidth selection
   ## Example of estimation using LSCV
   udbis2 <- kernelUD(pantherspdf[,2], h = "LSCV", hlim = c(10,50),extent=1)
   image(udbis2)
   #Now change h to href for comparison to LSCV later
   ## Compare the estimation with ad hoc and LSCV method
   ## for the smoothing parameter
   cuicui2 <- kernel.area(udbis2)
   cuicui2

6. After running some very important appears for both animals that reads:
   Warning messages:
   1: In .kernelUDs(SpatialPoints(x, proj4string = CRS(as.character(pfs1))), :
   The algorithm did not converge
   within the specified range of hlim: try to increase it
   2: In .kernelUDs(SpatialPoints(x, proj4string = CRS(as.character(pfs1))), :
   The algorithm did not converge
   within the specified range of hlim: try to increase it

7. Note that regardless of change hlim or extent, LSCV will not converge for these animals
   so let's try a trick here. I believe LSCV is a poor estimator with GPS locations being
   too numerous and very close together compared to traditional VHF datasets which
   LSCV were originally evaluated. So lets jitter locations 50 meters from their original
   location and try again.
   panther$jitterX <- jitter(panther$x, factor=50)
   panther$jitterY <- jitter(panther$y, factor=50)
   locjitter <- data.frame("x"=panther$jitterX,"y"=panther$jitterY)
   proj4string <- CRS("+proj=utm +zone=17N +ellps=WGS84")
   jitterspdf <- SpatialPointsDataFrame(locjitter,panther, proj4string = proj4string)
   plot(jitterspdf, col=pantherspdf$id)
   points(pantherspdf, col="blue")
   udbis3 <- kernelUD(jitterspdf[,2], h = "LSCV")#, hlim = c(1, 5),extent=1)
   image(udbis3)
   #Now rerun with jitter factor = 100 then 500 instead of 50 and see what happens?
   cuicui3 <- kernel.area(udbis3) ## LSCV
   cuicui3
   #Now rerun with jitter factor = 500 instead of 100 and see what happens?
   #Combine all estimates for comparison
   iso <- cbind(cuicui2,cuicui3)
   colnames(iso) <- c("FP121_lscv","FP143_lscv","FP121_Jitter","FP143_Jitter")
   iso