Opened 12 years ago
Closed 11 years ago
Last modified 11 years ago
#1305 closed enhancement (fixed)
ST_Azimuth on the spheroid
|Reported by:||realityexists||Owned by:||pramsey|
As discussed on postgis-users over a year ago, the code to calculate azimuth on the spheroid already exists, but is not exposed to SQL. Please create an overload of ST_Azimuth that works on the geography type.
Change History (10)
comment:1 by , 11 years ago
|Status:||new → closed|
comment:2 by , 11 years ago
Thanks for implementing this, Paul! I tried out r8577 (Windows) today and found a couple of issues:
1) ST_Azimuth(geography) returns degrees, but ST_Azimuth(geometry) returns radians. This should probably be consistent to reduce programmer errors and follow the principle of least surprise.
2) When the two points are equal ST_Azimuth(geography) returns NaN, while ST_Azimuth(geometry) return NULL. This should be consistent, too. I would strongly recommend that both overloads return 0, because passing NULL and NaN into ST_Project makes it return NULL and "POINT(nan nan)", respectively. That means every programmer using ST_Azimuth and ST_Project must be aware of this special case and code around it.
ST_Project('POINT(10 10)'::geography, 0, 0) returns 'POINT(10 10)' as expected.
comment:3 by , 11 years ago
|Status:||closed → reopened|
Oh bugger, so the existing one returns rads… humbug. It makes sense then to use radians in the new one, but I *hate* that, since at a user level, navigation is usually done in degrees.
I guess I agree with your argument on the return for the equality case… invertibility is a nice property.
Robe, what do you think? We can't change the existing ST_Azimuth, can we?
comment:4 by , 11 years ago
Yeah, it's a tough one. I agree with you that degrees are nicer for the user. You could make the argument that having one return radians and the other return degrees is no different to ST_Distance(geometry) returning degrees (or whatever) and ST_Distance(geography) returning metres.
comment:5 by , 11 years ago
no I think the existing ST_Azimuth is too much in use and I think in radians
Besides PostgreSQL does have a radians function:
function that will convert degrees to radians. We can just provide an example of that in the docs.
comment:6 by , 11 years ago
oh I meant degrees function. e.g.
SELECT degrees(ST_Azimuth(ST_Point(25,45), ST_Point(75,100))); — 42.273
I probably should change the docs to use that function since its easier to write and remember and that function has existed in postgres for eons.
comment:7 by , 11 years ago
|Status:||reopened → closed|
Should be better at r8655
comment:8 by , 11 years ago
Topology relies on NULL being returned by ST_Azimuth(x,x). I don't think 0.0 is a valid return as it pretends a point has a direction, which it hasn't
comment:9 by , 11 years ago
I flipped ST_Azimith(p1, p1) back to returning NULL and changed ST_Project(p1, 0, NULL) to return p1.
comment:10 by , 11 years ago
All good now (make check with topology enabled succeeds)
Committed at r8496
Regina, could you do the doco-magic on this one, not sure how to add the geography variant to the existing geometry entry.