inbo / fish-tracking

🐟 Collection of scripts for processing and analysing fish tracking data

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Error in binary mask calculation for Belgian receivernetwork

PieterjanVerhelst opened this issue · comments

Loading the relevant shapefiles (under RIVER SECTION, NETE SECTION, WESTERSCHELDE and BELGIAN PART OF THE NORTH SEA) leads to sf objects. Hence, these need to be converted to sp objects by the following code (line 103):

rivers <- as(rivers, "Spatial")
nete <- as(nete, "Spatial")
westerschelde <- as(westerschelde, "Spatial")
sea <- as(sea, "Spatial")

Finally, these files have to be merged by the gunion() functionality present in the script (line 110).
Note the following warning about 2 different proj4 strings:

> study.area <- gUnion(rivers, nete)
Warning message:
In RGEOSBinTopoFunc(spgeom1, spgeom2, byid, id, drop_lower_td, unaryUnion_if_byid_false,  :
  spgeom1 and spgeom2 have different proj4 strings

When I run the binary mask functionality, I get the following error:

> study.area.binary <- shape.to.binarymask(study.area, nrows, ncols)
 Show Traceback
 
 Rerun with Debug
 Error in x$.self$finalize() : attempt to apply non-function 

Yes, I noticed this as well. Unpleasant. Thanks to notice it. I will give a look immediately.

The warning is not a problem, as the proj4string is identical, but the bug is well a problem 😄

I think the best way is to avoid updating to sf but still working with sp. At the end, we just load shapefiles and we combine them together, which is made based on gUnion a basic function of rgeos which doesn't support sf objects. And loading sf objects to transforming to sp immediately after and getting a bug.

Please, push what you still have to push now as I am going to converting the things back to sp. Thanks.

Ok, thanks! Everything is pushed from my side.

Please pull. Things are in sp again and this issue should not occur anymore.

Done 👍

Still getting the error.

Strange. I checked it once again. I don't get any error for the union of rivers, nete, westerschelde and sea.
Did you maybe forget to skip this line before applying shape.to.binarymask(study.area, nrows, ncols) ? https://github.com/inbo/fish-tracking/blob/distance-frome/scripts/receiver_distance_analysis/prepare_dataset.R#L111

Nope. I also don't get the error at the union() functionality, but when I run the binary mask study.area.binary <- shape.to.binarymask(study.area, nrows, ncols). I just restarted Rstudio, but the same error persists.

I tried it a couple of times and suddenly the code didn't give the error anymore (strange...). However, I now get an error at the control.mask() functionality. Were you able to generate a distance matrix? Because the error I get is about an input file with unequal number of stations:

> control.mask(study.area.binary.extended, locations.receivers)
Error: length(receivers) not equal to length(matched.receivers)
In addition: Warning message:
In .local(x, y, ...) :

Yes, I get same error. But the most important and strange thing is that I get the very same by running from master. How can it be? Did you use this code before? If yes, when did you run it for all Belgian network? Just to get to the moment master got missed up.

That could have been 2 years ago. However, I don't recall we made changes to the code after that. Perhaps a 'packag-update' issue?

Thanks @PieterjanVerhelst. I will try to fix it. A package-update issue? Yes, it can be, but typically you get a warning or a message. I will try to debug and find the place of the bug.

I think I solved it. As you can see in the commit above the problem was that in shape.to.binarymask() a raster is created and we have to take care that it is created with the same CRS of the study.area.
I tested on all Belgian networks and everything works fine again. Let me know.

I still get errors.

When shaping to binary mask, I always get an error running the code the first time. However, for some reason the code does generate the output (study.area.binary) despite the error. Running the code a second time does not give an error anymore.

> study.area.binary <- shape.to.binarymask(study.area, nrows, ncols)

 Error in x$.self$finalize() : attempt to apply non-function 

When calculating the distance matrix, I still get the following error:

> cst.dst.frame <- get.distance.matrix(study.area.binary.extended,
                                      locations.receivers)

 Error in (function (classes, fdef, mtable)  : 
  unable to find an inherited method for function ‘costDistance’ for signature ‘"TransitionLayer", "Spatial", "missing"’ 

Could this have something to do with the control mask? At line 160 documentation tells that when the distance calculation results in an error, the mask characteristics should be checked:

# --------------------------------
# CONTROL MASK
# --------------------------------
# Control the mask characteristics and receiver location inside mask:
# (if an error occurs, this need to be checked before deriving distances again)
control.mask(study.area.binary.extended, locations.receivers)

Update: I also get the error when trying to calculate the distances for the Frome River.

The error calculating the distance matrix should be solved by my last commit: I forgot to change to sp syntax in function get.distance.matrix().
Meanwhile can you let me know which version of R are you using? You can find it in the first part of the output of devtools::session_info().

Ok, Google helps of course if I google the right thing. See here: https://stackoverflow.com/questions/61598340/why-does-rastertopoints-generate-an-error-on-first-call-but-not-second about Error in x$.self$finalize() : attempt to apply non-function.
Debugging, it seems this error occurrs while running this commando within shape.to.binarymask:

study.area.binary <- rasterize(shape.study.area, r, 1., fun = "first", getCover = TRUE)

and as you can read in the link above it comes randomy due to some garbage collection whint Rcpp module which is used while running rasterize. We can ignore this error, even if it is very annoying and I hope it is solved soon by Rcpp. Rcpp is a package which is maintained at fast speed so I am quite sure it will happen fast.

So, based on this info and the last commit I referred to in my last comment, everything should be ok? At least for Belgian network and frome. I go meanwhile further testing gudena and mondego.

Aha, thanks! I am testing; for the Frome River the code works. Now running the code on the Belgian network.

Issue solved 👍! Could calculate distances between receiver stations in Belgium for different resolutions.