You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm using true latlong data in order to run simulation models, in which individuals were collected at a specific location. However, running this simulation rounds the latlong coordinates to the nearest whole integer, causing the entire run to be hundred of miles off of the true start location.
The text was updated successfully, but these errors were encountered:
Hello,
Yes you're right, for performance reasons, the coordinates are internally converted to integers. This is so, in order to increase the speed of the simulations.
Either you convert to projected coordinates before, or you can multiply the geographic coordinates by a constant, say, 100000 - but note that this option will be biased for large spatial extents because the simulations run in an euclidean space.
We will change the documentation in order to make explicit that the package works in projected coordinates, sorry.
EDIT:
Actually this is not exactly as I said above (initially it was but I changed it later); the simulations do run in double precision. Only the starting coordinates are converted to integers, but that's completely unneeded now, that's an unfortunate remain of the past. I'll change this ASAP.
In any case, the same recommendation applies - simulations should be carried out with projected coordinates because the simulation space is euclidean.
I'm using true latlong data in order to run simulation models, in which individuals were collected at a specific location. However, running this simulation rounds the latlong coordinates to the nearest whole integer, causing the entire run to be hundred of miles off of the true start location.
The text was updated successfully, but these errors were encountered: