Geoservices Implements OGC Standards for Dutch Public Works

In 2003, the RWS Adviesdienst Geo-informatie and ICT (AGI) (the advisory board for Geo information and ICT of Rijkswaterstaat) started setting up the Web based GIS infrastructure. The different RWS organizations unanimously indicated that a Web services based GIS infrastructure was needed for standardization and efficiency purposes. The implementation of this infrastructure was based on the OGC Web Services architecture. By choosing OGC Web Services, RWS AGI made sure they got technical interoperability without being dependent on a single supplier.

Problem statement

In considering the design for a Web based geo-information system for Rijkswaterstaat, the following problems had to be addressed:

• Diversity of available Web based GIS software
• Duplication of geo-information for the different applications (because there was no interoperability)
• Application functionally was 70 to 80% the same in the different applications.
• Support and management were often not adequate.
• Lack of knowledge and time for setting up and supporting applications
• Limited budgets

The goal was to make geoinformation available directly from the source. The use of open standards was a given, whereas the use of open source software to realize the OGC Web architecture was one possible choice.

Execution

Rijkswaterstaat, and the AGI especially, is both the principal and executor of the GeoServices project. Development is supervised by a consultation group from Rijkswaterstaat. The company Geodan was hired to build the GeoServices application architecture. After the inventory of needs and cost analysis were made, Geodan delivered a proof of concept, on the basis of which full implementation was done. Eventually the architecture was completed. What remains for RWS AGI are management activities and the development of new activities related to GeoServices.

Open standards used

The GeoServices project uses open standards on two levels:

• GIS standards ("technical standards"). The most important functional capability provided by the OGC standards is “publish-find-bind” based on Web Services. With this capability, the services of a GIS system can be published in a catalogue, can be searched for, and ultimately can be accessed and used (for a fee or for no fee). The OGC standards that are used are the OpenGIS Web Map Service Specification (WMS), OpenGIS Web Feature Service Specification (WFS), OpenGIS Web Coverage Service Specification (WCS), OpenGIS Styled Layer Descriptor Specification (SLD), OpenGIS Web Map Context Documents Specification (WMC) and OpenGIS Geography Markup Language Specification (GML).
• Metadata standards ("semantic standards"). Metadata enables Web searches for data and services. Metadata standards used in the project are ISO 19115 for geoinformation and ISO 19119 for services. The standard GML (2.1.2) is also used as one output format for geodatasets.

Open source software used

An important part of the services oriented application architecture is the UMN MapServer, developed by the University of Minnesota (UMN). The OGC standards WMS, WFS and WCS have been implemented in this product. The UMN MapServer also supports SLD and WMC. The open source product Deegree (Latlon) is used to implement the WCS. For Client functionality the open source software product Chameleon is used. Other non-geospatial open source software components on the central platform are Apache, PHP, Tomcat and Linux.

Lessons learned

The most important lessons learned from this project are:

• Open standards fully met all expectations.
• The initial expectations for open source were not as high, but the quality of the open source applications and the responsiveness of the open source communities were surprisingly good. Less time was usually needed for bug fixes from the open source community than from regular software suppliers. Moreover, the community makes the problem more transparent, and encourages transparency, which means a better estimate of the time and effort needed for possible solutions can be obtained.
• The fast set up of the first proof of concept was another important factor for the success of the project. It worked as a booster for the project.
• Standardization requires time. When no definitive standard is at hand, it can even take too much time. This is a problem, since it slows down the project. However, in the end patience is rewarded.
• In some cases a “workaround” is necessary to make standard specifications applicable in specific situations. This requires consortium membership of the management organizations to make sure that workarounds become part of the standard.
• Supplier dependency does decrease. But the position in negotiations with closed software suppliers is much stronger.
• Management support turns out to be an important factor for success. In this project management support definitely contributed to the success.

In conclusion, it can be said that the GeoServices project was a highly successful one. It shows how open source software can be used with the same open standards that provide interoperability with a diversity of proprietary software products.