From lyons.andy at gmail.com Mon Sep 1 17:59:38 2014 From: lyons.andy at gmail.com (Andy Lyons) Date: Mon, 01 Sep 2014 08:59:38 -0700 Subject: [tlocoh-info] Package_Update_Tlocoh-info Digest, Vol 9, Issue 3 In-Reply-To: References:

Message-ID: <540497EA.5010609@gmail.com> Thanks Anna. Yes it seems if you're using R3.0, the update.packages() will only update to version 1.16, but if you update R to v 3.1 then it will install 1.17. Or you can manually download the latest version of the package as you suggest and install it from the zip file. Best, Andy On 8/31/2014 2:20 PM, Anna Schweiger wrote: > Hi Bruce > > At first the package update >> update.packages(oldPkgs="tlocoh", repos="http://R-Forge.R-project.org") > didn?t work for me either, I think because R kept installing the > binary version (which is 1.16) and not the new version 1.17 which is > source code. > > What did work was to download the .zip folder from > https://r-forge.r-project.org/R/?group_id=1622 > > and then manually install the new version via the Packages menu on the > R console and selecting Install packages from local zip files (see: > http://tlocoh.r-forge.r-project.org/manual_install.html). > > from the console: >> install.packages("~/R/win-library/tlocoh_1.17.zip", repos = NULL) > package ?tlocoh? successfully unpacked and MD5 sums checked >> packageVersion("tlocoh") > [1] ?1.17? > > Maybe this could also solve your problem? Sorry, I?m not the expert > but I learned that often people have the same problems :) > > Best, Anna > > > > > On Wed, 20 Aug 2014 12:00:08 +0200 > tlocoh-info-request at lists.r-forge.r-project.org wrote: >> Send Tlocoh-info mailing list submissions to >> tlocoh-info at lists.r-forge.r-project.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/tlocoh-info >> >> >> or, via email, send a message with subject or body 'help' to >> tlocoh-info-request at lists.r-forge.r-project.org >> >> You can reach the person managing the list at >> tlocoh-info-owner at lists.r-forge.r-project.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Tlocoh-info digest..." >> >> >> Today's Topics: >> >> 1. Unable to update (Bruce Miller) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Tue, 19 Aug 2014 06:40:15 -0400 >> From: Bruce Miller >> To: tlocoh-info at lists.r-forge.r-project.org >> Subject: [tlocoh-info] Unable to update >> Message-ID: <53F3298F.7050407 at gmail.com> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> The "update.packages(oldPkgs="tlocoh", >> repos="http://R-Forge.R-project.org") : >> Is not working >> Warning: unable to access index for repository >> http://R-Forge.R-project.org/bin/windows/contrib/2.15 >> >> >> >> >> >> ------------------------------ >> >> _______________________________________________ >> Tlocoh-info mailing list >> Tlocoh-info at lists.r-forge.r-project.org >> http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/tlocoh-info >> >> >> End of Tlocoh-info Digest, Vol 9, Issue 3 >> ***************************************** > > _______________________________________________ > Tlocoh-info mailing list > Tlocoh-info at lists.r-forge.r-project.org > http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/tlocoh-info -------------- next part -------------- An HTML attachment was scrubbed... URL: From julia.krejci at chello.at Tue Sep 9 15:33:32 2014 From: julia.krejci at chello.at (Julia Krejci) Date: Tue, 9 Sep 2014 15:33:32 +0200 Subject: [tlocoh-info] WG: nsv and mnlv Message-ID: <002601cfcc32$a621fc70$f265f550$@chello.at> Dear tlocoh-list, I've calculated revisitation rate and mean duration of visit for some birds I put GPS-transmitters on. I chose an inter-visit-gap of 12 hours. Maybe I'm already work-blind, but I can't seem to understand the intervals the output gives me. If I display the nsv data, it shows me all points which are considered as consecutive visits to a hull, right? And the colour code shows if the individual was there rarely or often. The intervals of my output are: 1 - 11.6 11.6 - 22.2 22.2 - 32.8 . and so on. So, this means, the individual revisited this hull once or 22 times during one inter-visit-gap? That doesn't seem right. I'm quite sure I'm missing something. It is the same for the mean duration of visit. This means the mean number of records taken of an individual during one visit to the hull, right? But the output gives me 1.30 - 11.56 11.56 - 21.82 and so on up to 52.60. This cannot mean the bird stayed in this hull for 52 records. My GPS interval is one hour and the transmitters are shut down during the night to save energy, so they don't record over night. Maybe I have to keep that in mind? I tried to send you a sample image for illustration but it seems to be too big to be sent. I hope my explanation is understandable. I'd be very grateful for some advice. Thank you and best wishes, Julia -------------- next part -------------- An HTML attachment was scrubbed... URL: From lyons.andy at gmail.com Wed Sep 10 11:55:52 2014 From: lyons.andy at gmail.com (Andy Lyons) Date: Wed, 10 Sep 2014 02:55:52 -0700 Subject: [tlocoh-info] WG: nsv and mnlv In-Reply-To: <002601cfcc32$a621fc70$f265f550$@chello.at> References: <002601cfcc32$a621fc70$f265f550$@chello.at> Message-ID: <54102028.5030409@gmail.com> Hi Julia, Good questions. See some comments below. Also take note: 1) Version 1.17 of the T-LoCoH package has a bug. If you updated to that version, *please update to v1.18* (which was posted today) update.packages(oldPkgs="tlocoh", repos="http://R-Forge.R-project.org") or install.packages("tlocoh", repos = "http://R-Forge.R-project.org") 2) There's a new tip sheet about time-use analysis on the website that you might find useful, see http://tlocoh.r-forge.r-project.org/tips_faqs.html. Other comments below: On 9/9/2014 6:33 AM, Julia Krejci wrote: > > Dear tlocoh-list, > > I've calculated revisitation rate and mean duration of visit for some > birds I put GPS-transmitters on. I chose an inter-visit-gap of 12 > hours. Maybe I'm already work-blind, but I can't seem to understand > the intervals the output gives me. > > If I display the nsv data, it shows me all points which are considered > as consecutive visits to a hull, right? And the colour code shows if > the individual was there rarely or often. The intervals of my output are: > > 1 -- 11.6 > > 11.6 -- 22.2 > > 22.2 -- 32.8 ... and so on. > > So, this means, the individual revisited this hull once or 22 times > during one inter-visit-gap? That doesn't seem right. I'm quite sure > I'm missing something. > nsv stands for number of separate visits, where a visit is defined as not being away from the hull for 12 hours or more. So the hull where nsv=22 doesn't mean the individual visited 22 times during one intervisit gap period, but rather it was there and left for more than 12 hours and then came back, 22 times. nsv values will of course be integer values. Those ranges you show I presume are from the plot legend, which R computes by taking the range of values and chopping it up into equal intervals. But the nsv values themselves should be all integers > It is the same for the mean duration of visit. This means the mean > number of records taken of an individual during one visit to the hull, > right? But the output gives me > > 1.30 -- 11.56 > > 11.56 -- 21.82 and so on up to 52.60. > > This cannot mean the bird stayed in this hull for 52 records. My GPS > interval is one hour and the transmitters are shut down during the > night to save energy, so they don't record over night. Maybe I have to > keep that in mind? > A hull where the mnlv=52 means the animal was within the hull for 52 locations during at least one visit, where a visit again is defined by a period of separation. Hence that "one visit" could theoretically go on for several weeks, if for example the individual left and returned every 11 hours like clockwork, it would all be considered one visit because your inter-visit period is 12 hours. That of course is very unlikely, more probably the hull where mnlv=52 could also contain a bunch of closely spaced locations, perhaps a site where it stayed for a long time or returned at intervals shorter than your ivg value, etc. The tip sheet on the website illustrates how you can investigate the time use metrics of individual hulls. > I tried to send you a sample image for illustrationbut it seems to be > too big to be sent. > > I hope my explanation is understandable. I'd be very grateful for some > advice. > > Thank you and best wishes, > > Julia > > Hope this helps. Let me know what other questions you come across. > > _______________________________________________ > Tlocoh-info mailing list > Tlocoh-info at lists.r-forge.r-project.org > http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/tlocoh-info -------------- next part -------------- An HTML attachment was scrubbed... URL: From lyons.andy at gmail.com Fri Sep 12 05:25:18 2014 From: lyons.andy at gmail.com (Andy Lyons) Date: Thu, 11 Sep 2014 20:25:18 -0700 Subject: [tlocoh-info] WG: nsv and mnlv In-Reply-To: <004301cfcd1a$873e13f0$95ba3bd0$@chello.at> References: <002601cfcc32$a621fc70$f265f550$@chello.at> <54102028.5030409@gmail.com> <004301cfcd1a$873e13f0$95ba3bd0$@chello.at> Message-ID: <5412679E.5020903@gmail.com> Hi Julia, That's a good question, and probably very common as many GPS devices are programmed to go to sleep during certain intervals to save battery power. I don't think the omission of night time locations would cause much of a problem in terms of generating a space use model with T-LoCoH per say, but it would affect what you can claim about your space use model (including the 'homerange' which is a subset or product of a space use model). First thing to note is that when there is no sampling at night, the estimated utilization distribution (isopleths) should be interpreted as the UD of the sampled data, and not necessarily the individual as a whole. Take for example a dataset where the sampling is once an hour during the day, but the GPS unit goes to sleep from 6pm to 6am. Now consider a nest, where the individual was recorded at 6pm, and again at 6am, because it never moved during the night. If the goal is to construct a utilization distribution that represents the overall relative intensity of habitat use, then that nest should really be represented by 13 locations, not 2. So we couldn't claim a space-use model generated from those data represent that, but what we can say more confidently is that the isopleths generated from our data represent how space is used during the day, and that based on our knowledge of the species, the overall pattern of space use will be encompassed in the day time space use (although that may not be true for all species). Whether or not that more conservative claim about our analysis is an issue for the study as a whole depends on the research question. If our research question only requires an outline of the core area (50% isopleth), or the 'homerange' (95% isopleth), and the gradient of use within the core or homerange doesn't really matter, then this is probably not that big of a deal. On the other hand if we're going to feed our UD into another level of analysis where the gradient of the intensity of use matters, for example a parameter estimation for a resource selection function or volume intersection with another UD, then the omission of night time points might be more of a deal breaker. Secondly, if you are generating time-use metrics (nsv and mnlv), you certainly wouldn't want the intervisit gap period to be shorter than the period the device was programmed to go to sleep, otherwise it would appear as though a stationary individual (in the extreme case, dead) was making multiple visits to the nest, when in fact it hadn't moved at all. Does that make sense? If the omission of night time points is a deal-breaker for your analysis, you could potentially model the missing data (i.e., insert fake nightime points) based upon the assumption that the individual didn't move during the night. T-LoCoH doesn't have a function to do this, but it wouldn't be hard to make one. You could also test whether the insertion of fake points is reasonable or not by computing the distance between the last location of each day and the first location of the following day, and see if indeed the distances are actually close to zero. Hope this helps. I invite others to chime in, as these are issues that affect not just T-LoCoH but any kind of space-use modeling method. Andy On 9/10/2014 10:13 AM, Julia Krejci wrote: > > Hi, thank you for your quick answer! > > I have another question, not really related to the one below: My > transmitters were switched off during the night to save energy and > because the birds I investigate are only active during the day. This > creates a gap in the data, which is also visible in the > lxy.plot.freq(my.lxy, deltat.by.date=T) function. I've attached an > example. Does this in any way affect the analysis? What I want is > basically home range and core area, nsv and mnlv. Do I have to account > for that in any way? > > Thank you, > > Best wishes, > > Julia > > *Von:*Andy Lyons [mailto:lyons.andy at gmail.com] > *Gesendet:* Mittwoch, 10. September 2014 11:56 > *An:* Julia Krejci > *Cc:* Tlocoh-info at lists.r-forge.r-project.org > *Betreff:* Re: [tlocoh-info] WG: nsv and mnlv > > Hi Julia, > > Good questions. See some comments below. Also take note: > > 1) Version 1.17 of the T-LoCoH package has a bug. If you updated to > that version, *please update to v1.18* (which was posted today) > > update.packages(oldPkgs="tlocoh", repos="http://R-Forge.R-project.org" > ) > or > install.packages("tlocoh", repos = "http://R-Forge.R-project.org" > ) > > 2) There's a new tip sheet about time-use analysis on the website that > you might find useful, see > http://tlocoh.r-forge.r-project.org/tips_faqs.html. > > Other comments below: > > On 9/9/2014 6:33 AM, Julia Krejci wrote: > > Dear tlocoh-list, > > I've calculated revisitation rate and mean duration of visit for > some birds I put GPS-transmitters on. I chose an inter-visit-gap > of 12 hours. Maybe I'm already work-blind, but I can't seem to > understand the intervals the output gives me. > > If I display the nsv data, it shows me all points which are > considered as consecutive visits to a hull, right? And the colour > code shows if the individual was there rarely or often. The > intervals of my output are: > > 1 -- 11.6 > > 11.6 -- 22.2 > > 22.2 -- 32.8 ... and so on. > > So, this means, the individual revisited this hull once or 22 > times during one inter-visit-gap? That doesn't seem right. I'm > quite sure I'm missing something. > > > nsv stands for number of separate visits, where a visit is defined as > not being away from the hull for 12 hours or more. So the hull where > nsv=22 doesn't mean the individual visited 22 times during one > intervisit gap period, but rather it was there and left for more than > 12 hours and then came back, 22 times. > > nsv values will of course be integer values. Those ranges you show I > presume are from the plot legend, which R computes by taking the range > of values and chopping it up into equal intervals. But the nsv values > themselves should be all integers > > > It is the same for the mean duration of visit. This means the mean > number of records taken of an individual during one visit to the hull, > right? But the output gives me > > 1.30 -- 11.56 > > 11.56 -- 21.82 and so on up to 52.60. > > This cannot mean the bird stayed in this hull for 52 records. My GPS > interval is one hour and the transmitters are shut down during the > night to save energy, so they don't record over night. Maybe I have to > keep that in mind? > > > A hull where the mnlv=52 means the animal was within the hull for 52 > locations during at least one visit, where a visit again is defined by > a period of separation. Hence that "one visit" could theoretically go > on for several weeks, if for example the individual left and returned > every 11 hours like clockwork, it would all be considered one visit > because your inter-visit period is 12 hours. That of course is very > unlikely, more probably the hull where mnlv=52 could also contain a > bunch of closely spaced locations, perhaps a site where it stayed for > a long time or returned at intervals shorter than your ivg value, etc. > The tip sheet on the website illustrates how you can investigate the > time use metrics of individual hulls. > > > I tried to send you a sample image for illustrationbut it seems to be > too big to be sent. > > I hope my explanation is understandable. I'd be very grateful for some > advice. > > Thank you and best wishes, > > Julia > > > Hope this helps. Let me know what other questions you come across. > > > > > _______________________________________________ > Tlocoh-info mailing list > Tlocoh-info at lists.r-forge.r-project.org > http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/tlocoh-info > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajlyons at stanford.edu Sun Sep 21 20:53:48 2014 From: ajlyons at stanford.edu (Andy Lyons) Date: Sun, 21 Sep 2014 11:53:48 -0700 Subject: [tlocoh-info] T-LoCoH Updates In-Reply-To: <53dfce47.c808b40a.3377.139eSMTPIN_ADDED_BROKEN@mx.google.com> References: <53dfce47.c808b40a.3377.139eSMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: <541F1EBC.2070400@stanford.edu> Dear tlocoh list, In the next week or two, I plan on splitting the tlocoh package into a 'core' and 'development' package. The rationale for the split is that the current package contains a number of functions that are not commonly used and need additional documentation and testing, and thus would be better suited for an 'in-progress' development version. This includes functions for hull-based association analysis and working with large datasets. The development package will also serve as a platform for testing and distributing new features, without necessitating everyone to update the entire package. All of the functions described in the tutorial will stay in the 'core' package. Both the core and development packages will continue to be available on R-Forge and supported. The 'core' package will also be submitted to CRAN. Thoughts or suggestions on this split are welcome. And as always, if you have developed any functions or workflows that might be useful to other people, please let me know so we can explore how to share it including potentially including it in the core or development package. Best, Andy -- *Andy Lyons* Office of the Vice Provost for Undergraduate Education 223B Sweet Hall 590 Escondido Mall Stanford University Stanford, CA 94305-3082 ajlyons at stanford.edu http://undergrad.stanford.edu/programs/thinking-matters http://tlocoh.r-forge.r-project.org http://www.novamodeler.com http://www.andylyons.org -------------- next part -------------- An HTML attachment was scrubbed... URL: