WEBVTT

00:00.000 --> 00:10.400
So, hi. I'm Bart. I've been working for my

00:10.400 --> 00:14.200
believer for the past three years as a maintainer.

00:14.200 --> 00:16.200
Frank, do you want to introduce yourself?

00:16.200 --> 00:19.400
Hi, I'm Frank. I'm on the governing board.

00:19.400 --> 00:22.800
He's not only on the governing board, he's also a maintainer

00:22.800 --> 00:27.000
for Martin, a tile server, so we're in very good company to be

00:27.000 --> 00:31.000
talking about tiles today.

00:31.000 --> 00:36.000
So, this week we announced a map labor tile.

00:36.000 --> 00:42.000
It's a new tile format, and yeah, we're going to smooth into it

00:42.000 --> 00:45.000
for the people that don't know what map labor is.

00:45.000 --> 00:48.000
Maybe don't know what vector tiles are.

00:48.000 --> 00:50.000
We give a quick introduction here.

00:50.000 --> 00:54.000
So, if you're not familiar with map labor,

00:54.000 --> 00:58.000
these are two main libraries.

00:58.000 --> 01:02.000
There are map tool kits. You can use them to add maps to your apps,

01:02.000 --> 01:06.000
either to your web apps or to your native apps.

01:06.000 --> 01:10.000
I've been maintaining it for the former, so map labor native.

01:10.000 --> 01:14.000
Now, map labor started out as a fork when

01:14.000 --> 01:18.000
map box closed source to their client libraries.

01:18.000 --> 01:23.000
And this is good to keep in mind because I think a lot of projects here

01:23.000 --> 01:28.000
had fuzz them. They have been open source from the start.

01:28.000 --> 01:35.000
So, they have their initial creators are still maintaining the library.

01:35.000 --> 01:38.000
So, they have a huge history, right?

01:38.000 --> 01:43.000
And we needed to start without that institutional knowledge.

01:43.000 --> 01:47.000
We needed to figure out how are we going to organize ourselves.

01:47.000 --> 01:52.000
We even needed to dig into the code base to understand how we can extend it.

01:52.000 --> 01:56.000
And we've been doing that over the years.

01:56.000 --> 02:01.000
So, one of the things we did in the beginning

02:01.000 --> 02:06.000
is we set up an organization to help support the software projects

02:06.000 --> 02:09.000
that handles the sponsorships and donations.

02:09.000 --> 02:14.000
We've actually been quite successful getting sponsorships.

02:14.000 --> 02:20.000
Because a lot of companies, they were deeply dependent on the map box libraries

02:20.000 --> 02:26.000
and they wanted to continue using open source.

02:26.000 --> 02:31.000
So, we've been even been able to hire a few people, including myself,

02:31.000 --> 02:34.000
to maintain these libraries.

02:34.000 --> 02:36.000
Now, we also have a board.

02:36.000 --> 02:40.000
Of course, we have a huge community of contributors.

02:40.000 --> 02:43.000
We have some other projects under the map labor umbrella

02:43.000 --> 02:47.000
and they mostly work these subcommunities mostly work independently.

02:48.000 --> 02:51.000
But we do try to get together once every month.

02:51.000 --> 02:54.000
And also, if you're an active contributor,

02:54.000 --> 02:58.000
you can become a voting member to vote on the board.

02:58.000 --> 03:01.000
So, these are the developments over the years.

03:01.000 --> 03:04.000
One of the first milestones was the rewrite of the map labor

03:04.000 --> 03:06.000
geologists and typescript.

03:06.000 --> 03:10.000
The first board and the first sponsors in 2022.

03:10.000 --> 03:15.000
And the graphics back ends, new graphics back ends

03:15.000 --> 03:18.000
from up to the native globe mode, from up to the web,

03:18.000 --> 03:22.000
and the recent milestone of the project is MOT.

03:22.000 --> 03:25.000
So, let's talk about vector tiles.

03:25.000 --> 03:29.000
What are vector tiles and why would you want them?

03:29.000 --> 03:34.000
Now, you're probably familiar with Raster-based maps.

03:34.000 --> 03:38.000
Raster-based maps are basically just a bunch of images

03:38.000 --> 03:40.000
that are stick together on the client,

03:40.000 --> 03:43.000
which means you have a very simple client.

03:44.000 --> 03:47.000
Now, on the other hand, vector-based maps,

03:47.000 --> 03:51.000
you send the raw geometric data to the client

03:51.000 --> 03:53.000
along with some styling information,

03:53.000 --> 03:56.000
how to draw those geometries.

03:56.000 --> 03:58.000
And you have a much more complicated client,

03:58.000 --> 04:01.000
but you get some advantages.

04:01.000 --> 04:05.000
So, one of them is that you have a lot of better UX.

04:05.000 --> 04:08.000
So, you have continuous zoom,

04:08.000 --> 04:10.000
because when you're in between two,

04:10.000 --> 04:13.000
zoom levels, it gets pixelated.

04:13.000 --> 04:16.000
You don't have that with vector-based maps.

04:16.000 --> 04:18.000
And you can do something like over zoom,

04:18.000 --> 04:22.000
where if you zoom in, you can use the data

04:22.000 --> 04:27.000
of the lower zoom level to render that zoom level

04:27.000 --> 04:33.000
to still have a very detailed picture.

04:33.000 --> 04:37.000
And you can do things like runtime styling.

04:38.000 --> 04:41.000
So, you can have a completely different looking map

04:41.000 --> 04:44.000
based on the style that you provide.

04:44.000 --> 04:48.000
And vector maps are,

04:48.000 --> 04:51.000
even a requirement for some use cases.

04:51.000 --> 04:53.000
One of them is navigation.

04:53.000 --> 04:55.000
So, you can imagine if you're navigating,

04:55.000 --> 04:57.000
you want the labels to save a top.

04:57.000 --> 04:58.000
If you turn your car,

04:58.000 --> 05:00.000
you don't want to read upside down

05:00.000 --> 05:02.000
to know what the name of this road

05:02.000 --> 05:04.000
or this point of interest is.

05:04.000 --> 05:07.000
So, vector-based maps are very dominant

05:07.000 --> 05:09.000
in an navigation space.

05:09.000 --> 05:11.000
And these are actually all apps

05:11.000 --> 05:13.000
that use map-libernative.

05:13.000 --> 05:15.000
If you go to the app story,

05:15.000 --> 05:17.000
download the random navigation app,

05:17.000 --> 05:22.000
it's very likely that it's using map-libernative.

05:22.000 --> 05:25.000
Now, let's go back for technical comment.

05:25.000 --> 05:31.000
So, this is a concept of a tile pyramid.

05:31.000 --> 05:35.000
We're relevant for both vector-based maps

05:35.000 --> 05:36.000
and vector-based maps.

05:36.000 --> 05:39.000
So, we need a way to download

05:39.000 --> 05:45.000
the vector data with the right fidelity.

05:45.000 --> 05:49.000
Of course, if we look at the whole world,

05:49.000 --> 05:51.000
we cannot encode house numbers,

05:51.000 --> 05:54.000
because there's a few to many houses in the world

05:54.000 --> 05:56.000
that make that feasible.

05:56.000 --> 05:58.000
Only when you zoom in,

05:58.000 --> 06:00.000
are you getting that data, right?

06:00.000 --> 06:01.000
We, at different zoom levels,

06:01.000 --> 06:04.000
we have different vector data.

06:04.000 --> 06:06.000
Okay.

06:06.000 --> 06:11.000
So, for the past more than 10 years,

06:11.000 --> 06:14.000
we've been using map-box vector tiles,

06:14.000 --> 06:17.000
and it's a binary format,

06:17.000 --> 06:20.000
which is, of course,

06:20.000 --> 06:24.000
much better than using something like geojason

06:24.000 --> 06:26.000
for performance reasons,

06:26.000 --> 06:29.000
and also because you can pack it much smaller.

06:29.000 --> 06:31.000
It has a relatively simple definition,

06:31.000 --> 06:35.000
so it's defined using something called proto-buff.

06:35.000 --> 06:39.000
It's a format to describe binary format.

06:39.000 --> 06:41.000
It has very wide support,

06:41.000 --> 06:43.000
and everyone has their own implementation,

06:43.000 --> 06:49.000
because it's so easy to implement.

06:49.000 --> 06:53.000
And yeah, it serves us really well.

06:53.000 --> 06:56.000
So, why do we need something new?

06:56.000 --> 07:00.000
Well, we just didn't like the name, right?

07:00.000 --> 07:03.000
Okay, now that's not actually it.

07:03.000 --> 07:06.000
The reason is, we can do better.

07:06.000 --> 07:08.000
And this is sort of the marketing pitch,

07:08.000 --> 07:10.000
and there's, of course, always a little bit

07:10.000 --> 07:11.000
of an asterix there,

07:11.000 --> 07:15.000
but we can achieve a three times better performance ratio,

07:15.000 --> 07:18.000
and a three times better decoding performance,

07:18.000 --> 07:23.000
using the latest insights of data

07:23.000 --> 07:26.000
for data compression research,

07:26.000 --> 07:29.000
because we've actually had some new insights

07:29.000 --> 07:32.000
in the past 10 years there.

07:32.000 --> 07:36.000
So, to understand why we can do better,

07:36.000 --> 07:38.000
we first have to look at MVT,

07:38.000 --> 07:40.000
and I'm handing it over to Frank.

07:40.000 --> 07:43.000
So, it's working.

07:43.000 --> 07:44.000
Yeah, it's working.

07:44.000 --> 07:46.000
So, MVT, very simple encoding.

07:46.000 --> 07:49.000
We start off with one big box,

07:49.000 --> 07:53.000
that is one tile, that is one piece of data.

07:53.000 --> 07:55.000
That data is encoded in protobuff.

07:55.000 --> 07:59.000
Okay, it contains, oh, this is not great.

07:59.000 --> 08:01.000
It contains layers.

08:01.000 --> 08:03.000
A layer can be, this is a street,

08:03.000 --> 08:07.000
this is a tree line, this is something else.

08:07.000 --> 08:09.000
That's great, that works.

08:09.000 --> 08:12.000
If we zoom into one layer,

08:12.000 --> 08:14.000
they contain both metadata,

08:14.000 --> 08:17.000
and the key dictionary, a valid dictionary,

08:17.000 --> 08:18.000
and some features.

08:19.000 --> 08:22.000
So, why do we have a key and be a valid dictionary?

08:22.000 --> 08:25.000
Very simple, because that's where we store our strings.

08:25.000 --> 08:27.000
We do string and turning.

08:27.000 --> 08:32.000
So, let's look at why this is sub-optimal.

08:34.000 --> 08:39.000
Well, first of all, this is very inefficient to render.

08:39.000 --> 08:42.000
Well, we have here movement-based geometry.

08:42.000 --> 08:46.000
We have winding order, it's winding order dependent.

08:46.000 --> 08:50.000
So, for example, if I have one geometry disk goes this round,

08:50.000 --> 08:54.000
and then inside it, it goes the other way around,

08:54.000 --> 08:57.000
then we need to cut this out.

08:57.000 --> 08:59.000
This is very inefficient,

08:59.000 --> 09:03.000
and we also need to do a test relation on the client.

09:03.000 --> 09:06.000
IE cutting up into little triangles.

09:06.000 --> 09:12.000
So, this is fundamentally failing what we want to do, fast rendering.

09:12.000 --> 09:19.000
But we also have, we only have string and turning here.

09:19.000 --> 09:21.000
It's like this here, they're great.

09:21.000 --> 09:23.000
And they're not compressed at all.

09:23.000 --> 09:26.000
If you have very long string in your Open Street map,

09:26.000 --> 09:29.000
it's going to be very large here.

09:29.000 --> 09:31.000
That's not ideal,

09:31.000 --> 09:35.000
because we're literally just having a string dictionary.

09:35.000 --> 09:37.000
Okay.

09:37.000 --> 09:41.000
So, TLDR, these were very simple to implement.

09:42.000 --> 09:45.000
This was back then the only way this could be done.

09:45.000 --> 09:47.000
It is very hard to optimize,

09:47.000 --> 09:51.000
because, frankly, these were not designed to be optimally rendered.

09:51.000 --> 09:53.000
They were designed to be simple.

09:53.000 --> 09:57.000
Well, yeah, if your tiles are compressible by three X,

09:57.000 --> 09:59.000
if you, so G-zip at them,

09:59.000 --> 10:02.000
maybe it's not a good tile format.

10:02.000 --> 10:07.000
So, let's enter MBT here, MLT here.

10:07.000 --> 10:09.000
What is MLT?

10:10.000 --> 10:14.000
It is a more efficient column oriented lightweight encoding,

10:14.000 --> 10:16.000
basically like park key.

10:16.000 --> 10:19.000
And what is column oriented?

10:19.000 --> 10:21.000
Currently, we are row oriented.

10:21.000 --> 10:25.000
So, the data is, for example, string,

10:25.000 --> 10:28.000
integer string, integer, string, integer.

10:28.000 --> 10:30.000
And that's up to more.

10:30.000 --> 10:33.000
Let's start a different way, string string string string string string.

10:33.000 --> 10:37.000
And I can roll them up, do fast FST on them,

10:38.000 --> 10:40.000
be more efficient this way,

10:40.000 --> 10:43.000
and have a more lightweight encoding.

10:43.000 --> 10:45.000
Basically, the same thing that we have been doing

10:45.000 --> 10:47.000
in databases for the last 10 years.

10:47.000 --> 10:50.000
Not like we only have been doing this in the last 10 years

10:50.000 --> 10:52.000
because back in the 2000s,

10:52.000 --> 10:56.000
we were still thinking that computers are going to get faster.

10:56.000 --> 11:00.000
So, we can also do more modern things with them.

11:00.000 --> 11:04.000
Like, for example, nested things like Jason

11:04.000 --> 11:10.000
or MLUs, or actually sucking.

11:10.000 --> 11:15.000
We can move the test relation to the server.

11:15.000 --> 11:17.000
Why is that important?

11:17.000 --> 11:20.000
Because we are currently spending when we are rendering.

11:20.000 --> 11:22.000
Most of our time doing that.

11:22.000 --> 11:26.000
We are cutting up your little polygons into triangles.

11:26.000 --> 11:29.000
That is most of the time where we are spent on rendering.

11:29.000 --> 11:33.000
We are not using a protobuff.

11:33.000 --> 11:36.000
We are rolling our own encoding because we think we can do it better.

11:36.000 --> 11:41.000
It is reasonably simple as similar to how parky is doing it.

11:41.000 --> 11:45.000
So, we start off with a size, a version, and then a data.

11:45.000 --> 11:46.000
Object.

11:46.000 --> 11:48.000
We are going to do it.

11:48.000 --> 11:54.000
It is reasonably simple as similar to how parky is doing it.

11:54.000 --> 11:58.000
So, we start off with a size, a version, and then a data.

11:58.000 --> 12:02.000
Object.

12:02.000 --> 12:07.000
And how modern encodings do we are doing this?

12:07.000 --> 12:10.000
That is that we have four, a certain class of things.

12:10.000 --> 12:11.000
For example, a string.

12:11.000 --> 12:15.000
We have many different encodings that are optimal in some use cases.

12:15.000 --> 12:17.000
This is from a research paper.

12:17.000 --> 12:19.000
This is too complex.

12:19.000 --> 12:23.000
If we ship something like this, we are going to get stranded.

12:23.000 --> 12:26.000
Like, not being able to implement all of them.

12:26.000 --> 12:28.000
Having correctness bugs somewhere.

12:28.000 --> 12:32.000
So, that is not something that we can do currently in the future.

12:32.000 --> 12:35.000
But that is the optimal way.

12:35.000 --> 12:38.000
So, what did we do?

12:38.000 --> 12:45.000
We chose the most effective encodings for the different value types.

12:45.000 --> 12:47.000
And packed them in.

12:47.000 --> 12:52.000
For example, for bullions, they can be either raw in a bitvector.

12:52.000 --> 12:54.000
Or they can be run length encoded.

12:54.000 --> 12:56.000
If you have very many bullions.

12:56.000 --> 12:59.000
Or, like, it goes all the way down.

12:59.000 --> 13:01.000
For example, bull doubles.

13:01.000 --> 13:04.000
We have ob, which is the inductive format.

13:04.000 --> 13:05.000
Or for strings.

13:05.000 --> 13:10.000
We have FSST, which is the format from Munich.

13:10.000 --> 13:13.000
Or for geometry.

13:13.000 --> 13:16.000
We are doing vertex space encoding.

13:16.000 --> 13:21.000
And then the integer optimizations, which is fairly efficient.

13:21.000 --> 13:24.000
Like, delta, early environments.

13:24.000 --> 13:27.000
And, or fast people.

13:27.000 --> 13:30.000
And, like, these all are not new things.

13:30.000 --> 13:34.000
These all have been around in the database world for a while.

13:34.000 --> 13:42.000
But, like, the geo world just hasn't picked up on these improvements in the database world until now.

13:42.000 --> 13:44.000
So, things are going to get better.

13:44.000 --> 13:45.000
Things are going to get faster.

13:45.000 --> 13:47.000
It's amazing.

13:47.000 --> 13:50.000
So, where can I learn more about?

13:50.000 --> 13:52.000
Well, thank you already.

13:52.000 --> 13:53.000
I mentioned it.

13:53.000 --> 13:57.000
Marcus Dremel, who invented the format.

13:57.000 --> 13:58.000
Pushed out.

13:58.000 --> 14:00.000
Research paper is actually published now.

14:00.000 --> 14:04.000
There's some more technical talks on YouTube.

14:04.000 --> 14:10.000
And we also published the specification, which you can find on our GitHub.

14:10.000 --> 14:15.000
Now, the elephant on the room is complexity.

14:15.000 --> 14:16.000
Right?

14:16.000 --> 14:18.000
This is a much more complicated format.

14:18.000 --> 14:23.000
And, actually, there was some controversy, which I was very happy about because, of course,

14:23.000 --> 14:27.000
no open source project is complete without some controversy.

14:27.000 --> 14:37.000
So, the tile maker, maintainer, was limiting the fact that this new format is so much more complex to implement.

14:37.000 --> 14:42.000
And, he went so far as to say that only if you're a big corporate, you can really,

14:42.000 --> 14:44.000
feasibly implement this.

14:44.000 --> 14:46.000
So, complexity.

14:46.000 --> 14:48.000
Well, what makes it complexity?

14:48.000 --> 14:50.000
Well, what makes it complex?

14:50.000 --> 14:55.000
Well, not just because you have to implement all these different encodings that Frank mentioned.

14:55.000 --> 15:04.000
But also, you cannot just put the data that you have in a tile, because you need to figure out what's the best way,

15:04.000 --> 15:06.000
what's the best encodings to choose.

15:06.000 --> 15:09.000
And these encodings, they can even differ per tile.

15:09.000 --> 15:11.000
So, you need to use heuristics.

15:11.000 --> 15:12.000
Right?

15:12.000 --> 15:16.000
So, you need to search all the different encodings.

15:16.000 --> 15:19.000
And you need to think about your trade-offs.

15:19.000 --> 15:26.000
For example, you might choose to have slightly bigger tiles because you get better decoding performance.

15:26.000 --> 15:38.000
So, or you might choose not to search this huge encoding space and have a little bit better encoding time.

15:38.000 --> 15:39.000
Now, how do we address this?

15:39.000 --> 15:45.000
Well, I was speaking to my co-maintainer, Harold, and the first thing he said was, it's not that complicated.

15:45.000 --> 15:52.000
That's his first reply to any technical problem, which is, I mean, it's a good mindset to have.

15:52.000 --> 15:55.000
Another is, MVT is not going away, right?

15:55.000 --> 15:57.000
Well, support MVT indefinitely.

15:57.000 --> 16:03.000
And if MVT works for your use case, I mean, I don't want to throw as much shade as MVT has Frank did.

16:03.000 --> 16:06.000
I think it's a great format still.

16:07.000 --> 16:12.000
And another idea is that we can focus a bit more on sharing code.

16:12.000 --> 16:20.000
I mentioned post-GA, I mentioned tip of canoe, I mentioned ductDB, they all have their own MVT implementation.

16:20.000 --> 16:28.000
And maybe we can use this concept called a library to share the implementation between different integrators, right?

16:28.000 --> 16:30.000
That's one idea as well.

16:30.000 --> 16:32.000
All right.

16:32.000 --> 16:36.000
Another question, when can I start using MLT?

16:36.000 --> 16:40.000
And the answer is always, as always, it depends.

16:40.000 --> 16:47.000
And the answer is today, if you're adventurous, because you will need to make your own tiles, right?

16:47.000 --> 16:53.000
Actually, you can use it today, because it's now supported by both Map Libre native and Map Libre GLGS.

16:53.000 --> 16:56.000
And experimental support has been added to planet iron.

16:56.000 --> 17:03.000
It's a very popular software for making tiles, it's Java based.

17:03.000 --> 17:18.000
And if you don't want to make your own tiles, you sit back and we expect the ecosystem of tile distributors, both commercial and non-commercial to catch up, and will eventually offer MLT.

17:18.000 --> 17:23.000
And AWS is actually funding further MLT improvements this year.

17:23.000 --> 17:33.000
So you can imagine this problem of finding the best encodings that will take some more development to really get right.

17:33.000 --> 17:39.000
But there's a lot of upside potential for optimizing tiles making them smaller.

17:39.000 --> 17:47.000
Now, I mentioned Map Libre, this open source project, we're not a big enterprise, and you can actually shape the future of MLT.

17:48.000 --> 17:53.000
We're active, very active on GitHub, GitHub discussions, GitHub issues.

17:53.000 --> 17:56.000
We have a Slack channel.

17:56.000 --> 18:04.000
Every second Wednesday of the month, we have a big meeting for both Map Libre libraries.

18:04.000 --> 18:07.000
And we also have a monthly meeting on MLT specifically.

18:07.000 --> 18:12.000
If you would like to be invited, everyone is welcome to join, just message us.

18:12.000 --> 18:15.000
Send us an email and we'll send you an invite.

18:15.000 --> 18:20.000
Yeah, we also put a monthly newsletter to all the socials.

18:20.000 --> 18:23.000
And you're welcome to follow us there.

18:23.000 --> 18:31.000
Now, at this point, it's good to mention that MLT came to be thanks to collaboration between both,

18:31.000 --> 18:36.000
between academia, open source, and enterprise.

18:36.000 --> 18:44.000
And we've seen this in the past with other Map Libre developments where we work together with enterprise

18:44.000 --> 18:48.000
to deliver some feature.

18:48.000 --> 18:52.000
And we're very thankful for our sponsors.

18:52.000 --> 18:59.000
And the sponsors are actually why I've been able to be a paid maintainer for Map Libre for the past three years.

18:59.000 --> 19:05.000
But I think recently, especially here in Brussels, not that we're here in Brussels, we're starting to think about

19:05.000 --> 19:12.000
some other funding modes as well, maybe apply for CMU fund or grant.

19:12.000 --> 19:17.000
So if you're a talented developer and wants to work on Map Libre, come talk to us,

19:17.000 --> 19:22.000
and maybe we can apply for one of those grants together.

19:22.000 --> 19:24.000
All right.

19:24.000 --> 19:26.000
Then thanks, thank you very much.

19:26.000 --> 19:28.000
Stand for some questions.

19:34.000 --> 19:38.000
Because it's always a bit awkward getting the first question.

19:38.000 --> 19:41.000
We actually have a question of our own.

19:41.000 --> 19:49.000
And it is, why does it even matter to get smaller tiles better the coding performance?

19:49.000 --> 19:52.000
Frank, do you want to answer that one?

19:52.000 --> 19:57.000
Well, because having a pasta map matters to real users,

19:57.000 --> 20:03.000
I can only share anecdotal evidence, but like when our software got, when our,

20:03.000 --> 20:07.000
our map got faster, we got positive feedback.

20:07.000 --> 20:08.000
Great.

20:08.000 --> 20:14.000
I think you are in India last week and in some parts of the world,

20:14.000 --> 20:17.000
people don't have the latest iPhone and the latest Pixel phone.

20:17.000 --> 20:22.000
So there it also matters a lot to have more faster tiles, right?

20:22.000 --> 20:23.000
Faster.

20:23.000 --> 20:28.000
Yeah, also in some parts of the world, we have very shitty internet like Germany.

20:28.000 --> 20:31.000
And what is the answer?

20:31.000 --> 20:33.000
And what is the answer?

20:33.000 --> 20:34.000
What do you think is the answer?

20:34.000 --> 20:36.000
And what do you think is the answer?

20:36.000 --> 20:40.000
What do you think is the answer?

20:40.000 --> 20:42.000
What are you going for?

20:42.000 --> 20:43.000
Yeah, whatever.

20:43.000 --> 20:45.000
Is this a question?

20:45.000 --> 20:46.000
Thanks.

20:46.000 --> 20:57.000
So again, on LWN, there was an article from the C-standard

20:57.000 --> 21:01.000
maintainers about implementing use case,

21:01.000 --> 21:06.000
specific compression formats or providing a tool kit to implement it.

21:06.000 --> 21:08.000
Did you already into look that?

21:08.000 --> 21:12.000
Was it too late for the specification of this format?

21:12.000 --> 21:19.000
The depth that work is, I was already done with the microphone,

21:19.000 --> 21:21.000
so I don't need to repeat that.

21:21.000 --> 21:25.000
So I think you're referring to the adaptive,

21:26.000 --> 21:31.000
yes, the extended compression where they have multiple lightweight encodings in there.

21:31.000 --> 21:35.000
And that was too new for us to look into,

21:35.000 --> 21:39.000
but also it wouldn't really fix this.

21:39.000 --> 21:45.000
Because like, the Z-standard people don't know,

21:45.000 --> 21:50.000
like, you wouldn't go to margin encoding for your geometries,

21:50.000 --> 21:54.000
which is like 70% of your tile size.

21:55.000 --> 21:58.000
Because that's not generally what you want.

21:58.000 --> 22:01.000
That's something you want in geometry,

22:01.000 --> 22:05.000
but like for like Z-standard, that doesn't make any sense,

22:05.000 --> 22:07.000
because it's only available for geometry.

22:07.000 --> 22:11.000
Like who would even think about putting geometry in this thing?

22:11.000 --> 22:15.000
So that is something which would be interesting,

22:15.000 --> 22:18.000
but I don't think it could get a 3x performance boost.

22:18.000 --> 22:21.000
It could get a small performance boost,

22:22.000 --> 22:26.000
and MVT, but for that it would need to be shipped into the browser,

22:26.000 --> 22:30.000
which is, for example, need Firefox support,

22:30.000 --> 22:35.000
which is, I don't know, we go talk to them later.

22:37.000 --> 22:39.000
Okay, thanks.

22:45.000 --> 22:48.000
Anyone else with a question?

22:52.000 --> 23:01.000
So, hi, thank you.

23:01.000 --> 23:06.000
You mentioned that it would be nice to reuse the implementation

23:06.000 --> 23:09.000
of your new Mupply Versile format.

23:09.000 --> 23:13.000
Are you planning on providing like a reference implementation

23:13.000 --> 23:16.000
or providing these libraries in some form?

23:16.000 --> 23:20.000
So in an ideal world, we have a spec that's clear as day,

23:20.000 --> 23:22.000
and you can just go and implement it.

23:22.000 --> 23:27.000
So the reality is that right now it's sort of implementation defined.

23:27.000 --> 23:36.000
But, I think the Java encoders is the most mature one right now,

23:36.000 --> 23:39.000
but we have something else going on.

23:39.000 --> 23:41.000
I'll miss the rest talk about it.

23:41.000 --> 23:45.000
The plan is to provide a rust library, which then can be very easily wrapped

23:45.000 --> 23:50.000
into other ecosystems, with some of the existing tooling.

23:50.000 --> 23:54.000
And we're going to see if that is the right path.

23:54.000 --> 23:59.000
We currently also have a TypeScript and C++ version.

23:59.000 --> 24:05.000
I'm hoping on the rust version being the best one,

24:05.000 --> 24:07.000
but it's currently not.

24:08.000 --> 24:10.000
That comes to the hair, by the way, maybe.

24:10.000 --> 24:11.000
I know.

24:11.000 --> 24:16.000
So if you go to our GitHub to the documentation of my

24:16.000 --> 24:20.000
libretile, we have an overview there of all the different implementations and

24:20.000 --> 24:21.000
integrations.

24:21.000 --> 24:26.000
And if you're working on an integration or an implementation in your project,

24:26.000 --> 24:30.000
it's not listed there yet, please create a pull request to add it.

24:31.000 --> 24:35.000
So there will definitely be multiple encoders,

24:35.000 --> 24:40.000
and probably something that wraps this rust encoder.

24:40.000 --> 24:41.000
Yeah.

24:41.000 --> 24:44.000
It's going to be fun.

24:44.000 --> 24:49.000
Any more questions?

24:49.000 --> 24:51.000
Great presentation.

24:51.000 --> 24:54.000
Thank you for explaining that all of us to us.

24:55.000 --> 25:00.000
Have you had any signal from GDAL or PostGIS in terms of supporting?

25:00.000 --> 25:04.000
I know you were just talking about getting all the foundation or sort of

25:04.000 --> 25:09.000
encoding libraries in place, but is there any initial signal from them?

25:09.000 --> 25:11.000
We haven't talked to them yet, I think.

25:11.000 --> 25:15.000
But we're hoping to, if someone here is working in that space,

25:15.000 --> 25:19.000
maybe I don't know what come talk to us, because like,

25:20.000 --> 25:24.000
PostGIS people are here and they're standing reasonably near to us.

25:24.000 --> 25:27.000
So we are hoping on that.

25:27.000 --> 25:28.000
Yeah.

25:28.000 --> 25:31.000
I'm not sure what kind of library they would need, because I don't think that,

25:31.000 --> 25:35.000
actually I think you can write PostGIS plugins in Rust now.

25:35.000 --> 25:36.000
That was mentioned.

25:36.000 --> 25:40.000
Well, it's mostly a technical problem at this point.

25:40.000 --> 25:44.000
But if you want to join that one of the MOT meetings,

25:44.000 --> 25:48.000
just email us and we'll see you there.

25:49.000 --> 25:50.000
Yeah?

25:50.000 --> 25:51.000
I think we're done with time.

25:51.000 --> 25:53.000
Yeah, you're having a good time.

25:53.000 --> 25:54.000
Thank you.

25:54.000 --> 25:55.000
Thank you.

25:55.000 --> 25:56.000
Thank you.

25:56.000 --> 25:57.000
Thank you.

25:57.000 --> 25:59.000
Someone in the library had a standout?

25:59.000 --> 26:00.000
Okay.

26:00.000 --> 26:08.000
Thanks for listening to our TED Talk.

26:08.000 --> 26:09.000
Thank you.

26:09.000 --> 26:10.000
Thank you.

26:10.000 --> 26:11.000
Thank you.

26:19.000 --> 26:21.000
Thank you.