I create a polygon where each x/y point is WGS84 format
lat/long values.
The polygons are good approximations to circles and sectors of
radius R (each circumference/arc point is a projected lat/long
value of distance R from a centre/apex coordinate - which I have
verified is correct by computing the Haversine distance between
the edge and reference points and getting a value of R back) .
I use GEOSSetSRID(4326) to indicate the coords are WGS84 format.
GEOSGetSRID() confirms the SRID is set.
Use of GEOSArea then gives a value not even remotely close to
the expected value.
I do not see what else I can programmatically do.
If I set the points in cartesian format, and then set the SRID to
4326, will GEOS implicitly convert the polygon points to WGS84 ??
Is the basic GEOS C API incapable of doing the above ??
Dos SRID have no meaning to the API at all ??
Any info/pointers to correct usage/solutions would be much appreciated.
TIA.
The distance that is given is something like degrees between the two points. In actuality, the GEOS API (at least the C++ interface) is units agnostic; the units it gives the distance in is based on whatever you passed in.
In general, multiplying the result you get by 111000 gives you a fairly accurate measurement in meters. For area, you have to do 111000^2.
Related
I am trying to figure out a way to convert the result of presto geo spatial function ST_DISTANCE to meters.
If I run the this example query:
SELECT ST_Distance(ST_Point(0.3476, 32.5825),ST_Point(0.0512, 32.4637))
The result I get from Presto is: 0.3193217812802629. The actual distance between these two places is 40,000m.
The presto documentation states that ST_DISTANCE: Returns the 2-dimensional cartesian minimum distance (based on spatial ref) between two geometries in projected units.
What I can understand about spatial ref is at links such as these:
http://webhelp.esri.com/arcgiSDEsktop/9.3/index.cfm?TopicName=Defining_a_spatial_reference
Which leads me to believe I need to figure you what spatial-ref Presto is using.
If I check the prest docs here:
https://github.com/prestodb/presto/blob/master/presto-geospatial/src/main/java/com/facebook/presto/geospatial/GeoFunctions.java
I can guess that is using the ESRI libraries so I assume the ESRI spatial ref? But that is where I get a bit lost as to where to proceed?
Thank you for your help..
I would recommend using Presto’s great_circle_distance() function instead of ST_Distance(). It will interpret your coordinates as WGS84 (aka EPSG:4326), and find the distance between them in kilometres by treating the shape of the earth as a sphere.
ST_Distance() would be appropriate if the coordinate system being used was already projected into a system that used metres or miles or some other unit, but there's no trivial way to do that in Presto.
From looking at the docs, it appears that presto supports a geometry type but not a geography type. That means it's not working with Latitude and Longitude, which is what I assume you're supplying as those point parameters. It's just an arbitrary 2D grid and so the resulting units are in whatever units you supplied as input.
The distance, in meters, between two points which are both approximately 32.5 meters "up" from the origin and about 0.5 meters "left" from the origin (how presto will have interpreted your points) is, indeed, 0.3193217812802629, the value that was returned to you.
How to calculate Altitude from GPS Latitude and Longitude values.What is the exact mathematical equation to solve this problem.
It is possible for a given lat,lon to determine the height of the ground (above sea level, or above Referenz Elipsoid).
But since the earth surface, mountains, etc, do not follow a mathematic formula,
there are Laser scans, performed by Satelites, that measured such a height for e.g every 30 meters.
So there exist files where you can lookup such a height.
This is called a Digital Elevation Modell, or short (DEM)
Read more here: https://en.wikipedia.org/wiki/Digital_elevation_model
Such files are huge, very few application use that approach.
Many just take the altidude value as delivered by the GPS receiver.
You can find some charts with altitude data, like Maptech's. Each pixel has a corresponding lat, long, alt/depth information.
As #AlexWien said these files are huge and most of them must be bought.
If you are interest of using these files I can help you with a C++ code to read them.
You can calculate the geocentric radius, i.e., the radius of the reference Ellipsoid which is used as basis for the GPS altitude. It can be calculated from the the GPS latitude with this formula:
Read more about this at Wikipedia.
Currently I'm trying the following: I have points from google earth (WGS84) which I want to transform to a local x,y coordinate system: a tangential plane with y positive from south to north and x positive from west to east.
There is no need for the plane to be part of a global coordinate system more than the relation (x=0, y=0) = (lat,lon). The scale at which I'm working is in the order of say 100 kilometers (maximum of for example 200 km's). Very small errors (due to for example the curvature of the earth) are acceptable.
I have relatively little understanding of this topic as of yet. Can anybody help me out? Where would I need to look for example.
Thanks!
I haven't found the answer mathematically but have found that the package basemap (of the mpl_toolkit) should help with this respect (from wgs84 to a transverse mercator projection).
I have GPS coordinates provided as degrees latitude, longitude and would like to offset them by a distance and an angle.E.g.: What are the new coordinates if I offset 45.12345, 7.34567 by 22km along bearing 104 degrees ?Thanks
For most applications one of these two formulas are sufficient:
"Lat/lon given radial and distance"
The second one is slower, but makes less problems in special situations (see docu on that page).
Read the introduction on that page, and make sure that lat/lon are converted to radians before and back to degrees after having the result.
Make sure that your system uses atan2(y,x) (which is usually the case) and not atan2(x,y) which is the case in Excell.
The link in the previous answer no longer works, here is the link using the way back machine:
https://web.archive.org/web/20161209044600/http://williams.best.vwh.net/avform.htm
The formula is:
A point {lat,lon} is a distance d out on the tc radial from point 1 if:
lat=asin(sin(lat1)*cos(d)+cos(lat1)*sin(d)*cos(tc))
IF (cos(lat)=0)
lon=lon1 // endpoint a pole
ELSE
lon=mod(lon1-asin(sin(tc)*sin(d)/cos(lat))+pi,2*pi)-pi
ENDIF
This algorithm is limited to distances such that dlon <pi/2, i.e those that extend around less than one quarter of the circumference of the earth in longitude. A completely general, but more complicated algorithm is necessary if greater distances are allowed:
lat =asin(sin(lat1)*cos(d)+cos(lat1)*sin(d)*cos(tc))
dlon=atan2(sin(tc)*sin(d)*cos(lat1),cos(d)-sin(lat1)*sin(lat))
lon=mod( lon1-dlon +pi,2*pi )-pi
Actually I have the decimal values of latitude and longitude.
In a 2d referential, are those values the x an y coordenates?
example :
in a position P
latitude = 41.15 longitude = -8.64
So, in a 2d dimension P is defined by (41.15,-8.64) ?
Thanks
No, its exactly opposite:
The coordinate (lat, lon) corresponds to the pair (y,x)
So when passinge lat, lon to mathematical routines, like point in polygon calculations
pass in order (lon, lat).
longitude raises parallell to the aequator, which corresponds to our x achsis direction we normally use in cartesian (x,y) systems.
Unfortunatley for historical reasons, the latitude is often written before longitude. (The cause might be that the latitude was easier to determine than the longitude.)
This all leads for us SW developpers to the bad situation, that sometimes functions use (lat,lon) order, sometimes when working with transformations from (lon,lat) to (x,y) or mathematical routines, the order lon, lat must be used. Be careful, every person I know someday has accidentally exchanged that.
In your example:
P is related to (-8.64), 41.15).
But lat,lon are spherical coordinates, for most application you must convert them to cartesian (x,y) .
But this is another question.
Be careful with units. In systems like Google Maps, those numbers are usually in degrees. Usually.
They might also be in radians, though, so at least make sure of what unit the API is using.