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

OpenLayers 6 - There And Back Again

00:00

Formal Metadata

Title
OpenLayers 6 - There And Back Again
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 last few months have been quite a ride for our good ol’ web mapping companion. What should have been a peaceful rest after a lengthy refactoring in version 5 did in fact end up being an involved rewrite of its rendering code: better **performance**, nicer **vector tiles**, smoother **WebGL**, more options and even some Mapbox goodness in there. In this talk we will take a quick tour of all the new stuff in OpenLayers and talk about the *why*s and *how*s, as well as what lies ahead of us. Love maps? We do too, come along!
Keywords
Presentation of a groupSoftware developerDifferent (Kate Ryan album)Thomas BayesVisualization (computer graphics)Lecture/ConferenceMeeting/Interview
WebsiteServer (computing)TwitterContext awarenessPhysical systemAxonometric projectionLibrary (computing)Interactive televisionOpen setBeta functionCodeElectric currentRevision controlLibrary (computing)Projective planeInternetworkingComplex (psychology)Web pageContext awarenessBeta functionSoftware developerSoftwareBitFile formatMultiplication signServer (computing)VotingOpen setQuicksortRight anglePanel painting
Library (computing)Level (video gaming)CodeWeb pageGoodness of fitBitSource codeBuildingRevision controlLink (knot theory)Computer animation
Modul <Datentyp>Open setComputer configurationTypprüfungSoftware testingArtistic renderingSoftware developerWebsiteLibrary (computing)CodeStandard deviationElement (mathematics)Web browserVector spaceOverhead (computing)Read-only memoryData managementLevel (video gaming)Position operatorReading (process)Revision controlVideoconferencingPRINCE2Prisoner's dilemmaCondition numberParameter (computer programming)Projective planeWeb pageWebsiteDevice driverLibrary (computing)19 (number)Medical imagingQuicksortConnected spaceRight angleTerm (mathematics)Scaling (geometry)Multiplication signBitInternetworkingAutomatic differentiationPiPoint (geometry)Computer configurationSet (mathematics)CausalitySoftware developerDigital photographyStaff (military)Type theoryStandard deviationAlgebraic closureMoment (mathematics)Software testingForm (programming)CodeInsertion lossLevel (video gaming)Equivalence relationService-oriented architectureAxiom of choiceResultantPhysical systemModule (mathematics)Open setFunctional (mathematics)Content (media)Endliche ModelltheorieFocus (optics)FrequencyNeuroinformatikTorusMultilaterationTesselationVector spaceMathematical optimizationWeb browserPlanningCartesian coordinate systemZoom lensGraph (mathematics)Element (mathematics)Complex (psychology)Queue (abstract data type)Group actionText editorFilm editing
Element (mathematics)VolumenvisualisierungLevel (video gaming)Revision controlCuboidProof theorySound effectMappingInteractive televisionVector spacePower (physics)TesselationFunction (mathematics)QuicksortElement (mathematics)1 (number)Computer programmingBitRaster graphicsUtility softwareLibrary (computing)ResultantDifferent (Kate Ryan album)Projective planeCodeCASE <Informatik>Latent heatPoint (geometry)Web 2.0Default (computer science)Focus (optics)LeakComputer clusterObservational studyOpen setRoundness (object)Transport Layer SecurityHoaxOverlay-NetzWordWage labourView (database)Axiom of choiceMultiplication signGenderStudent's t-testWeb pageTexture mappingObject (grammar)Software bugComputer animation
VideoconferencingView (database)Constraint (mathematics)CodeProcess (computing)Vector spaceAxonometric projectionData structureRead-only memoryMultiplicationSocial classMIDIFile formatQuicksortView (database)Object (grammar)BitData structureMultiplication signPhysical systemRevision controlFile formatFrame problemElement (mathematics)Type theoryLevel (video gaming)MathematicsVolumenvisualisierungCartesian coordinate systemDefault (computer science)VideoconferencingTask (computing)BefehlsprozessorElectric generatorSocial classConstraint (mathematics)Semiconductor memoryZoom lensWeb 2.0Vector spaceOpen setCombinational logicCASE <Informatik>Group actionExtension (kinesiology)Context awarenessArithmetic progressionLine (geometry)WordMedical imagingMoment (mathematics)MultiplicationDistortion (mathematics)PolygonElektronisches MarketingSpacetimeINTEGRALShape (magazine)Network topologyProjective planeNatural numberPoint (geometry)Process (computing)Panel painting
CodeSelf-organizationWritingProjective planeLibrary (computing)MathematicsState of matterGenderComputer configurationPoint (geometry)DigitizingTorsion (mechanics)Condition numberSource codeMusical ensembleMultiplication signDifferent (Kate Ryan album)VolumenvisualisierungWebsiteComputer fileRevision controlPhysical systemPerfect groupQuicksortLatent heatControl flowMereologyVector spaceWeb 2.0Lecture/ConferenceMeeting/Interview
Transcript: English(auto-generated)
Okay, I think we're ready to start. Hi, welcome everyone. Welcome to this presentation about OpenLayers.
Okay, so OpenLayers 6. So first, some introduction. My name is Olivier Guyot. I work at Cam2Camp. I'm a developer. I work in France, Chambéry. And Cam2Camp is a company that is based in Lausanne, Switzerland.
And we specialize in different kinds of spatial softwares. QGs, GeoServer, of course OpenLayers, GeoNetwork and others. Okay, so this talk is about the new version of OpenLayers
that is about to come out, version 6. I'm going to start with some context so that everyone understands what we're talking about. Also, I will try to keep this talk not too technical. So if it's either too technical or not enough, you can ask questions afterwards.
How many of you have already used OpenLayers in their projects? Okay, that's a lot. More than I expected. Cool. Alright, so some context. OpenLayers is a JavaScript library for making interactive maps. It's a bit of a complex library because it's pretty powerful.
It can handle many different formats and can also handle different projections. So it's really powerful. It's been around since 2006 for version 1, so 13 years. And there was a version 3 that was published in 2014.
Version 3 was a complete rewrite of the library. So sometimes on the internet you see people still using the OpenLayers 2 version, which is basically a completely different library. So the project is following semantic versioning, and the latest release is 5.3.
There is a beta version for version 6, which has been available, I think, since February. So it's a pretty long-running beta. And the project is hosted on GitHub, OpenLayers slash OpenLayers.
So the development of the library has been funded by several companies over the years. To name a few, we have Swiss Topo, which is the Swiss federal topographic agency. Terrestris, Poundless, not so much now, CounterCamp, and others. There is also an open collective.com page if you want to check in.
So just to make it clear, most of the work done on the library is paid work. It's not hobbyist. So the library is thoroughly documented. There is an API doc. The links are not very readable.
The API doc is generated from the source, so it's pretty complete. It hasn't been very readable since version 5 because of the restructuring. So we are aware of that, and it should be much better for version 6. Also on OpenLayers.org you'll find almost a bit less than 200 examples.
Basically every feature of the library is showcased in an example. So in my opinion, this is the best way to learn how to use it. So if you go on an example page, you can see all the code below the map, and you can also edit the example in CodePen.
So that's really useful. You can tweak it. So the library is available on NPM as a package called OL, and it's published as ES6 modules. This is important because now since version 5, even though the library is pretty big in terms of size,
when you import the different modules in your project, you will not end up with all the library in your application. So your application should not be too big because of OpenLayers, unless you use 100% of the library. The library is written in JavaScript, but it has type annotations,
so you can use it in your editor and you will have type checking, IntelliSense, auto imports, stuff like that. So you see here a quick video where I'm attempting to write code, and it works very well. So to be honest, setting up a project with this sort of JavaScript project
sometimes doesn't go as well as planned. So there is a lot of documentation on the GitHub of the project to tell you what exactly to do to have this sort of result. The library has been built by almost 100 contributors over the year. You can see the graph of the commits here.
So you see that we're still in a very active period, so it's a great time for the library. And we had more than 500 commits since the start of 2019, so it's really going strong. All right, so what about now? What's happening? So as I said, we're transitioning from version 5 to version 6.
Version 5 was a big overhaul of the library. It was focused on the developer experience. We changed the system with which the library was built and shipped, which is called Closure Compiler,
and we went to something more standard, which are ES6 modules. There are type checkings, more rendering tests. The result is that the library is easier to use, to include in your project, and it's also easier to contribute to because there are more tests. It's safer. Now, in version 6, the focus was more on the library functionalities.
There was a big focus on the vector tile performance, which has been there for a few versions, but we really wanted to step up on this topic. Also, better API, more possibilities, so a bit more flexibility, which has already been a strong point of OpenAIers.
Also, there's going to be some work on the website and documentation. So we had two cut sprints since the fall of 2018 for version 6, and there is the last one that is planned at the end of September, and hopefully that will be the last step before the release.
These cut sprints have been funded by the community. There was a fundraising campaign. People responded to it. We could fund a lot of work time for this, so it's great. Thank you. Let's dive in on what's new in version 6.
So there is a big thing that's happening. Basically, previously, when you had your OpenLayers map in your page, you had the equivalent of one image, and all the data, all the contents of the map was blended into this image. Now, with version 6, we're transitioning to what we call composite rendering,
where each layer will have a different element on the page. Standard layers will still use the canvas element, which is the basic thing when you want to draw stuff on a web page. You could use something else. The idea is to give more flexibility and to open up options possibilities.
So it's not actually that new, and that's also why this talk is called There and Back Again, besides being an obvious reference to Tolkien. It's also because before that, OpenLayers used to work pretty much like this,
and by doing this, we're kind of reassessing the choices that were made before, and we thought, OK, with what's happening now and what the browsers are capable of now, let's go back to something more flexible like this. So we make the library more versatile.
The library code is a bit simpler, because it doesn't have to compose all these things into one image, and it also leverages browser optimizations. So it's pretty good. There were some performance issues at the beginning. That was the biggest challenge in my opinion, and we made what was necessary to make it work,
so now it works great. And for those who know what it is, WebGL map is gone. But I'll get back to it a bit later. OK, so about vector tile improvements. This was supposed to be animated, but it wasn't working well.
So on vector tiles, we really spent time optimizing and tweaking the way they are generated and rendered so that it gets smoother. Vector tiles are pretty hard to manage, because they can be heavy, and they're heavy on CPU,
so it's hard to have a very smooth experience. But it got really better with this version. There's better tile queue management, faster tile generation, and less tile load. The idea is to load only the tiles we really need, and at the right time, not all the tiles. At the same time, etc. It's a bit hard to illustrate, a bit complex.
I did put a small animation where you can see the fact that we reused tiles across zoom levels. So this is captured using a slow internet connection, and you can see that the user experience is not too bad, because you're still zooming in on one tile,
and gets rescaled up, but it's still sharp, and that the details arrive, gets better and better. So that's really something new in this version. OK, let's talk a bit about WebGL. OK, so you probably know that if you want to display something
in a web page, you have two choices. You either use 2D graphics or WebGL. 2D graphics is a very nice API, very easy to use. It gives clean output. It's very nice, but it's slow. And WebGL is all the contrary of this.
It's a pretty verbose API. It's hard to use, it has glitches and expected behaviors, so it's kind of a pain. Originally in OpenAIREs version 5, and before you had two renderers available. You either had the default renderer, which was using 2D graphics,
and then you had the WebGL renderer. You could create a map and say, I want this map to use WebGL. It worked, but it had bugs, glitches, the text were blurry, and the code was very complex because of this, because we basically had in the same project
two libraries, one library to handle 2D graphics, another to do WebGL. It was a lot of code, very hard to maintain, and not that used eventually. So now that we have composite rendering, we said, why not just render most of the maps
using 2D graphics, because it looks good, it works well. And then for specific use cases, use WebGL. We got rid of the monolithic renderer. We just deleted it. It's still there in the history of the project, and we're still taking inspiration from it,
but it's gone from the library, and now we added some new utilities to the WebGL, with a focus on being really lightweight and focused on specific use cases. So the first use case we targeted was large point datasets.
You can see there's an example there. It's a map of the UFO sightings. In the world, it's basically a population map. So it's 80,000 points, and with this WebGL renderer, you can specify textures,
you can specify colors, you can filter. You can have all sorts of effects. It's pretty low level. It supports retina devices, heat detection. It is multi-threaded, so it runs pretty well.
And to have a kind of proof of concept with this approach, we said, okay, why not rewrite the heat map layer? There was already a heat map layer in OpenAIOS. It worked pretty well. It was using the 2D graphics API. We said, okay, let's rewrite it with the power of WebGL.
Now, when you look at a static image, the result will be exactly the same in version 5 and 6, but when you navigate in the map, then you'll see the difference. It's much smoother, it's much nicer experience, and yeah, it works very well.
So this is permitted because with this new renderer, we actually gave access to shaders, which is basically GPU programs. So for those of you who have attended Ivan's workshop yesterday about WebGL raster processing,
this is something you can use what you learned in the workshop with this renderer. This is exactly the sort of power we wanted to give to the users. Okay, so now also we have with composite rendering, we can have custom layers. By custom layers, I mean layers that are not the standard ones.
Any kind of HTML elements. We said, okay, we can put anything we want in the map, so why not try and put map box in the map? We were looking for a way to have a nice base map based on vector tiles and still be able to put stuff on it and interactive layers,
drawings, et cetera. Using the vector tile layer of the library was giving us a bit of a performance issue, especially on mobile devices. So we tried with map box and actually it worked really well. So there is an example that showcases this. So you see you have the base map, which is map box,
and then you have an overlay, which is a simple country vector layer. Now, okay, so if any of you work at map box or are related one way or another to map box, to use this, we used an undocumented API from the library,
which is a great library, by the way. We really like to have some sort of official API to do this sort of integration, because for us it's very interesting. It's really a way to have the best of both worlds, so spread the word. Okay, you can do anything else you want, actually.
You could have GIF animations, SVG objects in your map, you could have video, native HTML5 video elements. These were the sort of things that were possible in previous versions, but because everything was kind of blended into one image, animations weren't working well, you had to copy the frames
and the frame rate wasn't good, and the SVG were blurred, so it was kind of hard to manage. With this new system, it should be much more easier. Now, this is not yet implemented, and we'd like to have this in, but that's a lot of work, so if anyone wants to try and contribute,
be my guest. And on the illustration, you can see there is a graphical layer, which was rewritten and reworked for the composite rendering, so it's just an example, among others, to use this system. We also reworked a bit the way the view constraints work.
You will be able now to specify an extent constraint on your map, which means the user will not be able to zoom out or pan out of this extent. It wasn't really possible before. You could specify a center constraint or a zoom constraint, but this is a combination of both.
Using this system, we implemented what I call multi-word constraints. You see on the left, this was something that was quite frequent with open layers, because you could zoom out to zoom level 0, and then you'd see all these mirrors of the world, and that doesn't really make sense.
Now, the default behavior is that you are not able to do this, and you will be limited by the height of the world, so it's a better user experience. It's less misleading. You can see I have the previous behavior, if you want, with an option. There's also multi-threading that was added to open layers.
This was a very nice contribution. There is a pipeline that is completely seamless for the application. The users absolutely don't have to worry about it. It's just there. It's only used in the WebGL renderer for now, but it would be very interesting to use it for all the CPU heavy tasks
that are processing. Also, vector type generation can be pretty hard. All right, so I covered most aspects of the version 6. There are some things planned for the future.
There is something as a work in progress, which would be a big change in the API. For those of you who have actually used a written code with open layers, the API, for example, if your map is rendered in Web Mercator,
which is most likely the case, you will need to give the API coordinates in Web Mercator, and this is not really practical. You end up transforming geographic coordinates to Web Mercator all the time. It is error-prone. It's annoying. It's verbose. The idea would be to transition the API to only use geographic coordinates all the time
and not take into consideration the view projection. This is a work in progress. I don't know if it's going to be there in version 6 or not. At some point, we'll have to stop adding new stuff, but I can't talk for the others. Also, the improvements to data structures we'd like to have in.
Currently, all the features, geometries, ties are based on classes. It's nice, but it takes a bit of memory. It's not serializable, and it cannot be used in multi-trading contexts. We'd like to move to something more based on JSON, GeoJSON,
to have more useful use cases. That would mean rewriting the whole API, probably for another major version. What's next? More multi-trading? More WebGL possibilities? Lines, polygons, of course.
That would be great. New and emerging formats when they arrive. That's it. Any questions?
The question is, how hard will it be to migrate from version 5 to version 6? It shouldn't be too hard.
Most of the changes are under the hood, so you won't see the difference in your code. I think it should be easy, and it's all documented. The breaking changes are documented.
That's a good question. OpenLayers is not able to use Mapbox styles directly. There is a library that is part of the organization on GitHub that does this.
It's called ol-mapbox-style, and it takes Mapbox JSON and transforms it into OpenLayer styles.
If you want to use different renderers, basically you won't create the renderer yourself. This is kind of internal stuff. The API is not completely fine on this.
We need to work this out. You'll probably just create a layer, and it's going to be either a vector layer, which is standard, or you maybe have a points layer, which will use the WebGL renderer. It's all under the hood, and we want to make the API very simple.
You probably have to write something,
SVG renderer. I don't know. It's a good question. It would be interesting to have a specific renderer for this, for example, that uses SVG elements. That's not there. That's not there already.
There have been improvements. I cannot guarantee that it's going to be fixed. It all depends on how you include the library. It's true that for a while it wasn't very clear how you were supposed to include it. You can have this sort of stuff working perfectly.
We have many projects with OpenIR 6. It works great. It's just a matter of configuration. There's a lot of documentation on this topic, and we know it's hard for people. The library is published as ES6, so you have to take that into account. It should be in the documentation.
That was tricky. So the web workers are separate files in the source code,
and there is a transpiling step before publishing the package, and at that time the worker code is written as a blob in the package. It's a great system. It's awesome.
Okay, thank you very much.