h_ref and h_opt output when running Point KDE

[Rooby Dooby]

Hello!

I have been generating KDE estimates for some mice I tracked this summer in several different programs, and my estimates are typically very large (like twice the size of the MCP). I've been suspicious that this is a scaling issue because these mice are occupying small areas, and when I play around with different cell sizes in OpenJump HoRAE (and other programs) I see it affects the home range area calculated for a 95% home range estimate, and when I use cell sizes I've used to visualize elk data with (e.g., 25) it just creates a polygon which I assume means it's too big. I know you all are busy and I hope this question is justified. I'm trying to figure out how to know I'm using the best cell size for the analysis so I'm reporting the best area estimates possible. I noticed when I run Point KDE, at the bottom left of the screen in a temporary yellow bar, it reads out "h_ref:some number h_opt: some number". I tried to find in your wonderful pdf document what that means, and did see you say you need to determine a cell size that is relevant to the total space used by an animal. But, I was unable to find anything about what that output translates to (but, might have missed it). If those outputs (which look like bandwidth estimates) are close, does that mean the smoothing is better? Just a shot in the dark.

Thanks for any help you might be able to provide!

[Stefan Steiniger]

Hi Ruby,

thanks for your interest in OJ Horae, and also it was good that you attached your data right away, so I could have a look at it. Great is also to see that you transformed you GPS coordinates already into local (metric) ones, so the analysis can be done straight away. 

Now I am not really sure if my response answers your doubts, however: so cell size is certainly an issue. The default is 25m (i.e. within 25 meters no differences are considered). Looking at the mouse data you send, I saw/measured that the points have an extent of about 130m x 80m. So 25m cell size, given the point distribution is clearly too large. Then I check for Point KDE the pre-calculated h_ref value which is 10.6m (normal kernel). So given that I think the cell size should be at least 3-4 times smaller  than the suggested kernel bandwidth of 10.6 m. So a cell size of 2-3 meters seems best. I decided for a cell size of 2m for your data, and did a first trial with a bandwidth of 11m which resulted in several isolated areas... which seems not so reasonable in the case of mice (but I am not a biologist). So, I decided to check what the ad-hoc method delivers, which looks for the bandwidth at which the home range area splits. Based on that (see screenshot) it appears that a bandwidth of 15m is a good choice (but with a p=95%), to avoid isolated HR areas.

Now, in case of mice and given your time recordings (and there aren't so much points), I decided that it may be good to apply the Line-Based Kernel Density method (perhaps even better could be the Brownian Bridge, or perhaps GeoEllipse could give interesting results too) . So for that I just enumerated the observations according to time from 1 to X, and used it as an input (locid). I attach you this shapefile (zipped) for loading in OpenJUMP (but without the cartographic projection information file). And I also attach an image showing the result of the Line-based Kernel density with 15m bandwidth... 

At the end the bandwidth you chose should be reasonable for the mice... i.e. until where they are able and likely to move within a certain time. (with QGIS and an OpenStreetMap map in the back, I saw that there is a road/highway nearby... I guess this is a barrier for mice, so point-KDE may not be a good option in this case). 

So... I hope you can get some ideas - and perhaps have a look at the ad-hoc approach to define the bandwidth. If you have more doubts, then let me know.

best,

stefan

PS: using Brownian Bridge, though, requires to calculate ideally time differences in seconds, and also takes more time (i.e. for this mouse it was 9 minutes). When I used a standard of 10.000 secs between points, then I just got a circular home range, so the time between points needs to be more reasonable or better: calculated. GeoEllipse also needs to prepare the data to have all necessary inputs.

--
You received this message because you are subscribed to the Google Groups "OpenJUMP HoRAE Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ojhorae-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ojhorae-users/ba07bfb9-9f8a-47fe-b7fe-b42390bd9457o%40googlegroups.com.

[Rooby Dooby]

Hello Sir,

Thank you for the quick and helpful response. You're logic for setting cell size is helpful in giving me some sort of general guidelines so thanks for that! Also, thanks for the suggestions regarding these other methods. I will read a little more about them in the literature and play around with them more in OpenJUMP. Thanks again for your time!

Best,

Ruby

On Wednesday, July 29, 2020 at 5:51:52 AM UTC-7, ssteiniger wrote:

Hi Ruby,

thanks for your interest in OJ Horae, and also it was good that you attached your data right away, so I could have a look at it. Great is also to see that you transformed you GPS coordinates already into local (metric) ones, so the analysis can be done straight away. 

Now I am not really sure if my response answers your doubts, however: so cell size is certainly an issue. The default is 25m (i.e. within 25 meters no differences are considered). Looking at the mouse data you send, I saw/measured that the points have an extent of about 130m x 80m. So 25m cell size, given the point distribution is clearly too large. Then I check for Point KDE the pre-calculated h_ref value which is 10.6m (normal kernel). So given that I think the cell size should be at least 3-4 times smaller  than the suggested kernel bandwidth of 10.6 m. So a cell size of 2-3 meters seems best. I decided for a cell size of 2m for your data, and did a first trial with a bandwidth of 11m which resulted in several isolated areas... which seems not so reasonable in the case of mice (but I am not a biologist). So, I decided to check what the ad-hoc method delivers, which looks for the bandwidth at which the home range area splits. Based on that (see screenshot) it appears that a bandwidth of 15m is a good choice (but with a p=95%), to avoid isolated HR areas.

Now, in case of mice and given your time recordings (and there aren't so much points), I decided that it may be good to apply the Line-Based Kernel Density method (perhaps even better could be the Brownian Bridge, or perhaps GeoEllipse could give interesting results too) . So for that I just enumerated the observations according to time from 1 to X, and used it as an input (locid). I attach you this shapefile (zipped) for loading in OpenJUMP (but without the cartographic projection information file). And I also attach an image showing the result of the Line-based Kernel density with 15m bandwidth... 

At the end the bandwidth you chose should be reasonable for the mice... i.e. until where they are able and likely to move within a certain time. (with QGIS and an OpenStreetMap map in the back, I saw that there is a road/highway nearby... I guess this is a barrier for mice, so point-KDE may not be a good option in this case). 

So... I hope you can get some ideas - and perhaps have a look at the ad-hoc approach to define the bandwidth. If you have more doubts, then let me know.

best,

stefan

PS: using Brownian Bridge, though, requires to calculate ideally time differences in seconds, and also takes more time (i.e. for this mouse it was 9 minutes). When I used a standard of 10.000 secs between points, then I just got a circular home range, so the time between points needs to be more reasonable or better: calculated. GeoEllipse also needs to prepare the data to have all necessary inputs.

On Sat, Jul 25, 2020 at 1:59 PM Rooby Dooby <ruby.l...@gmail.com> wrote:

Hello!

I have been generating KDE estimates for some mice I tracked this summer in several different programs, and my estimates are typically very large (like twice the size of the MCP). I've been suspicious that this is a scaling issue because these mice are occupying small areas, and when I play around with different cell sizes in OpenJump HoRAE (and other programs) I see it affects the home range area calculated for a 95% home range estimate, and when I use cell sizes I've used to visualize elk data with (e.g., 25) it just creates a polygon which I assume means it's too big. I know you all are busy and I hope this question is justified. I'm trying to figure out how to know I'm using the best cell size for the analysis so I'm reporting the best area estimates possible. I noticed when I run Point KDE, at the bottom left of the screen in a temporary yellow bar, it reads out "h_ref:some number h_opt: some number". I tried to find in your wonderful pdf document what that means, and did see you say you need to determine a cell size that is relevant to the total space used by an animal. But, I was unable to find anything about what that output translates to (but, might have missed it). If those outputs (which look like bandwidth estimates) are close, does that mean the smoothing is better? Just a shot in the dark.

Thanks for any help you might be able to provide!

--
You received this message because you are subscribed to the Google Groups "OpenJUMP HoRAE Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ojhora...@googlegroups.com.