turf-next proposal

[tmcw]

opinion warning: this is opinion

Turf 3.0 should

• Switch to a uni-repo method. All core modules will be in a single repo. Addons will be managed as such
• Turf will have a global dependency to lodash 4.x, which will help with some of the fp stuff but more importantly with immutability
• Turf packages will still be bundled as split-out packages, like lodash modules or babel modules, and we'll take advantage of lerna to do that.
• Turf support will be moved 100% to gis stackexchange or stackoverflow and off of github. This leaves GH as only the place for technical discussion

cc @Turfjs/owners

[mourner]

Support everything except the lodash dependency, which I find unnecessary.

[tmcw]

@mourner i'm fine with an alternative to lodash: mainly I'm excited by the inclusion of lodash-fp, which provides immutable methods. I think turf's mutability problems need a generalized solution. lodash is one, there are surely others.

[anandthakker]

Re: immutability -- I've been trying out seamless-immutable in a recent project, and I've been 80% happy with it, but my guess is that there would be perf problems out of the box

[mourner]

@tmcw although I don't have a lot of experience with immutability to have a weighted opinion here, I feel like immutability should be more of convention rather than a library you depend on (especially a bloated one like lodash) , at least in libraries like Turf as opposed to end-user applications.

I like the approach of seamless-immutable — it basically throws helpful exceptions when you mutate objects/array that should be immutable, but you can switch to "production build" which doesn't do that and performs much better.

[anandthakker]

I like the approach of seamless-immutable — it basically throws helpful exceptions when you mutate objects/array that should be immutable, but you can switch to "production build" which doesn't do that and performs much better.

@mourner Yeah I like this approach too. My concern using the actual lib with turf is that for each turf function you might have to do a deep traversal on input (to make input geojson immutable) and again on output (to make it back into a plain object), which I'd think would be noticeable overhead.

I guess that overhead could be avoided if turf were to return seamless-immutable objects, which look and act just like plain objects (especially using the production build), except for having a private, non-enumerable __immutable_invariants_hold property on them that's used internally by seamless-immutable.

[tmcw]

cc @morganherlocker @tcql what say you?

[tmcw]

Here's a proposed module roadmap:

turf v3 layout

• geometry-helpers these modules should be one module
  • turf-polygon
  • turf-featurecollection
  • turf-point
  • turf-linestring
• turf-statistics
  • turf-sample
  • turf-aggregate these modules should all just be one function and should
    be named after what it does for real. Condense turf statistics sprawl into turf-collect #314
    • turf-count
    • turf-min
    • turf-sum
    • turf-max
    • turf-median
    • turf-deviation
    • turf-variance
    • turf-average
• turf-grid
  • turf-hex-grid
  • turf-point-grid
  • turf-square-grid
  • turf-triangle-grid
• turf-operations
  • turf-union
  • turf-intersect: should be named intersection, to match union
  • turf-concave
  • turf-tag
  • turf-convex
  • turf-buffer
  • turf-simplify
  • turf-difference
  • turf-midpoint
  • turf-kinks
  • turf-centroid
  • turf-within
  • turf-center
  • turf-along
  • turf-square
  • turf-planepoint
  • turf-point-on-line
  • turf-point-on-surface
  • turf-line-slice
  • turf-extent
• turf-analysis
  • turf-area
  • turf-inside
  • turf-bearing
  • turf-destination
  • turf-nearest
  • turf-line-distance
  • turf-distance
• turf-geojson-utils
  • turf-combine
  • turf-flip
  • turf-random
  • turf-bezier
  • turf-explode: rename to something more descriptive, like turf-coordinates
  • turf-bbox-polygon
• turf-interpolation
  • turf-isolines
  • turf-tin

rename

• turf-size rename this turf-resize or something. turf-size is not a good name

deprecate

• turf-merge: this is confusingly named and doesn't provide any value over calling union repeatedly
• turf-envelope: does not provide any value over calling bboxPolygon(extent(features))
• turf-quantile: provides no value over ss.quantile(features.map(f => f.properties.foo), [1, 2 3])
• turf-jenks: provides no value over ss.jenks(features.map(f => f.properties.foo), 3)
• turf-filter: provides no value over features.filter(f => f.properties.foo == 'bar')
• turf-remove: provides no value over features.filter(f => f.properties.foo !== 'bar')
• turf-reclass: provides no value over features.map(f => { class: getClass(f.properties), ...f.properties })

[morganherlocker]

Thanks for posting this @tmcw. I think a modest v3 release that helps v3+n easier is a terrific idea.

high level

Switch to a uni-repo method. All core modules will be in a single repo. Addons will be managed as such

Turf packages will still be bundled as split-out packages, like lodash modules or babel modules, and we'll take advantage of lerna to do that.

👍 I think this would be drastically easier to maintain and release. The lodash approach that has evolved is great. Ideally, we would have one repo to develop under and publishing would release all the submodules and the master module as if they were separate (my understanding of how lodash works). This would make things like updating benchmarks, linting changes, testing core updates across internal dependencies a breeze compared to how it is now.

Turf will have a global dependency to lodash 4.x, which will help with some of the fp stuff but more importantly with immutability

I think we should design a pattern for how we do immutability. I do not think we should depend on the full lodash, but something more focused to deal specifically with immutability (if we need a library at all, instead of simply a codified pattern). A short note on best practices with respect immutability in the CONTRIBUTING.md file would go a long way in my opinion.

Turf support will be moved 100% to gis stackexchange or stackoverflow and off of github. This leaves GH as only the place for technical discussion

👎 I do not see any reason to do this. I have absolutely zero problem with support type questions here, and we have been able to help many people over the years through Github. Issues are cheap, and I honestly enjoy answering the questions. 😄

rename

turf-size rename this turf-resize or something. turf-size is not a good name

👍 resize is better. I would also be fine with dropping this entirely. I tend to be using different patterns these days around this type of operation (explicit distance-based bbox buffers).

deprecate

👍 I agree with all of these except for turf-envelope, which I think is a useful convenience method. A method that saves a bit of thought and typing for quick scripting is worthwhile IMO. The other modules on the list are mostly clunky wrappers around ss, and it makes sense to encourage people to dig a bit deeper. turf-merge is a performance landmine many people have run into, and I think we would have less issues around this if people had to explicitly say "yep, I'm unioning a billion polygons YOLO".

layout

Are you proposing to namespace the actual library, or simply organize the code this way? I prefer the flat structure we currently have, since remembering a module name is much easier than remembering a module name + which category it belongs to. This is a big pain point in similar stats and spatial libraries in my experience, and the flat structure lines up with other "easy to use" grab bag libraries like lodash.

[tmcw]

Re: layout. I think each category should be a module, and the modules to be reflected in namespaces. So like turf.geom.featurecollection and turf.grid.hex. And you'd install turf-geom to get just the geometry helpers, and turf-grid to get just the grids.

And, I know I'm in the minority here, but I still really want to get rid of geometry helpers :)

[tmcw]

The actions that had consensus are now in master.

[tmcw]

Still need to remove turf-reclass

[tmcw]

Fixed in f9e1bd9

[easherma]

resize is better. I would also be fine with dropping this entirely. I tend to be using different patterns these days around this type of operation (explicit distance-based bbox buffers).

@morganherlocker this might be better for a separate thread, but I'm curious if you could elaborate on what you mean by explicit distance-based bbox buffers and why you prefer that method.