Sep 162011
 

One of the main challenges in creating a WMS factory tool is to provide an intuitive way for end users to specify the rendering rules for the data they upload. Significant progress has already been made within IGIBS in calculating on-the-fly the minimum/maximum scale which is adequate for raster data. However, The cartographic rules mandatory for rendering vector data still needs to be manually specified by the user.

It is important to clarify that this is irrelevant to the SLD functionality for rendering custom vector data provided by OpenLayers. Loading all the vector data on the browser and letting the user change their style on-the-fly is not currently possible for the big datasets we are targeting. What we need is a javascript library that can query the features of a WMS and let the user specify styling rules for each feature based on certain criteria. This is unfortunately vendor dependent as a WMS GetFeatureInfo response is not standardised.

Possible approaches to specifying cartographic rules are to:

  1. Allow the user to upload an SLD file along with his/her datasets.
  2. Search for existing libraries that provide an SLD Editor functionality for a WMS.
  3. Implement a web-based WMS styling editor for a basic subset of the cartographic requirements that can be realistically implemented within a few weeks.

The first option assumes that a geographer using the service will have to write the SLD manually or use existing desktop GIS software that can export SLD files. This defeats the whole purpose of providing users with a tool to easily distribute their data as part of a fully functional WMS service and should only be used as a last resort.

The second option is an attractive one since web-based cartography is both important and missing. An independent project would mitigate the development to a central place, where different developers from different projects could contribute. Unfortunately there is no obvious existing tool that is feature-rich enough to provide the cartographic functionality of existing desktop software.

As a side note, there has been a promising initiative from OpenGeo to create a SLD editor that works with geoserver. A demo is available here. Unfortunately, after two years of development it does not appear mature enough and had no stable source code releases. Furthermore, it depends on openlayers and has therefore other shortcomings like the lack of support of multiple symbolizers per feature which is slated for the 2.12 release of OpenLayers.

The third option is the most reliable one for the short-term (i.e. next couple of weeks) and that’s the approach we are following. One can start with the basic rendering functionality using the most common styling rules: colour, width and transparency. Afterwards, a more extensive styling application can be developed to provide a long term solution to the problem of web-based cartography.

Please feel free to submit comments or suggestions bellow.

 

Sorry, the comment form is closed at this time.