Okay, hello everyone, does that work?
Yeah.
Okay, so I have to speak out.
Okay, so I'm really happy to be here.
It's my first time at Phos Dam, so I'm a little bit nervous.
It's going to be fine.
I'm going to talk to you about Open Layers, which has been mentioned about it in the Phos.
That's great.
So, a little bit of introduction about myself.
My name is Olivia.
I work at a company called Camp for Camp.
A few words about Camp for Camp, so it's a service company.
It does geospatial as well as other stuff.
It's for structure and hosting, space in Switzerland, France,
and Germany, and we're about 200 people.
It's a great company that does a lot of open source,
and the allow me to be here, so it's great.
And I have been working on the Open Layers project for three years now.
I contributed to some stuff.
I touched a bit of everything, but mostly the WebJair Ranger stuff,
which we're going to talk about later.
And you can reach me out and get up,
and go to the Blue Sky, and it's my email address.
So, right, just a quick question first.
Who here has used Open Layers before?
Okay, let's get it out of the plate.
So, okay, I'm really happy that the others will be able to discover it.
So, Open Layers, it's a JavaScript library for doing interactive maps on the web.
There's other open source libraries around.
It's the main open source libraries are leaflets, map library, and open layers.
But the Open Layers have been around for a long time.
The first version was out in 2006, actually I checked.
It was rewritten from scratch in 2013,
and it's constantly evolving and improving,
and I think that's really important.
The codebase is very healthy, it's kept up to date.
It's very well tested, also, which is important.
You can use it by doing npm install oil, so it's an npm package,
and come back to that a bit later.
Quick screenshot of the GitHub repository.
So, the website, the code source is hosted on GitHub,
Open Layers, slash Open Layers.
And you can see here, there's...
So, it's been around for a while, so we have a lot of stars,
it's a bit of a vanity metric, a lot of commits.
The license is BSD2 class.
We have almost 90 open per request.
So, this number is increasing, that's time.
I just talked about half of that, so the community is active,
but there's more, I guess it's a growing interest in it.
So, it's good, but it's a little catch up.
So, Open Layers has the reputation to be quite big library.
Probably people have called it bloated at times.
The important part, the important thing to understand is that
Open Layers, every feature is placed into separate modules.
So, you know, there's just one package, which is,
I think, a package, which is oil,
but if you only import the features that you need,
it won't have too much of a burden on your code.
That's really important.
I mean, there should be three shaking happening.
So, if you don't use all of it, it can actually be quite light.
And the reason for this is that contrary to leaflight, for example,
Open Layers does not expect you to rely too much on a plugging ecosystem.
There are extensions and plug-ins out there, and some of them are really good,
but the library is thought to have all the main features inside
and maintained in the core code at the same level of quality.
Let's look at some stuff that we can do with the library.
I want to cover a few topics.
I won't have too much time to dive too deep.
So, I'll just cover a few stuff, and then you can look for yourself afterwards.
Vector data, oh, that looks, that works.
So, you can see here, this is an example,
a basic vector layer example.
This is a big geogation data set of the world.
And I can pan around zoom in zoom out, works great.
This example actually used the WebGA renderer.
The way we define styles in Open Layers.
So, I want to talk a bit about this.
If you used Open Layers, maybe a few years ago,
you might have used the mainstream styling API,
which where you instantiate style objects,
and it's very valuable, it's quite complicated.
I also utilize a lot on style functions.
We introduced a couple of years ago,
I think, the concept of expression-based styling.
So, instead of defining its complex styling objects
and functions that are evaluated all the time,
you can just give it a set of rules of styling rules.
And I hope this is readable, maybe not that much,
but so, each rule has a filter and style properties.
So, the filter lets you select which objects
will be affected by that rule,
and then the style properties will be for these objects.
This is very important move,
and we really recommend people to use that.
And a very important part of this is that filters
and style properties can be, so here it's just a color,
but you can also have expressions,
so expressions for filters and for style properties.
And this way, you don't have to rely on style functions anymore.
You can define the style using these expressions.
It's a very powerful system.
It's not very easy to use at first.
We actually got most of the inspiration for the map library,
a style specification, which also use these kind of expressions.
If you use these kind of styling,
you will be able to have better performance.
For instance, if you want to use WebJair rendering,
you have to use these, you can choose style functions.
This is another example of vector data using WebJair,
and you can see here, we apply a filter that actually changes along the line,
according to values along the line.
So we can change the filter dynamically,
and then have the lines randomly differently.
We also have colors changing along the line.
I think it's a very interesting example of what we can do
with this style expressions, which we couldn't do before.
Vector data, you can also render it using clusters.
It's pretty good.
You have also a heat map.
And then let's move on to type data.
So, open yours, loves type data.
Obviously it's very efficient for rendering.
It comes in many different types and shapes.
The most simple type data is image size.
So you can see here, you have a map size,
come from IGN in France.
So, open yours, we'll just load the ties at the correct zoom level,
and stitch them together, and that's all working well.
Here, you have an example that shows vector ties.
So, same principle, here the vector ties,
sort of being images are, you know, bunches of geometry isn't them.
And here they're not tied.
So you can see kind of what's looking,
how it looks inside the vector tie.
But most of the time, you would want to tie them, obviously.
Open errors has a lot of logic for loading ties,
you know, the right ties at the right time.
And you can see here, there's an animation,
and I'm moving, animating the view from a burnt brothels.
And why the view is animating, you know,
the ties that are shown change along the way,
and the pioneers try to find the best tie for the best zoom level,
so that the map stays crisp and readable.
There's a tie queue system, you can change the side of the tie cage.
This is all very elaborate.
Tie data is distributed across the categories,
and I just want to mention this,
because oftentimes we see ties on the web mechanism,
which is a total tie grid, right, the world is square,
and we split it by two and two.
But a tie grid can be anything,
it can be different projections,
it can be just over a certain area,
and the operators has no assumption of the tie grid that you use.
Operators also will handle devices with higher pixel density.
So typically mobile devices,
how can I have like two, three, four, and more DPI's.
And then the library will try and load the right ties,
you know, use the higher quality ties,
it's available, and it's kind of things.
Again, so that it stays very crisp on your screen.
Vector ties also have decluttering applied to them.
So typically if you have vector ties with the labels,
you might not want to show all the labels at the same time,
because they will be unreadable.
So decluttering happens,
and this is also a very elaborate system
where you can change a lot of things.
Rusted data.
So Rusted data typically comes from satellite imagery,
also like draw on other kind of photography.
And what you can do in open areas,
you can actually, you can give the library raw Rusted data
and render it in different ways.
Here we use a geotip file,
and then we compute on the fly the NDVI,
so the normalized difference.
And to do that, we use again an expression.
So here you can see,
we're creating a tie layer, which is for image ties.
And this tie, instead of being for vector data,
it just has a color property,
and here we give it an expression.
And this expression computes NDVI,
NDVI, and the WI,
and assigns it to the different channels.
This is all done.
This is all done on the client, right?
And that means that you can just decide,
you know, give the raw data to open areas
and decide how to render it.
For example, here this data comes from Sentinel2.
Here we're just assigning the visible color bands
to the color channels, right?
So red bands goes to random, et cetera.
But we can also switch the styling
and have the red channel be the infrared band,
and the other channels be something else.
And then you can again, on the fly,
you can just change the way the data is showing on a map.
Open layers has a support for many different kinds of protections.
This is also very important in the library.
When you create a map by default,
it's going to be web macator,
it's like a sensible default.
But you can give it really anything
that's supported by Prosh for.
And here, for example, this is the map of the world
using mall-vider projection.
You can have many other curve projections.
You can have polar projections and this curve things.
And this is very important also.
I want to emphasize in open layers.
You have the concept of the view projection, right?
You decide what, how your map will be rendered
with which projection.
But you also have the projection of your data.
So if your data comes from a different projection,
an open layers will mostly,
most likely be able to convert it on the fly.
If it's vector data, it will transform the curve vector coordinates.
And if it's raster data,
it will also be able to distort the images
so that it matches the projection.
Right. Another addition that was done
pretty recently, that's recall, it's a flow layer.
So it's a web-gear rendered layer.
You can give it a grid of values
typically coming from a weather data.
And then the layer will interpolate between those values
and then make a field out of it.
And then simulate particles going over it.
It's pretty common visualizations,
but no, it's built in the library.
You can have many different formats in open layers.
Just a quick list.
Yeah, anywhere.
I'm just going to spend some time on this.
There's many different sources.
Operators knows about OGC API standards.
So map and vector ties.
Classic OGC protocols, WMS, et cetera.
Sentinel hub also is a source now.
Pianties.
You can use Google Maps if you have a key.
Stay the maps.
Cloud Optimized Geotif is also a data source.
The way it works is when you create a layer.
You have to assign it to source, right?
You have different kind of layers, different kind of source.
And you kind of make that work together.
I'm not going to have different control interactions.
Again, I'm not going to spend too much time on this.
Classic to draw interaction, select, modify.
You can rotate the view, full screen, scale bar,
double gratical, and these kind of things.
This is an example of a draw interaction.
That uses tracing, which I think it's really nice.
So you see here, you're going to draw a shape.
And I think that would be cool to draw a draw.
And then you will have this kind of snapping
where it will follow a shape.
And that's really useful if you have complex shapes.
This is also something that the draw interaction can do for you.
Operators has first class mobile support.
So I talked about pixel density.
But also like when you create a map by default,
you will work on mobile.
So you can interact with the fingers.
You can zoom in, zoom out.
You can rotate them up and stuff things.
It's really first class support.
How to use the library?
So this is what it looks like.
Create a map.
It's just a pretty simple example.
And actually, most of it will be much more complex than that.
You just do the general concept.
You have a map which contains layers.
Layers have sources.
And then a map has a view.
The view lets you center on objects.
The view are very useful functions.
If you want to center on an object.
If you want to animate the view.
Compute an extent.
And this kind of things.
And then you set up controls.
And interactions.
The NPM package is called OEL.
It comes with type definitions.
So openness is written in JavaScript.
But it has JS documentation.
So it's a type library.
And you get type free support.
If you use NPM style while we get the latest table version.
You can use a dev.
If you want to have the latest version on main.
That can be really useful.
If the features have not been released yet.
The main version is really very stable.
That might be a few bugs.
But that haven't been fixed yet.
Or breaking changes.
But most of the time you get to go.
That's a very extensive example.
List on the website.
So openness.org.
And latest examples.
I usually suggest people to start with this.
It's a very, yeah, it's like 258 examples.
There's an example for almost every feature.
And if you're not sure if the library can do something.
Or what it looks like when it runs, then just take a look at the example.
And you should have your answers.
There's an API doc as well.
Recently, we came up with something interesting.
We created a website for doing benchmarks.
And that's because in the past year and a half sort of we tried.
Improving the performance of vector data rendering.
As much as possible, we invested a lot of time and energy in this.
And together, an idea of how good the library was getting.
We came up with these benchmarks.
So these benchmarks have different cases, right?
Rendering polygons, rendering lines, etc.
Rendering vector ties.
And for each case, you have like these shapes showing up.
And you can change all the parameters.
And increase the number of shapes.
And see how far you can push the library.
And by doing this, we try and find the soft limits of the library.
And that's a very good indication of, you know,
should we improve this part of the rendering further or not.
You can switch from WebJair.
You can switch on or of WebJair rendering.
And you can also, there's a performance tracker,
which lets you give you an idea of what's going on at each frame.
And this is, I mean, this is very interesting for us when you try to improve the performance.
But I think it's also interesting.
You can take a look at it if you want to have an idea of how the library runs.
And what performance you can expect from it.
So the website is open.org-bench.
And you can also change what would different pass versions
and see how the effects that's pretty cool.
So we worked it out on the performance of vector data.
And that's mostly done through WebJair rendering, which I talked a little bit.
Just a few words to say why I think this project is important
and why I care about it very much.
So I mentioned the other open source libraries, my library and leaflet.
I think each library has their strong points and weaknesses.
The thing is, opening it is really, it's not easy to use.
I mean, it has a bit of a complexity, but you can do, you know,
really, pretty much anything.
It can throw pretty much anything at it and it will render it.
It's completely agnostic to the source providers,
data providers, you know, the kind of data,
can be tied data or not, many different formats and projects.
The project is not owned by a company.
It's a true community project.
And I have to say, it's a very neutral project.
Because, you know, there's no assumption about anything.
So, yeah, I said, like Western assumptions,
because you can use it in different projections, different parts of the world.
We have regularly Chinese users, I think showing up at the GitHub,
which makes communication a bit hard,
but I think that's a very interesting thing.
Also, a good example is text rendering on the map,
because we rely on the text rendering of the browser.
It means that text can be anything.
It doesn't have to be our alphabet, can be right to left.
You can be different characters and these all works really well.
So, yeah, so just a quick word to say that,
if you want to help, you welcome, you know,
go to GitHub.
You can try it out.
If you find a bug, please report it.
And if you want to try your candidate, please try and open the poor request.
And people will help you out.
No worries.
Yeah, that's it. Time for questions.
Okay.
Okay, so you put requests when was it opened?
Before what?
Okay.
Right.
So, also, keep in mind that people sometimes use their own time to work on this.
So, you know, basically what you try and do is say,
yeah, okay, I'll have to get it.
I can, I can, I can, yeah.
It's very great.
Yeah.
You're saying, like, obviously, open this has a lot of functions.
And maybe, or like, in reference to something like,
if there's a lot of stuff that she's been saying,
directly to open this.
Right.
How to, like, the main thing is to size, like,
what to, what should be included in the poor library and what to, like,
you know, potentially popular to, like, a bug game or just some external credit,
like, it's there.
Is it, how does that discussion happen?
So, the question is, how do maintenance decide what gets,
put inside the library or what maybe is left for other plugins to do?
I think the library tries to have as many,
200 as many providers and formats as possible.
So, you know, if there's something coming up,
and, for example, the OGC API standards, then, you know,
they became more stable and then they were supported in the library.
When it comes to functionality, more like high level stuff,
like interactions or complex drawing, things, for example,
then usually it will be like, maybe, you know,
people can do that in other extensions or in their application code.
The interaction stuff stays quite low level, I would say.
Yes?
So, how is the interaction done?
Is it only, like, going with the logic cable,
can you create a piece of the coordinates to,
and go by?
Okay, the question is about drawing, right?
The drawing interaction, how can you,
so the default drawing interaction, again,
you can click, set a vertex at every click.
You also have a free-hand mode,
but you can also programmatically push coordinates.
And that's what we do in the trading stuff, right?
When you snap to a polygon, then we push coordinates without clicking.
If I have a map that I just want to eat it today,
if I want to, if I want to trap objects on a map,
right?
I don't know, probably not, like, okay,
so if you want to feel your map with data,
you don't need to do, like, interaction is really when it comes to,
like, the user doing something,
but if it programmatically, you want to push objects in your map,
then you don't need interactions.
You basically push data on your source at the source level,
and then it shows up on them.
Yeah?
Can you share about how you do performance testing on mobile devices,
like, constraints in CPU, RAM, or, in cases of,
like, that network, or, you know, a critical out, you far away,
or, like, how do you do that?
Okay, so about performance on mobile.
So network, you can do a flying stuff with open layers,
but it's not really handled by the library.
You know, if you push the data into its source,
if you're offline, or online, actually the library doesn't really care.
The library tries to be as light as possible on battery.
This benchmark website is also,
it can also be used to test stuff on mobile.
So, yeah, basically, yeah.
But, I mean, for a long time, we just,
we don't have any problem metrics, right?
We will just try and stuff, you know,
like, try the examples on your mobile,
or use a simulator or something.
But, no, we try to have better metrics.
Oh, no.
Okay.