Given a starting point (origLat, origLon), ending point (destLat, destlon), and a % of trip completed. How do I calculate the current position (curLat, curLon)?
Aviation Formulary is a great resource which covers this question and more.
MTL provides some good content on great circle computations and some working applets you can use to verify your implementation.
In this case, it should be really simple:
curLat = origLat + percentageOfTripCompleted*(destLat-origLat);
curLon = origLon + percentageOfTripCompleted*(destLon-origLon);
*The fact that the earth is a sphere really has no bearing on this problem.
Related
The simple equation for user location using inbuilt inertial measurement unit (IMU) which is also called pedestrian dead reckoning (PDR) is given as:
x= x(previous)+step length * sin(heading direction)
y= y(previous)+step length *cos(heading direction )
We can use the motionManager property of CMMotionManager class to access raw values from accelerometer, gyroscope, and magnetometer. Also, we can get attitudes values as roll, pitch, and yaw. The step length can be calculated as the double square root of acceleration. However, I'm confused with the heading direction. Some of the published literature has used a combination of magnetometer and gyroscope data to estimate the heading direction. I can see that CLHeading also gives heading information. There are some online tutorials especially for an android platform like this to estimate user location. However, it does not give any proper mathematical explanation.
I've followed many online resources like this, this,this, and this to make a PDR app. My app can detect the steps and gives the step length properly however its output is full of errors. I think the error is due to the lack of proper heading direction. I've used the following relation to get heading direction from the magnetometer.
magnetometerHeading = atan2(-self.motionManager.magnetometerData.magneticField.y, self.motionManager.magnetometerData.magneticField.x);
Similarly, from gyroscope:
grysocopeHeading +=-self.motionManager.gyroData.rotationRate.z*180/M_PI;
Finally, I give proportional weight to the previous heading driection, gryoscopeheading, and magnetometerHeading as follows:
headingDriection = (2*headingDirection/5)+(magnetometerHeading/5)+(2*gryospoceHeading/5);
I followed this method from a published journal paper. However, I'm getting lots of error in my work. Is my approach wrong? What exactly should I do to get a proper heading direction such that the localization estimation error would be minimum?
Any help would be appreciated.
Thank you.
EDIT
I noticed that while calculating heading direction using gyroscope data, I didn't multiply the rotation rate (which is in radian/sec) with the delta time. For this, I added following code:
CMDeviceMotion *motion = self.motionManager.deviceMotion;
[_motionManager startDeviceMotionUpdates];
if(!previousTime)
previousTime = motion.timestamp;
double deltaTime = motion.timestamp - previousTime;
previousTime = motion.timestamp;
Then I updated the gyroscope heading with :
gyroscopeHeading+= -self.motionManager.gryoData.rotationRate.z*deltaTime*180/M_PI;
The localization result is still not close to the real location. Is my approach correct?
Given a GEO-JSON polygon, such as the below:
[
[15.520376, 38.231155],
[15.160243, 37.444046],
[15.309898, 37.134219],
[15.099988, 36.619987],
[14.335229, 36.996631],
[13.826733, 37.104531],
[12.431004, 37.61295],
[12.570944, 38.126381],
[13.741156, 38.034966],
[14.761249, 38.143874],
[15.520376, 38.231155]
]
How can I check if a GPS location is within the polygon region?
For example, if the user is at Lat 37.387617, Long 14.458008, how would I go about searching the array?
I don't need someone to necessarily write the code for me, I just don't understand the logic of how I can check. If you have any example (any language) please point me.
This task is called point in polygon test.
Gerve has explained the algorithm that is widley used for this task. But this will not help you in implementing it. There are foot traps, like parallel lines.
One of that algorithms is called Crossings Multiply test, which is an optimized variant.
Source code: CrossingsMultiplyTest (last function in the file)
An Overview is given in "Point in Polygon Strategies"
Use longitude for the x coordinate, and latitude for the y coordinate.
I've found an article about the Ray-casting algorithm. It's explained pretty well here, the jist of it is (in pseudo code):
count ← 0
foreach side in polygon:
if ray_intersects_segment(P,side) then
count ← count + 1
if is_odd(count) then
return inside
else
return outside
I'm trying to measure the distance between two points (longitude, latitude). My problem is that I get different results on iOS then on Android.
I've checked it with this site and the result was that the Android values are correct.
I'm using this MapKit method to get the distance in iOS: distanceFromLocation:
Here are my test locations:
P1: 48.643798, 9.453735
P2: 49.495150, 9.782150
Distance iOS: 97717 m
Distance Android: 97673 m
How is this possible and how can I fix this?
So I was having a different issue and stumbled upon the answer to both of our questions:
On iOS you can do the following:
meters1 = [P1 distanceFromLocation:P2]
// meters1 is 97,717
meters2 = [P2 distanceFromLocation:P1]
// meters2 is 97,630
I've searched and searched but haven't been able to find a reason for the difference. Since they are the exact same points, it should show the same distance no matter which way you are traveling. I submitted it to Apple as a bug and they closed it as a duplicate but have still not fixed it. I would suggest to anyone who wants this to be fixed to also submit it as a bug.
In the meantime, the average of the two is actually the correct value:
meters = (meters1 + meters2)/2
// meters (the average of the first two) is 97,673
Apparently Android does not have this problem.
The longitude and latitude are not all that you need. You have to use the same reference model like WGS84 or ETRS89.
The earth is not an exact ellipsoid, so you need models, none of the models are entirely exact, and depending on which model you use, distances are somewhat different.
Please make sure you use the same reference for iOS and Android.
There is more than one way to calculate distance between long/lat coords based on how you compensate for the curvature of the earth, and there's no right or wrong approach. Most likely the two platforms use a slightly different model.
Here are some formulae for calculating it yourself. http://www.movable-type.co.uk/scripts/latlong.html
If you absolutely need them to be the same, just implement your own calculation using one of these formulae, then you can ensure you get the same result on both platforms.
I have a projectile that I would like to pass through specific coordinates at the apex of its path. I have been using a superb equation that giogadi outlined here, by plugging in the velocity values it produces into chipmunk's cpBodyApplyImpulse function.
The equation has one drawback that I haven't been able to figure out. It only works when the coordinates that I want to hit have a y value higher than the cannon (where my projectile starts). This means that I can't shoot at a downward angle.
Can anybody help me find a suitable equation that works no matter where the target is in relation to the cannon?
As pointed out above, there isn't any way to make the apex be lower than the height of the cannon (without making gravity work backwards). However, it is possible to make the projectile pass through a point below the cannon; the equations are all here. The equation you need to solve is:
angle = arctan((v^2 [+-]sqrt(v^4 - g*(x^2+2*y*v^2)))/g*x)
where you choose a velocity and plug in the x and y positions of the target - assuming the cannon is at (0,0). The [+-] thing means that you can choose either root. If the argument to the square root function is negative (an imaginary root) you need a larger velocity. So, if you are "in range" you have two possible angles for any particular velocity (other than in the maximum range 45 degree case where the two roots should give the same answer).
I suspect one trajectory will tend to 'look' much more sensible than the other, but that's something to play around with once you have something working. You may want to stick with the apex grazing code for the cases where the target is above the cannon.
How'd I go about this one? I want to tween a value from one to another in x time. While also taking into account that it'd be nice to have an 'ease' at the start and end.
I know, I shouldn't ask really, but I've tried myself, and I'm stuck.
Please assume that to cause a delay, you need to call function wait(time).
One simple approach that might work for you is to interpolate along the unit circle:
To do this, you simply evaluate points along the circle, which ensures a fairly smooth movement, and ease-in as well as ease-out. You can control the speed of the interpolation by changing how quickly you alter the angle.
Assuming you're doing 1-dimensional interpolation (i.e. a simple scalar interpolation, like from 3.5 to 6.9 or whatever), it might be handy to use Y-values from -π/2 to π/2. These are given by the sine function, all you need to do is apply suitable scaling:
angle = -math.pi / 2
start = 3.5
end = 6.9
radius = (end - start) / 2
value = start + radius + radius * math.sin(angle)
I'm not 100% sure if this is legal Lua, didn't test it. If not, it's probably trivial to convert.
You may look at Tweener ActionScript library for inspiration.
For instance, you may borrow necessary equations from here.
If you need further help, please ask.