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.

 

 Posted by at 18:37 Mapping Application, Techie, WMS Factory Tagged with: , , , ,  Comments Off on Web-based Cartography for the IGIBS WMS Factory tool
Jun 042011
 

One of the many goals of IGIBS is to generate Web Map Services that will be used in conjunction with INSPIRE type View Services which themselves are compliant with the INSPIRE Technical Guidance for View Services version 3.0. To that end, it made sense to take the following basic INSPIRE criteria into consideration when making our choice of tools:

  1. Support for the LANGUAGE request parameter in a GetCapabilities Request.
  2. Support for “extended attributes” including elements extending the
    _ExtendedCapabilities substitution group of the WMS 1.3.0 schema with a custom
    xsd.
  3. Support for the optional WMS 1.3.0 parameters wms:identifier, wms:AuthorityUrl and wms:LayerLimit

Up till ~3 weeks ago (May 12th) no stable release of either geoserver or mapserver satisfied any of the above criteria.

Mapserver Customisation

In order to make IGIBS services INSPIRE compliant we are using a customised version of mapserver 5.6.6. The customizations involve backporting selected features from the development tree of version 6.0 plus our own additions to add support for the LANGUAGE parameter and the extended attributes in the GetCapabilites response. The code is available for perusal here for any interested parties. It comprises a patch against mapserver 5.6.6 plus a sample mapscript wrapper that can be run as a cgi to provide an INSPIRE compliant View Service. Since Mapserver 6.0 the patch should no longer be necessary, but the mapscript wrapper is still required.

Latest Developments

On May 12, 2011 mapserver released version 6.0 and geoserver released version 2.1.0. As part of that release, Geoserver got funding from the Ordnance Survey to add support for the aforementioned INSPIRE spec as a plugin and can now satisfy all of the above criteria, while mapserver only got support for the wms:Layerlimit attribute.

Conclusion

The choice of software depends on one’s requirements. For a national mapping agency seeking INSPIRE compliance it seems that geoserver 2.1.0 is currently the best route. For the purpose of IGIBS, we will stick to the modified mapserver 5.6.6 for the following reasons:

  • Speed. Mapserver has performed considerably faster in our tests involving rendering and reprojection of geospatial data, which is crucial for the dynamically generated services of IGIBS.
  • Flexibility. Mapserver can be very easily scripted in a high level language for prototyping and experimentation.
  • Tried and trusted modifications to ensure compatibility while still being flexible enough to follow the fluid INSPIRE specs.
  • Geoserver does not yet fully support all parts of the INSPIRE TG e.g. the  “scenario 2” mentioned in the standard.

Please feel free to submit any comments.