I received a note recently from a GeoServer blog reader who wanted to show off another project using GeoServer, which I am happy to present here.
The Marine Science Institute at UC Santa Barbara and Farallon Geographics have built a public, online mapping application enabling scientists and community members to help select marine environments that they feel should be designated for conservation, recreational, and/or commercial uses. It’s called the MarineMap Decision Support Tool.
You need to have a login to make edits, but anyone can view the layers that are already there. And there’s a good amount of info too, from water quality to estuaries to locations of popular surfing sites. These layers can be exported to Google Earth as well. The designers have also helpfully created a screencast showing how to use their application.
The site is based on GeoServer and OpenLayers. But what intrigued me was the pleasing desktop-styled application. It reminded me of GeoExt, and for good reason, since GeoExt is a framework for constructing web mapping applications combining the user interface components of Ext with OpenLayers. And sure enough, it turns out that Ext was used in this application.
I don’t know about you, but I think the folks at the MSI should join up with the GeoExt project; I’m sure everyone could learn a lot.
Here’s a neat trick for those working with road maps that want to indicate traffic direction by way of appropriately pointed arrows. With text symbolizers using font characters, this is actually a snap, provided your data includes information about direction.
The New York City streets data set has an attribute field called
trafdir which specifies the flow of traffic on one-way streets:
**W** - ("with") One-way in the direction of ascending street numbers **A** - ("against") One-way in the opposite direction of ascending street numbers
With this in mind, all that is needed is an SLD with two rules, each rule drawing an arrow pointing in appropriate direction specified by the
trafdir attribute. Since arrows are included in most fonts, this can be accomplished using text symbolizers. And since the text label is oriented relative to the lines themselves (due to labels that can follow curves) the arrows will automatically be properly aligned with the road.
Here is one of the SLD rules. The other rule is identical, except for the attribute value and the specific character used.
<Rule> <ogc:Filter> <ogc:PropertyIsEqualTo> <ogc:PropertyName>trafdir</ogc:PropertyName> <ogc:Literal>W</ogc:Literal> </ogc:PropertyIsEqualTo> </ogc:Filter> <TextSymbolizer> <Label> <ogc:Literal>→</ogc:Literal> </Label> <Font> <CssParameter name="font-family">Lucida Sans</CssParameter> <CssParameter name="font-size">18</CssParameter> </Font> <Fill> <CssParameter name="fill">#a4bdc5</CssParameter> </Fill> </TextSymbolizer> </Rule>
This trick was figured out by Jordan Anderson, author of Ride The City, who goes on to say:
_"Probably the most challenging thing was getting the correct balance between street name labels and arrow labels (which are on two different layers). I became intimately familiar with all the new labeling options and made use of spaceAround, maxDisplacement, and Repeat to get something close to the right balance."_
Looks pretty good to me. Thanks Jordan!
The Google Summer of Code is upon us! (Yes, it does seem like we just finished SoC 2008.) GeoServer is once again a part of this process and we have a list of projects posted for anyone who is interested.
We are assuming all students interested in working on GeoServer will have solid Java knowledge, but no geospatial or GIS knowledge is required (although it will not hurt).
We’ve got lots of good ideas posted, from styling maps with CSS to integration with NASA WorldWind and more. The deadline for applications is April 3rd, so if you are interested in contributing, please see the OSGeo page on Summer of Code, or feel free to email the GeoServer developers list.
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!)