It is the usual practice to mention the longitude of the planet
by it's rasi position and the degrees.
Example: Sun in virgo 23 degrees. To convert this into a 360 format you have to add 150 degree the starting point of virgo. Adding the 23 to 150 gives 173 degrees.
I have the dictionary:
RasiDegree={"Aries":0,"Tarus":30,"Gemini":60,"Cancer":90,"Leo":120,
"Virgo":150,"Libra":180,"Scorpio":210,"Sagitarius":240,"Capricorn":270,"Aquarius":300,"Pisces":330}
for rasi,degree in RasiDegree.items():
print(rasi, degree)
the print out comes out correctly.
To access any particular rasi, my code is print(RasiDegree["rasi"])
So far so good. How do I write the python prograame to calculate the above.
I tried to get the user input for the rasi and the degree. I am stuck. Should I write a function?
Any help will be greatly appreciated.
Use below function. This function takes rasi name and degree by user as input and return in 360 fomat.
def calculate():
rasi = input()
degree = input()
if(rasi in RasiDegree.keys()):
return RasiDegree[rasi]+int(degree)
I am trying to find out the longitude of ascending/descending moon nodes using Skyfield but unable to find any reference in documentation. Is it possible?
Also do any of the JPL Files provide this data already?
Update:
Skyfield’s almanac module now supports this computation directly! See: Lunar Nodes
Original answer, for those wanting these details:
It is easy to at least find them relative to the J2000 ecliptic — which might be fine for dates far from the year 2000 as well, since I think that only the definition of ecliptic longitude changes with the passing years, but not latitude (which is what the nodes care about)?
In any case, you'd precede like this. Let's say you want the ascending node. It must happen within the next 30 days, because that's more than a full orbit of the Moon, so let's look for the day on which the latitude of the Moon passes from negative to positive:
from skyfield.api import load
ts = load.timescale()
eph = load('de421.bsp')
earth = eph['earth']
moon = eph['moon']
t = ts.utc(2018, 1, range(14, 14 + 30))
lat, lon, distance = earth.at(t).observe(moon).ecliptic_latlon()
angle = lat.radians
for i in range(len(angle)):
if angle[i] < 0 and angle[i+1] > 0:
break
print(t[i].utc_jpl(), angle[i])
print(t[i+1].utc_jpl(), angle[i+1])
The result is the discovery that the ascending node must happen sometime on January 31st:
A.D. 2018-Jan-31 00:00:00.0000 UT -0.0188679292421
A.D. 2018-Feb-01 00:00:00.0000 UT 0.00522392011676
To find the exact time, install the SciPy library, and ask one of its solvers to find the exact time at which the value reaches zero. You just have to create a little function that takes a number and returns a number, by converting the number to a Skyfield time and then the angle back to a plain number:
from scipy.optimize import brentq
def f(jd):
t = ts.tt(jd=jd)
angle, lon, distance = earth.at(t).observe(moon).ecliptic_latlon()
return angle.radians
node_t = brentq(f, t[i].tt, t[i+1].tt)
print(ts.tt(jd=node_t).utc_jpl())
The result should be the exact moment of the node:
A.D. 2018-Jan-31 18:47:54.5856 UT
I just installed PostGIS with GeoDjango. Everything worked fine, but now I have a problem and cant find out the reason for this.
I have model like this:
from django.contrib.gis.db import models
class Shop(models.Model):
name = models.CharField(max_length=80)
point = models.PointField(null=True, blank=True)
objects = models.GeoManager()
And I set its point to this position (49.794254,9.927489). Then i create a point like this:
pnt = fromstr('POINT(50.084068 8.238381)')
The distance between this points should be about ~ 125 km, but when i do this:
results = Shop.objects.distance(pnt)
print results[0].distance.km
I'm getting always about 60 km too much in my result, so it returns 190 km! My SRIDs of both points are 4326... probably something wrong with that?
And maybe another interesting fact, when i do this:
pnt.distance(shop.point)
it returns 1.713790... as a result.
What am I doing wrong? Any alternatives for me to use with python + django? If there is a better solution I would not need to use PostGIS.
Hope you can help me!
Chris
I just ran this query in postgis :
select round(CAST(ST_Distance_Sphere(ST_GeomFromText('POINT(49.794254 9.927489)',4326), ST_GeomFromText('POINT(50.084068 8.238381)',4326)) As numeric)/1000.0,2) as distance_km;
distance_km
-------------
190.50
the result is in fact 190.50, so it seems there's nothing wrong with your 190 km result
same result with this awesome page, there is a brief explanation of how to calculate this distances.
the 1.713790... result seems to be in the same units of the srid, or in other words that number is not in meters.
EDIT
Ooohh I just saw your problem you misplaced the lat and lon, in the WKT format, Longitude comes first so the real query should be:
select round(CAST(ST_Distance_Sphere(ST_GeomFromText('POINT(9.927489 49.794254)',4326), ST_GeomFromText('POINT(8.238381 50.084068)',4326)) As numeric)/1000.0,2) as distance_km;
distance_km
-------------
125.10
so the points should be created like this
POINT(9.927489 49.794254)
POINT(8.238381 50.084068)
I have difficulties with finding current coordinates (RA, DEC) for star in sky.
In net I have found only this one tutorial, how to use ephem library: http://asimpleweblog.wordpress.com/2010/07/04/astrometry-in-python-with-pyephem/
As I understood I need to:
create observer
telescope = ephem.Observer()
telescope.long = ephem.degrees('10')
telescope.lat = ephem.degrees('60')
telescope.elevation = 200
Create a body Object star
here is trouble, I have only (RA,DEC) coordinates for star
Calculate position by .calculate(now())
by new coordinates find altitude
One more question about accuracy of this library, how accurate it is? I have compared juliandate and sidestreal time between this program and kstars, looks like quite similar.
and this http://www.jgiesen.de/astro/astroJS/siderealClock/
PS! Or may be some one can reccomend better library for this purposes.
I guess you're looking for FixedBody?
telescope = ephem.Observer()
telescope.long = ephem.degrees('10')
telescope.lat = ephem.degrees('60')
telescope.elevation = 200
star = ephem.FixedBody()
star._ra = 123.123
star._dec = 45.45
star.compute(telescope)
print star.alt, star.az
I don't know about the accuracy; pyephem uses the same code as xephem, and eg the positions of the planets are given by rounded-down VSOP87 solutions (accuracy better than 1 arcsecond); kstars appears to use the full VSOP solution.
But this will really depend on your need; eg don't rely on it blindly guiding your telescope, there are better solutions for that.
star = ephem.FixedBody(ra=123.123, dec=45.45)
in my case fixedbody creation does not work, should be
star = ephem.FixedBody()
star._ra = ephem.hours('10:10:10')
star._dec = ephem.degrees('10:10:10')
Does anyone know an algorithm to either calculate the moon phase or age on a given date or find the dates for new/full moons in a given year?
Googling tells me the answer is in some Astronomy book, but I don't really want to buy a whole book when I only need a single page.
Update:
I should have qualified my statement about googling a little better. I did find solutions that only worked over some subset of time (like the 1900's); and the trig based solutions that would be more computationally expensive than I'd like.
S Lott in his Python book has several algorithms for calculating Easter on a given year, most are less than ten lines of code and some work for all days in the Gregorian calendar. Finding the full moon in March is a key piece of finding Easter so I figured there should be an algorithm that doesn't require trig and works for all dates in the Gregorian calendar.
If you're like me, you try to be a careful programmer. So it makes you nervous when you see random code scattered across the internet that purports to solve a complex astronomical problem, but doesn't explain why the solution is correct.
You believe that there must be authoritative sources such as books which contain careful, and complete, solutions. For instance:
Meeus, Jean. Astronomical Algorithms. Richmond: Willmann-Bell, 1991. ISBN 0-943396-35-2.
Duffett-Smith, Peter. Practical Astronomy With Your Calculator. 3rd ed. Cambridge:
Cambridge University Press, 1981. ISBN 0-521-28411-2.
You place your trust in widely-used, well-tested, open source libraries which can have their errors corrected (unlike static web pages). Here then, is a Python solution to your question based on the PyEphem library, using the Phases of the Moon interface.
#!/usr/bin/python
import datetime
import ephem
from typing import List, Tuple
def get_phase_on_day(year: int, month: int, day: int):
"""Returns a floating-point number from 0-1. where 0=new, 0.5=full, 1=new"""
#Ephem stores its date numbers as floating points, which the following uses
#to conveniently extract the percent time between one new moon and the next
#This corresponds (somewhat roughly) to the phase of the moon.
#Use Year, Month, Day as arguments
date = ephem.Date(datetime.date(year,month,day))
nnm = ephem.next_new_moon(date)
pnm = ephem.previous_new_moon(date)
lunation = (date-pnm)/(nnm-pnm)
#Note that there is a ephem.Moon().phase() command, but this returns the
#percentage of the moon which is illuminated. This is not really what we want.
return lunation
def get_moons_in_year(year: int) -> List[Tuple[ephem.Date, str]]:
"""Returns a list of the full and new moons in a year. The list contains tuples
of either the form (DATE,'full') or the form (DATE,'new')"""
moons=[]
date=ephem.Date(datetime.date(year,1,1))
while date.datetime().year==year:
date=ephem.next_full_moon(date)
moons.append( (date,'full') )
date=ephem.Date(datetime.date(year,1,1))
while date.datetime().year==year:
date=ephem.next_new_moon(date)
moons.append( (date,'new') )
#Note that previous_first_quarter_moon() and previous_last_quarter_moon()
#are also methods
moons.sort(key=lambda x: x[0])
return moons
print(get_phase_on_day(2013,1,1))
print(get_moons_in_year(2013))
This returns
0.632652265318
[(2013/1/11 19:43:37, 'new'), (2013/1/27 04:38:22, 'full'), (2013/2/10 07:20:06, 'new'), (2013/2/25 20:26:03, 'full'), (2013/3/11 19:51:00, 'new'), (2013/3/27 09:27:18, 'full'), (2013/4/10 09:35:17, 'new'), (2013/4/25 19:57:06, 'full'), (2013/5/10 00:28:22, 'new'), (2013/5/25 04:24:55, 'full'), (2013/6/8 15:56:19, 'new'), (2013/6/23 11:32:15, 'full'), (2013/7/8 07:14:16, 'new'), (2013/7/22 18:15:31, 'full'), (2013/8/6 21:50:40, 'new'), (2013/8/21 01:44:35, 'full'), (2013/9/5 11:36:07, 'new'), (2013/9/19 11:12:49, 'full'), (2013/10/5 00:34:31, 'new'), (2013/10/18 23:37:39, 'full'), (2013/11/3 12:49:57, 'new'), (2013/11/17 15:15:44, 'full'), (2013/12/3 00:22:22, 'new'), (2013/12/17 09:28:05, 'full'), (2014/1/1 11:14:10, 'new'), (2014/1/16 04:52:10, 'full')]
I ported some code to Python for this a while back. I was going to just link to it, but it turns out that it fell off the web in the meantime, so I had to go dust it off and upload it again. See moon.py which is derived from John Walker's moontool.
I can't find a reference for this for what time spans it's accurate for either, but seems like the authors were pretty rigorous. Which means yes, it does use trig, but I can't imagine what the heck you would be using this for that would make it computationally prohibitive. Python function call overhead is probably more than the cost of the trig operations. Computers are pretty fast at computing.
The algorithms used in the code are drawn from the following sources:
Meeus, Jean. Astronomical Algorithms. Richmond: Willmann-Bell, 1991. ISBN 0-943396-35-2.
A must-have; if you only buy one book, make sure it's this one. Algorithms are presented mathematically, not as computer programs, but source code implementing many of the algorithms in the book can be ordered separately from the publisher in either QuickBasic, Turbo Pascal, or C. Meeus provides many worked examples of calculations which are essential to debugging your code, and frequently presents several algorithms with different tradeoffs among accuracy, speed, complexity, and long-term (century and millennia) validity.
Duffett-Smith, Peter. Practical Astronomy With Your Calculator. 3rd ed. Cambridge: Cambridge University Press, 1981. ISBN 0-521-28411-2.
Despite the word Calculator in the title; this is a valuable reference if you're interested in developing software which calculates planetary positions, orbits, eclipses, and the like. More background information is given than in Meeus, which helps those not already versed in astronomy learn the often-confusing terminology. The algorithms given are simpler and less accurate than those provided by Meeus, but are suitable for most practical work.
I think you searched on wrong google:
http://home.att.net/~srschmitt/zenosamples/zs_lunarphasecalc.html
http://www.voidware.com/moon_phase.htm
http://www.ben-daglish.net/moon.shtml
http://www.faqs.org/faqs/astronomy/faq/part3/section-15.html
Also, pyephem — scientific-grade astronomy routines [PyPI], which is a Python package but has the computational guts in C, and that does say
Precision < 0.05" from -1369 to +2950.
Uses table lookup techniques to limit calls to trigonometric functions.
PyEphem is now deprecating - they recommend preferring Skyfield astronomy library over PyEphem for new projects. Its modern design encourages better Python code, and uses NumPy to accelerate its calculations.
The phase of the Moon is defined as the angle between the Moon and the
Sun along the ecliptic. This angle is computed as the difference in
the ecliptic longitude of the Moon and of the Sun.
The result is an angle that is 0° for the New Moon, 90° at the First Quarter, 180° at the Full Moon, and 270° at the Last Quarter.
Code taken from here
from skyfield.api import load
from skyfield.framelib import ecliptic_frame
ts = load.timescale()
t = ts.utc(2019, 12, 9, 15, 36)
eph = load('de421.bsp')
sun, moon, earth = eph['sun'], eph['moon'], eph['earth']
e = earth.at(t)
_, slon, _ = e.observe(sun).apparent().frame_latlon(ecliptic_frame)
_, mlon, _ = e.observe(moon).apparent().frame_latlon(ecliptic_frame)
phase = (mlon.degrees - slon.degrees) % 360.0
print('{0:.1f}'.format(phase))
Output
149.4
Pyephem by default uses coordinated universal (UTC) time. I wanted a program that would generate a list of full moons that would be accurate in the pacific time zone. The code below will calculate the full moons for a given year and then adjust that using the ephem.localtime() method to calibrate to the desired time zone. It also appears to properly account for daylight savings time as well. Thank you to Richard, this code is similar to what he had written.
#!/usr/bin/python
import datetime
import ephem
import os
import time
# Set time zone to pacific
os.environ['TZ'] = 'US/Pacific'
time.tzset()
print("Time zone calibrated to", os.environ['TZ'])
def get_full_moons_in_year(year):
"""
Generate a list of full moons for a given year calibrated to the local time zone
:param year: year to determine the list of full moons
:return: list of dates as strings in the format YYYY-mm-dd
"""
moons = []
date = ephem.Date(datetime.date(year - 1, 12, 31))
end_date = ephem.Date(datetime.date(year + 1, 1, 1))
while date <= end_date:
date = ephem.next_full_moon(date)
# Convert the moon dates to the local time zone, add to list if moon date still falls in desired year
local_date = ephem.localtime(date)
if local_date.year == year:
# Append the date as a string to the list for easier comparison later
moons.append(local_date.strftime("%Y-%m-%d"))
return moons
moons = get_full_moons_in_year(2015)
print(moons)
The code above will return:
Time zone calibrated to US/Pacific
['2015-01-04', '2015-02-03', '2015-03-05', '2015-04-04', '2015-05-03', '2015-06-02', '2015-07-01', '2015-07-31', '2015-08-29', '2015-09-27', '2015-10-27', '2015-11-25', '2015-12-25']
I know that you're looking for Python but if you can understand C# there's an open source project out there called Chronos XP which does this very well.
If you don't need high accuracy, you can always (ab)use a lunar (or lunisolar) calendar class (e.g., HijriCalendar or ChineseLunisolarCalendar in Microsoft .NET) to calculate the (approximate) moon phase of any date, as the calendar's "day-of-month" property, being a lunar (or lunisolar) calendar day, always corresponds to the moon phase (e.g., day 1 is the new moon, day 15 is the full moon, etc.)