Turf – A modular GIS engine written in JavaScript | Hacker News Reader

Turf – A modular GIS engine written in JavaScript

turfjs.org

137 pointsuptown22 comments

Re-posting what I said in r/javascript. I'm digging the modularity.

My only complaint would be that some of those modules do not really need to be "turf" specific. For example, "turf-is-clockwise" would be more Unixy if it was just "is-clockwise" or "is-polygon-clockwise". This would help improve discoverability and make them nicer to use alongside other generic npm modules, like:

simplify-path, delaunay-triangulate, triangulate-contours, chaikin-smooth, convex-hull

etc.

I also think the turf modules would appeal to other uses than just GIS. They are generic enough to be useful in games, interactive apps, etc. :)

Has anyone tested this with a ~500 MB dataset ? Say the parcels of a city. How does it perform ?

Here are some rough benchmarks[1]

Performance will vary widely depending on which functions you are calling and characteristics of the data. Some types of analysis will quickly process 500 MB, and others you will probably want to use some sort of indexing strategy.

For pure javascript indexers, check out rbush[2] (R-Tree indexes) and tile-cover[3] (map tile indexes), both of which are as fast or faster than the C++ indexers used in most mainstream spatial databases.

Expect these benchmarks to improve in the coming months as we push the limits with new, faster algorithms as well.

[1] https://gist.github.com/morganherlocker/a9041f2491c63b541cb2

[2] https://github.com/mourner/rbush

[3] https://github.com/mapbox/tile-cover

Thanks ! I'll have a deeper look at all that later. I was wondering if you were using r-tree indexes (I haven't looked at the code yet). Rbush certainly looks interesting.

It is sad that substantial part of this lib assumes flat Earth; it will work well on a city scale, but one has to expect spectacular fails on a longer distances and near the poles :/

Distance calculations account for this and geodesic buffer support is on the way. This is close to top of my priority list right now.

All examples currently failing, getting an error page instead of turf.min.js:

"This request has been blacklisted for sending too much traffic to rawgit.com. Please contact the owner of the site that sent you here and ask them to use cdn.rawgit.com instead, which has no traffic limit."

Thanks for the heads up! Everything is back up now.

I'd just started learning about what's offered in Geotools.JS (https://github.com/jillesvangurp/geotools-js). This looks way way more comprehensive; very cool.

Have you thought about porting it to Meteor's Atmosphere (https://atmospherejs.com/i/publishing)? You'd only need to set up a Meteor Developer account and then create a Meteor package file and export the library for Meteor's usage (afaik).

I'm curious if this supports Leaflet too?

Here's the Mapbox blog post about it, where they confirm easy integration with Leaflet:

https://www.mapbox.com/blog/turf-gis-for-web-maps/

> Have you thought about porting it to Meteor's Atmosphere

We currently support npm, bower, and a CDN build on Mapbox. Additional package managers can be added if there is a community need.

> I'm curious if this supports Leaflet too?

Turf is not tied to any visualization framework. GeoJSON in - GeoJSON out; display it where you want (or don't display it at all).

Found this blog visualizing turfjs modules with mapbox.js (http://rousseau.io/turf-mapboxjs/)

Does anyone know how widely this is being used in production? Turf looks pretty good and I've had my eye on it for a while, but I'm not willing to get too attached to it if it has performance issues, and I'd like to hear about other people's experiences.

wow, that looks beautiful! i used GIS pretty extensively when I worked in the public sector. I've sort of stopped doing any kind of mapping work, but this makes me want to find a project!

I wish I had a use for this because the documentation is beautiful.

In the demo wombats code, shouldn't 'miles' be in a constant somewhere? That seem messy.

The source has awareness of miles, kilometers, radians, and degrees as units of measure. Passing it in the demo is just specifying which one you're expecting results to use in its calculations.

Does it just punt on miles<->longitude? I looked at the code some and don't see where it would ever deal with projections.

(jsts mentions coordinates systems in comments, but I don't where it ever does anything about them)

Wgs84 data is assumed for distance calculations. If you need to convert your data on the fly, I typically recommend proj4js.

Maybe you could document that more explicitly. Basically defining the scope of the project and where to look for complementary tools like proj4js and rbush for instance.

I'm talking about buffering and such, "1 mile" isn't a sensible measure in latlong. I didn't carefully analyze the code, so maybe I'm just missing something.

Reply on news.ycombinator.com