I am given site co-ordinate systems having the following parameters:
Projection Type (usually Transverse Mercator)
Ellipsoid/Datum (usually GRS80/GDA94)
Central Meridian
Central Scale Factor
False Easting
False Northing
and then need to programmatically convert a large number of points from ECEF into the site co-ordinate system, so ideally I'd like to use a transform matrix.
Wikipedia gives the formula for this transform matrix as:
http://upload.wikimedia.org/math/6/c/5/6c5e10c1708acc1663d618c2f3fecc98.png
But how do I calculate the parameters needed for this formula from the site mapping parameters I have been given?
The usual way to do this conversion is to first convert from ECEF to geodetic coordinates (latitude,longitude,height), and then to convert these to map coordinates (northing,easting,height). Each of these transforms is non-linear. However if the site is not too large and your accuracy requirements not too stringent, you could carry out the above transforms on a few dozen (say) points round the perimeter of the site, and then use these points and the original to find an affine transform that best approximates the map coordinates from the ECEF coordinates.
I've played around with this a bit and it appears that while it is possible to get the eastings and northings with fair accuracy (eg a couple of centimetres over a site within a circle of radius 10km and a 20m height variation over the site; but if the height variation is 200m the accuracy drops to 2 decimetres), it is not possible to get even fair accuracy on the height -- in the example the height could be ~8m in error. This is unavoidable, as a line of constant height in site coordinates will be close to a circular arc, and if you compute the greatest distance of the chord from the arc for an arc of length 20km and a circle of radius earth radius you get ~16m.
Related
I have a webpage that I am using a Google Map on. When the user drags the map and lets go, I need to query a server for all data points that fall within the bounds of the visible region of the map. I can quite easily get the North-East and South-West coordinate of the visible region of the map through the javascript API, essentially providing a bounding rectangle. However on the server, I am relying on a database whose geographic query API only supports queries in the form of a center point and a radius. So basically what I would like to do is figure out the minimum radius circle I would need to at least encompass the North-East and South-West points.
The simplest algorithm I thought of involved finding the center point between the NE and SW coordinate and then measuring the radius as the distance from the center point to either the NE or SW coordinate. In a simple euclidean space I'd be comfortable doing this, but I think I'd probably get something wrong with the Earth's non-flat coordinate system. I haven't even been able to convince myself that if I knew that centerpoint that the distance would be the same between the center and NE and the center and SW.
I've come across algorithms for smallest circles on a flat 2D surface and also algorithms describing the opposite i.e. bounding box from circle center and radius. I haven't come across a concise algorithm for this particular problem though.
I assume what you call the east-west and north-south coordinates are the longitude and latitude. You can convert them to Cartesian points and find the midpoint between the edge points of your region. This will yield a point C' below Earth's surface with the same latitude and longitude as your centre point C. (This will only work if the difference of your longitudes is smaller than 180°, however; otherwise you'll get a point on the opposite side of the earth, but with the same latitude.) If you need Cartesian coordinates for your centre point, you can project C' onto the surface by adjusting the radius to find your new centre point.
The distance bewteen the two points on the surface of Earth can be calculated with the great-circle disnatce formula.
Transformation is easy if you assume that Earth is a perfect sphere with radius R = 6373 km:
x = R * cos(lat) * cos(lon)
y = R * cos(lat) * sin(lon)
z = R * sin(lat)
and back:
lon = atan2(y, x)
lat = atan2(z, r) with r = sqrt(x*x + y*y)
(But Earth does not have a constant radius, so you might want to use a better coordinate system, maybe ECEF as explained in this answer if you need more precision.)
My first thought was to find your midpoint in terms of longitude and latitude, which should be okay if you take care of wrapping for the latitude. Then you calculate your distance accpording to the great-circle formula. But averaging the longitudes and latitudes does not seem to be sensible if your map region includes a pole.
I am trying to implement the method of Dalal and Triggs. I could implement the first stage compute gradients on an image, and I could create the code who walk across the image in cells, but I don't understand the logic behind this stage.
I know is necessary identify first between a signed (0-360 degrees) or unsigned (0-180 degrees) gradients.
I know I must create a data structure to store each cell histogram, whit n bins. I know what is a histogram, hence I understand I must visit each pixel, but I I don't fully understand about the method for classify each pixel, get the gradient orientation of this pixel and build the histogram with this data.
In short HOG is nothing but a dense representation of gradient orientations weighted by their strengths over a overlapped local neighbourhoods.
You asked what is the significance of finding each pixel gradient orientation. In an image the gradient orientation at each pixel indicates the direction of the boundary(edge between two textures) of the object at that location with respect to X and Y axis. So if you group the orientations of a patch or block or part of an object it represents the distribution of edge directions of object at that region in a very strong way or unique way... Now let us take a simple example, a circle if you plot the gradient orientations of a circle as a histogram you will get a straight line (Don't imagine HOG just a simple plot of gradient orientations) because the orientations of edges of circle ranges from 0 degrees to 360 degrees if u sampled at 360 consecutive locations, For a different object it is different, HOG also do the same thing but in a more sophisticated manner by dividing image into overlapping blocks and dividing each block into cells and making the histogram weighted by the strengths of the local gradients...
Hope it is useful ...
I am currently working on a computer-vision program that requires me to determine the "direction" of a color blob in an image. The color blob generally follows an elliptical shape and thus can be used to track direction (with respect to an initially defined/determined orientation) through time.
The means by which I figured I would calculate changes in direction are described as follows:
Quantize possible directions (360 degrees) into N directions (potentially 8, for 45 degree angle increments).
Given a stored matrix representing the initial state (t0) of the color blob, also acquire a matrix representing the current state (tn) of the blob.
Iterate through these N directions and search for the longest stretch of the color value for that given direction. (e.g. if the ellipse is rotated 45 degrees with 0 being vertical, the longest length should be attributed to the 45 degree mark / or 225 degrees).
The concept itself isn't complicated, but I'm having trouble with the following:
Calculating the longest stretch of a value at any angle in an image. This is simple for angles such as 0, 45, 90, etc. but more difficult for the in-between angles. "Quantizing" the angles is not as easy to me as it sounds.
Please do not worry about potential issue with distinguishing angles such as 0 and 90. Inertia can be used to determine the most likely direction of the color blob (in other words, based upon past orientation states).
My main concern is identifying the "longest stretch" in the matrix.
Thank you for your help!
You can use image moments as suggested here: Matlab - Image Momentum Calculation.
In matlab you would use regionprops with the property 'Orientation', but the wiki article in the previous answer should give you all of the information you need to code it in the language of your choice.
In my application, I have few screen coordinates through which I draw a Bezier Spline and I need to find the average Velocity and acceleration through that spline.
How should I go about it ?
I will find it in terms of pixel/sec and pixels/square-sec.
and then convert it to m/sec and m/sec sq once the User provides pixel-meter mapping.
But How will I get the velocity or accn as I cant just take start point and end point, It has to be thru that curve.
Ughh, leave the pixel/sex and the pixels/square-sec approach aside for now.
I'm assuming from your question that you have an x-y plot with some sort of Bezier spline, some sort of curve which represents way over time. The x axis usually represents time, while the y axis represents way (length) s.
Velocity is the derivation of length over time, and acceleration the derivation of that. A derivation is simply the ratio of dy/dx in a (preferably) close pair of points.
So, what you need for a start is to interpolate and gather as many points from that Bezier spline. Leaving that up to you. From there,
dy = y(i+1) - yi
dx = x(i+1) - xi
velocity = dy/dx
So a graph of velocity over time would be that plotted on a time basis. Same goes for accelleration, just repeat the process.
You need to differentiate the curve once with respect to the temporal dimension in your plot (here I am assuming the x-axis/horizontal axis represents time; the y-axis/vertical axis represents distance travelled) to gain the local velocity component. Differentiate twice with respect to the same temporal dimension to get the acceleration at a given point. This is basically working out the gradient at each point along the curve for velocity, and the gradient of velocity to get the rate of change of velocity, namely acceleration.
To do this you use numerical integration to get the new quantities (velocity and acceleration) at each discreet point (or coordinate) on your spline based upon the data surrounding that point/coordinate location.
I have some GPS sample data taken from a device. What I need to do is to "move" the data to the "left" by, let's say, 1 to 5 meters. I know how to do the moving part, the only problem is that the moving is not as accurate as I want it to be.
What I currently do:
I take the GPS coordinates (latitude, longitude pairs)
I convert them using plate carrée transformation.
I scale the resulting coordinates to the longitudinal distance (distance on x) and the latitudinal distance (distance on y) - imagine the entire GPS sample data is inside a rectangle being bound by the maximum and minimum latitude/longitude. I compute these distances using the formula for the Great Circle Distance between the extreme values for longitude and latitude.
I move the points x meters in the wanted direction
I convert back to GPS coordinates
I don't really have the accuracy I want. For example moving to the left by 3 meters means less than 3 meters (around 1.8m - maybe 2).
What are the known solutions for doing such things? I need a solution that deviates at most by 0.2-0.5 meters from the real point (not 1.2 like in the current case).
LATER: Is this kind of approach good? By this kind I mean to transform the GPS coordinates into plane coordinates and back to GPS. Is there other way?
LATER2: The approach of converting to a conformal map is probably the one that will be used. In case of a small rectangle, and since there are not roads at the poles probably Mercator will be used. Opinions?
Thanks,
Iulian
PS: I'm working on small areas - so imagine the bounding rectangle I'm talking about to have the length of each side no more than 5 kilometers. (So a 5x5km rectangle is maximum).
There are two issues with your solution:
plate carrée transformation is not conformal (i.e. angles are not preserved)
you can not measure distances along lat or lon that way since that are not great circles (approximately you are off by a factor cos(lat) for your x).
Within small rectangles you may assume that lon/lat can be linearly mapped to x/y pairs but you have to keep in mind that a "square" in lon/lat maps to a rectangle with aspect ratio of approx cos(lat)/1.