Adam Wulkiewicz wrote On 28-11-2014 16:34:
But, I feel that we could play with the distance calculation. I.e. use one of the mappings, calculate the position and the radius of a corresponding sphere and then use haversine. Actually I'm thinking about the 3rd mapping (or rather the red one). So we could take the coordinates, calculate their position in 3D, then calculate the 3D plane perpendicular to the surface. Then somehow calculate the mid point. Using those 3 points in 3D calculate the radius of a circle/sphere containing all 3 points and the position of the center. Then the angle between the endpoints in 3D. Then the length of the arc would be the distance. Assuming that the above could be done I'd say that it'd be a method corresponding to SSF. This would also be an approximation but most certainly faster than Vincenty distance. And most certainly good enough in some situations.
Do I understand that this might be an alternative distance calculation, faster than Vincenty and still better than Haversine?
I did not really plan or intend to change distance calculations. However, if we have a distance calculation over the spheroid which is compatable with the SSF over the spheroid, that would be welcome of course, I've the feeling that could be of use.
I did not have the time yet to dive deep into this. I'm not sure if you mean to check distance or side calculations, or both...Ok, for now I don't have any other ideas ;)
The side calculations (likewise, segment-segment intersections) are crucial to all the overlay algorithms (union, intersection, (sym)difference, buffer) we want to implement, as is also segment/segment intersections. They should be mutually consistent, we should use them together. If distance belong to them, I don't know yet, that is to be figured out. Even if SSF over the spheroid is a little (but only a little) different, I mean does not follow the geodesic, it can possibly be still useable.