• [X] Use a meaningful title for the pull request. Include the name of the package modified.
• [X] Have read How To Contribute.
• [X] Run npm test at the sub modules where changes have occured.
• [ ] Run npm run lint to ensure code style at the turf module level. --> not sure how/if it works

First draft of @turf/clusters-dbscan Ref. #811

Note: this module might be merged into clusters and support both distance & numberOfClusters params (still up in the air).

Compared to the kmeans cluster this is roughly 5x-50x times faster (the kdbush index does help a lot -- The performance will most likely slow down as weighted clusters becomes implemented).

To-Do

• [x] Translate existing GeoJSON properties
• [x] Weighted clusters based on distance (right now the first point from each new cluster is the "center")
• [x] Not too sure if we should be adding centroid/points in the outputs (instead of simply a FeatureCollection<Point>). Using the cluster property param is already enough to be able to create a centroid/center/centerOfMass.
• [x] Only supports kilometers as distance

More To-Dos

• [x] change library name to clusters-dbscan
• [x] add a dbscan property
• [x] drop the centroid
• [x] Prevent input mutation

Examples

points1.geojson

points2.geojson

The goal for Turf v3 was to create a system in which Turf could be coordinated as a set of modules, operating independently but uniform in style, management, and properly versioned together. Unfortunately, that's no longer the case: the current codebase is heterogenous, hard to contribute to, and the guidelines for releases are nonexistent.

About half of the modules are in TypeScript, and about half of those modules have a tsconfig.json file. About 40% of modules name their main export main, and the rest call it index. Same with providing a module entry point, it's about 50%. 3 modules have a .mjs module file, the rest have .es.js.

Basically, there are no real homogenous properties of Turf anymore. It's a worst-case scenario for a mono-repo: it makes Turf maintenance feel much more like 'maintaining 55 modules' than it does 'maintaining a mono-repo'.

Organizationally, Turf currently has a small chunk of cash, a much much smaller number of long-term maintainers, and zero institutional/company code contributors. This is pretty common for open source projects.

To propose a few ways forward:

Remove TypeScript

The TypeScript transition, while a very nice contribution, is unfinished and offers little to the project. We didn't have many bugs caused by type mismatches before, and the resulting addition of complexity outweighs the benefit.

Would this be unpopular? Probably! But it'd be better to re-achieve stability and releasability, and make the project fit its actual contributors, than to perpetually be in a half-deployable state.

If this is the option, we could do it by basically configuring tsc to generate ES modules.

Move lerna.js back to fixed/locked mode

Per https://github.com/Turfjs/turf/pull/1247 the lerna config was switched to independent versioning. This makes collaboration harder: the intent of lerna was and is to make versioning automatic so that the project can be released always with lerna publish. There should not be a thought process for which modules need updating and releases.

Move releases/ back into changelog

This releases directory is the same as a central changelog. Let's move these back to the changelog.

Use standard commits

Again, a common collaboration point - this will automate changelog generation and version more accurately

Write these contribution tips into CONTRIBUTING.md

And probably create a strong process for changing them. This stuff shouldn't become wobbly; Turf should stay in a deployable, simple state that all the maintainers have a grasp on.

(Extreme solution) just move to a singular ES6 module

This would probably be even less popular than removing TypeScript: create one turf module (again), now that tree-shaking means that people using Rollup/Webpack/Parcel can efficiently import a subsection of a module without including all of the code. This would drastically reduce complexity and let advanced users continue to get the performance advantages of the current mini-modules, but it would leave people using old-fashioned require etc out in the cold.

Honestly I'm also in favor of this extreme solution: it'd be a huge decrease in complexity, and it'd do this for existing users:

1. Script-tag or browserify users: yep, would be slower
2. Node users: probably don't mind the startup time or install size that much
3. Webpack/Rollup users: would work great
4. Future native-js module users: would easily be able to sub-import

This is intended to be a bit of a jumping-off point, none of these ways to victory are quick-fixes and we'd want to attain some consensus before embarking on them. Dividing this work up would also be useful, given that there are few maintainers, or if there is an institutional/company contributor who wants to take on some of this, it'd be more than welcome - Turf is definitely generating a lot of value out there in the world, much more than it captures.

Ref: #747

@DenisCarriere @dpmcmlxxvi The output is currently not correct: it is scaled successfully, but for some reason it does not reflect the factor value. I implemented my proposal for the origin; I look forward to knowing your opinion. Also, the scaling along the z-coordinate is not along a Rhumb line, but a simple multiplication by 'factor'. Is there a way, if it make sense at all, to perform such a scaling on z?

For the moment I'd keep it simple and consider only uniform scalings, i.e. scaling factor equal in all directions.

Implemented first module @turf/transform-translate Note: I used @turf/rhumb-destination to create the translation vector, which defines the motion; needs to be checked if the length of the resulting translation matches the provided distance.

Please feel free to comment, suggest, correct, add tests.

(Ref: #747)

New Module @turf/line-offset

Adds a new lineOffset module as per this issue. Basically takes an input line and returns a new line offset by the distance.

Geometry Support

• [x] LineString => LineString
• [x] MultiLineString => MultiLineString

Geometry NOT supported

• Point => LineString (alternative @turf/circle?)
• MultiPoint => MultiLineString (alternative @turf/circle?)
• Polygon => LineString (alternative @turf/buffer / @turf/transform-scale)
• MultiPolygon => MultiLineString (alternative @turf/buffer / @turf/transform-scale)
• FeatureCollection/GeometryCollection (might contain mixed geometries and cause errors)

To-Do

• [x] Start and end points of the resulting line shall not be connected.
• [ ] Equidistance offset (similar to issue https://github.com/Turfjs/turf/issues/660 / https://github.com/Turfjs/turf/pull/718)

JSDocs

/**
 * Takes a {@link LineString|line} and returns a {@link LineString|line} at offset by the specified distance.
 *
 * @name lineOffset
 * @param {Geometry|Feature<LineString>} line input line
 * @param {number} offset distance to offset the line (can be of negative value)
 * @param {string} [units=kilometers] can be degrees, radians, miles, kilometers, inches, yards, meters
 * @returns {Feature<LineString>} Line offset from the input line
 * @example
 * var line = {
 *   "type": "Feature",
 *   "properties": {},
 *   "geometry": {
 *     "type": "LineString",
 *     "coordinates": [[-83, 30], [-84, 36], [-78, 41]]
 *   }
 * };
 *
 * var offsetLine = turf.lineOffset(line, 2, 'miles');
 *
 * //addToMap
 * var addToMap = [offsetLine, line]
 */

Examples

• [x] Use a meaningful title for the pull request. Include the name of the package modified.
• [x] Have read How To Contribute.
• [x] Run npm test at the sub modules where changes have occurred.
• [x] Run npm run lint to ensure code style at the turf module level.

The devDependency lerna was updated from 2.8.0 to 3.4.2.

This version is not covered by your current version range.

If you don’t accept this pull request, your project will work just like it did before. However, you might be missing out on a bunch of new features, fixes and/or performance improvements from the dependency update.

Your Greenkeeper bot :palm_tree:

I upgraded my project to Angular 6 which migrated to Webpack 4. I have a dependency on mapbox which uses turf. After the upgrade I started getting build errors like the following.

ERROR in ./node_modules/@turf/meta/index.mjs
997:15-25 Can't import the named export 'lineString' from non EcmaScript module (only default export is available)
 @ ./node_modules/@turf/meta/index.mjs
 @ ./src/index.js

It appears to be failing because @turf/meta uses mjs and @turf/helpers is a non mjs module. I am not sure if this is just a build configuration in Webpack that needs to be tweaked or if a correction needs to be made to turf. I looked around the Webpack issues and didn't really see anything to help along with a fix.

Here is a repo to easily reproduce this issue.

https://github.com/adamduren/webpack4-turf-issue

Major release pre-announcement (TurfJS v5.0) ⭐️ 📢

Due to some drastic changes coming up, the next TurfJS release will be v5.0 (Major release).

If anyone has any suggestions for breaking changes, the time would be now to do it.

Timeline

Approximately a 1-2 weeks (end of September/ early October, 2017).

Major To-Dos before publish

• [ ] Finish adding new optional parameters (options) (PR https://github.com/Turfjs/turf/pull/953)
• [x] Convert to ES6 modules using Rollup (PR https://github.com/Turfjs/turf/pull/960)
• [ ] v5.0 issues

Not happening for next publish

• [x] jsts won't be entirely removed

@stebogit @rowanwins Any additional suggestions for v5.0 changes?

Don't hesitate to send some breaking PR changes (within reason & approved).

CC: @Turfjs/ownership

So just wanted to continue the discussion from this pull request.

I'd find it quite handy to have a module that looped through interior and exterior rings of polys easily.

turf.ringEach(feature, function (ringCoords, ringIndex, isExterior) {
  //=ringCoords = [[0,0], [1,1], [1, 0], [0, 0]]
  //=ringIndex = 0
  //=isExterior = true
});

@DenisCarriere you proposed splitting the module into interior and exterior versions, I'm just trying to think through whether it would be better to have them together in a single module and how I'd use them....

In an ideal world I'd then love to be able to pass a coord array into one of the other meta functions, eg coordEach without having to first turn into a geojson feature or geometry.

Anyway just starting the discussion rolling in a more trackable place than a vaguely related pull request :)

@DenisCarriere I implemented the turf-sector module (related to #155 and #649). However I did not create the README file cause I thought it was created automatically from the documentation in the index.js, but it didn't. Should I create it manually? Not sure if the index.d.ts and bench.js are correct, as I'm not familiar with them.

Is that ok if I created the branch in this repo or should I work on my forked one?

Self-intersecting polygon has wrong area. It cannot be zero:

• [x] Version: @turf/[email protected].
• [x] GeoJSON data as a gist file: https://gist.github.com/sigorilla/e0f97a91e579bc1f27e4a950352a29ae
• [x] Snippet of source code: https://runkit.com/sigorilla/turf-area-self-intersecting

Please fill in this template.

• [x] Use a meaningful title for the pull request. Include the name of the package modified.
• [x] Have read How To Contribute.
• [x] Run npm test at the sub modules where changes have occurred.
• [x] Run npm run lint to ensure code style at the turf module level.

This is a minor PR to fix what I thought might be a typo in the @turf/boolean-intersects docs. The example has two geometries that don't intersect, but says it returns true. Thank you!

I use @turf/turf 6.5.0.

Features of the screenshot :

{
  type: 'Feature',
  geometry: { type: 'LineString', coordinates: Array.from({ length: 27 }, (_, i) => [20, i * 5 - 65]) },
  properties: {}
},
...Array.from({ length: 27 }, (_, i) => ({ type: 'Feature', geometry: { type: 'Point', coordinates: [0, i * 5 - 65] } as GeometryPoint, properties: {} } as GeoJsonFeature<GeometryPoint>))

When I create a 140 miles buffer with the turf buffer function, here's what happened :

(For rendering the map, I use OpenLayer 7.1.0 in projection EPSG:4326)

The buffer of each point is correct, but every time I try to buffering an other king of Geometry, such as LineString or Polygon, the buffer is not correct : it doesn't respect the projection and the distances.

Please provide the following when reporting an issue:

• [x] The version of Turf you are using, and any other relevant versions (6.5.0)
• [x] GeoJSON data as a https://gist.github.com/Kilowhisky/5f3a5e3b7c3467a7913a19785c702cc3
• [x] Snippet of source code or for complex examples use jsfiddle.

simplify(feature, {
            tolerance: 0.01,
            highQuality: true,
            mutate: true
});

Error: invalid polygon
    at file:///C://node_modules/@turf/simplify/dist/es/index.js:257:13
    at Array.map (<anonymous>)
    at simplifyPolygon (file:///C://node_modules/@turf/simplify/dist/es/index.js:252:22)
    at file:///C://node_modules/@turf/simplify/dist/es/index.js:215:16
    at Array.map (<anonymous>)
    at simplifyGeom (file:///C://node_modules/@turf/simplify/dist/es/index.js:214:45)
    at file:///C://node_modules/@turf/simplify/dist/es/index.js:169:5
    at geomEach (file:///C://node_modules/@turf/meta/dist/es/index.js:590:13)
    at simplify$1 (file:///C://node_modules/@turf/simplify/dist/es/index.js:168:3)
    at _getAlertFeatureCollection (file:///C://handler.js:113:9)   

It seems that internally turf.simplify calls cleanCoords. It appears that cleanCoords will remove duplicates so much that it will make polygons invalid by reducing them below the 4 point minimum.

As a bonus here is the raw GeoJSON that the above Gist was constructed out of by the truncate and union function. What I was attempting to do was combine all polygons and simplify to make the object easier to render. https://gist.github.com/Kilowhisky/bd1b46f162aac622c5a77dfebb709d5e

turf-union in all its docs mentions the union of only two (multi)polygons or geojson's

https://www.npmjs.com/package/@turf/union

It would be nice and useful if we could unite several (multi)polygons or geojson's

let union
union = turf.union(poly1, poly2)
union = turf.union(poly1, poly2, poly3)
union = turf.union(poly1, poly2, poly3, ..., polyn)

const polygons = [poly1, poly2, poly3, ..., polyn]
union = turf.union(...polygons)

I was looking for a way to transform each coordinate of a GeoJSON object and was about to propose .coordMap() (similar to #1438).

It was only by reading through the comments that I realised that .coordEach() can be used to do in-place transformation.

I'd suggest updating the description from:

Iterate over coordinates in any GeoJSON object, similar to Array.forEach()

to:

Iterate over coordinates in any GeoJSON object, analogous to Array.forEach(). Modifications to currentCoord mutate the input object.

(IMHO "analogous" is a better word here than "similar" because of the different arguments and input type)

Also, if possible, clarify what coordIndex is, because it's not that obvious to me in the case of a (Multi)Polygon.