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

State of the OL-Cesium library

00:00

Formale Metadaten

Titel
State of the OL-Cesium library
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
Herausgeber
Erscheinungsjahr
Sprache

Inhaltliche Metadaten

Fachgebiet
Genre
Abstract
OL-Cesium is a popular Open source Javascript library that you can leverage to add 3D to a new or existing OpenLayers application. You code the logics in a single place and it gets applied to both OpenLayers 2D map and Cesium 3D globe. The library handles the synchronization of the view, layers, styling, for you. This behaviour is customizable. Since its creation, 9 years ago, the library has attracted a large community of users. It has evolved to follow OpenLayers, Cesium and the global javascript ecosystem. This talk is about the strengths of the library, its state and the plans for the future.
SoftwarewartungComputerspielApp <Programm>ProgrammbibliothekVersionsverwaltungDimension 3Offene MengeOpen SourceMAPKartesische KoordinatenCodeUmwandlungsenthalpieMathematikPhysikalisches SystemFramework <Informatik>CASE <Informatik>Güte der AnpassungEntscheidungstheorieGraphfärbungCompilerNormalvektorBimodulMatchingAutomatische HandlungsplanungMapping <Computergraphik>SichtenkonzeptDynamisches SystemGlobale OptimierungGruppenoperationTouchscreenElementargeometrieImmersion <Topologie>ComputerarchitekturRechter WinkelPunktKontrollstrukturNebenbedingungBasis <Mathematik>Projektive EbeneSelbst organisierendes SystemSpannweite <Stochastik>VererbungshierarchieVektorraumTransformation <Mathematik>VersionsverwaltungProgrammbibliothekSynchronisierungSoftwarewartungAlgebraisch abgeschlossener KörperComputeranimation
TypentheorieSystemplattformImplementierungAxonometrieBitmap-GraphikTaskKonfigurationsraumCodeVersionsverwaltungMigration <Informatik>AbstraktionsebeneSpeicherabzugPolygonTermFahne <Mathematik>Projektive EbeneSoftwareMAPGeradeVersionsverwaltungKanalkapazitätMigration <Informatik>Spannweite <Stochastik>TesselationBitmap-GraphikTeilmengeVolumenvisualisierungMereologieOffene MengeVektorraumHilfesystemMultiplikationsoperatorCodePhysikalisches SystemPunktInverser LimesVollständiger VerbandÄquivalenzklasseGüte der AnpassungEntscheidungstheorieClientSpieltheorieTypentheorieSoftwarewartungProgrammbibliothekHochdruckHalbleiterspeicherLineare RegressionNeuroinformatikOffice-PaketSystemplattformVollständigkeitGlobale OptimierungInternetworkingTexteditorDifferenteDimension 3Fahne <Mathematik>Open SourceImpulsSchnitt <Mathematik>CASE <Informatik>Mapping <Computergraphik>SelbstrepräsentationStellenringThreadComputeranimation
UMLComputeranimation
Transkript: Englisch(automatisch erzeugt)
The third dimension for open layers, it's also about the community, it's an open source project,
it's in the open layer organization and it's driven by your community, it's not a company project. Hello everyone, I'm very happy to be here with you and my name is Guillaume Beraudot, I'm the OLCSM maintainer for almost 10 years now.
I work at Camp2Camp on projects involving open layers and CSM. If you look on the right, you will see it's how I look like in GitHub.
So if you look for me on GitHub, it's me. Now you know it. To really understand, let's go on how it looks like when you are not using OLCSM. So in the center you have your application and this application is using open layers on the left and CSM.
The problem with that architecture is that you have a lot of duplication. So imagine you have a point, you want to bring your point to your screen, then for open layers you need to create a feature, add the feature to a source and this source in a layer
and then define some styling and it ends up on your screen. And if you want the same on CSM, you need to do duplicate work. You create what they call a geometry or an entity, put it in a data source,
define the styling the same if you want the same thing, and then it displays on your globe. So that's not really optimum. Really there is this duplication of code, you really don't want that.
And it's custom code, so you write some code that is specific to this application. It's code spaghetti, you get code everywhere, dealing with CSM, you don't want that. Also you have more things to do. Of course you want to see the same thing in 2D and in 3D,
then you need to synchronize the view, you need to remember your maps, and now if you have layers that are dynamic, then again you need more work. So we thought about that almost ten years ago and we came up with this solution.
So we rewind everything and we start again from the start. We have the application, it's using Open Layer and it's nice, it works like you want. Don't modify anything. Now we add all CSM. So we add the dependency, we pass it your Open Layer map,
and then all CSM will look into it and it will do the work of creating a one-for-one matching 3D globe with CSM. It's automatic in the good case.
What's really interesting, of course it does the thing for you, so that's very nice, it's quicker, but that's not the most important thing. The most important thing for me is that we are passing from custom code and spaghetti to a generic code. The code that is created into all CSM is generic.
Before we had specific code for every application you wrote, you would write some specific code. Now with this solution, the code that is in all CSM is generic, it works with any application. So it's reusable and it hides you all the math for the magic.
It's done in one place. It's external to your application. Your application becomes easier, cleaner, simpler. So it's ten years ago, now I'm looking back and thinking, is all CSM the good design?
Is it doing what we expect from it today? And really, as maintainer, I really thought about that, and I really think the design of all CSM is a good one. So like I explained, something really separate, thinking about how to handle any application,
and also in a generic way, in a flexible way. So it's not depending on any UI framework, it's OpenLayers and CSM and that's everything.
It's not forcing you on some specific OpenLayer version or some specific CSM version. It supports a wide range of OpenLayer version, of CSM version. You, as a user, is providing it, you provide the OpenLayer version you want. It can be a fork, it can be anything in the range supported, and it works.
The same for CSM, you provide what you want, you can have extended CSM, you just provide it, it's super simple. And this, I think, is really killer feature of all CSM. The other point is that it does a lot of things automatically, that's very nice, but sometimes you want more,
you want something more special. And then you can see all CSM as a toolkit. So inside all CSM, there are many things, and it's just a library, it's a JavaScript library. You just depend on that and you go and pick the path you want.
You want just the transformation of vector data from OpenLayer to CSM, just pick that and you will only pay for that. If you want to have the synchronization of the view, in anything, any other situation, just use that. So it's extremely flexible.
Ten years ago, OEL was very good at 2D, CSM was very good at 3D, and I think that nowadays it's still the same, in the same situation. OpenLayer has evolved a lot, it can do many more things. We are coming back to WebGL, so it's really alive and it's really going forward.
CSM is really the same, very alive, a lot of the dynamic, it's really the library you want if you want 3D tiles, if you want terrain, if you want navigation, that is not kind of a pseudo-2D issue.
You really want 3D navigation, you want immersion, you want CSM. What should we do? Now, what's the work to be done as a project? Of course there is the basis of everything,
so that's what has been done since the beginning of the library, is making sure that it works with new version of OpenLayer and new version of CSM. I don't remember, but OEL CSM, it was created with OpenLayer 3. Olivia explained, we are now OpenLayer 7, a few major versions, it still works.
It works with OpenLayer 7, it also works with OpenLayer 6, it's very flexible. Not anymore with the 3, I think. For CSM, you may know that there is a new major version every month. Every month, the first day of the month, it goes out and we have some breaking changes or anything.
I think CSM is now version 100, 110 maybe, something like that. And we support from CSM 60, I think.
So it's really up to you, what you want to use, or what you have to use because of overconstraints. But we also want to support the latest. Then there is the code itself. It's normal code, it's JavaScript.
It started with Closure Compiler, it was typed, everything. Then we moved to plain JavaScript ES6 modules. And now we would like to go to TypeScript. I think that TypeScript is really the way to have good and maintainable code. We want to have the code of the library in TypeScript.
We want to publish type. It's really how people nowadays work, what they expect from a library, is to have code completion, the documentation directly inside the editor. We want to do that.
It's 10 years ago, so we moved to the new stuff, but we didn't really remove the whole thing. So we are still supporting Internet Explorer 11 or this kind of thing. I think now it's enough about that. We want to focus on ES6 platform.
So everything that is before ES6, we want to remove that in the future. And like we saw just before, Olivia showed there is a lot of things happening in OpenLayers and new features coming.
It would be very great if a newer OLCM version could introspect these new features and create equivalence into Sezium automatically, or at least to have all the things to help you do that.
So I don't know, for example, there is geotiff in OpenLayers. We could have the same in Sezium automatically. That's also depending on you. What do you want? What do you need? And come in, contributing what you rely on and what you expect.
Another interesting thing is vector tiles. So OpenLayers is supporting vector tiles with some limitations, but also with some very good points like local projection. It does work with OpenLayers. There is work also to have it more speedy with WebGL.
That's ongoing. But still it's useful. At Game2Game, we are using it for several years for some clients. We are using the OpenLayer renderer, vector tile renderer, to render vector tiles into Sezium. You may know Sezium doesn't support vector tiles.
Mapbox vector tiles is just not part of Sezium. But we add that to Sezium. So today it's really a simple one. We only do with a subset, just lines. We use that for rendering a road network, a hiking network.
It's definitely possible to do that for the full range of styling and capability of vector tiles supported in OpenLayer. The goal is really to have the same thing in 2D,
in your 2D map with OpenLayer and in Sezium. If you use the same renderer, that's just the best you can expect. There was also work on the client-side raster representation. I didn't push that very much at that time. I don't remember there was some corner case not working.
So just put that on the side. Today I'm really thinking that could really help people, people using OpenLayer maps. Often they are using local projection. Clearly they don't have to do something special for their Sezium.
And it reasonably goes to 3D, that would be really cool. So I don't know if something that you have a problem with, but if it is, just come in, just discuss, let's discuss that together. Let's find the financing and the momentum to move forward
and to evolve for everyone. Yes, that's why I put also the three points. It's all open. It's a community project. There is no company really behind that.
It's open to your community. It's you. So just come in with your needs and it's how open source works. Everyone has different needs. Everyone participates to the project and it benefits to the community. The community.
All Sezium is really popular. I don't do a lot for that, but it's just popular. And if you go on GitHub, you'll see there are so many stars, so many forks, so many people watching it. And it's used broadly.
We have just in GitHub, it's saying 63 dependent projects. We have a few contributors. Of course, the main contributors are not so numerous, but we have contributors, not much sponsored, so Camp2Camp is doing a lot, but we could have more.
Well, that's a fact. It's really popular. This year, we organized a code print. Actually, it was the first code print of all Sezium,
and it was done in B.C.D., in the Camp2Camp office, as part of the OGC and OSGO code print. We had a big team. There were nine persons in the whole Sezium team. I was very surprised, so much interest. And we worked on a few things that were interesting.
So here are the people that worked on it, and what they did was starting working on this TypeScript migration, the longstanding extrusion feature that was asked by someone. Yeah, it was implemented. It was not that hard, actually.
We worked on newer versions of Sezium. There was some regression in Sezium, so we fixed that, fixed the example. We did some memory optimization. We did thread work on the memory optimization, added on the examples, pedo on the extrusion,
vlad on the TypeScript migration. And me trying to help everyone get into it. My goal, really, as a maintainer, is not anymore to really work, to do all the work, but it's to be welcoming,
to give everything I can to the contributors, to help grow the community, and make it easy to come and contribute to all Sezium. For that, what I want to do is to enable GitHub discussion. Now it's possible to have discussion directly in the open,
directly in the project. I want to enable that. I want that all discussion we have, it's in the open. I want we have regular meeting, that the community can meet together. We had this whole Sezium footprint, it was very great, and really thinking we need to have regular face-to-face,
even if it's online, with the community. Kind of a scrum. We use some review regularly, where we do a summary of what happened, when we are transparent about it. I want better getting started documentation. We didn't move it from 10 years ago.
I think it needed good documentation. I think it will come with TypeScript migration. I would like we have examples directly editable live, so deployed example, you click on the button, and you are in the content, something like that, and you can experiment and do stuff
without having to do complicated stuff. Exactly like in Open Layer. And I would like we really try our best to flag issues as good first-time contribution, so that it's easy to get into the project and to contribute something.
Voilà. I'm Guimberdo. OLCGEM is Third Dimension for Open Layer. It's a community project. It's your project. I really welcome you, and I'm listening for your question now.