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

Spatial Reference Systems Transformations with Boost.Geometry

00:00

Formal Metadata

Title
Spatial Reference Systems Transformations with Boost.Geometry
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
Production PlaceBucharest

Content Metadata

Subject Area
Genre
Abstract
What are spatial reference systems and how to convert between them? What are various ways of creating transformation representation in Boost.Geometry and how to use them to convert between polygons on the surface of a globe and flat surface of a map? We discuss solutions to those questions highlighting some of the latest developments in Boost Geometry, the library that is currently being used to provide GIS support to MySQL. The implemented solutions allows to define transformations both in compile-time and run-time with known tradeoffs: execution time vs compilation time, run-time flexibility vs compile-time error reporting, etc. Last but not least we discuss similarities and differences between Boost.Geometry and Proj4 libraries. The presentation is example driven thus emphasizing on the user perspective.
Keywords
129
131
137
139
Thumbnail
28:17
Wave packetLibrary (computing)Computational geometryGeometryLecture/Conference
SoftwareGeometrySystem programmingTransformation (genetics)OracleAlgorithmPrice indexMereologyConditional probabilityMeta elementComputer programmingElectronic mailing listWebsiteRepository (publishing)Source codeLibrary (computing)Core dumpSoftware developerPredicate (grammar)Relational databaseOperations researchUniqueness quantificationAreaData bufferModel theorySpacetimeState diagramRevision controlState of matterEmailVertical directionOperator (mathematics)Parameter (computer programming)Exception handlingError messageThread (computing)Vector spaceError correction modelDefault (computer science)Modal logicMultiplicationLine (geometry)Point (geometry)Addressing modeMaß <Mathematik>NeuroinformatikLibrary (computing)Auditory maskingMereologyAlgorithmPairwise comparisonPoint (geometry)BenchmarkData conversionNetwork topologyState of matterRing (mathematics)Form (programming)Object (grammar)Different (Kate Ryan album)Projective planeIntegrated development environmentDefault (computer science)Coordinate systemString (computer science)CodeFile formatArmSource codeOrder (biology)Parameter (computer programming)Product (business)Arithmetic meanEqualiser (mathematics)Multiplication signRight angleAreaMessage passingSubject indexingInterface (computing)Sound effectSelf-organizationLetterpress printingTransformation (genetics)Computer programmingComputer configurationPhysical systemUltraviolet photoelectron spectroscopyParsingRevision controlAdditionEmailElectronic mailing listSoftware developerException handlingData storage deviceWordCodeDistanceMathematicsPrimitive (album)Computer fileINTEGRALInterior (topology)Degree (graph theory)Cartesian productType theoryFunctional (mathematics)Shared memoryConformal mapExpressionGeometryFlow separationLine (geometry)Authorization1 (number)Thread (computing)Variable (mathematics)Electronic visual displayVector spaceRun time (program lifecycle phase)NumberData typeFehlererkennungComputer animation
SpacetimeMaß <Mathematik>Fluid staticsGeometryData storage deviceLattice (order)State diagramBenchmarkThread (computing)Extension (kinesiology)Visual systemOracleThread (computing)Different (Kate Ryan album)Product (business)Transformation (genetics)Run time (program lifecycle phase)Virtual machineMultiplication signLibrary (computing)SynchronizationExtension (kinesiology)Structural loadDirectory serviceParameter (computer programming)CompilerVisualization (computer graphics)Variable (mathematics)System callData storage deviceHeat transferMessage passingCodeProgrammer (hardware)Social classConstructor (object-oriented programming)Projective planeString (computer science)Streaming mediaCASE <Informatik>Instance (computer science)Cartesian coordinate systemObject (grammar)Pairwise comparisonMultiplicationCodeGame controllerSemiconductor memoryBenchmarkOrder (biology)Degree (graph theory)BuildingTwitterParsingObservational studyOnline helpArithmetic meanFigurate numberDatabaseInsertion lossDemosceneMiniDiscWebsiteNumberRight angleFile formatNetwork topologyType theoryComputer animation
WebsiteTwitterOnline helpLine (geometry)1 (number)CodeGreatest elementState diagramThread (computing)Lecture/Conference
GeometryRevision controlElectronic mailing listEquations of motionProjective planeComputer programmingServer (computing)Point (geometry)Software developerLevel (video gaming)Series (mathematics)State observerRight angleLatent heatView (database)Element (mathematics)ECosInstance (computer science)Physical systemFocus (optics)Fitness functionFunctional (mathematics)Event horizonComputer animationLecture/Conference
Transcript: English(auto-generated)
Ok, so let's start another talk. I'm Adam and I work at MySQL and together we are
developing Boost's geometry, a library for geometrical computing used by MySQL to do GIS stuff. So we are part of Boost's ecosystem, so we adapt their principles
like header only, we're a header only library, we tend to focus on performance, we use modern C++, we tend to do things in compile time, instant of run time and so on. And Boost's
geometry allows us to vector data and perform algorithms on this vector data. It also contains
spatial index to speed things up and now projections. Yeah, I started. It was a public demand. So the current version is 1.71, documentation mailing list and GitHub displayed. We have
a vibrant development team, any contributions are welcome. We are participating in Google's number of codes, so if you want to contribute, please. Here are some algorithms, examples
of algorithms implemented in Boost geometry. If you know OGC standard, then you know the algorithms. And here is Hello World, calculating the distance between my home
city and Bucharest. And this distance is calculated in geographic coordinate system in WGS84 by default. So we like to be as expressive as possible. So first here, or
maybe I'll use the cursor. So here we are creating a point which is 2D in geographic
coordinate system and coordinates are in degrees. And the data type is double because you can, in Boost geometry you can use whatever coordinate type you like. And then
two points are created and function is called. And I'll be comparing with Proj4 which is state of the art. I used 5.2 for the comparison and benchmarks and the current version is
6.1.1 which changes things severely. So what are the differences? Work on projections in both geometry was started by Barand Girls which is the original author. They call this
based on Proj4. So it basically works more or less like Proj4 but it was severely redesigned in order to make it more, let's say C++ friendly. And I'm not talking about the
interfaces but the internals. So cons are that there are less transformation than in the more recent Proj. It's 2D only, there is no pipelines. There are of course no
Proj 6 features. On the other hand, it's more, let's say C++ friendly or Boost friendly that it's header only. There are no additional requirements. There are no environments, variables used under the hood. It's faster. I'll show it later. And our handling
is done differently. It's based on exceptions. So we don't store this global error codes
which makes the library thread safe, let's say. During the talk I'll be using this data. So here are the vectors I'm using. There will be three examples. One with Poland
and Romania and one with New Jersey. New Jersey I'm using because it's one of the last non-depurgated EPSG codes using NAD grids. So here is Poland and Romania in EPSG 4326 which is the native
data of this file I've shown. And I'll be transforming into conformant project using
conformant production to EPSG 3034. So first this is how you do it in Proj 4. This
of coordinates. And the coordinates are interleaved XY in the vector. This is as far as I understand you do it in Proj 5 where you'd pass PJ coordinates which are up to two to four dimensional
coordinates. And Boost geometry, the most basic interface in Boost geometry is not
very different. Oh, first note about the expressiveness. In Boost geometry it's possible to express various ODC primitives in the code like points, line string and multi-line strings. So here we have geographic ones and Cartesian ones. So the point type defines the coordinate
systems at compile time. So here is the difference. Right? Geographic in degrees and Cartesian. And all of the derived types share this coordinate system. So here is how you perform
the transformation in Boost geometry which is more or less like Proj 4. First you have you define your geographic multi-line string, create transformation object, passing source
and destination transformation parameters and you're performing forward transformation. And that's it. But since we're in C++ environment maybe you don't want to create strings because
you probably have parameters already in your code. But this will be another example. So in this example I'm using different projection. That one was conformant. This
will be equal area. So here it looks similar, right? Two Proj 4 strings. And another possibility is to pass parameters directly from C++. Which is similar. And the interface was based
on both program options. Names of parameters are the same. So it's similar to Proj 4. But it allows you to omit string parsing and string formation and string parsing on
the side of library which is faster. And if you know what transformation we'll be using at compile time. So for instance you're writing a very specific application doing
very specific thing and only that and you want to be as fast as possible then you'll probably want to do it at compile time. And it's also possible. Also with transformation object. So basically here you're creating two types. And only filling the runtime values
that are needed. But if you don't care about that you can simply pass APS-G codes.
And that will create transformation for you. The upper one is that the APS-G code is passed in the runtime and the below one is passed at compile time. Now the third
example. As I said here, I wanted to show you how to use NAD grids. It's different than in Proj which loads grids automatically under the hood from directories
specified in variable. In both geometry, if you do something like this, the grids won't be used at all. Even if they're defined in the parameters. So this will, this
call will be the fastest. The transfer should be the fastest. The grids won't be, they won't pass. If you want to pass grids you have to do it by yourself. And we want
to be, want to give the programmer the flexibility to store the grids whatever he likes, whenever he likes. Load them however he likes. So we provide this additional class which is grid storage which takes stream policy and grids
definition. So if stream policy defines how to load the grids because maybe you don't want to load them from disk. Maybe you want to load them from somewhere else. Maybe you want to define the path somehow. So this allows
you to do it. And the second parameter tells the library how to synchronize the grids in case you wanted to do transformation in multiple threads. So
there is the same. And with this object you also have the control where the grids are actually stored, how they are stored in memory and where they are removed from memory. So where they are destroyed. So in order to
use grids you have to put this grid storage somewhere and then initialize grids for your specific production and pass the grids manually. So this
example shows how to perform production in one thread. If you want to use several threads, the only difference is that you're passing shared grids. And shared grids are using boost threads for synchronization. So here is
an example how to perform the transformation in two threads and wait for both threads to end. But if you don't want to rely on boost threads, you
don't want to have this dependency and have a compiler supporting C++ 14, then you can use standard threads and standard synchronization. So you
have to include a different header, pass a different type and you're free to go. The code looks exactly the same. And here are some benchmarks.
I'm showing the time of construction of projection and below is the transformation itself. So this benchmark is for the first example. As you can see, the construction is a lot faster with when you don't have to
parse strings. And because it's possible to, because it's a library and because it was severely redesigned, it allows the compiler to perform
transformation faster. Because the compiler is able to optimize and this makes things a lot faster. It's the same story with another projection.
As I'm not entirely sure what happens here, I also tried approach six, but the comparison would be unreliable because it does things entirely differently, searches the definition in the database, so it takes a lot,
a lot longer to create. And the time of execution is still slightly slower than approach four. So I just omitted approach six here. Yes, and it's
basically the same for all cases. With NAD grids, I think the difference is
even more, it's more or less two times faster. And how it behaves in multiple threads, so some charts, these are times of the same work
divided into multiple threads, how they are scaling with threads, with boost synchronization or STD, standard synchronization is red. So there's no difference actually between boost thread and STD. And different
machine and different compiler. Now with approach five, also clang. So
yes, that will be it. And we also have this extension which you can use with Visual Studio to visualize your variables at debug time when you're debugging in Visual Studio. Okay, thank you. Yes, if there are any
questions. What kind of threads are you using for approach four and
approach five benchmarks? Standard ones. So it's C++ 11 STD thread.
Sorry, is the code available on GitHub? Yes, of course. Bottom line. So yeah, you can test it. Do you have any interest from any of the C
projects to use this library? Or have you tried to get other people using it? Let's say, especially map server, but the other programs
relying on C and C++? No, we didn't try to reach anyone. I don't know well enough about map server to suggest if it would be a good fit or
not. My understanding is that map server lives in a specific ecosystem which already have everything it needs. Maybe because from other
libraries point of view, like approach four for instance, the I guess it depends on what aspects of development you would like to
put focus on. If you tend to perform, if you tend to care about performance more or maybe about modern C++ or about features or accuracy, then you would pick one or the other.
I'd just like to thank Adam and wish you a pleasant lunchtime. So see you in the afternoon. Thank you all for coming.