Ticket #1305 (closed enhancement: fixed)

Opened 18 months ago

Last modified 17 months ago

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

Changed 17 months ago by pramsey

  • cc robe added
  • status changed from new to closed
  • resolution set to fixed

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.

Changed 17 months ago by 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.

Changed 17 months ago by pramsey

  • status changed from closed to reopened
  • resolution fixed deleted

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?

Changed 17 months ago by 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.

Changed 17 months ago by 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.

Changed 17 months ago by 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.

Changed 17 months ago by pramsey

  • status changed from reopened to closed
  • resolution set to fixed

Should be better at r8655

Changed 17 months ago by 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

Changed 17 months ago by pramsey

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

Changed 17 months ago by strk

All good now (make check with topology enabled succeeds)

Note: See TracTickets for help on using tickets.