Vector Tiles with GeoServer and OpenLayers
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Teil | 149 | |
| Anzahl der Teile | 193 | |
| 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 | 10.5446/20333 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache | ||
| Produktionsort | Bonn |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
| |
| Schlagwörter |
FOSS4G Bonn 2016149 / 193
8
20
21
27
28
34
39
51
53
56
61
64
66
68
72
75
78
79
80
84
104
108
112
120
123
126
130
131
134
135
140
142
143
145
146
153
154
157
160
165
182
183
188
190
00:00
ElementargeometrieVektorrechnungOffene MengeGebundener ZustandOffene MengeCoxeter-GruppeTesselationVektorrechnungComputeranimation
00:33
Web ServicesMAPDreiEinfache GenauigkeitSpezialrechnerOffene MengeAttributierte GrammatikElementargeometrieReelle ZahlVektorrechnungAuflösung <Mathematik>VektorServerClientGesetz <Physik>Demo <Programm>Prozess <Informatik>RenderingKontextbezogenes SystemKontrollstrukturParkettierungAdressierungVolumenvisualisierungClientVektorVektorrechnungTesselationParkettierungElektronische PublikationVererbungshierarchieBildgebendes VerfahrenAuflösung <Mathematik>Mapping <Computergraphik>VolumenvisualisierungAnalysisBimodulServerOffene MengeDemo <Programm>MAPAuswahlverfahrenStandardabweichungQuaderResultanteBenutzerbeteiligungInformationSoftwarewartungPhysikalisches SystemReelle ZahlGamecontrollerBitRelativitätstheorieKontextbezogenes SystemDatensichtgerätMinkowski-MetrikEntscheidungstheorieCachingMultiplikationsoperatorQuadratzahlPixelBandmatrixProzess <Informatik>ZoomNP-hartes ProblemWeb ServicesFunktionalRenderingInhalt <Mathematik>InformationsspeicherungMessage-PassingExergieEinfach zusammenhängender RaumRuhmasseTouchscreenQuick-SortSpannweite <Stochastik>GradientPräprozessorÄhnlichkeitsgeometriePunktTeilbarkeitMaßerweiterungGeradeHypermediaNabel <Mathematik>Stochastische AbhängigkeitExogene VariableTurm <Mathematik>App <Programm>WebcastingTaskComputeranimation
06:39
FlächeninhaltMereologieSchlussregelElementargeometrieMAPServerKontrollstrukturWidgetDigitalfilterInformationMaßstabAdressierungLESGeradeRundungSolitärspielSpezialrechnerVektorrechnungOffene MengeCachingGenetischer AlgorithmusBenutzerbeteiligungEntscheidungstheorieMathematikBildgebendes VerfahrenMaßstabSchlussregelVektorrechnungFunktionalGamecontrollerGraphfärbungDifferenteAuswahlaxiomTesselationTaskClientMAPAnalysisRandwertMapping <Computergraphik>Objekt <Kategorie>ZweiVolumenvisualisierungParkettierungFlächeninhaltRenderingServerStandardabweichungPunktTeilmengeInformationProzess <Informatik>Elektronische PublikationCASE <Informatik>MultiplikationsoperatorInformationsspeicherungGeradeInhalt <Mathematik>Turm <Mathematik>Web-SeiteZeichenketteZentrische StreckungMereologieAggregatzustandCachingOffene MengeElementargeometriePixelComputeranimation
12:46
CAMVolumenvisualisierungMAPVektorrechnungSpezialrechnerAxonometrieOrientierung <Mathematik>KreisbewegungOffene MengeQuaderInteraktives FernsehenAttributierte GrammatikStandardabweichungBinärdatenProgrammbibliothekKonfiguration <Informatik>TeilmengePixelInnerer PunktQuellcodeVarianzServerElementargeometrieAuflösung <Mathematik>CliquenweiteInformationOverlay-NetzPunktDatensichtgerätProgrammbibliothekVersionsverwaltungOffene MengeParkettierungZoomGruppenoperationVektorrechnungBinärcodeFunktionalGlobale OptimierungInteraktives FernsehenTesselationGeradePixelMittelwertsatz <Integralrechnung>VolumenvisualisierungTeilmengeDruckspannungKlasse <Mathematik>MAPEreignishorizontInstantiierungAuflösung <Mathematik>GraphfärbungCliquenweiteOrdnung <Mathematik>Automatische IndexierungMinkowski-MetrikCASE <Informatik>MathematikBitmap-GraphikOverlay-NetzQuellcodeAttributierte GrammatikBildgebendes VerfahrenFunktion <Mathematik>CodeInformationZeiger <Informatik>KreisbewegungMereologieRenderingStandardabweichungKoordinatenMapping <Computergraphik>MetadatenOrtsoperatorMultiplikationsoperatorSchreib-Lese-KopfMailing-ListeKartesische KoordinatenSoftwareGrenzschichtablösungVorzeichen <Mathematik>ElementargeometrieFlächeninhaltProjektive EbenePunktDatensatzSpeicherabzugFramework <Informatik>Gewicht <Ausgleichsrechnung>AnalysisBitrateEuler-WinkelComputeranimation
17:46
Offene MengeDemo <Programm>Vollständiger VerbandDreiDemo <Programm>MathematikFunktionalMAPPunktVektorrechnungTesselationBitBenutzerbeteiligungGeradeTouchscreenInteraktives FernsehenOffene MengeProgrammbibliothekCASE <Informatik>RechenschieberMapping <Computergraphik>Projektive EbeneMultiplikationsoperatorBildgebendes VerfahrenCoxeter-GruppeInhalt <Mathematik>AggregatzustandKurvenanpassungArbeit <Physik>MenütechnikComputeranimation
20:58
Offene MengePhysikalisches SystemCodierung <Programmierung>Transformation <Mathematik>WärmeübergangMereologieAdditionFunktionalHochdruckClientMailing-ListeWort <Informatik>SoundverarbeitungServerGüte der AnpassungLuenberger-BeobachterMultiplikationsoperatorStandardabweichungProgrammbibliothekElementargeometrieSprachsyntheseMAPRenderingUnrundheitVektorrechnungComputeranimation
23:02
ElementargeometriePixelClientHochdruckTransformation <Mathematik>Dichte <Stochastik>MathematikAuflösung <Mathematik>Offene MengeDemo <Programm>Klasse <Mathematik>Web ServicesProgrammbibliothekMapping <Computergraphik>ParametersystemMAPMultiplikationsoperatorParkettierungBesprechung/Interview
24:00
Kerr-LösungLokales MinimumWindkanalQuerkraftDemo <Programm>Besprechung/InterviewVorlesung/Konferenz
24:44
FünfTouchscreenArbeit <Physik>MultiplikationsoperatorMailing-ListeRuhmasseFontTermVektorrechnungMAPTesselationBesprechung/Interview
25:43
InformationsmanagementICC-GruppeMultiplikationsoperatorVorlesung/KonferenzComputeranimation
Transkript: Englisch(automatisch erzeugt)
00:09
So, without further ado, I present to you the presentation about GeoServer and Open Layers 3. Hi. We'll be talking about vector tiles generated by GeoServer and rendered using Open Layers.
00:22
Others will disagree, but for me the most interesting thing to happen in GeoServer in the last little while is vector tiles. They're really easy to use and they open up a lot of possibilities. I'm really excited to talk to you about them. Here's our cast of characters. Gabrielle, he wrote the original GeoServer vector tiles components. On David, I'm currently moving vector tiles from a GeoServer community module to a more
00:44
official extension and on the module maintainer. Andreas, he wrote the Open Layers components. He'll be talking about Open Layers later on. Let's get started. I want to quickly introduce vector tiles in relation to what's familiar, tiled maps. Here's a standard web map using OSM data.
01:02
We've all seen them. If you pan around, you get little independent squares called tiles. Get pulled in from the server. These maps are great. The server only has to draw each tile once. It's cached and it's very quick for everyone using the map. They make for fabulously interactive maps. Here's an OSM tile.
01:22
A lot of time and effort went into the cartography for this. It looks great. It's clear and beautiful. It's super easy to put together a map using these tiles. However, there's not much you can do with them other than draw them. Not getting any access to underlying feature line work. I don't have any control how the map looks. It's set in stone.
01:43
What if we do the hard work of data prep? What's available at each zoom level? Get ready to draw but don't actually draw it. Instead, we package real features into squares just waiting to be drawn. We call these data tiles, without any styling information, vector tiles.
02:02
We take the vector tiles, put them in a grid and cache them. We then deliver them in exactly the same way as an image tile map. Except instead of just blitting images on the screen, the client decides what's drawn and how the map looks. It does the rendering. End result is a personalized interactive vector tiles web map.
02:23
I want to emphasize that image tile maps and vector tile maps are very similar. Except image tiles maps have pre-rendered on the server tiles and vector tiles have rendered on the client tiles. Other than that, the tiling system is pretty much exactly the same.
02:44
Vector tiles are empowering and efficient but a little bit harder to work with. There's this thousand different stories to tell with your map data. Vector tiles empower the client instead of the server to decide which story is told because the client decides what the map looks like. You're not constrained to the server's cartography decisions.
03:03
Vector tiles are very efficient because you can tell all the thousand stories with the same tiles. You only need one copy of them on the server and you just render them differently on the client. They're also efficient because they can really pack a lot of information to a little space. This is especially true for the high resolution displays that are really popular nowadays.
03:23
You have to bring in a lot of pixels and that means a lot of extra image tiles. That's a ton of extra server bandwidth and storage. Drawing vectors which look good at any resolution instead of pre-generated images can be really efficient. It's a huge savings. For the last two points, vector tiles can be more difficult to work with,
03:42
especially if you're doing your own style because you need to understand both feature data and the tools. Luckily Andreas has made the tools as easy to use as possible. I've introduced vector tiles to be continually talking mostly about the server side,
04:00
how GeoServer creates vector tiles and how you can control their content. The takeaway of this is that vector tiles are easy to use with GeoServer and all the tools and techniques that you're familiar with, you get to reuse. Andreas will be talking about and demoing the client side open layers. He's got a really slick demo and he'll show you some of the cutting edge new functionality.
04:24
It's super easy to get vector tiles from GeoServer and GeoWebcache. Instead of asking for an image like a PNG from GeoServer's WMS, you just ask for a vector tiles format. That's it. Instead of an image, you're going to get a vector tile back from GeoServer. Instead of drawing it into an image canvas, GeoServer draws it into a data file.
04:44
We'll go into more details of that later. And to make them available through GeoWebcache's tile caching service, just tick the box in the vector tiles format you're publishing to and it does the rest. There's nothing else to worry about. That's it, five seconds and you're up and running.
05:02
Before we go into details, I just want to put vector tiles in the context of the OGC services. It's a little confusing because you make maps with them, so I think WMS, which is used to make maps. There's also tiles in the title, so I'm thinking tile services like WMTS. There's also vectors in the title, so I think WFS, which is about querying and retrieving features.
05:23
It's all a little confusing. So to be clear, we use GeoServer's WMS with a special vector tiles renderer to generate tiles. We use GeoWebcache to handle the caching and tiling. GeoWebcache is a bit magical and it just works. And WFS, in the context of vector tiles, is surprisingly pretty much independent.
05:45
A lot of people feel that because WFS is about access to unstyled feature data, there should be connection between vector tiles and WFS. Turns out, although they do provide actual access to feature data, line work and attributes, they differ because vector tiles provide easy-to-render features
06:03
and WFS returns the glorious feature details that are needed for actual GIS analysis. GeoServer's WMS rendering process is fairly comprehensive. There's two main renderers. The streaming renderer used to make image maps, draws styled features onto an image.
06:21
The vector tiles renderer, which is used to make vector tiles, draws unstyled features into a data file. In the end, both renderers are very similar. They both preprocess and render the data, either onto an image or into a data file. Just at the interest of time, I'm not going to talk about most of the steps,
06:41
other than to warn you that the geometry will be generalized to make them smaller, perhaps transformed to another CRS, and in very small sub-pixel features will be maybe omitted. In almost all cases, this is exactly what you want. I'm going to talk about clipping and controlling the creation of vector tiles using SLD.
07:03
We clip so we're only sending what needs to be drawn to the tile, saving bandwidth, storage and rendering time. But we don't clip right at the tile boundary. If we did, the tiles would look wrong at the edges, especially if you're using thick or big styles where features cross or near the boundaries. In fact, I recently fixed a clipping too close to the boundary issue
07:23
and it makes maps look horrible, as you can see up in the corner. Just a quick note, because of the extended clipping area, you will see overlapping data in adjacent tiles, which isn't a problem when you're rendering, but it's sometimes something to be aware of if you're doing any analysis with the tiles.
07:42
Open layers draws all the data on the tile, but the rendering is clipped to the exact tile boundary. This is exactly what you want and your maps look great. The final piece of the puzzle is how we decide what data is in the tiles at various map scales. For example, when zoomed in, when zoomed out,
08:03
I only want to show highways. When zoomed in, I want to draw most of the roads. In comes SLD, style layer descriptor, which is a standard OGC way to describe how to style a map. SLD is usually associated with making pretty maps, colors, fills and thick lines, things like that.
08:22
Styling is the job of the streaming renderer for drawing images. The vector tiles render is simple. If the SLD rule would have drawn a feature onto the image, it draws it without any styling information into the vector tiles data file. It's as simple as that. If your SLD would have drawn the features onto the image,
08:43
it'll be in the vector tiles data. There's basically three parts to the SLD rules. Scale, how zoomed in and out you are controls what rules are getting turned in off. Filter, which tells you what data to use. And styling, which isn't used in vector tiles,
09:01
but important for image tile maps. You could make an uglier map, but I think you would have to really try. Showing a SLD rule for showing residential roads using a data filter only when you're zoomed in more than one to 70,000.
09:22
For the streaming renderer, easily showing the image with thin blue lines when you're zoomed in. For the vector tiles renderer, it would get put into the vector tile data file, no styling information when you're zoomed in. Remember when the streaming renderer would have drawn the feature,
09:42
the vector tiles renderer puts it in the data file. I'm using a really ugly map here just to make the styling easy to see, but also prove a point. With vector tiles, you get to decide what your map looks like. You're not stuck with my cartography decisions, and that's good. Traditionally, you would use geo web cache to tile
10:01
and cache your WMS images using this SLD, and boom, you've got a really ugly web map that shows different details of data depending how zoomed in you are. Really standard stuff. But if you want to use my data, but not my colors, or my style, or my choice of styling,
10:21
click, that's all it takes. Five seconds to make this available as vector tiles and geo web cache when we power the client to make the styling decisions. Now we're cooking with gas. Here's an example of an image and a vector tiles map. I put the same styling in both maps. As you'd expect, the look can behave pretty much exactly the same.
10:40
You can use vector tiles in most situations where you would use image tile maps. There are two types of common changes I want to show you. First of all is just changing how the client map looks styling. Andreas will be demoing this later on. Second involves changing the server's SLD
11:01
to change what data gets put into the vector tile. The first is simple. A styling change is shown here. This is where vector tiles really shine. If you want your map to look different, you just have to change the client styling function and nothing on the server changes. You don't have to regenerate the tiles.
11:21
I updated the open layer styling function to do road casing as you can see. I don't have to change anything on the server. I keep using the exact same tiles and I now have two different looking maps. The second type of change is more complex. My map is missing some of the features I want to draw. The features are just not in the vector tiles data.
11:42
The SLD isn't putting OSM footways into the vector tiles because there's no SLD rule that says to do that. To add the state of the vector tiles, I update the SLD and add a rule so it renders the footways into the vector tiles as I show here. GeoWebcache will magically notice the SLD change and reset your cache.
12:02
This is an example of a change on the server to change the actual content of the vector tiles data. The previous was a client change to change the styling of the map. Now that I've added footways to the server vector tile data, I also update my open layer style so it renders them.
12:21
I've chosen pink to dash lines to go with my world's ugliest map theme. This is the basic idea behind vector tiles in GeoServer. We use SLD to render features, including generalization and clipping, into a data file that GeoWebcache makes available in a cached and tiled manner. It's really easy.
12:41
Andreas is gonna talk about open layers in the client now. Thank you, Dave. So let's take a look. For those of you who were not here in the morning session, open layers is a map framework, map library, mapping library that can map pretty much everything, images, image tiles, vector data,
13:01
and now also tiled vector data. It can do so in any projection. We even have a raster reprojection in open layers. It has full rotation support, so if you have a navigation application, you can have a head-up map instead of a north-up map. We support animations that transition your viewport
13:23
from one zoom level, position, whatever, to another, and you can combine these animations even, so you could even fly through valleys or whatever you could think of, and it integrates very well with other libraries, like, for example, Cesium or D3.
13:42
Vector tiles in open layers were added in version 3.11, I think, so about 10 months ago. We already gave a sneak preview last year at the conference in Seoul, but that was not in a release yet, and we support basically all the vector formats
14:01
that are available in open layers, but Mapbox vector tiles is the preferred format because it has the best optimizations for rendering, and styling works the same as with untiled vector data using open layer style functions, and I'm going to show you how these style functions work in a minute.
14:21
Also, because attributes that are required for styling are transferred with the vector tiles, you can have some interactivity in your map. For example, hover over features and get information about that feature, so you have access to the feature attributes, and I cannot stress this enough. Dave already said it.
14:41
It's not a replacement for vector as in WFS data. It's really not made for analysis. It's made for rendering. Mapbox vector tile support in open layers is encapsuled in the OL format MVT class. It uses Mapbox's PPF library to read the binary tile data,
15:01
and it uses Mapbox's vector tile library to extract the layers and features from the vector tiles. In open layers, what we add to that format is you can also configure it to only read a subset of the layers that are available in the vector tile, and instead of creating OL feature instances which have the full geometries, full attributes,
15:22
full event listening for changes and everything, we create very lightweight render features that have coordinates in pixel space that are very fast to render. So usually you would create a vector tiles layer like you would an XYZ layer
15:41
that has raster tiles like an OpenStreetMap layer, but with open layers, we can take advantage of the WMTS output format. So this code snippet shows how you could read the WMTS capabilities from GeoServer for a layer that provides Mapbox vector tiles.
16:03
And with the tile URL function and the tile grid that we get back from that WMTS capabilities parsing, we can finally create our vector tile layer. Open layers uses the class OL layer vector tile for vector tile layers, and the source has the same name.
16:21
And the most interesting part is the last line here in this code snippet, the style. Open layer style functions are called with the feature that's being styled and with the resolution that's used to render the feature. And this allows for very flexible styling. One simple example in this snippet here,
16:43
we see streets with road casing styled nicely by having two styles, one with a thicker line width for the casing and another with a different color with a thinner width for the actual road. And OpenLayers also has Z index support
17:01
so you can tell the renderer the order that you want the features rendered. So obviously you want the casings below the actual street. For getting interactivity when hovering over the map, you also can use the same standard OpenLayers features that you would use for vector layers.
17:22
You can register for a pointer move event which gets triggered whenever you move your pointer over the map. And inside that listener, you can use the for each feature at pixel function. And that function is called with the feature. And in this case, we just want to display the name
17:40
of the feature in an overlay that is positioned next to the feature itself at its coordinate. Let's do some live demo to show you these features.
18:01
Gonna move those to the big screen. Where is it? Here we go. And now I should see where to make it full screen. Somewhere here maybe. Here we go. All right, so this is the ugly map
18:20
that Dave had mentioned, which has the same basic styling that he used in his SLD. I went ahead, took the same map and changed the styles a little bit with road casings and everything.
18:40
And I don't know if you've noticed, but the map that Dave has shown was using EPSG 4326 as projection. So it might look a bit unfamiliar. So I made another change and requested the Web Mercator tileset instead from GeoServer. And I ended up getting a map
19:00
that looks a bit more familiar. You can also see labels here. And the nice thing about vector tiles is when you rotate the map that the labels stay upright. Let me see if I can rotate the map. Yeah. So the labels stay upright.
19:20
And I also mentioned the interactivity. So as I hover over the features here, you can see the names of the streets. Looking a bit in the future, I am currently working on a library that translates Mapbox GL styles into open layer style functions.
19:40
And this is how it looks. Currently, as you can see, there's obviously no support yet for line labels and point features. That's what I'm currently working on. And one feature that's still missing in open layers is labels that follow curves or lines. That should also be available very soon. And then you will really be able to get very nice looking vector tiles maps in open layers.
20:06
And this already brings us to the end of our presentation. And I'm just not able to find the slides again because I don't know how the screens are arranged. But that shouldn't keep you from asking questions.
20:22
Thank you very much. So thank you guys for this really great talk about this exciting new features. And I think it really adds a lot to web mapping.
20:41
I didn't register any questions during the talk, but I think there might be questions. So we start right here. Hello, did I get it right that I have to define style twice, first in SLD, in server,
21:01
and then again in open layers in client. There is no way to have it done only once. Very good observation. That's really a thing that we've been struggling with in this whole Phosphor-G ecosystem for years, that there's no good story for transferring styles from one system to another. The SLD format is an XML format
21:23
that is suitable for doing that, but it's also quite a verbose format and open layers has added quite a few interesting additions that are not part of standard SLD. So what we have in GeoService somewhere in between SLD and symbology encoding, it adds geometry transform functions
21:41
and other interesting features. And my personal opinion is that with the new Mapbox.jl style format, for the first time in this Phosphor-G ecosystem, we have a style format that should be easy to transfer styles between systems. And I cannot make 100% promise,
22:01
but if I have funding and time to develop it, I will also be, I'm planning to work on a library that translates SLD to Mapbox.jl styles, and then you have the whole round trip from GeoServer to open layers. You could even do a get style request, WMS get style request, take the SLD
22:20
and turn it into open layer style functions and then get the same rendering in open layers. Does this answer the question? I hope so. It wasn't me. Thanks for the great speech. I have a thing that I would like to ask you. We always run in kind of the same problem,
22:42
which is about print. And have you tried printing with vector tiles? Is that possible? I mean, you could do server-side prints for VMS maybe, or client-side print. I can say a few words about client-side printing.
23:02
In open layers, the whole map is rendered to a canvas, and you can take this canvas and print it. And if you want to print at a higher resolution, all you have to do is change the pixel ratio that you render the map in, and the tile will get rendered with a higher resolution, but using the same styles.
23:21
So that should be easy if you want to print from the client-side. There are even libraries that can, on the fly, create a PDF from whatever you add to it on the client. We have an official demo also in the open layers examples if you look for PDF and print. That's for client-side printing. I cannot answer the server-side printing question.
23:42
Okay, so now we have five minutes. So if rooms have changed, then it probably is the time. I actually have one question here. So I was just wondering about the SLD on the GeoServer side. If you put in a rendering transformation or a geometry transformation,
24:00
will that be reflected in the tiles? No. Okay. Okay, so are there any more questions left? Because we would have five minutes, but not a question. Okay, sorry. Actually, when you have a question, you know you can just shout out, you know,
24:20
because there's no need to be shy. And it's kind of hard to spot people, you know, because the room is not that easy to scan. Actually, what I'm doing when I'm sitting up there, I'm trying to scan the room, so you can raise your hand during the talks. I'm wondering about performance. So as we were showing the demo and you tried to rotate it, it was like tick, tick, tick, tick.
24:42
Is it normal or is it getting better somehow? I think there was something, because switching screens a lot, so I didn't get the full canvas rendering performance, but we do have a room for performance improvements for labor rendering still in OpenLias. So if you rotate the same map without labels,
25:00
it will be faster. There is something with labor rendering, and it's the halo that you add around the font that takes a while to render, but there are ways to improve that. So that's also on my list for performance improvements. Okay, so I would have one more question over here. I think we're doing okay in time, so.
25:21
Yeah, thank you. Just one quick question in terms of preparing the vector tiles. Is that possible on the fly as well, or does it always have to go through geoweb cache? No, you can directly request vector tiles from the WMS, so you can generate them on the fly.
25:44
I don't see any more questions, and we did quite well on time. So thank you again for this great talk and this introduction.