ST_Azimuth on the spheroid

[realityexists]

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

[pramsey]

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.

[realityexists]

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.

[pramsey]

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?

[realityexists]

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.

[robe]

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.

[robe]

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.

[pramsey]

Should be better at r8655

[strk]

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

[pramsey]

I flipped ST_Azimith(p1, p1) back to returning NULL and changed ST_Project(p1, 0, NULL) to return p1.

[strk]

All good now (make check with topology enabled succeeds)