#657 closed task (fixed)
Spheroid/Ellipsoid projection given Lat/Lon, Distance & Bearing
Reported by: | lwilmen | Owned by: | pramsey |
---|---|---|---|
Priority: | low | Milestone: | PostGIS 2.0.3 |
Component: | postgis | Version: | master |
Keywords: | bearing distance liblwgeom spheroid ellipsoid | Cc: | realityexists |
Description
Feature request to expose spheroid_project() from liblwgeom as an SQL function to enable projecting from a give lat/lon by a specified heading/distance (metres).
Change History (11)
comment:1 by , 13 years ago
Milestone: | PostGIS 1.5.3 → PostGIS 2.0.0 |
---|
comment:2 by , 13 years ago
Cc: | added |
---|
comment:3 by , 13 years ago
Priority: | medium → critical |
---|
comment:5 by , 13 years ago
Thanks! I tried out the new ST_Project function in r8577 together with ST_Azimuth. If ST_Azimuth is changed to return radians (consistent with the geometry overload) then I think ST_Project should also take a bearing in radians. Either way, would be nice to explicitly document it, eg. "The distance is given in meters and the azimuth in ...".
A few other issues:
1) ST_Project can return a point outside of the (-180,180) range, which then fails when passed to other functions, eg.
SELECT ST_Project('POINT(175 10)'::geography, 2000000, 90)
=> POINT(193.223435218359 9.50463611585127)
SELECT ST_AsText(ST_Project('POINT(175 10)'::geography, 2000000, 90))::geography
=> ERROR: Coordinate values are out of range [-180 -90, 180 90] for GEOGRAPHY type
2) SELECT ST_Distance(ST_Project('POINT(10 10)'::geography, 10, 0), 'POINT(10 10)'::geography)
=> ERROR: gbox_overlaps: cannot compare geodetic and non-geodetic boxes
3) ST_DWithin doesn't work with the returned point.
SELECT ST_DWithin(ST_Project('POINT(10 10)'::geography, 2000, 90), 'POINT(10 10)'::geography, 2000)
=> false
SELECT ST_DWithin(ST_AsText(ST_Project('POINT(10 10)'::geography, 2000, 90))::geography, 'POINT(10 10)'::geography, 2000)
=> true
comment:6 by , 13 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Version: | 1.5.X → trunk |
Oops, am I exposing radians? I want to only work with degrees at a user level. Sound good? And looks like ST_Project needs to normalize the outputs before returning.
comment:8 by , 13 years ago
Just noticed that the manual page for ST_Project still uses degrees in examples, even though the function now takes radians for the azimuth.
comment:9 by , 12 years ago
Priority: | critical → low |
---|---|
Resolution: | fixed |
Status: | closed → reopened |
Type: | enhancement → task |
Please update the documentation for ST_Project. It sais nothing about how to pass the azimuth and as said before, the example is still showing degrees instead of radians.
comment:10 by , 12 years ago
Milestone: | PostGIS 2.0.0 → PostGIS 2.0.3 |
---|---|
Resolution: | → fixed |
Status: | reopened → closed |
fixed
for PostGIS 2.1 at r11026 : http://postgis.net/docs/manual-dev/ST_Project.html
for PostGIS 2.0 at r11027 : http://postgis.net/docs/manual-2.0/ST_Project.html
The changes should update on website shortly so check back if you don't see them and let us know if it still needs further clarification.
Please, please implement this for 2.0.0, along with closely related ticket 1305!
I'm currently in the process of implementing these in SQL and, being new to GIS, may waste a lot of time and not do it 100% correctly. A native PostGIS implementation would really help. This has been requested several times on the mailing list, so I think I'm not alone in needing it:
http://postgis.refractions.net/pipermail/postgis-users/2010-October/027906.html http://postgis.refractions.net/pipermail/postgis-users/2010-November/028116.html http://postgis.refractions.net/pipermail/postgis-users/2011-May/029749.html