INSPIRE Coordinate Transformation Service; the Specification and Experiences Gained

from a Pilot Implementation

Janne Kovanen, Lassi Lehto Finnish Geodetic Institute, Janne.Kovanen@fgi.fi, Lassi.Lehto@fgi.fi

Abstract According to one of the main strategic principles of the INSPIRE framework the

European Spatial Data Infrastructure (ESDI) is seen as a service infrastructure that is based on the National Spatial Data Infrastructures (NSDI) on the Member States (MS) level. Due to the national conventions the NSDIs are largely incompatible. Seamless access to consistent information on the European level can be potentially achieved by appropriate transformation mechanisms. In this paper Web Service-based content transformation are presented as a solution. In particular, the INSPIRE Transformation Services are discussed with special emphasis on coordinate operations. The relevant INSPIRE specifications are introduced and a pilot implementation of the INSPIRE Coordinate Transformation Service is described.

Keywords: Transformation Service, Coordinate Transformation, Coordinate Conversion, Coordinate Reference System, INSPIRE, Web Processing Service 1. INTRODUCTION

European Spatial Data Infrastructure (ESDI) is currently being intensively

developed. One of the most important drivers in this process is the INSPIRE Directive (EC 2007) and it's implementation undertaken by various actors both on the European level and in the Member States (MS). According to the main strategic principle of the INSPIRE framework, the ESDI is seen as a service infrastructure that is based on the National Spatial Data Infrastructures (NSDI) on the MS level.

The NSDIs in Europe are incompatible regarding applied data content structures,

encoding conventions, visualization practices etc. This is due to the diverse cultural traditions and varying stage of geographical information technology development. One of the aspects that differ from a European country to the next, is the spatial reference systems used for storing the location information contained in spatial data sets. The reference systems can use different means for referencing like addresses or grid reference systems, however, the main method is to use coordinate reference systems (CRS). Although well-specified coordinate reference systems exist for use in the Pan-European context, most of the existing data sets are still maintained in local systems and many of them will continue so for the foreseeable future. This is a justifiable as the original coordinates are more or as accurate than transformed coordinates.

In many occasions it is very difficult for the MS level actors to simply make their

data collections compatible with the common European level specifications. One of the most important reasons for this is the dependency on the extensive data capturing and maintenance procedures and tools that are tightly integrated to the existing data structuring and encoding conventions. A possible solution for this dilemma is to set up a separate service database, compatible with the common European data specifications. However, this approach introduces a couple of new problems. Access to the most up-to-date information gets broken, unnecessary duplication of data occurs (with probable inconsistencies) and data maintenance

duties increase. In addition, in case of really large databases the approach easily becomes impractical. In this situation real-time content transformations emerge as a promising solution.

2. CONTENT TRANSFORMATIONS IN THE INSPIRE FRAMEWORK

The INSPIRE Directive recognizes Transformation Service as one of the five

network service types essential for an interoperable SDI. The Directive presents Transformation Service as a special auxiliary service, designed to be used together with the other recognized service types (Discovery/View/Download) in order to make those services compatible with the common European specifications. This concerns both data content, in relation to the theme-specific INSPIRE data specifications, and service interfaces, in relation to the INSPIRE service interface requirements.

According to the INSPIRE Directive, Transformation Service can be used as an

alternative for the adaptation of the national data sets to the INSPIRE requirements. As such the service is predominantly seen as a support function for the data Download Service. However, the Directive states that a Transformation Service can be combined with the other service types to help make them compatible with the established interoperability requirements. Thus, a Transformation Service could potentially also process metadata content or map displays. A role of the Transformation Service might even be to only reconcile the differences in service interface protocol, leaving the transferred content untouched. It can be deduced from the Directive that Transformation Services are expected to be available free of charge, even though it is not explicitely stated.

2.1 The Implementing Rules and Technical Guidance

The INSPIRE Network Services Drafting Team has published the first draft

instructions for implementing Transformation Services. These instructions are divided into two parts: the Implementing Rule (IR) and the Technical Guidance (TG). The IR (INSPIRE 2008b) specifies the Transformation Service in abstract terms and is designed to serve as a single common conceptual level specification for the various types of transformations that might be needed in the context of the INSPIRE service infrastructure. This potentially covers transformations like language translations, geometric transformations (e.g. generalization), thematic reclassifications, transformations of visual properties, structural transformations, encoding translations, coordinate transformations etc.

The IR aims at covering all the conceivable transformation types and leaves the

technical details to be specified in the corresponding TG. The first example of a related TG document focuses on coordinate transformations (INSPIRE 2009). Schema transformation is another recognized transformation type and will potentially be specified as another TG at a later time.

2.2 Architecture Alternatives for a Transformation Service

The role of the Transformation Service in the INSPIRE context is to help other

services to work in compliance with the common European specifications. Therefore it is important to consider how the Transformation Service could and should be connected with the other service types. Various possible architectures can be recognized. The service might be taken as in internal function of another service type (Figure 1). In this case the service interface is invisible to the calling application and does not need to be standardized as a specific type of INSPIRE network service. An example of this approach is the support for internal coordinate transformations

provided by many existing Web Map Service (WMS) or Web Feature Service (WFS) implementations.

Figure 1: An UML activity diagram representing Transformation Service as an internal function of the content access service.

The second architecture approach is to make use of the Transformation Service

as a separate component, layered on top of the main service (Figure 2). In this case the Transformation Service is seen as an opaque layer hiding the main service from the calling application and has to support the content access interface of that service. However, the transformation might be configurable from the outside world and the access interface thus needs to be specified. A cascading/translating WFS approach is an example of this kind of service organization.

Figure 2: Transformation Service as a component layered on top of the content access service.

The third architecture alternative represents the approach taken in the INSPIRE

Directive: the Transformation Service is seen as a separate service category with its own distinctive service interface (Figure 3). In this case the Transformation Service is regarded as a type of geospatial processing service, capable of transforming its input data set from one form into another. The transformation is carried out according to instructions provided to the service by a set of input parameters. This setup facilitates

flexible service orchestration in which individual Transformation Services can be freely plugged into a content access service to achieve the best possible end result. This service chaining can be done manually or, in a more sophisticated setup, be managed by an automate service orchestration engine.

Figure 3: Transformation Service as an individual processing service.

3. COORDINATE TRANSFORMATION SERVICE INTERFACE A Transformation Service can support Download Services and View Services to

satisfy the requirements established for the common use of spatial data in the Pan-European context. In particular, Coordinate Transformation Services are essential in an environment, where spatial data are stored and viewed in multiple coordinate reference systems. Following its role as an auxiliary service with a support function, the interface of the Coordinate Transformation Service must facilitate easy chaining with other services.

The interface of the INSPIRE Coordinate Transformation Service is specified as

an Application Profile (AP) of the Web Processing Service (WPS), an official OGC standard (Schut 2007). An AP describes how the WPS serves a process that is recognized by OGC. This is achieved by a unique URN, an reference description of the process (XML document) and optionally via an human-readable description and WSDL description. A Coordinate Transformation Service instance is defined as a single WPS process conforming to the AP defined in the relating TG.

The interface incorporates the functionality of the mandatory operations of the

Web Coordinate Transformation Service (WCTS) specification, which has been published as an OGC Discussion Paper (Whiteside et al. 2007). The main concepts of the interface are based on the WCTS’s Transform operation. In addition, the interface makes use of the OGC Web Service's exception reporting mechanism to implement the WCTS’s optional IsTransformable operation under the same AP. The specified Coordinate Transformation Service accepts Geography Markup Language (GML) encoded data as input. A given service implementation can handle various GML versions. However, the version of the output will be the same as for the input, as the service is not supposed to support schema transformations.

4. PROTOTYPE IMPLEMENTATION A test implementation of the service was developed at the Finnish Geodetic

Institute using Open Source libraries as the basis. For efficiency reasons the implementation uses a straightforward method of transforming the input coordinates point by point, ignoring the geometry and application specific elements in case of non-coverage GML data. The only situation where geometry is taken into account is the special case of bounding boxes. The prototype demonstrates that the interface specification can be realized and is suitable for the given purpose. In addition, the prototype gives guidelines for the further developments.

Implementations of the Coordinate Transformation Service are platform

independent as the client only sees the service interface. This creates a favourable situation in which the restrictions are only based on the available components to implement the service interface. The Coordinate Transformation Service consists of two components, the first being the WPS instance and the second being the process performing the actual coordinate transformations. The relationship between these two depends on the implementation of the WPS.

4.1 Selecting the WPS instance

The WPS instance must be compatible with the official version 1.0.0 of the WPS

specification. At the time of development only the open source WPS implementation of the 52ºNorth community (52N 2009) fulfilled this requirement, others being 0.4.0 compliant. Therefore the 52ºNorth's WPS implementation was selected as the development platform. Since then a few other implementations have also achieved 1.0.0 level. However, the official version does not guarantee that the WPS would be suitable for the service, it only assures that the mandatory elements of the WPS service exist. In addition the WPS needs to support some optional features of the WPS specification. These include the use of Application Profiles (AP), Simple Object Access Protocol (SOAP) as the communication-protocol and the Web Service Definition Language (WSDL) as the binding technology. The WPS also has to support non-standard process-specific exception codes, which allow the process to respond to the IsTransformable operation query.

The requirement for Applications Profile support is on theoretical level as the

profiles should be also supported by registry services, where the profiles are in a semantically defined hierarchy. Until such registries exist the client has to recognize the process identifier as no registry service allows to query a reference process description or the human-readable documentation.

The WPS specification defines a binding for the SOAP/WSDL protocol, but it's

implementation can be seen as optional. Thus, not all WPS 1.0.0 services support SOAP/WSDL. However, the INSPIRE Network Services Architecture Document (INSPIRE 2008) defines the default protocol for INSPIRE services to be SOAP. The version of the protocol for the INSPIRE framework is currently 1.1 (Villa et al. 2008), which can differ from the version used by WPS instances. This is a result of choosing an different version than the OGC's discussion paper on SOAP (Schäffer 2008) and W3C recommend. In the next versions of the INSPIRE SOAP framework it is probable that a transition from the current WS-I Basic Profile version 1.2 to version 2.0 will occur, thus changing the SOAP version to 1.2 (Villa et al. 2008). However for now all INSPIRE Network Service should support SOAP 1.1 as messaging protocol, HTTP as the transport protocol and WSDL 1.1 for describing the Web Service. Because this change is probably forthcoming, it was seen that sticking strictly to SOAP 1.1 was not necessary for the prototype.

An important aspect in choosing a WPS instance is also to take into account how

the processes, in this case especially the coordinate transformation process, can be provided through the WPS interface. Aspects that came up in the prototype development were the configuration of the WPS, demand for a particular coding language of the process and accessibility to the input data. Some WPS instances allow to implement the processes in any programming language, like the PHP-based WPS server (Bergenheim et al. 2009). In the case of the 52ºNorth's WPS the required programming language was Java 1.5.

4.2 Customizing the WPS instance

The 52ºNorth's WPS uses the Java Topology Suite (JTS) to access geometries

and the GeoTools-project (GeoTools 2009) for manipulating feature data, coverages and parsing GML 2 data. The GML’s XML-structured data is bound to Java types through the Apache XMLBeans. The WPS can handle KVP/GET, XML/POST and XML/SOAP request. In addition, the WPS supports WSDL, storing results, informing of process status and exception handling. In case the data have to be stored on the WPS server, an embedded Apache Derby database can be used. The logging of the Web Service’s actions is performed using the Apache log4j and the project is managed using the Apache Maven Project.

The WPS implementation needed only little customization. The main addition to

the WPS was to implement a streaming parser, that forwards the input data to the process. This allows the WPS process to decide how the input data is handled. The default behaviour of the WPS is to objectize the GML data. Subsequently the process became independent of the GML version. This was beneficial as the WPS did not support GML 3 versions. A new output writer was also developed to write the output data without the need to first convert objects to GML data. One optional addition was to include a new database handler (HSQLDB), which is used to store the CRS and transformation related parameters (e.g. affine parameters of a triangle-wise transformation).

4.3 Implementation of the transformation process

The WPS responses to the GetCapabilities queries based on it's configuration

that is aware of all available processes. The WPS also handles the WSDL queries, which are an alternative for the GetCapabilities queries. In case of an Execute operation request the WPS reads the input data from the contents of the XML- encoded SOAP envelope (or XML/POST or KVP/GET message).

4.3.1 Input data

The input data is composed of the data to be transformed together with

constrained and optional parameters. The source and target CRS identifiers ('SourceCRS' and 'TargetCRS') are mutually exclusive with the coordinate operation ('Transformation'). However, if the coordinate operation is an coordinate conversion then the target CRS identifier becomes mandatory.

The data to be transformed can also be given as a reference to a Web-accessible

resource like a WFS query string (i.e. URL) in which case the WPS first downloads the data. To test whether the transformation is possible, the boolean 'TestTransformation' parameter can be assigned. If the GML data contains coverages then the desired interpolation method can be designated by one of the interpolation type identifiers ('nearest', 'linear', 'quadratic', 'cubic' or 'none') defined by

Whiteside & Evans (2008). Nevertheless, handling of null values is not defined. The CRS and transformation identifiers can be OGC URNs as described in the TG (INSPIRE 2009). The version of GML is left open, because most Web services do not yet support the GML version 3.2.1 (ISO 19136:2007) that is initially going to be used by the INSPIRE Network Services.

All parameters are forwarded directly to an instance of the process without

converting the GML data to corresponding Java objects. Multiple processes can work simultaneously as these are threaded. The first step in the process is to check that the input has been given correctly, as the WPS does not manage multiplicity constraints between input elements. First the process checks if both of the CRS identifiers are defined. If not then whether the coordinate operation identifier is specified. The process returns an exception report if the constraints do not match. Next the process initializes the main coordinate operation (transformation or conversion) defined by the identifiers. If the coordinate operation identifier is given and the created operation is an coordinate transformation then the target CRS identifier is gotten directly from the metadata of the transformation, otherwise it should have been delivered as one parameter.

4.3.2 Parsing the coordinates of GML features

If the coordinate operation initialization is successful, then the data is parsed with

a SAX parser, otherwise an exception report is returned. The coordinate operation, together with the CRS identifiers, is given to the parser. Additionally, the parser uses a few stack structures for maintaining the coordinate operations and the relevant GML elements. This creates a reasonably efficient and simple implementation.

At first the coordinate operations stack only contains the main coordinate

operation. If during parsing another CRS identifier is encountered than the source CRS, a new coordinate operation is initialized and added to the stack (see Figure 4). For instance, an identity transformation is added to the stack if a geometry has the target CRS as it's CRS. If the stack contains more than one operation, then also the main coordinate operation's copy (or reference) is added to the stack. As a result, the topmost operation always corresponds to the CRS of the geometry at hand. Duplicate operations in the stack are needed as the operations are popped when the elements defining an CRS end. The initial main coordinate operation is never popped and is left in the stack as parsing of the GML file ends. By this way the process can actually transform input data in multiple coordinate reference systems to a single one, even though this scenario is rare. However, as this option is not taken into account in the INSPIRE context, an other CRS identifier than the source or target identifier raises an exception.

The parser needs to be aware of the already encountered GML elements for several reasons. The first reason is that the parser only cares about the coordinates, which make up the geometries. In GML these are given in different elements depending on the version. For instance, in GML 1 (and GML 2 for backward compatibility) the 'coordinates' element and in GML 3 the 'pos' and 'posList' elements are used. In GML 2 (and GML 3 for backward compatibility) the coordinates are given with a 'coords' element that has the coordinates in it's sub elements. If a sub element is encountered then the existence of the parent element is checked. A second reason to store the elements is to check if an bounding box is encountered (an 'Envelope' or 'Box' element). The bounding box is an exceptional geometry, because the coordinates can not be transformed point-by-point if the coordinate operation includes a coordinate conversion. In this case process has to take care that the transformed bounding box contains at least the same area as the source envelope

and thereby the coordinate values have to be recalculated based on the coordinate conversion. The third reason is to be aware when the coordinate operations need to be popped from their stack.

Figure 4: Parsing of the GML 3 features.

4.3.3 Transforming the coordinates

The actual coordinate transformations are carried out with the slightly modified

open source software GeoTools. The additions made to the software allow to transform coordinates from the coordinate reference systems used nationally in Finland to the INSPIRE-related coordinate reference systems, and visa versa. This arrangement was needed as the accurate transformations are unordinary and the height transformations use national geoid models. These transformations could also have been implemented without using GeoTools. However, the usage of GeoTools allows the service to perform also ordinary transformations between dozens of other coordinate reference systems.

4.3.4 Output data

The output contains the same data content as the input, except that coordinate

values have been transformed and the CRS identifiers in the GML have been

changed to correspond the target CRS. The decimal count of the data may also have changed as all coordinates are returned with 0.1 mm decimal precision regardless of the Unit of Measure (e.g. degrees are returned with 9 decimals). This may be in some situations problematic as the client might expect an transformation's accuracy to correspond to the decimal count. However, as the process is unaware of the transformation accuracy, the decimal count has been made high enough for all INSPIRE-related applications.

Currently in case of the 'TestTransformation' parameter the process works

almost as without the the parameter. The only difference is that the coordinate transformations are not calculated. The operation returns 'false' if the coordinate operations can not be initialized or some other exception occurs during the parsing, else 'true'.

The process can give information about the progress of the coordinate

transformation by first quering the SAX parser of it's current status. The parser returns the count of already transformed data in bytes and the process calculates it's percentage of progress by comparing this number with the original amount of data to process.

5. CONCLUSIONS

The developed prototype illustrates that the implementation of the Coordinate

Transformation Service interface, based on the Implementing Rules and Guidelines of the INSPIRE, is a feasible approach.

Secondly, the presented prototype demonstrates that the implementation of the service is possible using open source software as the basis. The prototype could have been built using many other solutions, like traversing the GML document with a DOM parser. However, the used approach minimizes the need to process the data by taking into account only the main components of the geometries – the coordinate values. Therefore the whole document tree does not need to be in the memory and the procedure becomes simpler to handle.

Currently the main problems are in the identification of the coordinate reference systems. Almost all the INSPIRE-related coordinate reference systems have gotten identifiers. Probably even the EVRS will soon be elaborated as the EVRF2007 and the geodetic ETRS89 (φ, λ, h) is added to the mandatory CRSs. However, the identification of the national coordinate reference systems, which are mainly used as source CRSs, has not yet been addressed. A Pan-European database for the coordinate reference systems is needed. Since such does not yet exists other means like the well-known EPSG codes or even more challenging methods like using URI references to defining documents (encoded for instance according to the GML 3.2.1 CRS-schema) have to be used.

REFERENCES

52N (2009), 52° North Initiative for Geospatial Open Source Software GmbH, at: http://52north.org [accessed 1 April 2009]. Bergenheim, W., Sarjakoski, L. T. and T. Sarjakoski (2009). A Web Processing Service for GRASS GIS to provide on-line generalisation. Proceedings of the 12th AGILE International Conference on Geographic Information Science, June 2-5, 2009, Hannover, CD-ROM, (in print).

EC (2007). DIRECTIVE 2007/2/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 14 March 2007 establishing an Infrastructure for Spatial Information in the European Community (INSPIRE), at: http://eur-lex.europa.eu/JOHtml.do?uri=OJ:L:2007:108:SOM:EN:HTML [accessed 1 April 2009]. GeoTools (2009). GeoTools. The open source Java GIS toolkit, at: http://geotools.codehaus.org [accessed 1 April 2009]. INSPIRE (2008a). INSPIRE Network Services Architecture, version 3.0, draft, p. 29, at: http://inspire.jrc.ec.europa.eu/implementingRulesDocs_ns.cfm [accessed 1 April 2009].

INSPIRE (2008b). Draft Implementation Rules for INSPIRE Transformation Services, Network Services Drafting Team, version 2008-10-31, at: http://inspire.jrc.ec.europa.eu/implementingRulesDocs_ns.cfm [accessed 1 April 2009].

INSPIRE (2009). Draft Technical Guidance for INSPIRE Coordinate Transformation Services, Network Services Drafting Team, version 2009-02-10, at: http://inspire.jrc.ec.europa.eu/implementingRulesDocs_ns.cfm [accessed 1 April 2009].

ISO 19136:2007 (2007). Geographic information - Geography Markup Language (GML).

Schäffer, B. (Ed.) (2008). OWS 5 SOAP/WSDL Common Engineering Report, version 0.1.0, OGC Discussion Paper 08-009r1, at: http://www.opengeospatial.org/standards/dp [accessed 1 April 2009].

Schut, P. (Ed.) (2007). OpenGIS® Web Processing Service, OpenGIS® Standard, Version 1.0.0, OGC 05-007r7, at: http://www.opengeospatial.org/standards/wps [accessed 1 April 2009].

Villa, M., Matteo, G. D., Lucchi, R., Millot, M. and I. Kanellopoulos (Eds.) (2008). INSPIRE NETWORK SERVICES SOAP Framework, Joint Research Centre Scientific and Technical Reports, EUR 23635-2008.

Whiteside, A., Müller, M., Fellah, S. and F. Warmerdam (Eds.) (2007). Web Coordinate Transformation Service (WCTS) Interface Engineering Report. OGC Discussion Paper, Version 0.4.0, OGC 07-055r1, at: http://www.opengeospatial.org/standards/dp [accessed 1 April 2009]. Whiteside, A. and J. D. Evans (Eds.) (2008). Web Coverage Service (WCS) Implementation Standard, Version: 1.1.2, OGC Implementation Standard, OGC 07-067r5, at: http://www.opengeospatial.org/standards/wcs [accessed 1 April 2009].