WEBVTT 00:00.000 --> 00:06.000 So they start? 00:06.000 --> 00:07.000 Yeah. 00:07.000 --> 00:08.000 Yeah. 00:08.000 --> 00:09.000 Good. 00:09.000 --> 00:10.000 Great. 00:10.000 --> 00:11.000 Thanks a lot. 00:11.000 --> 00:13.000 I'm a Syrian. 00:13.000 --> 00:17.000 I've got a computer and a container of boost geometry. 00:17.000 --> 00:21.000 And today I will present the library. 00:21.000 --> 00:24.000 So the talk goes roughly this way. 00:24.000 --> 00:28.000 I will give a brief introduction of what is boost geometry. 00:28.000 --> 00:31.000 Then quickly go through the design. 00:31.000 --> 00:38.280 Then I'll give some examples of how to use this library and end up with some spatial 00:38.280 --> 00:39.280 computations. 00:39.280 --> 00:40.280 Okay. 00:40.280 --> 00:44.280 First of all, the boost geometry is an open source. 00:44.280 --> 00:46.640 Library is part of boost plus plus libraries. 00:46.640 --> 00:48.640 It's here there only. 00:48.640 --> 00:51.280 It has a stable interface. 00:51.280 --> 00:59.560 It supports a simpler plus 14 conditionally supports also newer standards. 00:59.560 --> 01:02.560 But this is the main support. 01:02.560 --> 01:08.400 The main simplest plus version that we support. 01:08.400 --> 01:15.440 It builds on static ball morphism, metaprogramic and touch disposing to give some generosity 01:15.440 --> 01:16.440 of the types. 01:16.440 --> 01:20.200 I will explain this in the design of the library. 01:20.200 --> 01:25.360 And basically has three parts, like primitives, geometries, algorithms that are spatial 01:25.360 --> 01:27.360 index. 01:27.360 --> 01:28.360 Okay. 01:28.360 --> 01:29.760 And also it's standard conformant. 01:29.760 --> 01:43.080 It follows the OTC, a simple fixture, a simple feature standard by OTC. 01:43.080 --> 01:50.640 There is some documentation on the boost website. 01:50.640 --> 01:51.640 We have a mailing list. 01:51.640 --> 01:57.680 There's also the mailing list of the boost libraries that you can discuss topics of the 01:57.680 --> 02:02.040 library and general topics of boost libraries. 02:02.040 --> 02:07.400 It hosts it on a GitHub and there is a list of main code debutors. 02:07.400 --> 02:12.800 Let's say the code debutors, but there are several others who also participated in some 02:12.800 --> 02:18.400 GitHub of code some years ago. 02:18.400 --> 02:23.600 So this is the basic shell award example of boost geometry. 02:23.600 --> 02:32.600 So you can include the headers, it's yet around these Justin Biles. 02:32.600 --> 02:35.760 And then there's a model of the points. 02:35.760 --> 02:39.800 This is a two-dimensional point and there are three parts. 02:39.800 --> 02:43.600 So this is a number type that you can use. 02:43.600 --> 02:44.600 This is a dimension. 02:44.600 --> 02:46.040 It's two-dimensional points. 02:46.040 --> 02:50.120 And then the third part is the coordinate system. 02:50.120 --> 02:55.360 So it can be Cartesian if you are using a projection or it can be a spherical or a geographical. 02:55.360 --> 02:59.480 We combine this a bit later. 02:59.480 --> 03:03.360 And then if let's say that you want to compute this, this is one of the most simplest 03:03.360 --> 03:06.480 examples that you can do. 03:06.560 --> 03:11.760 You create a point that it's longitude, latitude, let's say Athens. 03:11.760 --> 03:19.720 And then you compute the distance from another point which is the coordinates of brassons. 03:19.720 --> 03:30.480 And this gives you this number, you can compare it with what Google Maps gives you. 03:30.480 --> 03:32.360 It's a bit different. 03:32.400 --> 03:38.080 This has to do with the internal computations that they will show up in the presentation. 03:38.080 --> 03:42.440 Why this is different? 03:42.440 --> 03:47.560 OK, so what primitive boost geometry supports? 03:47.560 --> 03:49.560 It supports the basic primitive stuff. 03:49.560 --> 03:57.080 The standard is like we have points, multipoints, line strings, polygons, and they're 03:57.080 --> 04:02.040 multivergons, so multipologons and you can have also a geometry collection. 04:02.720 --> 04:05.360 So these are pretty basic. 04:05.360 --> 04:11.360 And there is a list of algorithms that are implemented. 04:11.360 --> 04:23.160 That ranges from area and lengths of geometries to separations. 04:23.160 --> 04:29.520 And also some functions that help navigation like length, double lathe, 04:29.600 --> 04:34.000 and these are some lardy. 04:34.000 --> 04:42.280 This is part of the limitation, so you can browse it and see all the available algorithms. 04:42.280 --> 04:49.760 And there's a number of applications, so it mainly designed for GIS, 04:49.760 --> 04:55.280 but it's more general, so it can be used in robotics and CAD. 04:55.280 --> 05:03.120 And also my skill is using it as a geometry engine. 05:03.120 --> 05:08.640 OK, let me discuss a bit about the design of the library. 05:08.640 --> 05:12.240 So there are three layers in the design. 05:12.240 --> 05:16.560 There is an algorithms layer where there is the API. 05:16.560 --> 05:19.560 This under this namespace. 05:19.560 --> 05:24.880 There is also the spout layer where all the tagged spouting is done. 05:24.880 --> 05:28.640 This is to, let's say, for the user perspective, 05:28.640 --> 05:32.960 this is to, this is a way to provide the general listing. 05:32.960 --> 05:35.680 And there's also the implementation layer. 05:35.680 --> 05:44.320 Where are all the, in this namespace, where are all the implementation details are hidden. 05:44.320 --> 05:48.920 OK, so mainly they are going to sing a boost geometry. 05:48.920 --> 05:53.680 They are pretty functions, like the distance that showed you in the first slide. 05:53.680 --> 06:01.520 So there is area buffer and all these algorithms takes one input with this or two inputs, 06:01.520 --> 06:03.600 which are geometries. 06:03.600 --> 06:09.400 And there is also an optional parameter with this strategy. 06:09.400 --> 06:12.800 So this strategy tells you how to treat the geometries. 06:12.800 --> 06:17.320 For example, if you have a distance of two geometries, 06:17.320 --> 06:22.040 then the library will see what is the coordinate system of the geometries. 06:22.040 --> 06:27.880 And they will, it will implement the right algorithm for them. 06:27.880 --> 06:36.400 If the geometries are on the plane, the distance algorithms will just implement the Pythagorean theorem. 06:36.400 --> 06:41.720 If the points have a coordinate system that is, let's say, on the ellipsoid, 06:41.720 --> 06:45.120 there are more advanced algorithms will be, will run. 06:45.120 --> 06:49.120 And this, the, the, the algorithms understand it. 06:49.120 --> 06:52.760 So the user can just pass the geometries. 06:52.760 --> 06:57.400 But if, if you want the user optionally can pass a different strategy, 06:57.400 --> 07:02.560 if, if you want to choose a different algorithm, for example, for the ellipsoid. 07:02.560 --> 07:07.520 Because of ellipsoid, there are many algorithms that you can use. 07:07.520 --> 07:12.560 I will, I think it will become clear in the next slide. 07:12.560 --> 07:15.240 So this is the input of the of our algorithms. 07:15.680 --> 07:19.840 And the algorithms are independent of the geometry representation. 07:19.840 --> 07:25.120 So you don't have different distance algorithms for different points on the, on the, 07:25.120 --> 07:27.880 on the sphere or points on the, on the plane. 07:27.880 --> 07:33.160 You have one distance algorithm for, for all the geometry types. 07:33.160 --> 07:38.520 So it works across Cartesian spherical and geographic coordinate systems. 07:38.520 --> 07:44.440 And okay, this is the internal implementation detail that this is implemented 07:44.520 --> 07:49.080 or resolved by this part in the simplest lesson. 07:50.280 --> 07:54.080 Okay, so strategies as I explained a bit before, 07:54.080 --> 07:57.120 they encapsulate the mathematical models and the formulas. 07:57.120 --> 08:01.560 So let's say that the algorithm is a group in a tutorial part. 08:01.560 --> 08:05.320 And the strategy is the, let's say mathematical part. 08:05.320 --> 08:10.560 Like you can, you can compute a convex file on the plane. 08:10.560 --> 08:14.200 But then if you want to decide if a point is on one side of the other side 08:14.200 --> 08:16.960 of a line, then this is the strategy. 08:16.960 --> 08:22.040 This is the mathematical part that it's treated by, by the strategy. 08:22.040 --> 08:27.080 For example, we have implemented a Vincendi and Doyer Thomas. 08:27.080 --> 08:31.000 These are different formulas for geographic descent. 08:31.000 --> 08:33.840 So this, this, and so on the ellipsis. 08:33.840 --> 08:42.320 So the strategies as I explain can be explicitly used by the user, 08:42.360 --> 08:46.560 like calling it together with the algorithm or they can be defaulted. 08:46.560 --> 08:52.080 So the user can, if, if they won't, they cannot use any strategy. 08:52.080 --> 08:56.400 And internally the library will select the right strategy for their problem. 08:56.400 --> 08:59.760 According to the coordinate systems, not the use. 08:59.760 --> 09:02.400 Okay, and also strategies can give you some, 09:02.400 --> 09:05.520 I cured us in performance trade-off. 09:05.520 --> 09:08.880 For example, you can use, for a complicated problem, 09:08.880 --> 09:12.240 like a distance on the ellipsis, you can use different 09:12.240 --> 09:15.200 strategies in that, implement an algorithm, for example, 09:15.200 --> 09:18.160 that it's not very accurate, but very fast. 09:18.160 --> 09:21.160 But then a user that needs more accuracy, 09:21.160 --> 09:23.960 they can use the strategy in the same distance algorithm 09:23.960 --> 09:30.560 that have more, maybe takes more time, but it's more accurate. 09:30.560 --> 09:34.240 Okay, so a bit about targeting spathing. 09:34.240 --> 09:39.120 There are tags for geometric strategies and coordinate systems. 09:39.120 --> 09:43.440 The data tag, the tag types are available through metafunctions, 09:43.440 --> 09:48.800 and we're dispatching according to geometry type, 09:48.800 --> 09:52.240 coordinate system, which is Cartesian, geographic, et cetera, 09:52.240 --> 09:57.520 dimension, because the algorithms that works in three dimensions, 09:57.520 --> 10:01.760 and according to strategy. 10:01.760 --> 10:05.360 And this provides a type safe and a static polymer 10:05.680 --> 10:11.840 that it's, so all of them are dispatching on compile time. 10:11.840 --> 10:15.680 So you don't have overhead in performance. 10:15.680 --> 10:19.680 Okay, hopefully this gives a bit more intuition. 10:19.680 --> 10:22.800 So let's say that you have a basic algorithm, distance. 10:22.800 --> 10:26.320 This will take two geometries and compute the distance. 10:26.320 --> 10:28.640 So this is the dispatching part. 10:28.640 --> 10:33.600 So if you give two points, then the right implementation will, 10:33.680 --> 10:38.000 in compile time, we'll go here and go to the implementation 10:38.000 --> 10:40.880 of computing distance between two points. 10:40.880 --> 10:45.760 Then there is another choice, if it will go and see if the points 10:45.760 --> 10:50.080 are Cartesian on the plane or geographic, 10:50.080 --> 10:52.880 and then it will choose the right implementation. 10:52.880 --> 10:55.440 And then again, it will, on compile time, 10:55.440 --> 10:58.480 it suits what is the right dimension. 10:58.480 --> 11:01.720 So if you have the cbts of computing, 11:01.720 --> 11:04.440 that this is between two points on the plane, 11:04.440 --> 11:07.160 you will go this way. 11:07.160 --> 11:16.200 And the labry will select the right implementation for your problem. 11:16.200 --> 11:23.400 Okay, so now let's go, once the further and see how we can use it. 11:23.400 --> 11:31.720 Okay, so this is typical with a simplest last template libraries. 11:31.720 --> 11:37.880 You have a set of liaising. 11:37.880 --> 11:41.240 So these are the main primitives. 11:41.240 --> 11:45.240 So you define points that are, as we said before, 11:45.240 --> 11:47.800 this is this is a point that it's in two dimensions. 11:47.800 --> 11:50.120 It's used double and it's Cartesian. 11:50.120 --> 11:54.680 Then you will use this type to define a line string polygon, 11:54.680 --> 11:57.880 and then the polygon you will use it to define a multi-volgan. 11:57.880 --> 12:04.760 So this is the main way that you define your primitives, your geometries. 12:04.760 --> 12:10.920 And then you can construct them, and then you can import data. 12:10.920 --> 12:15.880 So there is this function of reading the well-known text. 12:15.880 --> 12:23.320 This is a standard way of importing data in GIS. 12:23.320 --> 12:27.480 So this will read a line string polygon, a multi-volgan, 12:27.480 --> 12:34.280 and ask from these stands to compute the distance between those geometries. 12:34.280 --> 12:37.480 Okay, here there is no strategy. 12:37.480 --> 12:40.680 I didn't, as a user, I'm not using any strategy. 12:40.680 --> 12:44.440 So the library internally will use the right strategy for the right 12:44.440 --> 12:47.720 coordinate system, and the right dimension. 12:47.720 --> 12:54.840 So the user does the user just call distance with two attributes. 12:54.840 --> 12:59.960 Okay, so this is a graphical view of this. 12:59.960 --> 13:03.640 So this is the line string and we said what's the distance from this multi-volgan, 13:03.640 --> 13:09.240 and this polygon, and this is the result. 13:09.320 --> 13:14.680 Okay, so because it's general, the design can be used 13:14.680 --> 13:16.920 to define your own types. 13:16.920 --> 13:22.520 So you can create your own point, you must follow some concepts, 13:22.520 --> 13:24.440 which let's say the point concept. 13:26.440 --> 13:28.360 This is defined by some traits. 13:28.360 --> 13:35.240 There is some, for usability, there are some markers that can define, 13:36.200 --> 13:41.160 can generate your point, according to your struct. 13:41.160 --> 13:46.920 So these are some, my simple point with two doubles, 13:46.920 --> 13:52.600 can be read as a point that is usable for boost geometry, 13:52.600 --> 14:00.200 and then I can create one point and one line string 14:00.200 --> 14:03.480 by using a vector and just call the distance again, 14:03.480 --> 14:07.320 and this will again work. 14:07.320 --> 14:13.320 So this, and over here for all the algorithms, let's say that there are three main categories. 14:13.320 --> 14:18.680 We have measure algorithms like computing distance, length, and these are the similarity 14:18.680 --> 14:21.960 functions like Fresen, House of Distance. 14:21.960 --> 14:25.720 There are some geometric that compute the convex scale of a set, 14:25.720 --> 14:32.440 envelopes, bondic boxes, the buffer, and simplify. 14:32.520 --> 14:36.600 And there is another big part, which is the relational set of operations, 14:36.600 --> 14:39.400 that computes relational relation between, 14:39.400 --> 14:44.280 let's say, if a polygon crosses and other polygon, things like that. 14:44.280 --> 14:49.640 So everything is in the reference manual of the library. 14:51.640 --> 14:56.360 I will just give one more example of measure functions. 14:56.360 --> 15:01.400 So you can create a life and click this by pushing points 15:02.360 --> 15:09.000 on this type, and then I will just call this functions to compute the length, 15:09.000 --> 15:13.240 the area, and the perimeter, and this is the graphical, 15:13.240 --> 15:15.880 and I can have my results here. 15:15.880 --> 15:18.600 So everything up to here is Cartesian. 15:20.600 --> 15:24.840 Okay, so the same we're going to do with topology. 15:26.200 --> 15:29.800 Again, we define our geometry, and we can compute in the second and within. 15:30.360 --> 15:36.200 So this example of a polygon and line strength that intersect, 15:36.200 --> 15:38.200 but they're not within. 15:38.200 --> 15:40.040 So you can do many examples like this. 15:42.200 --> 15:46.920 And this is the last example before the spatial commutations. 15:47.800 --> 15:49.320 It's about the vertex. 15:49.320 --> 15:52.280 So there is an R3 implemented. 15:52.280 --> 15:55.800 It has three different split ureistics. 15:56.760 --> 16:00.360 Again, it's got to use some user-defined value, 16:00.360 --> 16:03.560 and can do spatial and gain and quills. 16:03.560 --> 16:09.080 So the R3, very, very broadly, it's a spatial structure 16:09.080 --> 16:13.960 that's like a B3 for geometric data. 16:13.960 --> 16:15.560 It looks like this. 16:15.560 --> 16:17.480 I will not dip into the details. 16:19.320 --> 16:21.160 Again, these are my types. 16:22.200 --> 16:24.440 I have to create a box and the value. 16:26.040 --> 16:32.120 And then I create my R3 with a value and to do the indexing. 16:33.000 --> 16:37.560 So I will create some geometries and insert them to the bottom box 16:37.560 --> 16:40.040 and insert them to my R3. 16:41.640 --> 16:46.040 And then I create a query, which is another geometry. 16:48.840 --> 16:50.440 I'm running this query on the R3. 16:50.440 --> 16:56.840 And then I iterate over the results of my query and it's like this. 16:56.840 --> 17:04.120 So these triangles, the orthogonal triangles are the data of my R query. 17:05.400 --> 17:08.200 And then this is my query. 17:10.520 --> 17:13.560 R3 will return, we'll not return those 17:13.560 --> 17:15.400 triangles that are far away. 17:15.400 --> 17:18.200 It will return those that the bottom box are in the exact. 17:18.200 --> 17:23.400 And then I can iterate and check which of them are really 17:23.400 --> 17:25.240 intersect my query. 17:25.240 --> 17:29.320 So that's why the previous loop I will get 17:29.320 --> 17:33.560 intersection of two triangles and then one of them is really intersecting. 17:33.560 --> 17:37.560 So it's like filtering geometries that are far away. 17:38.760 --> 17:39.400 OK. 17:39.400 --> 17:43.160 And this is the last part that's more, I'm 17:43.160 --> 17:46.760 thank to give some applications of first. 17:46.760 --> 17:50.600 This is the idea of a coordinate system that 17:50.600 --> 17:53.960 I've probably discussed it a bit before. 17:53.960 --> 17:57.960 You can have a three different coordinate systems 17:57.960 --> 17:59.000 and these are really meditating. 17:59.000 --> 18:01.160 Usually you can have a flat surface. 18:01.160 --> 18:02.440 You can have a sphere. 18:02.440 --> 18:04.600 Or you can have the elephant of revolution. 18:04.600 --> 18:06.760 This is the most accurate mode. 18:06.760 --> 18:09.480 More takes more time to compute. 18:09.720 --> 18:21.960 And this is how they will represent them in buzzometrics. 18:21.960 --> 18:24.440 Like this is the Cartesian, the spherical 18:24.440 --> 18:27.960 equatorial and the geographic that are parameterized by either the 18:27.960 --> 18:29.960 grids or radians. 18:29.960 --> 18:34.920 So I can use them now to my, to my distance example to see what 18:34.920 --> 18:36.040 what's the difference. 18:36.040 --> 18:39.880 So again, I will compute the distance between 18:39.880 --> 18:41.480 Athens and Brussels. 18:41.480 --> 18:46.280 But now I will get my specific strategy. 18:46.280 --> 18:48.920 And this will change a bit result. 18:48.920 --> 18:55.720 So if my strategy is spherical, I will get this number, 18:55.720 --> 18:58.600 which is like Google Maps because in Google Maps, 18:58.600 --> 19:00.520 they compute on the sphere. 19:00.520 --> 19:04.440 But then if I compute if I use a different strategy, 19:04.440 --> 19:07.720 like a geographic and doyer, I will get this result, 19:07.720 --> 19:09.000 or this result, or this result. 19:09.000 --> 19:11.640 So the difference are slides. 19:11.640 --> 19:16.360 But if you have an application that it's more accurate, 19:16.360 --> 19:19.800 it demands more accuracy, you may, you have to use 19:19.800 --> 19:25.400 a Vincentian, there are some, and if you have long distances, 19:25.400 --> 19:27.640 let's say your applications have a very long distances. 19:27.640 --> 19:34.840 Then the less accurate functions, the less accurate strategies 19:34.840 --> 19:35.960 will not work. 19:35.960 --> 19:39.160 We'll give larger errors. 19:39.160 --> 19:43.720 But this is not, I will not discuss more in this talk. 19:43.720 --> 19:47.640 I will just want to focus on the part that you can use different strategies 19:47.640 --> 19:49.320 to have a different angular axis. 19:52.440 --> 19:55.400 OK, so then this is one thing that we 19:55.400 --> 19:58.840 can do with the boost geometry. 19:58.840 --> 20:01.480 This is transformation between coordinate systems. 20:01.480 --> 20:06.360 So let's say that you have points on the air surface, 20:06.360 --> 20:10.840 given by GPS, and you want to map them on a map, 20:10.840 --> 20:14.760 to visualize them on a map. 20:14.760 --> 20:20.200 Since they are long-adliked, you cannot do it. 20:20.200 --> 20:22.120 So you have to project. 20:22.120 --> 20:25.320 Let's say that we are in British National Agreed, 20:25.320 --> 20:28.920 and we have a map, and then using boost geometry, 20:28.920 --> 20:34.040 we can project this GPS points on our grid. 20:34.040 --> 20:37.160 So there's a function transformations that takes you 20:37.160 --> 20:41.640 from this coordinate system to that coordinate system. 20:41.640 --> 20:46.840 So this is the GPS, and this is the our map. 20:46.840 --> 20:52.040 You just define this, and you call it with your points. 20:52.040 --> 20:58.680 So in this example, I will use London in GPS coordinates. 20:58.680 --> 21:03.560 I long-adliked it, and I just call it like this, 21:03.560 --> 21:08.760 and I compute the point on my map. 21:08.760 --> 21:11.880 So if the implementation here, it uses, 21:11.880 --> 21:17.240 actually, ring glimates a big part of a approach for it. 21:17.240 --> 21:20.680 And my project got, and it's finally out of those. 21:20.680 --> 21:30.120 So then I can draw, for example, I'm using QGIS to draw this. 21:30.120 --> 21:38.920 I can draw GPS points using boot geometry on this map. 21:38.920 --> 21:43.080 So this is the transformation function. 21:43.080 --> 21:52.040 And this is my last example, how to run a last project 21:52.040 --> 21:53.160 that is using boot geometry. 21:53.160 --> 21:59.960 So this is more or less this phrase, and how to do similar functions. 21:59.960 --> 22:06.680 Let's say that you have a GPS track, and you have many tracks in GPS. 22:06.680 --> 22:10.280 And you want to see how close are those tracks? 22:10.280 --> 22:12.040 How similar are they? 22:12.040 --> 22:17.480 And so using boot geometry, you can do it without projecting, 22:17.480 --> 22:21.240 because all the algorithms are implemented for all the coordinate systems. 22:21.240 --> 22:26.760 So you can have a similarity distance function that takes points 22:26.760 --> 22:28.920 that are longer to latitude. 22:28.920 --> 22:32.840 In the previous application, we had to project, 22:32.840 --> 22:34.680 because we wanted to draw in a map. 22:34.680 --> 22:38.280 But now, since we only want similarity of trajectories, 22:38.280 --> 22:41.320 you can do it also with a geography coordinate. 22:41.320 --> 22:45.160 And this is nice, because you don't have to project. 22:45.160 --> 22:47.960 You can also use as a preprocessor here, 22:47.960 --> 22:50.120 simplify algorithm for the R3. 22:50.120 --> 22:53.960 I will skip it for the example. 22:53.960 --> 22:58.920 And this is the code. 22:58.920 --> 23:04.200 You have line strings with your GPS data. 23:04.200 --> 23:07.640 And this is the function that you need. 23:07.640 --> 23:11.800 You compute the phrase that distance between your trajectory. 23:11.800 --> 23:14.760 Let's say this is your trajectory that you want to find similar trajectory. 23:14.760 --> 23:16.840 Your query trajectory, the black one. 23:16.840 --> 23:20.920 And these are the input trajectories of some workers on a park. 23:20.920 --> 23:24.040 And using phrase that distance, you 23:24.040 --> 23:29.960 will compute some values that gives you the similarity of those 23:29.960 --> 23:31.640 trajectories with your query trajectory. 23:31.640 --> 23:38.760 For example, here, let's say that the blue and the orange 23:38.760 --> 23:46.120 are more similar than the green one, let's say, or the red one. 23:46.120 --> 23:53.320 It gives you some similarity between those objects. 23:53.320 --> 23:57.240 OK, and that's it more or less. 23:57.240 --> 24:01.240 There's some future topics. 24:01.240 --> 24:06.920 There is some 3D support, polyheter self-face. 24:06.920 --> 24:10.480 This is in the last two releases. 24:10.480 --> 24:12.360 There is the definition of polyheter self-face 24:12.360 --> 24:15.280 and some validation algorithms. 24:15.280 --> 24:20.560 This is, let's say, limit the support for now. 24:20.560 --> 24:23.840 There is also some interest to support cave geometries. 24:23.840 --> 24:27.920 And there is a standard interest of improving robustness 24:27.920 --> 24:30.960 to have, because in geometric, logic points 24:30.960 --> 24:36.400 can be very nasty, but this is a total different topic. 24:36.400 --> 24:42.240 And we'd like to integrate newer standards in the boost geometry. 24:42.240 --> 24:44.240 And I think that's it. 24:44.240 --> 24:45.240 So thanks. 24:45.640 --> 24:46.240 Thank you. 24:54.240 --> 24:55.240 Any questions? 25:02.240 --> 25:09.040 No, no, it says, OK, are there any plot for the limitations? 25:09.040 --> 25:11.520 So this is in boosted plus plus libraries. 25:11.520 --> 25:13.360 These are tested. 25:13.360 --> 25:16.880 There are some regression tests on the page of boosted. 25:16.880 --> 25:20.000 There are tested in many platforms, many different textures 25:20.000 --> 25:22.800 and different compilers. 25:22.800 --> 25:26.520 And it builds on, you can see the test. 25:26.520 --> 25:30.960 It builds in, you have different results in some cases, 25:30.960 --> 25:34.280 some flotic point issues, but it builds on. 25:34.280 --> 25:38.560 And there are 800 while the wide lower is required for this support. 25:38.560 --> 25:39.960 No. 25:40.960 --> 25:45.720 Are there any other libraries that are needed for boosted geometry? 25:45.720 --> 25:48.560 So there are some dependencies, internal dependencies, 25:48.560 --> 25:50.200 in boosted plus plus libraries. 25:50.200 --> 25:55.480 So boosted geometry is using some boost libraries, 25:55.480 --> 25:58.640 but it's very typical in many applications 25:58.640 --> 26:03.840 to just take the whole boost and build your application. 26:03.840 --> 26:06.040 But you can just take boosted geometry 26:06.040 --> 26:07.840 and the dependencies and build it. 26:09.960 --> 26:21.320 The transformation that you mentioned between the different geocordinant systems, 26:21.320 --> 26:27.000 you also mentioned this brush for, is this code entirely 26:27.000 --> 26:30.760 in boost as well, or do you have a still dependency on brush for? 26:30.760 --> 26:32.680 There is no dependency on brush for, it's 26:32.680 --> 26:36.120 really mandated and executed inside boost geometry. 26:41.120 --> 26:45.880 Can you discuss error messages and build times? 26:45.880 --> 26:47.000 I don't mess up this. 26:47.000 --> 26:48.200 Yeah, compiler error messages. 26:48.200 --> 26:50.520 If I mess up, I don't know what type or something 26:50.520 --> 26:54.000 to use, c++ concepts to get these internal messages, 26:54.000 --> 26:58.480 or yes, boost geometry is using concept. 26:58.480 --> 27:01.040 They're not using the simplest plus point concepts. 27:01.040 --> 27:06.280 There are some concepts, let's say, a home brew. 27:06.280 --> 27:11.280 There is some error messages in compile time, 27:11.280 --> 27:16.320 because most of the parties tend late. 27:16.320 --> 27:20.480 It's possible to also see a huge error with a lot of templates 27:20.480 --> 27:21.920 that you know that are standard. 27:21.920 --> 27:29.000 But we try to give some intuition about what's the, what's 27:29.000 --> 27:34.560 there about, what about build times? 27:34.560 --> 27:39.080 So it's a header on library, so it depends on the application. 27:39.080 --> 27:43.560 So if you see the regression test, 27:43.560 --> 27:49.000 there are some times there in a boost website. 27:49.000 --> 27:52.920 Otherwise, since it's not an application, 27:52.920 --> 27:56.040 I cannot say about the build times. 27:56.360 --> 28:01.280 You can, okay, it's here, there are only 28:01.280 --> 28:02.440 and there are some opportunities. 28:02.440 --> 28:05.080 So what do you mean about build times? 28:05.080 --> 28:07.080 I mean, can you clarify a bit? 28:07.080 --> 28:10.360 Yeah, no, just sometimes with the template heavy libraries, 28:10.360 --> 28:13.320 when you include a single header, then they build time 28:13.320 --> 28:15.440 of a single translation and you need to explode, 28:15.440 --> 28:17.440 and I just want to know if that's the case, 28:17.440 --> 28:20.080 or even your small example is like, 28:20.080 --> 28:22.280 is something usually, is just something used. 28:22.280 --> 28:24.480 Yes, those examples are very simple. 28:24.480 --> 28:28.160 There, you will not notice a huge big time, build time. 28:28.160 --> 28:30.480 But let's say if you build my school, 28:30.480 --> 28:35.480 you will see a big part will be combining a boost geometry. 28:38.160 --> 28:40.640 Yeah, hello. 28:40.640 --> 28:45.080 Back to 2018, I compared boost geometry, 28:45.080 --> 28:53.080 C-Gell, geometry tools, libraries, and I found that, 28:53.080 --> 28:57.040 yeah, boost geometry has a very nice interface 28:57.040 --> 28:58.880 and most convenient to follow this library, 28:58.880 --> 29:01.520 this is my personal opinion, but still, 29:03.240 --> 29:06.440 nevertheless, I had to choose another library 29:06.440 --> 29:11.440 because a lot of, let's say, bugs, 29:11.440 --> 29:14.880 by the behavior and boost geometry, and of the eight years, 29:14.880 --> 29:17.080 how was it involved? 29:17.080 --> 29:22.080 Is it better now and did you fix a lot of bugs recently? 29:24.040 --> 29:27.160 Yes, so the question is about bugs 29:27.160 --> 29:31.280 in boost geometry and how they evolve and fix them. 29:31.280 --> 29:33.920 Okay, so I would say the most, yes, 29:33.920 --> 29:38.440 so bugs are issued in GitHub issues. 29:39.880 --> 29:44.880 There is relatively, let's say, 29:46.120 --> 29:51.120 good tracking and they're, 29:51.280 --> 29:54.800 we try to solve most of them. 29:54.800 --> 29:58.120 I would say the most difficult ones 29:58.120 --> 29:59.720 are regarding robustness. 30:00.800 --> 30:05.800 So in geometry, if you, I mentioned it before 30:06.880 --> 30:09.880 in the talk, in geometry, if you want to, 30:11.040 --> 30:13.080 you may have floating point these use 30:13.080 --> 30:18.080 that become errors that are combinatorial errors, 30:18.080 --> 30:21.520 you take it, you consider total different structure 30:21.520 --> 30:22.640 if you have a floating point. 30:22.640 --> 30:27.640 So this is fixed in three or four releases, 30:29.080 --> 30:33.200 I go, part, part, I'll fix in predicate. 30:33.200 --> 30:36.680 So the set operations now, if you're answer, 30:36.680 --> 30:39.600 if you're asking something as a yes or no, 30:39.600 --> 30:41.440 this is much more robust now 30:41.440 --> 30:43.960 because we integrated the robust, 30:43.960 --> 30:47.040 the filtering predicate, which is always correct. 30:49.400 --> 30:54.400 We throw away some all the tricks with floating points. 30:54.880 --> 30:56.640 So this is fixed. 30:56.640 --> 30:58.880 Something that it's missing that is more 31:00.320 --> 31:02.840 difficult to say needs more work 31:05.160 --> 31:08.080 is the robustness of intersections. 31:08.080 --> 31:10.040 So if you want to construct something, 31:10.040 --> 31:12.040 then you have to be robust also. 31:12.520 --> 31:14.480 So this needs more also, 31:14.480 --> 31:19.480 segal, solving it by have some kernels 31:20.640 --> 31:21.680 that takes more time, 31:21.680 --> 31:23.560 but if you select the right kernel, 31:23.560 --> 31:25.760 you can have a robust intersection. 31:25.760 --> 31:30.120 So in geometry right now, some bugs are related to this. 31:32.200 --> 31:35.200 Many of them are only floating point issues 31:35.200 --> 31:39.960 that we fix them, but maybe there are some, 31:39.960 --> 31:41.520 some of them are more deep. 31:42.880 --> 31:45.040 But there are a lot of bugs that are simpler 31:45.040 --> 31:46.920 and we just fix them. 31:50.840 --> 31:53.680 Hey, thank you very much. 31:53.680 --> 31:57.560 My question is about the strategies 31:57.560 --> 32:00.960 as I'm not very familiar with those, 32:00.960 --> 32:03.080 what is the difference between them? 32:03.080 --> 32:04.320 Excuse me, about there. 32:04.320 --> 32:05.760 The difference strategies. 32:05.760 --> 32:06.880 Ah, the strategies. 32:06.880 --> 32:08.160 Okay, so the strategies, 32:08.480 --> 32:13.160 let's say that they select a coordinate specific 32:14.240 --> 32:15.520 method for your algorithm. 32:15.520 --> 32:20.520 Let's say if you want to compute the distance between two points 32:20.520 --> 32:22.840 on the, on the, just on this table, 32:22.840 --> 32:25.600 it's a Pythagorean theorem, it's just one line. 32:25.600 --> 32:28.320 If you want to compute it on a sphere, 32:28.320 --> 32:33.320 then it's that some sign cosine functions, 32:34.160 --> 32:36.520 it's the gonometric again one line. 32:36.520 --> 32:38.840 If you want to compute on the ellipsoid, 32:38.840 --> 32:41.000 then you have to do some Newton method. 32:41.000 --> 32:46.000 It's a larger function, it's a 20 lines of code. 32:46.000 --> 32:49.560 So you have, and also it's a letter of method. 32:49.560 --> 32:53.200 So depending on the coordinate systems that you are, 32:54.280 --> 32:57.040 you have also different methods underlying. 32:57.040 --> 33:00.560 So if you are, let's say on ellipsoid 33:00.560 --> 33:02.280 and you compute a convex hull, 33:03.320 --> 33:05.600 or let's say the freezer distance, 33:05.600 --> 33:07.720 how close are two trajectors. 33:07.720 --> 33:09.720 If you do it on the ellipsoid, 33:09.720 --> 33:11.840 then at every step, the freezer algorithm 33:11.840 --> 33:13.920 with a combinatorial, at every step, 33:13.920 --> 33:16.320 they try to compute the distance between two points 33:16.320 --> 33:17.920 on the ellipsoid. 33:17.920 --> 33:19.480 So it calls a Newton method. 33:21.400 --> 33:24.080 The same algorithm on the plane, 33:24.080 --> 33:26.720 it will just go the Pythagorean, you know, 33:26.720 --> 33:28.560 where, 10 operations. 33:28.560 --> 33:32.520 And is it related to different uses? 33:32.520 --> 33:35.080 Like for example, you talked earlier about autonomous 33:35.720 --> 33:36.920 it depends on the application. 33:36.920 --> 33:42.280 So if your application is working on a projection, 33:42.280 --> 33:46.120 so you have points on some project with our Cartesian, 33:46.120 --> 33:49.000 then you just use the Cartesian algorithms. 33:49.000 --> 33:52.400 If your application is on the sphere 33:52.400 --> 33:55.320 and you don't want to do some projection, 33:55.320 --> 33:58.280 for example, if you want to compute 33:58.280 --> 34:01.880 the distances on the, on Europe, 34:01.920 --> 34:03.760 then as far as I know, 34:03.760 --> 34:08.760 you cannot project on every single part of Europe 34:08.760 --> 34:10.280 and then do Cartesian there. 34:10.280 --> 34:14.720 So you have to do something with a spherical or ellipsoid. 34:14.720 --> 34:16.160 So you have to do with the application. 34:16.160 --> 34:18.280 Last part of the question, 34:18.280 --> 34:21.040 are you aware of some real-time applications 34:21.040 --> 34:23.720 that use put geometry library? 34:24.720 --> 34:25.880 About what applications? 34:25.880 --> 34:28.960 Real-time applications like, for example, 34:28.960 --> 34:31.840 autonomous driving apps applications. 34:31.840 --> 34:32.680 I don't know. 34:32.680 --> 34:33.040 OK. 34:33.040 --> 34:33.720 I don't know. 34:33.720 --> 34:36.040 Thank you. 34:36.040 --> 34:36.880 That's it. 34:36.880 --> 34:38.200 I think we're out of time for questions. 34:38.200 --> 34:41.120 Sorry to anyone else had a question. 34:41.120 --> 34:42.720 Next talk in five minutes. 34:42.720 --> 34:43.680 A very quick question. 34:47.080 --> 34:48.080 Is. 34:48.080 --> 34:49.080 Thank you. 34:54.080 --> 34:55.480 Here's the next speaker here.