Bearing to Yerushalayim and Zmanim Map 2.0

Vintage Map with CompassThe availability of the Bearing to Yerushalayim and Zmanim Map was originally announced on December 30, 2007. At the time there were a number of bugs related to the Google Map API. These bugs were reported to Google and eventually fixed. Since that time, the only change was a minor JavaScript fix for IE. The Bearing to Yerushalayim worked, but the zmanim tabs had a major issue because the timezone calculated was done based on the user’s current browser timezone. This made it tricky to check zmanim in a different location or timezone than the user’s current timezone.Zmanim tab using timezonesI recently updated the map to look-up the actual timezone of the latitude and longitude selected by the user. This was implemented by doing a look-up at the geonames.org timezone web-service. The timezone is passed to the Zmanim API and used to generate the XML output of a list of daily zmanim that is displayed in the map. Since the Olson timezone database changes a few times a year, there will almost certainly be cases where the proper timezone can’t be determined. Some of these are changes of timezone names, such as the change from Asia/Calcutta to Asia/Kolkata (my host will not run the TZ Updater tool). In these cases, a simple mapping between the old and new was added to the map. In cases where the timezone can’t be determined the timezone will default to GMT. Ocean locations within 10 km of land will use the closest landmass, but anywhere beyond 10 km will default to GMT. One issue with using the geonames.org webservice, is that when it is down, the map will timeout. I experimented with various ways of dealing with this, but unless my host updates the Java version from 1.4, they are too complex to use at this time.

See the Technical Information about the Bearing to Yerushalayim Map post for technical details about the original implementation.

Zmanim API 1.2 Released

The Zmanim API 1.2 was released today. The only change in this release is the removal of elevation as a factor in the calculation of all zmanim besides sunrise and sunset. Updated JavaDocs now reflect these changes. Please see the Elevation Now Only Impacts Sunrise and Sunset Calculations in the Zmanim API post for additional information.

I would like to thank the various people who contacted me on the subject.

The main download is the Zmanim 1.2 release zip file that includes source files and JavaDoc documentation. Also available for download (included in the above zip file) is the main zmanim-1.2.jar. The zmanimAstronomical-1.1.jar that only includes the AstronomicalCalendar was not impacted by this change, but the version has been updated to zmanimAstronomical-1.2.jar for consistency. Additional detail on the downloads can be seen on the Zmanim Download page

Elevation Now Only Impacts Sunrise and Sunset Calculations in the Zmanim API

Sunrise over Everest

Note: On Aug 1, 2018 – כ״א אב תשע״ח, elevation became optionally available as a factor in most zmanim calculations. The KosherJava Zmanim library was updated to optionally allow using elevation as an attribute that will adjust most zmanim via the ZmanimCalendar​.setUseElevation(boolean). There are some zmanim such as degree-based zmanim that are driven by the amount of light in the sky and are not impacted by elevation. These zmanim intentionally do not support elevation adjustment. The following is the original post.


I have received a few emails over the past year or so about the use of elevation as part of the calculation of various zmanim in the API. All releases of the zmanim API up to the current 1.1 release, use elevation to affect the calculation of all sunrise/sunset based zmanim. While my footnote on the Zmanim Calendar Generator page stated that this only impacted sunrise and sunset (quoting the Yisrael Vehazmanim and Calendrical Calculations), in practice all zmanim calculated based on sunrise and sunset were affected by elevation. An example of a zman that used elevation in 1.1, but will no longer in 1.2, is the calculation of Sof Zman Krias Shema according to the GR”A. The soon to be released version 1.2 limits the impact of elevation to sunrise and sunset only. The Zmanim Calendar Generator page already uses the latest changes to the code. To facilitate changes by ports of the API, a list of changes to the source code of the ZmanimCalendar.java and ComplexZmanimCalendar.java is available in a diff file (a proper Unix diff/patch is not available at this time). The diff files were generated prior to updating the JavaDocs to simplify the work of anyone modifying ports of the Zmanim API. Detailed sources for not using elevation for anything besides sunrise and sunset can be found in פרק ב׳ סעיף ט׳ (pages 186-187) in the second edition of Zmanim Kehilchasam זמנים כהלכתם by Rabbi Dovid Yehuda Bursztyn.

Calculating the Bearing/Direction to Har Habayis Using the Zmanim API

Vintage Map with CompassAn earlier “Bearing to Yerushalayim and Zmanim Map” post demonstrated the use of JavaScript to render the bearing to Har Habayis on a Google Map. A more detailed follow-up post “Technical Information about the Bearing to Yerushalayim Map” dealt with detailed technical information on these calculations. The main Bearing to Yerushalayim and Zmanim Map page usually has the most up to date information on the subject. What was not detailed in previously published posts and pages was that most of the calculations available via JavaScript are now in the core Zmanim API. Available since the July, 2008 beta 2 release of version 1.1 is the ability to bearings/directions using both the great circle and rhumb line methods in Java. The GeoLocation Object was modified to calculate the great circle bearings (both initial and final), and rhumb line bearing from any GeoLocation Object to another. In addition, distance calculation between the two points using both of these line types is supported. What was not ported from the JavaScript version was the less accurate Haversine formula, or the simpler spherical law of cosines algorithms that yield identical results. Instead, the Zmanim API uses the far more accurate Vincenty formulae using the WGS84 geoid model of the earth. Published by the geodesist/mathematician Thaddeus Vincenty, it is said to be accurate to about one-half millimeter, more than adequate for our calculation. The code in the API is a Java port of the previously published, slightly modified version of Chris Veness’s JavaScript implementation . Below is a simple Java example of generating bearing and distances.

/**
 * This program demonstrates how to calculate bearing to Yerushalayim
 * using the kosherjava.com Zmanim API. Both the great circle and
 * rhumb line method are shown
 * To compile, ensure that the Zmanim Jar is in your classpath.
 */
import com.kosherjava.zmanim.util.GeoLocation;
import java.util.TimeZone;

public class BearingToYerushalayim{
	public static void main(String [] args) {
		GeoLocation lakewood = new GeoLocation("Lakewood, NJ", 40.09596, -74.22213, 0, TimeZone.getTimeZone("America/New_York"));
		GeoLocation harHabayis = new GeoLocation("Har Habayis", 31.77805, 35.235149, 0, TimeZone.getTimeZone("Asia/Jerusalem"));

		double greatCircleInitialBearing = lakewood.getGeodesicInitialBearing(harHabayis);
		double greatCircleDistance = lakewood.getGeodesicDistance(harHabayis);

		double rhumbLineBearing = lakewood.getRhumbLineBearing(harHabayis);
		double rhumbLineDistance = lakewood.getRhumbLineDistance(harHabayis);

		System.out.println("Great circle initial bearing: " + greatCircleInitialBearing + " degrees ");
		System.out.println("Great circle distance: " + greatCircleDistance / 1000 + " km");

		System.out.println("Rhumb line bearing: " + rhumbLineBearing + " degrees");
		System.out.println("Rhumb line distance: " + rhumbLineDistance / 1000 + " km");

	}
}

ZmanimCLI (Command Line Interface)

Java Logo SepiaMoshe Wagner who wrote the Zmanim GUI notified me in August that that he created a command line interface for zmanim using my Zmanim API. The technical approach of using reflection was similar to the way I used reflection in the Zmanim Clock Applet, but he took it to new heights. Sample use of accessing zmanim using his CLI interface is:

moshe@debian:~/Desktop$ java -jar ZmanimCLI.jar sunrise
6:10:28
moshe@debian:~/Desktop$ java -jar ZmanimCLI.jar --date 2010/08/12 tzais72
20:38:15
moshe@debian:~/Desktop$ java -jar ZmanimCLI.jar
Usage: ZmanimCLI [options] [Time]

Options:
       -d      --date <yyyy/mm/dd>             Set date. (Year first!)
       -lat    --latitude <latitude>           Set location's latitude
       -lon    --longitude <longitude>         Set location's longitude
       -e      --elevation <elevation>         Set location's
elevation; Positive only
       -tz     --timezone <timezone>           Set location's TimeZone

Help:
       -h      --help                          Show this help
       -stl    --time-list                     Show common available
times to display
       -ftl    --full-time-list                Show all available
times to display
       -tzl    --timezone-list                 Show available timezones

Example:
       ZmanimCLI --latitude 31.7780 --longitude 35.235149 --elevation
600 --timezone Israel Sunrise
       Will show the sunrise time today in Jerusalem

While your first reaction may be that it is interesting in a theoretical geeky way, but has no practical value, I will quote Moshe’s explanation as to why it is useful:

Why is this useful? Well, first of all it was a nice experiment. But mainly, you can now use Zmanim (although externally), via any language you want, no longer being tied to Java.

Months later, Moshe actually put this to practical use in his C++ based Luach project. This Luach (similar to the known Kaluach) uses the Qt framework. utilizing libhdate for the date stuff (something not offered by the Zmanim API, and the topic of a future Zmanim API FAQ), displaying zmanim using the Zmanim API via CLI for the zmanim calculations. While you would expect such an approach to be slow, using the Luach seemed almost instantaneous. I will post more about his Luach program (recently reviewed at KosherDev.com) at some point in the future.