Libraries

JTS and Geotools

OTP has dependencies on both JTS and Geotools. OTP sometimes uses JTS directly, and sometimes via Geotools which also depends on JTS. Here are some links explaining this situation:

• http://docs.geotools.org/latest/userguide/library/jts/faq.html
• http://docs.geotools.org/latest/userguide/library/jts/index.html

JTS does not know about or make use of spatial/coordinate reference systems. It handles mathematical/topology calculations assuming entirely planar geometry. GeoTools does the rest of the GIS-style work to give planar geometry meaning on the Earth's surface: referencing (i.e. coordinate systems and transforms), features, rendering, database/file access etc. Geotools uses JTS to avoid reinventing the wheel, benefiting from years of work on numerically stable topology methods. It follows that for JTS calculations to be correct, the geometry objects must be projected to a CRS that looks locally planar.

In fact, OpenTripPlanner stores all geometries in WGS84 latitude and longitude. This is because most of our data sources and clients provide/expect unprojected coordinates. It would be impossible to settle on a single coordinate reference system for the whole Earth, and problematic to require all OTP users to learn about projections and properly set projection parameters for their local region. Instead, OTP has grown a set of functions that work directly on unprojected geographic coordinates, assuming a spherical Earth and an equirectangular or sinusoidal projection. These simplifications give completely reasonable results for our use case, where we only really need relative distances between points, projections of points onto lines, and spatial indexing. It is therefore entirely possible that we could one day transition to our own small spherical geometry library.

Note that Geotools provides a GeodeticCalculator for ellipsoidal distance calculations and a JTS.orthodromicDistance() method:

• http://docs.geotools.org/stable/javadocs/org/geotools/geometry/jts/JTS.html