Vector Tiles with GeoServer and OpenLayers
CC Attribution 3.0 Germany:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Blasby, David (Boundless)
Hocevar, Andreas (Boundless)
The latest release of GeoServer adds support for creating Vector Tiles in GeoJSON, TopoJSON, and MapBox Vector Tiles format through its WMS service for all the vector data formats it supports. These tiles can be cached using GeoWebCache (built into GeoServer), and served with the various tiling protocols (TMS, WMTS, and WMS-C). Thanks to very recent OpenLayers 3 development, these Vector Tiles can be easily and efficiently styled on a map. This technical talk will look at how GeoServer makes Vector Tiles accessible through standard OGC services and how they differ from normal WMS and WFS usage. It will also look at how OpenLayers 3 - as a simple-to-use vector tiles client - interacts with GeoServer to retrieve tiles and effectively manage and style them. OpenLayer 3’s extensive style infrastructure will be investigated.
 So without further ado, I present to you the presentation about GeoServer and OpenLayers Free. Hi. We'll be talking about vector tiles generated by GeoServer and rendered using OpenLayers. 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. Gabriel, he wrote the original GeoServer vector tiles components. On David, I'm currently moving vector tiles from a GeoServer community module to a more official extension and on the module maintainer. Andreas, he wrote the OpenLayers components. He'll be talking about OpenLayers later on. Let's get started. I want to quickly introduce vector tiles in the relation to what's familiar, tile maps. Here's the standard web map using OSM data. We've all seen them. If you pan around, you get little independence squares called tiles, get pulled in from the server. These maps are great. The server only has to draw each tile once. It's cash and it's very quick for everyone using the map. They make for fabulously interactive maps. Here's an OSM tile. A lot of time and effort went into the photography 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 future line work. I don't want to be in control of how the map looks. It's set in stone. 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. 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. In result, there's a personalized interactive vector tiles web map. 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. Vector tiles are empowering and efficient but a little bit harder to work with. This is a 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 on what the map looks like. You're not constrained to the server's cartography decisions. 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 pack a lot of information to a little space. This is especially true for the high resolution displays that are really popular nowadays. 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 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 and been continually talking mostly about the server side, 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 I'm going to show you some of the cutting edge new functionality. 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 tile's 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. We'll go into more details of that later. 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. Before we go into details, I just want to put vector tiles in the context of the open 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, something in tile services like WMTS. There's also vectors in the title, so I think WFS, which is about querying and retrieving features. It's all a little confusing. 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. WF is in the context of vector tiles is surprisingly pretty much independent. 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 and WFS returns the glorious feature details that 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. The vector tiles renderer, which used to make vector tiles, draws unstyled features into a data file. In both, the renderers, 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, we're not going to talk about most of the steps, but to warn you that the job trees will be generalized to make them smaller, perhaps transformed to another CRS, and in very small sub-fixal 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. 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 thicker big styles where features cross or near the boundaries. In fact, I recently fixed a clipping too close to the boundary issue, 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. 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 maps scales. For example, when zoomed in, I only want to show highways. When zoomed in, I want to draw most of the roads. Incomes to SLD, Style Layer Descripture, which is a standard OGC way to describe how to style a map. SLD is usually associated with making pretty maps, colors, bills, and thick lines, things like that. Styling is the job of the streaming renderer for drawing images. The vector tiles renderer is simple. If the SLD rule would have drawn an image, 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, it will be in the vector tiles data. There's basically three parts of the SLD rules. Scale, how zoomed in and out you are controls what rules are getting turned off. Factor, which tells you what data to use. And styling, which isn't using vector tiles, but important for image tile maps. You could make an uglier map, but I think you would have to really try. I'm showing a SLD rule for showing residential roads using a data filter only when you're zoomed in more than 1,000 to 70,000. For the streaming renderer, it's shown the image with 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, the vector tiles renderer puts it in the data file. I'm using a really ugly map here 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 geowed cache to tile 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 on 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, click that's all it takes. Five seconds to make this available as vector tiles and geowed 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. They look and behave pretty much exactly the same. 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, it's just changing how the client map looks styling. Andreas will be demoing this later on. Second of all, it's changing the server's SLD 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's styling function and nothing on the server changes. You don't have to regenerate the tiles. 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. 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. 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. I've chosen pink 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. Andreas is going to talk about open layers in the client now. Thank you, Dave. So let's take a look. For those of you who are not here in the morning session, open layers is a mapping library that can map pretty much everything. Images, image tiles, vector data, and now also tiled vector data. It can do so in any projection, you can even have rastery projection 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 from one zoom level position, whatever, to another. You can combine these animations even so you could even fly through values or whatever you could think of, and it integrates very well with other libraries, like, for example, cesium or D3. 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 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. 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. It's not a replacement for vector as in WFS data. It's really not made for analysis. It's made for rendering. And Spectre tile support in Open Layers is encapsulated in the OL format MVT class. It uses Mapbox's PPF library to read the binary tile data, 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, 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 that has raster tiles like an OpenStreetMap layer. But in OpenLayers, we can take advantage of the WMTS output format. So this code snippet shows how you could read the WMTS capabilities from tier server for a layer that provides Mapbox vector tiles. And with the tile URL function and the tile grid that we get back from the WMTS capabilities parsing, we can finally create our vector tile layer. OpenLayers uses the class OL layer vector tile for vector tile layers, and the source has the same name. And the most interesting part is the last line here in this code snippet, the style. OpenLayers 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, 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 Zindex support 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 can also use the same standard OpenLayers features that you would use for vector layers. 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 of the feature in an overlaid at this position next to the feature itself at its coordinate. Let's do some live demo to show you these features. I'm going to 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 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. And I don't know if you've noticed, but the map that Dave has shown was using EPSG for 3-6 as projection, so it might look a bit unfamiliar. So I made another change and requested the web marketer tileset instead from GeoServer and I ended up getting a map 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. So the labels stay upright. 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'm currently working on a library that translates mapbox GL styles into open layer style functions. 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. 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. Thank you very much. Thank you guys for this. 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. 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 and server and then again in open layers in client? There is no way to have it done it 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 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 and coding, it adds geometry transform functions and other interesting features. And my personal opinion is that with the new MapboxGL 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. But if I have funding and time to develop it, I will also be planning to work on a library that translates SLD to MapboxGL styles. And then you have the whole round trip from GeoService to open layers. You could even do a get style request, WMS get style request, take the SLD and turn it into open layer style functions and then get the same rendering in open layers. Just to answer the question. I hope so. It wasn't me. Thank you for the great speech. I have a thing that I would like to ask you. We always run in kind of the same problem, which is about print. And have you tried printing with vector styles? Is that possible? I mean, you could do server side prints for WMS maybe or client side print. I can say a few words about client side printing. 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 rendered the map in. And the tile will get rendered with a higher resolution but using the same styles. 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. And 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. Okay. So now we have five minutes. So if rooms have changed, then probably it's the time. I actually have one question here. So I was just wondering about the SLD on the Geo server side. If you put in a rendering transformation or a geometry transformation, will that be reflected in the tiles? No. Okay. Okay. So are there any more questions left? Because we would have five minutes. Oh, okay. Sorry. Actually, when you have a question, you know, you can just shout out, you know, 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. 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 OpenLiOS. So if you rotate the same map without labels, 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. 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 geo web cache? No, you can directly request vector tiles from the WMS. So you can generate them on the fly. Okay. 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.
 So without further ado, I present to you the presentation about GeoServer and OpenLayers  Free.  Hi.  We'll be talking about vector tiles generated by GeoServer and rendered using OpenLayers.  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.  Gabriel, he wrote the original GeoServer vector tiles components.  On David, I'm currently moving vector tiles from a GeoServer community module to a more  official extension and on the module maintainer.  Andreas, he wrote the OpenLayers components.  He'll be talking about OpenLayers later on.  Let's get started.  I want to quickly introduce vector tiles in the relation to what's familiar, tile maps.  Here's the standard web map using OSM data.  We've all seen them.  If you pan around, you get little independence squares called tiles, get pulled in from the  server.  These maps are great.  The server only has to draw each tile once.  It's cash and it's very quick for everyone using the map.  They make for fabulously interactive maps.  Here's an OSM tile.  A lot of time and effort went into the photography 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 future line work.  I don't want to be in control of how the map looks.  It's set in stone.  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.  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.  In result, there's a personalized interactive vector tiles web map.  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.  Vector tiles are empowering and efficient but a little bit harder to work with.  This is a 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 on what the map looks like.  You're not constrained to the server's cartography decisions.  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 pack a lot of information to a little space.  This is especially true for the high resolution displays that are really popular nowadays.  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 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 and been continually talking mostly about the server side, 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 I'm going to show you some of the cutting edge new functionality.  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 tile's 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.  We'll go into more details of that later.  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.  Before we go into details, I just want to put vector tiles in the context of the open  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, something in tile services like WMTS.  There's also vectors in the title, so I think WFS, which is about querying and retrieving  features.  It's all a little confusing.  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.  WF is in the context of vector tiles is surprisingly pretty much independent.  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 and WFS returns the glorious  feature details that 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.  The vector tiles renderer, which used to make vector tiles, draws unstyled features into  a data file.  In both, the renderers, 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, we're not going to talk about most of the steps, but to warn  you that the job trees will be generalized to make them smaller, perhaps transformed  to another CRS, and in very small sub-fixal 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.  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 thicker  big styles where features cross or near the boundaries.  In fact, I recently fixed a clipping too close to the boundary issue, 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.  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 maps  scales.  For example, when zoomed in, I only want to show highways.  When zoomed in, I want to draw most of the roads.  Incomes to SLD, Style Layer Descripture, which is a standard OGC way to describe how to style  a map.  SLD is usually associated with making pretty maps, colors, bills, and thick lines, things  like that.  Styling is the job of the streaming renderer for drawing images.  The vector tiles renderer is simple.  If the SLD rule would have drawn an image, 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, it will be in the vector tiles  data.  There's basically three parts of the SLD rules.  Scale, how zoomed in and out you are controls what rules are getting turned off.  Factor, which tells you what data to use.  And styling, which isn't using vector tiles, but important for image tile maps.  You could make an uglier map, but I think you would have to really try.  I'm showing a SLD rule for showing residential roads using a data filter only when you're  zoomed in more than 1,000 to 70,000.  For the streaming renderer, it's shown the image with 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, the vector tiles renderer  puts it in the data file.  I'm using a really ugly map here 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 geowed cache to tile 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  on 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,  click that's all it takes.  Five seconds to make this available as vector tiles and geowed 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.  They look and behave pretty much exactly the same.  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, it's just changing how the client map looks styling.  Andreas will be demoing this later on.  Second of all, it's changing the server's SLD 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's styling  function and nothing on the server changes.  You don't have to regenerate the tiles.  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.  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.  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.  I've chosen pink 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.  Andreas is going to talk about open layers in the client now.  Thank you, Dave.  So let's take a look.  For those of you who are not here in the morning session, open layers is a mapping library  that can map pretty much everything.  Images, image tiles, vector data, and now also tiled vector data.  It can do so in any projection, you can even have rastery projection 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 from one zoom level position, whatever,  to another.  You can combine these animations even so you could even fly through values or whatever  you could think of, and it integrates very well with other libraries, like, for example,  cesium or D3.  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 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.  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.  It's not a replacement for vector as in WFS data.  It's really not made for analysis.  It's made for rendering.  And Spectre tile support in Open Layers is encapsulated in the OL format MVT class.  It uses Mapbox's PPF library to read the binary tile data, 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,  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 that has  raster tiles like an OpenStreetMap layer.  But in OpenLayers, we can take advantage of the WMTS output format.  So this code snippet shows how you could read the WMTS capabilities from tier server for  a layer that provides Mapbox vector tiles.  And with the tile URL function and the tile grid that we get back from the WMTS capabilities  parsing, we can finally create our vector tile layer.  OpenLayers uses the class OL layer vector tile for vector tile layers, and the source  has the same name.  And the most interesting part is the last line here in this code snippet, the style.  OpenLayers 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, 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 Zindex support 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 can also use the same standard  OpenLayers features that you would use for vector layers.  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 of the feature in an overlaid at  this position next to the feature itself at its coordinate.  Let's do some live demo to show you these features.  I'm going to 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 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.  And I don't know if you've noticed, but the map that Dave has shown was using EPSG for  3-6 as projection, so it might look a bit unfamiliar.  So I made another change and requested the web marketer tileset instead from GeoServer  and I ended up getting a map 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.  So the labels stay upright.  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'm currently working on a library that translates mapbox  GL styles into open layer style functions.  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.  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.  Thank you very much.  Thank you guys for this.  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.  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 and server and then again  in open layers in client?  There is no way to have it done it 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 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 and coding, it adds  geometry transform functions and other interesting features.  And my personal opinion is that with the new MapboxGL 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.  But if I have funding and time to develop it, I will also be planning to work on a library  that translates SLD to MapboxGL styles.  And then you have the whole round trip from GeoService to open layers.  You could even do a get style request, WMS get style request, take the SLD and turn  it into open layer style functions and then get the same rendering in open layers.  Just to answer the question.  I hope so.  It wasn't me.  Thank you for the great speech.  I have a thing that I would like to ask you.  We always run in kind of the same problem, which is about print.  And have you tried printing with vector styles?  Is that possible?  I mean, you could do server side prints for WMS maybe or client side print.  I can say a few words about client side printing.  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 rendered the map in.  And the tile will get rendered with a higher resolution but using the same styles.  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.  And 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.  Okay.  So now we have five minutes.  So if rooms have changed, then probably it's the time.  I actually have one question here.  So I was just wondering about the SLD on the Geo server side.  If you put in a rendering transformation or a geometry transformation, will that be reflected  in the tiles?  No.  Okay.  Okay.  So are there any more questions left?  Because we would have five minutes.  Oh, okay.  Sorry.  Actually, when you have a question, you know, you can just shout out, you know, 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.  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 OpenLiOS.  So if you rotate the same map without labels, 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.  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 geo web cache?  No, you can directly request vector tiles from the WMS.  So you can generate them on the fly.  Okay.  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.
foss4g-2016-1154-vector_tiles_with_geoserver_and_openlayers-hd_0_215.png foss4g-2016-1154-vector_tiles_with_geoserver_and_openlayers-hd_216_827.png foss4g-2016-1154-vector_tiles_with_geoserver_and_openlayers-hd_828_1295.png foss4g-2016-1154-vector_tiles_with_geoserver_and_openlayers-hd_1296_2531.png foss4g-2016-1154-vector_tiles_with_geoserver_and_openlayers-hd_2532_3035.png foss4g-2016-1154-vector_tiles_with_geoserver_and_openlayers-hd_3036_4007.png foss4g-2016-1154-vector_tiles_with_geoserver_and_openlayers-hd_4008_5831.png foss4g-2016-1154-vector_tiles_with_geoserver_and_openlayers-hd_5832_6575.png foss4g-2016-1154-vector_tiles_with_geoserver_and_openlayers-hd_6576_7499.png foss4g-2016-1154-vector_tiles_with_geoserver_and_openlayers-hd_7500_8579.png foss4g-2016-1154-vector_tiles_with_geoserver_and_openlayers-hd_8580_9263.png foss4g-2016-1154-vector_tiles_with_geoserver_and_openlayers-hd_9264_13607.png foss4g-2016-1154-vector_tiles_with_geoserver_and_openlayers-hd_13608_14927.png foss4g-2016-1154-vector_tiles_with_geoserver_and_openlayers-hd_14928_15479.png foss4g-2016-1154-vector_tiles_with_geoserver_and_openlayers-hd_15480_16163.png foss4g-2016-1154-vector_tiles_with_geoserver_and_openlayers-hd_16164_17303.png foss4g-2016-1154-vector_tiles_with_geoserver_and_openlayers-hd_17304_19151.png foss4g-2016-1154-vector_tiles_with_geoserver_and_openlayers-hd_19152_19199.png foss4g-2016-1154-vector_tiles_with_geoserver_and_openlayers-hd_19200_20519.png foss4g-2016-1154-vector_tiles_with_geoserver_and_openlayers-hd_20520_23315.png foss4g-2016-1154-vector_tiles_with_geoserver_and_openlayers-hd_23316_26663.png foss4g-2016-1154-vector_tiles_with_geoserver_and_openlayers-hd_26664_26831.png foss4g-2016-1154-vector_tiles_with_geoserver_and_openlayers-hd_26832_27143.png foss4g-2016-1154-vector_tiles_with_geoserver_and_openlayers-hd_27144_27311.png foss4g-2016-1154-vector_tiles_with_geoserver_and_openlayers-hd_27312_27359.png foss4g-2016-1154-vector_tiles_with_geoserver_and_openlayers-hd_27360_31463.png foss4g-2016-1154-vector_tiles_with_geoserver_and_openlayers-hd_31464_33923.png foss4g-2016-1154-vector_tiles_with_geoserver_and_openlayers-hd_33924_34559.png foss4g-2016-1154-vector_tiles_with_geoserver_and_openlayers-hd_34560_35855.png foss4g-2016-1154-vector_tiles_with_geoserver_and_openlayers-hd_35856_35999.png foss4g-2016-1154-vector_tiles_with_geoserver_and_openlayers-hd_36000_36179.png foss4g-2016-1154-vector_tiles_with_geoserver_and_openlayers-hd_36180_37103.png foss4g-2016-1154-vector_tiles_with_geoserver_and_openlayers-hd_37104_37283.png foss4g-2016-1154-vector_tiles_with_geoserver_and_openlayers-hd_37284_38267.png foss4g-2016-1154-vector_tiles_with_geoserver_and_openlayers-hd_38268_38567.png foss4g-2016-1154-vector_tiles_with_geoserver_and_openlayers-hd_38568_38891.png foss4g-2016-1154-vector_tiles_with_geoserver_and_openlayers-hd_38892_39052.png