There are a lot of similar questions but I can't get a clear answer out of them. So, I want to represent latitude and longitude in a 2D space such that I can calculate the distances if necessary.
There is the equirectangular approach which can calculate the distances but this is not exactly what I want.
There is the UTM but it seems there are many zones and letters. So the distance should take into consideration the changing of zone which is not trivial.
I want to have a representation such that i can deal with x,y as numbers in Euclidean space and perform the standard distance formula on them without multiplying with the diameter of Earth every time I need to calculate the distance between two points.
Is there anything in Matlab that can change lat/long to x,y in Euclidean space?
I am not a matlab speciallist but the answer is not limited to matlab. Generally in GIS when you want to perform calculations in Euclidean space you have to apply 'projection' to the data. There are various types of projections, one of the most popular being Transverse Mercator
The common feature of such projections is the fact you can't precisely represent whole world with it. I mean the projection is based on chosen meridian and is precise enough up to some distance from it (e.g. Gauss Krueger projection is quite accurate around +-500km from the meridian.
You will always have to choose some kind of 'zone' or 'meridian', regardless of what projection you choose, because it is impossible to transform a sphere into plane without any deformations (be it distance, angle or area).
So if you are working on a set of data located around some geographical area you can simply transform (project) the data and treat it as normal Enclidean 2d space.
But if you think of processing data located around the whole world you will have to properly cluster and project it using proper zone.
Related
I am writing a program that captures real time images from a scene by two calibrated cameras (so the internal parameters of the cameras are known to us). Using two view geometry, I can find the essential matrix and use OpenCV or MATLAB to find the relative position and orientation of one camera with respect to another. Having the essential matrix, it is shown in Hartley and Zisserman's Multiple View Geometry that one can reconstruct the scene using triangulation up to scale. Now I want to use a reference length to determine the scale of reconstruction and resolve ambiguity.
I know the height of the front wall and I want to use it for determining the scale of reconstruction to measure other objects and their dimensions or their distance from the center of my first camera. How can it be done in practice?
Thanks in advance.
Edit: To add more information, I have already done linear trianglation (minimizing the algebraic error) but I am not sure if it is any useful because there is still a scale ambiguity that I don't know how to get rid of it. My ultimate goal is to recognize an object (like a Pepsi can) and separate it in a rectangular area (which is going to be written as a separate module by someone else) and then find the distance of each pixel in this rectangular area, i.e. the region of interest, to the camera. Then the distance from the camera to the object will be the minimum of the distances from the camera to the 3D coordinates of the pixels in the region of interest.
Might be a bit late, but at least for someone struggling with the same staff.
As far as I remember it is actually linear problem. You got essential matrix, which gives you rotation matrix and normalized translation vector specifying relative position of cameras. If you followed Hartley and Zissermanm you probably chose one of the cameras as origin of world coordinate system. Meaning all your triangulated points are in normalized distance from this origin. What is important is, that the direction of every triangulated point is correct.
If you have some reference in the scene (lets say height of the wall), then you just have to find this reference (2 points are enough - so opposite ends of the wall) and calculate "normalization coefficient" (sorry for terminology) as
coeff = realWorldDistanceOf2Points / distanceOfTriangulatedPoints
Once you have this coeff, just mulptiply all your triangulated points with it and you got real world points.
Example:
you know that opposite corners of the wall are 5m from each other. you find these corners in both images, triangulate them (lets call triangulated points c1 and c2), calculate their distance in the "normalized" world as ||c1 - c2|| and get the
coeff = 5 / ||c1 - c2||
and you get real 3d world points as triangulatedPoint*coeff.
Maybe easier option is to have both cameras in fixed relative position and calibrate them together by stereoCalibrate openCV/Matlab function (there is actually pretty nice GUI in Matlab for that) - it returns not just intrinsic params, but also extrinsic. But I don't know if this is your case.
Context: I want to create an interactive heatmap with areas separated by a ZIP code. I've found no way of displaying it directly (i.e. using Google Maps or OSM), so I want to create curves or lines that are separating those areas, and visualize it in maps.
I have a set of points, represented by their coordinates and their according class (ZIP code). I want to get a curve separating them. The problem is that these points are not linearly separable.
I tried to use softmax regression, but that doesn't work well with non-linearly separable classes. The only methods I know which are able to separate non-linearly are nearest neighbors and neural networks. But such classifiers only classify, they don't tell me the borders between classes.
Is there a way to get the borders somehow?
If you have a dense cloud of known points within each Zip code with coordinates [latitude. longitude, zip code], using machine learning to find the boundary enclosing those points sounds like overkill.
You could probably get a good approximation of the boundary by using computational geometry, e.g finding the 2D convex hull of each Zip code's set of points using the Matlab convhull function
K = convhull(X,Y)
The result K would be a vector of points enclosing the input X, Y vector of points, that could be used to draw a polygon.
The only complication would be what coordinate system to work in, you might need to do a bit of work going between (lat, lon) and map (x,y) coordinates. If you do not have the Matlab Mapping Toolbox, you could look at the third party library M_Map M_Map home page, which offers some of the same functionality.
Edit: If the cloud of points for Zip codes has a bounding region that is non convex, you may need a more general computational geometry technique to find a better approximation to the bounding region. Performing a Voronoi tesselation of the region, as suggested in the comments, is one such possibility.
According to the docs it says about 2d indexes:
The 2d index supports calculations on a flat, Euclidean plane. The 2d index also supports distance-only calculations on a sphere, but for geometric calculations (e.g. $geoWithin) on a sphere, store data as GeoJSON objects and use the 2dsphere index type.
Few things I do not understand..
I do not understand what is meant by distance-only, does it mean the Chord (that line which connects two surface points through a line "inside" the surface)?
How does that calculation work against Earth Longitude and Latitude? If that was designed for Euclidean space, how does it express distance in radians?
Instead, using the 2dsphere indexes, it calculates the surface distance correctly between two points, but it works without specifying the 360 longitude lines and the 180 latitude lines. Is it programmed to specially for Earth longitude and latinudes?
If 3. above is correct. does it takes into account that Earth is oblate spheroid and not a perfect sphere?
No. It means the surface distance using the Haversine formula.
I'm not sure what you are trying to ask in regards to "how does it express distance in radians" but if you mean how are lat/lon angle values and deltas converted into radians it is: PI * angle / 180.0. For the full Haversine formula, check out this link for implementations in 84 languages: http://rosettacode.org/wiki/Haversine_formula
2dsphere indexes use the WGS84 datum (which defines the bounds) See: http://spatialreference.org/ref/epsg/4326/.
Without looking at their code it is impossible to say. But given that they use WGS84 and talk about an "earth-like sphere" it is highly doubtful. I'm guessing they use Haversine (so distance calculations are only an approximation).
I'm having problems with st_distance function in postgis. I have three ways to calculate the distance, but I don't know which one is the most accurate.
SELECT ST_Distance('POINT(115.25 39.26)'::geography, 'POINT(117.30 41.04)'::geography) as distance;
--result is 263753.911823565
SELECT ST_Distance_Sphere(ST_GeomFromText('POINT(115.25 39.26)',4326), ST_GeomFromText('POINT(117.30 41.04)',4326)) as distance;
--result is 263674.468686404
SELECT ST_Distance( ST_Transform(ST_GeomFromText('POINT(115.25 39.26)',4326),32650),ST_Transform(ST_GeomFromText('POINT(117.30 41.04)', 4326),32650)) as distance;
--result is 263669.651755417
The difference between the 3 measurement calculations is the following:
The distance is calculated over the spheroid, a mathematical approximation of the earth's surface taking the flattening at the poles into consideration. This is also called the "great arc distance". In this case the default spheroid is WGS84, which is also used by the GPS system and satellite imagery.
The distance is calculated over a sphere, which does not considering flattening (the shape is effectively like a ball). Usually the sphere has the same volume as some spheroid so it is slightly smaller at the equator and slightly bulging at the poles. It is mathematically much simpler than the spheroid and therefore lots faster to calculate.
The distance is calculated on a cartesian coordinate reference system (a plane) established by transforming from geographic coordinates, in this case UTM50N from a WGS84 spheroid.
The first method usually gives the best result (of these 3), but for coordinates that are close together or close to the Equator, the difference would be negligible compared to the faster second method.
The third method is not particularly accurate with the UTM50N(WGS84) coordinate reference system, but a cartesian coordinate system has important other benefits, such as calculating angles between triplets of points or areas of polygons. Also note that some datums in use with local CRSes give a much better local representation of the earth's irregular surface than WGS84 does, in which case a local CRS becomes much more accurate than a great-arc calculation. You would have to look up all the geodetic details of your area to assess that.
I have data describing a rotated ellipse (the center of the ellipse in latitude longitude coordinates, the lengths of the major and minor axes in kilometers, and the angle that the ellipse is oriented). I do not know the location of the foci, but assume there is a way to figure them out somehow. I would like to determine if a specific latitude longitude point is within this ellipse. I have found a good way to determine if a point is within an ellipse on a Cartesian grid, but don't know how to deal with latitude longitude points.
Any help would be appreciated.
-Cody O.
The standard way of doing this on a Cartesian plane would be with a ray-casting algorithm. Since you're on a sphere, you will need to use great circle distances to accurately represent the ellipse.
EDIT: The standard ray-casting algorithm will work on your ellipse, but its accuracy depends on a) how small your ellipse is, and b) how close to the equator it is. Keep in mind, you'd have to be aware of special cases like the date line, where it goes from 179 -> 180/-180 -> -179.
Since you already have a way to solve the problem on a cartesian grid, I would just convert your points to UTM coordinates. The points and lengths will all be in meters then and the check should be easy. Lots of matlab code is available to do this conversion from LL to UTM. Like this.
You don't mention how long the axes of the ellipse are in the description. If they are very long (say hundreds of km), this approach may not work for you and you will have to resort to thinking about great circles and so on. You will have to make sure to specify the UTM zone to which you are converting. You want all your points to end up in the same UTM zone or you won't be able to relate the points.
After some more research into my problem and posting in another forum I was able to figure out a solution. My ellipse is relatively small so I assumed it was a true (flat) ellipse. I was able to locate the lat lon of the foci of the ellipse then if the sum of the distances from the point of interest to each focus is less than 2a (the major axis radius), then it is within the ellipse. Thanks for the suggestions though.
-Cody