The State of GeoServer
•Descargar como PPT, PDF•
1 recomendación•1,987 vistas
2011 marks the 10 year anniversary of the GeoServer project with 2010 - 2011 being the most successful year yet. GeoServer continues to grow with an active community and expanding user base. This presentation takes the pulse of the project with a status report of how GeoServer is doing and what to expect in the coming future. The presentation will start with a "year in review" overviewing some of the new and noteworthy of the past year. This year saw the coming of GeoServer 2.1, a major milestone for the project that brought some exciting new features along with it. Cascading WMS, Virtual Services, SQL Layers/Views, Unit of Measure support for SLD, WMS 1.3, and WPS are just a few of the highlights of 2.1. Attend this presentation to get the entire report of what happened this past year. The GeoServer developer community continues to remain active with a number of exciting features in the pipeline. The remainder of the presentation will focus on the future with a report of the new developments currently being worked on and what new features and improvements users can expect in 2012. Whether you are an expert user, a developer, or simply someone who wants to know what GeoServer is and what it can do for you, this talk is for you.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a The State of GeoServer
Similar a The State of GeoServer (20)
Último
Último (20)
The State of GeoServer
- 1. The State of GeoServer Andrea Aime GeoSolutions Justin Deoliveira Opengeo
- 10. Project Activity
- 11. Project Activity
- 12. Two Years in Review
- 13. Rendering
- 14. Advanced Projection Handling Dateline wrapping (Plate Caree, Mercator) Cut polygons to valid area (Mercator, Transverse Mercator, Polar)
- 15. Geometry Transformations Drop shadow <PolygonSymbolizer> <Geometry> < ogc:Function name=" offset "> <ogc:PropertyName>the_geom</ogc:PropertyName> <ogc:Literal>0.00004</ogc:Literal> <ogc:Literal>-0.00004</ogc:Literal> </ogc:Function> <Geometry> </PolygonSymbolizer>
- 16. Geometry Transformations Pointed Arrows <PointSymbolizer> <Geometry> <ogc:Function name=" endPoint "> <ogc:PropertyName>the_geom</ogc:PropertyName> </ogc:Function> </Geometry> <Graphic> <Mark> <WellKnownName>shape://carrow</WellKnownName> </Mark> <Rotation> <ogc:Function name=" endAngle "> <ogc:PropertyName>the_geom</ogc:PropertyName> </ogc:Function> </Rotation> </Graphic> </PointSymbolizer>
- 17. Rendering Transformations <FeatureTypeStyle> <Transformation> <ogc:Function name="gs:Contour"> <ogc:Function name="parameter"> <ogc:Literal>data</ogc:Literal> </ogc:Function> <ogc:Function name="parameter"> <ogc:Literal>levels</ogc:Literal> <ogc:Literal>1100</ogc:Literal> <ogc:Literal>1200</ogc:Literal> <ogc:Literal>1300</ogc:Literal> <ogc:Literal>1400</ogc:Literal> <ogc:Literal>1500</ogc:Literal> <ogc:Literal>1600</ogc:Literal> <ogc:Literal>1700</ogc:Literal> <ogc:Literal>1800</ogc:Literal> </ogc:Function> </ogc:Function> </Transformation> </FeatureTypeStyle>
- 18. SLD Parameter Substitution <Mark> <WellKnownName> <ogc:Function name="env"> <ogc:Literal>mark</ogc:Literal> <ogc:Literal>square</ogc:Literal> </ogc:Function> </WellKnownName> <Fill>#FF0000</Fill> </Mark> Normal output ...&env=mark:star
- 19. Unit of Measure Support 1:20K 1:10K 1:5K
- 20. Unit of Measure Support 1:20K 1:10K 1:5K <Rule> <MinScaleDenominator>18000</MinScaleDenominator> <LineSymbolizer> <Stroke> <CssParameter name="stroke-width"> <ogc:Literal>1</ogc:Literal> </CssParameter> </Stroke> </LineSymbolizer> </Rule> <Rule> <MinScaleDenominator>8000</MinScaleDenominator> <MaxScaleDenominator>18000</MaxScaleDenominator> <LineSymbolizer> <CssParameter name="stroke-width"> <ogc:Literal>2</ogc:Literal> </CssParameter> </Stroke> </LineSymbolizer> </Rule> <Rule> <MaxScaleDenominator>8000</MaxScaleDenominator> <LineSymbolizer> <Stroke> <CssParameter name="stroke-width"> <ogc:Literal>4</ogc:Literal> </CssParameter> </Stroke> </LineSymbolizer> </Rule>
- 21. Unit of Measure Support 1:20K 1:10K 1:5K <Rule> <LineSymbolizer uom="http://www.opengeospatial.org/se/units/metre" > <Stroke> <CssParameter name="stroke-width"> <ogc:Literal>5</ogc:Literal> </CssParameter> </Stroke> </LineSymbolizer> </Rule>
- 22. Label Obstacles <PointSymbolizer> <Graphic> <ExternalGraphic> <OnlineResource xlink:type="simple" xlink:href="..." /> <Format>image/png</Format> </ExternalGraphic> <Size>32</Size> </Graphic> <VendorOption name="labelObstacle">true</VendorOption> </PointSymbolizer>
- 24. Raster
- 25. Faster Raster Reprojection Piecewise linear approximation
- 27. Non Georeferenced Rasters EPSG:404000
- 33. Web UI
- 34. Web UI CRS Area of Validity Display EPSG:32612, UTM 12N EPSG:32614, UTM 14N
- 35. Web UI Log viewer Legend preview
- 36. Web UI Graphical file chooser
- 38. Projections Mollweide Eckert IV Winkel Tripel Robinson Equidistant conic
- 39. Web Map Service (WMS)
- 41. Time and Elevation ...&request=GetMap &time=2001-08-01T18:00:00Z/2001-09-01T00:00:00Z ...&request=GetMap &time=2003-08-01T18:00:00Z/2003-10-01T00:00:00Z
- 42. Animation Albacore Tuna catches, 1986 to 2000. (Params injected in a complex sql view computing each pixel) ...&request=GetMap &format=image/gif;subtype=animated & aparam = viewparams :YR_TA & avalues =1986,1987,...,2000 &format_options=gif_loop_continuosly:true
- 43. Animation ...&request=GetMap &format=image/gif;subtype=animated & aparam = bbox & avalues =-1800090, -1650,1490...
- 44. WMS Cascading
- 45. GeoWebCache Transparent caching Disk usage control
- 47. Web Coverage Service (WCS)
- 49. WCS Limits
- 50. Web Processing Service (WPS)
- 51. Web Processing Service Full extension status Lots of new processes
- 54. SQL Views Layers from SQL request=GetMap &layers=continents &viewparams=region:2
- 55. Service and catalog views per workspace Virtual Services
- 57. Control Flow
- 58. Control Flow
- 59. Cross Layer Filtering <wfs:Query typeName="sf:bugsites" > <ogc:Filter> <ogc:Intersects> <ogc:PropertyName>the_geom</ogc:PropertyName> <ogc:Function name=" querySingle "> <ogc:Literal> sf:restricted </ogc:Literal> <ogc:Literal>the_geom</ogc:Literal> <ogc:Literal>cat = 3</ogc:Literal> </ogc:Function> </ogc:Intersects> </ogc:Filter> </wfs:Query>
- 62. What's coming?
- 65. Oh Wait! It's trivia time. What was the original name of the organization that founded GeoServer? ?
Notas del editor
- <introduction> Originally I had planned to co-present this talk with Andrea Aime, but due to some unfortunately circumstances Andrea was not able to attend the conference this year. Anyone who has posted to the mailing list, or filed a bug report undoubtedly knows of Andrea. He is a very prominent figure in the GeoServer community. Andrea is a technical lead at GeoSolutions, and also sites on the GeoServer PSC. He will definitely be missed at the conference this year. This is a talk that has more or less been given a few times before, with the same format. Generally we start out by gauging the overall status of the project, the health and activeness of the community, as well as talk about any major milestones that were achieved over the year. And then the rest of the talk is really a year in review, where we go through major features and improvements that have been added over the year. Actually at last years conference this talk was not given, so this is sort of a two year review if you will. With that said there is lots of content to get through to let's jump in.
- With an open source project like GeoServer there are a number of factors that contribute to the health of the project. The most important, more important than the software itself, or any features that it might contain, is the community around the software. By community I mean the users who download and use the software, post questions to the mailing list, and file bug reports. The community also includes the developers who actually work on the software, adding new features, fixing bugs, etc... It also includes the organizations who fund that development, or those organizations who have developed their general business model around providing products and services based on geoserver, and help to further that development. So we will start off by trying to gauge the activity of the community, comparing to past years. First up is mailing list activity. This is measuring how many posts were made to the geoserver-users forum this year, compared to the previous two years. Now, before we go any further I will just say that the 2011 numbers obviously don't include the entire year, only the first 8 months. So because of that we also include a slide that also includes projected numbers for the 2011.
- And as we can see we are pretty close to previous years in terms of mail traffic. Also included in this graph is the emerging number of posts tagged &quot;geoserver&quot; that are appearing on the gis.stackexchange site. We are seeing more and more activity happening there as well.
- Sticking with the mailing lists we look now at list membership, rather than traffic. And pretty much across the board the numbers are up, in some cases significantly. With the addition of a new language, Japanese, added since 2009. The one exception however is the Chinese list, which I wasn't able to get numbers for this year. The forum seems to have been moved, or perhaps it has just folded, not sure. If someone has any info about that it would be great to know.
- Moving on we look at traffic in the issue tracker where we analyze both the number of issues or tickets opened, vs the number that resolved or closed. And here tickets include bugs, new features, improvements, and other tasks. So not just issues per se. These numbers come out of JIRA hosted by codehaus, a hosting site that generally provides free use of the confluence tools, such as jira, to open source projects. We see that in general traffic is down from past years.
- Even when looking at the projected numbers we see we are well down this year from 2009. So I guess we just have to hope this means that the software is getting more mature and so good that bugs are way down. Realistically though I think the most important thing to note on this slide is the comparison between opened tickets vs closed tickets. This gives us a good idea of how responsive developers on the project are to issues opened by users, which again is a very important things for any software project. And in general GeoServer does pretty well. This year opened vs resolved are pretty close.
- Next we look at downloads. These are numbers coming from sourceforge, which is where GeoServer downloads are hosted. Now while I would love to think that GeoServer is approaching 300,000 downloads I know this not to be the case. These numbers are pretty significantly exaggerated due to things like download accelerators, multiple downloads of a single file, etc... So we'll take the numbers on the left with a pretty good grain of salt.
- What we will note is the relative differences between the years. And we draw one of two conclusions. Either (a) geoserver is being downloaded by users as the years go by or (b) the same users are downloading geoserver more and more, or I guess also (c) those download accelerators are exaggerating the numbers by a greater factor as the years go by. Tough to say. Again we'll be optimistic and hope for the first.
- Next we look at major releases of the project. This only includes official point releases, not alphas, betas, or milestone releases. In general we are definitely seeing that release frequency is down. However this is not necessarily a negative. In 2009 the PSC decided we were going to try and keep up a 1-2 month release cycle, which we did a pretty good job of. However over the past few years that has trailed off and we have moved to a less scheduled and rigid release schedule. Releases now come more organically if you will. Again this can be a good or bad thing. ON the one side it means that users wait a bit longer for things like bug fixes and new features that come out. Which for those who like to live on the bleeding edge, i guess can be a negative. However for users and organizations that have larger deployments, an upgrade represents a significant amount of work. So fewer releases means longer maintainance cycles for older releases which is a good thing for users who usually lag behind a few releases.
- And lastly we will look at a more developer oriented metric, and that is commits to the geoserver subversion repository.
- And we are more or less on par with 2010, and down from 2009. With commits it is really hard to draw anything good or bad from these numbers, if anything it is more just a fun number to look at. The numbers can be impacted by many things, so it is hard to say if a drop/rise is a positive or a negative. But thankfully we are still seeing commits happen, which means the software is being worked on and maintained, which is a positive.
- So that gives us a look at how the community is doing. All in all things are looking pretty good. Now let's move on and talk about what has happended over the past two years, in terms of new features, and project milestones. The last two years have brought 5 releases, 1 major release, 2.1.0, and 4 minor releases. Across those releases spans a lot of significant new features and development. So I'll spend the remainder of this talk going over many of those new features (too many to do them all), and then give a quick look as to what is on the horizon for GeoServer. I do have a lot of slides to go through, I actually probably won't get through them all so I will go pretty fast here in order to leave some time at the end for questions.
- Will start with the exciting and visual stuff, improvements the rendering engine. For those of you familiar with GeoServer you know that GeoServer uses SLD as its styling engine. While SLD does encompass a lot, it does not do anything. So many of the things that have been done recently supplement or extend SLD, allowing for more than the spec proper allow for. So much of this is geoserver specific, and won't be supported by other WMS services that support SLD. That said, the next version of SLD 1.1, along with the symbology encoding specification, do allow for some of this stuff. And actually some of what we show here are things that have been poached directly from SE 1.1.
- We'll start with some improvements that allow GeoServer to better handle dateline wrapping issues. Historically geoserver has not done when it comes to dealing with polygons that cross the dateline, resulting in scrambled polygons and other strange looking affects. This happens because of the way that geoserver/geotools internally handle reprojection of these geometries, one point at a time. And when getting to a point that actually crosses the dateline the cycle nature of the math used moves that point to the other side of the world unintentionally. So the work done here will now actually detect this case, and cut the shapes up before the reproduction occurs. The end result looking like the cut up polygons you see on the lower right. Extending this idea it is possible to achieve the continuos map wrapping affect, often referred to as the google maps effect. The same improvements allow us to achieve this simply by applying an offset (the circumference fo the world) to the cut up polygons on the other side of the dateline. Special thanks to FAO for funding this work.
- Next up is a feature that allows one to apply a transformation (via SLD) to geometries before rendering them. Historically we have been constrained with applying only transformations that SLD allows for, which was pretty limited. Pretty much just applying offset for rendering points. However with geometry transformations one can specify any arbitrary transformation function to apply before rendering, and have the result of that function be rendered rather than the original geometry. To illustrate with an example we can use this to produce a drop shadow effect. On the left we have a regular polygon layer (buildings in this case) styled in a pretty typical manner. On the right however we have that same layer rendered on top of a second layer. In this second layer instead of rendering the original geometry we render the geometry slightly offset. The SLD snippet you see here is what accomplished this. In SLD a symbolizer element allows you to specify a &quot;Geometry&quot; element in order to choose which geometry to render. Especially handy when your data has multiple geometry fields. We extend this element to allow for specifying an arbitrary expression, in this case a function. In this case a function that takes the original geometry and applies the offset to it.
- Similarly in this example we use a function called &quot;endPoint&quot; to extract the the final point of a linear geometry. By rendering that point with a symbol, in this case an arrow, we can render the line with an arrow endpoint. In this case we actually use a second function when specifying the graphic to align the arror properly. Just a few examples of what is possible with geometry transformations. Special thanks to Andrea who actually carried out this work for the most part in his spare time.
- Geometry transformations are great, but they are limited in a couple of ways. First, they are limited to vector data... so don't apply to raster rendering. Second they operate on a geometry by geometry basis which limits their usefulness. Often in order to do meaningful transformations access to a collection of features at a time is necessary. Rendering transformations allow for both. In essence they allow us to take a set of vector or raster data as input, do some arbitrary transformation or calculation on, and return another set of data. Well this is a concept that is actually quite similar to another idea in GeoServer that I will cover later, the Web Process Service. Long story short rendering transformations provide a bridge from an SLD to the WPS world, allowing one to specify that rather than a layer be rendered directly, that the result of a process ran on that layer be executed instead. As an example consider generating contour lines from a dem layer. The two pictures on the left show a simple dem layer rendered normally, and then the same layer rendered with our transformation on top of it, the countour lines labelled with elevation. The partial SLD that does this is located on the right. Rendering transforms add the additional &quot;<Transformation>&quot; element to the &quot;<FeatureTypeStyle>&quot; element. Within that element we specify a function to execute. This function is actually just a wrapper around a WPS process. In this case the process is named &quot;contour&quot; and generates contour lines from a DEM, allowing one to specify discrete elevations to generate the lines for. Special thanks to NURC (Nato Undersea Research Center) for funding this work.
- Continuing on we move to a feature that allows for the parameterization of an SLD style. Essentially creating &quot;placeholders&quot; in an SLD document, and allow values for those placeholders to be specific on the fly. Again we make use of the magic of filter functions to make this possible. And in particular a special filter function called &quot;env&quot;, which is short for &quot;environment&quot;. Basically this functions purpose is to say &quot;give me the value of a variable named x, and obtain it from the executing environment&quot;, essentially the same purpose as an environment variable. In the example here we have a simple point SLD, in which we parameterize the name of the shape or mark to use the render points. We invoke the env function with the variable name &quot;mark&quot;, and specify a default of &quot;square&quot; to fall back on in cases where the environment does not have a value for us. The output on the left is a normal wms request against this style. And not to interestingly we get a square (which is our default) rendered. But on the right we execute the same request but with a special additional key value pair called &quot;env&quot;. The value of which are variable names/values we want to inject into the environment for this request. Our SLD then picks up this new value and the points are rendered as expected, with a star rather than a square. This feature allows us to create SLD documents more dynamic in nature. Big thanks to Andrea once again, and also to Michael Bedward of the GeoTools team for make this one possible.
- Next up is support for specifying units for a symbolizer. By default, when we specify something like the size of a shape, or width of a line, that value is assumed to mean pixels. Which is often is not ideal when you are talking about rendering at multiple scales. Since what we are rendering is typically a real life object, we want that object to grow/shrink accordingly as we move closer and further away from it. But specifying values in pixels means that line will always be x number of pixels, regardless of the scale of the map.
- So typically how have we gotten around this. Well we have been forced to duplicate styling rules at discrete intervals. Here is an example in which we create three rules, each with different scale constraints, and grows the width of lines as scale increases.
- However, what if we could just specify one value, in ground units. Basically saying i want this line to be rendered x meters or x feet wide and letting the rendering engine do the work of converting that into an appropriate value in pixels based on scale and the underlying map projection. Well this is exactly what unit of measure support in SLD allows us to do. We replace many rules with a single rule that can accomplish the same thing. Much more concise and convenient. UOM support is a feature that is taken from the SLD 1.1 spec and backported verbatim for use with SLD 1.0. Special thanks to a number of agencies who funded this work. The initial set of patches was provided by Tecgraf from Brazil., with SWECO and the city Malmo in Sweeden sponsoring further improvements and the backport of the patches to the stable series
- Next up are label obstacles which are a way to tell the labelling engine to respect some previously rendered artifact. Much the same way that label rendering is aware of previously rendered labels, so that we don't get two labels on top of each other, this allows for the same with non labels. For example, consider the map on the left. We some roads with labels, and some points representing transit stops. In many cases the road labels are drawn directly on top of the transit stop icons, which is undesirable in this case. Again this is because the labeller is only concerned with a. the roads being labelled, and b. other labels. However, with the use of a &quot;vendor option&quot;, which is essentially a hint, we can tell the rendering engine that hey, these icons should be labelled on top of. And the result is what we see on the right, no more obscured transit stops. Special thanks to Trimet, the portland transport authority, for funding the development of this feature.
- I could probably spend the entire rest of this talk discussion new rendering features, but in the interest of moving on i will try to summarize the rest here. The ability to offset labels for a point geometry was something added as of recent. The ability to manually specify the DPI to use when rendering a WMS request, rather than use the build in default. This is handy for print applications, which we actually have to print rendered maps on paper. The default dpi is appropriate for screen media like computer monitors, but a higher dpi is required when creating a pdf to print for instance. And last but not least we have seen generally rendering performance continue to get better.
- Moving on from rendering we move to a number of improvements made to GeoServer raster support.
- First up is much improved performance of raster reprojection. Understanding this one requires a bit of explanation. If you google this one you will find a full technical report about how it works. That said, historically the way geotools/geoserver did raster reprojection was to take every single point on the source raster, and apply the transformation to it to calculate the point on the reprojected raster. Now while this is a very accurate method, it is also very expensive. Especially since most map projections contain very complex mathematical functions. The idea is basically one of locality. If I take two points side by side in the source raster, and compare them with the computed points in the reprojected raster, chances are they will be close. And we could have used the result of the first calculation to approximate the result of the second. It is similar to the idea of approximating a curve with e sequence of straight lights. A concept known as piecewise linear approximation. Essentially the source raster raster is broken up into a number of areas, and for each area we compute a linear approximation for that group and use that rather than the original forumlas when reprojecting the individual pixels. Obviously this can work better in some cases than others, so this is accompanied with a method of calculating the error introduced by the linear approximation, and this is what is used to drive the algorithm used to divide up the source raster.
- This optimized algorithm was benchmarked against the original and as you can see from the graph here, there is a significant improvement. This graph measures throughput of requests that involve raster reprojection, with an increased load in terms of concurrent requests. As you can see the red (optimized) line scales significantly better (about 5 times).
- Continuing along a new feature is support non-georeferenced images. Examples might include things like scanned maps, building drawings, etc... GeoServer can now server up such images. Internally geoserver uses a coordinate reference that is essentially just a 2D cartesian plane. The identifier given to this CRS is &quot;EPSG:404000&quot;, the &quot;404&quot; meant to symbolize &quot;not found&quot; or &quot;no projection&quot;. This screenshot shows a railway system drawing being served up via GeoServer WMS to an openlayers map. Using the regular controls we can zoom and pan around the image. This work was funded by SFMTA, the municipal transport agency for San Francisco.
- The image mosaic format or coverage store has also seen a lot of improvements. It is now possible to attach attributes to the various tiles in a mosaic. Which enables the ability to filter based on those attributes, much like you would filter against an attribute in a vector dataset. ** more on attaching attributes Filtering by time and elevation is supported as well. I will talk a little about time and elevation support for WMS in a few slides. And finally, it is no longer necessary to store the mosaic index in a shapefile on the disk next to the tiles. It can now be stored in a database, or any other datastore format supported by GeoServer. This can be significant with regard to performance in very large mosaics.
- From image mosaic to image pyramids. The image pyramid coverage store is now significantly nicer to use. Before it required the tiles in the pyramid to be formatted in a specific structure. As well it required that mosaic index files be in place for the various pyramid levels. Now though the image pyramid format will recognize the output structure of the commonly used gdal_retile command. And build the mosaic indicies accordingly.
- Next up is the geoserver web administration application. A few nice additions have been made to make the app even more useful.
- The coordinate reference system list that allows users to scan through the supported projections and crs's in geoserver, now includes a display that visually shows the valid area for that projection. Here we see two UTM projections, and the area of validity highlighted in red. Thanks to Gabriel Roldan for working on this feature during a code sprint
- Another improvement is located on the layer publishing page, which allows one to configure the style, and other metadata for a layer. The style chooser now will render a preview of the legend for the style chosen. This makes it easier to inspect the contents without having to open the style editor, or preview the map with the layer preview, it can be done inline. Thanks to Gabriel Roldan for working on this feature during a code sprint. Also of much utility is a log viewer that makes the server logs available right from the admin app itself. Before users had to hunt down the location of the file, and then view it in an external editor. No longer. Thanks to Andrea Aime for working on this feaure in his spare time.
- And last but not least is a file chooser that can be used to graphically navigate for files on the server file system when configuring a file based data source like a Shapefile or a GeoTIFF. Makes life a bit easier for users rather than making them enter in file paths manually. This feature has been developed by Andrea in his spare time and later picked up and improved by OpenGeo for the Suite layer importer
- Over the past few releases a number of new map projections are now supported by GeoTools, and by extension geoserver. Each of these really deserves its own slide about the properites of each projection, but in the interest of time I won;t go into any details here. But another special thanks to FAO for funding the development to support some of these additional projections.
- Continuing on we move to the GEoServer web map service, and a number of new features added there.
- First up is support for time and elevation via WMS. It is now possible when configuring a layer to explicitly chose an attribute which represents time, or elevation.
- Once a layer is properly configured is possible to issue requests specifying time and elevation constraints, as defined by the web map service specification. On the previous slide we configured a layer representing hurricane/storm location and intensity over time. And with that we can query and visualize the data at specific times. Or over specific time intervals. These screen shots show the different storms occuring over 1-2 month time frames. Special thanks to Lamma, the weather authority for Tuscany Italy, for funding this development.
- Another recent and very cool addition to WMS has been an animation endpoint. This allows for a WMS request not only to supply a single static frame, but a collection of frame or in a format that supports multiple frames like an animated gif. The general idea is that a request specifies multiple values for attributes to filter on. Internally the WMS will perform multiple queries for each value and render them as different frames in the resulting animation. In this example we have a dataset that tracks tuna catches over a time period of 1986 to 2000. And specifying a series of dates in the request we see how the data changes over those years.
- Continuing on with animation, the previous example used attribues in the dataset to produce multiple images to render. But the animation endpoint is not limited to data attributes, it can use any wms request attributes, for instance bounding box. In this case we tell the animator to use the query bounding box and different values/locations. The end result is an animation that pans around the globe. Special thanks to FAO Fisheries for funding this development.
- Next up for WMS is the ability to cascade other WMS. Very similar in nature to how geoserver has support for cascading WFS, setting up a datastore backed by an external WFS server. In much the same way, it is now possible to add a &quot;WMS store&quot;, in which one specifies the url to an external, compliant WMS. An interesting use of this functionality is in conjucntion with some of GeoServers caching abilities, via GeoWebCache. Which I will talk more about on the next slide. But the jist is that one can add a cascaded WMS, and then turn on caching for that layer to start generating a file cache for that server. Or similarly one can use other WMS features like watermarking, which allow one to overlay an image or a logo onto a rendered image. This can be useul in cases where a watermark is desired but the source WMS may not support watermarking. This work was funded by the university of Perugia, in italy. Special thanks to them.
- I previously mentioned before GeoServer's ability to act as a tile cache via GeoWebCache. While this is not a new feature some notable improvements have been added. The first is the ability to transparently cache via the regular WMS service. In the past in order to make use of the internal tile cache one had to access the WMS through a specific geowebcache WMS endpoint. No longer. Now there is an option to transparently cache through the regular WMS interface. Which means if a client like openlayers or some other tiling client make requests that conform to a well known tile grid, they will be transparently cached without the need to separately configure geowebcache. In addition to this, is the ability to control how much disk space is used in order to store tiles on the disk. Anyone who has set up a tile caching service knows that disk space can fill up very quickly. Through geowebcache disk quota functionality it is now possible to set limits on disk space, and have older tiles, or tiles that are not drequently accessed be removed from disk to make space for new tiles. Special thanks to Gabriel Roldan, who implemented these features mostly in his spare time.
- And to wrap up new WMS features, a few more things very worthy of mention. At the top of the list is support for WMS 1.3, the latest version of the WMS spec. GeoServer now talks WMS 1.3, thanks to funding provided by the UK ordanence survey. Special thanks to them for that. Along with WMS 1.3 comes support for the next version of SLD as well. SLD 1.1, and the related specification Symbology Encoding 1.1.
- Sticking with OGC service we move onto the Web Coverage Service.
- For those not familiar with WCS, it is the equivalent of WFS, but for raster data. So with WCS rather than getting back a rendered or styled map, what you are getting at is the raster data under that map. Historically client support for WCS has never been great, at least not compared to some of the other OGC services like WMS and WFS. So this leaves users with a service that is kind of difficult to use, hacking out XML requests in order to utilize the WCS service. Well thankfully now we have the WCS request builder, which allows us to graphically build up and execute WCS requests via the web form you see here. It allows you to choose the coverage, bounding box of the source to query, projection of the result to return, etc... and allows you to either (a) execute that request, or (b) get at the raw XML for the request to use in some other application. Special thanks to Andrea once again to spent much of his free time on this one.
- When it comes to OGC in production, it is practically necessary to constrain the services somehow. Otherwise you face a public service quickly being rendered unusable by requests that are simply trying to use too many resources of the service. So for instance, with the WFS service in GeoServer you can see a global maximum number of features that may be returned by any single request. For WMS we can set limits on things like how much memory is used to render a map. And also a limit on how long the server may spend rendering the map before aborting. So this is basically the parallel but for WCS. If we look at the anatomy of a WCS, its pretty simple. It takes some input coverage data, and based on request parameters performs a few operations such as selecting individual bands to read, scaling and other transforms, reprojecting to required output projection and then writing the final raster to return to the user. WCS limits allow you to specify constraints on the amount of data read from the source, and the amount of data generated for the result. This prevents things like a client making a request that just tries to read too much source data, or the client specifying an output coverage size that is just too big. Special thanks to MassGIS, the GIS office for the state of Massachussets.
- Moving on we get to the new kid on the block when it comes to OGC services in GeoServer, the Web Processing Service, WPS.
- I won't get into too much detail about the details of WPS, but essentially it allows for executing arbitrary processes on an arbitrary source of input data, and return arbitrary result. By design the service is very underspecified, and open ended, and this also makes what you can do it very powerful. Typically WPS is used in conjunction with other OGC services. We saw before the example of generating contour lines for a DEM raster. This works by feeding a contour process data from a Web Coverage Service, running the process, and then returning the resulting lines as vector through a WFS. This is typically how a &quot;component&quot; or standalone WMS would work. GeoServer's take on WPS is more of an integrated service. And by integrated I mean integrated with other GeoServer facilities such as the catalog, and the other OGC services like WMS and WFS. For instance rather that input of a process be data from some other service, input to a process can simply be a layer already configured in geoserver. And by the same token the output of a process need not be a GML, it can simply be a newly configured GeoServer layer, ready to be visualized by the WMS, or readily accessed vy WFS to get at the underlying data. Again thanks to Andrea's hard work on mostly personal time WPS has reached official extension status within GeoServer, which means its fully supported and released along with the main GeoServer release.
- As an example showing an application of WPS, we will use geo-rectification as an example. This was an application built for the SFMTA, who funded the work for the georectification process work. For those not familiar with the process of geo-rectification a simple explanation. Essentially it is the process of taking a non spatial image, that is an image has no geo location information associated with it, and turning it into an image that does have geolocation. This works by selecting points in the source image, called control points, and assigning those points a geolocation. Then using various methods of transformations (there a few) the original image is warped accordingly and accompanied with the necessary information to geolocate it. So here what we see is on the left, a map of a non spatial image (we saw this before when we talked about supporting non-georeferenced images). The image depicts ocean avenue (somewhere in san francisco) along with some intersecting streets. On the right we see a map of the same area. The app allows for adding control points on the non geo image, and associating those with a location by placing matching points over the map. Once we have a few differnet control points we can run the georecitification process.
- And the result shows the wrapped image (now with location) overlayed onto the map. Just an example of the many many things that are possible with WPS. Again thanks to SFMTA for funding the georectification work.
- Moving on from OGC services we'll wrap up by covering a few more very exciting features. First up SQL Views. Historically with GEoServer when adding a layer from a database like PostGIS or Oracle, you just pick the table and that is it. Via WMS and WFS you can do some filtering/sorting/etc... to control how the data is queried, but its limited. Certainly not as powerful as specifying the SQL itself. Well SQL layers allow you to define the layer itself to be an arbitrary query, rather than just a static table. What's even more powerful is the ability to parameterize that query, essentially performing dynamic queries on the fly. We saw this before when showing the WMS animation example that involved the tuna catches. Basically an SQL view was used with a parameter for the YEAR, to create a data source that continuously changed it's query based on the year specified in the request. And here is the same. In the top left we define the query to be used as the data source. In this case we have a table that represents countries in the world. Each country has a region attribute that determines which continent the country is part of. We define the view to be the union of countries in a single continent, parameterizing the query with the region. The map on the upper right shows the result when we specify region 2, which is Africa. Very powerful feature. SPecial thanks to OBIS for funding this work.
- Next up is virtual services. Anyone who has set up an OGC service with geoserver knows that the service publishes every layers, with not very much control with regard to only having the service publish a subset of layers. While it is possible to do by setting up roles and security rules for particular layers, it is not always ideal. What virtual services does is create multiple &quot;virtual&quot; endpoints within the global service. These virtual endpoints correspond to workspaces configured on the server. The virtual service only publishes those layers that are part of that workspace. This allows one to partition up the global service into multiple virtual services, controlling the layers published by each via workspace. For instance, let's say we want to set up some OGC services to two sets of users. One set is interested in only vector data, so they only need WFS, and WMS for visualization. THe other set is only interested in some raster data, so really only need WCS. By splitting up the data into two workspace, here topp and sf, we can separate the two sets of data by service, providing our users with different virtual endpoints. Thanks to landgate, the land information authority in western australia, for funding this work.
- Onto another interesting extension, control-flow. I mentioned on a previous slide that when setting up OGC web services in production it is essential to properly protect the service from misuse, or possibly even malicious users attempting to overwhelm the service with a DOS attack. Well control flow allows us to do this. Essentially what control flow allows us to do is set limits on how much concurrent use the server may handle. For instance perhaps we have provisioned our service so that it really can n't handle more than 20 concurrent users at a time. But we often hit peak times which can see up to 100 concurrent users. With control flow we can essentially say just that, that no more than 20 concurrent requests at one time are possible. ONce that limit of 20 is reached additional requests are queued until a spot frees up. Queued requests use up minimal resources compared to a request executing a GetMap or GetFeature request for instance. Control flow allows for setting up global limits, as described abobe, or limits based on a particular service, operation, even output format. Also things like setting a limit on how many concurrent requests a single user may issue. This extension is really a must for any server running in production.
- The cross layer filtering extension is also an interesting. Often users ask for the ability to do WFS requests that involve multiple layers on the server. Unfortunately this has generally not been possible. WFS 2.0, which supports joins, is coming but not quite here. Well this extension allows one to specify filters that can access data from other layers than the one being queried. A classic example is trying to determine a set of features that fall within a particular boundary or polygon. In this example we have a query against the well known spearfish dataset. We have a restricted area (cat == 3). And want to return all the bugsites that fall into that area. Again making use of the ever so useful filter functions, we call a filter function called &quot;querySingle&quot;, essentially queries the layer we want to get the area from. Another function &quot;queryCollection&quot; also exists to return multiple features from a query. Very cool stuff. SPecial thanks to GeoSmart for funding this work.
- Another interesting extension that is very important in production systems is the monitoring extension. It allows one to track and analyze requests made against the server. A very useful thing for administrators to have when determine how to provision systems since it gives access to historic data about how the service is really used. From this data one can also generate some very interesting statistics such as what layers on the server are being accessed most frequently, analysis of OGC service use by service, and operation. As well as performance metrics in order to isolate those requests that are using up the most service resource, or taking the longest. Additionally it contains audit logging functionality that allows an administrator to create custom request / audit logs. Thanks to massgis to funding the initial development.
- Moving on we get to the new kid on the block when it comes to OGC services in GeoServer, the Web Processing Service, WPS.