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.
Related
I am using this query to extract the geometries of all countries using BigQuery public dataset, see question here
how to extract all countries geometry from Openstreet map dataset in BigQuery
I use R to draw the results
I tried Kepler.GL and gave me the same results
Something is wrong with Russia and the USA
I know little about R visualization, but what is probably happening is you getting WKT text from BigQuery, and feeding it to R, which has different assumptions.
Tthe issue is your R package probably treats WKT differently than BigQuery. WKT semantics depends on the spatial reference system (SRS) used, which could be geographic (non-projected, using sphere or ellipsoid) or projected (flat map). BigQuery uses geographic system, so edge between points A and B is the shortest geodesic path. Most visualization systems use projected coordinates, and assume flat map. Edge between A and B is shortest straight line on the flat map.
While this does not matter too much in many cases, it still does affect precision when you have long edges. But when an edge crosses anti-meridian (180 degree meridian) you get big problem. An edge between (-169, 66) (eastern edge of Russia) and say (176, 70) (a nearby point on Chukchi sea) is relatively short on the sphere, it crosses anti-meridian, and spans 15 degrees longitude. But the same edge on flat map span 145 degrees longitude and crosses most of the map! These are the long near-horizontal lines you see.
What should you do?
If R has a packet that supports geographic SRS (it is sometime an option to use geodesic edges), you could try it.
Or you can also let BigQuery convert geography from geographic SRS to flat map, that R would understand, using ST_AsGeoJson function. GeoJson is defined on flat map, so BigQuery ST_AsGeoJson converts the semantics from geographic SRS to flat map SRS. You then visualize GeoJson string instead of WKT string in R.
ST_AsGeoJson does a lot of work, to make result conformant to GeoJson spec and flat map. It splits parts of geography that lay east and west of anti-meridian, so you don't get edges that cross it. It also approximates geodesic edges with flat map edges. But it makes visualization system much easier.
So for example, I have two pairs of coordinates: (103.82 W, 32.024 N) and (104.2 W, 32.587 N). I'm trying to figure out how to calculate the distance between these two points and then represent that distance in DMS form. When I use the distance formula, I obtain a decimal number that does not accurately represent my desired number when I convert it to DMS format. I'm supposed to use the distance formula, so I'm not sure what I'm missing here or what I could be doing wrong. I don't believe I need to use the haversine formula for this.
Any help would be greatly appreciated!
The Rosetta Code web site has working code examples in various computer languages (Java, JavaScript, Python, and many others) to compute the distance between two lat/lon coordinates using the Haversine formula.
You can verify your distance results using this online distance calculator for comparison.
Given a coordinate in decimal degrees you can convert that number into the DMS components or vice versa. The formula has been answered in a related answer and there are online converters to convert between DMS and decimal degrees.
I'm working with a postgresql table that contains many rows with a GEOMETRY(Point, 4326). Using the ST_SnapToGrid function and a DISTINCT select, I only extract a subset of rows depending on the displayed map zoom level. I'm having trouble finetuning the ST_SnapToGrid function, as I don't not what unit the size parameter is in?
The size is specified in the same units as the SRID of the geometry.
In the case of SRID 4326 this is decimal degrees. The actual distance
that is of course varies depending on the actual latitude and longitude
of the point in question. If this matters, if might help to work in
some projected coordinates and do the rounding there.
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.
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.