I have blogged about turfjs before. Since then, I have been playing around with some large datasets to see how turfjs performs at scale.
At WDT, we have a decent amount of current observations at our disposal. I took the global dataset of observations and created a hexgrid map. As you can see, the hexgrid map loads incredibly slow. In fact, I had to trim the domain down to North & Central America and increase the hexgrid resolution to 1 degree so it would load a bit faster.
Morgan Herlocker (creator of turfjs) tweeted these out around the time I was tinkering with global obs that helped point me into a new direction:
[cont] realtime GIS is largely just an accidental byproduct of rebuilding tools from scratch that have been wrapped in 30 years of cruft— Morgan Herlocker (@morganherlocker) January 20, 2015
Sure, I can shove a shitload of observations into turfjs and process everything in the browser. The GIS analysis will eventually complete and results will show up on the map. However, if this is not performant, what good does the application do? You just have real-time processing in the browser for the sake of having real-time processing in the browser. This is not to say, do not use turfjs in the browser (MapBox has built some great examples). Just be smart with where you use turfjs and ensure the best possible experience for the end user.
Turfjs allows you to take GeoJSON and execute geospatial analysis that were only possible using a PostGIS database or, heaven forbid, ESRI. Turfjs is the open-source key to GIS freedom.
I have re-thought my hexgrid map into this node project. Follow the steps on the readme to take a static version of our global observations and create a beautiful map. If you just want to see the map…you can find it here.