Down with Podal!
Are you anti-podal? So are many geographic edges!
Actually, not many, but it feels like a common first test case people try when they start playing with the geography type. “How far is it between 0,0 and 180,0?”
There’s a big problem with anti-podal edges though: they don’t have a determinate path. That is, to get from (0,0) to (180,0) it doesn’t matter what direction you travel, just start moving. Any other pairing of points generates a single great circle describing the shortest path joining them. So anti-podal points make very bad components of geometry: they don’t define a path, and they can’t bound an area, because only the end points have a determinate location.
Which brings me to my problem. How do I handle geography objects in PostGIS that include anti-podal segments? On the one hand, since they are impossible to do calculations against, I should just disallow them in all cases, and throw an error. On the other hand, people think they have meaning and stick them into functions all the time. There are also a few functions (like ST_Length) where it’s actually possible to calculate a valid answer given an antipodal input (because we know that antipodal points are exactly one half-circumference apart, even if we don’t know what direction someone might travel between them).
What do you think? Is there a best answer? Comments most welcome!
I’d be curious to see a couple of examples to help me clarify my thinking.
Doing an area calculation should be fine as long as a antipodal points are not adjacent in the polygon, in which case I’d throw an invalid geometry error of some sort.
What other types of calculations would give bad results?
Doesn’t the fact that you’re using an ellipsoid mean that not all directions return an equal length route? (If my thinking is correct, you would still have two possible shortest paths, but not an infinite number, except if the points are the poles.)
It would also seem that for many polygons (though not all possible ones) that one of the two possible paths would cause a self-intersection, so you could assume the other direction was meant).
The example that brought it up is here:
I thought, “hey, that’s just an orange slice, with one line over the pole and the other back along the equator”, but in fact it’s… something or nothing at all.
What it comes down to is user intent, which is not divineable given the inputs. They probably don’t actually mean the shortest spheroid path (if there happens to be one, which for some locations there wouldn’t be), since they have no idea what that path is (nor do I).
Any calculation that wants to use the interpolated line between the points as a logical part of the calculation would be broken. Distance between objects, area, really anything but length measurements.
Don’t know if it helps but, for what it’s worth, Microsoft don’t allow antipodal edges in the SQL Server geography datatype - it throws an exception at the point you try to create an instance from WKT containing antipodal points.
how about traveling always into the positive axis direction? (0 -> 180, 180 -> 359.999)
It’s not a “one of two directions” problem. It’s a “one of an infinite number of directions” problem. I can get from the north pole to the south pole (or between any two antipodal points, actually) via London, or Paris, or Rome, or Vancouver, or New York, or… any direction will work.