possible conflict with raster package?

[ulrike.s...@gmail.com]

Dear Chris and team,

I came across some problem when plotting rasters when using raster package and ctmm at the same time.

library(raster)

library(ctmm)

r <- raster(ncol=10, nrow=10)

values(r) <- runif(ncell(r))

plot(r)

Error in as.double(y) : 

  cannot coerce type 'S4' to vector of type 'double'

Doing raster::plot(r) works fine. Also, when I switch the order in which I load ctmm and raster, i.e. first ctmm then raster, no error occurs in the first place.

So somehow the plot method gets confused by ctmm? Is this a general issue or specific to my computer? See below for my version. I have ctmm version 0.3.6.

It's not a big problem, now that I've found a way to get around it. But thought I'd let you know in case others may run into this as well.

Thanks,

Uli

> version

               _                           

platform       x86_64-apple-darwin13.4.0   

arch           x86_64                      

os             darwin13.4.0                

system         x86_64, darwin13.4.0        

status                                     

major          3                           

minor          3.3                         

year           2017                        

month          03                          

day            06                          

svn rev        72310                       

language       R                           

version.string R version 3.3.3 (2017-03-06)

nickname       Another Canoe 

[Christen Fleming]

Hi Uli,

I'm not sure what causes this and I've seen it happen between raster and sp (without ctmm), but it seems to not happen anymore on my development version of ctmm.

As far as I know, the only real compatibility issues coded in the package are that both raster and ctmm want to implement their own extent methods for list objects.

Thanks,
Chris

[ulrike.s...@gmail.com]

Thanks, Chris. 

I'll keep exploring the package. It offers some nice tools. I may show up here again in the future with questions. :-)

Best, Uli

[Virginia Morera Pujol]

I realise this is ages old, but just had the same trouble with ctmm (0.5.10) in R 4.0.2

ctmm conflicts with the plot() function for both sp and raster objects... Not a huge issue since it's solved by specifying the namespace, but just fyi!

El dia diumenge, 16 de juliol de 2017 a les 11:37:13 UTC+2, ulrike.s...@gmail.com va escriure:

[Thomas Collins FAL]

Hi all, 

i am adding my problem here as i believe it is related.... i have found namespace problems, as others have. i have solved some by specifying the namespace. i have an intermittent plotting problem that i am unable to replicate. i have plotted movement on a peninsula (spdf). And, when attempting to overlay the UD output on to the shape of the peninsula (plotted with move:: or sp::), i [sometimes/occasionally/rarely] receive the correct shape! Most often i receive one point at the centre of where the distribution should be -  i receive a red circle if i plot telemetry too (as below). Recently, i realized that it was in fact my UD but it was just that it was absolutely tiny - the scaling was wrong? i have been able to solve the problem by setting 'units = FALSE' in ctmm::plot (i always always specify the namespace). i had thought that the SI unit conversion (between m and km) is not functioning correctly and so keeping everything in metres was best. this method has since fallen apart as, even including this setting, i still receive mostly a tiny version of my UD. maybe a clue is in the errors...

from this code (plotted over the shape):

ctmm::plot(current.3month_telemetry, UD = current.3month_akde, col = rainbow(length(current.3month_telemetry)), level.UD = 0.95, units = F,  lwd.level = 2, add = T)

i receive warnings with my tiny UD:

In doTryCatch(return(expr), name, parentenv, handler) :

  "lwd.level" is not a graphical parameter

...and...

In graphics::segments(x0 = X[j, 1], y0 = Y[j, 1], x1 = last(X[j,  ... :

  "lwd.level" is not a graphical parameter

i receive these warnings in two different runs of similar code. Both indicate to my (rookie) eye as though the ctmm:: function is confusing itself with another plotting function (raster or base graphics?) importantly, if i run without 'add = T', i always get the UD but i am completely unable to have both the UD and the shape.

Could it be that, even with specifying namespace, R will sometimes not recognize the plot.telemetry function? Could it be a problem further back in the analysis due to a long/lat projection? 

i have completely reinstalled  R, Rtools and Rstudio. and tried different combinations of attaching the packages (sp, raster , ctmm, move, any others?). i have all but given up trying to plot the UD from the AKDE object and now only use the contour lines from ctmm::SpatialPolygonsDataFrame.UD. 

if anyone knows how to solve this or what i am doing wrong, i would be so grateful.

best,

Tom

[Ushma]

Hi Tom,

Assuming that your projections and extents for the shapefile and the telemetry objects are the same, I was wondering, if this would help.

lines(ctmm::plot(current.3month_telemetry, UD = current.3month_akde, col = rainbow(length(current.3month_telemetry)), type="l", level.UD = 0.95, units = F,  lwd.level = 2, add = T))

or you could use points insteads of lines and remove the type="l" argument if you want to plot is as SpatialPoints

Regards,

Ushma.

[Ushma]

Actually, you might not even need the lines () function, you should probably just add type="l" in the ctmm::plot function and it could work?

That should probably help with your  "lwd.level" is not a graphical parameter" error.

I am not sure if it solves your scaling problem.

Regards,

Ushma.

[Thomas Collins FAL]

Hi Ushma, 

thanks so much for your suggestion! unfortunately, it does not solve my problem. i belieive this is because the code you provided doesn't include the spdf. it does work/run in that it adds an object to an existing plot but this is still a tiny point!! Ushma, yes, I found that i didn't receive the warning this time - not sure if this is because of the code though  (it is intermittent and i have been unable to see any pattern). It doesn't solve my problem as, intermittently, i receive the warnings. Importantly, the reason i included those warnings was not because i was worried about them, or trying to get rid of them, but more so to highlight that it indicates that there may be some discrepancy between functions that are being called for and the possibility of conflcit. my thinking was, as 'lwd.level' is part of ctmm::plot, so it goes that ctmm::plot should recognize it too - this is not occurring consistently in my case. what is occurring consistently is a scale problem (aka my tiny plot!!!) and i assume they are somehow connected. yes, all my extents and projections are the same - they are projected to the AKDE's projection. let me if you have any other ideas i am so grateful for the help (and super quick too)!

If 'lwd.level' is not recognized, could it also be that 'units =F' is ignored too? How can ensure that R chooses ctmm to plot the UD? 

best and thanks again ! 

T

best,

Tom

[Christen Fleming]

Hi Tom,

I will check over the units scaling code in plot.telemetry and plot.UD, because it sounds like units=FALSE is being ignored in plot.UD. I will also check over how lwd.level is being passed. I need a couple of days, though, because I'm in the middle of re-coding a bunch of location-error stuff in the package to help with tiny error calibration datasets.

Actually, if you can email me some minimal working code (script, an animal, and shapefile), then I'd like to add a spdf argument to plot.telemetry and plot.UD, to make this kind of plotting easier (automating the projection and units of the shapefile).

Best,

Chris

[Thomas Collins FAL]

brilliant!

thanks so much for that! an spdf argument would work well for my needs.
and sorry to give you work!

ill email that over.

best,

Tom 

[Christen Fleming]

Hi Tom,

I finished my updates and tested your example. Everything is working fine for me when running the development version of the package

devtools::install_github("ctmm-initiative/ctmm")

I have not yet had time to implement an spdf argument, but will.

Best,

Chris

[Nanette Bragin]

Hi Tom,

Not sure this will help and I am not good at R.  But, in a webinar series on plotting by Andy Lyons for SCGIS, I took these notes of R code that sets your preference on which package to use for your plot functions.  This alleviates R choosing the wrong package that has the same name for a function.

Duplicate Function Names

Occasionally two or more packages will have a function with the same name.

R will use whichever one was loaded first.

Best practice: use the package name and the :: reference to specify which package a function is from.

x <- sp::over()

x <- grDevices::over()

 

y <- raster::select()

y <- dplyr::select()

library(conflicted)

 

# Set conflict preference

conflict_prefer("filter", "dplyr")

conflict_prefer("count", "dplyr")

conflict_prefer("select", "dplyr")

 

# From here on out, anytime we call select() or filter(), R will

# always use the dplyr version.

--
You received this message because you are subscribed to the Google Groups "ctmm R user group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ctmm-user+...@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/ctmm-user/032b6550-3963-48c2-9cc1-534c440ab406n%40googlegroups.com

.

[Thomas Collins FAL]

Hi Nanette,

thanks so much for that! it seems I haven't a problem with this for a while now. i'll continue to specify the package as you say.

very best,

Tom