I do not like these shortened names POP, LWP, etc, which give no clue as to what they do. I propose to use full names that clearly specify the purpose. If the user looks in the index under intersection, and sees a function intersectionLineWithPlane, he can get an idea what it does and whether it is interesting to explore that function. But if you see a lot of intersectionXYZ, you probably do not even bother to start reading.

Also, the functions can all be named after single case operation, even if they work on multiple objects as well.

Next, there should not be any hidden geometry in the naming. E.g., intersectionPointsPOP (intersection points of perpendiculars through points on planes).

Then, the result of the operation should not be mentioned, if the result is unique. The educated user knows what the intersection is of the geometrical entities involved.

In cases where two functions do the same, but one returns the resulting geometry, the other the parametric values, the first one should not mention the return type, while the latter gets the addition ...Times.
Or we could add an option to the above function to return the parametric values instead. Please give preference, if any.

Finally, we can shorten the names by not using the noun but the verb form of the operation.

Thus e.g. some name changes could be:

intersectionPointsPOP -> projectPointOnPlane

intersectionPointsLWP -> intersectLineWithPlane

intersectionTimesLWP -> intersectLineWithPlaneTimes or intersectLineWithPLane(times=True) ?

Any comments? Any additional rules?
If ok, we can make a renaming table to see if we can cover everything.


Another possible track would be to create Line, Plane, Segment, Vector, ... classes, that could be used to check/reshape the input arrays, and then have simple project/intersect methods.
This could also be done as a second step after the renaming of geomtools methods. The Coords(X).project(Y) would call geomtools.projectPointOnPlane if Y is a Plane object, and geomtools.projectPointOnLine if Y is a Line object.

There is already Coords.distanceFromPlane. I am not sure if it supports multiple planes (distanceFromLines does). So I would not like to add more confusion on what to use when: Coords.distanceFromPlane or geomtools.distancesPFP.
The same holds for Coords.projectOnPlane, which is the same as geomtools.intersectionPointsPOP.

I think we need to clean this up by

- renaming the functions/methods appropriately,
- checking which implementation is the best,
- adding the full functionality in one place: this can either be  a Coords method, or a function in geomtools which is then called by the Coords method.

This may be a good occasion to start doing so.