I am very basic question. Can we find the bearing i.e. angle with respect to North of a coordinate i.e. having GPS lat long of single point without any other sensors. I searched but everywhere it is like finding the bearing between two points, I want to know whether can we find bearing of single point without knowing the direction.
Secondly if we move our angle to some degrees, can we again find the new bearing?
Any reference or link to any material if available please help.
The bearing is an angle. Angle is a figure between two directions or rays with common origin (note it is not between two points, but between two rays). The bearing is angle between (1) direction from some point A to North and (2) direction from same point A to another point B.
So yes, you need two points to define bearing. While first direction (to North) is defined by a single point, defining second direction requires another reference point.
Related
I'm trying to automatically set all the Points In the nearest surface.
As I didn't find a simple way to do it, I'm trying to manually find the nearest surface for the needed points.
Is it possible to calculate the minimum distance from a Point and a Surface?
so that I can call
Point{n} In Surface {id_nearest};
and get a mesh node for that geometry Point?
My tries involved the use of Field.Attractor and FacesList, creating a Field for each Surface and then trying to find in which field the Point is with isInside. But this seems harder than it likely is and didn't work.
I have been exploring the GPS data mining literature esp. for problems like anomalous trajectory detection, time travel prediction, etc and one very common method I see is dividing the data or map into grids. Can any one please explain the logic of this? Are the coordinates euclidean in this case? Is grid decomposition really necessary?
I would be grateful if someone can also give/ quote some links or materials I should explore. I am new to this field, so please pardon me if the question is very obvious.
Thanks & Regards,
Lesnar
No they are not euclidean. But they don't have to be. The grids are not rectangles anymore, but can be treated as such for some operations.
If you create a lat/long grid, then each cell by means of meters is not rectangular. However it defines a zone where you add a counter, which has a clear inside/outside definition. And you can use cartesian operations (Rectangle.inside())
So the lat / lon span is constant for each cell, but not the longitudinal meters span, which shrinks by cos(latitude).
If one needs a grid with equal grid cells sizes by means of meters, then one
has to transform the geo coordinates before.
I am trying to properly project Latitude and Longitude into cartesian coordinates so that I can use an unscented Kalman filter to smooth out some GPS data. I am using constant jerk newtonian motion as my state transfer matrix. My issue is that I have tried many popular projections(Mercator, etc.) and when I reproject into latitude and longitude, my data is stretched with respect to maps. Any insight on my situation would be greatly appreciated! If you need more information please ask in the comments. Thank you.
The stretch factor between longitude and latitude is cos(latitude).
So you can do a local Cyclindrical Equidistant transformation.
this is a simple tranformation, but is only acurate around 10-100km
of the center (longitudeCenter, latitudCenter). this kind of projektion needs a (fixed) center.
Look further for "Cyclindrical Equidistant Projection" to get the simple formula.
This is a simple question that I would have rather chatted with someone about but here it is:
How is heading calculated? I can't figure it out visually.
If the heading is calculated in regards to the Earth's Geographic North, does that mean a top view of the Earth? So when you are standing on top of the surface of the Earth somewhere, how can you get a heading direction on a digital device? What are the calculations? Does it involve the sphere at all or does the device ignore the existence of the sphere and simply keep in mind a simple coordinate eg. 90.000 N and 0.000 W?
I don't know why I can't seem to grasp the concept of heading mathematically...
Edit: I think I figured it out. You are treated as a point, on the surface; north is always directly above you figuratively- you may deviate from this point 360 degrees potentially, that's as you as a point on the surface of the Earth.
Precisly a GPS receiver does not calculate heading.
heading is the direction where you are looking to.
The more correct term is course or course over ground.
But modern APIs often intermix heading, course and bearing.
heading and course is the same for a vehicle,
But not for a ship (due drift).
But the main point is that one could think a GPS chip calculates the course/heading by evaluiating old and new position. But this is not true. This would be by far to inaccurate.
GPS receiver use Doppler Shift for speed and probably also for heading calculation.
And yes course and heading is the angle clockwise measured from geographical north (0°)
There's no concept of "heading" in a coordinate, only in a procession of coordinates generated as something moves, in which case the heading is calculated based on the differences between the coordinates.
So if your first coordinate was at 10N50E and the second at 11N50E your device calculates you as traveling due north, thus on a northerly heading.
More than one question on this one :)
The heading (or yaw angle, in aeronautics), is defined as the angle between the North and the direction faced by the nose of the plane, when the plane is horizontal (pitch and roll angle at zero).
This is also what you could read on a compass (North = 0°, East = 90°, etc.)
Wherever you are on the globe, you should be able to lay on the ground a protractor whose 0° is aligned with your current meridian, pointing north, and the 90° is aligned on the local parallel, toward the east. Hence you can read your heading everywhere (except on poles)
In a car, the heading is deduced from the trajectory, by looking at the previously recorded points (Doppler based speed measurement is not widespread on cheap devices). And, as stated in other answers, this is not the heading but the track which is displayed (the direction you are moving to, compared to the direction you are facing). Luckily, cars don't drift (most of the time) and so, the track is equal to the heading.
In a smartphone, the display of the heading may be assisted by the internal compass.
So a GPS, as this, is not able to assess your heading, unless you use more than one antenna, like in this device. Where the phase difference measured between the two antennas enable the device to deduce a pure, GPS based, heading.
Similar to the method suggested in another answer - One way would be to have 2 GPS antennas and knowing their relative position to each other. Then you have the location of a straight line on the earth and you have a solid direction (perpendicular to this straight line). You can now calculate your orientation with respect to any datum (e.g. true north, or a reference GPS location).
I am writing a physics simulation using Ogre and MOC.
I have a sphere that I shoot from the camera's position and it travels in the direction the camera is facing by using the camera's forward vector.
I would like to know how I can detect the point of collision between my sphere and another mesh.
How would I be able to check for a collision point between the two meshes using MOC or OGRE?
Update: Should have mentioned this earlier. I am unable to use a 3rd party physics library as we I need to develop this myself (uni project).
The accepted solution here flat out doesn't work. It will only even sort of work if the mesh density is generally high enough that no two points on the mesh are farther apart than the diameter of your collision sphere. Imagine a tiny sphere launched at short range on a random vector at a huuuge cube mesh. The cube mesh only has 8 verts. What are the odds that the cube is actually going to hit one of those 8 verts?
This really needs to be done with per-polygon collision. You need to be able to check intersection of polygon and a sphere (and additionally a cylinder if you want to avoid tunneling like reinier mentioned). There are quite a few resources for this online and in book form, but http://www.realtimerendering.com/intersections.html might be a useful starting point.
The comments about optimization are good. Early out opportunities (perhaps a quick check against a bounding sphere or an axis aligned bounding volume for the mesh) are essential. Even once you've determined that you're inside a bounding volume, it would probably be a good idea to be able to weed out unlikely polygons (too far away, facing the wrong direction, etc.) from the list of potential candidates.
I think the best would be to use a specialized physics library.
That said. If I think about this problem, I would suspect that it's not that hard:
The sphere has a midpoint and a radius. For every point in the mesh do the following:
check if the point lies inside the sphere.
if it does check if it is closer to the center than the previously found point(if any)
if it does... store this point as the collision point
Of course, this routine will be fairly slow.
A few things to speed it up:
for a first trivial reject, first see if the bounding sphere of the mesh collides
don't calc the squareroots when checking distances... use the squared lengths instead.(much faster)
Instead of comparing every point of the mesh, use a dimensional space division algorithm (quadtree / BSP)for the mesh to quickly rule out groups of points
Ah... and this routine only works if the sphere doesn't travel too fast (relative to the mesh). If it would travel very fast, and you sample it X times per second, chances are the sphere would have flown right through the mesh without every colliding. To overcome this, you must use 'swept volumes' which basically makes your sphere into a tube. Making the math exponentially complicated.