One of the goals of IGIBS is to allow users to generate protected WMS services using SAML-based access control. The technology behind this is based onÂ prior research done in the past few years by EDINA for the EU funded ESDIN project. The ideas produced by the project have been successfully tested within the OGC Shibboleth Interoperability Experiment – see also the INSPIRE2011 page on this blog.
In order to access a protected WMS generated by the IGIBS factory tool one needs either:
A modified desktop client that supports the SAML ECP protocol.
The browser-based IGIBS mapping client.
Anyone interested in using a desktop client to access IGIBS protected services is encouraged to download the EDINA-modified version of Openjump. Further information about how the Enhanced Client or Proxy (ECP) profile works is available at OASIS.
For the above reasons IGIBS browser-based client uses the EDINA version of OpenLayers as a base. Interested parties are very much encouraged to download it and provide feedback and/or criticism for further improvements.
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.
Possible approaches to specifying cartographic rules are to:
Allow the user to upload an SLD file along with his/her datasets.
Search for existing libraries that provide an SLD Editor functionality for a WMS.
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.