 Okay. I guess we should start. My name is Norval. I'm a software engineer at Oracle. I work on geospatial data in MySQL. In MySQL 5.7, we started really improving the GIS support, and we're continuing in MySQL 8. In MySQL 5.7, we were able to replace a lot of the old, we actually replaced the entire computational engine for GIS. In MySQL 8, we are extending the support. So, I want to talk about the next version of MySQL. I can't promise anything. I know what we want to do, what we plan to do, but I can't really promise that this will be in the final product or all of it. I can say the general idea, some of this will be in the product, but we won't delay the release of MySQL 8 because we're missing a GIS function. So, if we miss the deadline for some of that, we can't, we'll deliver whatever we can. So, I'm going to talk a bit about the goals for MySQL 8, or GIS in MySQL in general. What we will do in MySQL 8, how we will extend our support. I'll talk a bit about the choice of library for geocomputations. Say something about our view on static compliance, and then this all boils down to a few decisions around, for instance, access or in data types. So, the real chain as you will see and difference between MySQL and some other systems, because of these principles I'll talk about first. So, our goals, ease of use. We want MySQL to be easy to use. One of those things is to follow the standards. Another thing is that it should be built in, not like some other open-source state-based management systems that have GIS as an add-on. This will be built in. First-class citizens. It should be really easy to start using GIS. If you have geodata, you don't need to add an extension just to store your coordinates and do computations on them. We are already the most popular DMS for web apps. If you've been to our stand-down downstairs, it says five out of five most popular web apps are using MySQL or something like that. Web maps are the real new thing, so we want to support that as well. We already have a great market for web apps. We want web maps as well, which means global data. This is not scientists working on Norway, for instance. These web maps are global usually. It means data-imported export that is suitable for the web. For instance, JSON export. We want to care for mobile devices. I have one here somewhere. We all have GPSs. Well, some of these apps are now being backed by web technology, so some of this applies to mobile devices as well. People start tracking where they go. We have people coming to me talking about vehicle tracking in MySQL, so we want to care for that as well. Maybe routing at some point. It's not on the bold map at the moment, but supporting some kind of fleet tracking, fleet management thing is definitely something we would like to see in MySQL. So what we'll do? We will do geography, geography, and geography. MySQL 5.7 and earlier only supports Cartesian math. You can specify an SRD, but like post-it, we'll ignore it with the geometry types. So we are adding the entire framework for supporting spatial reference systems. It's already in the first developer milestone of MySQL 8. It's hidden in there. We haven't talked much about it because we haven't really exposed it to the user yet. But the framework is starting to appear and we are planning to geographically enable as many functions as possible. We're not adding as many functions as possible. We are taking those functions we have for Cartesian data and starting to make them work on geographical data, longitude and latitude. We are using boost geometry as a library for GIS, and that means that we first have to add that functionality to boosts, and then we can start using in MySQL. We prefer not to add special mathematical functions to MySQL. We want to add them to boosts first, and then we wait for boosts to be released. And we will do some things to make the upgrade easier because MySQL already supports SRIDs, but it doesn't understand them. So you can set an SRID that's geographical, but it will still do Cartesian computations. This is kind of an upgrade story for us that does look too good. But it's still in development. We can do a lot of things. We really like your feedback. So we had a milestone release in September or October. There's one coming up soon. So I think in the next one, you will see some of this GIS work. So test it and give us feedback. We are really looking for feedback on our decisions and solutions. So we had to pick a library. We did that in MySQL 5.7. We didn't want to maintain all this alone. We can help maintain it, sure, but we don't want to do it alone. We want something that already exists that we can expand on. We're happy to contribute. We are maybe the single biggest contributor to boost geometry at moments. The two next guys are from Oracle as well. They are working exclusively with extending boost geometry. We're happy that they can actually contribute that back instead of doing it all in MySQL. We need a library for C, C++. MySQL is C++. And we want something that follows the OGC standards. Because we do that and we want something that kind of fits with that solution. And we want one library that handles Cartesian computations and geographic computations. We don't want to use two different libraries and adapt to two libraries because we have to adapt. With Boost, we have, well, there are properties of that library that makes it, that requires changes in MySQL to use a library. For instance, they're very into type traits and that kind of thing, which means we actually have a different point type for Cartesian and geographical data. Because it's a trait of that data type, which computations you get. So that affects some of our design decisions in the server. We started with Boost 155 a couple of years ago. And we are upgrading every version. We now own 163 in development. But as soon as we release, so MySQL 57 is a stable release, we froze that on Boost 159. So Boost geometry is a header-only library, so it's compiled in. There's no runtime linking at all. So the reason we freeze is that we are doing so much work contributing new stuff that we can't really upgrade and have a stable behavior of that MySQL version. So we need to freeze to be sure that we have a stable behavior. That means that we have to maintain some patches. In case we find bugs that we need to fix, we will have to make patches for Boost or separate header files to work around these issues. So we both extend Boost and we do some patching if we find the need for that in our release. So MySQL 57 was released two years ago or something. And we're going to support that for, I guess, until eight years. So there's quite a number of years to support one Boost version. But we only have to support the functionality that we are using. So we have to bug fix that. We want the standard compliant as close as possible to these standards, but they disagree a bit sometimes. Some things are not well-defined. We spend quite some time digging in the standards trying to figure out exactly what does this mean. Something is just stupid. If you look at GeoJSON, the RFC that came out, the interpretation of a line segment, that's just stupid. It's not the shortest line. It has to be on the globe, but it's a linear interpolation in the Cartesian system. It just doesn't make sense. So we decided not to do that. And the standards are usually object-oriented, like you would see in Microsoft SQL Server. But MySQL and Postgres are not. So we have a different dialect of things. And some things are not standardized. The SQL standards care about how you insert, update, lead, and query data. But it has nothing to say about how you create a spatial reference system, how you define it. That's not defined at all. So that's something we have to make up or look at how our competitors are doing it and copy them. This is where we are. We're at 50.81 and 4.38, which means we are in Brussels or outside the coast of Somalia. It depends on whether it's latitude, longitude, or longitude, latitude. I had beer here and not Indian ocean waters. So I think we're in Brussels. But this has been argued for a long time. And we want to be standard compliant. And this is what the OGC said nine years ago. Going forward, always follow the order of axis specified in spatial reference system. So MySQL uses the EPSG data sets. We currently import like almost 5,000 corner systems from that. That's all the types that we support. Those are either projections or 2D geographical systems. And EPSG uses latitude, longitude, which means MySQL is latitude, longitude. I remember Microsoft tried to use latitude, longitude when they added GIS support. They had so much complaints that they backed out of it and switched to longitude, longitude. So here we go again. I know buses is longitude, longitude, always. But we have something that Microsoft didn't have. We have extended the standard a bit. We allow for a separate parameter where you can say that my data is longitude latitude. No matter what this EPSG code says, this is longitude latitude. For this import, for this export, use longitude latitude. So we can override the default. That is, for all our systems, latitude, longitude. If you create the wrong, you can create the longitude latitude system. No problem. But all those that come with MySQL are latitude, longitude. So we believe that the best thing is to follow the standards and this is where it led us. Maybe not what we expected, but that's the way it turned out. On the other hand, we store it as longitude latitude, but that's our internal search format. Don't care about that. That's a historical decision and probably a good one. I don't complain about that, but this is for import, export. How we store it internally doesn't matter to our users. This is just something we need to do. But it matters in the upgrade we have to coming, but not for the user of MySQL. Not after the upgrade at least. Another decision we made because of the standards is that we use the same data types for Cartesian and geographic data. So it's geome from texts, both for SID0, which is kind of the abstract infinite plane, and for geographical data in WDS84. So if you come from post this world, you will see GOG from texts here because geometry and geography are different things in some systems, but not in MySQL, because this is the standard compliant way of doing it. This is what the OGC has said all the way. So Cartesian between kind of this is latitude, longitude, and it's in Cartesian, so it doesn't really make sense the output you have, but this is actually run on my working tree for geographical distance. So this actually is what MySQL will hopefully provide when I'm allowed to push that. But of course, you can coerce MySQL to think spherically, for instance. So even if it's SRAD0, we have functions that will coerce this into being a geographical computation. The reason these are different is that the defaults, this is a sphere, this is a spheroid. But yeah, so we had, we have made some decisions. The Bain wants to follow the standards and to use boost, that led us to having internal structure differences between geographical and Cartesian data, but because of standards, we try to merge it and present it as one data type to the user. But then you have these decisions and these consequences lead to the interesting upgrade story where upgrading from the previous MySQL to the current, to the next MySQL is going to be interesting if you use something else than SRAD0 because you might be saying that I have latitude, longitude, or longitude data, but your computations in the previous MySQL were Cartesian anyways. So we'll have some interesting effects there. Also, the latitude, longitude, longitude, latitude swapping that was introduced in MySQL 8, so the old MySQL doesn't really understand what you're doing. So it will always say X first then Y, so you will always, in old MySQL, you will always saw longitude first, which means that you have to change your import-export statements when upgrading. So this is going to be fun. All these users changing the data and the queries at the same time as they're upgrading. But we are trying to prepare users by saying, switch to SRAD0 now because that's actually what you're doing. Whatever you claim you're doing today with longitude latitude, you're not, it's Cartesian. So just tell MySQL that you're doing that and everything will be the same when you upgrade. It will simply wrong. So yeah, that's kind of perhaps one of the most interesting conclusions we arrived at when starting on this, that we were going to break quite a few things when upgrading. So this is still ongoing. I showed you some work on distance between geographical points. Hope that can get in. We have all the other functions we need to geographically enable as well. But we will blog about this as it happens. We will try to announce as much as possible because this, as I said, this will break things. So we'll try to be very active on telling users, this is what we're doing, this is how you should prepare now to be forward compatible. And I have a feeling that in the end we will be more standard compatible than the alternatives. Which is an interesting thing to see that MySQL is suddenly the most standard compliant one. But it helps sometimes to come late to the party because all the other ones have made the mistakes and you can learn from them. So I do have time for a few questions before the next one has set up. We have three sessions with no break between. So I can take, I think, a few questions before we continue. If there are any. Yeah. So, yeah, you're from the evil side or the good side from positive, the other side. Yeah, so you're asking about performance. We don't have any performance numbers yet. This is still in development. So I haven't really gotten around to doing that. But I guess we'll start seeing it when we actually release a development version that kind of a milestone that has the functionality that people will start comparing it. It will be interesting to see. And also, I think we could look at correctness. I think I've seen a few things in Puzzles that looks a bit weird in computations. So they're both things. We saw that when operating from five, six to five, seven that people complain, oh, it's almost slower. But then we said, yeah, but now we get correct answers. So what do you want? So, but the matter of accuracy versus speed, that is definitely a thing we're thinking about. And we may have, at the moment, fail on the side of being too accurate and too slow, maybe, in our application. We can adjust that afterwards. Puzzles is really flexible on that. We have Puzzle developers here. They know that we can adjust the strategies and the algorithms quickly. Okay, yeah. Do you have some estimates regarding GA? Estimates regarding GA on my scroll. So, no, the state release, well, I think it's been like two years since the previous one. So we typically release two or three years after the previous one. So, yeah, it's forthcoming. I don't have a date yet. I'm sorry. Yes. Just take a look at one hour for open worlds coming up that gives you a new sense. Could be a hint, yeah. Is the spatial index is not yet from boost? Are there other plans to change it, or is it just permanent? Spatial indexes are not yet from boost. No, our spatial indexes are homegrown, arteries. I don't think there are plans to, or I know there aren't any plans to replace that. I'm not sure we could. I'm not sure if the boost arteries would work in that setting because it's so ingrained into InnoDB and the way InnoDB works. So it's more similar to InnoDB B3s than to boost arteries. I think we have to do the next one offline because I'm one minute over my time here. Yes, no one, sir. Okay. Is it based on InnoDB only or other star changes? We are focusing on InnoDB only. My isome seems to be dying. That's just a hint. Okay. Thank you.