klausbrunner / solarpositioning Goto Github PK

Current one works ok if you only need a single pair of values, but users interested in twilight values will probably want more than one (e.g. sunrise/sunset + civil + nautical twilight). Then it's just repetitive and inefficient, as some calculations are repeated needlessly.

Maybe something along the lines of

List <SunriseTransitSet> bla = calculate(....., List.of(Horizon...., Horizon...))

Then refactor internally to separate the constant parts from those dependent on horizon type.

I am a new person in the java dev area and I wanted to use the repo in my project but i am confused about how to use the library what things do i need to have installed and do i need to make a jar file of the library could you please guide me for the same

I'm getting wrong sunrise/set information for:
Resolute Bay 74.6973, -94.8297 , November 1st, 2016
Returning Null, Null.
However there is a sunrise and sunset on this day.. and even 2nd, 3rd, 4rd, and 5th.. All of those return null.

DateTime dt = new DateTime(2016, 11, 1, 1, 0);
SPA.calculateSunriseTransitSet(dt.toGregorianCalendar(), 74.6973, // latitude
-94.8297, // longitude 68); // delta T

Unless I'm doing something wrong, it seems the error in the higher latitude is very big. If I enter a lower latitude I get results that look more accurate when comparing with other sources.

Not planned in the short term, but probably sometime 2016. Would allow using the new Joda-like date/time APIs instead of the awful old Date/Calendar mess.

Finally do all the paperwork and configuration to get this published on Maven Central.

http://central.sonatype.org/pages/apache-maven.html

There seems to be some demand for twilight times, so look into supporting those (civil/nautical/astronomical, perhaps also "golden hour").

Hi, there is a bug on file SPA.java, line 575

this one

pow(jd.julianCentury(), 2) / 38710000);

should be

pow(jd.julianCentury(), 3) / 38710000);

tried to compile using mvn however need to changed the default compiler from 1.3 to 1.7 in the pom.xml.

example would be adding following lines in the pom.xml :

maven-compiler-plugin
2.3.2

1.6
1.6

Testing of SPA and Grena3 in particular is a bit spotty - yet the test code is repetitive at the same time.

Should have a well-distributed collection of locations and times to use for both.

It's in the NREL SPA report.

Test coverage of DeltaT is a bit spotty, i.e. not all branches of that big switch are executed.

Might also use historic data tables like https://maia.usno.navy.mil/ser7/historic_deltat.data or https://astro.ukho.gov.uk/nao/lvm/Table-S15.2020.txt

Generally, the 2007 Espenak/Meeus polynomials don't seem to work very well these days (about 4 seconds off).

https://www.eclipsewise.com/help/deltatpoly2014.html seems to be an update to the 2007 NASA page based on data up to 2014 or 2015.

Algorithm 4 might be a good candidate to replace PSA.

https://github.com/woheller69/solarcast

Hey Klaus.
Any plans to expand the library to support moon and milky way calculations too?
Or maybe you could point me to some papers, or C++ libraries that do that?
Thanks

On SPA.calculateSunriseTransitSet, sun transit is calculated even when there is no sunrise nor sunset and that it is the night (case when the position is inside the Arctic circle).

GregorianCalendar cal = new GregorianCalendar(TimeZone.getTimeZone(ZoneId.of("Europe/Paris")));
cal.set(Calendar.YEAR, 2017);
cal.set(Calendar.DAY_OF_YEAR, 01);
SPA.calculateSunriseTransitSet(cal, 78., // latitude
16., //Longitude
DeltaT.estimate(cal)); // delta T

A simple correction could be to return null for sun transit when :
final boolean noDay = (acosArg > 1.0);

Or if this behaviour is correct for you, can we get another method to get information on if there is a day or not.

Sanity check on refraction params is reversed

Should be easy: http://eclipse.gsfc.nasa.gov/SEhelp/deltatpoly2004.html