LSIVIEWER 2.0 - A CLIENT-ORIENTED ONLINE VISUALIZATION TOOL FOR GEOSPATIAL VECTOR DATA

: Geospatial data visualization systems have been predominantly through applications that are installed and run in a desktop environment. Over the last decade, with the advent of web technologies and its adoption by Geospatial community, the server-client model for data handling, data rendering and visualization respectively has been the most prevalent approach in Web-GIS. While the client devices have become functionally more powerful over the recent years, the above model has largely ignored it and is still in a mode of server-dominant computing paradigm. In this paper, an attempt has been made to develop and demonstrate LSIViewer - a simple, easy-to-use and robust online geospatial data visualisation system for the user’s own data that harness the client’s capabilities for data rendering and user-interactive styling, with a reduced load on the server. The developed system can support multiple geospatial vector formats and can be integrated with other web-based systems like WMS, WFS, etc. The technology stack used to build this system is Node.js on the server side and HTML5 Canvas and JavaScript on the client side. Various tests run on a range of vector datasets, upto 35MB, showed that the time taken to render the vector data using LSIViewer is comparable to a desktop GIS application, QGIS, over an identical system.


INTRODUCTION
With the transition in technologies from desktop to web, the successful transition from Office suite to Google docs (Herrick, 2009), other domains joined the shift too.But for past two decades GIS has been largely desktop centric and web GIS was only used for one way transmission (Steiniger and Bocher, 2009), whereas in other domains it moved to much more interactive level.Earlier, most of the World Wide Web standards are text and document based where we can only view documents on the web browser.But eventually, these standards were extended to allow operational interaction with the rise of eCommerce (Puder, 2004).So, this is the right time for GIS applications to make the shift from desktop oriented models of application software to web oriented approaches which can bring single-installationinstance with single user to single instance handling multiple simultaneous users.In GIS, for 2D datasets the most common data models are Vector and Raster (Winter and Frank, 2000).Each of the data models have multiple number of file formats.The Vector models are largely being handled on desktop applications for functionalities like creation, deletion, modification, analysis and finite visualization (Dangermond, 1988), but most of the Desktop GIS applications are tightly coupled to these formats which raise the problem of interoperability.Hence, to solve this problem, a few open source libraries like Geospatial Data Abstraction Library(GDAL/OGR), translator library for geospatial vector data formats (Steiniger and Bocher, 2009) came into light.The other drawback of using Desktop GIS is its un-usability on multiple computing devices like smartphones, tablets, laptops and personal computers where the users use and switch between the devices while the data and the GIS application resides primarily on one of the these devices.A server based approach with multiple clients accessing it remotely is one potential solution but, the * Corresponding author current paradigm of WebGIS gives limited capabilities and functionalities to the user to handle the Geospatial data.
Open GIS consortium(OGC) is an active participant in developing standards that can be adopted by software developers and engineers to develop platform independent interfaces that geoenable the Web.These specifications empower developers to make complex spatial information and services accessible and useful with all kinds of applications (Wenjue et al., 2004).In 1999, OGC has developed web mapping specifications like Web Map Service(WMS) and Web Feature Service(WFS).WMS is a standard for visualizing Geospatial data over the internet in which, a client requests the WMS server for a map, the server queries its database and responds with necessary information in a raster format(PNG, JPG, SVG).WFS is a service that allows a client to request for retrieving Geospatial vector feature (Peng and Zhang, 2004).WMS can primarily return only an image which can not be edited or spatially analyzed and also the map is pre-rendered by the server and the client is just a dumb display terminal/browser.In the case of WFS, it allows for data manipulation operations like create, delete and update the features but this is also similar to the WMS where the rendering of image happens on the server side.Thus both of the standards are server centric (Lu, 2005), which makes the user to knock server for the simplest of the operations demanding continuous server calls requiring high bandwidth for data transfers.While some of the load has been reduced by the Web Map Tile service(WMTS) (Porta et al., 2013), it still limits the user interaction as far as rendering is concerned.
But at the same time, while GIS applications are slow in adapting web technologies, web technologies have suddenly improved which makes the client equally powerful rather than heavy processing being at the server end.Recent evolution of web technologies from server centric models where the client needs to re-quest the server for any functional operations, to client oriented models where the capabilities of client has improved greatly, reducing the data transmissions from client to server over the internet and also being able to handle most of the functionalities by itself, favoring the web applications to become more prevalent (Wood et al., 2014).The extension of HTML(Hypertext Markup Language), HTML5 is the core markup language of the World Wide Web (Anthes, 2012) which diminished the requirement for plugin-in-based technologies such as Microsoft Silverlight, Oracle-Sun JavaFX and Adobe Flash.It has introduced a new element, Canvas which draws graphic contents using JavaScript.This element is useful to GIS in many ways, like easy and fast visualization, seamless interaction with data like scaling, panning the map and applying styling to the objects drawn (Boulos et al., 2010).An alternative to the Desktop GIS application can be implemented with these web technologies that could make it easier for sharing data online and collaborating with other GIS users.For example, in a company there are ten different users to do the basic GIS analysis.If we intend to use Desktop GIS application, we require ten different systems with ten Desktop GIS application installed on each system and requiring a license for each application.Now imagine a client oriented rendering system, which is independent of platform and hardware, and can still work with having one backend server for conversion of file formats whereas the client efficiently handles functions like zooming, panning, styling and labeling.Therefore, a system with these functionalities could make efficient use of resources and also be cost effective.So, there is a need for adapting latest technologies and implementing open source client based rendering GIS application.We develop and demonstrate such a system with the following objectives.
• Building an installation free, platform-independent application which is accessible openly to everyone on the web to visualize the locally-stored1 vector data anytime they want with a reliable internet connection.
• With the development of the latest web technologies, transferring the server-side functionalities to the client side.
• Data rendering speeds on the developed system to be comparable to the traditional Desktop GIS application.
In this paper, we present LSIViewer *2 , a client-oriented framework for rendering spatial vector data in native HTML5.As part of the working prototype developed and presented here, the scope of this application is limited to a basic set of rendering functionalities.The analytical processing capabilities are currently out of scope of this paper.In section 2, we illustrate the architecture of LSIViewer and show a brief implementation of its components.
In section 3, we show the performance comparison of LSIViewer with a typical Desktop GIS application and its performance on multiple web browsers.Finally, in section 4, we conclude and discuss the future applications.

ARCHITECTURE OF LSIVIEWER 2.0
LSIViewer is based on a client-server architecture as shown in Figure 1, where the role of the server is to provide an instance of the client application, act as an adapter and convert the input vector data into a client suitable format by encoding, compressing the encoded data and sending it as a response to the client.The client decompresses the encoded response and renders the map on HTML5 canvas using JavaScript.Traditionally, most of the client server architecture are server-centric where the server does all the computations and the client is only used for displaying the response.But here an effort is made to use the client as much as the server, for rendering the vector data as well as for functionalities like zoom, pan, label and apply color.The detailed architecture is delineated in the below subsections.

Data Upload
The application allows the user to input necessary vector data files through a HTML form and supports five Geospatial vector formats which are ESRI ShapeFile, Geography markup language(GML), Keyhole markup language(KML), GPX and Geo-JSON.ESRI Shapefile is the standard de facto format for vector data (Kelso and Patterson, 2009) and is also the most commonly used vector data format, although it is not accepted as an official standard by OGC.GPX(GPS eXchange) is a standardized XML format for GPS data (Morris et al., 2004) whereas GML, KML and GeoJSON are popular vector formats that are used on the web.While selecting the data for upload, the user has to take care of the necessary file formats for successful visualization.In case of ESRI Shapefile, the user has to upload files with Multipurpose Internet Mail Extensions(MIME) type .shp,.shx,and .dbf.For GML, GPX and KML the user has to upload .gml,.gpxand .kmlfiles respectively.When the filled form is submitted, the data is sent to the server using the multipart/form-data algorithm.

Data Ingestion and Validation
Here, the server side implementation of endpoint handlers required to validate the user-uploaded vector files are emphasized.
When the server receives the data, it extracts the contents from the client's request, processes it and returns the vector data in a client-suitable format as a response.The server-side application is built on Node.js framework.
Node.js(also termed as Node) is a platform built on Google Chrome V8 JavaScript runtime engine that is event-oriented, non-blocking I/O model framework for coding JavaScript on the server (Jun and Doh, 2013).The main purpose for using Node is to make the application fast, scalable, and lightweight (Nair et al., 2016).Node is implemented in C and C++ focussing on low memory consumption, high performance and allows using JavaScript end to end, both on the server and on the client (Chaniotis et al., 2014).This important aspect helps the system to run the application efficiently without the need of parsers.This has modules that help to process the data passed from the client.These modules are in the form of plugins, add-ons, and extensions to facilitate the development process of the application.They are broadly divided into the following categories, which are core modules, third-party modules, and local modules.
For this application, we use Express, a Node.jsweb framework, which provides methods to develop web applications.This application has a POST handler to receive the vector files that are uploaded from the client.Request handling methods in Express application use a callback function whose parameters are request and response objects.This request object contains information passed from the client such as headers, type of encoding and input vector files.Then these vector files are passed to a local module which does the validation of vector data files uploaded from the client.Validation includes determining the type of vector format, file name, and a MIME type, an identifier for file format.The local module returns these parameters after successful execution, from which we know the format of the input files uploaded and its contents.

Data Conversion
Data interchange format has compelling consequences on data transmission rates and client-side rendering performance.Here we explain the tool used for conversion of the client-uploaded vector files and reasons for choosing GeoJSON as a data interchangeable format between the client and the server.Data conversion is done using a simple, efficient, and popular open source tool, GDAL/OGR, a translator library for raster and vector geospatial data formats.
It is an open source, cross platform tool that supports read/write operations for more than 52 vector formats (Bunting et al., 2014).LSIViewer uses a third-party module, ogr2ogr3 , in Node.js.The module converts vector data into GeoJSON format using the GeoJSON OGR driver.
GeoJSON is a JavaScript Object Oriented Notation(JSON) which is simple, human-readable, lightweight format used on the web for transferring geographical information.Each feature in Geo-JSON has two parts: geometric and attribute data.Geometric features include point, line, polygon, multi-Point, multi-Line, and multi-Polygon.The other popular data interchange format is GML, a XML-like format introduced by OGC which provides encoding for points, polylines, polygons and other complex spatial data structures.GeoJSON is better at encoding point data while GML is good at encoding polyline and polygon data (Li et al., 2015).Although GML has advantage over GeoJSON in polygon and polyline encoding, we had to choose GeoJSON deliberately for the reasons described in Data transmission rate depends on the response size.To reduce the size of encoded GeoJSON and make it smaller than its original size without loss of information, a DEFLATE algorithm compression method is used.It achieves faster compression speed with relatively lower compression ratio compared to LZMA (Li et al., 2015).This observation is shown in performance comparison section.After sending the compressed GeoJSON, the client decompresses it, parses it and render on the browser using HTML5 canvas.

Data Visualization
When the client receives a compressed GeoJSON response from the server it should then be visualized on the client.To visualize data on the client, we have two types of viewers, a Simple Data Viewer(SDV) and WMS viewer (WMSV).Figure 2, shows a 5MB shapefile consisting of data of the roads in South Africa, visualized on SDV and WMSV.(Juntunen et al., 2013).Canvas element, which is introduced in HTML5, is crucial for heavy graphics based applications.Its vector rendering performance is more suitable to GIS applications (Park et al., 2011).It provides Application programming interface(API) which has methods to draw line, arc, circle, text, rectangles and render images.Using these canvas API methods we can render the GIS vector data smoothly on the browser.
The functional modules implemented in the JavaScript which are required to render the map on the canvas are listed below.While GetMapExtent and GetFeatureCoordinates define the canvas size and the feature mapping, the DrawMap and Symbology functions help render the data onto the canvas.Detailed description of the functions implemented are listed below.
(D) Symbology Symbology in GIS greatly affects how map can be interpreted.SDV allows the user to perform GIS abilities zoom, pan, color, label and export the map.2. Shows the list of functionalities available on the toolbar and their respective implementation methods

WMS Viewer
In SDV, the user can not validate the vector data by comparing with the actual satellite imagery.So, we integrated WMS which helps us to visualize the GeoJSON data by overlaying it on a base map like Google Map or Openstreetmap(OSM).WMS layer provides a set of geo-referenced raster images which renders on the browser viewing area.WMS layer is loaded using Openlayers, an open source JavaScript library that supports OGC standards.It is implemented using AJAX and JavaScript programming language (Han et al., 2009).After a WMS layer is loaded, canvas adds the GeoJSON data as a layer on top of it.

PERFORMANCE COMPARISON
LSIViewer's performance can be primarily evaluated on the grounds of its rendering speeds in comparison to the Desktop GIS application viz., QGIS.Census 4 and DivaGIS 5 websites.Each dataset varies in size, between 5KB and 35MB covering the geometries including points, lines and polygons.To achieve this performance we used data compression algorithms like DEFLATE and LZMA on the server side.The data sizes are compared for uncompressed data and compressed data with both the algorithms to delineate the degree to which the data transmission rate has been reduced.We also analyze the time taken for data processing and rendering in each of the algorithms and show why we choose one over the other.Finally for the efficient use of LSIViewer, we compare rendering speeds on different web browsers for datasets of varying size.Table 3 contains information related to the datasets used for analyses and Table 4 contains the system configuration of the client and the server instances used for comparison study.

Compression Method for Efficient Transmission of Data
While choosing a compression method, there are various factors involved like the compression ratio(CR) and the compression time(CT).For our study, we chose DEFLATE and LZMA algorithms due to browser support and their popularity.Figure 3 Compares the difference in size of data transferred back to the client side using GeoJSON encoding by using compression techniques(DEFLATE and LZMA).The x-axis shows the file size of datasets in increasing order.Figure 4 indicates that the overall time taken for a response to reach the client when used DEFLATE compression method is faster than LZMA for all the datasets.
For example, in Figure 3 a 35MB dataset is reduced to 6.4 MB and 7.2 MB with LZMA and DEFLATE respectively.And from Figure 4 for the same file, the time taken to reach the client for LZMA compressed data is 18 seconds while DEFLATE takes 6 seconds.This result clearly indicates that, though the size of  LZMA is lesser than DEFLATE, the time taken to compress the data on the server is more in LZMA method, which complements the conclusions derived by (Li et al., 2015).Based on these observations that the data processing time is equally crucial to the data compression ratios achieved, the application implements the DEFLATE method instead of LZMA.One of the challenges to a data-heavy application like GIS to shift to an Online platform is the response time for rendering these datasets.So, in this study, we compare the time taken to render above datasets in both LSIViewer 2.0 and QGIS, a popular open source Desktop GIS application.As can be seen from Figure 5, across all datasets the performance of the desktop GIS is only marginally better than the online toolkit irrespective of the datasize, for example even a 35 MB shapefile, containing 46995 features with 431026 vertices, can be rendered in time that is very close (8∼ 10% slower) to QGIS rendering time, which is less than a second.This implies that the suite of technologies that have implemented as part of LSIViewer 2.0 do show comparable data handling efficiencies.

Rendering on multiple devices
As the number of smartphones and tablets increasing day by day (Khan and Shah, 2016), it is important to test the application on multiple devices.Figure 7 and Figure 8 shows LSIViewer running on a mobile web browser on both smartphone and a tablet.The application can be opened on any web browser on any device, as shown in the previous section.Hence, we can say that LSIViewer is compatible on multiple devices across different platforms.

CONCLUSION AND FUTURE WORK
In current architecture and deployed version of LSIViewer 2.0, it is successfully demonstrated that the server dominant pro-cesses which include rendering and other GIS operations, can be migrated to client side with similar performance characteristics as the desktop based versions of GIS tools.This does show that geospatial data handling and rendering can no longer be a platform-specific, operating-system-specific application and can use/share and work with the geospatial data across multiple devices with different operating systems, as long as they do have a browser and connectivity to access a central or enterprise level server where LSIViewer is deployed.The recent developments in web technology standards, primarily HTML5, have brought to the fore some of the capabilities that a core geospatial toolkit looks for and by integrating these with the geospatial data models has enabled the development of an online geospatial rendering application, LSIViewer.As the client level processing is being done in a JavaScript environment, it was found that GeoJSON, as the data model, is more appropriate than the use of GML, the current standard for WebGIS.Although LSIViewer 2.0 follows a client-server architecture, using the DEFLATE algorithm for compression of the GeoJSON data being transferred between client and server, the processing and transmission time is largely improved to an extent of 75%.
The experiments with multiple data size files containing varied spatial features, has shown that the rendering speeds achieved on LSIViewer 2.0 are very similar to a desktop GIS application, which can be considered as a great precursor to the rise of webbased GIS applications.For instance, in a client-server model, a single server with 100 clients where rendering is happening on client's side is far more scaleable than 100 requests with its associated overheads, all being processed by a single server.All the web browsers that supports HTML5 give this capability to the client making this application a platform-independent and installation-free toolkit.LSIViewer 2.0 requires continuous development of its features and performance improvement techniques on both the server side and the client side.While the current implementation takes care of the basic functionalities, there can be an option for other operations like support for multiple vector formats, adding projection support, overlaying multiple layers of vector data and could be extended to support visualization of CityGML data.Since the application is a web-based one, we can always integrate GIS specifications like WFS, WCS.Also, this design can be a starting point to build an enterprise level collaborative platform for developers and users to share and process/work on their data.

Figure 2 .
Figure 2. Roads of South Africa on a Simple data viewer(SDV) and WMS viewer (WMSV) 2.4.1 Simple Data Viewer(SDV) The client decompresses the GeoJSON response and sends decompressed data to the JavaScript modules.Web 2.0 has introduced HTML5, a new standard to create interactive, high quality web pages on a PC, tablet and a smartphone(Juntunen et al., 2013).Canvas element, which is introduced in HTML5, is crucial for heavy graphics based applications.Its vector rendering performance is more suitable to GIS applications(Park et al., 2011).It provides Application programming interface(API) which has methods to draw line, arc, circle, text, rectangles and render images.Using these canvas API methods we can render the GIS vector data smoothly on the browser.

Figure 5 .
Figure 5. Rendering time comparison between LSIViewer and QGIS 3.2 Is Online Rendering Comparable to Desktop Rendering speeds?

Figure 6 .
Figure 6.Comparison of rendering time over five popular browsers The suite of technologies used in LSIViewer 2.0 are compatible with the current web technology standards that supports HTML5.Hence, the application should be agnostic to the user's browser of choice and follow the current development model of not using any additional plugins or software to be installed on the client side.In this subsection, we report the performance of the application across five popular browsers, in alphabetical order, -Chrome, Firefox, Internet Explorer (IE), Opera and Safari.From Figure 6,

Table 1 .
Advantages of GeoJSON over GML in a JavaScript environment The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume XLII-2/W7, 2017 ISPRS Geospatial Week 2017, 18-22 September 2017, Wuhan, China Y ) are obtained as the new scaled co-ordinates.This can be mathematically represented as below: xScale = canvas.width÷ (xM ax − xM in).
(B) GetFeatureCoordinates() =⇒ return (coordinates : [X , Y ])This method scales the map with respect to the canvas size.This is done by computing new coordinates X and Y .We can scale the size of map by scaling each co-ordinate by multiplying it with a scaling factor.If the original 2D coordinates are (X, Y), for the scaling factor (xScale, yScale), (X , Table 2 contains the list of functionalities and canvas API methods used to implement them.

Table 3 .
The datasets used in this comparison study are ESRI Shapefiles downloaded from the United States ESRI Shapefile datasets used for observations