turf

I've created a Fog Of War map based on my data export using python in 30 minutes, and decided to build a web app to make it easier for others. Then I spent a whole day trying to figure out how to do it in JS, why it's way slower (https://github.com/Turfjs/turf/issues/2851), how to optimize it (I tried Rust wasm but had too many problems with bindings for geo), then trying to deploy it as a static page but had too many problems with next.js error pages and awaits. This version is still alpha, doesn't collect your data, built with next.js and deployed to cloudflare pages like this https://developers.cloudflare.com/pages/framework-guides/nex...

There's many environments/ecosystems where javascript is used https://en.wikipedia.org/wiki/JavaScript#Uses_outside_Web_pa... One can even use Javascript inside a PostgreSQL database https://pgxn.org/dist/plv8/doc/plv8.html Lastly there's, libraries (data manipulation, algorithms, crypto etc) that work both on frontend and backend (nodejs) which never touch the browser DOM, e.g. https://github.com/Turfjs/turf (http://turfjs.org/docs/)

You can have both. Frameworks like turf (a geospatial analysis library that I authored) have one high level convenience module[1]. You can require('turf'), then run any function from a single object (ie: turf.buffer(), turf.smooth(), etc.). Finer control is often required, however, for all sorts of reasons. For these cases, turf is made up of a collection of sub-modules [2][3], and these can be required individually. I like this approach, since it provides a nice curated framework for users simply wanting to get stuff done quickly, but it also allows for more tuned usage in production environments. It has been a bit more work to maintain (~70 repos, instead of 1), but I have been pleased with the approach so far. [1] https://github.com/Turfjs/turf [2] https://github.com/Turfjs/turf-buffer [3] https://github.com/Turfjs/turf-smooth

turf - geospatial analysis engine written in node.js. The goal is to provide a high level gis scripting api similar to arcpy (but much faster and open source). Anyone interested in maps or stats might find it interesting. https://github.com/morganherlocker/turf If you do not have expertise in computational geometry or geospatial analysis: 1) I would be happy to share whatever knowledge I have and tee up a few easier issues to work on 2) Feature requests, testing, design (hoping to get a dedicated site up and running), and help with docs are also extremely valuable.

About 6 months ago I began writing a library[1] that focuses on topology (much of what was discussed in the article) and geospatial stats. I am by no means a math genius, and my library does nothing too novel from a mathematical perspective. Still, it has been nearly all consuming to grok the immense amount of math that goes into this sort of thing. I can only imagine the creative energy it must have taken to actually design these algorithms from scratch. [1] https://github.com/morganherlocker/turf

As someone who switched from python to node.js, I can give a few reasons. 1. npm is extremely easy to use and has a lot of traction. Language X is going to be a tough sell if it lacks good libraries. 2. node.js devs tend to be religiously adherent to the idea of small modules. While not everyone like this, and some would prefer large frameworks, it is definitely a more flexible model. 3. Speed. I happen to write mapping and geospatial analysis software. Most of the existing solutions are python based. I spent months optimizing one particular algorithm in python and was able to get processing time down to 70 seconds. This was not acceptable for a web app, so I wrote a new geostatistical engine from scratch in node.js. New operating time: 35ms. Sure, there were probably ways to optimize the python code further, but it was never going to tou

90% of the time I see one of these build systems in place, all they are doing is running browserify, then minifying the results. Maybe they have a stylus compilation or a couple things thrown in on top. Either way, most of these tasks would be much less complex in simple bash or node. Does a build script like this really need to be abstracted away?: https://github.com/morganherlocker/turf/blob/master/build And yet there are still requests on this project to switch over to grunt or gulp. I just do not get it in most cases. Big tools when not required create a sort of open source equivalent to "vendor lock in".

I try to put these in my issue tracker instead of the code. Same thing though. Sometimes my issues look like the rambling ravings of a madman talking to himself. https://github.com/morganherlocker/turf/issues/41