I'm building an augmented reality game, and working with CLLocation is rather cumbersome.
Is there some way to locally approximate CLLocation as XYZ coordinate, expressed in meters with the origin starting at some arbitrary point (for example the initial position when the game was started)?
Lets say I'm working with a 1 mile radius and do not really care about the curvature of the earth. Is it possible to approximate or somehow simplify the location based calculations for local position tracking?
Alternatively, is there a coordinate system that can be used with CLLocation that also incorporates the roll, pitch, yaw of the CMAttitude as well as compass orientation?
Clarification: As far as I understand, the problem with latitude and longitude is that their units vary in size, depending on the position on the globe. I should've specified that X,Y,Z should be in standard units, like meters or feet.
Thank you!
The Haversine formula may be useful.
I found a good article on it at http://www.jaimerios.com/?p=39 with code examples.
You could get the initial point at the app's launch and calculate the relative points based on the user coordinates as he or she moves. Admittedly, this is not super elegant, but if you are just trying to do some simple comparisons based on the user's location relative to an arbitrary origin, this should work. For the Z, Alex Stone's suggestion of calculating it based on the altitude should be fine.
Related
I'm trying to make a Unity game that allows the user to explore the surface of an Earth shaped spheroid, based on WGS84.
The project so far is on Github, and there's a YouTube video of this behaviour.
A shape the size of Earth is way too big for Unity, so I just spawn tiles near the user, offset so that the first tile is at Unity's origin point. This bit works.
The issue is moving around. I've been using an approach where I get the user's position in ECEF coordinates, then normalise that to provide the global orientation for the player, then I translate the player forward based on that and their rotation.
The issue with this is that normalising the ECEF coordinate means that the player is moving in a spherical shape, but the WGS84 spheroid is not perfectly spherical. So the player sinks into the floor, or flies up if you got south or north, respectively.
My question is, how can I allow the user to move around the surface of the spheroid by way of translation? I feel like there might be some way of taking the major/minor axis of the spheroid into account as the player moves, but I'm not sure how to do that.
I have no experience with Unity or computer graphics, I'm approaching it purely from the navigation point of view.
Let's look at the real world.
We want to travel either by walking/driving on the surface or flying at some altitude. When we do it, we move in the local coordinate system (North-South, East-West, Up-Down), we can't see any curvature. We assume the Earth is flat.
The problem arises when we try to do it on a computer, which is ruthlessly precise and knows the shape of the Earth. We can't assume the Earth is flat, we can't assume the Earth is a sphere. The Earth is a geoid. Fortunately for some purposes we can simplify things and assume the Earth is an ellipsoid. You chose WGS84. Good!
So how to move around an ellipsoid? Solving the problem analitically is a nightmare. We have to cheat ;)
We should assume te Earth is flat for a moment, make a move in a chosen direction in the local coordinate system, write down the altitude of the new position, calculate the global geodetic coordinates (Lat, Long, Alt) of that new point and then replace the altitude with the one obtained while using the local coordinate system. In other words: each time we move forward along a perfectly straight line and diverge from the ellipsoid (just a tiny bit), we force the altitude not to change in relation to the ellipsoid.
Implementation.
You need to be able to freely translate coordinates between geodetic (Lat, Long, Alt) and ECEF. Going from geodetic to ECEF is easy. Finding geodetic coordinates for a given ECEF position is much more complex, there are many different algorithms, I'm sure you should be able to find a ready to use implementation somewhere.
What you also need is Local Tangent Plane, and to be precise, you are going to use NED.
Let's assume your object is initially at some geodetic position. You write down the altitude (relative to the ellipsoid). Then you create a local NED coordinate system with its origin at that point. Then you move the object in that local coordinate system. You write down how much the altitude (or rather the Down coordinate) changed. Then you must calculate the ECEF coordinates of that new position and transform it to geodetic (Lat, Long, Alt). You have the old altitude, you have the altitude change in the NED coordinates, which means you know the new altitude. You then apply that altitude to your new geodetic coordinates (brutally replace the Alt in Lat/Long/Alt with a new value).
Then you make another move in the NED coordinates defined for that new position. And so on...
I'm not sure if it is clear, the process is quite complicated. If you can't understand - shout :)
May I know how I should calculate the bearing of one point relative to another? All the formulas I'm seeing on the Internet are for lat/lon coordinates. I'm working with the Cartesian coordinate system here and am unable to find a solution. Please help!
Use atan2 function (IIRC your objective-c should have it).
It gives you a result between -PI and PI. You have to map it to 0-360 if you need it.
Not really an answer to your question, but if you're getting your points using CLLocationManager, each CLLocation has a course property, which gives you the bearing of your journey for the given point. For the actual math, see Axeman's answer.
I have a series of nature reserves that need to be plotted, as polygon overlays, on a map using the coordinates contained within KML data. I’ve found a tutorial on the Apple website for displaying KML overlays on map instances.
The problem is that the reserves vary in size greatly - from a small pond right up to several hundred kilometers in size. As a result I can’t use the coordinates of the center point to find the nearest reserves. Instead I need to calculate the nearest point of the reserves polygon to find the nearest one. With the data in KML - how would I go about trying to achieve this?
I've only managed to find one other person ask this and no one had replied :(
Well, there are a couple different solutions depending on your needs. The higher the accuracy required, the more work required. I like Phil's meanRadius parameter idea. That would give you a rough idea of which polygon is closest and would be pretty easy to calculate. This idea works best if the polygons are "circlish". If the polygon are very irregular in shape, this idea loses it's accuracy.
From a math standpoint, here is what you want to do. Loop through all points of all polygons. Calculate the distance from those points to your current coordinate. Then just keep track of which one is closest. There is one final wrinkle. Imagine a two points making a line segment that is very long. You are located one meter away from the midpoint of the line. Well, the distance to these two points is very large, while, in fact you are very close to the polygon. You will need to calculate the distance from your coordinate to every possible line segment which you can do in a variety of manners which are outlined here:
http://www.worsleyschool.net/science/files/linepoint/distance.html
Finally, you need to ask yourself, am I in any polygons? If you're 10 meters away from a point on a polygon, but are, in fact, inside the polygon, obviously, you need to consider that. The best way to do that is to use a ray casting algorithm:
http://en.wikipedia.org/wiki/Point_in_polygon#Ray_casting_algorithm
Can GPS on a phone, such as iPhone or Android determine your Z coordinates ?
I know it certainly has to be able to determine X and Y, well longitude, latitude that is, but what about the Z coordinates ? Can it determine your height, and can I obtain height relative to ground ?
Height, as measured by a gps, is relative to the WGS84 ellipsoid. The WGS84 is representative of the field where the gravity is the same, the geoid. Not quite the same as the ground.
You can determine altitude with iPhone using CoreLocation
http://developer.apple.com/iphone/library/documentation/CoreLocation/Reference/CLLocation_Class/CLLocation/CLLocation.html
Android surely can ... have a look at the features of e.g. MyTracks which include even evaluation profiles.
Altitude, however, is usually measured in "above sealevel", which means, that you could determine the distance from the ground by substracting the ground evaluation from your actual evaluation: ev(ground) - alt = distance(fromGround).
I'd like to know (from a high level view) what would be required to take a pdf floor plan of a building and determine where exactly you are on that floor plan using GPS coordinates? In addition to location, the user would be presented with a "turn by turn" directions to another point on the map, navigating down hallways, between cubicles, etc.
Use case: an iPhone app that determined a user's location and guided them to a conference room or person's office in the building.
I realize that this is by no means trivial, but any help is appreciated. Thanks!
It's an interesting problem. When you're using Core Location, you're not necessarily using GPS. Using WiFi and cell tower triangulation, you can get pretty good location results. So from Core Location you get a latitude and longitude fix. (You might also get altitude info, since GPS data is 3-dimensional. You also will get an accuracy value.)
So you have lat and lon. You need to map these coordinates to the PDF plan's coordinates. Assuming that the plan is aligned with the latitude and longitude lines, and that you have a lat-long fix for one of the points on the plan, you need to calculate the x-axis scale and y-axis scale. Then it's some calculations to map the lat-long to x-y coordinates on the PDF plan.
GPS may not be accurate enough for this purpose, especially indoors. Assuming errors on
the order of 10 meters, you'll have difficulty determining which floor the user is on.
Here's a neat (?) idea that might work: can you post some "You are here" placards
at various locations around the building? You could label each one with a unique,
machine-readable location code (maybe a QR code or something similar), then take an
image using the camera, have your app read that image and interpret the location code,
and use that instead of GPS to determine the start location.
GPS inside? That's your first -- and biggest -- hurdle.
Next hurdle is knowing the GPS coordinates of at least three points on that PDF to define the plane of of your map in the real world. (The PDF will need to be to scale, of course.)
So that gives you where you are on the PDF. Now you'll need to figure out some way to determine where you can walk (or where you can't) to get directions.