We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Geodesic algorithms: an experimental study

00:00

Formal Metadata

Title
Geodesic algorithms: an experimental study
Title of Series
Number of Parts
295
Author
Contributors
License
CC Attribution 3.0 Germany:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
The figure of the Earth can be modelled either by a cartesian plane, a sphere or an (oblate) ellipsoid, in decreasing order with respect to the approximation quality. The shortest path between two points on such a surface is called a geodesic. Studying geodesic problems on ellipsoids dates back to Newton. However, the majority of open-source GIS systems today use methods on the cartesian plane. The main advantages of those approaches are simplicity of implementation and performance. On the other hand, those approaches come with a handicap: accuracy. We experimentally study the accuracy-performance trade-offs of various methods for distance computation (as well as similar geodesic problems such as azimuth and area computation). We test projections paired with cartesian computations, spherical-trigonometric computations and a number of ellipsoidal methods such as [Andoyer'65] and [Thomas'70] formulas, [Vincenty'75] iterative method, great elliptic arc's method, and [Karney'15] series approximation. We also show that some methods from the bibliography (e.g. [Tseng'15]) are neither faster nor more accurate compared to the above list of methods and thus become redundant. For our experiments we use the open source libraries Boost Geometry and GeographicLib. Our results are of independent interest since we are not aware of a similar experimental study. More interestingly, they can be used as a reference for practitioners that want to use the most efficient method with respect to some given accuracy. Geodesic computations (such as distance computations) apart from being a fundamental problem in computational geometry and geography/geodesy are also building blocks for many higher level algorithms such as k-nearest neighbour problems, line interpolation, densification of geometries, area and buffer, to name a few. # References * Some experimental results can be found here: https://github.com/vissarion/geometry/wiki/Accuracy-and-performance-of-geographic-algorithms * A related talk (with some graphs on performance and accuracy) can be found here https://fosdem.org/2019/schedule/event/geo_boostgeometry * The source code of most of the algorithms of the study is in Boost Geometry: https://github.com/boostorg/geometry but we contain to our study GeographicLib https://geographiclib.sourceforge.io
Keywords
129
131
137
139
Thumbnail
28:17
Coordinate systemCurvatureProjektive GeometrieAlgorithmGeodesicBitDistanceEllipsoidSurface of revolutionEndliche ModelltheorieWorkstation <Musikinstrument>Web pagePhysical systemBenchmarkComputational geometryLecture/Conference
MultiplicationSphereGeodesicGoodness of fitCoordinate systemState of matterSurface of revolutionSpacetimeInformationEndliche ModelltheorieHyperplaneAnalogyCurveObject (grammar)Rhumb lineAngleAlpha (investment)NavigationCommutatorDistanceComputational geometryLevel (video gaming)SphereApproximationsalgorithmusSeries expansionComplex (psychology)Numerical integrationPoint (geometry)Trigonometric functionsInverse elementWell-formed formulaPythagorean theoremProjektive GeometrieLine (geometry)Great circleEllipsoidINTEGRALImage resolutionIterationSet (mathematics)AzimuthOrder (biology)BenchmarkSeries (mathematics)Observational studyGeodesicAlgorithmPresentation of a groupQuicksortService (economics)Video projectorForcing (mathematics)Multiplication signCASE <Informatik>Arithmetic meanCondition numberProduct (business)Valuation (algebra)Regulator geneThermal expansionMeasurementOvalFault-tolerant systemBridging (networking)PhysicalismLecture/Conference
AlgorithmGeodesicGeometryIterationSeries (mathematics)ApproximationSeries (mathematics)Numerical analysisDisintegrationEllipseInverse elementCartesian productLocal ringAxonometric projectionPoint (geometry)ApproximationAreaPopulation densitySimilarity (geometry)Hausdorff spaceRevision controlBenchmarkEllipsoidWikiLengthWell-formed formulaCASE <Informatik>Goodness of fitCodeProjektive GeometrieAlgorithmSoftwareSeries (mathematics)Line (geometry)Point (geometry)Computational geometryResultantDistanceBenchmarkGeometryImplementationEllipseSimilarity (geometry)ApproximationsalgorithmusBlock (periodic table)String (computer science)BuildingInterpolationDivergenceGeodesicNumerical analysisInverse elementAzimuthAreaImage resolutionFlow separationDirection (geometry)State of matterMeasurementOpen sourceSeries expansionInverse problem1 (number)Arc (geometry)Black boxOrder (biology)Limit (category theory)Thermal expansionForm (programming)TelecommunicationNetwork topologyPolygonSet (mathematics)TrailMedical imagingService (economics)Visualization (computer graphics)Open setGraphics tabletSummierbarkeitProcess (computing)JSONXML
GeodesicAverageTable (information)GeometryCurvatureSphereAzimuthDistanceHopf algebraApproximationSeries (mathematics)Point (geometry)Ordinary differential equationAreaCartesian productAxonometric projectionEquals signOperations researchMilitary operationGroup actionCylinder (geometry)Conic sectionPlot (narrative)OracleScaling (geometry)Execution unitGoodness of fitCASE <Informatik>Automatic differentiationRevision controlFile formatGrass (card game)Newton's law of universal gravitationBitProjektive GeometrieTable (information)AreaResultantDistancePoint (geometry)Connected spaceDifferent (Kate Ryan album)Error messageEqualiser (mathematics)Computational geometryBenchmarkMetreParameter (computer programming)Optical disc driveSoftware testingInsertion lossDenial-of-service attackLogic gateSaddle pointDreizehnMultiplication signProcess (computing)Limit (category theory)Digital photographyCartesian coordinate systemSet (mathematics)AzimuthWell-formed formulaFlow separationGeodesicEllipsoidAcoustic shadowTrapezoidCurvatureApproximationsalgorithmusWikiHierarchySeries (mathematics)Order (biology)GeometryAlgorithmLibrary (computing)AuthorizationInverse problemImplementationComputer animation
Basis <Mathematik>Game theoryDifferent (Kate Ryan album)AreaBitPoint (geometry)CollisionMetreSquare numberError messageOperator (mathematics)Computational geometrySeries (mathematics)Computer animationLecture/Conference
Mach's principleAzimuthDemosceneDistancePoint (geometry)Process (computing)Roundness (object)Workstation <Musikinstrument>Multiplication signWeb pageMachine visionState of matterPresentation of a groupLecture/Conference
Transcript: English(auto-generated)
All right, good afternoon, everyone. Thank you for coming to the session on geodesic algorithms. I'd like to welcome our next speaker to present his research. Thank you. Thanks.
So today we're going to talk a bit about how we compute distances on ellipsoid revolution and some benchmarks. So let me start with some basics. So there are several models of the Earth and coordinate system.
So the simplest one, if you get some projection to the two dimensions, is to model the Earth as flat and then have some bad approximation in general, but good if you are in some local place. And then a better level of approximation
is to consider the Earth as a sphere. And then you could have log-latitude coordinates. As far as I understand, the state of the art for GIS computations is the ellipsoid of a revolution.
So the Earth is not exactly a sphere. And then you could also have geodes. So I'm not a space analyst in this, so maybe you have geophysics here can tell us more. So you have more information about the altitude also and valleys and mountains. So I'm not considering this model here,
at least in this presentation. So what is a geodesic? It's the shortest path between two points. So in 2D, it's just a straight line. In the sphere, it's a great circle. So it's an intersection of a hyperplane passing
through the center of the sphere. In ellipsoid, it's not the same. So if you intersect the ellipsoid with a hyperplane passing from the center, you will get a great ellipse, which is analog to great circle, which is not the shortest path. So the shortest path is a curve
that goes around your object. So since there are a few talks here about Mercator projections, it's nice to see that, of course, there the straight lines are not shortest paths.
They're called loxodromes that keep the azimuth, which is the angle from the point that you are to the north or south pole. And of course, as many of you know better than me, the shortest paths are curves on this projection.
So in general, there are two main problems, two main geodesic problems. The one is called the direct and the other the inverse. So in the first, we are given the point, the azimuth, and the distance. And we won't compute the new point at that distance.
So here, we are given a, and then lowercase alpha 1, which is the azimuth, and the distance, s12. And we want to compute b. So it's like navigating. We are in some point of an angle
and a value of the distance. And then we're going to go there. So this is a direct geodesic problem. And we also have the inverse, actually the distance commutation problem. So we have two points, a and b. And we won't compute s12. And also as a byproduct, we can compute the azimuth alpha 1.
So first, sorry for this slide. This is just to illustrate the complexities between those two models. I will not explain the formulas. The first is self-explanatory.
It's the Pythagoras theorem in 2D. There is an ancient closed formula. For the sphere, the shortest distance between two points is a trigonometric function. It's readily evaluated. But on ellipsoid, the shortest distance
is given by a set of integrals. So you have to do some more complicated computations. This is not rocket science. It's something that is solved. But here we like to study benchmarks on performance and accuracy.
So this is really old, of course. But compared to the sphere, this is not a closed formula. So what you usually do is some evaluation, either by numerical integration or series expansion. And then you also need some iteration
to convert to the solution. So no more technical details here. So this is a set of, I tried to collect a set of algorithms for geodesic problems. So I'm open to suggestions for more if you have.
The first one is a series approximation, which goes back to Bessel. And it's rediscovered, maybe re-engineered by Carney, together with an iterative method to give a very accurate solution up to series order
8 to the two geodesic problems that I described before. Another method is a numerical integration, how we studied the literature.
So we are not considering this here. And the third one is, as far as I see, the most widely used. It's within the iterative method for computing the distance. And there are some old school ones that can be retrieved from papers from the 60s and 70s.
There are series approximation of order one and two by Thomas and Doyer. And then you have the spherical one, which is the Haberstein formula that we showed. And there are some, again, in this series of papers
from the 60s, there are also some inverse elliptic arc length formulas. Again, those are by series expansions. And the last thing that you can do is to take some projection that maybe fits on your data and do some Cartesian computation.
So the first case is implemented in geographic leap. We still have a work from boost geometry. So we have a pull request from a good number of code project that we, in the future, we also
add this algorithm in boost geometry. So two is not, I don't even know if it's open source or I don't know if any implementation is available. And the rest, we support them in one or the other way
in boost geometry. So I'm just saying this to declare which software I will use for the benchmark. So it's basically geographically bent implementations in boost geometry. OK, so this is the first example. I want to compute the distance between Athens and Brussels. These are given in longitude latitude.
So the first method of this high series expansions give this value for this particular problem up to this accuracy. It visually seems the same as Vincenti. And then you can see that by choosing
the other less accurate methods, we have some divergence in the results. So Thomas is a few centimeters. I assume that the first one is the most accurate. And then I have Andoia and these elliptic formulas.
OK, so apart from Vincenti, all these are these 70s old school formulas that we use in boost geometry because they are fast. But as we can see, they also give some nice results. OK, I will systematically explain this later.
And then we have also a spherical approach. And here if we project and compute the distance, so this is one kind of projection, which I am not citing here, you get something really bad
because the distance is too long. OK, so distance computation and the direct problem are building blocks for other algorithms too.
So if you want to compute the distance between geometries, in general, so for example, between a line string and a multi-polygon, then the building block will be to compute the distance between two points or a point of the segment. So it is important to build on top
all the or many geographic algorithms. So when you want to compute the area of a polygon, then you need to compute the azimuth. So again, you need to solve the inverse problem. In other algorithms too, like a line interpolate points
when you interpolate points on a line string or if you densify a geometry, then inside you want to solve both direct and inverse problems. So they are almost everywhere in the whole set
of geographic algorithms. Also the last one, it's the nearest case of algorithms. So if you want, for example, you have tracks, GPS tracks that is given by line strings and you
want to compute the similarity, there are some similarity measures like Hausdorff or Frézé distance. Again, you have to compute your black box will be distance computation. So you have to solve the inverse problem. So OK, one more example here.
So this is a building block for distance between geometries. So I have a line string, so this is just a segment. And I have a given point, and I want to compute the distance. So this will solve, at least in both geometry,
how it's implemented will solve several inverse and direct geodesic problems. And yes, bi-spherical have a very simple formula. I'm getting this result. And I can use Andoyer, Thomas, and Vinceti algorithms to get those results.
And then out of curiosity, we can also use a PostGIS, which is the state of the art and also gives some most widely used and also give two versions, like spherical, which is the same as in both geometry. So we are OK here.
But geographic gives a different number. So yes, I will leave it to you to think of how is it possible to check if these results are correct or not, and which result is more accurate. Because it's not visually, from the first sight,
possible to do it. So I'll continue with a benchmark. So that was some illustrative examples. So we use a data set, which is open in Zenodo.
It contains 100,000 geodesics computed by uniform distributed points on the ellipsoid. And it also contains 50,000 short geodesics that are less than 10 kilometers.
And using this data set, I will just run tests with the previous described algorithms, just to see which is faster, which is more accurate. So regarding accuracy, this data set
also provides an accurate solution for the direct and the inverse problem. So this is computed in geographic lib by the author of geographic lib, with some exact arithmetic,
so no floating points, and supposed to be very exact. So we can use it to test the accuracy. And there is also a wiki for more details. So looking at performance for distance, OK, flat.
It's very fast, but as we saw, even for simple examples, it does not give any good results. Spherical, which is the first approximation that you can find, is 10 times faster than Andoyer, which is our first working geographic approach.
And then this is almost 10 times faster than geographically boosted, which is the most accurate. So more or less, we have a hierarchy of performances. So the stars are using the implementations in boost geometry, and the other is geographically.
So then I want to test accuracy. These are some remarks. So for long geodesics, the faster the method, the lower the accuracy. This is something expected, and we wanted to show it also in benchmarks.
So for long geodesics, geodesics can almost cover the globe, but are not covering the whole globe. I mean, you don't have two antipodal points, because then you have issues. These are the occurrences that we get from our algorithm.
So like a spherical, you can have errors in kilometers, and you go up to nanometers for the high series approximation. So Andoyer is the one that in boost geometry we use by default, has a few hundred meters
accuracy in that long geodesics. And flat approximation has extremely low accuracy, but it's only suitable for very, very specific applications when your data sets are only inside one city.
Yes, the only method that actually works for points that are antipodal is the method with high series approximation.
So everything else is broken when the two points are nearly antipodal on the globe. So the result is the formulas are going really, really wrong. So this graph, it's log scale, so those two
are supposed to be very inaccurate. And you can see the scaling of the algorithms while the distance increases. The first is almost one meter, so it's very short. The last cases are the near-adipodal points. So you can see that apart from a geographic leap, which
are those versions here that are stable, all the other algorithms at some point, they explode and produce very wrong results. We use several versions of geographic leap. You can compile it with a smaller order series.
And yes, it's interesting that even with four order series, we get very accurate results. OK, but even three is better than Vincente, so OK. So then we run some benchmarks with Azimuth and ARIA.
So these are a bit connected, because ARIA is using Azimuth. But yes, and here, the difference is that with very short geodesics, we have very large errors. And also here, we can test some equal area projections.
OK, let's see the equal area projections. OK, this is accuracy. This is accuracy of Azimuth. Then we can see that in short geodesics, the computed Azimuth is really off. You have to go to around 100 meters to maybe 10 meters
to get something which is accurate. Geographically, of course, it's performing, and Vincente, relatively good. OK, but still, geographically, it has large errors in small geodesics.
And then ARIA, it's a bit more interesting. So here, we also test those guys here that are projections, equal area projections, for small distances. So actually, we compute the area of the geodesic and the shadow on the equatorial.
So we have something like a trapezoid. This is the areas we compute. And yes, you can see that in small distances, projection makes sense. But then here, there is an explosion in the area. So it's really nonsense, the results that you get.
Again, we have this hierarchy of geographically, which is the most accurate. Then Vincente, and again, this time is over. Yes, and then Vincente, and then Thomas, and Andoja.
OK, and that's all. Thank you.
Question on the area calculation, what was the reference point for calculating the error there for the area calculations? What do you mean, the reference point? So you were measuring in accuracy on the y-axis, no? Yes, it's square meters.
The errors are in square meters. Yeah, compared to what? What's the basis for that? Again, you have an exact computation of the area with the geographic lib, and this exact arithmetic operations.
So what was the performance of the high series compared to Vincente? Sorry? Performance of the high series method compared to Vincente method? What's the difference? Yes, could you go back to the slide? In performance, OK.
Yes, it's a bit more than two times, so it's not that. And this is in distance. In azimuth, it's the same. So actually, what you do in Vincente,
intuitively, is that somehow you kill the process early. But even if you leave it iterate if the points are on the portal, then there is a strong issue. So geographically, by taking care of this,
probably introduce some performance. Any other last questions before we thank him? No? All right, thank you. One last round of applause. Unfortunately, the third speaker is not here today.
So if anyone was here for that presentation, our sincere apologies. But other than that, I guess the session is closed. So thank you, everyone, for attending. And enjoy the rest of your time here. See you at the AGM. Thank you.