I've been musing (and doing prototype coding) for a 'projection free' geographic codebase with your basic point, line & polygon primitives.
Rather than dealing with all the sacrifices that come along with projecting to the plane, however, I'm writing algorithms that work directly on the surface of the ellipsoid.
One of the potential complications is that there are different kinds of "lines" out there:
- (arcs of) great circles: shortest distance along the (constant-zero-elevation) surface between two points; should correspond exactly to line-of-sight paths.
- rhumb lines: connect the two points with a path of constant direction -- for example, some state borders follow lines of latitude (which are not great circles).
- curves: circular arcs (paths of constant distance from a given center-point); Bezier (not sure on correct re-interpretation in the context of a curved surface), etc.
Of the different kinds of paths (including ones I missed), which are important enough that they have an 'exact' representation, vs representing within an error bounds by short segments of a simpler path (e.g. short geodesic arc segments)?
Clarification edits: by 'exact' above, I mean parametric. In other words: computable to any desired accuracy, without a a densification-on-import step.
An edit, much later, to add a citation I've come across that closely parallels my own thoughts on the use of 3D unit vectors as a geographic primitive: A Non-singular Horizontal Position Representation (alt link). Best part? I didn't have to write it all out myself!