Here’s a guest post by Ben Caradoc-Davies and Robert Woodcock of the Australian Commonwealth Scientific and Industrial Research Organisation.
As a part of the Auscope Spatial Information Services Stack, GeoServer **complex feature** support is nearing completion. [Auscope](http://www.auscope.org.au) is using GeoServer to support its vision of developing a collaborative national geoscience spatial data infrastructure (SDI) that improves information exchange across industry and government in the earth sciences. The earth science community is challenged with increasingly complex problems in environmental sustainability, climate change, minerals discovery, and others. In investigating these challenges scientists and policy makers are increasingly combining spatial information from multiple organizations and disciplines. Scientists need to be certain of the meaning being conveyed and the assertions they can make regarding the data. It isn't sufficient to label a value as "temperature" or "sky". GeoServer, with OGC standards support, provides a basis for the exchange of geospatial information. With the addition of the **application schema** (or "app-schema", the GeoTools module that implements complex feature support) GeoServer can provide for the expression of community-agreed features and vocabularies, like those of [GeoSciML](https://www.seegrid.csiro.au/twiki/bin/view/CGIModel/GeoSciML), a GML application schema and international standard for earth science information exchange. This is important for the type of scientific and policy dialogue Auscope's community is seeking. Auscope is working with Australian government agencies and research organizations to ensure the GeoServer app-schema support is robust enough for full deployment. Auscope is also working with the [One Geology](http://www.onegeology.org) on a "cook book" for geological surveys who wish to deploy GeoServer and use GeoSciML as part of the international exchange of earth science information. AuScope Ltd is funded under the [National Collaborative Research Infrastructure Strategy](http://ncris.innovation.gov.au) (NCRIS), an Australian Commonwealth Government Programme.
For those who are on the fence about deploying GeoServer because of complex feature support, your wait will soon be over. An alpha release of GeoServer with complex feature support in WFS is expected by the end of April. For more information about this ongoing work, please see the GeoServer Improvement Proposal.
Admit it. You love visualizing data. Mere tables do nothing for you, but the minute you can turn that into a map (or a graph or chart), information comes alive.
I was recently turned on to Swivel, a website that allows you to upload, visualize, and share data. The main page provides a list of some of the more recent data collections and, like so many great websites, my response to many of those graphs was interest piqued that I never knew I had.
I looked into the process of getting data on Swivel, and saw that one of the ways of uploading data was via a hosted CSV file. And this was noteworthy, since with the release of GeoServer 1.7.3, CSV is newly available as an output format.
So, thinking of our perennial favorite, the topp:states layer (USA Population), I found my hosted version of GeoServer 1.7.3, and built the following request:
As a refresher (or for those whose eyes glaze over at long GET requests), let’s briefly go over this:
**service=wfs** - Specifies a WFS request, so we should be getting back XML, not images. **request=GetFeature** - Asks for actual feature data from a layer, as opposed to information about that data (like in a GetCapabilities request). **typename=topp:states** - This specifies the layer to apply the request to, in this case, "topp:states", the "Hello World" of GeoServer. **outputformat=csv** - This specifies the CSV output format.
Anyway, I flexed my fingers and pasted the above link into Swivel’s upload page. In a few seconds, Swivel returned with a preview of the tabular data, to make sure that it was uploaded correctly (and to check things like delimiters and titles).
Swivel appears to have gotten everything right on the first try, so I continued on. Next it asked me about title names, and to verify the data types on the columns (text/numbers/etc).
Once again, Swivel appears to have needed no steering. The next page asked for information about the data set. (And I know when adding layers to GeoServer, we never skip this step, and always fill out the Name/Title/Abstract, right?)
Then came to obligatory signup page (a smart thing to put at this step and not at the beginning, I might add) and then a long wait. Finally, I was presented with the ability to decide which columns to set as the graph. I wanted to go for public transit usage as a function of total population (basically a graph of PUBTRANS/PERSONS vs. STATE_NAME) but Swivel didn’t provide for mathematical operations that I could find, , so I contented myself with a simple population graph.
The small point to make is that GeoServer can natively interact with many different applications, often in whimsical and unexpected ways. The larger point is that our data is more than just dots on a map. A robust data set, full of attributes and good metadata, can tell us stories, and the visualizations make the stories come alive. After all, it’s the story that’s really important, not the data, when it comes down to it.
(If you link up your GeoServer to Swivel and come up with some nifty visualizations, please send us the links, so we can see what you’re up to!)
A quick note to all those who recently downloaded GeoServer 1.7.3. The release has been patched to address a bug with the user interface. The patched release can be found on the download page. The bug prevents a user from editing a feature type directly after it has been added. For those not wanting to upgrade the work around is to first add the feature type, then save, then reload the configuration. After a reload the feature type will be editable. Apologies for the inconvenience.
When the GeoServer Team announced GeoServer 1.7.3 last Wednesday, the response was quite impressive. GeoServer received the largest amount of downloads in a single day on Thursday, March 12th, at over 1,500 (normally the number is less than half that). Our website hit a new record of visits as well.
While we’re all delighted, I wonder whether it was a new feature, a bug fix, or just new people coming on board that led to the spike. As always, I’d like to know what we’re doing well and what we could be doing better.
The GeoServer team is proud to announce the release of GeoServer 1.7.3. The team has been busy in the six weeks since the previous release, with a code sprint in New York last month and a whopping 63 bugs and new features fixed and implemented (respectively, of course).
This release brings improved support for ArcSDE rasters. Previously GeoServer only supported a limited number of SDE rasters, namely 3 and 4 band UCHAR with no color map support. GeoServer now supports all sample types up to an arbitrary number of bands, with color map support. Special thanks goes out to MassGIS who provided the funding for this work, and Gabriel for his hard work implementing this feature.
In a first step towards a “multiple configurations” feature, GeoServer now allows you to filter any capabilities request based on namespace. A client can now ask for a particular subset of layers instead of having to receive all of them, which can greatly increase client performance if serving lots of layers. (This works the same way for all services, although the above link is for WCS.)
There are quite a few new extensions for GeoServer, including:
**REST** - GeoServer now allows for [configuration via REST](http://geoserver.org/display/GEOSDOC/RESTful+Configuration+API) ([REpresentational State Transfer](http://en.wikipedia.org/wiki/Representational_State_Transfer)). This opens up a whole new world for interfacing with GeoServer, whether it's [a simple metadata update, a batch configuring of layers, or a one step shapefile upload](http://geoserver.org/display/GEOSDOC/RESTFul+Configuration+API+Use+Cases).
**JDBC Image Mosaic** - This extension allows a coverage to be stored along with its pyramids in a [JDBC database](http://geoserver.org/display/GEOSDOC/Using+the+ImageMosaic+JDBC+Plugin). Special thanks to Christian Müller, who contributed this work!
**Excel** - Adding to the list of [WFS output formats](http://geoserver.org/display/GEOSDOC/WFS+output+formats), feature data can now be output in Microsoft Excel (.XLS) format. If you want tabular output, but don't need the full power of Excel, you can output comma-separated values (.CSV). CSV output is available as part of the GeoServer's core, with no extension needed.
**Directory datastore** - In addition to the REST interface, there is now an even easier way to add lots of shapefiles to your catalog. With the [directory datastore](http://geoserver.org/display/GEOSDOC/Directory+datastore), you can point GeoServer to a directory full of shapefiles and just hit go (well, Submit, Apply, and Save) and all of the shapefiles will be loaded in as datastores.
Also, don’t forget that GeoWebCache is now built in to GeoServer (it was previously an extension), so GeoServer can immediately cache WMS tiles, which can vastly improve the speed of rendering.
- GeoServer repository transition to main branch
- FOSS4G 2018 GeoServer Developers Workshop
- GeoServer at FOSS4G 2017 Boston
- REST API Code Sprint Prep
- Nov 18th Bug Stomp
- Online GeoServer Bug Stomp - July 2016 Results
- Online GeoServer Bug Stomp
- GeoServer Explorer Plugin for QGIS
- New repository and release delay
- GeoServer FOSS4G 2015 Activities