Subject: Re: [geometry] Support for geographic coordinate system
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2014-11-30 21:57:34
2014-11-30 20:26 GMT+01:00 Barend Gehrels <barend_at_[hidden]>:
> 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.
If only I had more time to play with such things ;)
> Ok, for now I don't have any other ideas ;)
> 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...
Actually I had my test in mind, where I wanted to test the quality of sides
calculation indirectly by checking which curve better represents geodesic
(is shorter for some specific CS). But this didn't give any clear answer.
If you had some time you could check it out, but I don't require it
> 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
Yes, I agree. Even if it was a little bit worse than some hypothetical
"ideal" method it's a good starting point. And I'm guessing that if SSF as
it is works for geographic CS then all sphere-mapping-based side strategies
probably also should work the same way.
Geometry list run by mateusz at loskot.net