 Well, I work with GeoServer, which we're going to be talking about today, GeoTools, which is a data access library, does a lot of rendering, does a lot of that Geo for Geospatial. JTS Topology Suite, which is the rocket science of the Geospatial community, this is the library that does all the geometries. Without geometry and being able to compare shapes, we wouldn't have an open source GIS industry at all. I just help out with that project. I'm not one of the rocket scientists. I work on a couple other projects, ImageN and Udig. I also volunteer with the community. So I volunteer with the OSGeo Foundation. I just wrapped up my second tour as OSGeo director. I serve on the incubation community, helping new project teams not to be embarrassing on the internet. I'm also the GeoTools project officer. I also help out with the marketing team because without users, a lot of our open source projects would get very lonely. I also do some volunteer work with the Eclipse Foundation. Now, there's several popular GeoServer talks. We do an annual kind of team update, a tour of what's new. This is great for folks that already use GeoServer. We do a GeoServer feature frenzy. This is all the stuff that's cool and exciting and kind of the headline features that we wouldn't normally get to talk about every year. And we also do one called GeoServer ecosystem where we show a lot of the crazy systems that people have set her up worldwide. And that's very inspirational. It gives folks a chance to see what's possible. There's a problem with all of these talks. Every time I help out with one of them, I get a question. So what does GeoServer actually do? And so that's what this talk is about. So let me start with what GeoServer is for. GeoServer has a vision right on the top of our homepage. GeoServer is an open source server for sharing geospatial data. We're really passionate about sharing data. The project was founded out of like a community project in New York to like help the community map all the trees in their neighborhood. We're here because we want people to be able to share a map. And we don't want you to stop just at sharing a map. We want you to share the data behind the map. And it's not enough just to share the data. We want to support editing. We want to make sure those community members can actually edit the data, not just consume it blindly. So this is the foundation principle of how our software project was formed. Our approach, how we're trying to address this, design for interoperability. We actually take that pretty seriously to publish data from any major data source using open standards. So I just want to unpack that a bit. GeoServer doesn't want to lock you in. We're not a vendor. We want you to share your data with as many folks as possible. And to that end, GeoServer is kind of open-ended. It can be considered a framework where we gradually plug more and more protocols in over time. So once you set up your GeoServer and you're publishing your data, as you upgrade, you can reach more and more clients. We also don't want you to have to like import your data into GeoServer. It hangs out in the middle. If you're one of these organizations that has Oracle as a data policy, well, you're going to be able to use GeoServer to take the data out of Oracle and share it with the open community. If you are in the cloud and have GeoMesa or MongoDB, you'll be able to take GeoServer and use it as a front-end so people can access all your cloud data. And we do start with the industry standards. It's the opposite of the not invented here syndrome. If we have to invent something in isolation, chances are we're taking the wrong approach. We're always looking for folks to collaborate with. So most people come to GeoServer just wanting to publish a map. So each data set in GeoServerSpeak is a layer of content. You can actually gather those layers into a group and arrange them in order to make a little base map or something. There's also a small little layer preview that you can use to test things out locally. GeoServer, in this case, is the rendering engine. So it's producing maps for clients on the web, desktop, mobile, et cetera. We've got more than one approach. Remember, it's just the concept of publishing a layer. You might publish it as a map where people can zoom and pan around and do ad hoc queries. You might publish an entire tile set of data for mobile clients. The result of publishing a map doesn't always look like an image. It doesn't have to be a PNG. SVG and KML output, they're little vector formats that include baked-in styling information on how they're supposed to be drawn. You can also have extensions for GeoServer that get it to generate out PDFs. One I personally like is vector tiles, which are pre-processed little vector data sets, and they're pre-processed for client-side rendering. I'm just going to breathe there. Everyone's looking stunned. How am I doing so far? There's a question? I'll try. I guess I should have got some water. The next thing we can do is vector data publishing. In the spirit of Open, we're really wanting to set ourselves up to share the data behind the map. We've got interfaces that support queries in a whole wide range of different out formats, from JSON to KML to zip shapefiles, if that's what you like to work with. Who likes zip shapefiles? Wow, this is a developer conference. I was just at a QGIS user meeting. They're in the middle of the transition from shapefiles to geo-package, and there's terror. We also support vector editing, so we really want to make sure those community members can get a hold of and interact with the data. We did make sure editing is off by default, but we only did that recently. So if you've been using GeoServer for years, check your settings. You might be letting anybody on the internet edit your information. We also do provide direct raster access. Now keep in mind for the vector and the raster access, GeoServer is not providing you an interactive experience. That's up to a client like QGIS on the desktop or open layers or leaflet in a web mapping environment. Okay, so you get a general purpose of what GeoServer is for. Who here owns data they want to share? A couple people. That's great. Okay, so GeoServer configuration. When you launch GeoServer, there's this little welcome screen and it's a little web configuration app that you can use to configure and publish your different data products. I need to stop at this point and say this is not GeoServer. This is just a little tool to configure. The real services, the real web services are over here on the right hand side. The different service capabilities and endpoints which clients use to programmatically access the data. Yeah, so if you're going into production, you probably want to configure your, you know, your Apache or something to hide these configuration screens. There's no reason to share that with the public. My examples use natural earth. So I'm going to walk through how GeoServer is set up to begin with your data is collected into individual workspaces. These are like folders which you can use to organize content. There's a few little tweaks I got to talk about here. Each workspace is considered a distinct XML namespace for all of those little formats that really like XML because the 1990s were fun and they had good music. The workspace also has a little name that's used in a prefix when we're talking to the individual layers. So we can go through, we can hit new workspace, fill in a little bit of information and we've got a new empty workspace to work with there. One advanced thing to talk about each workspace can be its own distinct web service. So if you're supporting dozens of teams, you might want to set up a workspace for each team. Next we get into data sources. So data sources is GeoServer being connected to a directory of shapefiles or, you know, two terabytes of GeoTefs in a folder or a cloud service or a database. The data store name is internal to GeoServer, that doesn't show up on any of the protocols. That way you can change what service you're using behind a layer and none of the clients have to know. So we can go through, we can add a new data store. In this case I'm pointing it to a directory of shapefiles. So my connection parameters aren't very interesting, it's just a single path on my server. And it's the same thing here when I'm publishing a GeoTiff. I'm pointing to a single path on the file system. I should have had an example here working with a database. So pausing workspace, inside the workspace we've got various different data sources which we're using to connect to the information that's already there in our organization. For vector layers, GeoServer's publishing information is distinct layers. We've got several things you need to check when you publish. You want to make sure your layer has a name and a title. The name is actually machine readable and it's used on all the protocols and URLs. And the title is human readable. We also really need to make sure that the spatial reference system and the bounds are correct. If we don't have that information correct, clients won't be able to draw our data in the right spot. Each protocol is going to use a different term for how they publish the information. Sometimes a layer will be called a layer. Sometimes it'll be called a feature type. Sometimes it's a coverage or a grid coverage or a tile set. It really just depends on what protocol the client is using. So in this case I'm going to the culture data store I set up before. I'm choosing one of the shapefiles for my directory of shapefiles and I'm hitting publish. To start out with I'm filling in the name and the title and I'm sure nobody can read that. And then I'm going through here and double checking the bounds and the bounding box. And in this case I'm generating those by having it look at the data set. Same thing for a raster data layer. I can go through and publish a raster. Geotifs only have one data product inside of them. But if I'm working with something like NetCDF I might have to pick and choose which data product inside the NetCDF bundle I want to publish. Okay so next up I've got a layer group. So the most common use for a layer group is to bundle up several layers together in order to draw a base map. The layers are listed in draw order. You can also use layer groups to kind of construct a table of content structure. So like a series of folders to organize your data. So I can go to layer group, add a new layer, provide a name and a title. And then I need to go down to the layer section and add my layers in order. And that's the order they're going to be drawn in. So my raster data I want to draw first and then my vector data. And if I had point data I'd draw that on top. And that's really unintuitive for me. So this mistake of getting things in the wrong order is one of the most common geoserver kind of learning troubles. After we've got our layers we can go ahead and calculate the pounds and the coordinate reference system. It's hard to do that before we have content which is why we added the layers first. Okay take a break. How's that working for people? Going too fast can people hear me? Couple people. Next I want to talk about styling. Geoserver has a bad reputation with styling. The styling engine, the drawing engine we use from Geotools is really super powerful. But geoserver out of the box supports a format called SLD or Style Layer Descriptor, which is all done in XML. But here's the secret. Nobody wanted you to write that by hand. We really want you to use a tool like QGIS or Geostyler or any of the other tools to generate your SLD. And we've started to see extensions developed where people have human readable CSS or YAML style definitions, which makes Geoserver a lot more accessible to people. So we really recommend if you're a human you write your style in something intended for humans. There's built-in styles provided. One thing that's interesting is each workspace has a style folder, and that's where you're going to store any icons or fonts that you want to use for your cartography. So I can add a new style. In this case I'm adding it to my workspace. I'm calling it map color nine. And I'm choosing the YSLD format, which someone very carefully thought of as a joke. But it's a YAML version of the SLD concept. So I can hit generate. The Geoserver style editor lets you look at a layer preview as you're updating your style. So I'm going to go ahead and switch over to the preview tab and have a look. I'm going to fill in a little snippet of YAML here where I'm going to recode map color nine from one to a color from two to a color and so on. So this is a very, well, it's more human readable than XML. So this is a little bit more approachable. Here's what that looks like. And then finally I can go over to the publishing tab and I can associate this style with my state province shape layer I published earlier. And here's what that looks like. So it's my hope that we've managed to introduce four concepts. Workspace, which is a folder to organize your things. Data stores, which are used to connect you to the data in your organization. Layers, which is where you published individual data products. And styles where you're choosing how you want those drawn. Okay. Just checking time. I'm not too bad for time. So I've got a great question. How does it work? Who here is programmed in Java before? Okay. How many people have used Spring? Okay. So GeoServer is a Spring-based application. It didn't used to be. GeoServer used to be done in a system called Struts, I think. Is that a system? I'm trying to forget it. It was terrible. The other interesting framework we use is one called Wicket. Has anyone used Wicket before? It's a UI framework which only a Java developer could love. The reason we like it is because it's modular. And GeoServer is a very fiercely modular application. We really want all our extensions and community modules to be distinct. So people can have the code and their code can also include user interface contributions. We've got a little... So the web administration is done with Wicket and Open Layers and so on. Our REST API, we transitioned from RESTlet over to Spring Model View Controller a few years ago. The core GeoServer application is creatively called Dispatcher. So that's the thing that takes in requests and dispatches it off to the appropriate service like WMS or WCS or so on. We actually have an embedded and entirely otherwise innocent application called GeoWebCache. You can actually download GeoWebCache and install it on your own. It's a perfectly good kind of tile proxy thing written in Java, but in this case we're using it as a library. Underneath the covers, GeoServer has a catalog, which is where we store all our configuration. We also have a data directory where we were storing all those files and fonts and icons, and the resource pool represents our live connections to all the different data sources. I just wanted to bring these ones up because when we look into advanced deployments of GeoServer, people will take these components and plug in alternates. Under the covers we use Spring GeoTools and an image processing library called Java Advanced Imaging. And that's what this slide says. So we've got a lot of effort put into keeping GeoServer modular. The formal modules we have are called extensions. So these are actually part of GeoServer. They're released as part every time we make a release. They have the same version number. The only reason they're in extension is not because they're not good. It's because we want to keep GeoServer as small as possible and have you only install the things you use. So Oracle is an example of connecting to a new data type. We also have entire other services like web processing service that you could install and GeoServer would learn to speak and manage entirely new set of challenges. Collecting to cloud things like GeoMesa or MongoDB. We also have a really robust security model. So there's an extension called Geofence where it rips out the GeoServer security system and puts in a really sophisticated one where you can limit editing to just a Geofence area. And one of my personal favorite extensions is one that does vector tiles. We also have a scary kind of demilitarized zone called community modules. This dates from when we were hosted in Subversion. And so it was easier to give people a little community play area in order to support grad students and so on. Over time, we've actually found that consultants are working here. So they are doing some work in public for their customers, but they haven't yet met our requirements for documentation and quality assurance. So if you see a community module, it's an opportunity to pick up the code yourself or to see who's interested in supporting it. It's very much used at your own risk. So examples of community modules. Here's one which backs all of the catalog and data directory onto a blob store. And that's really nice if you're in Amazon Web Services. You can store all of your configuration in RWS and cluster. For example, backup and restore, pick up all of your configuration from test and deploy it into production, MapML, SAP, HANA, all kinds of stuff. So just to wrap up, we've got a project steering committee. We're part of the OSGO Foundation. So they've reviewed our processes. We try and keep things open and fair. We do have a strong history of collaboration. This project has seen many entire companies come and go. So it was started by Open Planning Project. I don't know, 2002 or something like that. The initial core team of companies was Open Planning Project, Geosolutions, Refractions Research. We've seen government departments come in and take part. So we try and keep our steering committee with a mix of skills and backgrounds. OK, so try it out. There's binary. There's a web archive. We don't have any Windows or Mac installers right now. Our build server had some vandalism last year and we haven't restored those. Docker. There's a bazillion Docker images out there, but nothing official. And there's a few companies that are willing to offer you hosting. Thanks. Maybe now or... Sure. If you don't have questions, I have questions for you, so speak up. I don't have questions. Moving features? Yes. I'm not sure. We do offer animations and lots of our raster support is temporal-based and a lot of our feature datasets can have a time component. But I don't think there's anything specific for... What do you call it? Like bearings and so on? Yeah. There are these set of OGC standards for moving features. OK. Yeah. I'm not aware of any R&D right now. I do know one of the community modules is working on the OGC APIs, for example. Those community modules are often where a lot of, like, OGC testbed work takes place. Not all of it sees the light of day. Yeah. Sir? Yes. I'm just wondering... Do you know GeoSiamL? No. OK. That's a geology format and Syro spent like 10 million teaching GeoServer how to do all that stuff. Yeah. Right? I understand. One cottage industry for consultants is writing a data store to read abnormal things so GeoServer can make them consumable by others. Maybe we should talk after. Yeah. It seems like a challenge. There was someone over here, sir? Yes. What city are you based out of? That's a great question. I'm really jet lagged, so I think I'm gradually moving east. I think I'm probably at Halifax now. No. I'm out of Vancouver Island. So go to Vancouver, fall in the ocean, go a little bit further. So Victoria, BC. But you mentioned it's a Netherlands-based company? It is. They're in a little village called Bennecom. Yeah. They just joined them, so I know nothing. Okay. Yep. The footprint? Yeah, the number is you. Oh, it's actually not as scary as you would expect. So it's been designed from the ground up to stream, so it never loads the data into memory. It's always streaming the features past. The image processing engine in particular is really good using a on-demand processing. I don't remember the right raster buzzword for that. So I've certainly run GeoServers in like 256 mags. I've seen people throw lots of memory at it and have no effect. So it really depends on your dataset how much memory would help you. Does that help? Okay. There's versions of GeoServer that have been set up as little spring boot applications for cloud. I'm not sure I recommend them. Yeah. There's a reason why not. That Java advanced imaging thing is not open source. It's a Sun binary something or other license. I actually got Oracle to donate the code to me. Actually, this guy did. So I'm trying to rescue that bit of code, but I didn't get into the Java dev room. I'm here with you. So it might take longer. Yeah.