Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#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 pramsey, 13 years ago

Cc: robe added
Resolution: fixed
Status: newclosed

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.

comment:2 by realityexists, 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 pramsey, 13 years ago

Resolution: fixed
Status: closedreopened

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 realityexists, 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 robe, 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 robe, 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:7 by pramsey, 13 years ago

Resolution: fixed
Status: reopenedclosed

Should be better at r8655

comment:8 by strk, 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 pramsey, 13 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 strk, 13 years ago

All good now (make check with topology enabled succeeds)

Note: See TracTickets for help on using tickets.