Today in class wev'e been introduced to the haversine function. the describtion of the function goes like this : "This uses the ‘haversine’ formula to calculate the great-circle distance between two points – that is, the shortest distance over the earth’s surface – giving an ‘as-the-crow-flies’ distance between the points (ignoring any hills they fly over, of course!)."
The goal is to load a csv file that inclued lat,lon and alt of a point and calculate the distance of 2 coordinates on earth.
My question is: how do I integrate the haversine function with the altitude factor?
Related
I have two coordinates with latitude and longitude, and I want to calculated the distance between them in meters/miles. Does the vividsolutions JTS library have the functionality to do this? If there is a function I can use please point me to it, thanks!
JTS Will calc distance with the measurement unit the SRID is based on (so if you're using 4326 the number will literally be the diff in lat/lng). If you can convert to an SRID that is metric based, you can get a measurement in meters using distance, or distance3d (if your objects have a 3rd dimension for elevation). Then convert that to other units if you need to.
You can also do the math, but isn't a basic conversion - it takes into account the radius of the earth, and other geometric issues (things the spatial reference will do for you). If prefer that way search for something like "convert lat long to meters" and something will pop up.
There is geopoint array, one point with longitude and latitude as the center and radius. It takes to choose only those ones which are within the radius. One more thing is that the points are close to prime meridian. Can you advise the solution for it or some java libraries?
I have a position given in decimal degrees (x.xxxxxxxx and y.yyyyyyyy). I need to draw a rectangle around it. The center of the rectangle matches the position. The dimensions of the rectangle is given in meters and it has a rotation ranging from 0-360 degrees.
Question
How can I calculate the four corners of the rectangle and return the result as four decimal degree values? Like arrayOf<LatLon> getRectangle(LatLon position, int rectWidthCm, int rectLengthCm, double rectRotation).
Example
I have a position given in LatLon format with two two values: latitude and longitude. We will assume this location is precise.
The main task is to draw a rectangle based on this position in a Google Maps chart. The rectangle can have any dimentions but let's use these in this example: Width = 0.9 meter and Length = 1.2 meters. Any heading may also be given so lets use this heading: 45. 0 Is north and going clockwise round (east = 90, south = 180 and west = 270). When the rectangle is pointing north it has the length in the north/south direction. Finally, the rectangle center should be equal to the given position.
Note: The project setup is an Android application with Kotlin support and a google maps chart. I am interested in a modern approach to this problem. Regarding precision loss it should at most be within centimeters.
I understand that you are looking for a function geo_rect(x,y,w,h,a) with the following parameters
x is the longitude according to WGS84
y is the latitude
w is the width of the rectangle in meters
h is the height of the rectangle in meters
a is the angle to which the rectangle is turned from w being horizontal (meaning pointing exactly West to East). I suggest to allow values ranging within the open interval (-90°,90°) as this makes the math either to understand.
Your function getRectangle(LatLon position, int rectWidthCm, int rectLengthCm, double rectRotation) deliver all the required information, you need a small wrapper function which determines w, h, and a from rectWidthCm, rectLengthCm and rectRotation, with the latter being within [0°,360°).
The function geo_rect() will return an arrayOf<LatLon> of length four, namely the coordinates of all four corners, starting on the top left and then going clockwise. We will refer to the points as P_NE,P_NW,P_SE, and P_SW respectively.
Assumptions
In order to keep things mathematically feasible, we make some assumptions
We assume that we can use as approximation that the rectangle is a plane, which is okay if w ~ h << r with r = 6378 km being the radius of the Earth.
We further assume that the Earth is a ideal sphere rather than an ellipsoid or even more bumpy. For an accessible article on that issue, see e.g. Zachary C. Eilon's blog
Basic structure of the algorithm
The algorithm could be structured as follows:
Determine the distance d from (x,y) to all four end points. Because of our first assumption we can use simple Euclidian geometry rather than intricate Spherical geometry. Pythagoras holds: d^2 = (w/2)^2 + (h/2)^2.
We also need the four bearings, e.g. b_NW for the angle between the vector pointing to the North Pole and the vector pointing from (x,y) to point P_NW.
Given the information (x,y,d,b_NW, b_NE, b_SW, b_SE) from the previous steps, we can now follow Get lat/long given current point, distance and bearing to calculate the position of all four points. This is the mathematically hard part where I suggest to use a well-established and tested library for.
Last but not least, let us double-check whether the calculation went well by evaluating Great circle distances between some or all pairs of points. For instance d(P_NE,P_NW) should approximately be w, d(P_NW,P_SW) should approximately be h. Don't be surprised if there is actually a difference - this errors are due the assumptions we made. Normal GPS under usual conditions will anyhow not allow you to determine your position up to the centimeter, you will need DPGS for that.
Further reading
At https://www.movable-type.co.uk/scripts/latlong-vectors.html you can experiment online to determine a destination point along a great-circle given the distance and bearing from a start point (in our case: the center of the rectangle).
Old, but amazingly documented and well tested tool kit for geo-applications in general are the https://www.generic-mapping-tools.org/ - you might want to look at the command gmtvector.
If you are looking for java implementations, I found e.g.
https://introcs.cs.princeton.edu/java/12types/GreatCircle.java.html on of many implementations for calculating great circle distances
Need a standalone Java library for performing spatial calculations on lat/lon data
Calculate point based on distance and direction
So I am working with a set of images where the the corners are the lat long on the map. I am creating Polygons to check if there is overlap of the given images. I need to know the units associated with the .getarea() methods for both Polygon and geometry. I'm using the following objects to create my polygons and geometry
http://tsusiatsoftware.net/jts/javadoc/com/vividsolutions/jts/geom/Geometry.html#getArea()
http://www.vividsolutions.com/jts/javadoc/com/vividsolutions/jts/geom/Polygon.html
When using both of the above objects I get a number back however I have found no indication on what the units associated with the number are. So are we talking meters, kilometers, miles?
a sample of cordinates i'm using are
+30.658739 -086.345670, +30.659997 -086.34002, +30.664041 -086.345082, +30.662783 -086.342750 I'm looking for the area between these 4 points.
the value i get back from the .getArea() is 1.31039680000139E-5 The points are realitively close so i'm thinking its in meters which would be 1310.4 meters
This is difficult to tell without knowing what the underlying coordinate system is. After taking a quick glance at the Javadoc API you linked to, I suspect that your geometry package is probably dealing in raw cartesian coordinates and is agnostic about the units of measurement being used. If this is the case, you are on a very slippery slope. Here's the problem:
Not All Degrees Are Created Equal
Degrees in latitude all have the same spatial resolution. Each degree of latitude corresponds to roughly 111km of distance. This is not the case for degrees of longitude. At the equator, degrees of longitude correspond to 111km of distance, but at the poles, 1 degree of longitude has ZERO km of distance. In other words, if you have a Lat/Lon box with the upper left at 10:0 and lower-right at 0:10, it will have more surface area than a Lat/Lon box with upper left at 20:0 and lower-right at 10:10, even though the sides of those boxes are all 10 degrees long.
A second issue is the curvature of the earth. Because of the earth's curvature, a 100km by 100km square on the earth's surface will have more surface area than 10000 km^2, because the shortest distance from one point on the earth's surface to another is not actually straight line, but an arc.
A third and often-overlooked but less-important issue is that the Earth is not actually a sphere, but an ellipsoid. It tends to bulge near the equator, which breaks our assumption that a degree of latitude anywhere on earth is the same distance as another degree of latitude anywhere else. However, this issue does not introduce as much error into our surface area estimates as the first two.
In other words, spherical (or in reality, ellipsoidal) surface area isn't an easy problem to solve, at least not as easy as mapping to cartesian coordinates and using them to find euclidean measurements of surface area. You can get away with it if the surface area you are dealing with spans a very small angular distance, but the larger your lat/lon box is, the more distortion you get.
Possible Solution
This only works if your images are rectangular and top/bottom of the image have constant latitude from left-to right. This still introduces more error with wider ranges of latitude because it still ignores the curvature of the earth, but does a better job than assuming all degrees are created equal in a cartesian coordinate system. If this is the case, then the intersection of your image will be bounded by the following coordinates:
topLat:*leftLon*, bottomLat:*rightLon*
Calculate the average latitude, then use it to find distance per degree of longitude at that average latitude, kmPerLon. We now have the following equation:
area = ((topLat - bottomLat) * 111km) * (rightLon - leftLon) * kmPerLon)
The area you get from this will be measured in square kilometers, but again, I'd like to reiterate that this only works reasonably well if your images are rectangularly aligned to parallel latitudes and do not span much angular distance.
CodeBlind is correct that the library is unit-agnostic. The units aren't in the Javadoc because JTS has no opinion on the subject. You can use whatever units you want. If your units are inches, area will be in square inches. If you're using feet, area will be in square feet... and so on. If your numbers are in degrees, then your area is in degrees squared.
What are the distance units in com.vividsolutions.jts.geom.Geometry class?
From that post Distance is in radian (and I have proven it). Then I wonder if the area is also in radian. So I tried it with this:
Math.toRadians(polygon1.getArea()) * 6371000 * 100 => this one become square kilometers.
I don't know if this is accurate or not. But it came pretty close
Given a point coordinates(latitude/longitude) and an array of latitude/longitude representing a polygon. How do I get the distance from the point to the polygon, using OpenMap API?