OXYGENE: AN OPEN FRAMEWORK FOR THE DEPLOYMENT OF GEOGRAPHIC WEB SERVICES Badard, T. and Braun, A. Institut Géographique National. COGIT laboratory, 2-4 avenue Pasteur, 94165 SAINT-MANDE Cedex, France. E-mail:
[email protected] and
[email protected] ABSTRACT At this time, many problems hinder the development of web based applications relying on geographic information: the lack of interoperability between geographic data models implemented in GIS software, the use of proprietary programming languages, the weak capabilities of commercial GIS for the deployment of applications over the Internet, etc. In order to tackle these problems, numerous technologies in software engineering have emerged: standard and extensible object-oriented programming languages with web capabilities, development techniques based on reusable software components and model driven architectures, object-relational database management system enabling the storage and querying of geographic information. Taking benefit from all these more and more mature technologies, a new interoperable platform (named OXYGENE) has been designed and developed at the COGIT laboratory of IGN. It aims at providing an open framework for the development of research applications and allows for the centralisation of codes, their documentation and an easy maintenance/upgrade (preservation of researches). By embedding standard remote procedure call protocols and services description languages, this platform aims at deploying researches undertaken at the COGIT laboratory as true “geographic web services”. The architecture and the model of the OXYGENE platform will first be presented and detailed. The development of geographic web services will then be discussed and illustrated with an example stemming from an application implemented at the COGIT laboratory. 1.
INTRODUCTION
Nowadays, the development of web based applications relying on geographic information comes up against many problems. They are mainly due to: ! The lack of interoperability between geographic data models implemented in commercial software, even if efforts are undertaken by ISO and OpenGIS Consortium (OGC) to unify the different representations. An application developed on a non standard data model may not be used in another platform without deeply modifying it. ! Programming languages embedded in commercial software are often proprietary languages, which implies to learn them and to code anew the same algorithm for various platforms. Code sharing is thus impossible. Moreover, users are highly dependent on a commercial solution and on its technologic evolution. ! Commercial GIS platform are not natively web enabled. When it is possible, users are compelled to buy expensive additional components to connect their GIS to Internet. But only data are online, processes can not be remotely accessed. Thus, it is not possible for a developer to call a remote process hosted on a distant server (notion of “true” web service) in order to code its own application. Such capabilities are important, because developers are not experts in generalisation, geographic data matching, etc. They could thus take benefit from all these available processes and develop optimised applications faster (reusability). ! GIS are not DBMS (Database Management Systems), which implies that problems as concurrent access (clustering and load balancing capabilities) or security management are often not fully addressed by these software. Deploying geographic applications on the web may thus come up against important problems of reliability, consistency and rapidity. The COGIT laboratory of IGN (the French National Mapping Agency) has faced these problems. Indeed, for the last ten years, four platforms have been designed and developed in order to fulfil the requirements of COGIT researchers for their developments: ! PlaGe [1]: entirely developed in ADA and dedicated to the set up of independent generalisation algorithms (especially for road and building features). ! StrateGe [2]: based on SMECI (an expert system from ILOG) and developed in Le-Lisp (a proprietary Lisp) to implement researches in contextual generalisation. StrateGe’s and PlaGe’s concepts and algorithms have been embedded in the AGENT prototype, a module devoted to the automation of the generalisation process based on multi-agent technologies. AGENT is built on top of the LaserScanTM GIS platform [3].
Proceedings of the 21st International Cartographic Conference (ICC) ‘Cartographic Renaissance’ ISBN: 0-958-46093-0
Durban, South Africa, 10 – 16 August 2003 Hosted by The International Cartographic Association (ICA) Produced by: Document Transformation Technologies
994
!
Finally, GeO2 [4]: a platform relying on the Object Oriented Database Management System (OODBMS) O2 (from O2 Technology), and essentially implemented in O2C (a proprietary C/C++). It still hosts a large part of all research developments undertaken at the COGIT laboratory to help in the management of geographic information (geographic data matching, updating, 3D, multiscale databases, ...).
In addition, some developments (works of students during their training period, parts of research theses) have been implemented in commercial platforms (mainly ArcViewTM). Due to such a variety of systems and languages without any capabilities of communication between them, same problems as mentioned before arose. Some algorithms have to be developed in the different platforms and have been implemented several times, as codes were not centralised, not fully documented and not maintained in all platforms. Moreover, as commercial GIS software (with different models and languages) were mainly used in the production units of the IGN or outside this NMA, the release of research applications was made very difficult (often impossible). In addition, due to problems of weak performance (in terms of amount of data and processing rapidity), such a release was made not to be worthy as is. In order to tackle these problems, numerous technologies in software engineering have emerged: standard and extensible object-oriented programming languages with web capabilities (e.g. JavaTM), development techniques based on reusable software components and model driven architectures (e.g. UML – Unified Modelling Language), objectrelational database management system enabling the storage and querying of geographic data (OracleTM, InformixTM, PostGIS, …), etc. Taking benefit from all these more and more mature technologies, a new interoperable platform (named OXYGENE) has been designed and developed at the COGIT laboratory of IGN. It aims at providing users with an open framework for the development of research applications and allows for the centralisation of codes, their documentation and an easy maintenance/upgrade (preservation of researches). By embedding SOAP (Simple Object Access Protocol) [5] and WSDL (Web Service Description Language) [6] technologies, this platform aims at deploying researches undertaken at the COGIT laboratory as true “geographic web services”. The architecture and the model of the OXYGENE platform will first be presented and detailed (section 2). The development of geographic web services will then be discussed and illustrated with an example stemming from an application implemented at the COGIT laboratory (section 3). Finally, conclusions and outlooks for future works will be provided (section 4). 2.
ARCHITECTURE OF OXYGENE
The general structure of the platform is illustrated in Figure 1. OXYGENE is based on 2 main principles: ! Network centred to enable the deployment of developments and the communication between components. ! The use of software components for which they are good. • Clients Web (Browser, applets) • Web Services (WSDL, UDDI)
e.g. Objecteering, Eclipse with Omondo’s plugins, etc.
• etc ...
e.g. Forte for Java, Eclipse e.g. ArcView, Mapinfo, (+ plugin SOAP, WSDL) PCI Geomatics, etc.
CASE Tool (UML, ...)
GIS Clients
IDE
Deployment Server e.g. Tomcat / Axis
e.g. ArcIMS
OXYGENE’s core OGC, ISO, GéO2, ...
Web Map Server (OGC) Object-oriented schema (Java implementation) Mapping
Network (Intranet, Internet)
Web Feature Server (OGC) e.g. ArcSDE
(e.g. Castor, OJB) DBMS (Oracle)
Library of geographic processes (Java, etc.)
Geographic Data Loader
• Documentation (Javadoc) Spatial
• CVS (Concurrent Versioning) • SOAP (W3C)
Figure 1. General structure of the OXYGENE platform
995
e.g. FME, Shp2sdo
It relies on JavaTM and open source technologies and provides users with an extensible object data model (geographic features, geometry, topology and metadata) compliant with OpenGIS and ISO specifications (191xx standards family). Data are stored in a relational DBMS (RDBMS) to ensure a rapid and reliable access to the system but users do not have to worry about any SQL statements: they model their applications in UML and code in Java. For users, all is object ! Mapping between object and relational environments is automatically and flexibly performed with an open source software (see section 2.4). To preserve the independence of developments, geographic processes are coded and stored in a separate library (see section 2.2). Processes come from different sources: web, former developments carried out at the COGIT laboratory: They are in different programming languages (C, C++, Fortran, Ada) and are interfaced with the Java language. The architecture of OXYGENE also includes many tools for the generation of the documentation, for consistently sharing the code (Concurrent Versioning System - CVS), for loading geographic data, for modelling (CASE tools – Computer Aided Software Engineering) and for developing the applications (IDE Integrated Development Environment), and GIS clients to help in viewing and analysing data. 3.
OBJECT-ORIENTED SCHEMA AND ITS IMPLEMENTATION
An object-oriented schema has been designed to enable the modelling of all aspects of geographic information. Its global organisation (UML packages) is illustrated in Figure 2. This model implements ISO standards (working group TC 211) and OGC specifications. Some of these "standards" are finalised, others are still working drafts:
metadata
spatial
src
dictionnary
geoschema
Figure 2. General organisation of the model (UML package diagram) !
!
!
!
ISO 19107 - Spatial schema [7]. It allows for the representation of geometry and topology. It is a set of classes gathered in the spatial package. Two abstract classes called TP_Object and GM_Object are respectively the root classes for modelling the topology and the geometry. Topology and geometry classes present a parallel structure but are independent. Usage of topology without geometry is thus allowed: topology is designed as a layer of higher level of abstraction relying on the geometry. For example, it enables the navigation in the (topologic) graph of a road network without querying the geometry. According to ISO standards, a GM_Object is a primitive (GM_Primitive) or a collection of GM_Object. A collection with no geometrical intersection or overlapping is a GM_Aggregate. A collection of geometrically connected geographic features is a GM_Complex. GM_Complex enables then the sharing of geometrical primitives between different geographic objects or the modelling of structures such as a sequence of connected curves (e.g. a road network). ISO 19109 - Rules for application schema [8]: It allows for the definition of the metamodel of a geographical application. A set of Java classes have been developed to implement this standard. They are gathered in the dictionary package. These classes enable thus the definition of the dictionary (i.e. attributes types, possible values for an attribute, etc.) for data modelled and stored in the system. ISO 19111 - Spatial referencing by coordinates [9]: This standard provides a framework for reference systems and projections. At this time, as data sets used at the IGN are all in the extended Lambert II reference system and we do not need to make coordinates transformations, ISO 19111 has not been implemented in OXYGENE yet. Only an abstract class in the src (which stands for “Spatial Referencing by Coordinates”) package has been developed in order to preserve the conformance to the standard. ISO 19115 - Metadata [10]: Only a part of the complete metadata model defined by ISO have been implemented. These classes are gathered in the metadata package. Most relevant classes corresponding to features commonly found in the data sets at the IGN are coded. A full implementation is possibly planned in order to fulfil specific research requirements dealing with the online access to geographic databases produced by IGN.
996
An additional package (named geoschema) has been designed to gather geographical classes stemming from a data set stored in the system. This package contains a Java class (FT_Feature) from which all geographical classes inherit. FT_Feature holds the topology and the geometry, all subclasses inherits then these properties. A user will thus define an application schema adapted to his geographical data in the geoschema package, using the metamodel of the dictionnary package. Two additional tools have been developed to fully take benefit from the object-oriented point of view on geographic data provided by the schema: a geographic object viewer, based on the Geotools open-source project [11] and a generic graphical object browser to display states in time of objects and to interactively trigger methods.
Graphical object browser
Researchers at the COGIT laboratory have started to implement applications on the OXYGENE platform. These applications deal with the specifications of geographic databases, risk assessments, geographic data matching, automatic propagation of updates, DTM enrichment with vector data [12]. To fulfil their research requirements, users have designed specific data models. As illustrated in Figure 3, each application schema relies on the OXYGENE’s core schema, directly or through the “Topologic maps” schema. It provides in a transparent way users with a modelling of geographic data compliant with the topologic map concept designed in [13]. Detection of inconsistencies between different database representations (objects and schema) Geographic data matching
Risk assessment applications DTM enrichment with vector data
Topologic maps
Geographic objects viewer
Automatic propagation of updates in databases
OXYGENE’s core schema (ISO/OGC)
Figure 3. Developing applications with OXYGENE 2.2 Library of geographic processes Some geographic operators are based on the structure of the OXYGENE's core schema. They have been coded and shared in an separate library in order to preserve the independence of the developments. It includes different algorithms dealing with geometry, topology or geographic features. For instance, basic algorithms on geometrical features (union, intersection, buffer, …) or more complex algorithms like Delaunay’s triangulation, Voronoï’s diagram or measures as Hausdorff’s distance are available in the shared library of processes. They have mainly been implemented in the JavaTM programming language. Although former developments carried out in the different platforms set up at the COGIT laboratory (PlaGe, Stratege, GeO2) have been written in another programming language than Java, their integration in OXYGENE remains possible without coding them anew. The JavaTM Native Interface [14] provided by Sun Microsystems enables such an integration. It is performed just by writing an interface file (in the JavaTM programming language) which converts data types used in a C/C++, ADA or Fortran compiled library into JavaTM data types. The JavaTM Native Interface avoids thus developing anew codes which have already required a hard work for their optimisation (former developments, free libraries for computational geometry available on the Internet). In addition, it allows to take benefit from faster processes in OXYGENE because Java generally remains slower than other compiled programming languages. 2.3 Database Management System (DBMS) Commercial GIS often rely on proprietary solutions for the storage and handling of geographical data but these solutions do not provide users with full capabilities of a DBMS. Problems such as concurrent access, storage of large data set or security management are not fully addressed. As, from the design step of OXYGENE, it has been decided to use a tool for what it has been designed, a solution based on a DBMS has been adopted. This DBMS should be relational because the object-oriented DBMS have demonstrated weak performances. Oracle has been chosen for OXYGENE. Oracle has provided users with a spatial cartridge which enables the storage and querying of geographical information, through an “object” viewpoint since the release of the 8i version [15]. However, the modular architecture and schema of OXYGENE would allow to interface/connect any other DBMS enabling the storage of geographical information (e.g. PostGIS, the open source extension of the relational DBMS PostgreSQL [16]).
997
2.4 Object-relationnal mapping Although the Oracle DBMS provides users with some object-oriented capabilities, its core remains relational. The model of the OXYGENE's platform has been implemented with Java and defines a full object-oriented viewpoint on data stored in the system. So, a link between the two "worlds" has to be established: it is the “mapping” process (a table stored in the relational database corresponds to a Java class in the model). In the platform, the mapping between object and relational environments is performed with an open source software. Two open source JavaTM API (Application Programming Interface) have been tested: CASTOR [17] and OJB [18]. At his time, OJB is faster than CASTOR and provides users with more advanced object/relational mapping capabilities. They are related to the JDO standard specified by SunTM Microsystems [19] and allow for a convenient object-oriented access to persistent data. All mapping information are stored in human readable XML files, which allow for an easy customisation of the mapping. A developer thus handles directly Java classes without worrying about relational tables and SQL statements. The modular structure of OXYGENE enables the support of other mapping tools just by implementing a new class from the generic interfaces provided with the platform and dedicated to the database connections. 2.5 Development tools Like any other classical development projects, codes in OXYGENE are documented. From special comments inserted in codes, a tool (JavadocTM, provided with the Java SDK) automatically generates HTML documentation pages of the developments. Consistency between developments and documentation is thus preserved. Resulting documentation can be accessed on an internal web server by the developers. Other electronic documents (courses, slides, articles, books, etc.) are also available on this server in order to facilitate the learning of the different techniques embedded in OXYGENE. The preservation of the consistency between the different versions of codes implemented by researchers is performed by a CVS (Concurrent Versioning System) [20]. It allows for the centralisation of codes and their sharing on a server. Users can download the updates and commit their own modifications. Possible conflicts are mentioned by CVS and it tries to automatically solve them. If it is not possible (e.g. a same portion of code has been updated by different users), users have to modify their codes in order to resolve the conflict. In order to easily browse the different versions of codes, an access to the CVS is provided to users on the documentation web server. First step in the development of an application usually deals with its modelling. This can be facilitated by Computer Aided Software Engineering (CASE) tools, which help in designing conceptual diagrams, documenting them and transforming them into logical schemas adapted to a DBMS or a target programming language. Various commercial or open source solutions are available. Due to all interesting and useful concepts (different viewpoints on an application, object oriented paradigms, etc.) it provides, UML has been adopted as the common formalism for the design of the different application schemas set up by the researchers at the COGIT laboratory of IGN. More specific formalisms like Perceptory [21] or MADS [22], which allow for the direct modelling of geographic and temporal information, could also be used in OXYGENE. In order to make the development of applications easier, an IDE (Integrated Development Environment) can be used. As it provides very powerful tools for the development in the JavaTM programming language, Eclipse [23] is mainly deployed at the COGIT laboratory. It is an open source project initially based on an contribution from IBM. As sources are available, many plugins are developed by the open source community and are available (often free) on the Internet. They enhances Eclipse with more and more powerful features: development and deployment of web services, UML modelling [24], database connectivity, etc. 2.6 Geographic data loader and viewer Data are generally available in a (commercial) GIS data format (ESRITM Shapefile, MapInfoTM MIF/MID, GeoConceptTM, etc). These data have to be loaded in the DBMS in order to be accessed and processed by the OXYGENE developers. FME (Feature Manipulation Engine from Safe Software) is used for that purpose [25]. Exporting data from Oracle to another format is also possible. Data sets processed by OXYGENE can then be available in various GIS platforms. Data are visualised in GIS clients (MapInfo, GeoConcept, Esri), via data exports performed with FME or via a direct connection to Oracle as numerous software enable such a connection. Users can then benefit from all the powerful capabilities provided by these software for viewing and analysing data. A simple viewer can also be used (FME viewer or Geomatica free view from PCI Geomatics as an example). In addition, a geographic object viewer has been developed at the COGIT laboratory (see section 2.1). It allows to fully take benefit from the object-oriented point of view on geographic data provided by OXYGENE. Persistent data stored in the platform and non persistent objects (i.e. created at runtime in a Java program) can thus be accessed and visualised. Properties of objects can also be graphically displayed as the object browser (see section 2.1) is embedded in the viewer. This viewer is mainly based on the open source API developed by the Geotools project [11].
998
2.7 Geographic Web Services As mentioned in introduction, by embedding SOAP (Simple Object Access Protocol) [5] and WSDL (Web Service Description Language) [6] technologies, OXYGENE aims at deploying researches undertaken at the COGIT laboratory as true “geographic web services”. At this time, web services dealing with geographic information are not fully standardised even if efforts are undertaken by ISO and OpenGIS Consortium (OGC) to enact specifications for their semantic interoperability. 2.7.1 The OGC point of view The OpenGIS Service Architecture has been adopted as an ISO draft standard, ISO 19119 [26]. Computational viewpoint, information viewpoint and engineering viewpoint have been considered in this standard for respectively dealing with service chaining, service taxonomy and technology mapping. The proposed geospatial service taxonomy relies on the Extended Open Systems Environment (OSE) model. Five main kinds of services have been identified: • Human interaction services: viewer and editors. • Model / Information management services: management and access to persistent storage. • Workflow / Task services: chain definition and enactment. • Processing services: feature modification services. • Communication services: encoding and infrastructure. This can be a basis for semantic interoperability and have to be related with technology mapping allowing the use of a common semantic across different environments. 2.7.2 Web Feature Server and Web Map Service Web Map Service and Web Feature Server respectively belong to the first and the second categories of the previous taxonomy (human interaction and model/information management services). A "Web Feature Server" (WFS), as specified by OGC [27], connects geographical data warehouses in order the users to access them via the Internet. It is thus possible to handle data through the Web: creation, destruction and update of data are basic queries provided by such a service. A "Web Map Service" (WMS), also defined by OGC [28], enables the display of maps based on geographical data in Web browsers. A map is here defined as a visual representation of data and not as data themselves. Maps produced by such a service can be in an image file format (GIF, JPEG) or in a vector file format (SVG). At this time, neither a WFS nor a WMS have been installed in OXYGENE. Nevertheless, the modular architecture of OXYGENE allows for it and installation of such services is planned in order to develop web services dedicated to mapping applications. Some WMS or WFS implementations are already available in open source on the Internet. 2.7.3 Toward processing web services A Web Service is a set of related application methods that can be remotely accessed across a network (such as a corporate intranet or Internet itself). The information that an application must have in order to programmatically invoke a Web Service is given by a Web Service Description Language (WSDL) document. WDSL documents will be indexed in searchable Universal Description, Discovery, and Integration (UDDI) Business Registries so that developers and applications can locate Web Services. Web Services are powered by Web applications servers that speak Simple Object Access Protocol (SOAP), and deliver information marked up in eXtensible Markup Language (XML) [29]. All Web Services available on the internet as a whole is called the Service Web. The Service Web will be the backbone of the next generation of distributed applications. Today, the Service Web is in its infancy, but is very promising. OXYGENE aims at deploying researches undertaken at the COGIT laboratory as “processing web services” (according to the OGC/ISO taxonomy). Such a kind of services already exists on the Internet: coordinate conversion service, coordinate transformation service, orthorectification service, etc. For experiment purposes, the use of SOAP/WSDL technologies has recently been investigated and tested since they become mature and standard for the deployment of non geographic web services. Nevertheless, attention is paid to the OGC/ISO recommendations for service discovery and service description in order to develop an interoperable framework of web services in OXYGENE. The next section will focus on an example of deployment and use of such a Web Service. 3. EXAMPLE OF DEPLOYMENT AND USE OF A GEOGRAPHIC WEB SERVICE IN OXYGENE The example detailed in this section illustrates the deployment of a geographic web service and its use by a client. Although both client and server are implemented on the OXYGENE platform for practical purposes, feasibility of such a deployment is proven. Tests for a deployment of geographic web services in distributed and heterogeneous environments (e.g. OXYGENE as a server on a Unix platform and a commercial GIS as a client on a Microsoft WindowsTM operating system) are planned and should not result in an impossibility.
999
As mentioned in section 2.7.3, the example detailed in this section relies on a « traditional » implementation in terms of web services: The SOAP protocol for the exchange of messages between the client and the server has been implemented. A Tomcat/Apache SOAP application server has been used to deploy the web service. WSDL standard for description of web services is currently not supported by Apache SOAP. A migration to Apache Axis [30], the new reference implementation of the W3C SOAP protocol provided by the Apache Software Foundation will allow for it and is planned in a near future. 3.1 Presentation of the deployed web service The service deployed in this example is named “FiltrageService”. It deals with a basic Douglas-Peucker filtering method implemented in the OXYGENE platform. As this method is applied to a vector of points (named “DirectPosition” in the ISO model of OXYGENE) sent by the client to the server, the DBMS is not accessed by the server in this example. Figure 4 illustrates the N tiered architecture on which the deployment of this web service relies. CLIENT SIDE
!
Data Base
intranet
Internet (HTTP)
Client
JDO
SOAP
SERVER SIDE Deployment server
Service Method
local
Java
OXYGENE library
Figure 4. N-tiered architecture of the OXYGENE deployment server The client (a Java program) first retrieves a geographic object in the database by invoking JDO access methods to the DBMS. The remote Douglas-Peucker filtering method, which is hosted by the “FiltrageService” interface deployed on the server, is then applied to the object. The client sends all parameters to the server by the way of SOAP messages. The server process the request by triggering the corresponding methods in the OXYGENE library of processes and return the results to the client by the way of SOAP messages too. The client can then achieve the initiated transaction and commits it. As mentioned before, both the server and the client are implemented in the OXYGENE platform. Figure 5 provides readers with a clear identification of the components used by the server and by the client. • Clients Web (Browser, applets) • Web Services (WSDL, UDDI) • etc ...
CLIENT SIDE Deployment Server
SERVER SIDE Object-oriented schema (Java implementation)
DBMS (Oracle)
Library of geographic processes (Java, etc.)
Spatial
Figure 5. This example in the global architecture Following sections detail the implementation of this example web service on the client and on the server sides. SOAP messages exchanged between the client and the server are also presented. 3.2 Server side On the server side, an interface (named “FiltrageService”) is first implemented. It consists in a set of operations focusing on filtering methods. One of these methods deals with the Douglas-Peucker filtering process for a vector of points. It is just an alias to the Douglas-Peucker method hosted in the shared library of processes available in the OXYGENE platform. The deployment by itself consists then in writing a XML Web Service Deployment Descriptor file (WSDD) required by the deployment server in order to be able to reply to requests issued by clients. To achieve this task, the Apache SOAP 2.2 deployment server takes benefit from the Tomcat servlet engine and implements its own
1000
servlets to get requests from clients, invoke the requested methods (defined in the WSDD file) and send responses to the clients. 3.3 Client side Geographical features on which the test of web service deployment is performed, are road sections stemming from a database produced by the IGN. On the client side, data have first been loaded into the Oracle DBMS. They are thus stored as a relational table. A tool provided with OXYGENE automatically generates a Java Bean class and a XML mapping file, which the object-relational mapping-tool can interpret (see Figure 6). The generated Java class inherits from the FT_Feature class which holds the geometry and topology. They can thus be accessed from the generated class.
Figure 6. Relational table, Java class and mapping file The following code sample (see Figure 7) illustrates how the remote procedure call to the Douglas-Peucker deployed on the server is achieved. // Initialise a new database connection Geodatabase db = new GeodatabaseOjbOracle(); // Initialise a Java stub with an URL SoapClientHelper.initService(FiltrageService.class, "http://localhost:8080/soap/servlet/rpcrouter"); FiltrageService filtre SoapClientHelper.makeServiceInstance(FiltrageService.class);
DeploymentDesciptor.xml, =
(FiltrageService)
// Start a transaction and load a feature by its class and identifier db.begin(); FT_Feature feature = (FT_Feature)db.load(roadSectionClass,gid); // Get its geometry and apply the remote Douglas-Peucker on it GM_LineString linestring1 = (GM_LineString)feature.getGeom(); GM_LineString linestring2 = (filtre.DouglasPeuckerList(linestring1.coord(), threshold));
new
// Create a new feature and set the new geometry FT_Feature result = new Result_Curve(); Result.setGeom(linestring2); // This feature is made persistent in the database and transaction is committed db.makePersistent(result); db.commit();
Figure 7. Example of code embedding a remote procedure call with SOAP
1001
GM_LineString
An instance of Geodatabase is first created: it opens a connection to the geographic database hosted in a Oracle DBMS via the OJB object-relational mapping tool. A Java stub (also named proxy) is then initialised. It allows for the dynamic remote procedure call of methods hosted by the “FiltrageService” interface deployed on the server. Its instantiation is performed by providing the Web Service Deployment Descriptor (WSDD) file location for the requested service and the URL of the SOAP listener servlet on the server to a SOAP client helper. A transaction is opened and a persistent object is loaded by providing the class name and the identifier of the accessed object. The geometry of the geographic object (a road section) is then retrieved and the remote Douglas-Peucker method is applied on it. A new geographic feature is created and the geometry resulting from the remote process is assigned to this object. It is finally stored in the database and the transaction is committed. 3.4 Exchanges of SOAP messages As mentioned in section 3.1, information exchanged between the server and the client are based on the Simple Object Access Protocol (SOAP). It uses the world wide web Hypertext Transfer Protocol (HTTP) and its Extensible Markup Language (XML) as the mechanisms for information exchange. SOAP specifies exactly how to encode an HTTP header and an XML file so that a program in one computer with an operating system can call a method of a service in another computer with possibly another operating system, and pass it information. SOAP also specifies how the called program can return a response. SOAP messages are automatically generated and read by both proxy client and deployment server, so that programmer do not have to worry about it. A tool provided in the Apache SOAP 2.2 web services server allow for the tracing of SOAP messages. Figure 8 illustrates a sample of SOAP messages exchanged between the client and the server when the remote Douglas-Peucker filtering method is invoked on the server. Coordinates of the geometric feature representing the processed road section clearly appear in it. 0 1000512.57 3 280.3 1000512.57 1870538.61 280.3 1870538.61 0 1000511.78 3 281.5 1000511.78 1870522.71 281.5 1870522.71 0 5
Figure 8. Sample of SOAP messages exchanged between the client and the server when the remote Douglas-Peucker method is invoked 4.
CONCLUSIONS
OXYGENE, the new interoperable platform designed and developed at the COGIT laboratory of IGN has been presented and detailed. It provides users with an open framework for the development of applications based on
1002
geographic data and allows for the centralisation of codes, their documentation and an easy maintenance/upgrade (preservation of developments). Researchers at the COGIT laboratory have begun to develop their applications above the OXYGENE platform. They deal with the specifications of geographic databases, risk assessments, geographic data matching, automatic propagation of updates, DTM enrichment with vector data, etc. By embedding technologies as standard protocols for remote procedure call and languages for the description of services, this platform enables the deployment of researches undertaken at the COGIT laboratory as true “geographic web services”. The feasibility of such a deployment based on the OXYGENE platform has been proven. Nevertheless, a lot of work remains in order to implement a web services framework fully compliant with ISO/OGC standards. Future works will thus mainly deal with such an implementation. 5. [1] [2] [3]
[4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30]
REFERENCES F. Lecordix, C. Plazanet, J.-P. Lagrange, A Platform for Research in Generalisation: Application to Caricature,. GeoInformatica 1:2, Kluwer Academic Publishers, Boston, pp.161-182 (1997) A. Ruas, OO-Constraint Modelling to Automate Urban Generalisation Process, Proceedings of the 8th International Symposium on Spatial Data Handling (SDH’98) pp.225-235 (1998) M. Barrault, N. Regnauld, C. Duchêne, K. Haire, C. Baeijs, Y. Demazeau, P. Hardy, W. Mackaness, A. Ruas, R. Weibel, Integrating Multi-agent, Object-oriented, and Algorithmic techniques for Improved Automated Map Generalization, Proceedings of the 20th International Cartographic Conference, vol. 3, Beijing, China, pp. 21102116 (2001) L. Raynal, B. David, G. Shorter, Building an OOGIS prototype: experiments with GeO2, AutoCarto, pp.137-146 (1995) World Wide Web Consortium, Simple Object Access Protocol (SOAP) 1.1, W3C Note, http://www.w3c.org/TR/SOAP (2000) World Wide Web Consortium, Web Service Description Language (WSDL) 1.1, W3C Note, http://www.w3c.org/TR/WSDL (2001) OpenGISTM Consortium, The OpenGISTM Abstract Specification – Topic 1: Feature Geometry (ISO 19107 Spatial Schema), version 5, OGC document number 01-101 (2001) ISO, Geographic Information, Rules for Application Schema, ISO Draft International Standard 19109 (2001) ISO, Geographic Information, Spatial Referencing by Coordinates, ISO Draft International Standard 19111 (2001) ISO, Geographic Information, Medatada, ISO Draft International Standard 19115 (2001) Geotools Project, Geotools, Open Source mapping toolkit, http://www.geotools.org (2003) F. Rousseaux, Enrichment of a TIN with 3D vectors data, GIS Research in UK (GISRUK), City University, London (2003) B. David, Modélisation, représentation et gestion d’information géographique – Une approche en relationnel étendu, PhD. Thesis, Université Paris 6 (1991) SunTM Microsystems, Java Native Interface (JNI), http://java.sun.com/products/jdk/1.2/docs/guide/jni (2003) OracleTM, Oracle Technology Network, http://otn.oracle.com (2003) PostGISTM, Geographic Objects for PostgreSQL, http://postgis.refractions.net (2003) Castor Project, Castor Project Home Page, http://castor.exolab.org (2003) The Apache DB Project, OJB – ObJectRelationalBridge, http://db.apache.org/ojb/ (2003) SunTM Microsystems, Java Data Objects (JDO), http://java.sun.com/products/jdo (2003) CVS, Concurrent Version System, the Open Standard for Version Control, http://www.cvshome.org (2003) Bédard, Y., Visual Modelling of Spatial Databases: Towards Spatial PVL and UML, Geomatica, Vol. 53, No. 2., pp. 169–186 (1999) Parent, C., Spaccapietra, S., Zimanyi E., Spatio-Temporal Conceptual Models: Data Structures + Space + Time, Proceedings of the 7th ACM Symposium on Advances in GIS, Kansas City, Kansas (1999) Eclipse Project, Eclipse Main Page, http://www.eclipse.org (2003) Omondo, Eclipse-Omondo, the Live UML Company, http://www.omondo.com (2003) SafeTM Software, Data Translation Solutions, http://www.safe.com (2003) OpenGISTM Consortium, The OpenGISTM Abstract Specification – Topic 12: Service Architecture (ISO 19119 Geographic Information Services), version 4.3, OGC document number 02-112 (2002) OpenGISTM Consortium, Web Feature Server Specification, OGC document number 01-023 (2001) OpenGISTM Consortium, Web Map Service Implementation Specification, OGC document number 01-068r3 (2001) A. Ryman, Understanding Web Services, http://www7.software.ibm.com/vad.nsf/Data/Document4362/ (2003) Apache Axis, Home Page, http://ws.apache.org/axis/ (2003)
1003
OXYGENE: AN OPEN FRAMEWORK FOR THE DEPLOYMENT OF GEOGRAPHIC WEB SERVICES Badard, T. and Braun, A. Institut Géographique National. COGIT laboratory, 2-4 avenue Pasteur, 94165 SAINT-MANDE Cedex, France. E-mail:
[email protected] and
[email protected] Biography Thierry Badard is a researcher and Ph.D. in Geographic Information Science at the COGIT laboratory of IGN (the French National Mapping Agency). He has been responsible for the research activity on the automatic propagation of updates in geographic databases since 1996.He is also leader of the OXYGENE development project. He has research interests in GIS software development, updating of multi-scale databases and geographic data matching tools. Arnaud Braun is a research engineer at the COGIT laboratory of IGN. He is mainly involved in the development of the OXYGENE platform. He has research interests in GIS software development, updating and data matching tools for geographic databases.
1004
