I need to find points (from a rather small dataset) which are close enough to a polyline. All coordinates are WGS84.
I think of some r-tree thing to reduce the data to just a few candidates which then have to be checked in more detail.
While i managed to do this using "great circle" arithmetic, i am sure this is too pedantic for the following reasons:
The segmentation of those polylines is quite high. A single segment of a polyline can be considered to be no longer than 10 km.
The points in question are not more than a few hundred meters away from segments.
The area in question is Europe, so the algorithm does not need to be valid for extreme (near pole?) conditions. Again: points don't need to be checked agains the whole polyline (which could be hundrets of kilometers). Only the "nearby" segments need to be considured.
Do i need to transform the WGS84 coordinates to
some local cartesian reference system
to a mercator system
Or can i even just calculate with "angle differences"? I know that this is just a matter of accuracy: I can accept an error which is below ~50 meters.
I highly appreciate your suggestions!
On how to measure distance from point to polyline:
you have to measure distances from all your points to all segments of a polyline.
See Distance from a point to a polygon
You can do without converting coordinates to cartesian (especially if the area is rather small, you don't mind 50 meters error and you don't need exact distances, just relative) See https://en.wikipedia.org/wiki/Decimal_degrees.
The curve is in fact the trajectory of a bus, the curve is represented by many (up to a few thousand) discrete points on the curve (the points were recorded by a GPS device installed on the bus).
Input a point P, I need to find the closest point on the curve to the point P. The point P is usually no more than 30m away from the trajectory of the bus. Note, the closest point isn't necessary a point recorded by the GPS device, it could be a point somewhere between two recorded points.
First I need an algorithm to recover the trajectory from those recorded points. It would be great if the interpolated curve could show sharp turns made by the bus. Which curve is best for such task ? Is Bezier curve good enough ? And finally I have to calculate the closest point on the curve, of course the algorithm completely depends on the kind of curve chosen.
I'm doing some research, and don't have much knowledge in curve interpolation, so any suggestions are welcome.
For computing the trajectory from recorded points, I recommended using the centripetal or chord-length Catmull-Rom splines. See link for more details. Catmll-Rom splines are in fact special cubic Hermite curves, which can be easily converted into cubic Bezier curves. Please note that the result from Catmull-Rom spline is a G1 curve only in general. If you want the trajectory to be with higher continuity (such as C2), you can go with natural cubic splines or general B-spline interpolation. Whatever approach you take, it is advised to keep the spline's degree no higher than 5. Degree 3 is a popular choice.
Once you have the mathematical representation for the trajectory, you can compute the minimum distance between a given point P and the trajectory. In general, the squared distance between point P and a curve C(t) is represented as D(t) = |P-C(t)|^2. The minimum of D will happen at where its first derivative is zero, which means we have to find the root for the following equation:
dD/dt = 2*(P-C(t)).C'(t) =0
When C(t) is of degree 3, dD/dt will be of degree 5. This is the reason why it is recommended to use a low degree curve earlier.
There are many literatures or online materials talking about how to find the root of a polynomial (of any degree) efficiently and robustly. Here is another SO post that might be useful.
I want to build an app that calculates project distance traveled by a kicked ball (ball is kicked into a training net) based on the initial readings from accelerometer/gyroscope and some assumptions about weight, air resistance, etc. The ball contains Triple Axis Accelerometer and Gyro. The measurements can either be raw accel/gyro x/y/z values or one of the following:
Actual quaternion components in a [w, x, y, z] format
Euler angles (in degrees) calculated from the quaternions
yaw/pitch/roll angles (in degrees) calculated from the quaternions acceleration components with gravity removed. This acceleration reference frame is not compensated for orientation, so +X is always +X according to the sensor, just without the effects of gravity.
acceleration components with gravity removed and adjusted for the world frame of reference (yaw is relative to initial orientation)
I actually don't know what any of the above means.
Could someone suggest a formula to use in this scenario with this kind of data available? I went through this question, but it doesn't exactly have what I'm looking for.
This is based on the question I asked here, but I think I might have asked the question in the wrong way. This is my problem:
I am writing a scientific ray tracer. I.e. not for graphics although the concepts are identical.
I am firing rays from a horizontal plane toward a parabolic dish with a focus distance of 100m (and perfect specular reflection). I have a Target at the focal point of the dish. The rays are not fired perpendicularly from the plane but are perturbed by a certain angle to emulate the fact that the sun is not a point source but a disc in the sky.
However, the flux coming form the sun is not radially constant across the sun disc. Its hotter in the middle than at the edges. If you have ever looked at the sun on a hazy day you'll see a ring around the sun.
Because of the parabolic dish, the reflected image on the Target should be the image of the sun. i.e. It should be brighter (hotter, more flux) in the middle than at the edges. This is given by a graph with Intensity Vs. Radial distance from the center
There is two ways I can simulate this.
Firstly: Uniform Sampling: Each rays is shot out from the with a equal (uniform) probability of taking an angle between zero and the size of the sun disk. I then scale the flux carried by the ray according to the corresponding flux value at that angle.
Secondly: Arbitrarily Sampling: Each rays is shot out from the plane according to the distribution of the Intensity Vs. Radial Distance. Therefore there will be less rays toward the outer edges than rays within the centre. This, to me seems far more efficient. But I can not get it to work. Any suggenstions?
This is what I have done:
Uniformly
phi = 2*pi*X_1
alpha = arccos (1-(1-cos(theta))*X_2)
x = sin(alpha)*cos(phi)
y = sin(alpha)*sin*phi
z = -cos(alpha)
Where X is a uniform random number and theta is a the subtend angle of the Solar Disk.
Arbitarily Sampling
alpha = arccos (1-(1-cos(theta)) B1)
Where B is a random number generated from an arbiatry distribution using the algorithm on pg 27 here.
I am desperate to sort this out.
your function drops to zero and since the sun is not a smooth surfaced object, that is probably wrong. Chances are there are photons emitting at all parts of the sun in all directions.
But: what is your actual QUESTION?
You are looking for Monte-Carlo integration.
The key idea is: although you will sample less rays outside of the disc, you will weight these rays more and they will contribute to the sum with a higher importance.
While with a uniform sampling, you just sum your intensity values, with a non uniform sampling, you divide each intensity by the value of the probability distribution of the rays that are shot (e.g., for a uniform distribution, this value is a constant and doesn't change anything).
Is there any use of Sin(720)or Cos(1440) (angles in degrees)?
Whether in computer programming or in any other situation?
In general, is there any use of Sin/Cosine/Tan of any angle
greater than 360?
In Physics we do use dot products and cross products
a lot, but even they require angles less than 180 degrees
always.
Hi All,
I know how to compute them....
I want to know, if they are ever useful????
When will I ever encounter a situation, when
I need to compute Sin(440) for example???
Both in math and programming:
Sin(x) = Sin(x % 360)
As another answer pointed out, angles greater than 360 represent one or more full rotations over a circle plus the modulo part. This could have a physical meaning in some circumstances.
Also, when doing trigonometric calculations, you should take this fact into consideration. For example:
sin(a)*cos(a) = (1/2)*sin(2a)
For a>180 you will get the sin of an angle greater than 360.
By the way, have a look here.
I have seen such things come up when doing angle arithmetic:
float angleOne = 150;
float angleTwo = 250;
//...
float result = Sin(angleOne + angleTwo); // Sin(400)
float result = Sin(angleOne - angleTwo); // Sin(-100)
In this (contrived) example, it seems obvious, but when you are computing an angle based on arbitrary rotations of several objects, you can't always know what kind of numbers you would be getting. Imagine calculating the poisition of the player in a 3D game while he is standing on top of a spinning platform, for example.
Any time you're dealing with a user interaction technique, it's entirely possible that they'll push you past 0 degrees or 360 degrees. Imagine that you're making a game with a gun turrent. It's currently pointed at 359 degrees and the user yanks the joystick to the right: now it's pointed at 361 degrees. If you implement the angular representation wrong, all of a sudden, the gun with rapidly traverse nearly 360 degrees to the left.
I predict that the users will be ... disappointed with that bug.
There are all sorts of issues that come up with Euler angle representations of the frame of reference that are important in games, simulations and real device control. Gimbal lock is a serious problem in actual rotating device control (it was a problem with camera pan / tilt devices in my life). The "rapid rotation" bug was a very nasty issue in a small boat autopilot system once upon a time - imagine wrapping a steel cable very tightly around the wheel house (i.e., you don't want to be standing there).
There have been times where the normal math means you end up "traversing the circle" one or more times, and if you keep the math simple your angles might be greater than 360. Personally I like to normalize the angles to be 0 to 360 or -180 to 180 after such operations, but it's doesn't really matter much.
Sometimes the greater number might really represent something. To take a trivial example, imagine instructions to open a classic dial combination safe. You need to spin the dial around a couple of times, so the instructions could be:
turn(800); // Twice around plus another 20 degrees
turn(-500); // Once around the other direction plus 140 degrees
turn(40); // Dial in the last digit
In that context, taking the sin or cos would tell you something about the ultimate position of the dial, but you would lose the information about how many turns were involved.
One rotation around a circle is 360 degrees or 2pi radians.
Trigonometric functions such as sine and cosine will "wrap around" when they reach 360 degrees and act the same way as being at 0 degrees. Basically, the following occurs:
angle_in_unit_circle = angle mod 360
Also, some trigonometric functions such as tangent are not defined at certain angles, such as 90 and 270 degrees, where tangent of an angle will return a positive or negative infinity.
This "wrapping" around can be seen by representing the sine, cosine, tangent functions using an right triangle inscribed in an unit circle, and this behavior makes those functions periodic because they will repeat their patterns over and over again.
Wikipedia has an extensive article on Trigonometric functions, so that might be worth taking a look at.
Usage
In terms of use, I can't quite think of a good example off the top of my head, except, maybe perhaps to represent a location of a particle at a certain time in a polar coordinate system, where the angle θ is dependent on time t:
r(θ(t)) = t where θ(t) = t
for values of t from 0 to 720, which could then be represented in a Cartesian coordinate system as:
x(t) = r sin(θ(t)) == t sin(t)
y(t) = r cos(θ(t)) == t cos(t)
The particle will be moving in a spiral type movement, dependent on the time t. In this case, the sine and cosine of angles beyond 360 will be calculated.
(And my math is rusty, so if there are any errors in the equations above, please let me know!)
On a sine curve, Sin(720) == Sin(0) (etc), so I'd expect any decent implementations of those functions to handle degrees "greater than" 360. There's any number of reasons for arriving at an angle greater than 360 or less than 0.
Angles outside the range of "principal angles" [-180,180) are essentially aliases of each other (modulo 360 degrees) and have no physical distinction.
From a mathematical/engineering sense, if you have a process where the # of rotations is important and must be kept track of (e.g. a motor that is spinning back and forth), then 0 degrees and 720 degrees are not the same. Sine and cosine are just periodic functions so they have the same value every 360 degrees. If you have a particle undergoing uniform circular motion where x(t) = A cos (ωt + φ) and y(t) = A sin (ωt + φ), then the phase angle θ = (ωt + φ) is going to be whatever it is, whether 0 or 720 degrees or 82144.33 degrees or whatever.
So the functions cos(θ) and sin(θ) just get used to calculate the x and y coordinates, no matter what the value of θ is. It's not like you have a choice in the matter, if θ is 82144.33 degrees then you're going to want to calculate the sine and cosine of that angle.
I play a PC game called Garry's Mod, and there are moments in the game where, when programming, I want a simple solution to keep an object constantly moving in a constant circle. To do this I use the sine and cosine of a forever increasing timer, measuring the amount of time since the game launched.
The sine of T (time) is equal to the orbit paths X value, while the cosine of T is equal to the orbit paths Y value(X and Y being on a 3 dimensional coordinate plane with Z not being used at the moment.)
Example:
T=1000 ticks
X=sin(T)
Y=cos(T)
So X is 0.8268795405320025 during that moment in time and Y is 0.15466840618074712.
Now let's say the amount of time grows to 1500. X would be -0.9939019569066535 and Y = -0.11026740251372914.
In a nutshell, it would constantly fluctuate from 1 to -1, leaving me the opportunity to multiply that value by say 100, and making the coordinate plane local to my characters position, then I can tell the programmed expression to move an object based on those coordinates and it would move in a constant circular path around me.
Tada. Who says you can't learn from video games?
Because sin(x) = sin(x mod 360°) and cos(x) = cos(x mod 360°) you can use every value in calculation, but you could also normalize to the range [0°,360°) or any other range of 360°. It just depends on the usage if large angles have a well defined meaning or not.
Processors will likley normalize the calculation to just a range of 90° or even less, and derive all other values from this small range.
When will arguments greater than 360° occur?
They naturaly occur in simulations of periodic time or space dependent functions.
Your question does not make much sense seeing as you seem to know the difference here:
No - you will never have to "compute" Sin(720), anymore than you will have a need to "compute" Sin(0). You need to look at the definition of the Sinus function to fully understand what goes on under the covers - and when that is understood it makes total sense for anyone as to why Sin(0) = Sin(720) - there's nothing magical going on, there's (logically) no Angle = FullAngle % 360 going on, it's all in the definition of what the function is supposed to do.
See wikipedia
#dta, I think folks are a little confused. You ask if it's ever "useful." I'd say "It doesn't matter, because you just shift the angle to the proper range when performing the calculation." There are certainly cases where you need to know how far from 0 degrees an object has rotated, accounting for multiple rotations. But aside from those cases, it's more convenient to interpret angles in the normal 0-360 range. Most people build up an intuitive feel for which direction corresponds to angles in that normal range. What direction does 170,234 degrees point? The same as 314 degrees.
As #Chris Arguin and others said, whether sin of an angle greater than 360° (or for that matter less than -360°) is useful to you depends on whether you need the information about rotations (or fractions thereof) that is represented by the difference between angle and angle%360°.
Also, since you get the same answer, you'll save a little processing time if you call sin(angle) instead of sin(angle%360), especially if you are doing many computations in a loop.
OTOH, #Scottie T makes a good point that if it is important for someone to know where around a circle your angle points, people can generally intuit position of an angle with an absolute value of 360 or less easier than they can for larger angles.
There are many circumstances where angles outside of [0,360] are needed. I like the idea of a combination lock. Here one will often see both positive and negative angles outside of the simple [0,360] degree range.
Multiple angle formulas are often important in mathematics. Trig functions are used in places other than just triangles. They appear in a variety of places, Fourier series for example, or image compression schemes, or the solution of differential equations. Computationally, it is true that you can always use mod to reduce the range for a trig function to the default. But it is rarely true that angles will always be provided in that nominal range.
There definitely can be times when you might end up with an angle measure > 360 degrees because of some kind of calculation...but it would be identical to an infinite number of other angle measures, exactly one of which will be between 0 and 360. However, if you are coding a function, you should be able to handle this calculation yourself...not rely on the user to do the mod for you.
ie While it is true that sin(370) == sin(10), and the user could do this translation themselves, they may not want to for one reason or another (see the "bolt" example in the comments for the top rated answer), and so the function should be able to handle any value.
Angles higher than 360 degrees are also used e.g. to describe snowboard tricks:
http://en.wikipedia.org/wiki/List_of_snowboard_tricks#Spins
So you see, there are various real world example where you use higher angles to describe the rotation of an object.