search

locationtech / geowave

GeoWave provides geospatial and temporal indexing on top of Accumulo, HBase, BigTable, Cassandra, Kudu, Redis, RocksDB, and DynamoDB.
Apache License 2.0
502 stars 190 forks source link

Orthodromic Distance fails if points are close together (within some Epsilon) #540

Closed rwgdrummer closed 9 years ago

rwgdrummer commented 9 years ago

An assertion, active only in integration tests for GeWave, within the GeoTools code checks between ellipsoid distance and spherical distance (both orthodromic distance computations). d1 = od d2 = ed if (abs(d1-d2) < 1E-14) fail. When the points are close together, the difference in the distance is above 1E-14. 'Close'. in this case is, defined as 0.05 meter. In this case, just use the elliptical distance. This will not occur at the poles, as GeoTool's code uses Ellipsoid in this case (no comparison).
The assertion should be ignored for GeoWaves's purposes.

drew-bower commented 9 years ago

How does orthodromic distance compare to elliptical distance. Can you point me a reference?

rwgdrummer commented 9 years ago

Actually, according to the code, the approaches are similar. One is ellipsoidal and one is spherical. They use the same CRS and similar algorithms (same comments and references, show below). The 'check' is only used as an assertion, which is turned on in the integration tests. When working with the poles, the Ellipsoid approach is always used. But there is going to be places on the globe using WGS84 where the distances will diverge. This is ok. However, the code has an 'assertion' used for internal checking. Normally, assertions are turned off. GeoWave uses assertions in integration tests. So, the point of this ticket is the bypass the assertion.

FYI The comment from GeoTools's code sites the following algorithm (for both ellipsoid and circle).

     * Solution of the geodetic inverse problem after T.Vincenty.
     * Modified Rainsford's method with Helmert's elliptical terms.
     * Effective in any azimuth and at any distance short of antipodal.
     *
     * Latitudes and longitudes in radians positive North and East.
     * Forward azimuths at both points returned in radians from North.
     *
     * Programmed for CDC-6600 by LCDR L.Pfeifer NGS ROCKVILLE MD 18FEB75
     * Modified for IBM SYSTEM 360 by John G.Gergen NGS ROCKVILLE MD 7507
     * Ported from Fortran to Java by Daniele Franzoni.
rwgdrummer commented 9 years ago

Updated description for clarity.

drew-bower commented 9 years ago

I guess I'm generally interested in geodesic measurement and related extensions of range/azimuth projections and buffering operations for all geometry types. Probably should be another issue, not well suited for this one.

rwgdrummer commented 9 years ago

We use the same computation for buffering as well. The reason is that the default buffering through CQL DWITHIN is in degrees. It effectively ignores the unit. (See issues #410 & #403). Chris Bennight mentioned improving buffering with a smarter algorithm around the poles that uses something like Azimuthal Equidistant or Stereographic projections.