Ticket #1305 (closed enhancement: fixed)

Opened 2 years ago

Last modified 2 years 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 2 years 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 2 years 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 2 years 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 2 years 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 2 years 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 2 years 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 2 years ago by pramsey

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

Should be better at r8655

Changed 2 years 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 2 years ago by pramsey

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

Changed 2 years ago by strk

All good now (make check with topology enabled succeeds)

Note: See TracTickets for help on using tickets.