Is there a function/algorithm that allows me to input the latitude and the approximate orbital position of the earth in so that I can determine how long the sun is up? IE during the winter it would show that the sun is only up a few hours in the far north hemisphere.
I did some basic Google search and didn't find much so I was thinking that I might have to do some trigonometry that would allow me to calculate how much the earth is inclined or not toward the sun then use that information along with the latitude to figure out how much sunshine a site would be getting.
Nice problem. Would this Sunset/Sunrise algorithm be helpful?
Source:
Almanac for Computers, 1990
published by Nautical Almanac Office
United States Naval Observatory
Washington, DC 20392
You can use the Sunrise/Sunset Algorithm to calculate the start/end of each day, and then just subtract to get the amount of daylight.
Also, NOAA hosts an improved sunrise/sunset calculator which includes an online tool as well as links to their JavaScript source code and other resources.
Related
So I am doing my own research, and I need to read this paper.
CALVIN, T. W. (1977). "TNT Zero Acceptance Number Sampling." ASQC Technical Conference Transactions, Philadelphia, PA.
https://hero.epa.gov/hero/index.cfm/reference/details/reference_id/8389081
However, I checked on google scholar, I used the acedamic VPN, I searched on my university library,
none of them have the access of this paper.
I REALLY need this paper, and I do not live in the united stated, so I can not go to the library there.
Is there any chance you know how to get access to this?
Thank you so so much!
I have spend a bit of effort trying to figure out what the geographic projection is of coordinates attached to the exif files of the photos taken on the DJI Phantom 3 advance. I assumed that it was in WGS84 with the elevation in its associated datum, but when I looked closely at the elevation values, there was a systematic offset that was closer to the NAVD88 datum (but still off).
I called DJI's tech support and was put on hold for a while, and they reported back that the it was indeed NAVD88. I am not sure I buy this answer though. The person I was talking to had no idea at first, and I had planted the term navd88 when I posed the question, and even spelled it out for him; I asked if the z was in a global ellipsoid or a local datum like navd88.
Like I said, I was on hold for a long time, so it is possible this is really the correct answer, but when I think about it, it doesn't make sense. These are flown all over the world, so why would you want a North American datum if you are flying in Tasmania for example. I suppose it is possible there is a list of local datums onboard, and it automatically applies it depending on the location, but I kind of doubt it.
I know that the onboard GPS in not very accurate, especially in the Z direction, but where I am at there is more than 13 meters difference between the WGS84 global ellipsoid and NAVD88. Knowing the datum will help strengthen my photogrammetry product.
I also went through all the DJI documentation I could find on the subject, to no avail.
Has anyone else examined this issue in detail?
Thanks!
I was thinking the exact same thing! Which datum is used, so propably WGS84. But yes if you are in Tasmania, that make a difference, you can have more than hundred feet diffence if you are looking at a specific waypoint. But at the end, that makes no diffence of using the "universal datum" WGS84, because when you use a point as a "RTH" point, you not entering a geodesic point (lat/long). But the drone is recording where is at according to what it's reading! The day that DJI will offer to enter a coordinated, then, exact country datum will be required.
Another "BUT".... if you are looking at your flight records, while playback your flight, at the bottom you can see you coordinates, so if you have an nicking gps, and that gps is set at WGS84 datum, do that exercise, enter you coordinated on google earth and check where it's landing. Then change gps datum to another datum, nad27 or what ever and enter again your coordinates and check again, you will be surprise of the distance difference!!
Take care!
based on my experience, Phantom 4 is using the WGS84 as datum.
I made experiment by taking several GPS reading at 1 site used for GPS calibration. The reading from all GPS is slightly matching the coordinate of calibration point.
Then I take a reading via phantom 4 and its not matching with the calibration point. I changed the datum from the Phantom 4 reading into Timbalai 1948 (datum use in Borneo Island), the coordinate is matching with the calibration point.
Therefore I confident that datum used by the Phantom 4 is using WGS 84 since this datum is universal datum and also used by Google Earth.
I am currently developing technique to help users find a spot to park.
But i face a little problem:
if a user indicates that he is parking right now in a free spot but he is lying and he is at home right now.
How can i detect from GPS if he is inside a building or along side the road?
Thanks
You'll need map data (OpenStreetMap is free), and figure out whether the user is somewhere on that map or not. You do that by comparing GPS data to the map data.
What I do in such situations is measure the distance between the lat/lon and each road, and compare the GPS angle to that of each line. The more context information you use the more accurate you can get your results:
If the speed is 60km/h, you're probably not in a building. You're probably not on a 30km/h road either.
If you're standing still for more than 2 minutes, you're probably not in a car.
If you know the buildings, and there are only a few of them, you could check if you see a certain wifi router or not.
Basically you'll calculate a score for each road, and then pick the road with the highest score to know where you are.
Score = DistScore*DistWeight + AngleScore+AngleWeight etc.
Also, from iOS and Android you get an accuracy in meters. You can also calculate that yourself if you can access raw GPS data. Using that, you set the area that you need to scan. For example, for a high accuracy (3m), you probably don't have many roads to scan. If the accuracy is 50m, you should probably match roads that are farther away.
If accuracy is important, you should look at series of GPS data, and test if the followed route is a logical path or not.
I am trying to use region monitoring for my app, but I am trying to use it with accuracy on the order of what building in a given city area the user is in.
Reading through other articles here on region monitoring, I have gotten a bunch of conflicting arguments on the accuracy of the system. Now, at the end of 2012, what is the accuracy like?
From my own testing it seems to be checking me into locations that are a few dozen meters away from where I am, which is too granular for my needs. I need to know if this is an issue with region monitoring or just my implementation.
Thanks, and I hope this question isn't too much of a repetition of other ones, but the dates of those questions and responses makes getting the current answer confusing.
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.).