Site Calibration with PROJ and WKT2
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 266 | |
| Autor | ||
| Lizenz | CC-Namensnennung 3.0 Deutschland: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/66542 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
00:00
Grothendieck-TopologieSoftwareSoftwareentwicklerBaumechanikInformationVolumenOpen SourceWeg <Topologie>DateiformatQuellcodePauli-PrinzipInternationalisierung <Programmierung>Funktion <Mathematik>TermClientWorkstation <Musikinstrument>Inhalt <Mathematik>PunktStellenringSystemprogrammierungKoordinatenOrientierung <Mathematik>Maß <Mathematik>Kartesische KoordinatenReservierungssystem <Warteschlangentheorie>Grothendieck-TopologiePunktKartesische KoordinatenProgrammbibliothekStellenringWorkstation <Musikinstrument>Produkt <Mathematik>RechenwerkDienst <Informatik>KoordinatenProfil <Aerodynamik>InformationHardwareVerschlingungKollaboration <Informatik>Coxeter-GruppePhysikalisches SystemOpen SourceQR-CodeRichtungAliasingCASE <Informatik>Total <Mathematik>Design by ContractComputeranimation
02:27
DreieckRechnernetzAbstandGewicht <Ausgleichsrechnung>Web-SeiteWorkstation <Musikinstrument>AbstandDirekte numerische SimulationNeuroinformatikWinkelCoxeter-GruppeTouchscreenTriangulierungPunktDigitale PhotographieDatenfeldSondierungComputeranimation
03:20
Grothendieck-TopologieReservierungssystem <Warteschlangentheorie>Physikalisches SystemEinflussgrößePunktTranslation <Mathematik>KreisbewegungMaßstabVerzerrungstensorUnified Threat ManagementFlächeninhaltAuflösung <Mathematik>RechenbuchResiduumKoordinatenProgrammbibliothekEigenwertproblemAlgorithmusMatrizenrechnungNegative ZahlFunktionalVerzerrungstensorURLFlächeninhaltEinfach zusammenhängender RaumZahlenbereichRandomisierungOpen SourcePunktTransformation <Mathematik>GeheimnisprinzipWorkstation <Musikinstrument>Ausdruck <Logik>Funktion <Mathematik>DimensionsanalyseFlächentheorieParametersystemPhysikalisches SystemReservierungssystem <Warteschlangentheorie>Zentrische StreckungDienst <Informatik>BeamerStellenringTranslation <Mathematik>TabelleKreisbewegungProjektive EbeneMathematikUnified Threat ManagementGrothendieck-TopologieEinflussgrößeDifferenteAbstandFitnessfunktionPunktwolkeMeterQuadratzahlAlgorithmusSummierbarkeitVektorraumResiduumNichtlineares GleichungssystemInformationsspeicherungStandardabweichungCASE <Informatik>MultiplikationsoperatorBitEigenwertproblemWinkelOrtsoperatorDatenfeldKollaboration <Informatik>KoordinatenKonstruktor <Informatik>RechenschieberLokales MinimumComputeranimation
11:20
VertikaleEinflussgrößeDatenmodellKrümmungsmaßPunktAuflösung <Mathematik>MaßstabKreisbewegungTranslation <Mathematik>ResiduumRechenbuchKoordinatenEigenwertproblemProgrammbibliothekAlgorithmusMethode der kleinsten QuadrateUmsetzung <Informatik>Reservierungssystem <Warteschlangentheorie>StellenringSelbstrepräsentationSystemprogrammierungFlächeninhaltParametersystemTeilbarkeitTransversalschwingungTransformation <Mathematik>Affiner RaumKartesische KoordinatenGruppoidOrdnung <Mathematik>MeterCodeLeistungsbewertungFunktion <Mathematik>Grothendieck-TopologieOpen SourceVerzerrungstensorParametrische ErregungKreisbewegungE-MailUmsetzung <Informatik>PunktBitFunktionalParametersystemEinflussgrößeKoordinatenMatrizenrechnungHeegaard-ZerlegungGeneigte EbeneAusdruck <Logik>RauschenRichtungKegelschnittRechenwerkProgrammfehlerOrdnung <Mathematik>HackerEin-AusgabeReservierungssystem <Warteschlangentheorie>CASE <Informatik>Kartesische KoordinatenNichtlinearer OperatorZentrische StreckungTransformation <Mathematik>KnotenmengeZahlenbereichPhysikalisches SystemMereologieKonstruktor <Informatik>Projektive EbeneWort <Informatik>GamecontrollerDifferenteOpen SourceSelbstrepräsentationZusammenhängender GraphGraphfärbungDatenstrukturFunktion <Mathematik>Mapping <Computergraphik>ResiduumKonfiguration <Informatik>FehlermeldungMultigraphEinsLambda-KalkülFlächeninhaltDienst <Informatik>p-BlockGrothendieck-TopologieBeamerZeichenketteElektronische PublikationSchnittmengeInformationsverarbeitungCoxeter-GruppeQuadratzahlWikiCodeMailing-ListeProdukt <Mathematik>Deklarative ProgrammierspracheGefangenendilemmaEreignishorizontSoftwareentwicklerBenutzerschnittstellenverwaltungssystemEllipsoidStellenringDivergente ReiheComputeranimation
19:21
Computeranimation
Transkript: Englisch(automatisch erzeugt)
00:08
Hello everybody and welcome to this presentation, this talk about site calibration with Proj and WKT2. I'm Javier Jimenez-Jau. You already presented me, thank you.
00:22
You can find more information about myself on my GitHub profile. I'm currently the technical coordinator of P4SRS team at Pix4D, a photogrammetry company. I want to thank before starting Juan Fernando, we made this paper together. And Alexander Nervas, he should be here helping me, but unfortunately it was not possible.
00:44
This paper, you have the link there, this QR code. The purpose of the paper was to offer an open source solution for something that's already out there, but done by private companies with proprietary solutions.
01:00
Blackbox, they are not well documented what's going on. They just work, those manufacturers are mainly hardware manufacturers, total stations. We are developing this solution in our products, mainly so far in Pix4D catch, and we want to make it an open solution that fits perfectly with Proj, that's the library that we are using.
01:24
By the way, no AI was harmed during the making of this paper. What we are going to see here, first was a site calibration. By the way, anybody knows here what's a site calibration or site localization?
01:41
Okay, so I want to explain why that's interesting, why we need it. Some use cases, the mathematical things are going underground. Then what's WKT2 and why it's an interesting solution for that problem, and Proj, that's an open source library, how it's helping us.
02:04
So first, what is a local coordinated reference system? Those are some aliases of the same concept. It's a Cartesian non-georeference coordinated reference system with an arbitrary origin. So you have your origin at some point, probably your contraction site,
02:21
and you have Cartesian x, y, n, n direction, any units, and no reference to the Earth. Okay, surveying. How was done surveying before GNSS era? It was done using mainly further lights, that's this device on the black and white screen.
02:42
There are bigger pictures later in the presentation. That's measuring mainly angles, high accurate way to measure angles on the field, also distances but mainly angles. Nowadays, what's used is this device, the same idea but with a computer and a laser beam, that makes things easier.
03:00
That's a total station, I don't know why the name. That lets the surveyors and topographers to make triangulations on the terrain. And with this triangulation, you can deduce later the coordinate of any point in the field or in the country. But nowadays, with these GNSS constellations, what we use is a GNSS receiver
03:28
and making some maths to get an absolute coordinate with respect to a geo-reference coordinate. So why do we need site calibration? So, as I said before, local CRAs are not geo-referenced to any global system.
03:46
They're absolutely floating and GNSS measurements are in global coordinates. So they are geo-referenced. And if I want to use my GNSS device on my construction site, that's a typical example of a local coordinate reference system, how to use it.
04:04
So I have my local system and I have my GPS and I want to use there. So site calibration is going to be how to convert my coordinates from my local CRAs to a well-known CRAs and vice versa.
04:20
And here are two use cases, I'm sure there are more. One is that now with this site calibration, I can quickly measure with my GPS, with or without RTK, depends on how much accuracy I want, I can quickly measure and transform them to my local coordinate system.
04:42
Using a total station is something much slower, you need usually a professional to do that. Or I can fly my drone, but nowadays every drone has an embedded GPS, and produce the output of that, can be a point cloud, can be an orthosych, already in your local coordinates. And you can directly include that point cloud, that orthosych into your project
05:06
that's already in your local coordinates. Okay, so here we are going to see an example of how things don't and how we match points. So in a local coordinate reference system, you need some reference points in your field,
05:23
so probably a surveyor went there and marked some points, in the example there are four, S1, S2, S3, S4, and with known coordinates. As you see, S1 has 500, 500, usually they don't start with zero to avoid negative numbers, so the reference, the zero here is a bit far away.
05:43
And with a total station, if you want to find out the position of the fifth point, there in the center, you measure the angles, and you can deduce the location of this point. We know the coordinates of these four points in this local reference system.
06:05
What we are going to do is to measure the location of those points with a GNSS receiver. In the example here, I just select one random geographic coordinate reference system, ETS 89, and we measure the points in latitude, longitude in the example.
06:25
By the way, all those numbers are fictional, don't try to find any actual connection between them. So, we have side points in measuring meters or in feet, any linear distance,
06:46
remember that the local CRS is a Cartesian coordinate system, we have the global points that we did measure in a latitude, longitude in a geographic system, we have the definition of this global CRS,
07:00
and what's missing is the definition of our site CRS, that's what we want to find. When we have it, we can do transformations between these two, actually to any other CRS. And we want to find this CRS in a way that we can do that transformation. So, how are we going to define the site calibrated CRS?
07:26
First, we'll need base projected CRS centered in the area of interest, because we want to minimize local distortion, lean distortion, the projection distortion, and also the height distortion.
07:42
In top of that, we are going to apply a translation, a rotation, and a scale, that sounds a fine transformation, we'll see later, that can be expressed with certain parameters. These certain parameters are not the same as in a Helmert transformation, remember that Helmert transformation is applied at the center of the Earth,
08:02
you go to Cartesian but at the center of the Earth, and then you apply that there. This is happening in the projected CRS, so this transformation is happening at the surface of the Earth, not at the center. And we need a projected CRS,
08:20
so we will choose a CRS centered in the area of interest, UTM is not centered in the area of interest, so it has distortion that can be significant in some cases, and it's a good idea to use a conformal CRS, so that keeps angles, because probably we're using that for surveying, and we want to minimize distortion that way,
08:43
but it's not mandatory. So I've seen private realizations that looking at the documentation, you find out it was using another one, I think it was orthographic, I'm not sure, but it was not conformal. Okay, so on top of that projected CRS,
09:03
we're going to apply a rotation, scale, and translation. This formula there is, I try to use the same letters as in the paper, the rotation, it's a matrix, can be a 2D or 3D rotation, T is a translation, a vector, and C is scale,
09:23
and that transformation fits very well with what Proj has as a fine transformation. This is the formula in the Proj documentation, actually Proj has the fourth dimension, that's the time, but we don't care here about time, so we can encapsulate scale and rotation in this matrix,
09:44
S1 and so on, the translation is X of, Y of, Z of, and that's all. But we have to compute these three parameters, the scale, the rotation, and the translation.
10:01
For that, what we are going to do, is to compute the residuals and try to minimize them. The residuals is the difference between the local coordinate that we measure, the green values on the table a few slides before, and the transformation with these parameters from a well-known coordinate,
10:22
or from what you measure from your GNSF receiver. So, these two things are linear, in meters, or feet, and the difference is how much is your deviation from your point. We want to make it minimal,
10:41
and that's the question we want to solve. Minimize the residual sum of all them squared. There's a well-known algorithm published last century, there's Umeyama, that minimize that. It's demonstrated that this solution is the minimal,
11:01
it works on any dimension, we are going to use two or three, but if you're interested, this works on any dimension. And we are using C++ Eigen library, that's open source as well, to solve this with this function, eigen, colon, colon, Umeyama.
11:22
But we realized that we started solving that on 3D, and you can see here that the rotation matrix, actually here, is a 3D rotation matrix, but we realized that the noise on the vertical component,
11:43
because GNSF receivers has a worse accuracy on C direction, can introduce some noise on the horizontal measurements, because we are making a 3D rotation. So we try, and it works very well,
12:00
splitting in horizontal and vertical calibration. And in these graphs here, on the left-hand side, you can see that's a 3D calibration, so the rotation is 3D, so any noise on the vertical component, that's the X axis, introduces some noise on the X, Y, and horizontal error maps.
12:25
As you can see there. But when we split in two, because there are two different calibrations, it's not affecting it. And that also helps the user to select different points to calibrate the horizontal part and the vertical part.
12:42
Sometimes they have much more points than measured in 2D, X, Y, and they have just one or a few points with a C value that's really reliable. With that, you can use more points on the horizontal block, different number of points.
13:03
So for the vertical calibration, what we are using is this function in EPSG that was implemented now in Proj, vertical offset and the slope. That's the formula there. It sounds a bit complicated, but it's much simpler.
13:22
The only unknowns we have are the letters in capitals. Instead of the I phi and I lambda that are the offset of a point and the slopes on the latitude and longitude direction. So it's a linear system. We can solve it with a least squares method.
13:44
We need for that at least three points with a vertical coordinate. Okay, so what is WKT2? Because that was in the title of the presentation. It is a well-known representation
14:01
of a coordinate reference system. There was a present one, but it was not fitting the needs we have here. So to add this a fine transformation and the vertical offset and slope, I was telling before, was not doable. I didn't find at least a way to do it with WKT1.
14:22
But with WKT2 is a way to do that. That helps a lot. And will allow us to define the local coordinate reference system already calibrated, self-contained. So it will be just one file, one string, that defines completely the CRS. So we can use it to define it
14:41
and to transform just to any other system in just one thing. We don't have to split. Here is the project. Here is the parameters. No, it's all together. Let me show you here an example of a WKT2. Can be better both.
15:01
So please don't pay so much attention to the gray text. Just look only at the color words there. So first thing we have is a compound CRS. This example is splitting horizontal and vertical and for that we need a compound CRS to define first the horizontal part
15:22
and then the vertical. And the first entry is this derived projected CRS. That's the horizontal part. That has first base projected CRS. That's the projected first coordinate system
15:41
I was talking about before. In this case it's a transformer cutter. You can use any other laminar conic or any other projection you like that is centered on the area of interest. So it's really interesting that the origin of this projection is where we want to work. On the construction side, on your backyard
16:01
or wherever you are going to define those points. And on top of that, because it's a derived projected, we have a derived conversion. And this is the parameters I saw you before about this offset and rotation and scale embedded in this matrix.
16:20
In this case with this approach based operation method. There are other options in WKT2 that I included now in EPSC, but you have less control over the axis order and units.
16:41
So me personally, now I'm more comfortable with this because everything is under control. And the second component of this compound CRS is a vertical CRS. This is the definition of a derived vertical CRS with a base one. In this case I was using
17:01
ellipsoid. That's a bit of a hack. It should be a proper vertical system, but the measurements were not done on that vertical system, so I was using that. And a deriving conversion. This deriving conversion is this vertical offset and slope I mentioned before. It should be centered somewhere. Can be the same point as before. Doesn't have to.
17:20
And has a vertical offset and these two inclinations or slopes in the latitude and longitude direction. And that's all. We have the CRS defined. And let me talk a bit about Proj. Well, it's a C++ API we use
17:41
directly on C++, not in the Python. And we use that to create the CODIA reference system, the initial ones. Obviously, this projected truss from a cutter, that's the projection we were using to create all the deriving conversion and so on. And obviously to create the WKT2.
18:01
So the output of our function input was the input points, the side points, and the points measured with the DNS-S receiver. And the output was the definition of, oh, the input was also the CODIA reference system of the DNS-S receiver.
18:21
And the output was the definition of the CRS. And of course, we were using Proj to do any transformation, to check the residuals and so on. And I would like to thank Ivan Ruhl, that's here, Ivan Ruhl. He helped us a lot during the
18:40
development. We found some bugs or missing functionalities that he answered pretty quickly of PRs and mails. And just as a summary, the main idea is that we are using WKT2
19:00
to define a CRS that encapsulates the side calibration, self-contained, it's plain text. You can read it, you can understand it. It's open source. And this compounds CRS, the structure of this WKT2. That's all. Thank you.