pyEphem - from angle to date - pyephem

We have following function is exist
j = ephem.Jupiter('1612/12/28')
n = ephem.Neptune('1612/12/28')
print j.ra, j.dec, j.mag
11:48:20.52 2:41:13.6 -1.96
My requirement is little different
I would like to know date by supplying angle is it possible?
Please reply.
Thanks
Harshad

There is no built-in function to, given an angle, find a date. Generally, when you have a problem like this that goes “backwards” from a circumstance that you need satisfied to the determination of the date on which that happens, you will need to try one date after another over and over again until you get out the angle that you are looking for.
There are several well-known techniques for finding the time at which a function returns a given angle, which are discussed here:
Using pyephem to calculate when a satellite crosses a Longitude
Are you able to imagine how you might apply the ideas in that answer to your own situation, since you are also looking for a particular angle (even though it comes from a different part of PyEphem)?

Related

How do I stop a spread sheet from auto correcting to a date?

I want to turn off auto-correcting to dates. I have been using spreadsheets for years and never, not once, have I ever used or wanted a date. I want the cell to compute an equation. I want to put in =3/12, or =6/12, or =9/12 equations and have it return an answer of .25, 0.5, or .75 instead of an auto-corrected date. I do not want to use ' because it will keep the fraction text instead of returning an answer from the equation, it would be the same thing if I changed the cell to text, it will no longer calculate an equation. I have put an equal sign in front because that is usually how you indicate that you want it to be an equation, but it still changes the equations to dates. Other equations work and when I put these fractions inside of other equations they work, but they do not work as stand-alone equations, neither does =90/3 or any other. They all get turned into dates and I need them to be used as equations. And yes, I need to be using a spreadsheet and yes, I want to use Open Office. I just want to know how to get it to do what I want it to do. Please Help. I have seen other forums on this topic and many arguments have ensued for no good reason. I just need help with this one simple thing, thank you.

pgr_drivingDistance with flexible distance value on each route

I would like to calculate a graph similiar to an isochrone using pgsql. Therefore, I already used the algorithm pgr_drivingDistance. You provide a starting point and a distance value and receives an isochrone.
The output using the algorithm is received with code which looks something like:
SELECT * FROM pgr_drivingDistance(
'SELECT id, source, target, cost FROM edge_table',
2, 2, false -- starting point, distance, directed
);
The red star represents the starting point.
Now, I want a graph which works the same way, like starting at one point and get routes in all directions. The difference is, that I don't want to provide a travel distance, but a list with point coordinates, which are lying on the road network. The route in every direction has to stop at the first reached point lying on each route. The distance on every route is different and I don't know which points are the closest ones.
The desired output using the "stopping" points, which are visualized in green, is supposed to look like this.
I tried already:
Using the given algorithm pgr_drivingDistance and raising the distance value every time no point is reached -> problem here: the distance is equal for all directions and not individual for each route.
Using the algorithm pgr_dijkstra for each route -> problem here: because you don't know which point is affected you don't know which end point to choose for the calculation. You also cannot take the closest one in the immediate vicinity because you need the closest one on the specific route.
I know that I have to build an almost complete new algorithm, but maybe someone has an idea how to start or even experience with this kind of problem.
Thank you in advance!
This is a one to many routing problem. You have to compute the route to each end point to find the shortest one. I have not looked at the pgRouting function recently, but I believe there is a one to many, many to one and many to many Dijkstra function(s). You should be able to use the one to many to compute all the routs in one go and then you can sort the routs based on length to find the shortest one.

Where are jplephem ephemerides api documented?

I am working on what is likely a unique use case - I want to use Skyfield to do some calculations on a hypothetical star system. I would do this by creating my own ephemeris, and using that instead of the actual one. The problem i am finding is that I cannot find documentation on the API to replace the ephemerides with my own.
Is there documentation? Is skyfield something flexible enough to do what I am trying?
Edit:
To clarify what I am asking, I understand that I will have to do some gravitational modeling (and I am perfectly willing to configure every computer, tablet, cable box and toaster in this house to crunch on those numbers for a few days :), but before I really dive into it, I wanted to know what the data looks like. If it is just a module with a number of named numpy 2d arrays... that makes it rather easy, but I didn't see this documented anywhere.
The JPL-issued ephemerides used by Skyfield, like DE405 and DE406 and DE421, simply provide a big table of numbers for each planet. For example, Neptune’s position might be specified in 7-day increments, where for each 7-day period from the beginning to the end of the ephemeris the table provides a set of polynomial coefficients that can be used to estimate Neptune's position at any moment from the beginning to the end of that 7-day period. The polynomials are designed, if I understand correctly, so that their first and second derivative meshes smoothly with the previous and following 7-day polynomial at the moment where one ends and the next begins.
The JPL generates these huge tables by taking the positions of the planets as we have recorded them over human history, taking the rules by which we think an ideal planet would move given gravitational theory, the drag of the solar wind, the planet's own rotation and dynamics, its satellites, and so forth, and trying to choose a “real path” for the planet that agrees with theory while passing as close to the actual observed positions as best as it can.
This is a big computational problem that, I take it, requires quite a bit of finesse. If you cannot match all of the observations perfectly — which you never can — then you have to decide which ones to prioritize, and which ones are probably not as accurate to begin with.
For a hypothetical system, you are going to have to start from scratch by doing (probably?) a gravitational dynamics simulation. There are, if I understand correctly, several possible approaches that are documented in the various textbooks on the subject. Whichever one you choose should let you generate x,y,z positions for your hypothetical planets, and you would probably instantiate these in Skyfield as ICRS positions if you then wanted to use Skyfield to compute distances, observations, or to draw diagrams.
Though I have not myself used it, I have seen good reviews of:
http://www.amazon.com/Solar-System-Dynamics-Carl-Murray/dp/0521575974

getting the value of a filter at an arbitrary time

Context: I'm trying to improve the values returned by the iPhone CLLocationManager, although this is a more generally applicable problem. The key is that CLLocationManger returns data on current velocity as and when it feels like it, rather than at a fixed sample rate.
I'd like to use a feedback equation to improve accuracy
v=(k*v)+(1-k)*currentVelocity
where currentVelocity is the speed returned by didUpdateToLocation:fromLocation: and v is the output velocity (and also used for the feedback element).
Because of the "as and when" nature of didUpdateToLocation:fromLocation: I could calculate the time interval since it was last called, and do something like
for (i=0;i<timeintervalsincelastcalled;i++) v=(k*v)+(1-k)*currentVelocity
which would work, but is wasteful of cycles. Especially as I probably want timeintervalsincelastcalled to be measured as 10ths of a second.
Is there a way to solve this without the loop ? i.e. rework (integrate?) the formula so I put an interval into the equation and get the same answer as I would have by iteration ?
If you write your original equation as
v = k*vCurrent + (1-k)*v
you can apply the answer from another SO question.
Instead of iterating, you could just choose the value of k based on the size of the interval. For example, if the interval length is an hour - you'd probably want k to be 0.
It would be easy to precompute k for a variety of interval sizes to give the same answer as the iteration would give. Just compute the change by iterating (you already have code for that), and then compute the value of k that would give you that algebraicly.
It's a common programmer jedi trick to have a table of lookup values in place of expensive calculations. (there, now my answer has something to do with code!)

Calculation route length

I have a map with about 80 annotations. I would like to do 3 things.
1) From my current location, I would like to know the actual route distance to that position. Not the linear distance.
2) I want to be able to show a list of all the annotations, but for every annotation (having lon/lat) I would like to know the actual route distance from my position to that position.
3) I would like to know the closest annotation to my possition using route distance. Not linear distance.
I think the answer to all these three points will be the same. But please keep in mind that I don't want to create a route, I just want to know the distance to the annotation.
I hope someone can help me.
Best regards,
Paul Peelen
From what I understand of your post, I believe you seek the Haversine formula. Luckily for you, there are a number of Objective-C implementations, though writing your own is trivial once the formula's in front of you.
I originally deleted this because I didn't notice that you didn't want linear distance at first, but I'm bringing it back in case you decide that an approximation is good enough at that particular point of the user interaction.
I think as pointed out before, your query would be extremely heavy for google maps API if you perform exactly what you are saying. Do you need all that information at once ? Maybe first it would be good enough to query just some of the distances based on some heuristic or in the user needs.
To obtain the distances, you could use a Google Maps GDirections object... as pointed out here ( at the bottom of the page there's "Routes and Steps" section, with an advanced example.
"The GDirections object also supports multi-point directions, which can be constructed using the GDirections.loadFromWaypoints() method. This method takes an array of textual input addresses or textual lat/lon points. Each separate waypoint is computed as a separate route and returned in a separate GRoute object, each of which contains a series of GStep objects."
Using the Google Maps API in the iPhone shouldn't be too difficult, and I think your question doesn't cover that, but if you need some basic example, you could look at this question, and scroll to the answer.
Good Luck!
Calculating route distance to about 80 locations is certain to be computationally intensive on Google's part and I can't imagine that you would be able to make those requests to the Google Maps API, were it possible to do so on a mobile device, without being severely limited by either the phone connection or rate limits on the server.
Unfortunately, calculating route distance rather than geometric distance is a very expensive computation involving a lot of data about the area - data you almost certainly don't have. This means, unfortunately, that this isn't something that Core Location or MapKit can help you with.
What problem are you trying to solve, exactly? There may be other heuristics other than route distance you can use to approximate some sort of distance ranking.