DISMAR implementing an OpenGIS compliant Marine Information Management System

Transcription

1 DISMAR implementing an OpenGIS compliant Marine Information Management System Éamonn Ó T uama, Coastal & Marine Resources Centre, ERI, University College Cork. DISMAR DISMAR (Data Integration System for Marine Pollution and Water Quality [1], a three year project funded under the EU IST Programme, is now approaching the half way point. It is an ambitious undertaking, involving some 17 partners from six countries, working with diverse observing systems such as satellites, aircraft, ships and in situ instruments, and testing multi-sensor data fusion and other data synthesis techniques. The project aims to improve the management of pollution crises in coastal and ocean regions of Europe by use of an advanced web-based information system, with a particular focus on oil spill and harmful algal bloom events. Two core tasks underpin the project those of data harmonisation, and design and development of a data management system. CMRC is responsible for implementing the data management system within certain broad constraints. Among the latter is the use of a GIS as the core component of a distributed system, complying with various OpenGIS, W3C and ISO standards, and working with Open Source software where available. These requirements are not novel, on the contrary, they mainly reflect the guidelines provided by the EU INSPIRE initiative [2] on implementing a pan-european SDI (spatial data infrastructure). This article provides an overview of some OpenGIS standards and operations used in building DISPRO, the first prototype of the DISMAR system. For a comprehensive and definitive account of the standards, the interested reader is directed to the relevant online specifications. OpenGIS In many ways, it was good timing for DISMAR. Great progress had been made by the OpenGIS Consortium (OGC) [3] and others in the move to geo-enable the web. In particular, the Web Map Service (WMS) [4] and Web Feature Service (WFS) [5] specifications had achieved the status of OpenGIS Implementation Specification, and conformant software/tools were becoming available, such as the University of Minnesota (UMN) MapServer [6] and GeoServer [7]. Moreover, the widespread uptake of XML for encoding and transport of data meant that there were many Open Source tools available for processing XML. Thus a solution for building a simple distributed GIS was available by using a combination of Open Source web server technologies (Apache HTTP server; Apache Tomcat Java servlet container), an OpenGIS Web Map Server (UMN MapServer), and Java/XML processing tools. Web Map Server An OGC conformant Web Map Service returns map images (i.e., visual representations rather than the geodata itself) in response to requests delivered over HTTP (the standard protocol of the web). There are three WMS operations GetCapabilities, GetMap, and GetFeatureInfo. The first one - GetCapabilities - is a request for information about the WMS. The GetCapabilities request takes the form of a standard HTTP request with a series of name-value pairs appended to a base URL: &SERVICE=WMS &VERSION=1.1.0 &REQUEST=GetCapabilities 1

2 In this example, the base URL, points to the configuration file dispro-wms.map of the UMN MapServer application running on the server with IP address The service required is WMS, version 1.1.0, and the request is GetCapabilities. On receiving the GetCapabilities request, the server returns a Capabilities file encoded in XML (Fig. 1), describing the service, including the content available and which request parameters to use. Fig. 1. Part of a Capabilities file returned in response to a GetCapabilities request. Note the OnlineResource element with the attribute xlink:href pointing to the base URL, and several Layer elements. Based on the information provided in the returned XML file, GetMap requests can now be issued to the server. The GetMap request has a similar format to GetCapabilities but many more name-value pairs. For example, the following request returns a 1024x768 pixel raster image in PNG format of the nature reserves layer overlaid on the bathymetry layer (Fig. 2). &REQUEST=GetMap &VERSION=1.1.0 &FORMAT=image/png &WIDTH=1024 &HEIGHT=768 &LAYERS=bathymetry_low_res,nat_reserves Other attributes of the layer that can be specified include style (STYLES), bounding box (BBOX), spatial reference system (SRS), image background colour (BGCOLOR), transparency (TRANSPARENT), time (TIME) and elevation (ELEVATION). The raster formats (e.g., png, jpeg) that are requestable are listed under the GetMap element in the Capabilities file (Fig. 1). Unlike the previous two operations, the GetFeatureInfo request is optional for an OGC compliant WMS. It returns information about a map feature at a particular point on the map. 2

3 Fig. 2. A GetMap request returns a raster image of the map layers (e.g. nature reserves and bathymetry) in the image format and dimensions requested. Web Feature Server In contrast to a Web Map Service which, upon request, generates map images, a Web Feature Service (WFS), returns actual geographic feature data, both properties and geometry, encoded in Geography Markup Language (GML) [8]. GML, an application of XML, is another widely adopted OpenGIS standard designed for the transport and storage of geodata (see also GIS Ireland Vol 7: Issue 1, Vol 7: Issue 2 and this issue for a three part introduction to GML). An OGC WFS is thus a step beyond WMS, with the potential for more complex interactions between client and server. In fact, the OGC defines two types of WFS: Basic and Transaction. A Basic WFS is a read-only one, implementing the operations GetCapabilities, DescribeFeatureType, and GetFeature, whereas a Transaction WFS also incorporates the Transaction operations providing create, update and delete functions for geodata. There is not scope here to explore the full WFS interface, in particular that of the Transaction WFS. Instead, we will take a brief look at the GetFeature operation as implemented in GeoServer. The format of the request is: request=getfeature &typename=cmrc:whiddy_sacs Note again the base URL pointing to the GeoServer application on server (running in the Tomcat Java servlet container, hence the default port 8080). The request is GetFeature and the feature type (typename) is whiddy_sacs, i.e., the Special Areas of Conservation (SACs) around Bantry Bay. Part of the GML file returned is illustrated below with The Roaringwater Bay feature expanded (Fig 3). In the Shapefile version of this map layer, there are some 176 features (equivalent to the rows in the shapefile's companion.dbf file). Each feature is encoded as a gml:featuremember element with various sub-elements to tag the geometry, e.g., gml:coordinates and properties, e.g., cmrc:name. What happens to the returned feature data depends on the client application. One very interesting and powerful combination is to transform the GML to SVG (Scalable Vector 3

4 Graphics) for viewing in a web browser with the appropriate plug-in (e.g., Adobe SVG Viewer [9]). Fig. 3. The GML file returned in response to a GetFeature request. Dispro Prototype Just being able to call up map images with one of more layers from a remote single server, while useful, is not really the point of OpenGIS web map serving. The real magic happens when we start talking to multiple, widely distributed map servers, querying what maps they can provide and then building dynamic GIS client interfaces to work with the layers. This is just what the initial DISPRO prototype, currently in development, is aiming for. There will be six nodes (North Sea/Skagerrak, German Coast, French Coast, Italian Coast, English Channel, S.W. Ireland) each providing map layers, accessible through a portal hosted on the CMRC server in UCC. Many of the map layers will, of course, only have local relevance but others will provide data of greater geographic extent. For example, satellite data for sea-surface temperature (AVHRR) and ocean colour (SeaWiFs, ESA MERIS, NASA MODIS) are processed in near-real time by DISMAR partners at Plymouth Marine Laboratory in order to monitor harmful algal bloom (HAB) events. The particular focus is the English Channel and North Sea/Skaggerak areas and the products (in GeoTiff format) are made available on their map server. Because the map server complies with OGC specifications, these georeferenced images are available for overlay with others on the DISMAR map server node located in the Nansen Environmental & Remote Sensing Centre in Bergen. The capacity to visualise algal bloom events and overlay them with other map features (e.g. sensitive areas, fish farms, habitats) offers the possibility of taking pre-emptive action to reduce damaging impacts. 4

5 Fig. 4. Integration of the various DISPRO web map service nodes. As a user selects a region (1), a GetCabilities request is issued to the other nodes via the portal integration software layer (2); the returned Capabilities files (3) are processed using Java/XML tools in the portal integration software layer, and the GIS client interface is generated and displayed (4); map layers are now viewable via the client, with the integration layer issuing the appropriate GetMap requests (5). CMRC is building the DISPRO portal using Java/XML technologies in conjunction with UMN MapServer. In the simplest scenario, a DISPRO node is only required to provide the standard MapServer configuration file (the mapfile) extended for OGC web map serving. With this information, and using the WMS operations, GetCapabilities and GetMap, the integration layer software on the CMRC DISPRO portal can create a web GIS client interface on the fly providing the standard MapServer functionality (e.g., select /deselect map layer, pan, zoom, etc.) (Fig. 4), but with the list of available map layers dynamically generated from the information returned by the GetCapabilities requests to the various nodes. When the user selects certain layers, or performs a pan / zoom action, the MapServer client issues GetMap requests with the appropriate parameters to the appropriate web map servers, and a map is generated and displayed in response. Metadata The map viewer is one way into the geodata stored on the DISMAR nodes. A metadata database is another and we are testing the efficacy of the native XML database application, exist [10], for this. This metadata catalogue is the core component of the DISPRO portal. All data products in the DISPRO system must be provided with a 'discovery' metadata companion file which conforms to an ISO [11] profile defined for the system. These files constitute the catalogue items. The catalogue is fully searchable and provides, among other elements, appropriate links into the map viewer, and where available, to the data download site. 5

6 Challenges DISMAR has ambitions that extend beyond basic web map serving. Perhaps its biggest challenge is the integration of model outputs into the GIS, in particular those of an oil drift model provided by Norwegian partner Met.no. There are also plans to incorporate Web Feature Servers, at least in their Basic WFS form, to take advantage of the finer data access they provide. The ideal, not likely realisable within the resources and time constraints of the project, is a full OGC Transaction Web Feature Service network. [1] DISMAR: [2] INSPIRE: [3] OpenGIS Consortium: [4] Web Map Service: [5] Web Feature Service: [6] University of Minnesota MapServer: [7] GeoServer: [8] GML: [9] SVG: [10] exist: [11] ISO 19115: Author Addendum Éamonn Ó Tuama is a Senior Scientist at the Coastal & Marine Resources Centre in UCC. He has a particular interest in the use of web based technologies for environmental informatics and GIS. 6