Does the following distance calculation fail to take into account the curvature of the earth?
"The deviation of STDistance() on common earth models from the exact
geodesic distance is no more than .25%. "
Docs: http://msdn.microsoft.com/en-us/library/bb933808.aspx
create proc findNearbyZips
#lat float,
#lon float,
#radius float
as
begin
declare #geo geography;
set #geo = geography::Point(#lat, #lon,4326);
with ZipsWithinRadius as
(
select zip5, city, state from zips
where
#geo.STDistance( zips.centroidGeoLocationInBinaryFormat ) <= #radius * 5280.00
)
select [...]
end
Make sure that you use the correct units so you dont calculate things in miles when it should be meters or vice versa. When in doubt, assume SI base units (http://en.wikipedia.org/wiki/SI_base_unit)
Related
I want to check the area of geometry values.
The geometry values are POLYGON or POINT or MULTI POLYGON.
The field has the type of geometry
I check the srid of the geom field:
select st_srid(geometry)
from my_table
And I got srid=32636.
I checked here:
https://epsg.io/32636 and it seems that the units are in meters.
Now I want to get the area (in meters) of each value:
select st_area(geometry)
from my_table
And I'm getting very small values (0.0002, or 0.000097 or 0.33, ....).
I want to be sure:
Does those values means square meter (m^2) ?
So the values are less than 1 square meter ?
Since your SRS unit is metre, ST_Area will return the area in square metres. The following example calculates the area of a polygon using SRS's that have different units:
WITH j (geom) AS (
VALUES ('SRID=32636;
POLYGON((-1883435.029648588 6673769.700215263,-1883415.1158478875 6673776.142528819,-1883411.8478185558 6673765.073005969,-1883431.7724919873 6673758.967942359,-1883435.029648588 6673769.700215263))'::GEOMETRY))
SELECT
ST_Area(geom) AS sqm,
ST_Area(
ST_Transform(geom,2249)) AS sqft
FROM j;
sqm | sqft
-------------------+-------------------
237.6060612927441 | 2341.135411173445
EPSG 32636: Units are metres (Ellipsoid WGS84)
EPSG 2249: Units are feet (Ellipsoid GRS1980)
To your questions:
Does those values means square meter (m^2) ?
Yes.
So the values are less than 1 square meter ?
Yes. I'm curious about what are your geometries about. Perhaps you mixed up different SRS?
Unrelated note: Spatial operations with SRS's that have the same unit might still deliver different results, as they might also use different ellipsoids. The example below will calculate the area of the same geometry using SRS's that have metre as unit but a different ellipsoid. Note the difference in the result:
WITH j (geom) AS (
VALUES ('SRID=32636;
POLYGON((-1883435.029648588 6673769.700215263,-1883415.1158478875 6673776.142528819,-1883411.8478185558 6673765.073005969,-1883431.7724919873 6673758.967942359,-1883435.029648588 6673769.700215263))'::GEOMETRY))
SELECT
ST_Area(geom) AS sqm_32636,
ST_Area(
ST_Transform(geom,26986)) AS sqm_26986
FROM j;
sqm_32636 | sqm_26986
-------------------+--------------------
237.6060612927441 | 217.49946674261872
EPSG 32636: Units are metres (Ellipsoid WGS84)
EPSG 26986: Units are metres (Ellipsoid GRS1980)
.. but if you stick to the same ellipsoid and unit, the math makes more sense:
WITH j (geom) AS (
VALUES ('SRID=32636;
POLYGON((-1883435.029648588 6673769.700215263,-1883415.1158478875 6673776.142528819,-1883411.8478185558 6673765.073005969,-1883431.7724919873 6673758.967942359,-1883435.029648588 6673769.700215263))'::GEOMETRY))
SELECT
ST_Area(
ST_Transform(geom,2249)) AS sqft_2249,
ST_Area(
ST_Transform(geom,2249)) * 0.3048 ^ 2 AS sqm_2249, -- manually converted from sqm to sqft
ST_Area(
ST_Transform(geom,26986)) AS sqm_26986
FROM j;
sqft_2249 | sqm_2249 | sqm_26986
-------------------+--------------------+--------------------
2341.135411173445 | 217.49859674966302 | 217.49946674261872
Demo: db<>fiddle
I have a PostGIS geography point that I want to rotate by a set distance on the ideal sphere (not spheroid). I see the ST_Project() function, but it seems that it rotates points on the spheroid. For example, if I rotate (0,10) by 1 degree north, the result is slightly larger than 1 degree
select ST_AsText(ST_Project(ST_Point(0,10), 111194.68229846345*1,radians(0.0)));
st_astext
---------------------------
POINT(0 11.0052750273178)
(1 row)
Rotating (0,60) by the same distance gives a result that is slightly less than 1 degree.
POINT(0 60.9979713953998)
I can also compute the distance between the points using the spheroid
select ST_Distance(ST_Project(ST_Point(60,89.9)::geography, 111194.68229846345*1,radians(0.0)),ST_Point(60,89.9),'t');
st_distance
------------------
111194.682298475
(1 row)
and the perfect sphere
select ST_Distance(ST_Project(ST_Point(60,89.9)::geography, 111194.68229846345*1,radians(0.0)),ST_Point(60,89.9),'f');
st_distance
-----------------
110698.09475313
(1 row)
So it is not that I got the circumference of the Earth wrong.
For many functions that operate on geography objects, such as ST_DWithin, there is an option to use the spheroid or the perfect sphere. I do not see the option for ST_Project.
In general, my azimuth will be one of 0, 90, 180, and 270, and it has to work properly around the poles.
You just need to create a new spatial projection, where semi-major and semi-minor axes for the spheroid are the same. So for a sphere with a radius of 6370986 m, here is a new SRID=123456:
INSERT INTO spatial_ref_sys(srid, auth_name, srtext, proj4text)
VALUES (123456, NULL, '', '+proj=longlat +a=6370986 +b=6370986 +ellps=sphere +no_defs ');
For geography types, the default SRID=4326 is for the WGS84 ellipsoid. To use the new sphere ellipsoid, you need to set the SRID to a non-default value.
SELECT ST_AsText(ST_Project(ST_SetSRID(ST_Point(0,10), 123456), 111194.68229846345, 0.0));
st_astext
-------------
POINT(0 11)
(1 row)
I'm testing out different formulas for finding specific points on the earth within a given radius from a given latitude/longitude. I've been using the 'spherical law of cosines' and what I believe to be an implementation of Haversine.
For the following formulas, these are the variables:
[$lat/$lon] = point of origin
[latitude/longitude] = second point
[$radius] = radius
Spherical law of cosines
3959 * acos( cos( radians('.$lat.') ) * cos( radians( latitude ) ) * cos( radians( longitude ) - radians('.$lon.') ) + sin( radians('.$lat.') ) * sin( radians( latitude ) ) ) ) <= '.$radius.';
Haversine (at least I think it is!)
3959*3.1415926*sqrt((latitude-'.$lat.')*(latitude-'.$lat.') + cos(latitude/57.29578)*cos('.$lat.'/57.29578)*(longitude-'.$lon.')*(longitude-'.$lon.'))/180) <= '.$radius.';';
I initially came across a lot of information saying that Haversine was the gold standard as far as accuracy. However, there also seems to be an opinion that the spherical law of cosines is more accurate than Haversine, as long as the distance being measured is greater than 5 metres or so. Furthermore, some say that Vincenty is said to trump both in accuracy.
Three questions:
Is my Haversine formula actually Haversine or it something else?
Any thoughts on which wins out for most accurate?
Can anyone provide me with a formulation for Vincenty along the lines of the above forumlas?
thanks!
Your so-called Haversine formula is totally incorrect.
Firstly it contains 7 left parentheses and 8 right parentheses.
Secondly conversion from degrees to radians is done in some cases by dividing by 57.29578 then there's a constant pi up the front and a constant 180 down the back.
Thirdly haversine(x) = sin(x / 2) ** 2 and I don't see the / 2 anywhere.
Fourthly there should be an asin function call near the front.
Correct formula here
My answer will be more Specific for your first and second answer
Q1: Is my Haversine formula actually Haversine or it something else?
I Don not understand Your haversine formula you made it
The write one or exactly the SQl query for haversine Formula is that
From Google Developer Site Click Here For Details
SELECT id, ( 3959 * acos( cos( radians(37) ) * cos( radians( lat ) ) * cos( radians( lng ) - radians(-122) ) + sin( radians(37) ) * sin( radians( lat ) ) ) ) AS distance FROM markers HAVING distance < 25 ORDER BY distance LIMIT 0 , 20;
This SQL statement that will find the closest 20 locations that are within a radius of 25 miles to the 37, -122 coordinate. It calculates the distance based on the latitude/longitude of that row and the target latitude/longitude, and then asks for only rows where the distance value is less than 25, orders the whole query by distance, and limits it to 20 results. To search by kilometers instead of miles, replace 3959 with 6371.
You can make your Changes for this SQL query To be exactly What you want to.
Q2: Any thoughts on which wins out for most accurate?
There is no final answer for who can win?!, But we can deal with that:
1.Haversine is More Faster.
2.Spherical law of cosines is more accurate for Small distances.
And About Q3 I Know that the vincenty Formula is the most accurate But it is the slowest One
I am using PostgreSQL to store the location of a user send to the server by my android app. I needed to find the total distance travelled by the user for a particular time duration.
The user location is stored in the following table :
CREATE TABLE userlocation
(
latitude character varying,
longitude character varying,
geopoint point,
userid integer,
locationtime timestamp
)
I retrieved the records and calculated the distance in java using the following haversine distance method :
public double getdistance(final double lat1, final double lon1, final double lat2, final double lon2, final char unit) {
final double theta = lon1 - lon2;
double dist = Math.sin(deg2rad(lat1)) * Math.sin(deg2rad(lat2))
+ Math.cos(deg2rad(lat1)) * Math.cos(deg2rad(lat2))
* Math.cos(deg2rad(theta));
dist = Math.acos(dist);
dist = rad2deg(dist);
dist = dist * 60 * 1.1515;
if (unit == 'K') {
dist = dist * 1.609344;
} else if (unit == 'N') {
dist = dist * 0.8684;
}
if (Double.isNaN(dist)) {
dist = 0.0;
}
return (dist);
}
However this calculation is time consuming especially while calculating the distance for multiple days as there are a lot of records. I decided to try doing the distance calculation at the database level to reduce the calculation time. I found the the following query which allows me to calculate the distance to a certain point :
SELECT latitude, longitude, geopoint <-> '19.23,72.89' AS distance FROM userlocation ORDER BY distance;
I tried to create a query that would either return the total distance traveled or atleast calculate the distance between two consecutive rows and store it in another column so that I calculate the sum in Java instead of the distance calculations.
I have tried searching for a solution but I have been unable to find one yet. Most of the questions on SO deal with distance calculation between two points.
I do not have PostGIS at the moment. Would it be possible to calculate distance in PostgreSQL or should I just continue with my current approach? In that case is there an alternative for reducing the distance calculation time.
I had the same problem last month.
I added the module Earthdistance to PostgreSQL. This plugin add functions to compute the great circle distances between two points.
Installation is simple:
CREATE EXTENSION "cube";
CREATE EXTENSION "earthdistance";
Hope that helps
I have a table geofences which stores geometry of polygon.
I also have a point A which is inside the geometry. What I have to do is find the two closest points from point A that lie on the surface of the polygon geometry.
Function in PostGIS:
CREATE OR REPLACE FUNCTION accuracyCheck(Polygon geometry
,decimal lat
,decimal lon)
RETURNS VARCHAR AS
$BODY$
DECLARE height DECIMAL;
DECLARE accuracy VARCHAR(250);
BEGIN
CREATE TEMPORARY TABLE closePointStorage AS
SELECT ST_AsText(ST_ClosestPoint(geometry
,ST_GeomFromText('POINT(lat lon)',0)
)
) AS closestPoint
FROM (
SELECT ST_GeomFromText(geometry) as geometry
FROM gfe_geofences
WHERE is_active=true
) As tempName;
CREATE TEMPORARY TABLE areaStorage ON COMMIT DROP AS
SELECT ST_Area(ST_GeomFromText('Polygon((23.0808622876029 96.1304006624291
,28.0808622876029 99.1304006624291
,100 200
,23.0808622876029 96.1304006624291
))'
,0)
) AS area;
CREATE TEMPORARY TABLE distanceStorage ON COMMIT DROP AS
SELECT ST_Distance(
ST_GeomFromText('POINT(23.0808622876029 96.1304006624291)',-1)
,ST_GeomFromText('POINT(28.0808622876029 99.1304006624291)',-1)
) AS distance;
height = (SELECT area FROM areaStorage)
/(0.5*(SELECT distance FROM distanceStorage));
IF height < (SELECT radius_meters
FROM gfe_geofences Where is_active=true) THEN
accuracy = "FullConfirm";
RETURN accuracy;
ELSE
accuracy = "PartiallyConfirm";
RETURN accuracy;
END IF;
END;
$BODY$ LANGUAGE plpgsql;
I just want to find two points on boundary of polygon geometry. Just like I have found one from the query:
CREATE TEMPORARY TABLE closePointStorage AS
SELECT ST_AsText(ST_ClosestPoint(geometry
,ST_GeomFromText('POINT(lat lon)',0)
)
) AS closestPoint
FROM (
SELECT ST_GeomFromText(geometry) as geometry
FROM gfe_geofences
WHERE is_active=true
)
AS tempName;
Other then this point I have to find one more with distance greater then the point find above but smaller then the rest of points.
Use ST_DumpPoints() to dump the points of the polygon, then select from that order by ST_Distance to A limit 2. ?
So it is something like
SELECT * from ST_DumpPoints(poly) order by ST_Distance(A,geom) asc limit 2;
(assumes that this is an inner select where poly is the polygon, A is the point to compare to and geom is the geom column of one of the points in the poly being compared)
There generally is no second closest point on the boundary polygon, if you include the lines. Just like there is no real number second closest to zero.
Either you only wish to consider the points at the corners, like Markus suggests.
Or you have only one closest point.
1) Kind of a left-field idea, but to find the second-closest point to your destination, why not find the closest point to the point you already found?
2) Or, more germaine to your specific question,
find the set of points within some reasonable range of the point,
find the intersection of that set with the set of points lying on the polygon border (which I am guessing may be another PostGIS function; haven't used postG in a while so I'm not sure)
3) Farther into left field, dump some of your dataset into Mongo and use the $near function... http://docs.mongodb.org/manual/reference/operator/near/
I am assuming you want to find the edge of the polygon that passes the closest to the point in question
To obtain the distance 'd' of point 'C' from line [A,B]
First translate all points so A is at 0,0
B -= A //vector subtraction
C -= A
Then normalize B so it is of length 1.0
len = sqrt( B . B) //dotproduct of two vectors is the length squared
B /= len //scalar divide by length
Find length from A that is at right angles to C
dotp = B . C //dot product again
closestPointOnLine = B * dotp //scalar multiply
Now get the distance
diff = (C - ClosestPointOnLine)
d = sqrt(diff . diff)
Not sure how to do that in SQL. You will need to do the above for each edge on your polygon, and then find the smallest value 'd'
By the way the sign of the cross-product of B and C will now tell you whether the point is on the inside of the polygon or not