We're going to go next speaker.
Okay, hello everyone.
Does that work?
Yeah.
No?
No.
The light is either fine.
It doesn't work.
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 going to be nervous.
That's going to be fine.
I'm going to talk to you about Open Layers, which has been mentioned about it as a talk.
So that's great.
So a little bit of introduction about myself.
My name is Olivia.
I work at a company called Camster Camp.
A few words about Camster Camp.
So it's a service company.
It does geospatial as well as other stuff.
It's for structure and hosting.
It's based in Switzerland, France and Germany.
And we're about 200 people.
It's a great company that does a lot of open source.
And you know, they allow me to be here.
So it's great.
And I have been working on the opening of this 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 our blue sky and it's my email address.
So, right.
Just a quick question first.
Who here has used open layers before?
Okay.
It's quite a lot of great.
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 pretty 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.
I 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.
And you can see here.
So, it's been done 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 clause.
We have almost 90 open per request.
So, this number is increasing.
The last time I do talk was half of that.
So, the committee is active.
But there's more.
I guess it's a growing interest in it.
So, it's good.
But it's also hard to 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 split into separate modules.
So, you know, there's just one package, which is,
I think a package, which is well.
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 tree shaking happening.
So, if you don't use all of it, it cannot actually be quite light.
And the reason for this is that contrary to leaflet, for example,
open layers does not expect you to rely too much on a plugging ecosystem.
There are extensions and plugins 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 of 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, I actually used the WebGA renderer.
The way we define styles in open layers.
So, I want to talk about this.
If you use the paneers, 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.
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 quite, it's very powerful system.
It's not very easy to use at first.
We actually got most of the inspiration for the map library,
style specification, which also use these concept expressions.
If you use this kind of styling, you will be able to have better performance.
For instance, if you want to use WebJair rendering,
you have to use this, 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 render 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 standard.
You have also a heat map.
And then, let's move on to type data.
So, opinions, 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 types.
So, you can see here, you have a map types,
come from IGN in France.
So, opinions will 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, instead 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 a vector tie.
But most of the time, you would want to tie them, obviously.
Oppenirers has a lot of logic for loading ties.
You know, the right ties are the right time.
You can see here, there's an animation, and I'm moving,
animating the view from Burnt Brussels.
And why the view is animating, you know,
the ties that are shown change along the way,
and Oppenirers 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 size of the tie cage.
This is all very elaborate.
Tie data is distributed across tigrades,
and I'll just want to mention this,
because oftentimes we see ties on the web-necitol
tigrade, right, the world is square,
and we're split it by two and two.
But a tigrade can be anything.
It can be in different projections.
It can be just over a certain area.
And Oppenirers has no assumption of a tigrade
that you use.
Oppenirers also will handle devices with
higher pixel density.
So typically mobile devices,
how it can have like two, three, four, and more dpi.
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 apply 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 Oppenirers,
you can actually, you can give the library raw Rusted data
and render it in different ways.
Here we use a geotif file,
and then we compute on the fly the NDVI,
so the normalized difference.
Vegetation index.
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 and DWI
and assigns it to the different channels.
This is all done.
This is all done on the client, right?
It's on the fly.
And that means that you can just decide,
you know, give the raw data to Oppenirers
and decide how to render it.
For example, here this data comes from Sentinel2.
Here we're just assigning,
you know, the visible color bands to the color channels,
right?
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 know, you can, again,
on the fly, you can just change the way
the data is showing on a map.
Oppenirers 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,
like a sensible default.
But you can give it really anything
that's supported by Prash4.
And here, for example, this is the map of the world
using mall-vader projection.
You can have many other kind of projections.
You can have polar projections and these kind of things.
And this is very important also.
I want to emphasize in Oppenirers.
You have the concept of the view projection, right?
You decide what, how your map will be rendered
with width projection.
But you also have the projection of your data.
So if your data comes from a different projection,
an opening is mostly,
most likely be able to convert it on the fly.
If it's vector data,
it will transform the core 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 previously,
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 a common visualization,
but no, it's built in the library.
You can have many different formats,
and open layers.
Just a quick list.
Yeah.
I'm just going to not spend too much time on this.
Many different sources.
Operators, no support,
OGC API standards,
so map and vector ties,
classic OGC protocols,
WMS, et cetera.
Sentinel hub also is a source now,
PMTIs.
You can use Google Maps,
if you have a key,
state in Maps,
Cloud Optimize 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,
the vertical,
and this 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,
in terms of draw.
And then you will have this kind of snapping
way, it will follow a shape,
and that's 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,
it 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 it will be much more complex than that.
It's just the general concept you have a map,
which contains layers, layers of 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,
which is done before.
It comes with type definitions,
so open-airs is written in JavaScript,
but it has JSDoc annotations,
so it's a type library,
and you get type flip support.
If you use NPM instead of where we get the latest table version,
you can use OEL adev,
if you want to have the latest version on main,
that can be really useful
if the features that have not been released yet,
the main version is usually very stable,
that might be a few bugs that haven't been fixed yet,
or breaking changes, but most of the time you get to go.
There's a very extensive example list on the website,
so open-airs.org eann 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,
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, 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,
rendering polygons, rendering lines, etc.,
rendering vector ties, and for each case,
you have this 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 basically by doing this,
we try and find the soft limits of the library,
and that's a very good indication
of should we improve this part of the rendering further or not.
You can switch from WebGL,
you can switch on of WebGL 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 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 operative.org-bench,
and you can also change it with different past versions,
and see how it affects that's pretty cool.
So we worked a lot on the performance of vector data,
and that's mostly done through WebGL 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, it's not easy to use.
It has a bit of complexity,
but you can do really much anything.
You can throw pretty much anything at it,
and it will render it.
It's completely agnostic to the source providers,
data providers, the data,
can be detailed 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 there's no assumption about anything.
I said Western assumptions,
because you can use it in different projects,
different parts of the world.
We have regularly Chinese users,
I think showing up at the GitHub,
which makes communication 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.
You can be right to left.
You can be different characters,
and these all works really well.
So, yeah.
Just a quick word to say that,
if you want to help,
you welcome to GitHub.
You can try it out.
If you find a bug, please report it.
If you want to try your candidate,
please try and open a pull request,
and people will help you out, no worries.
Yeah, that's it.
Time for questions.
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 look at it.
I can say, yeah.
It's very great.
Yep.
You're saying, like, obviously, open this,
has a lot of function.
Maybe, or, like, in reference to something like,
if there's a lot of stuff,
it should be in the same direction to open it.
Right.
How do you, like, the main thing is to size,
like, what to, what should be included in the pull library,
and what to, like, you know,
potentially,
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 OGCAPI standards,
then, you know, they became more stable,
and then there was supported in the library.
When it comes to functionality,
it's 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,
you know, 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,
what is the interaction done?
Okay, the question is about drawing,
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-and-mode,
but you can also programmatically push coordinates.
And that's what we do in the tracing stuff, right?
When you snap to a polygon,
then we push coordinates without clicking.
Yeah, but we think, if I have a format,
then I just want to eat it here.
If I want to trap objects on a map.
Right?
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 you programmatically 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 the map.
Yeah?
Can you share the words,
how do you do performance testing on mobile devices
in their, like, constraints in the CPU,
or RAM, or in cases of, like,
that network, or, you know,
with your mobile device, or,
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 a source,
if you're offline, or online,
actually the library doesn't really care.
The library tries to be as light as possible on, 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 didn't have any proper metrics, right?
We were just trying stuff, you know,
like, try the examples on your mobile,
or use an emulator or something.
But, no, we tried to have better metrics.
Yeah.
Okay.
Thank you.