Error for small dist argument about polylinesplitter HOT 7 CLOSED

Thanks, it is not a large shape file. I've posted it here: [https://github.com/jschap1/WSEw/tree/master/riv_example]

It works with dist = 11, and also at dist = 1. Oddly, it also worked when I tried with dist = 10 again, but then it didn't work at dist = 2, 3, or 5.

from polylinesplitter.

Interesting... I will look into this in a bit. I havn't seen that behavior before. Just the occasional off-by-one error you described.

from polylinesplitter.

Thank you for pointing this out, BTW.

from polylinesplitter.

library(parallel)
cl <- makeCluster(detectCores())
clusterEvalQ(cl, {
    library(rgdal)
    source("./polylineSplitter.r")
    riv <- readOGR("./data/riv_example/", "riv")
})

tests <- parLapply(cl, 1:200, function(x){
    tryCatch(splitLines(spobj = riv, dist = x),
             error = function(e) return(as.character(x)))})

stopCluster(cl)

which(sapply(tests, function(x) class(x) == "character"))

This returns:
[1] 2 3 5 6 8 9 12 15 18

These are the distances that are causing errors from 1:200. I will debug this more over the next day or so. I haven't looked at this repo in a while. It appears that someone made a pull request in March, not sure how I missed that. They might have fixed this issue in that request. I'm going to get some dinner now.

from polylinesplitter.

OK! I found the bug and I have a fix, albeit I don't fully understand what is going on with the bug. I think it's related to floating point error, but I need to investigate further to be sure. Essentially the vertices of the new line segments that are generated occasionally drop the last coordinate off the sequence, especially at smaller distance intervals. The fix is to simply add back the coordinates for the end of the segment when this happens.

When I stop the function when xnew and ynew are not equal I can see the xmod and ymod, although are supposed to be precise multiples of the sequence, they are occasionally not. That is more likely to happen when the split distances are smaller. To fix this I just add back the expected end of the sequence to the new vector.

There is an old pull request for this repo that wraps this function up into a package from March that I missed. I want to merge that first, then add this bug fix. I am going to address this tomorrow when I get a chance to review and test the pull request. Here is the patch for now:

xnew <- seq(xydf$x[i-1] - xremsub, xydf$x[i-1] + (xmod * segs), by = xmod)[-1]
ynew <- seq(xydf$y[i-1] - yremsub, xydf$y[i-1] + (ymod * segs), by = ymod)[-1]
## patch is here ---v
if(length(xnew) != length(ynew)){
    if(abs(length(xnew) - length(ynew)) > 1) stop("Error found in new sequence. Code needs to be reviewed...")
    if(length(xnew) < length(ynew)){
        xnew <- c(xnew, xydf$x[i-1] + (xmod * segs))
    } else {
        ynew <- c(ynew, xydf$y[i-1] + (ymod * segs))
    }
}
## patch is here --^
rem <- sqrt((xydf$x[i] - tail(xnew,1))^2 + (xydf$y[i] - tail(ynew,1))^2)
x <- c(x, xnew)

There might be a more elegant way to do this also. Using seq this way has bit me before.

from polylinesplitter.

This bug had been patched! You can now install the package straight from github and use the tool without sourcing the script, thanks to a pull request that was made in March.

Thanks for you interest and help here.

from polylinesplitter.

Thanks a lot!

from polylinesplitter.