#1305 closed enhancement (fixed)
ST_Azimuth on the spheroid
Reported by: | realityexists | Owned by: | pramsey |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS 2.0.0 |
Component: | postgis | Version: | 1.5.X |
Keywords: | Cc: | robe |
Description
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.
See http://postgis.refractions.net/pipermail/postgis-users/2010-August/027389.html
Change History (10)
comment:1 by , 13 years ago
Cc: | added |
---|---|
Resolution: | → fixed |
Status: | new → closed |
comment:2 by , 13 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 , 13 years ago
Resolution: | fixed |
---|---|
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 , 13 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 , 13 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:
SELECT radians(45);
function that will convert degrees to radians. We can just provide an example of that in the docs.
comment:6 by , 13 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:8 by , 13 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 , 13 years ago
I flipped ST_Azimith(p1, p1) back to returning NULL and changed ST_Project(p1, 0, NULL) to return p1.
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.