everyone
recently I am trying to solve the location error generated by GPS, so I came up with an idea of projecting the GPS points to the nearest road, as shown bellow [1]. But I know that indeed earth is not a flat plane and general projection method is not adaptive to this problem. What should I do to deal with the projection problem that exists on sphere to get a better precision?
![1]: http://imgur.com/nL7tB7m
Similarly, when it comes to interpolation between two points, same problem emerged. I did once assume two points were closed so I could ignore the flatness
effect, but failed if their distance was long enough. Regular interpolation method won't give me a better-precision result.
![2]: http://imgur.com/rOSu8gk
Related
TL;DR: can anyone help w/ geospatial things in R using geom_raster() in ggplot?
Basically it seems that my issue is stemming from the fact that I don't have perfectly gridded values (aka I get this message: "Warning: Raster pixels are placed at uneven vertical/horizontal intervals and will be shifted. Consider using geom_tile() instead."). So, if I switch to geom_tile, then I can control the size of the tiles, but then they look chunky and awful since there's no interpolation feature in geom_tile. If I use geom_raster, I think it gets confused what size it should plot the pixels since it's not perfectly gridded, so when I facet my ggplot, the output sometimes will have teeny tiny dots (or even no dots at all) on some facets, and pretty maps on the other facets. When I round the lat/lon coordinates to 0 decimal places, this fixes the teeny tiny / no dots problem, but then ends up with things just like geom_tile (chunky with no blending between).Any ideas on how to fix this? I think if there's a way to manually interpolate to fill in NA values so that I do have nice symmetrically-gridded data, then geom_raster should work fine. Like what needs to happen is for each situation where we're missing a value at a certain lat/lon, we need to take the mean value between the two closest neighboring points to fill in that missing lat/lon point on the grid. But I'm not sure how to do this (aka how to convert from my dataframe into all the different spatial classes and back again). Then again, this manual approach might be overcomplicating things and I'd love a simpler solution. (fingers crossed)
I'm building this in a shiny app with crazy long code, and a very large dataset, but happy to share additional info as needed!
example plot
example plot2
warning example
I am trying to implement an inflation layer between two geometries in my mesh using ANSYS, and I am confused about the procedure.
I found online (see the answer from Gopinath N K on 1/17/22) that in the ANSYS meshing tool you cannot combine face meshing with inflation. So I tried to remove the face sizings thinking that was what was being referred to but it gave mixed results which I'll explain below.
Second, I saw here that to create inflation I might need to employ named selections instead of selecting the two geometries (a body and a face) but this also gave mixed results.
As to my mixed results, I successfully got an inflation layer to work for a cylindrical body inside another cylindrical one (see images below). The blue larger cylinder is the body (red arrow), and the green circles are the edges of the small cylinder inside (green arrows). I created this inflation layer successfully.
However, when I try to create an inflation layer between the Rotating Zone (larger cylinder) and the Stationary Zone the inflation layer fails. This occurs as soon as I select the rectangular larger body. I didn't bother to finish selecting the other faces since next to Active it says "No, Invalid Method". The same thing occurs if I select the Structured Zone (smallest cylinder) and the faces of the wing (angled plate subtracted from the Structured Zone). So I really no clue what is causing this since it seems to occur as soon as I select the outer larger body geometry. Maybe I'm not selecting the right set of faces, or there is something else that is leading to this.
Thank you
So it turns out that the message saying "No, Invalid Method" is referring to a Hex Dominant method I created. There are certain mesh methods that inflation does not like to work with, and I haven't been able to find any reason why. I hope anyone using the ANSYS Mesher finds this helpful.
I am trying to extract rotation matrix and translation matrix from essential matrix.
I took these answers as reference:
Correct way to extract Translation from Essential Matrix through SVD
Extract Translation and Rotation from Fundamental Matrix
Now I've done the above steps applying SVD to essential matrix, but here comes the problem. According to my understanding about this subject, both R and T has two answers, which leads to 4 possible solutions of [R|T]. However only one of the solutions would fit in the physical situation.
My question is how can I determine which one of the 4 solutions is the correct one?
I am just a beginner on studying camera position. So if possible, please make the answer be as clear (but simple) as possible. Any suggestion would be appreciated, thanks.
The simplest is testing a point 3D position using the possible solution, that is, a reconstructed point will be in front of both cameras in only one of the possible 4 solutions.
So assuming one camera matrix is P = [I|0], you have 4 options for the other camera, but only one of the pairs will place such point in front them.
More details in Hartley and Zisserman's multiple view geometry (page 259)
If you can use Opencv (version 3.0+), you count with a function called "recoverPose", this function will do that job for you.
Ref: OpenCV documentation, http://docs.opencv.org/trunk/modules/calib3d/doc/calib3d.html
I would like to be more specific about what I want to do. I get coordinates in ECI and I need to get the latitude and longitude from this. How can I do? I was searching but I could'nt find anything about it. Thanks again.
(I'm doing a small program in java that shows the position of a satellite in a given time. So, I used the NORAD SGP algorithm, and I have the position (x,y,z) and velocity(Vx,Vy,Vz). But the coordinates system used by this algorithm is the ECI, according what I read. Now I need to draw the satellite in a map, but I can't convert this coordinates to some system that could help me. I think if I can convert it to longitude and latitude it would be easy to draw. Could you help me? how can I do it? What is the best option(UTM,etc)? Thanks.)
What you want to do is called ECI/ECEF (cartessian) to Geodetic (lat/lon) conversion. This conversion is the most complex of all the geodetic conversions as the closed form solution is complicated. See page 34 of Stevens and Lewis, Aircraft Control and Simulation for a discussion of the coordinate systems: http://books.google.com/books/about/Aircraft_control_and_simulation.html?id=T0Ux6av4btIC
ECI to geodetic is a two step process:
The first step is the easiest in that you need to convert ECI (earth centered inertial) to ECEF (earth centered/earth fixed).
The second step is to convert ECEF to geodetic. You can read about solving this via Newton-Ralphson here: http://en.wikipedia.org/wiki/Geodetic_system
However, if I remember correctly, Newton-Raphson becomes unstable around the poles. The closed form solutions are much more complicated. I have successfully implemented Zhu's method. The advantage of the closed form solution is no iterations and there are no singularities (technically there are singularities but not above the earth). The reference: J. Zhu. Conversion of earth-centered earth-fixed coordinates to geodetic coordinates. Technical Report IEEE Log NO. T-AES/30/3/1666, IEEE, December 1993.
The PyMap3D library for Python has the eci2ecef and the ecef2geodetic functions. They interface with Astropy by default and are quite good, thanks to the hard work of Michael Hirsch (SciVision - he accepts donations).
You need, of course, to know the times at which the ECI coordinates were observed; without that you cannot convert them to ECEF. I recommend not using the simpler eci2geodetic function unless high precision and accuracy are not required; it will be somewhat quicker because it does not account for Earth's nutation, etc.).
When researching on how to do the classic "get POI in range" problem I've found that the most used algorithms are Haversine and if you need real accuracy then Vincenty's formula. I went the first one because high accuracy wasn't an issue. However, it got me thinking on something that hits me as odd, why is that I found no references to caching the Cartesean coordinates on the database instead of using the haversine formula with the lat/lon?
The issue here is, of course, performance. The haversine formula requires a ton of cos/sin function calls, but wouldn't it be simpler to store the projected X, Y and Z of a lat/lon point on the database and apply the dot product directly? That would require a single arccos call unless I'm mistaken.
Because any given Cartesian projection will only give the correct answer for certain points - a projection which gives the right distance between two points on one particular circle around a sphere will distort distances along another particular circle.
Formulas such as Haversine are independent of the relative locations of the various points on the sphere; they return the correct distance regardless.
No, you are not mistaken. Two things, though. First, obviously, your performance benefits will depend on the nature of your application. If you need to use the same points many times in your calculations, you will improve performance by doing what you suggest.
Second, the formula you use is not the issue here. If you precompute and store sin and cos of lat/lon and use haversine, you will get the exact same performance improvements.
Calculating the distance between two X,Y,Z coordinates will give you the straight line distance (as the arrow flies). The Haversine formula gives the shortest path on the surface of the curved earth (spherical distance). Most geographic software applications need to compute the distance across the earth's surface, thus the Haversine or similar spherical trigonometry algorithms are used.