Spherical Geography support

[jagill]

Background

Presto Java has basic support for Spherical Geographies and some functions on them: ST_Area, ST_Length, ST_Distance, ST_Centroid. Spherical Geographies differ from Geometries in two core ways:

1. Geometries are on a Euclidean (flat) 2D plane. Spherical Geographies as on a sphere (sort of, see next).
2. The "Geography" part is that they use the WGS84 oblate spheroid and datum instead of a sphere.

When users want to calculate distances/etc on Earth, using a planar geometry has significant errors. Longitudinal distance (east-west) are smaller on a sphere by a factor of cosine(latitude), which is ~0.79 for San Francisco and ~0.62 for London. Distance between two points has an additional error factor that it should be measured along a great circle not a straight line (in lon/lat space).

Errors from using a perfect sphere vs an oblate spheroid are less than 1%.

Presto Java

Presto Java uses the open source ESRI Java library to do these geographical calculations. ESRI C++ is closed source and thus we can't use it Velox. GEOS (which we use in Velox) only supports planar calculations. We have to decide what functions we want to support in Velox, and how to support them.

Understanding current usage

The first step is determining the usage of these geography-enabled functions. Internally at Meta we are analyzing our queries, by filtering on queries that use to_spherical_geography, then looking at the usage of ST_Area, ST_Length, ST_Distance, ST_Centroid in these.

We'd also like to know the use of these outside of Meta. Do you or your customers use these functions? If so, what is their accuracy tolerance? All geographical calculations have some inaccuracy, but the tolerance for that inaccuracy varies widely depending on use-case.

@aditi-pandit Do we know if and how the IBM customers are using these functions?
@jkhaliqi Do we know if and how Uber is using these functions?
Anyone else?

cc @mbasmanova @pedroerp @kgpai @Sullivan-Patrick @czentgr