Standardised Access to Geospatial Information and Services

Transcription

1 Department of Computing Science Umeå University Standardised Access to Geospatial Information and Services - Towards a European Infrastructure for Geospatial Information Master's Thesis Project, 20 Credits Spring of 2006 Supervisor at Lantmäteriet: Pär Hollander Supervisors at Department of Computing Science: Peter Gardfjäll and Johan Tordsson Examiner at Department of Computing Science: Per Lindström

2

3 Abstract Good policy requires well-informed decision-makers and active participation by an educated public. The ability of geographic information to integrate information from many fields based on location allows decision-makers in many areas to make informed decisions at the local, regional, and global levels. To aid in activities such as environmental management, Geographic Information Systems (GIS) allow the capturing, storing, checking, integrating, manipulating, analysing and displaying of geographically referenced information. To support discovery, access and use of geographic information in the environmental decision-making process, the proposed INSPIRE directive provides a legal basis for a European infrastructure for geographic information. The vision is to ensure interoperability of data and services across administrative borders in the EU through a distributed network of databases linked by common standards and protocols. The purpose of this Master's Thesis project is to investigate the opportunities and requirements in terms of technology and information, with a special focus on network services, that should be made available by the National Land Survey of Sweden in accordance with INSPIRE. This thesis describes the required INSPIRE network services and discusses the possibilities of evolving OGC and ISO standards for geospatial information that may fulfil those requirements. The Web Processing Service (WPS) interface is implemented and tested together with Web Map Service (WMS) and Web Feature Service (WFS) implementations in a distributed environmental GIS sample application.

4

5 List of Abbreviations BPEL - Business Process Execution Language CQL - OGC Common Query Language CSW - Catalogue Service for the Web DT - Drafting Team ESDI - European Spatial Data Infrastructure GDAS - Geolinked Data Access Service GIS - Geographic Information System GLS - Geolinking Service GML - Geography Markup Language INSPIRE - INfrastructure for SPatial InfoRmation in Europe IPR - Intellectual Property Rights ISO - International Organization for Standardization JTS - JTS Topology Suit KVP - Key-Value-Pair LMO - Legally Mandated Organisation MIME - Multipurpose Internet Mail Extensions MTOM (SOAP) Message Transmission Optimization Mechanism OGC - Open Geospatial Consortium RISE - Reference Information Specifications of Europe SDI - Spatial Data Infrastructure SLD - Styled Layer Descriptor udig - User-friendly Desktop Internet GIS WFS - Web Feature Service WMS - Web Map Service WPS - Web Processing Service XLink - XML Linking Language

6

7 Table of Contents 1 Introduction Problem Statement and Purpose Method Disposition Distributed GIS and Geospatial Web Services Web Map Service (WMS) Web Feature Service (WFS) Web Processing Service (WPS) Extending the Reach - Adding SOAP and WSDL Support INSPIRE and the Need for Geospatial Information and Services INSPIRE as a Foundation for a European Spatial Data Infrastructure Current Status and Future Plans A Proposed European Spatial Data Infrastructure Architecture The Needed Geospatial Information and Services A Uniform Information Model Network Services Transformation Services Discovery Services View Services Download Services Upload Services Invoke Spatial Data Services Services Design and Implementation of a Web Processing Service GeoServer and udig WPS Server Implementation Environmental GIS - A Sample Application WPS Client Implementation Discussion Conclusion Future Work...51 Acknowledgements...53 References...55 Appendix A - Example WFS Operation Requests, Responses and GML Usage...61 Appendix B - Example WPS Operation Responses...65 Appendix C - udig Remote Operations User Manual and Installation Instructions...69

8

9 1 Introduction Good policy requires well-informed decision-makers and active participation by an educated public.1 Geographic information identifies the geographic location and characteristics of natural or constructed features and boundaries on the Earth2. The ability of geographic information to integrate information from many fields based on location allows decision-makers in many areas to make informed decisions at the local, regional, and global levels. Examples of areas in which decision-makers are benefiting from geographic information include business development, community land use assessments, disaster recovery and environmental restoration. To aid such activities, Geographic Information Systems (GIS) enable capturing, storing, checking, integrating, manipulating, analysing and displaying of geographically referenced information. Spatial Data Infrastructures (SDI) support discovery, access and use of geographic information in the decision-making process.3 The proposed INSPIRE directive, henceforth referred to as INSPIRE, provides the legal basis for a European SDI (ESDI) based on national SDIs to support decision-making in environmental issues of the European Union. The vision is to ensure interoperability of data and services across administrative borders in the EU through a distributed network of geospatial databases linked by common standards and protocols. The National Land Survey of Sweden (Lantmäteriet) is responsible for coordinating the development of a Swedish SDI and represents Sweden in the INSPIRE proceedings.4 The ESDI will be built upon current and evolving standards in the geospatial field. The Open Geospatial Consortium (OGC) and the International Organisation for Standardisation (ISO)'s Technical Committee 211 are two prominent standardisation bodies in this field. The OGC, as an association of geospatial information-industry actors, develops specifications that become de facto standards through a consensus process and common acceptance. OGC and ISO have identified areas of common interest and work closely to ensure harmonisation of efforts. One of the earliest OGC specifications, which has now become incorporated in the ISO series of standards for geographic information, is the Web Map Service (WMS) which is a networkaccessible service that produces map images that are representations of geospatial data. WMS was followed by the Web Feature Service (WFS) specification, which provides an interface for remote access to geospatial data. Currently, a Web Processing Service (WPS) specification is being discussed, that provides remote access to processes that are capable of performing calculations on spatial data. 1.1 Problem Statement and Purpose INSPIRE requires each EU member state to provide access to national sets of geospatial information. What types of geospatial information and services are member states required to make accessible? What geospatial standards could be used to realise these requirements and what possibilities and limitations do they present? The purpose of this thesis is to investigate the opportunities and requirements in terms of technology and information, with a special focus on 1 Commission of the European Communities (2004), Proposal for a Directive of the European Parliament and of the Council : Establishing an Infrastructure for Spatial Information In the Community (INSPIRE), Brussels, p.2 2 Masser, I. (1998), Governments and Geographic Information, Padstow, UK: Taylor & Francis Ltd, p.8 3 Nebert, D. (Ed.)(2004), Developing Spatial Data Infrastructures: The SDI Cookbook (Version 2.0), GSDI, p.6 ( ) 4 Hall, M., Beusen, P. (2005), Spatial Data Infrastructures in Sweden: State of play Spring 2005, p.7 ( ) 1

10 network services, that should be made available by Lantmäteriet in accordance with INSPIRE. 1.2 Method To fulfil the purpose of this Master's Thesis project, current and evolving standards for geospatial information and services are investigated in relation to INSPIRE. A WPS server and client are implemented and evaluated together with a WMS and a WFS in a sample application to assess the potential of those standards and to realise a subset of the network services of the proposed directive and to gain a deeper technical knowledge. Often, it is difficult to fully assess the potential of a standard without the practical experience that can be obtained from experimentally developing a reference implementation. 1.3 Disposition Chapter 2 describes some fundamental GIS concepts, and discusses evolving standards for geospatial web services which are candidates for implementing some of the network services required by INSPIRE. INSPIRE, the legal foundation for a European infrastructure for geospatial information, is the subject of Chapter 3. Chapter 4 discusses the design and implementation and the test of the WPS interface together with existing implementations of WMS and WFS, in the context of a sample distributed environmental GIS application. Chapter 5 discusses the material presented in Chapters 2 through 4 in the context of opportunities and issues of adopting geospatial standards. Finally, chapters 6, 7 and 8 contains a conclusion, future work and a list of references, respectively. 2

11 2 Distributed GIS and Geospatial Web Services INSPIRE is based on geospatial standards. This chapter discusses current and evolving geospatial standards for geospatial web services which are candidates for implementing some of the network services required by INSPIRE. Before a description of these services is given, some perspective is provided by relating these services to the functionality and architecture of traditional GIS. A GIS is a computer system for capturing, storing, checking, integrating, manipulating, analysing and displaying data related to positions on the Earth surface5. GISs were initially developed for the requirements of urban planners and landscape architects who wanted a system that made it possible to construct maps by overlaying digital geographic data from a variety of sources to discover sites that had a potential for future urban expansion.6 INSPIRE can be seen as a manifestation of the fact that GIS can also be used for environmental analysis. Environmental GIS is the use of location-based data management tools to assist in the decision making process that forms a strategy for environmental management.7 The potential application areas of GIS in the environmental field are many since environmental issues vary considerably: coastal management8, meteorological forecasting9, public transport planning10 and urban hydrology11 are just a few examples from Europe. In a GIS context, the concepts of feature and layer are central. A feature is an abstraction of a real world phenomena12. A layer corresponds to a particular feature type (e.g. river) and holds information of the geographic location of feature instances (e.g. the Rhine). Finally, to complete this discussion of fundamental GIS concepts, a map may be represented as several different layers combined in an overlay fashion (e.g rivers, roads and urban areas). Similar to traditional desktop GIS applications, a WMS provides the user the ability to display and integrate layers as maps, a WFS provides access to stored features, and a WPS provides the possibility of performing arbitrary geospatial analysis and manipulation on geospatial data. Together, these services provide many of the functions of a traditional desktop GIS, with the major difference that the services are made available at remote servers. The historical development of GIS architecture has been strongly affected by the progress in information technology and by the evolution of the Internet. GIS has gone from centralised 5 Association for Geographic Information GIS Dictionary (2006), ( ) 6 Masser, I. (2005), GIS Worlds: Creating Spatial Data Infrastructures, Redlands, California: ESRI Press, p.4 7 ESRI Web Site (2006), ( ) ISO - International Organisation for Standardisation, ISO 19107:2003 Geographic information - Spatial schema, p.8 3

12 stand-alone systems, to two-tier local or wide area network client/server systems, and more recently towards distributed GIS: Internet-based n-tier GIS systems where the previously clear separation of client and server is dissolving and where several services can be combined to form customised situation-based applications, regardless of their underlying platforms.13 Figure 2.1 shows how WMS, WFS and WPS could be combined by a client to provide a distributed GIS application. A thin client is software that supports a window-based user interface on a computer that is local to the user while executing applications on a remote computer.14 In a distributed system such as the one envisioned by the ESDI (see section 3.3), standards-based geospatial services such as WMS, WFS and WPS would enable users of that system to use thin clients to perform geospatial analysis for environmental applications. Using a simple web browser, a user could interact with member states' services indirectly through the ESDI geoportal as depicted in Figure 2.2, or possibly access them directly if made publicly available. Figure 2.1: A Distributed GIS. A client queries a WFS for vector data encoded in the Geography Markup Language (GML) (see section 2.2), which is then provided as input to a WPS that performs geospatial analysis and returns the resulting vector data to the client. The vector data is displayed as a layer on top of a satellite image provided by a WMS as a layer to provide the user with some location reference. 13 Peng, Z-R., Tsou, M-H. (2003), Internet GIS: Distributed Geographic Information Services for the Internet and Wireless networks, New Jersey, USA: John Wiley & Sons, p Coulouris, G., Dollimore, J., Kindberg, T. (2001), Distributed Systems: Concepts and Design, New York, USA: Addison Wesley, p.39 4

13 Figure 2.2: Thin client ESDI access. A user accesses the services provided by member states of the ESDI indirectly using a standard web browser and the Geoportal as the system entry point. With these perspectives in mind, sections 2.1 through 2.3 discusses the WMS, WFS and WPS interfaces. For each service, its usage is described initially, followed by a description of the operations that it supports. No fault messages are discussed. While the discussion of the service interfaces is an overview at the technical level, these are formally defined elsewhere (i.e. in their respective implementation specification) in XML Schema. XML Schemas provide a means for defining the structure, content and semantics of XML documents.15 Commonalities of OGC services The standardised service interfaces originating from OGC, including WMS, WFS and WPS, have commonalities in their design. One such commonality regards the metadata describing the capabilities of a service. Many of the metadata structures are common, based on the ISO international standard for geographic information metadata, and are provided by the common operation GetCapabilities.16 The response from a GetCapabilities request is an XML description of the service's information content and supported request parameters, and is therefore both machine- and human-readable. This capabilities document conforms to an XML Schema, partly 15 W3C (2001), XML Schema, ( ) 16 Whiteside, A. (Ed.)(2005), OpenGIS Web Services Common Specification, Open Geospatial Consortium, pp.22 5

14 unique for the particular type of service, which allows clients to validate the response.17 Subsequent calls to the more specialised operations of the service in question can be done manually or in an automated manner by the client, using suitable parameters. In general, for all OGC web service specifications, there are two possible operation request methods: HTTP GET and HTTP POST. The default operation request encoding format is KeyValue-Pair (KVP) for the HTTP GET request method. The default operation request encoding format is XML for the HTTP POST request method. However, a service implementation may also publish KVP request encoding support for the HTTP POST request method. 18 The GET request method is generally simpler than the POST request method, enabling a thin client such as a browser to issue a request using the browser address field. The GET-method however has limitations such as a maximum length of the request line. The POST-method with XMLencoding is more flexible in terms of the possible request contents and length. When making a request using HTTP GET with KVP encoding, a query consisting of name/value pairs is appended to an URL prefix, which may look like the following example in which a description of the Buffer process is requested from a version WPS service instance. request=describeprocess& service=wps& version="0.4.0"& identifier=buffer& The corresponding XML-encoded request conveyed using HTTP POST may look like: <?xml version="1.0" encoding="utf 8"?> <DescribeProcess service="wps" version="0.4.0" xmlns=" xmlns:ows=" xmlns:xlink=" xmlns:xsi=" instance" xsi:schemalocation=" <ows:identifier>buffer</ows:identifier> </DescribeProcess> A single server may implement several services (e.g. WMS, WFS and WPS) and reuse operation names for those services. It may also implement several operations for each service and support several versions of a single service specification.19 This makes it necessary for clients to always specify the service (e.g. WPS), request type (e.g. DescribeProcess) and service version (e.g ) in a request.20 The one exception to this rule is the GetCapabilities operation, where service version is not specified in the request. The GetCapabilities operation may instead support client-server version negotiation ISO - International Organisation for Standardisation, ISO 19128:2005(E): Geographic information - Web map server interface, p Whiteside, A. (Ed.)(2005), OpenGIS Web Services Common Specification, Open Geospatial Consortium, p Whiteside, A. (Ed.)(2005), OpenGIS Web Services Common Specification, Open Geospatial Consortium, p Ibid., p Schut, P., Whiteside, A.(Eds.)(2005), OpenGIS Web Processing Service v , Open Geospatial Consortium, p.4 6

15 2.1 Web Map Service (WMS) A WMS is a service that on request dynamically produces a map of spatially referenced data. A map in the WMS context is defined as a portrayal of geographic information as a digital image file suitable for display on a computer screen.22 Hence, a WMS does not produce actual geographic information as a response to a request, but rather maps as raster images that are representations of such information. A possible scenario, when a user has just discovered a previously unknown WMS, is first to query the WMS for information about its capabilities such as the map layers that it can serve and information about the service provider. Based on that information, the user requests a map and displays it on the screen. Once the map is displayed, the user might also want to query the WMS for additional information about a particular feature that is visible on the map, such as by clicking on a city. The above scenario is supported by three WMS operations. These operations together make up the interface that hides the complex inner workings of the Web Map Server, possibly including data requests from local or remote database servers, attaching symbols and translating coordinate systems.23 Two of the operations are mandatory, GetCapabilities and GetMap, whilst the third, GetFeatureInfo, is optional. These operations are explained in more detail below. A specification for a WMS interface was originally developed by OGC and has been incorporated into the ISO series of standards for geographic information, as the ISO "Web Map server interface". OGC uses the term "distributed computing platform" to designate the protocol binding for services. The protocol used by WMS is HTTP.24 GetCapabilites The critical service metadata provided by the WMS GetCapabilities operation is information describing the different layers that the WMS can provide, such as their names and what coordinate reference systems they may be rendered in, as well as which layers are further queryable with the GetFeatureInfo operation. Also, the capabilities document specifies one or many predefined styles for each layer, as described in the below section User-Defined Portrayal of Maps - Styled Layer Descriptor. This provides the users a limited way to define how they want the WMS to symbolise the layers, by specifying this with a parameter in the GetMap request. A more flexible way of selecting a style is defined in the Styled Layer Descriptor (SLD) Implementation Specification, as further described later in this section. GetMap GetMap is the WMS operation that generates maps. The response to a GetMap request is a map of the spatially referenced layers, the specified styles, coordinate reference system, the bounding box (i.e. the geographic area of interest), size, output image format and transparency that the user has requested.25 By querying several different WMS servers, specifying the same 22 ISO - International Organisation for Standardisation, ISO 19128:2005(E): Geographic information - Web map server interface, p.v 23 Kolodziej, K. (Ed.)(2004), OpenGIS Web Map Server Cookbook, Open Geospatial Consortium, p.7 ( ) 24 ISO - International Organisation for Standardisation, ISO 19128:2005(E): Geographic information - Web map server interface, p.5 25 Ibid., p.30 7

16 geographic bounding box and that images shall be transparent, a client may overlay several images to produce a merged map for display. Furthermore, a WMS may serve layers of information that are actually originating from other WMS and WFS servers; so called cascading WMS. Figure 2.3 shows how transparent maps from different WMS servers may be overlayed into a single map. Figure 2.3: Overlayed maps. The figure shows how separate WMS servers may provide layers of the same geographic area that can be overlayed as transparent images to produce a single map. GetFeatureInfo A WMS may support the optional operation GetFeatureInfo, available for those layers that are described as further queryable in the capabilities document. This operation is typically used when a user clicks on a map resulting from a GetMap request to get more information about a certain feature. Since the WMS protocol is stateless, the GetFeatureInfo operation requires much of the information that was provided in the previous GetMap request (e.g. bounding box, layers), as well as the clicked coordinates on the user's map.26 The information which the GetFeatureInfo operation actually returns is not specified and is therefore left to the WMS implementer to decide. 26 ISO - International Organisation for Standardisation, ISO 19128:2005(E): Geographic information - Web map server interface, p.31 8

17 User-Defined Portrayal of Maps - Styled Layer Descriptor An SLD is a more flexible way of specifying how to style maps than to simply choose a predefined style published by the WMS server. An SLD is intended for use together with a WMS and provides the user an XML styling language that gives control, down to the feature attribute level, over the visual portrayal, or "style", of the data available at the server.27 An SLD can be provided to a WMS in several ways, depending on the server implementation. E.g., an SLD can be embedded in a GetCapabilities request using HTTP POST. For a client to be able to generate a suitable SLD it is often the case that more detailed information about some particular layer is needed, such as the types of the features that the layer represents. Therefore, an SLD application profile of WMS has proposed extensions to WMS. The optional operation DescribeLayer returns the feature types of the specified layer or layers.28 This information would allow, for instance, individual colouring of feature types. Even more detailed styling can be done if the attributes of feature types are known. These can be found using for instance the WFS operation DescribeFeatureType, as described in section 2.2. GetLegendGraphic is another optional operation defined in the SLD profile of WMS, which provides clients a general mechanism for acquiring legend symbols. Legends are normally included in maps to indicate how (e.g. in what colour) feature types are displayed.29 Hence, this operation may be a solution to the INSPIRE requirement that view services should display legend information. Figure 2.4 and Figure 2.5 show how the same layer can be portrayed differently using SLD together with a WMS GetMap request. Figure 2.4: Server pre-defined style. The figure shows simple lines representing sea routes off the east coast of Sweden. Figure 2.5: SLD. The same sea routes as in Figure 2.6 using SLD, specifying different rules for rendering lines and labels. 27 Lalonde, W. (Ed.)(2002), OpenGIS Styled Layer Descriptor Implementation Specification v.1.0.0, Open Geospatial Consortium, p.ix 28 Müller, M., MacGill, J.(2006), Styled Layer Descriptor Application Profile of the Web Map Service: Draft Implementation Specification, Open Geospatial Consortium, p Ibid., p.18 9

18 The use of SLD does not stop at the server. It is also quite possible for clients that retrieve geospatial data from WFS servers and to apply local styling using SLDs before visual presentation to the user. SLDs are supported by both GeoServer and udig used in this thesis project, which makes customisable portrayal of map data possible both at the client and the server. 2.2 Web Feature Service (WFS) A Web Feature Service provides access and manipulation operations on geographic features using HTTP as the underlying protocol.30 A WFS provides access to vector data and is therefore fundamentally different from a WMS which produces mere raster image representations of geospatial data as maps. A WFS can be cascaded; it can serve data that is located at some remote WFS. When transporting geospatial data, the interchange format is the Geography Markup Language (GML) and conforms to some GML application schema. GML is further described later in this section. The operations provided by the WFS are GetCapabilities, DescribeFeatureType, GetFeature, GetFeatureWithLock, GetGMLObject, LockFeature and Transaction. The OGC WFS implementation specification is in the process of being included in the ISO series of standards for geographic information as ISO GetCapabilities Critical metadata provided by the WFS GetCapabilities operation are the feature types which it serves and the operations that are supported on each feature type.32 The capabilities document also specifies the output formats that the WFS support. An example capabilities response XML fragment can be found in Appendix A.33 DescribeFeatureType The WFS DescribeFeatureType operation generates schema descriptions of feature types that the WFS implementation serves. Upon the receipt of a DescribeFeatureType request from the client a XML Schema document that is a valid GML application schema is generated by the server as a response.34 This GML application schema describes how features provided as input to, or output from, the WFS are encoded.35 An example response to a DescribeFeatureType operation request can be found in Appendix A. GetFeature The WFS GetFeature operation lets the client fetch features from the WFS server. The response 30 Vretanos, P.A. (2005), OpenGIS Web Feature Service Implementation Specification, Open Geospatial Consortium, preface p.5 ( ) 31 ISO/TC 211 (2005), ISO/TC 211 N Vretanos, P.A. (2005), OpenGIS Web Feature Service Implementation Specification v.1.1.0, Open Geospatial Consortium, p.2 ( ) 33 Vretanos, P.A. (2006), Geography Markup Language (GML) simple features profile v.1.0, Open Geospatial Consortium, p.ix 34 Vretanos, P.A. (2005), OpenGIS Web Feature Service Implementation Specification v.1.1.0, Open Geospatial Consortium, p.26 ( ) 35 Ibid., p.24 10

19 is a GML instance document that validates against the default application schema that may be retrieved using the DescribeFeatureType operation, or against some explicitly specified application schema supported by the WFS server.36 A GetFeature request contains one or more queries, specifying the requested feature types, properties of those feature types, and any spatial or non-spatial restrictions on the features to be returned.37 Such restrictions may use the OGC Filter Encoding Specification38, and its use is exemplified by the GetFeature request and response of Appendix A. GetFeatureWithLock The WFS GetFeatureWithLock operation is optional and similar to the GetFeature operation. GetFeatureWithLock attempts to lock a set of feature instances, after which the client would normally update the feature set through a WFS Transaction operation.39 GetGMLObject The optional WFS GetGMLObject operation allows clients to retrieve features and element instances by their XML ID.40 The requested element could be any identified element such as a feature, a geometry, or a complex attribute. The XML Linking Language (XLink) allows elements to be inserted into XML documents in order to create and describe links between resources.41 The server may use XLink to include in the response XML document, elements whose data values reside at some URL specified by the XLink value. The client may specify the depth and time limit of traversal of nested XLinks that the server should perform.42 LockFeature The WFS LockFeature operation is optional and, if implemented, enables the client to lock a set of feature instances of a feature type, with the effect that others cannot access those feature instances for the time that they are locked. The response is a document that includes a lock identifier that the client may use in subsequent operations to manipulate the set of locked feature instances.43 The typical action that the client then proceeds with is to issue a transaction request using the acquired lock in the WFS Transaction operation. The WFS specification contains detailed information on how to avoid possible deadlocks. For instance, when a client requests locking a feature that is already locked by another client, the default behaviour by the server is to consider the request as failed and respond with an exception. Transaction Transaction is a WFS operation that is optional for servers to implement and that allows the 36 Vretanos, P.A. (2005), OpenGIS Web Feature Service Implementation Specification v.1.1.0, Open Geospatial Consortium, p.34 ( ) 37 Ibid., p Vretanos, P.A. (2005), OpenGIS Filter Encoding Implementation Specification, Open Geospatial Consortium ( ) 39 Vretanos, P.A. (2005), OpenGIS Web Feature Service Implementation Specification v.1.1.0, Open Geospatial Consortium, p.37 ( ) 40 Ibid., p.2 41 XML Linking Language (XLink) (2001), ( ) 42 Vretanos, P.A. (2005), OpenGIS Web Feature Service Implementation Specification v.1.1.0, Open Geospatial Consortium, p.51 ( ) 43 Ibid., p.59 11

20 client to modify features using different types of transactions: Insert, Update, Delete or Native.44 While the first three transaction types are self-explanatory, the Native transaction type allows for custom transaction types. Transactions may be performed using a previously established lock on a set of features to allow mutually exclusive feature modification. GML - Transferring and Storing Geospatial Data The data interchange format of WFS is the Geography Markup Language (GML). GML is an XML encoding for the transport and storage of geographic information.45 GML provides encodings for many concepts including features, geometry, coordinate reference systems, topology, time and metrics. GML was developed by OGC and is now in the process of being incorporated as a standard in the ISO series of standards for geographic information as ISO GML is defined using XML Schema and, since GML is a complex standard, it is generally the case that a particular application only uses a subset of the GML Schema. In fact, it might be difficult to achieve interoperability in a community if the allowed GML elements and attributes are not restricted.46 For a particular user community, such as the ESDI, a GML application schema should be defined, realising a uniform information model.47 By conforming to that GML application schema, geographic information could be interchanged within the ESDI. The common way to define a GML application schema is first to restrict the usage of GML parts by specifying a GML profile, that allows only a defined subset of GML. E.g., the "Geography Markup Language (GML) simple features profile" supports GML features and a limited set of linearly interpolated geometric types such as point, Curve (LineString) and Surface (Polygon).48 An application schema uses a profile as a basis to construct new types by extending and/or including the types of that profile.49 A basic example of a GML application schema together with a conforming GML fragment for an ESDI is provided in Appendix A. 2.3 Web Processing Service (WPS) The functionality of web mapping has gradually evolved from enabling viewing of remote data (WMS); to enabling access and modification of remote data stores (WFS); and more recently, in a step towards a truly distributed GIS, a general purpose Web Processing Service (WPS) interface providing access to processes capable of performing calculations on geospatial data. 44 Vretanos, P.A. (2005), OpenGIS Web Feature Service Implementation Specification v.1.1.0, Open Geospatial Consortium, p.63 ( ) 45 ISO - International Organisation for Standardisation (2005), ISO/DIS 19136:2005 Geography Markup Language (GML), p Vretanos, P.A. (2006), Geography Markup Language (GML) simple features profile v.1.0, Open Geospatial Consortium, p.xii ( ) 47 Examples of existing GML application schemas are CityGML, designed for use in the modelling of 3D urban objects; and XMML, designed for use in the geoscience and exploration domain. 48 Vretanos, P.A. (2006), Geography Markup Language (GML) simple features profile v.1.0, Open Geospatial Consortium, p.1 ( ) 49 ISO - International Organisation for Standardisation (2005), ISO/DIS 19136:2005 Geography Markup Language (GML), pp

21 Since the WPS interface is a general purpose interface for providing access to any geospatial processing functionality, it is likely that other more specialised proposed OGC standard interfaces such as Geolinked Data Access Service (GDAS) and Geolinking Service (GLS) will be rewritten as WPS profiles.50 GDAS provides a way to publish and access data that refer to features, but reside in non-spatial databases. Such "geolinked" data sets does not contain the geometry that it references, but contain links such as names of the features they reference.51 Geolinked data sets can be statistical data such as river throughput or traffic noise at road segments. When extracted and published with GDAS, a GLS allows real-time linking of that statistical data as attributes to a geospatial data set, joined on some identical key in the two data sets.52 The resulting geolinked data set from GDAS and GLS could then be used as input to other geospatial services (e.g. WMS, WPS) or clients. The WPS specification is implemented in this thesis project and is therefore discussed in more detail than WMS and WFS in previous sections. The description of the WPS operations is followed by a discussion of how WPS addresses the INSPIRE requirements. A WPS implements three mandatory operations: GetCapabilities, DescribeProcess and Execute. Common for all of these operations is that HTTP is the only supported protocol. As we shall see, each operation supports at least one of the HTTP GET and HTTP POST request methods. GetCapabilities The WPS GetCapabilities operation must use the HTTP GET request method with KVP encoding.53 The response of the WPS GetCapabilities operation provides important metadata about the WPS service instance. As indicated by the section "Commonalities of OGC services", the contents are similar to that of WMS and WFS. This includes basic information such as the service type, service version, service title, a short description of the server, keywords (e.g. spatial, processing, buffer), any fees for using this server and any access constraints (i.e. to assure protection of intellectual property or likewise).54 The response also includes information about the provider, such as the provider name, web site and contact information, as well as information about the operations that the server supports. Information about supported operations is similar but not identical between different implementations of OGC-originating specifications, since service implementers may include additional information and specify mandatory parameters in requests.55 For each operation implemented by a service, the GetCapabilities response contains the operation name and the protocol binding (currently only HTTP) together with a service access URL and supported request methods. Unique to the WPS metadata is a description of the different processes that the WPS implementation offers. A brief description is provided for each process that the server implements. More specifically, any inputs and outputs are not included in the GetCapabilities document.56 The brief description must at least contain one unambiguous identifier of the 50 Communication with Schut,P., editor of WPS discussion paper ( ) 51 Schut, P. (Ed.)(2004), OpenGIS Geolinked Data Access Service (GDAS) version 0.9.1, Open Geospatial Consortium, p.7 52 Schut, P. (Ed.)(2004), OpenGIS Geolinking Service (GLS) version 0.9.1, Open Geospatial Consortium, p.9 53 Schut, P., Whiteside, A.(Eds.)(2005), OpenGIS Web Processing Service v , Open Geospatial Consortium, p Whiteside, A. (Ed.)(2005), OpenGIS Web Services Common Specification, Open Geospatial Consortium, p Ibid., p Schut, P., Whiteside, A.(Eds.)(2005), OpenGIS Web Processing Service v , Open Geospatial Consortium, 13

22 process, together with its title. In an INSPIRE context, the identifier and other parameters pertaining to a process would be particularly important for service discovery. Optionally, the description may contain a brief narrative abstract of the process, additional metadata, and the release version of the process. Note that the release version is not the same as the WPS service version. The metadata of the GetCapabilities document may be used in subsequent calls to the DescribeProcess operation. A GetCapabilities response XML document generated by the WPS instance that is implemented in this thesis project is given in Appendix B. DescribeProcess The WPS DescribeProcess operation must support the HTTP GET request method using KVP encoding. Optionally, the HTTP POST request method with XML or KVP encoding may also be supported. The need for the DescribeProcess operation arises from the fact that in order to use the processes that the WPS implements, the server needs a way to describe those processes in detail. By specifying a set of process identifiers, usually received from a previous call to GetCapabilities, a client can get detailed process metadata in XML. The functionality of the DescribeProcess operation is similar to that of the DescribeFeatureType operation of WFS, since the response is in fact an application schema for a particular user community. The WPS application schema describes the behaviour of one or more processes, or in an INSPIRE context, it would describe the behaviour of INSPIRE spatial data services. In effect, the DescribeCapabilities operation adds some discovery service functionality to the WPS, for discovering INSPIRE spatial data services. If WPS were to be included in the INSPIRE draft Network Services Implementing Rules as "invoke spatial data services" services, the WPS application schema published by WPS instances would need to be aligned with work of the Data Specifications and of the Metadata drafting teams in defining a unified information model. When a client issues a DescribeProcess request, it includes an unordered list of process identifiers for which metainformation is required. These identifiers are a subset of the ones received in a previous GetCapabilities request. An example DescribeProcess request using KVP encoding might look like: version=0.4.0&identifier=buffer,boundarylength& The metadata returned by the DescribeProcess operation is sufficiently detailed to be used for service chaining57, as well as automatically build a user interface at the client that lets the user provide values for any needed inputs and outputs when executing a process by calling the Execute operation.58 The response contains a set of process descriptions, corresponding to the specified process identifiers of the DescribeProcess operation call.59 Each process description contains full information about a particular process. This includes, besides the brief description from the capabilities document, the inputs and outputs needed by this process, as well as p.9 57 Schut, P. (2006), WPS RFC responses - Presentation to the OGC Architecture Working Group, Open Geospatial Consortium, p Schut, P., Whiteside, A.(Eds.)(2005), OpenGIS Web Processing Service v , Open Geospatial Consortium, p Ibid., p.16 14

23 parameters indicating whether or not this process supports asynchronous execution and if execute results may be stored at the server as web accessible resources.60 The contents of the DescribeProcess response are discussed in more detail below. It is mandatory to provide additional metadata for each process in the DescribeProcess response since it is a complete description of a process. That metadata contains basic information about the process such as identifier, title, language of this description, and any fees or access constraints. The inputs and outputs to a process are described in detail by the DescribeProcess response. A process may require no input. The reason is that a process always produces a result but that does not necessarily mean that input from the user is necessary. An example of a process requiring no input is generation of a weather report from data already stored at the server or some predefined remote location. A process may however require many inputs and must produce at least one output. For each input and output, an identifier, title and type of input/output is provided as part of the description. The DescribeProcess response describes the allowed values of these inputs and the types of the outputs. The WPS implementation may support different formats for each input and output, which are specified in the response document. Input and output of a process may be one of three types: Complex, Literal or BoundingBox. An example of Complex input to a process is a GML fragment, describing e.g. a geometry. The DescribeProcess document shall specify the formats (e.g. "text/xml"), encodings (e.g. "UTF-8") and schemas (e.g. " supported for each Complex input data. A Literal is a simple value such as an integer. A BoundingBox specifies the coordinates of an upper and a lower corner of an area, in a specified coordinate reference system. Finally, the ProcessDescription response document specifies for each process if storage is supported at the server, and whether the server supports asynchronous execution of requests. If the server supports storage, then an Execute request may provide the parameter "store" to indicate that the process output shoud be stored at the server. This is e.g. useful for making service chaining more efficient when outputs are large.61 If the server supports quick status retrieval, then an Execute request may provide the parameter "status" to indicate that a quick response with status information shall be returned instead of the results, indicating a webaccessible location where further status of the process execution may be retrieved. This parameter is useful e.g. when the process takes a very long time to execute.62 Appendix B provides a DescribeProcess response XML document generated by the WPS instance implemented in this thesis project. Execute The WPS Execute operation must support the HTTP POST request method and XML request encoding. Optionally, KVP encoding of the request may be supported. Using the information provided by the previous operations (GetCapabilities and DescribeProcess) as input, the Execute operation lets the user request the execution of a certain process implemented by the server. 60 Schut, P., Whiteside, A.(Eds.)(2005), OpenGIS Web Processing Service v , Open Geospatial Consortium, p Ibid., p Ibid., p.18 15

24 In the request, the process identifier as well as any required inputs are specified. 63 The user may also specify any allowable output formats and descriptions. For instance, a user may want to specify the title and abstract of an output to better reflect the meaning of this particular execution. If the WPS supports storage, the user can specify the "store" parameter. If the results are stored, the response of the Execute operation is an XML document specifying a location where each output can be retrieved.64 Furthermore, the user may specify that the Execute operation should be performed synchronously or asynchronously. When asynchronous execution is requested, the status information provided by the server may include the expected time until completion and similar statistics. The status information at the URL is embedded in an updated Execute response document.65 Notably, when a client makes an Execute request specifying a process that requires Complex input, that Complex value may be embedded in the request as XML or provided to the process as a remote resource by referencing an URL. If the HTTP GET request method is used and KVP encoding for the operation is supported, the remote resource referencing possibility of the proposed WPS standard allows a simple client such as a web browser to perform execute requests with complex input if the location of that input data is known and accessible by the service. However, because of the limitations of HTTP GET request method and KVP encoding, only a subset of the parameters possible with HTTP POST and XML encoding are available.66 When a process produces a complex output, that output may be included in the XML response document or provided as a remote resource by referencing an URL. This means that, if a user request the server to store the results and to execute the operation asynchronously, the response document retrieved at that status URL contains yet another URL to the resulting output. Such URLs could be supplied as XLinks to allow for automated retrieval by an XML parser. If Literal and BoundingBox values are provided as inputs or outputs, they are embedded in the Execute request or response.67 It is recommended by the proposed WPS standard that any inputs to the process are included in the response, to allow for the user to better keep track of the meaning of a result.68 It is possible for the WPS server to include a URL that references some input that was previously provided by the user, which is particularly useful to improve performance when that input is large.69 While the response to an Execute request is typically an ExecuteResponse XML document, there is a special case that does not follow this pattern. The special case occurs when the output of a successful process execution is a single output of Complex type and no storage is requested. The response is then returned directly and contains only that Complex result; not wrapped with any other metadata in an XML response message.70 E.g., this is the case when a single geometry encoded in GML is the result. An example Execute response to a request where the "status" and "store" parameters were set is 63 Schut, P., Whiteside, A.(Eds.)(2005), OpenGIS Web Processing Service v , Open Geospatial Consortium, p Ibid., p Ibid., p Ibid., p Ibid., p Ibid., p Ibid., p Ibid., p.51 16

25 shown in Appendix B. 2.4 Extending the Reach - Adding SOAP and WSDL Support This section provides a discussion of possibilities and issues that arise from aligning services in the geospatial field with industry standards such as SOAP71 and Web Services Description Language (WSDL)72, together with possible techniques for dealing with some of the issues. While OGC specifications have had bindings for other middleware platforms, more recently the OGC attention is towards relying on the Web for improving interoperability between services, what is called OGC Web Services. While middleware such as CORBA, DCOM or JINI provide efficient implementations of services, the Web complements them as an important contributor to interoperability between and access to services because of its strengths such as simplicity of access and ubiquity.73 When the concept of Web Services surfaced in the beginning of the 2000's, OGC considered it completely in line with the OGC thinking regarding the provision of interoperable Web Services. The OGC definition of Web Services is: Web services are self-contained, self-describing, modular applications that can be published, located, and invoked across the Web. Web services perform functions that can be anything from simple requests to complicated business processes. Once a Web service is deployed, other applications (and other Web services) can discover and invoke the deployed service.74 Today, this general definition differs from the industry supported W3C's point of view which focuses more on specific industry standards as components of a larger Web Services Architecture: A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.75 In a move to further increase the reach and interoperability of OGC services, the OGC has begun adopting industry supported standards such as SOAP and WSDL into geospatial service specifications.76 In the Catalogue Services for the Web (see Section 3.4.2) specification as well as in the WFS implementation specification which is currently in the process of becoming a standard in the ISO series, support have been added for using SOAP messages over HTTP POST for transporting request and response XML documents. These specifications have also been added the possibility to use WSDL for service interface description. 77 Also, there are 71 W3C (2001), Web Services Description Language (WSDL) 1.1, ( ) 72 W3C (2003), SOAP Version 1.2 Part0: Primer, ( ) 73 Doyle, A., Reed, C.(2001), Introduction to OGC Web Services: An OGC White Paper, Open Geospatial Consortium, p.2 ( ) 74 OGC Resources Web Site (2006), ( ) 75 W3C (2004), Web Services Architecture - W3C Working Group Note 11 February ( ) 76 Sonnet, J.(2005), OWS 2 Common Architecture: WSDL SOAP UDDI, Open Geospatial Consortium, p. IV 77 Vretanos, P.A. (2005), OpenGIS Web Feature Service Implementation Specification v.1.1.0, Open Geospatial 17

26 change proposals for the WMS and Web Coverage Service (WCS)78 specifications to include support for these industry standards.79 Considering their important role as input to the INSPIRE process and its drafting teams80, it is unfortunate that current geospatial standards are still in the process of adopting these industry standards and have not yet fully done so. It has been recommended that INSPIRE network services be implemented as W3C Web Services, since geographic information would then become a component that align with the general development of standards-based solutions in the IT field.81 Web Services have in general been recommended in cases where a system consists of components potentially from different vendors, running on different platforms, or where new or existing services are to be published and made available on the web.82 However, there are problematic issues using SOAP in the field of geospatial information that need to be taken into account. The data sets to be transferred may be very large, stemming from the fact that geospatial industry actors and national mapping organisations typically possess vast amounts of geospatial data that have been collected over long time. Furthermore, data that is not geospatial in nature can often be referenced geographically by e.g. postal code, which further adds to the amount of data that may be involved in an application. The processing of large data sets has been identified as a potential problem for SDI's when using SOAP for information exchange.83 Typically, the whole SOAP message is buffered in memory by the server before it is sent. This behaviour of many SOAP engines may stem from SOAP's remote procedure call (RPC) roots, where streaming of messages is not very meaningful because of the simple fact that a RPC can not be executed until the entire message is present. Some issues are not only limited to SOAP, but shared by all systems that use XML for message encoding, including OGC services that use HTTP POST with XML encoding for operation request or response. E.g., raw binary data such as maps that are typically returned as binary images from WMS can not be included in a valid XML message. Furthermore, the performance of a distributed application can be significantly impacted by the choice of XML encoding to represent the data. XML representation of data can be ten times the size of the original binary representation, which may result in worse network transfer times.84 The size of XML messages is but one factor that may affect performance as has been shown in a recent study of the retrieval time of GML features from a WFS server to a WFS client in which several control parameters, including methods of encoding format and compression where altered. It was shown that the performance gains from compressing GML output compared to providing raw GML diminish in high-bandwidth network Consortium, p.13, Nebert, D. Whiteside, A. (Eds.)(2005), OGC Catalogue Services Specification Version with Corregendum, p. 114 Evans, J.D. (2005), OpenGIS Web Coverage Service (WCS) Implementation Specification Version (Corrigendum), Open Geospatial Consortium, ( ) Duschene, P., Sonnet, J. (Eds.)(2005), WCS Change Request: Support for WSDL & SOAP, Open Geospatial Consortium, Duschene, P., Sonnet, J. (Eds.)(2005), WMS Change Request: Support for WSDL & SOAP Dufourmont, H., Annoni, A. & De Groof, H. (2004), INSPIRE - work programme Preparatory Phase , ESTAT-JRC-ENV, p.31, CEN/TC 287 (2005), Geographic information - Standards, specifications, technical reports and guidelines, required to implement Spatial Data Infrastructure, CEN/TC 287, p.28, Joint Research Centre, Detailed Definitions on the INSPIRE Network Services, JRC-Institute for Environment and Sustainability, Ispra, p.2 Ibid., p.8 CEN/TC 287 (2005), Geographic information - Standards, specifications, technical reports and guidelines, required to implement Spatial Data Infrastructure, CEN/TC 287, p.29 van Engelen, R.A.(2003), Pushing the SOAP Envelope With Web Services for Scientific Computing, paper presented at International Conference on Web Services 2003, Las Vegas, USA, p.4

27 environments, and that significant performance gains are predominantly achieved in low bandwidth environments.85 From the above discussion it is clear that the idea of sending very large data sets embedded in SOAP messages, and thus XML, is sometimes infeasible because of its implications on payload type and size. As no universal solution to this problem exist, several techniques may address these problems depending on the particular application requirements. It has been recommended that further work should go into investigating how Web Services should deal with the problem.86 HTTP chunking, supported by HTTP 1.1, is a form of streaming and incremental processing of data. This applies to both SOAP-based Web Services and traditional OGC services and may be used to better handle XML messages of arbitrary size. HTTP chunking allows sending a not previously agreed amount of XML-encoded or binary data in chunks, by having the sender inform the receiver of the size of each chunk.87 In an attempt to address the performance drawback of bulky SOAP messages, the use of Multipurpose Internet Mail Extensions (MIME)88 packaging has been proposed to allow for data outside the SOAP envelope as attachments.89 OGC has recommended using SOAP with Attachments (SwA) for geospatial services that produce messages involving large binary data. Using binary data as attachments to SOAP messages would avoid the overhead incurred by encoding data in the XML message using e.g. base64 encoding, but the resulting messages as a whole are not valid XML messages and interoperability problems may arise if they are routed through XML-based frameworks that do not recognize MIME messages.90 MIME attachments also have performance-reducing flaws in its design, such as the need to scan the message to find MIME part boundaries which requires computing time proportional to the size of the MIME message. The OGC recommendation to use SwA for geospatial services may potentially become a problem when considering service chaining, which has been seen as important in INSPIRE. If for instance the industry standard Business Process Execution Language (BPEL)91 is considered for service chaining in the ESDI, it should be taken into account that BPEL has no built-in support for SOAP attachments. The Message Transmission Optimization Mechanism (MTOM)92, a part of the SOAP 1.2 specification, may be a possible amendment to the latter problem by making attachments appear as SOAP messages transparently Burggraf, D.S. (2006), OWS 3 GML Investigations Performance Experiment, Open Geospatial Consortium, p. X 86 CEN/TC 287 (2005), Geographic information - Standards, specifications, technical reports and guidelines, required to implement Spatial Data Infrastructure, CEN/TC 287, p Goddard, T (2003), NETCONF Over SOAP, ( ) 88 Freed, N., Borenstein, N. (1996), Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, ( ) 89 Oracle (2005), Attachments in SOAP Messages - An Oracle white paper, Oracle, p.4 ( ) 90 Sonnet, J.(2005), OWS 2 Common Architecture: WSDL SOAP UDDI, Open Geospatial Consortium, p Business Process Execution Language for Web Services version 1.1, ftp://www6.software.ibm.com/software/developer/library/ws-bpel.pdf ( ) 92 W3C (2005), SOAP Message Transmission Optimization Mechanism, 93 Oracle (2005), Attachments in SOAP Messages - An Oracle white paper, Oracle, p

28 To conclude this discussion, handling large data attachments through streaming is considered key for high throughput and low response times.94 Streaming may be performed at the transport level by the SOAP engine or at the sending and receiving endpoints through streaming-enabled XML parsers. The SOAP specification allows for incremental processing of SOAP messages, as long as the result is the same as when the entire message is processed at once. However, the SOAP specification does not mandate streaming support, which leaves it up to the SOAPimplementers to fulfil such needs. 94 Oracle (2005), Attachments in SOAP Messages - An Oracle white paper, Oracle, p

29 3 INSPIRE and the Need for Geospatial Information and Services This chapter describes INSPIRE and the network services that are required from member states, as well as discusses some geospatial standards that are candidates for fulfilling those requirements. 3.1 INSPIRE as a Foundation for a European Spatial Data Infrastructure While the geospatial services described in Chapter 2 can form a distributed GIS, they will be useless if they do not have access to geospatial information. Today, there is a global trend among nations and regions to develop frameworks that supports ready access to geospatial information. Such a framework is called a Spatial Data Infrastructure (SDI). Many definitions of SDI have been proposed over the years to make it fit into different local contexts. Masser provides a general definition: A spatial data infrastructure supports ready access to geographic information. This is achieved through the co-ordinated actions of nations and organizations that promote awareness and implementation of complimentary policies, common standards and effective mechanisms for the development and availability of interoperable digital geographic data and technologies to support decision making at all scales for multiple purposes. These actions encompass the policies, organizational remits, data, technologies, standards, delivery mechanisms, and financial and human resources necessary to ensure that those working at the (national) and regional scale are not impeded in meeting their objectives.95 From this definition it is clear that implementing an SDI is a vast undertaking, involving not only technical issues, such as data, technologies, standards, and delivery mechanisms, but also institutional matters, related to organisational responsibilities and information policies.96 In line with the global trend of SDIs, the European Union has taken an initiative to establish an ESDI. In 2004, the Commission of the European Union submitted a proposal for a directive to the European Parliament and the Council of the European Union for establishing an INfrastructure for SPatial InfoRmation in Europe: INSPIRE. INSPIRE intends to set the legal framework for the gradual creation of an ESDI based on national SDIs of member states, with a focus on environmental information.97 INSPIRE will be a step towards making interoperable spatial information readily available in support of national and Community policy and to enable public access to such information. The directive was motivated by the fact that good policy depends on high-quality information and informed public participation. The increased complexity of the issues affecting society has made policy-makers in the European Union recognise the need for a new approach to deal with monitoring, reporting, data management and data delivery across the different levels of government. By employing policies to reduce the duplication of data collection and to assist and promote the harmonisation, broad dissemination and use of data, the result would be increased efficiency and improved availability and quality of information. It was recognised in the 95 Masser, I. (2005), GIS Worlds: Creating Spatial Data Infrastructures, Redlands, California: ESRI Press. p Ibid, p Annoni, A., Smits, P (2003), Main problems in building European environmental spatial data, International Journal of Remote Sensing, 2003, VOL. 24, NO. 20, , Taylor & Francis Ltd, p

30 proposal for a directive that spatial information in particular can play a special role in this new approach since it allows information to be integrated from a variety of disciplines for a variety of uses. INSPIRE is geared towards the environmental sector but may be extended to include other sectors in the future.98 The National Land Survey of Sweden (Lantmäteriet) is responsible for coordinating the development of a Swedish SDI. Lantmäteriet represents Sweden as a Legally Mandated Organisation (LMO) in the INSPIRE proceedings. As an LMO, Lantmäteriet will make sure that the Swedish SDI includes the necessary INSPIRE components: metadata, spatial data themes (as described in Annexes I, II, III of INSPIRE), spatial data services; network services and technologies; agreements on sharing, access and use; coordination and monitoring mechanisms, process and procedures.99 Lantmäteriet provides the general public, the private and public sectors as well as other users in Sweden with geographic and real property information in the form of vector data, maps, aerial photography and satellite imagery. The overarching mission of Lantmäteriet is to manage the Swedish cadastral system and promote the rational subdivision of land, and to be responsible for the efficient provision of basic geographic and land information. Geographic information is provided through distributors. An important activity of Lantmäteriet is to maintain the Real Property Register which contains information about Sweden s real estate that is of fundamental importance for Swedish society and the economy.100 In the field of environmental information, Lantmäteriet is working together with the Swedish Environmental Protection Agency (Naturvårdsverket) to build up the components of a separate SDI with a special focus on environmental information. Geographic information in Sweden is mainly collected at the national and the municipal level, but increasingly also at the county level.101 The independent status of municipalities makes voluntary cooperation the necessary basis for the national management of geospatial information Current Status and Future Plans INSPIRE has since it was proposed entered a co-decision legislative procedure103 where the Commission, the Council and the European Parliament discuss and further shape the proposal. This process is expected to result in the entering into force of the directive during It has become clear that the Parliament and the Council take stands quite far apart on the issue of whether intellectual property rights (IPR) held by public authorities should be accepted as grounds for restricting public access to geospatial data sets or not. 104 The Parliament has taken a position close to the Commission's initial proposal on the issue, while the Council has taken a 98 Commission of the European Communities (2004), Proposal for a Directive of the European Parliament and of the Council : Establishing an Infrastructure for Spatial Information In the Community (INSPIRE), Brussels, p.3 99 Dufourmont, H., Annoni, A. & De Groof, H. (2004), INSPIRE - work programme Preparatory Phase , ESTAT-JRC-ENV, p Lantmäteriet Web Site (2006), ( ) 101Hall, M., Beusen, P. (2005), Spatial Data Infrastructures in Sweden: State of play Spring 2005, ( ), p.5 102Ibid., p For a description of the co-decision procedure, see EUROPA: the online portal site of the European Union, 104For a discussion of geospatial IPR, see Bishr, M.A (2006), Geospatial Digital Rights Management with focus on Digital Licensing of GML datasets, International Institute for Geo-Information Science and Earth Observation, Enschede, Netherlands. 22

31 common position of including IPR formulations in the directive.105 If the council and parliament cannot compromise, the proposed directive will not be adopted. In parallel with the co-decision procedure, a three-phased programme has been initiated, consisting of a Preparatory phase ( ), a Transposition phase ( ) and an Implementation phase ( ). The Preparatory Phase will prepare the future implementation of the directive.106 If adopted, INSPIRE must be implemented by national law in the member states of the European Union to whom the directive is addressed. A directive is legally binding as regards the results to be attained but leaves it free to the implementing states to determine how that result will be achieved.107 However, for INSPIRE to be effective, some measures will be provided in detailed Implementing Rules that are legally binding and ensures coherent implementaion. Five Drafting Teams (DT) will draft such Implementing Rules108 during the Preparatory Phase. Although this thesis is will have a particular focus on the work of the Network Services DT, the following is an overview of the responsibilities of the five DTs. Metadata Details issues such as what metadata should be collected and what quality it should have Data Specifications Will establish, among other issues, a uniform information model for geospatial information in the ESDI (see Section 3.4.1) Network Services Specifies six types of network services (see Section 3.4.2) Data and Service Sharing Deals with issues of data and service access rights and sharing. Monitoring and Reporting Specifies how member states should monitor and report on implementing INSPIRE. Input to the DTs will be provided by early projects, pilots and prototypes that test the specifications embedded in the draft Implementing Rules.109 Of special importance to the Network Services DT are inputs that can be gathered from projects addressing architectural issues of relevance to an ESDI, such as ORCHESTRA110, RISE111, GMES112, and the EUGeoportal113. Input will also be drawn from standardisation processes within W3C114, WS-I115, 105European Commission (2006), 2004/0175(COD) Communication From the Commission to the European Parliament ( ) 106Dufourmont, H., Annoni, A. & De Groof, H. (2004), INSPIRE - work programme Preparatory Phase , ESTAT-JRC-ENV, p Europa The European Union Online - European Judicial Network in civil and commercial matters, ( ) 108Implementation Rules are legally binding on all individuals or organisations to whom it is addressed and ensures a coherent implementation of the proposed INSPIRE Directive. 109Dufourmont, H., Annoni, A. & De Groof, H. (2004), INSPIRE - work programme Preparatory Phase , ESTAT-JRC-ENV, p.22f 110Open Architecture and Spatial Data Infrastructure for Risk Management (ORCHESTRA) (2006), ( ) 111Reference Information Specifications for Europe (RISE) (2006), ( ) 112Global Monitoring for Environment and Security (GMES) (2006), ( ) 113European Geo-Portal (2006), ( ) 114World Wide Web Consortium (W3C) (2006), ( ) 115Web Services Interoperability Organization (WS-I) (2006), ( ) 23

32 OMG116, OGC117, ISO118, OASIS119 and CEN A Proposed European Spatial Data Infrastructure Architecture The fundamental principles for a ESDI was stated early on by the European Commission as121: 1) Data should be collected once and maintained at the level where this can be done most effectively 2) It should be possible to combine seamlessly spatial information from different sources across Europe and share it between many users and applications 3) It should be possible for information collected at one level to be shared between all the different levels, detailed [information] for detailed investigations, general [information] for strategic purposes 4) Geographic information needed for good governance at all levels should be abundant under conditions that do not refrain its extensive use 5) It should be easy to discover which geographic information is available, fits the needs for a particular use and under which conditions it can be acquired and used 6) Geographic data should become easy to understand and interpret because it can be visualised within the appropriate context selected in a user-friendly way As part of the technical issues of an SDI and based on the above principles for the ESDI, the Architecture and Standards (AST-WG) Working Group provided recommendations related to architecture and standards for the INSPIRE legislative framework. The AST-WG definition of an architecture includes "the models, standards, technologies, specifications, and procedures used to represent, transform and generally accommodate the integration, maintenance and use of information in digital format"122. The proposed ESDI architecture consists of "interoperable services that can produce and publish, find and deliver, and eventually, use and understand geographic information over the Internet across the [EU]... at local, national, and European levels"123. Because technologies evolve rapidly, it is recognised that the technology focus should be flexible and directed on standardisation processes rather than locked on specific current technologies. The architecture is therefore proposed to be loosely coupled and open in the sense that new technologies can be used as they come into existence. The vision is a distributed network of geospatial databases, linked by common standards and protocols to ensure compatibility and interoperability of data and services across administrative borders in the EU. It is seen as important for the ESDI to offer a single entrance point for access to geospatial data and services, called a geoportal. A geoportal does not necessarily mean a highly centralised technical solution, but could instead allow for a distributed solution, like the architecture 116Object Management Group (OMG) (2006), ( ) 117Open Geospatial Consortium, Inc. (OGC) (2006), ( ) 118International Organization for Standardization (ISO) (2006), ( ) 119Organization for the Advancement of Structured Information Standards (OASIS) (2006), ( ) 120European Committee for Standardization (CEN) (2006), ( ) 121European Commission, Directorate-General Environment (2001), ESDI Organisation and E-ESDI Action Plan, Final Draft version 0.13 of 20 December 2001, Brussel - Belgium, p.6 ( ) 122Smits, P (ed.) (2002), INSPIRE Architecture and Standards Position Paper, JRC-Institute for Environment and Sustainability, Ispra, p.vi 123Ibid., p.14 24

33 proposed by the AST-WG.124 The proposal for a directive states that the commission will create and operate such a geoportal, where member states will make their network services available. However, each member state may also provide access to their SDI services by other means The Needed Geospatial Information and Services INSPIRE defines a number of network services required by all member states in order to share geospatial information. A common understanding of the geospatial information to be shared in the ESDI needs to be defined, as well as a data interchange format for use with the network services. This section discusses these requirements and relates them to current geospatial standards that may be suitable for implementing them A Uniform Information Model It is often stated that standards promote interoperability. ISO defines interoperability as the "capability to communicate, execute programs, or transfer data among various functional units in a manner that requires the user to have little or no knowledge of the unique characteristics of those units"126. Of fundamental importance within the context of an ESDI is the observation that, even if systems that allow data to be transfered between different SDIs are set up, they will not be of much use if there is not also a common understanding among humans and machines of the meaning of that data. ISO distinguishes this latter issue of a common understanding of the data contents as semantic interoperability, from the issue of data transfer as syntactic interoperability.127 Semantic interoperability is hampered by semantic heterogeneity, which occurs when two geographic information communities use the same name for different phenomena, or different names for the same phenomenon.128 Cross-administrative use of spatial information in Europe is generally hampered due to reasons such as fragmented or missing datasets, lack of harmonisation between different datasets, datasets differing in geographic scale and differing in quality due to duplication in data collection.129 The negative effects of this have been experienced by e.g. organisations in the EU carrying out environmental impact assessments in order for certain projects to be authorised. This may involve combining environmental information with topographic data and health statistics. It is often the case that the needed data comes from different data providers and that the data sets are not compatible. Adaptations of the data are often needed, something that is expensive in terms of time and money and may actually result in excluding the use of spatial data altogether. It has been estimated that INSPIRE could improve quality and reduce costs for preparing environmental impact assessment and related studies in the EU by million Euro per year, by addressing problems related to the availability of spatial data Bernard, L., Kanellopoulos, I., Annoni, A., Smits, P. (2005), The European geoportal one step towards the establishment of a European Spatial Data Infrastructure, Computers, Environment and Urban Systems 29 (2005) 15 31, p Commission of the European Communities (2004), Proposal for a Directive of the European Parliament and of the Council : Establishing an Infrastructure for Spatial Information In the Community (INSPIRE), Brussels. p.22. (Article 21:1,2) 126ISO - International Organisation for Standardisation (2005), ISO 19119:2005(E): Geographic information Services, p.2 127Ibid., p.8 128Bishr, Y. (1998), Overcoming the Semantic and Other Barriers to GIS Interoperability, International Journal of Geographical Information Science, 12 (1998) , p INSPIRE Web, Joint Research Committee (2006), ( ) 130Vanderhaegen, M., Muro,E. (2005), Contribution of a European spatial data infrastructure to the effectiveness of EIA and SEA studies, Environmental Impact Assessment Review (2005) , p

34 It is clear that for the ESDI to be effective, there is a need for semantic interoperability of data, metadata and services; expressing various concepts in a formalised way according to an agreedupon unified data language for the ESDI. Such a common and formalised understanding among the involved parties of a particular application domain is here defined as an information model. Conceptualising and formalising rules for geospatial metadata and services is the task of the INSPIRE Metadata DT, while the corresponding task for geospatial data is the responsibility of the Data Specifications DT. When these DTs are done formulating their Implementation Rules, the individual information models of metadata, data and services will together form a common information model for the ESDI. When this information model is adopted by member states, it is possible to integrate and use spatial data sets and services from the different SDIs in Europe. There are at least two options for how to conform with a uniform information model, and the proposed directive leaves it to each member state to decide which option to implement. One option would be to convert all national spatial data and metadata holdings to achieve total conformity with the common information model of the ESDI. This somewhat utopian vision of true harmonisation of spatial data sets in the EU by all data custodians is however very difficult and costly to achieve, even in the long run, because of the many existing data custodians in the combined member states, which often use different information models. A second option is for member states to provide interfaces to transform heterogeneous data to the uniform model. 131 By allowing spatial data sets to be kept in the member states' internal format and transformed upon request into the common information model of the ESDI, these interfaces are a good short-term solution that greatly improves the feasibility of making environmental geospatial information in the EU more accessible. The latter option is likely to be chosen by member states that have already made progress in their national SDI initiatives, including Sweden.132 Transformation of data sets into the common information model could be performed on-the-fly directly from the data source. Alternatively, all of the EU geospatial data could be transformed at a regular interval, e.g. once a month, and stored in a single data repository. Such architectural choices need to be guided by several variables such as the amount of data to be transformed, location of data sources, criticality of data, currency and accuracy of data, security and privacy requirements and budget.133 If there is a risk that components of a distributed database may become disconnected, a single data repository would perhaps be more suitable for time-critical applications such as crisis management, where simultaneous and instant access to all the data sets must be guaranteed. In that case, it is necessary to ensure that failure of the single data repository can be recovered from measures such as data redundancy. At a technical implementation level, based on its status as an internationally accepted geospatial standard, it is very likely that the data interchange format of the ESDI will be the Geography Markup Language (GML), and that the transported data will conform to a GML application schema that realises the uniform information model of the ESDI (see section 2.2 for a description of GML and application schemas). An important input to the INSPIRE process regarding data harmonisation will be provided by the Reference Information Specifications of Europe (RISE) project, which aims to deliver a repeatable methodology for developing, adopting and maintaining a geospatial data implementation specification for a subset of the INSPIRE 131Commission of the European Communities (2004), Proposal for a Directive of the European Parliament and of the Council : Establishing an Infrastructure for Spatial Information In the Community (INSPIRE), Brussels. p.7 132For an overview of SDI initiatives in the EU, see Vandenbroucke, D. (2005), "Spatial Data Infrastructures in Europe: State of play Spring 2005", ( ) 133Fischer, B. (2005), OGC White Paper: Server Architecture Models for the National Spatial Data Infrastructures (NSDI), Open Geospatial Consortium, p

35 Annex I and II spatial data, including among other parts a GML application schema.134 One example of an EU-funded project where a unified information model for geospatial information was developed and successfully used is GiMoDig135. In this particular project the several countries involved agreed on defining 17 feature types (e.g. building, road, forest) for the unified information model, which was realised through a GML application schema (see Chapter 2 for a discussion of feature types and other GIS-related concepts).136 More specifically, the data sets of each individual country where made accessible through the WFS interface (see section 2.2) in GML format, conforming to a country-specific GML application schema. A central cascading WFS service provided a single access point to the geospatial data by linking to all the individual WFSs and transforming the data they served to conform with the unified GML application schema Network Services INSPIRE states that network services are needed for the sharing of spatial data between public authorities in the EU. The network services should make it possible to discover, transform, view and download spatial data and to invoke e-commerce and spatial data services. 138 This section discusses the required INSPIRE network services and relates them to some geospatial standards that may be suitable for their implementation. The Network Services DT is responsible for drafting implementation rules concerning the network services that are required from member states by INSPIRE, including security and minimum performance requirements. Following the discussion of Section 3.4.1, the INSPIRE network services can be said to be geared more towards syntactic than semantic interoperability. However, a clear cut is difficult to achieve since parts of the uniform information model also deals with syntactical issues (e.g. specifying what a service interface is). The implementation rules provided by the Network Services DT will be precise, with the goal that each member state will be able to implement services compliant with the implementation rules. Six types of network services are required in the proposal for a directive. Transformation services, enabling spatial data sets to be transformed Discovery services, making it possible to search for spatial data sets and spatial data services on the basis of the content of the corresponding metadata and to display the content of the metadata View services, making it possible as a minimum to display, navigate, zoom in/out, pan, or overlay spatial data sets and to display legend information and any relevant content of metadata Download services, enabling copies of complete spatial data sets, or parts thereof, to be downloaded Upload services, for making metadata and spatial data sets and services accessible through the other network services 134Dufourmont, H., Annoni, A. & De Groof, H. (2004), INSPIRE - work programme Preparatory Phase , ESTAT-JRC-ENV, p Sarjakoski, T., Sarjakoski, L.T (2005), The GiMoDig public final report, Finnish Geodetic Institute (FGI) ( ) 136Ibid., p Ibid., p Commission of the European Communities (2004), Proposal for a Directive of the European Parliament and of the Council : Establishing an Infrastructure for Spatial Information In the Community (INSPIRE), Brussels. p.12 27

36 Invoke spatial data services services, enabling data services to be invoked In addition, for both download services and "invoke spatial data services" services, a member state should make e-commerce services available if the authority in question demands payment for usage of such services. The cited and unfortunately complicated name "invoke spatial data services" services is due to the distinction made between a network service and a spatial data service. A network service may invoke a spatial data service. A spatial data service is defined as "the operations which may be performed, by invoking a computer application, on the spatial data contained in spatial data sets that have a connection to the ESDI or on the related metadata"139. It can be argued that the distinction made between the two is ambiguous in some cases. For instance, how does the above definition of a spatial data service differ from the purpose of the network service type transformation service? The Network Services DT has provided a public and "living" document where any assumptions and issues open for interpretation, such as the one above, are discussed.140 A proposal by the Network Services DT has been to distinguish a transformation service from a spatial data service by availability on the Internet. A transformation service must be accessible over the Internet while a spatial data service does not have to be. An assumption has been made that spatial data services do not have to be on-line, but may be wide range including stand-alone applications, off-line processing, or general services like consultancy services.141 Another fundamental assumption made by the Network Services DT is that the implementation rules shall only specify communication between client and server, not including issues such as user interface interaction or service back-end interaction such as how data is accessed. Furthermore, when data is involved in a network service it is by default INSPIRE harmonised data, with the exception of the upload service.142 The required network services and some current and developing standards that may satisfy these requirements are discussed in sections through The system implementation (Chapter 5) of this thesis project has a particular focus on the WMS, WFS and WPS interfaces and therefore the operations that each of them provides are discussed in Chapter Transformation Services Transformation services shall enable spatial data sets to be transformed. INSPIRE states that the purpose of the transformation services is to allow the other network services to operate in conformance with the implementing rules laid down for harmonised spatial data specifications and arrangements for the exchange of spatial data.143 Transformation services are expected to be combined with other services to form a service chain, that is, the output of one service is used as the input to the next service. The transformation services would allow for operations such as 139Commission of the European Communities (2004), Proposal for a Directive of the European Parliament and of the Council : Establishing an Infrastructure for Spatial Information In the Community (INSPIRE), Brussels. p.15, Article 2(2) 140Joint Research Centre, Detailed Definitions on the INSPIRE Network Services, JRC-Institute for Environment and Sustainability, Ispra, p.1 141Ibid., p.9 142Ibid., p.3 143Commission of the European Communities (2004), Proposal for a Directive of the European Parliament and of the Council : Establishing an Infrastructure for Spatial Information In the Community (INSPIRE), Brussels. p.21, Article 18(3) 28

37 coordinate transformations, useful for clients working directly with data in a national coordinate reference system (CRS) combined with ESDI data.144 The OGC Web Coordinate Transformation Service (WCTS) is an evolving discussion paper that may deal with this particular issue Discovery Services With the growing amount of geospatial data created and stored in repositories follows the need for users to be able to find the data, and evaluate if it fits their requirements.146 INSPIRE considers it a high priority that member states should provide metadata descriptions of their available spatial data sets and services.147 Metadata describing resources can be stored in catalogue services that offer the ability to discover specific geospatial content.148 OGC has developed an Implementation Specification for catalogues that may be suitable for the needs of INSPIRE. It is generally the case for OGC Specifications that a single platform-neutral specification of a service provides the basis for several different platform-specific specifications, which in turn may be implemented as actual services. This is also the intention with the OGC Catalogue Services Specification v.2.0, which provides general descriptions of platform-neutral catalogue operations. Several platform-specific application profiles may comply with this specification; each fulfilling the needs of a particular user community. An application profile is platform-specific in that it makes use of one of the protocol bindings defined in the catalogue specification.149 One of the specified bindings is HTTP, a binding that is called Catalogue Service for the Web (CSW). An application profile also provides an information model for the particular application. This relation is depicted in Figure 3.1. Figure 3.1: The typical pattern of an implementation conforming to a platformspecific application profile that in turn complies with a platform-neutral specification. Adapted from Senkler, K.,Voges, U., Remke, A. (2004). 144Joint Research Centre, Detailed Definitions on the INSPIRE Network Services, JRC-Institute for Environment and Sustainability, Ispra, p.9 145Whiteside, A., Müller, M.U., Fellah, S., Warmerdam, F. (2005), Web Coordinate Transformation Service (WCTS) draft Implementation Specification, Open Geospatial Consortium, ( ) 146Nebert, D. (Ed.)(2004), Developing Spatial Data Infrastructures: The SDI Cookbook (Version 2.0), GSDI, p.24 ( ) 147Commission of the European Communities (2004), Proposal for a Directive of the European Parliament and of the Council : Establishing an Infrastructure for Spatial Information In the Community (INSPIRE), Brussels. p.17, Article 8(1) 148Nebert, D. (Ed.)(2004), Developing Spatial Data Infrastructures: The SDI Cookbook (Version 2.0), GSDI, p.40 ( ) 149Nebert, D. Whiteside, A. (Eds.)(2005), OGC Catalogue Services Specification Version with Corregendum, p

38 One of the developed application profiles that complies with the specification is the ISO19115/ISO19119 Application Profile for CSW. The information model defined by this application profile is based on the ISO19115 standard for data metadata and the ISO19119 standard for service metadata.150 This application profile is a result of interoperability issues of local SDIs in Germany and has showed that the OGC specification is sufficient for the needs of that user community; the plan is that the profile will form the basis for all SDI activities in Germany.151 A similar application profile of the CSW could be developed for the European community as a solution to the INSPIRE discovery service requirement. Searching a catalogue service is possible using one of the supported query languages. The OGC Common Query Language (CQL), defined in BNF152, is required to be supported by all OGC catalogue services.153 This improves interoperability among catalogue services, since a basic set of queries can be evaluated on catalogue implementations conforming to different application profiles. One particular realisation of OGC CQL is the OGC Filter Encoding Implementation Specification, which is XML encoded with the intent to be easily parsable using existing XML parsers and to be easily translatable into a target predicate language, such as an SQL where clause. Using Filter encoding, the below example catalogue query filter would return only the features that either are named "Elbe" or have a length that is greater than or equal to 500. <Filter xmlns= xmlns:myns= > <Or> <PropertyIsEqualTo> <PropertyName>myns:name</PropertyName> <Literal>Elbe</Literal> </PropertyIsEqualTo> <PropertyIsGreaterThanOrEqualTo> <PropertyName>myns:length</PropertyName> <Literal>500</Literal> </PropertyIsGreaterThanOrEqualTo> </Or> </Filter> Through the geoportal, national SDI catalogues aligned with the uniform information model of the ESDI would enable distributed queries on metadata in the ESDI, as depicted in Figure 3.2. By using standards-based catalogue services, it is possible to search other catalogue services that are linked to the ESDI but adhere to different application domains and supports CQL. 150Senkler, K., Voges, U. (2006), OpenGIS Catalogue Services Specification (with Corrigendum) - ISO Metadata Application Profile, p Senkler, K.,Voges, U., Remke, A. (2004), An ISO 19115/19119 Profile for OGC Catalogue Services CSW 2.0, Workshop paper presented at 10th EC-GI & GIS Workshop,Warsaw, Poland, June 23-25, 2004, p.8 ( ) 152BNF is short for Backus Naur Form 153Nebert, D. Whiteside, A. (Eds.)(2005), OGC Catalogue Services Specification Version with Corregendum, p.9 30

39 Figure 3.2: An architecture for distributed catalogue search in a ESDI. Transformation services of each SDI transforms local metadata into the harmonised information model. The transformation services are chained with discovery services which make the metadata accessible in the ESDI View Services Member states shall provide services for viewing spatial data sets, with the possibility to display, navigate, zoom in/out, pan, and overlay such data sets and to display legend information. While INSPIRE leaves it open how to address issues such as the need for metadata access and handling of potentially differing coordinate reference systems of data sets, this required network service type is otherwise straightforward. Fortunately there is a standardised WMS interface especially designed for such usage which would be appropriate for the view services. The WMS interface is discussed further in Section Download Services The INSPIRE proposal states that copies of complete spatial data sets, or subsets, should be possible to download through download services. A possible use case scenario is that a user can download (sub)sets of data of a particular geographic area of interest currently displayed on a map. The definition of a subset is not clear in the INSPIRE proposal, but possible candidates for download include layers, features, and attributes of features. The WFS interface discussed in Section 2.2 offers the ability to download at least subsets of data layers as features and attributes. Download services may be combined with e-commerce services if the public authority responsible for the data in question demands payment for usage of that data. In ISO services terminology, such payment services are considered general system management IT services and not geographic services. This separation is intended to promote the use of existing 31

40 IT services whenever possible.154 Existing e-commerce services of member states need to adapt a suitable interface in order to be chainable with INSPIRE network services. Even though security issues are not a focus of this thesis, it may be pointed out that the valuable data in question, and the intellectual property rights claimed on them, may deem security measures for service access and data transfer particularly important for download services. Who should have access to what information and what granularity would need to be considered? This problem is deeply connected with the work of the Data and Service Sharing DT Upload Services It is open for interpretation whether an upload service is intended to allow the physical transfer of data and metadata between member states or if it is merely intended to allow publishing the availability of data and services in a member state SDI for subsequent access through other network services.155 These services are an exception to the DTs assumption that all data handled by INSPIRE network services are in the uniform information model of the ESDI; the data can potentially be in native formats.156 The DT has further assumed that only data and metadata for services and data should be considered for upload. The WFS interface discussed in section 2.2 enables the transfer of geospatial features and may be a solution to the requirement for upload services Invoke Spatial Data Services Services "Invoke spatial data services" services must enable spatial data services to be invoked. The possible uses for this type of network service are many and include invoking environmental analysis functionality or off-line spatial data services (e.g. physical delivery of printed maps). INSPIRE states that member states shall ensure that e-commerce services are available where public authorities levy charges for the usage of invoke spatial data services services. One of the findings in an effort to specify an architecture for the ESDI geoportal was that, at the time, there existed no service interface specification that covered various services for processing geographic information, such as coordinate transformation, classification or generalisation.157 Since May 2005, this issue is in the process of being solved. An OGC discussion paper of a WPS is being developed with the aim to specify a general purpose interface providing access to processes capable of performing calculations on geospatial data. The proposed WPS interface is implemented in this thesis project, and is described further in Section 2.3. Since the WPS interface is still a discussion paper, it has not yet been implemented by many projects. One project that refers to WPS, and which is also an important input to the INSPIRE process, is the ORCHESTRA project; an EU funded effort to design and implement an open, service oriented software architecture to contribute to overcoming interoperability problems in 154ISO - International Organisation for Standardisation (2005), ISO 19119:2005(E): Geographic information Services, p Joint Research Centre, Detailed Definitions on the INSPIRE Network Services, JRC-Institute for Environment and Sustainability, Ispra, p.4 156Ibid., p.3 157Bernard, L., Kanellopoulos, I., Annoni, A., Smits, P. (2005), The European geoportal one step towards the establishment of a European Spatial Data Infrastructure, Computers, Environment and Urban Systems 29 (2005) 15 31, p.23 32

41 the multi-risk management domain Usländer, T. (Ed.) (2005), Reference Model for the ORCHESTRA Architecture (RM-OA), Open Geospatial Consortium, p ( ) 33

42 34

43 4 Design and Implementation of a Web Processing Service The WPS interface consists of three operations that provide users the possibility to remotely invoke processes that perform calculations on geospatial information, as discussed in section The WPS interface is tested by designing a distributed GIS including a WPS, WFS and WMS server and a GIS client. The system is realised by implementing a WPS server and WPS client and using them together with existing WMS and WFS implementations. Since the focus of this thesis is standards for geospatial data and services, it was decided that developing the client and server of the system would contribute to existing open source software and toolkits, thereby saving time by not having to re-implement already existing functionality, such as database access and map rendering. The WPS server and client were implemented as additions to the GeoServer and udig applications respectively. A more detailed discussion of these and other software chosen to implement the system can be found in Section 4.1. The client/server architecture of the implemented system is depicted in Figure 4.1. The WPS is deployed in a Tomcat application server as a component of GeoServer. The WMS and WFS components of GeoServer accesses a local PostGIS database to generate maps and GML documents as responses to incoming requests from the udig client. In addition to the normal functionality of accessing WMS and WFS servers, udig can also access the WPS server with the implemented Remote Operations plug-ins. Figure 4.1: Client-Server Architecture. The WPS is deployed in a Tomcat application server, responding to requests from udig which uses the Remote Operations Plug-in to communicate with the WPS. 35

44 4.1 GeoServer and udig Several open source GIS software projects exist within two main development communities: C and Java159. The Java-based GeoServer is chosen to implement the WPS server largely because of an active developer community and sufficient on-line documentation. Another reason for choosing GeoServer is that Lantmäteriet have had previous experience with the application from the GiMoDig project (see section 3.4.1). GeoServer provides an implementation of WMS and WFS (see sections 2.1 and 2.2). The current GeoServer architecture is more of an application than a modularised framework suitable for adding a new component such as a WPS. This made it necessary to in-depth learn large parts of the GeoServer code base in order to make the necessary additions that would make the WPS function as a part of the GeoServer architecture. Learning the GeoServer code-base was a particularly time-consuming effort. There is currently a process within the GeoServer community that aims to refactor the GeoServer code base to make use of some of the features of the Spring framework 160, thereby making it easier to plug in new services into the GeoServer framework. The User-friendly Desktop Internet GIS (udig) is a desktop application that supports manipulating and displaying geospatial features from different types of data sources, including remote sources such as WMS, WFS and local data storage such as the PostGIS database. udig was chosen to implement the WPS client since it is implemented in Java like GeoServer and supports plug-in addition of new functionality. udig also benefits from an active developer community. Both GeoServer and udig make use of GeoTools to provide important functionality. In fact, although these are three separate open source communities, they are working quite closely together. GeoTools provides an open source Java GIS toolkit for developing standards-compliant solutions.161 Of importance to this thesis project is that the GeoTools functionality includes among others a feature model, an implementation of the OGC Filter Encoding Specification 162 to specify a subset of features to operate on, renderers and datastore access to several database systems and file formats. The GeoTools feature model is in fact provided by yet another open source project: JTS Topology Suit (JTS). JTS Topology Suit (JTS) is a Java API that follows the OpenGIS Simple Features Specification for SQL, which defines a standard SQL schema that supports storage, retrieval, query and update of simple geospatial feature collections via the ODBC API.163 JTS provides robust methods supporting spatial analysis on features restricted to 2D geometry, such as polygons and linestrings. The PostGIS, the open source PostgreSQL database with spatial extensions, is used as a backend for GeoServer in the testing environment. PostGIS follows the OpenGIS Simple Features 159Ramsey, P. (2005), The State of Open Source GIS, Victoria, BC: Refractions Research Inc, p.6 ( ) 160Spring Framework Web Site (2006), ( ) 161GeoTools Web Site (2006), ( ) 162Vretanos, P.A. (2001), OGC Filter Encoding Specification () ( ) 163Open GIS Consortium (1999), OpenGIS Simple Features Specification For SQL, Open GIS Consortium, p.1 36

45 Specification for SQL, which makes it not only a geographic data storage extension, but it also provides functionality such as manipulating geographic data directly in the database. 164 However, PostGIS is only used for data storage in the implemented system. The data used to test the system was collected in the ESRI proprietary Shapefile data format from Boverket's VindGIS web site165 and converted into PostGIS tables. In PostGIS, a GIS layer (e.g. rivers) is represented by a database table, having a number of records representing feature instances. Columns of the table represents attributes of the feature type that the layer corresponds to (e.g. depth, geometry). Apache HTTP Server is used for web access and Apache Tomcat is used as the servlet container to deploy and test GeoServer with the implemented WPS component WPS Server Implementation An early design choice was to mirror the WPS design with the WMS and WFS design in order to achieve conformity with the overall GeoServer architecture. Therefore the WPS interface has been implemented using Java Servlet technology, with one servlet per operation. As depicted in Figure 4.2, each request is intercepted by a WpsDispatcher servlet, which then reads the HTTP message and based on the requested operation dispatches the request to the target servlet. The Capabilities, DescribeProcess and Execute servlets then makes use of several helper objects to create the XML response sent back to the client. Figure 4.2: WPS Internals. This figure shows internal dependencies of the WPS implementation. Not all the involved parts are displayed; the intention is to provide an overview of how different types of requests are separated and handled internally. A WPS provides access to geospatial processing services; here called WPS processes. A design goal was to allow for additional WPS processes to be added to the WPS in a simple manner. A Process interface was therefore designed, defining a set of methods that WPS processes are 164 Mitchell, T. (2005), Web Mapping Illustrated, Farnham, UK: O'Reilly Media Inc, p Boverket VindGIS (2006), ( ) 37

46 required to implement. An important method of the Process interface is performcalculation, which takes an Execute request object containing inputs and requested output formats and performs the calculation. The writeto method writes the process response to a provided Outputstream. An important method that must be implemented to enable a WPS process to describe itself is getprocessdescription. Two WPS processes were implemented in a sample application of environmental GIS, described next Environmental GIS - A Sample Application The system implemented in this thesis project in order to evaluate the WPS interface is a sample application, useful for environmental GIS analysis. At least two user actions are possible in this system. In the first case, a user wishes to calculate a buffer zone surrounding a river at a particular geographic location and display that buffer on a map. The ability to do this would e.g. be needed by planners when estimating the areas that would become affected by a river flood. The same functionality could also be used when determining the areas that would be affected by estimated noise levels at certain distances from a planned road segment. The implemented system lets the user calculate a buffer in one of two different communication modes; synchronous and asynchronous communication. The synchronous buffer calculation returns immediately with the result, whereas the asynchronous mode requires an initial request to start the calculation at the server followed by a subsequent request to retrieve the result as explained in Section The second application lets the user calculate the boundary length of a geometry, say an area represented by a polygon. This could e.g. be used when estimating the length of the needed temporary flood walls when simulating a flood catastrophe scenario. In the flood scenario, the user actions could be performed in sequence in an automated manner using service chaining, where the output of the buffer zone process would provide the input to the boundary length process. However, the implemented system requires the user to do this manually. The two actions are shown in Figure 4.3. Figure 4.3: Two actions made possible by the implemented system: buffering a geometry and calculating the boundary length of that buffer. 38

47 The system implements two processes to support these actions: BufferProcess and BoundaryLengthProcess. The Process interface and related classes are shown in Figure 4.4. Figure 4.4: The Process interface. This figure shows how the classes BufferProcess and BoundaryLengthProcess both realise the Process interface, which is needed by the WPS. The BufferProcess expects a GML geometry and a buffer distance as input and produces a buffer which is sent back to the client in the GML transfer format. The JTS method buffer is used for the spatial analysis. A buffer is defined as a geometric object that contains all direct positions whose distance from a specified geometric object is less than or equal to a given distance. 166 The JTS buffer operation geom.buffer(distance) computes the Minkowski sum of a geometry, with a disc of radius equal to the absolute value of the specified buffer distance.167 Figure 4.5 shows the initial and the resulting geometry before and after applying a buffer operation. Figure 4.5 An initial geometry (JTS Linestring) and the resulting geometry (JTS Polygon) before and after a buffer operation is executed. The specified distance is used as the radius of the disc (lower left corner). To test the support for synchronous and asynchronous process execution of the WPS interface specification, the BufferProcess may or may not start a new Java Thread depending on the values of the store and status parameters in the incoming Execute operation request. If the 166ISO - International Organisation for Standardisation, ISO 19107:2003 Geographic information - Spatial schema, p.4 167Aquino, J (2003), JTS Topology Suite - Version 1.4 Technical Specifications, Vivid Solutiuons, p.30 ( ) 39