dbspitz
commented
5 years ago Thanks Owen,
The decision for the 'dday' field to differ from Julian date was conscious. I appreciate your questions and concerns and have made some notes about clarifying this when I next revise the help documentation and vignette.
Julian date can easily be calculated from the neighboring date field e.g., 'format(date, "%j")'. Often, however, Julian date is not convenient because GPS units are rarely deployed on 1 Jan and thus the beginning of animal years usually start with some Julian date > 1 and then circle back to low Julian date values. (If you're interested more in this sort of problem, try googling "circular statistics".) To fit migrateR's models, we need a time variable that increases monotonically. "dday" stands for 'decimal day' and is calculated as the number of decimal days from the specified "stdt". If no "stdt" is specified, "dday" is calculated from the first location included in the animal-year of data. Thus, if a common "stdt" isn't specified, the same "dday" value in different animal years will indeed refer to different dates.
Consequently, "inconsistent" dday output is not necessarily indicative of a problem with the underlying code. (If, however, you get inconsistent dday values even after specifying a common "stdt" for your animal-years of data, that would be something to look into further. If you find this is the case, please send me a reproducible example and I'd be happy to follow up.) Let me know if you have more questions on this, otherwise I'll close the issue shortly.
Best,
Derek Spitz Postdoc, UCSC Bishop, CA (831) 737-3120 CityOfKitesAndCrows.com http://cityofkitesandcrows.com Wilmers Lab http://wildlife.ucsc.edu // Wittmer Lab http://cms.victoria.ac.nz/sbs/research/ecology-biodiversity-research/ecology-and-conservation-biology
On Fri, Jun 7, 2019 at 1:22 PM Owen notifications@github.com wrote:
Just want to say what a terrific package this is. I have noticed though that the dday output is inconsistent and it's not entirely clear from the manual how this value is derived. Take my output from a recent analysis, the same animal across 3 years; $1_2015` dday date str1 60.33286 2015-05-02 08:59:19 end1 83.32246 2015-05-25 08:44:20 str2 244.45017 2015-11-02 10:48:14 end2 254.72814 2015-11-12 17:28:31
$1_2016 dday date str1 129.3328 2016-05-09 08:59:12 end1 135.2217 2016-05-15 06:19:11 str2 305.2221 2016-11-01 06:19:51 end2 313.2154 2016-11-09 05:10:13
$1_2017 dday date str1 123.6583 2017-05-04 16:47:58 end1 154.3136 2017-06-04 08:31:30 str2 156.5081 2017-06-06 13:11:38 end2 162.3970 2017-06-12 10:31:37`
The dday for str1 in 2015 is ~60, and dday for str1 in 2016 is ~129, despite them only being 7 days apart when comparing the dates. How is dday calculated? The manual for mvmt2dt says they are calculated from stdt, but it also states their purpose is to facilitate comparison across years. Going off the dday, you'd incorrectly interpret the outward migration in 2015 starting ~ 2 months earlier than in 2016, but obviously looking at the dates, that isn't the case.
This is all to say, I think the dday value should just be the date in julian days, converted from date using a method similar to the yday() function in the lubridate package. I think those values might be more consistent and intuitive. Unless I'm missing something obvious about the dday as they are now?
Thanks!
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/dbspitz/migrateR/issues/5?email_source=notifications&email_token=ACTZKUR54UWOECYRSYZVFILPZK7OTA5CNFSM4HV2BIRKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GYKTBAQ, or mute the thread https://github.com/notifications/unsubscribe-auth/ACTZKUX2WPTI2RZZGQTVHW3PZK7OTANCNFSM4HV2BIRA .
orbidder
Just want to say what a terrific package this is. I have noticed though that the dday output is inconsistent and it's not entirely clear from the manual how this value is derived. Take my output from a recent analysis, the same animal across 3 years;
$1_2015` dday date str1 60.33286 2015-05-02 08:59:19 end1 83.32246 2015-05-25 08:44:20 str2 244.45017 2015-11-02 10:48:14 end2 254.72814 2015-11-12 17:28:31$
1_2016dday date str1 129.3328 2016-05-09 08:59:12 end1 135.2217 2016-05-15 06:19:11 str2 305.2221 2016-11-01 06:19:51 end2 313.2154 2016-11-09 05:10:13$
1_2017dday date str1 123.6583 2017-05-04 16:47:58 end1 154.3136 2017-06-04 08:31:30 str2 156.5081 2017-06-06 13:11:38 end2 162.3970 2017-06-12 10:31:37`The dday for str1 in 2015 is ~60, and dday for str1 in 2016 is ~129, despite them only being 7 days apart when comparing the dates. How is dday calculated? The manual for mvmt2dt says they are calculated from stdt, but it also states their purpose is to facilitate comparison across years. Going off the dday, you'd incorrectly interpret the outward migration in 2015 starting ~ 2 months earlier than in 2016, but obviously looking at the dates, that isn't the case.
This is all to say, I think the dday value should just be the date in julian days, converted from date using a method similar to the yday() function in the lubridate package. I think those values might be more consistent and intuitive. Unless I'm missing something obvious about the dday as they are now?
Thanks!