Custom Search

Rabu, 30 September 2009

A Robust Service oriented Architecture based solution for GIS Interoperability

A Robust Service oriented Architecture based solution for GIS Interoperability

Dinesh Agarwal
Dhirubhai Ambani Institute of Information & communication technology,Gandhinagar, India
Mailing Address : 501, Swapnadeep appts, bhatar char rasta, Surat– 395017 Gujarat. India
Tel: +919916830811
Email: dinesh_agarwal@daiict.ac.in

Abstract
Web-Based Geographic Information Systems (WebGISs) solutions have recently emerged as a productive area of research. A flexible and robust WebGIS can cater to the increasing needs for access and exchange of spatial data. The heterogeneity of the spatial data puts an extra requirement for the Web-Based GIS solution to be interoperable so that it can benefit a large scale of users. This paper tries to propose a Web-Based GIS solution based on Service Oriented Architecture (SOA), which addresses the issue of interoperability. In the context of interoperability we have discussed syntactic, structural and semantic heterogeneity. The standards of Open Geospatial Consortium (OGC) have also been discussed to adduce their usage in achieving interoperability and also in the context of SOA. For the visualization of spatial data in a browser we transformed it into SVG using XSLT stylesheets, implementation of which is also discussed in this paper. All the experiments were conducted in the Laboratories of Bhaskaracharya Institute for Space Applications & GeoInformatics (BISAG) formerly known as Remote sensing and communication Centre (RESECO). We were provided with the needed spatial data by the organization itself.

1. INTRODUCTION:
The Web-Based GIS (Geographic Information System) handling spatial data and geographic information on the Internet has been rapidly evolving with the change of the Internet and web technologies [1]. In many cases the required spatial data is available in different forms and it becomes difficult for different organizations to use it. This needs GIS solutions to be interoperable. The OpenGIS Geography Markup Language (GML) Encoding Specification is an XML encoding for the modeling, transport and storage of geographic information including the spatial and non-spatial properties of geographic features [2]. As GML is a subset of XML it separates the content from presentation. To make the spatial data, encoded in GML, available to the users on World Wide Web we need to transform this data into a display format that can be interpreted by viewer software. We have used Scalable Vector Graphics (SVG) as the display format. To transform GML data into SVG We have used extensible stylesheet language transformation (XSLT) stylesheet together with XSLT processor. The XSLT stylesheet is an XML document which describes the process to transform GML document into SVG document. The same XSLT stylesheet can be applied to different datasets having a homogenous schema. To add further functionalities to SVG such as zooming, panning, coloring, labeling etc. we have used ecmascript.

2. GIS INTEROPERABILITY
Information available in one spatial database may be useful for other GIS applications. But due to heterogeneity of databases it is difficult for such applications to not only use but also locate useful data. The major hindrance in GIS interoperability in such systems is because of obscure semantics, diversity of data sets, and the heterogeneity of existing systems in terms of data modeling concepts, data encoding techniques and storage structures [3]. When two systems differ in the way data is being stored and accessed we call it Syntactic heterogeneity while if the data is stored in different structures we see it as structural heterogeneity. A most common approach to achieve GIS interoperability in such systems is to have a standard format and transform all vendor specific data to standard file format. That is where we see GML suiting the needs for interoperability. This is a standard that will support GIS interoperability because of its standard specifications of data models and data structures. Organizations creating data independently are not expected to use the same terminology to define data properties. This is what we know as semantic heterogeneity. The base schemas defined in GML provide the geometric semantics for encoding the spatial data.

2.1. GML SCHEMAS:
There are three base schemas defined in GML 2.0 to encode spatial information. To create an application schema these schemas are to be used as foundation classes. The Feature schema defines the general feature-property model to describe various elements and types of spatial data. The Geometry schema includes the detailed geometry components and the Xlink schema provides the Xlink attributes to support linking functionality. These schemas do not provide an application schema to constrain data instances but application schema with base types and structures. An application schema has to declare the feature types and property types as they may differ for different domains. An application schema defined using components in base GML schemas has an advantage of standardized constructs and it will conform to OGC feature model. The correctness of a GML document has to be checked through validation. Any GML document should be well formed i.e. it should comply with the XML standards. If the document is well formed the next step is to check it against its schema.

3. XSLT OVERVIEW:
Originally, To add style to XML documents by using Formatting Objects (FO), XSL was used. Early in the definition of XSL, the specification was split in two: XSL Transformations (XSLT), which defines the process which transforms the XML instance into an FO, and XSL which only describes the semantics and rendering of each formatting object and property. The drawback of this scheme was that the XML document could only be transformed into an FO. XSLT was designed to be more general than for use only within XSL. This allowed users to transform XML documents to various formats like HTML or SVG. XSLT is a functional language, expressed in XML syntax. An XSLT transform (or stylesheet) is in essence a list of templates, each defining a mapping between an object from the source document (element, attribute, comment, etc.) to an object in the output document.





...


On top of that, XSLT defines standard programming language constructs like conditional statements and loops. An example of a for-each loop can be seen in the section “Displaying GML” in the paper.

4. SVG OVERVIEW:
SVG format is a new vector graphics standard based on XML grammar for defining vector-based 2D graphics on Web. SVG has more advantages than the most common graphic formats used on Web today. Specifically, it is a high-resolution graphics with plain text format, which are scalable, searchable text, filtering, animation and scripting etc abilities. The biggest advantage of SVG is that an SVG document itself is XML, and apparently conforms to the standards of XML. It offers all the advantages of XML, and it can be easily manipulated through standard APIs such as the Document Object Model (DOM) API and SAX. It can also be easily transformed through XML Style sheet Language Transformation (XSLT) that also utilizes DOM. Moreover SVG images can respond to user actions with highlighting, tool tips, special effects, audio, and animation.

5. OGC SERVICES OVERVIEW:
OGC formulate the specification for spatial data interoperability based on web service/XML together, such as Web Map Service (WMS), Web Feature Service (WFS), Web Coverage Service (WCS) and Geographical markup language (GML) etc. The WMS specification defines three operations: “GetCapabilities” gives the server metadata, which is a description of the service’s content and the necessary parameter; “GetMap” returns actual map; and “GetFeatureInfo” (available) give the information of the special feature on the map.

The WFS specification defines three mandatory operations. “GetCapabilities” queries the WFS service to determine available options. “DescribeFeatureType” retrieves the XML schema to allow the WFS client to parse the resultsets. “GetFeature” performs the actual query - parameters such as bounding box and any other filters should be passed in, as appropriate, and the WFS service then returns a GML resultset containing full geometry and feature attributes. Besides these mandatory services there are few more optional specifications defined by OGC. Though those are not mandatory we used them to add, delete and update features.

6. DISPLAYING GML:
According to the standards of XML technology no XML document can contain presentation details in it. Being a subset of XML same rule applies to GML too and thus a GML document cannot contain styling information. To apply styling either style can be added through external software or GML document can be transformed into SVG. Our focus here is on the latter and for that we use XSLT stylesheet. An XSLT stylesheet is a set of rules expressed in Extensible Stylesheet Language for transforming XML documents. For data visualization the role of XSLT is to convert XML documents in one of many display formats, which in our case is SVG. Once we have achieved the interoperability it is easy to create such XSLT document, which is generalized for all GML documents. These stylesheets are created such that the output produced by them is a valid SVG document and can be sent to the end users to be viewed in their SVG enabled browser window.

The following code shows a part of XSLT stylesheet to read features from GML documents and write the formatted output to SVG documents. To read all of the features of a GML document a “for-each” loop is used, along with which sorting is applied to sort the features by their name. These details are application specific and thus can be changed. Moreover there are XSLT processors available which allow grouping of features based on various attributes of a feature, But as specified earlier these details also are application specific and are not mandatory for every application.






To transform a feature into a vector graphic element we need to transform it suitably. One such scheme is shown in the code below which transforms the co-ordinates of a feature member to the attribute called points of an SVG’s element known as polygon.





Besides these things we added the ecmascript to the SVG document. The ecmascript lies on the server and controls the behavior of the SVG document and processes the actions of a user. The following code handles the click event on an SVG document and it is used to give the effect of changing the color of all polygons of a group to give the effect that they are selected.

if(evt.type == "click"){
origColor = evt.target.getAttributeNS(null,"fill");
var tempid=evt.target.getAttributeNS(null,"id");
evtText1 = document.getElementsByTagName("polygon");
for(i=0; i < node =" evtText1.item(i);" id =" node.getAttributeNS(null," id ="="" xt =" new" alist =" new" sw =" new" svgdoc =" strCurrentPath">

Tidak ada komentar:

Posting Komentar