Does Postgis have a Max Distance function for two geographies? It has ST_MaxDistance defined on two geometries:
ST_MaxDistance — Returns the 2D largest distance between two geometries in projected units.
But I'm not able to find a similar function that does the same for two geographies. Does it have that kind of function? As a reference, here would be an example: https://cloud.google.com/bigquery/docs/reference/standard-sql/geography_functions#st_maxdistance. I am not looking to cast the geographies to geometries.
Related
I have two circle on a map with Longitude, Latitude (point()) and Radius and now I would know if there is a SQL function that return true if those circle intersect ?
Thx for help.
Try:
If(ST_Distance(POINT(Long1, Lat1),POINT(Long2, Lat2))<=Radius1+Radius2, "INTERSECT","NO INTERSECTION")
Which is basically asking if the distance between the centers of the circles is <= the sum of their radii. If it is - they intersect.
Try ST_***() functions available in MySQL 5.6.
More information.
https://dev.mysql.com/doc/refman/5.6/en/spatial-relation-functions-object-shapes.html
https://www.percona.com/blog/2013/10/21/using-the-new-mysql-spatial-functions-5-6-for-geo-enabled-applications/
You indeed need to use the ST_*() functions and spatial operator functions, but Zamrony's answer is rather vague. So, what you need to do is to convert your circles into geometry data types and then you can use st_intersect() to see if the 2 circles intersect:
Use ST_Buffer() function to convert point and radius into geometry data type:
Returns a geometry that represents all points whose distance from the
geometry value g is less than or equal to a distance of d, or NULL if
any argument is NULL.
Pls read the description of ST_Buffer_Strategy() as well on how points making up the circle geometries are determined.
Use ST_Intersects() function to determine if the two geometries intersect each other.
we are using rethinkdb geospatial features to calculate distance between two latitude and longitude but the result returned by rethinkdb is different and looks wrong if i cross check on google maps or any distance calculator website. I have copied same code given rethinkdb help.
var point1 = r.point(-122.423246,37.779388);
var point2 = r.point(-117.220406,32.719464);
r.distance(point1, point2, {unit: 'km'})
// result returned
734.1252496021841 km
but when i test same point on http://www.onlineconversion.com/map_greatcircle_distance.htm it return following result 642.1854781517294 km.
Different from some other geo systems, RethinkDB uses the convention of having the longitude first, followed by the latitude.
We made that decision in order for being consistent with the GeoJSON format.
See http://www.rethinkdb.com/api/javascript/point/
From looking at your example, it looks like you've computed the distance correctly in RethinkDB, but entered the coordinates in the opposite direction in the online tool.
With latitude and longitude entered into the correct fields, I'm getting consistent results:
A more advanced note:
There is some difference behind the decimal point. The online calculator claims that "The script uses "Haversine" formula, which results in in approximations less than 1%." by which I assume it means up to 1% error, so this sort of deviation is to be expected.
RethinkDB uses geodesics on an ellipsoid for computing distances, based on the algorithm by C. F. F. Karney 1. This is an extremely precise algorithm, that calculates geodesics up to the limits of double-precision floating point numbers.
You will see even more deviation from Google maps (it gives me 735.234653 km for these two points). It looks like Google maps uses great-circle distances, which do not take the ellipsoidal shape of the earth into account at all.
1 http://link.springer.com/article/10.1007%2Fs00190-012-0578-z
I am having trouble understanding ST_GeomFromText. It looks like there are 3 sets of 2 numbers. Why is that? Wouldn't coordinates just consist of a latitude and longitude?
Here is an example from http://postgis.net/docs/ST_GeomFromText.html:
SELECT ST_GeomFromText('LINESTRING(-71.160281 42.258729,-71.160837 42.259113,-71.161144 42.25932)');
ST_GeomFromText() takes a WKT expression of a geometry object and
Constructs a PostGIS ST_Geometry object from the OGC Well-Known text representation.
The WKT expression in the example is a LINESTRING which is
a one-dimensional object representing a sequence of points and the line segments connecting them.
You might think a linestring would be two-dimensional, but it's not, because a line has no width or height. (Points are 0-dimensional, polygons are 2-dimensional).
So, by definition, that would have more than one set of coordinates. A pair of coordinates would be a POINT, not a linestring, and would look something like this, in conjunction with the function in question:
ST_GeomFromText('POINT (30 10)');
You may want to read up on some GIS fundamentals:
http://www.cise.ufl.edu/~mschneid/Service/Tutorials/TutorialSDT.pdf - excellent tutorial
http://www.opengeospatial.org/standards/orm - OGC Reference Model
I tried using the google.maps.geometry.poly.isLocationOnEdge(position, path, tolerance) function to decide whether the position(lat,lon) pair is within a certain distance (geodesic distance) from a designated path. The API says that the tolerance refers to measurements made in degrees, so one simple way of finding, let's say, points within a buffer radius of 50km from a certain path is to supply the tolerance as being 50/111 degrees (because one can assume that a degree corresponds to 111 km as the traveled distance on a sphere). Unfortunately, this is very erratic and gives many false positives even if they're 200 km away from the path. Am I misinterpreting what that function does?
111km is the length of a longitudinal degree at zero latitude, but this distance is going to vary based on a few factors for different locations. What you need is a function that will calculate the distance (in degrees) between two LatLngs.
See the top answer in this question for an example implementation.
My question is somewhat related to this similar one, which links to a pretty complex solution - but what I want to understand is the result of this:
Using a Mysql Geometry field to store a small polygon I duly ran
select AREA(myPolygon) where id =1
over it, and got an value like 2.345. So can anyone tell me, just what does that number represent seeing as the stored values were long/lat sets describing the polygon?
FYI, the areas I am working on are relatively small (car parks and the like) and the area does not have to be exact - I will not be concerned about the curvature of the earth.
2.345 of what? Thanks, this is bugging me.
The short answer is that the units for your area calculation are basically meaningless ([deg lat diff] * [deg lon diff]). Even though the curvature of the earth wouldn't come into play for the area calculation (since your areas are "small"), it does come into play for the calculation of distance between the lat/lon polygon coordinates.
Since a degree of longitude is different based on the distance from the equator (http://en.wikipedia.org/wiki/Longitude#Degree_length), there really is no direct conversion of your area into m^2 or km^2. It is dependent on the distance north/south of the equator.
If you always have rectangular polygons, you could just store the opposite corner coordinates and calculate area using something like this: PHP Library: Calculate a bounding box for a given lat/lng location
The most "correct" thing to do would be to store your polygons using X-Y (meters) coordinates (perhaps UTM using the WGS-84 ellipsoid), which can be calculated from lat/lon using various libraries like the following for Java: Java, convert lat/lon to UTM. You could then continue to use the MySQL AREA() function.