do you know the planets radii ?
from that you can calculate the pixels per meter and meters per degree
then for elevation change if it is a simple altitude change , then simple trig is all you need
sin = height/distance
I need a formula that can give me the straight line distance between two points given latitude, longitude, and elevation above sea level in meters. I've been experimenting with converting to Cartesian coordinates and using pythagorean but it's not working. Do I need wgs84? Can someone dump me a formula? Preferably something that uses Cartesian coordinates.
Posted mobile using Tapatalk
do you know the planets radii ?
from that you can calculate the pixels per meter and meters per degree
then for elevation change if it is a simple altitude change , then simple trig is all you need
sin = height/distance
--- 90 seconds to Midnight ---
--------
--- Penguin power!!! ---
It's earth. And I'm doing all of this in 3d space not imagery so I need all math to end up in meters. I'm basically trying to get the cuz coordinates of two points given lat/lon/el and then pythagorean theorem to get the distance between them. But my formula isn't working. I'm thinking it's because I'm not using a wgs84 ellipsoid but I don't know where to begin.
This is for a flight simulator at my day job btw.
Posted mobile using Tapatalk
http://williams.best.vwh.net/avform.htm should have something to interest you. LLA to ECEF on the two points and then take the Euclidean distance will give you the chord distance, which you're never going to be able to travel unless you are very good at tunneling.
Well this is for a flight simulator and all the distances will be usually within one geocell. So most of the straight line measurements will do just fine. But I've heard of great circle math. Is that something I should consider? Because if you travel 0.3 degrees at 5000 feet above sea level that's represented differently than 0.3 degrees at 1000 feet above sea level right?
Edit, I click the link you posted after my reply and the first thing I see is great circle navigation. Lol
Posted mobile using Tapatalk
You could take a look at Vincenty's formulae https://en.wikipedia.org/wiki/Vincenty's_formulae
If you want to see an implementation of geodetic distance, you could take a look at PostGIS's function here: https://github.com/postgis/postgis/b...odetic.c#L2084
You should be able to do it with cartesian + pythag if your assuming that the coordinate system is a sphere. WGS84 coords are spherical from a datum of the centre of earths gravity so it ought to be ok. If your not in WGS84 then it depends on the datum used and you can be a few hundred meters out if you dont use the correct elipsoid. Us brits get collard by this since almost every map you see in the UK is OSGB which means you need to set up a GPS datum or else its out. Extrapolating the OSGB elipsoid to the whole earth and you would be miles out on the other side of the planet. I have the formula to convert OSGB to WGS84 and back but it turns out that there is no single step you can do it in. You have to run it itteratively ! Bizarre but true. I dont have any datum to WGS84 but I am sure GDAL would be able to do this tho I have never looked.
I just had a shower thought and realized I'm thinking in meters and passing in altitude in feet. That oughta throw off my results. Will check that at work today and see what I get. Ultimately it looks like I need to learn gdal. Does it have a c# wrapper?
Posted mobile using Tapatalk
http://trac.osgeo.org/gdal/wiki/GdalOgrInCsharp suggests that there might be C# bindings.
The WGS84 datum is not a sphere, it's a spheroid.
As for datum shifts, GDAL requires special data files describing the transformation between datums (In geography this is the correct plural) and those transformations are specific to a particular pair of datums, for a particular region, and sometimes for a particular time. Depending on the distribution of GDAL you are using, you might get some transformations, particularly some common ones like transforming between NAD83 and WGS84 within North America.
That said, I don't expect Robbie's use case will require datum shifts, it should all be doable in a single datum, be it WGS84 or something else. GDAL/OGR is probably overkill. Proj.4 is a more focused library that can do the same thing in terms of coordinate system transformation, including datum shifts, but without all the additional geometry (OGR) and raster handling (GDAL).