Feature request: Equirectangular distance option

[mattkrick]

I'm doing some work on a LOT of points (buffers and intersects and all that fun stuff) & have noticed things were getting slow. When I dug into it, I noticed the destination() uses Haversine, which is great for big, continent-spanning distances, but all my calcs are inside the same city. So, I started replacing all those calcs with the equirectangular algorithm and things are smooth again. I'm not saying it should replace haversine, but it'd be nice for folks to be able to pass in a fast vs. accurate flag as an option for those really big computations. In my case, the difference in accuracy is measured in centimeters. This might be worth considering as more of the package functionality becomes geodesic.

http://jsperf.com/haversine-vs-spherical-law-of-cosines-vs-equirectangula/8 http://www.movable-type.co.uk/scripts/latlong.html

[tmcw]

I'm doing some work on a LOT of points (buffers and intersects and all that fun stuff) & have noticed things were getting slow. When I dug into it, I noticed the destination() uses Haversine, which is great for big, continent-spanning distances, but all my calcs are inside the same city.

Hm, can you give some example code that's not performant? Not to say this isn't a bad feature to build, but it's always best to profile code to identify the bottleneck before optimizing, and it's very likely that the bottleneck is in an operation like buffer() rather than in haversine. Also looks like there are some cheap optimizations to be had in turf-destination as-is.

[mattkrick]

Sure, I'm all for pushing optimizations to the back of queue before the bigger stuff gets sorted out. My current problem is: given a bunch of points, I need to cluster them in as few meeting locations as possible, constrained by a maximum distance of around half a mile for each point. Every approach I take runs in O(n*log(n)) time, but by first creating a hash table of cheap distances that only use 1 cosine, I only have to perform an expensive intersect or within on features I know will return at least 1 value. I'll try to clean up some code for a jsperf this week.

[tcql]

This is related to the suggestion in #244. Seems like the options are

• provide algorithm flags (fast/accurate or specifically named algorithms)
• provide separate modules for various algorithms

If we go down this route, I think it'd be a good idea to let other modules that rely on distance / destination supply a way to switch which mode it uses internally so users can easily customize output / efficiency

[DenisCarriere]

There's no way to make the @turf/distance calculations faster.

For "high performance" distance methods, you should explore @mourner's cheap-ruler.

CC: @mattkrick