Remove redundancies between 2D/3D variants, and unify API for general 3D case.

[jkalias]

The library has many redundancies between the same concepts in 2D and 3D.

For example, there is a Circle2D and a Circle3D struct, which both describe the geometric shape of a circle, once in 2D and once in 3D. Similar examples are Line2D/3D, Vector2D/3D and so on and so forth. This leads to a lot of code repetition, since the 2D case can be seen as a special case of the more general 3D one.

I propose that the library removes all 2D geometrical objects and provides direct support for 3D objects. The 2D case can be handled with additional constructors, for example, for which the z coordinate is 0. In addition, we should remove the 3D suffix for these types, since it will no longer coney any useful information.

If this is accepted from the core team members, we should also probably bump the major version of the library, since this will be a braking change.

@cdrnet , @Rickasaurus , @jvangael , @JohanLarsson what are your thoughts?

[TacetDiscipulus]

I have to disagree. Just fundamentally a circle and a sphere different objects. One has an area and perimeter, the other a volume and surface area. So given this difference it seems like a an endless list of edge cases, unnecessary parameters having the be added to function signatures to specify a that work is being done in 2D and not 3D which then goes on to make the functions themselves an unreadable mess. There are libraries that exist for working in arbitrarily high dimensions, this does not need to try to become one.

[jkalias]

This proposal was never to make Spatial a general purpose, arbitrarily high dimensions (N > 3) geometry library, Spatial is (and according to my understanding) will always be a Cartesian 3D math library.

I have to disagree. Just fundamentally a circle and a sphere different objects.

I don't think this is true. If we move the discussion to the fundamental level, these two objects ("objects" in the mathematical sense, not the software development one) are the same thing: the locus of points whose Euclidean distance from a given point in R^N is constant.

[jkalias]

Will not implement; not accepted from the community as too disruptive and not enforcing the proper API semantics

[cdrnet]

Sorry for the late response.

From my point of view I'd also pefer to keep them separate:

• The intention of working in 2D space can no longer be expressed in the types, typing becomes weaker.
• Degrees of freedom mismatch, meaning some of the parameter have to be assumed constant/fixed, yet the implementation is not aware of this. Usage in 2D becomes somewhat unclear due to these extra parameters.
• The special case can easily break down due to numerical precision, where 2D unexpectedly turns into 3D.
• Performance: storing and computing 2D cases with 3D seems unnecessarily wasteful.