A Robust Service oriented Architecture based solution for GIS Interoperability

A Robust Service oriented Architecture based solution for GIS Interoperability

SHARE

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: [email protected]

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

<xsl:stylesheet xmlns:xsl=”https://www.w3.org/1999/XSL/Transform version=”1.0″>
<xsl:template match=”foo”>
<bar><xsl:apply-templates/></bar>
</xsl:template>

</xsl:stylesheet>

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.

<xsl:for-each select=”gml:featureMember”>
<xsl:sort select=”NAME”/>
<xsl:sort select=”PERIMETER” data-type=”number” order=”descending”/>
</xsl:for-each>

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.

<xsl:element name=”polygon”>
<xsl:attribute name=”points”>
<xsl:value-of select = “geometryProperty/Polygon/outerBoundaryIs/LinearRing/coordinates”/>
</xsl:attribute>
</xsl:element> 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 < evtText1.length; i++){
node = evtText1.item(i);
id = node.getAttributeNS(null,”id”);
if(id == tempid) node.getStyle().setProperty(“fill”,”yellow”);
}}

After creating this XSLT stylesheet the process of transformation can be completed using any of available XSLT processors. For creating the transformed SVG document on the fly we have used C#. Before transforming we read the parameters passed with the request by the user and accordingly we call a processor and pass those parameters to the XSLT stylesheet. For example, if a user asks for the feature members with the area greater than or less than any particular given number, the parameter named area is passed that value, with the operator (greater than or less than), and the webservice that transforms the GML data into SVG passes that parameter to XSLT during transformation, and the resulting SVG document contains only requested feature members. This document is then sent to the user.

Following C# code depicts how to transform a given XML document to an SVG document. The XSLT stylesheet is first loaded and then the XML document is given to the processor along with the arguments. The processor then transforms the given XML document according to the XSLT stylesheet and writes this data to the stringwriter’s instance. This is then written to an SVG document and the link to that document is sent back to the caller of this service.

public string TransformPage(String strCurrentPath,String xmlDoc,String xslDoc,String svgDoc,String paraName, String paraValue)
{
XslCompiledTransform xt = new XslCompiledTransform();
XsltArgumentList Alist = new XsltArgumentList();
StringWriter sw = new StringWriter();
Alist.AddParam(paraName, “”, paraValue);
xt.Load(xslDoc);
xt.Transform(xmlDoc, Alist, sw);
File.WriteAllText(svgDoc,sw.ToString());
sw.Close();
svgDoc = strCurrentPath + “/result.svg”;
return svgDoc;
}

Depending on the size of GML file, spatial SVG document may be too large to be well organized for an efficient browsing and managing. Which requires a solution of organizing and storing SVG based spatial data in creating spatial databases. The main aspect of such a solution would be the classification of the geographic entities and the organization of their information. It has become standard practice to classify geographic entities according to their dimensionality, as points, lines, or area [6]. This typology is especially prevalent in cartography. These features will be enough to express the geographic entities in real world. There are elements defined in SVG to express such features, such as ellipse or circle element used to express point, path element to express a line and a group of paths to express a polygon or area. To organize the geographic entities’ information we separated the data into layers, levels and elements. The basic principle of layering approach was to divide the spatial data according to its type, such as layer for roads, layer for rivers or layer for railway tracks etc. The layers are independent and when more than one layer is required they can be easily overlapped. The basic principle behind element approach is to group similar elements together, which helped in processing those elements together referring to their group than processing each element separately. The leveling approach is to store the detailed information up to any number of levels instead of storing it in a single document. In order to organize the spatial data in SVG format, the features of SVG expression or data structure for graphics should be studied and then classified into different layers based on the basic elements such as point layer, line layer, polygon layer. A layer is expressed with ‘g’ as a grouped elements, and element ID is the identifier of the layer or group of elements in SVG document. Different layer has its own displaying stylesheet. In case of generalized stylesheet there need to be only one stylesheet for all layers. The result of abovementioned transformation process is a SVG document similar to the one displayed below.

<?xml version=”1.0″ encoding=”UTF-8″?>
<svg xmlns=https://www.w3.org/2000/svg xlink=”https://www.w3.org/1999/xlink” version=”1.1″ id=”cont” onload=”loadG(evt)”>
<script type=”text/ecmascript” xlink:href=”jscript.js” />
<g fill=”black” stroke=”red” id=”XYZ” transform=”translate(0,700) scale(0.001,-0.001)”>
<polygon transform =”translate(0,700) scale(0.001,-0.001)” peri=”960810.438″ points=”477371.96875,493473.8125 477278.71875,493495” onclick = “showClickEvt(evt)” onmouseout = “showMOutEvt(evt)”>XYZ</polygon>
….
</g>
</svg>
</xml>

When the size of GML file is too large and the data is stored in one SVG document and sent to browser at one time it has bad effect on the issuance speed. The technique of having layers caters to this problem. Now in this system when the browser sends out URL, the first sent SVG data is only the most basic layer for instance the map of entire country. Later, when the browser asks for other layers by check box like rivers or state boundaries, the GML file will be queried again and the results are written into a document in SVG format in order to display in the browser correctly. There may be any number of layers. Also to reduce the amount of spatial data more detailed maps are separated from each other. For Instance a user may be provided with the map of the globe at first, to see a particular country the user can select it and click on the next level which will query the relevant GML document and sends the SVG document to the client containing detailed information only about the selected country. Similarly a user may go to the deeper levels like a state or a village one after the other. Also the ecmascript added functionalities like panning, zooming, labeling, Selection highlighting etc. The following image shows a screen view of client after the Get Map request was made and the resulting SVG document was displayed to the user. The end user is provided with a user friendly interface which gives him the option to select parameters by means of graphical user interface.

7. CONCLUSION AND FUTURE WORK:
We tried to provide a complete Web based GIS solution by incorporating services like WMS and WFS with conversion of GML data to SVG and use of client side scripts to add interactivity to these SVG documents. The working model of this webGIS which we call BISAG Map Viewer proved the feasibility of such a solution. The use of SOA enables the solution to be used partially by other clients, for instance to deliver SVG documents based on the server side GML data. Such complete web-GIS solutions have wide development prospects. In the future, we will address a number of issues related to this research. First, in terms of data storage and querying, the GML based web-GIS reported in this paper is still impractical for dealing with gigabyte-sized geospatial datasets. The layering and leveling approach tried to alleviate the problem but still for very large sized spatial data documents the system may not return results within expected time limits.

8. ACKNOWLEDGMENTS:
I would like to thank the guides and reviewers for their comments and suggestion which greatly improves the organization and presentation of this paper. This paper outgrows from the joint work of Map Viewer Team at BISAG. I am indebted to all of the team members for ideas on the exchange of information. I extend my sincere gratitude to Prof. Abhinay Pandya of Dhirubhai Ambani Institute of Information and Communication Technology(DA-IICT) for his guidance and comments throughout the paper. I am grateful to BISAG for allowing us to use their labs and also for providing us with the spatial data. I would like to thank Distinguished Prof. A.R. DasGupta of BISAG for his guidance and untiring support while we worked in BISAG.

REFERENCES

  • Luis Manuel Callejas, “Web-Based GIS: A brief History”
  • OGIS, “The OpenGIS® Guide – Introduction to Interoperable Geoprocessing and the OpenGIS Specification,”, L. McKee and K. Buehler, Eds., MA: Open GIS Consortium, Inc, 1996.
  • OpenGIS® Geography Markup Language (GML) Encoding Specification Available at https://www.opengeospatial.org/standards/gml
  • T. Devogele, C. Parent and S. Spaccapietra: On Spatial Database Integration. International Journal of Geographic Information Science 4 (1998), 335–352
  • Scalable Vector Graphics (SVG) 1.1 Specification, J. Ferraiolo, Fujisawa Jun and Dean Jackson, editors, W3C Recommendation, 14 January 2003. Available at https://www.w3.org/TR/SVG11/
  • Spatial Representation: A Cognitive View, Spatial Representation: A Cognitive View. In Maguire, D. J., Goodchild, M. F., Rhind, D. W., and Longley, P. (editors) Geographical Information Systems: Principles and Applications, Second edition, v. 1, pp. 81-89.