Modules to potentially rename for v8

[rowanwins]

If we're working towards a release of v7 then now would be a good time to rename any modules as a breaking change.

• lineIntersect to become intersectionPoints. Rationale being is that this module supports both polygons and lines, and I think the proposed name is a bit clearer as to what it does and returns.

Any other thoughts for candidates @mfedderly @JamesLMilner @twelch ?

[JamesLMilner]

I agree that lineIntersect is a bit confusing considering it works on LineStrings and Polygons. I would be happy to rename it to intersectionPoints if that helps provide clarity to users

[mfedderly]

I don't know of any other renames offhand, but I made a PR for lineIntersect #2187

[smallsaucepan]

Rebooting this discussion, within the context of the boolean* functions, which I find a bit clunky. Can appreciate a legacy argument for highlighting a boolean return type via the function name. With typescript more prevalent now don't think that's as important.

Now that we have named exports (and can export the same function multiple times with different names), could we start transitioning names to roll off the tongue more easily?

Current	DE-9IM equiv?	Alias
booleanClockwise		clockwise
booleanConcave		concave
booleanContains	✔️	contains
booleanCrosses	✔️	crosses
booleanDisjoint	✔️	disjoint
booleanEqual	✔️	equal
booleanIntersects	✔️	intersects
booleanOverlap	✔️	overlaps
booleanParallel		parallel
booleanPointInPolygon		contains
booleanPointOnLine		contains
booleanTouches	✔️	touches
booleanValid		valid
booleanWithin	✔️	within

Some of the above suggestions collide with other function names - concave and convex - though we could in turn name those functions better as concaveHull and convexHull.

Regarding the original topic - lineIntersect - could we move in the other direction, and have just a single intersections method that returns the intersections for whatever you give it at run time? This seems neater than having thisIntersect, thatIntersect, intersectThisWithThat, etc.

Same would go for contains. Isn't booleanPointOnLine really just contains(line, point), and booleanPointInPolygon contains(polygon, point)?

That said though, a note on contains? Found this article which mentions:

That last clause causes the trap - because of it, a LineString which is completely contained in the boundary of a Polygon is not considered to be contained in that Polygon! [...] For this reason it's useful to define another predicate called covers, which has the intuitively expected semantics

[timtucker-dte]

A few thoughts:

Imports

If names are potentially changing, it would be nice if everything used the same import syntax.

i.e.: regardless of whether you add @turf/turf or @turf/helpers to your package, you could use:

import from @turf/helpers

Having a single way to import things would greatly simplify the documentation.

Seems like this could just be a matter of having the combination package include the subcomponents by referencing their NPM packages as dependencies as opposed to importing the workspace packages.

You could still have @turf/turf re-export things via a barrel file for compatibility with the existing import syntax.

Note that this would also make it easy for projects to go back and forth between the two ways of listing dependencies. As an example, you could start by installing everything via @turf/turf and then change your dependencies to just @turf/helpers if you later realized that's all you needed -- without needing to modify any code.

Aliases

Also agree that things aliased via the old names would be a good way of maintaining backward compatibility for renaming within packages, with the old aliases marked as deprecated and removed in a future release.

Function naming / prefixing

My personal preference for functions that return boolean is to prefix with "is".

I've found that prefixes generally make things easier to assign the output to variables without having to come up with a name that doesn't overlap.

Example:

const foo = isFoo(object);
if (foo) {
   // Do something
}

Another potential argument against some of the simpler function names I see above:

When using named imports, overlapping with built-in functions or common functions from other libraries creates a huge headache when tools that auto-suggest or add missing imports (IntelliSense in VS Code / linters / etc.).

(The ArcGIS libraries are terrible for this with how much they overlap @types/geojson for basic things like Point)

I'd much rather see things that are unique to the purpose, i.e.:
equalGeomery
containsGeometry

Return types

If you want to be a bit more generic, you could also consider looking beyond boolean as the return type.

Example:

enum GeometryRelationship {
    Equal = "Equal",
    Subset = "Subset",
    Superset = "Superset",
    Intersects = "Intersects",
    Disjoint = "Disjoint"
}

function geometryRelationship(objectA: Geometry | Feature<unknown>, objectB:  Geometry | Feature<unknown>): GeometryRelationship {
    // determine which type of relationship 2 objects have
}