Master Thesis Web Tech Comparison

Master Thesis
submitted within the UNIGIS MSc. programme
at the Department of Geoinformatics - Z_GIS
University of Salzburg, Austria
under the provisions of UNIGIS joint study programme with
University of Madras, Chennai, India
Comparative Analysis of Web
Technologies for Publishing Temporal
GPS Locations in Real-Time
A Case Study of Vehicle Movement in Jayanagar
Locality, Bangalore, India
by
Gopi Padmanabhan
GIS_103112
A thesis submitted in partial fulfilment of the requirements of
the degree of
Master of Science (Geographical Information Science & Systems) – MSc (GISc)
Advisors:
Dr. Shahnawaz and Dr. Jaganathan
Bangalore, India, 4th
November 2014

2
Science Pledge
By my signature below, I certify that my thesis report is entirely the result of my own
work. I have cited all sources of information and data I have used in my thesis report and
indicated their origin.
Bangalore, 4th November, 2014
Place and Date Signature

3
Acknowledgements:
This thesis study was completed successfully largely due to the effort of a number of
people who have given their valuable advice. I sincerely appreciate the inspiration, support
and guidance of all those people who have been instrumental in making this study a
success.
I feel deeply honored in expressing my sincere thanks to all the instructors of all the
modules for providing me valuable insights leading to the successful completion of my
thesis.
Last but not the least I place a deep sense of gratitude to my family members and my
friends who have been constant source of inspiration during the preparation of this thesis
report.

4
Abstract
Vehicle tracking system with the components such as automatic vehicle location and
software publishes fleet location information on internet. These applications mostly use
traditional Asynchronous JavaScript and XML (AJAX) based polling mechanism, to fetch
vehicle locations at specified interval. This is a pull based data transfer initiated from the
web application that is unaware of vehicle location updates availability.
The AJAX like any other traditional HTTP request and response consists of header
that are proportionally huge in data size in comparison to a single vehicle location
information. To overcome this heavy data transfer problem, the application contains a
trade-off to fetch a collection of vehicle locations at a larger time interval. This helps in
distributing the HTTP header data overhead to number of vehicle locations and increase in
efficiency of visualization.
With the new technology introductions in HTML5 such as Server Sent Events (SSE)
and WebSocket (WS), it is possible to send data over internet with a push based data
transfer. The web session initiated by browser but, web server pushes subsequent
captured vehicle location updates. This improves the efficiency of the web bandwidth.
This thesis is a comparative analysis between existing technology (AJAX) with new
technologies (SSE and WS) used in Vehicle tracking system.
The results of this study shows that the bandwidth usage is more efficient in case of
new technologies (SSE and WS). The study outcome would help in technology decisions
for future applications with sufficient backing of statistics. In addition, other types of sensors
can use the results in its data transfer. The positive outcome towards the new technologies
provides further motivation to perform detailed studies about them.

5
Table of Contents
Contents
Science Pledge....................................................................................................................2
Acknowledgements:.............................................................................................................3
Abstract................................................................................................................................4
Table of Contents ................................................................................................................5
List of Tables .......................................................................................................................7
List of Figures ......................................................................................................................7
List of Maps .........................................................................................................................8
Chapter 1: Introduction ........................................................................................................9
Background .................................................................................................................9
Vehicle tracking system ......................................................................................9
Tracking device ...................................................................................................9
Tracking server .................................................................................................10
User Interface....................................................................................................11
Vehicle tracking Classification...........................................................................12
Factors affecting visualization ...........................................................................13
Visualization issues...........................................................................................13
Motivation ..................................................................................................................15
Literature review........................................................................................................15
Aims ..........................................................................................................................17
Objectives..................................................................................................................17
Areas of focus ...........................................................................................................18
Chapter 2: Methodology ....................................................................................................19
Study area .................................................................................................................19
Method ......................................................................................................................21
Technologies .............................................................................................................22
Web Feature Service ........................................................................................22
Asynchronous JavaScript + XML ......................................................................23
Server Sent Events ...........................................................................................24
WebSocket........................................................................................................25
Software ....................................................................................................................26
Data capture......................................................................................................27
Data storage......................................................................................................29
Data publishing .................................................................................................32
Data visualization ..............................................................................................32

6
Hyper Text Transfer Protocol traffic Inspection.................................................33
Logging and summarizing visualization statistics..............................................33
Data...........................................................................................................................33
Base Map ..........................................................................................................34
Vehicle location data .........................................................................................34
Vehicle location data Collection strategy ..........................................................34
Environment ..............................................................................................................35
Chapter 3: Processes and Results ....................................................................................38
Software architecture ................................................................................................38
GeoServer Customization for publishing vehicle location data .................................38
GPS simulator ...................................................................................................39
New layer formats .............................................................................................39
Real time – AJAX ..............................................................................................40
Real time – Server sent events .........................................................................41
Real time – WebSocket.....................................................................................43
Web application for data visualization .......................................................................45
Server sent events ............................................................................................47
WebSocket........................................................................................................49
Measurement and logging.................................................................................51
Data publishing and visualization......................................................................52
Results ......................................................................................................................53
Asynchronous JavaScript + XML with 2s polling interval ..................................53
Asynchronous JavaScript + XML with 5s polling interval ..................................55
Asynchronous JavaScript + XML with 10s polling interval ................................57
WebSocket........................................................................................................61
Analysis .....................................................................................................................63
Distance between subsequent vehicle locations...............................................63
Latency in visualization .....................................................................................65
Duplicate and skipped Vehicle location data.....................................................67
Bandwidth usage efficiency...............................................................................69
Discussions ...............................................................................................................72
WebSocket........................................................................................................73
Chapter 4: Conclusions .....................................................................................................74

7
Future work areas .....................................................................................................75
References ........................................................................................................................76
Abbreviations.............................................................................................................78
List of Tables
Table 1: Web browser support for Server-Sent Events .....................................................24
Table 2: Database schema................................................................................................30
Table 3: Tablet configuration for data capturing ................................................................36
Table 4: System configuration (software) used for tracking server and user interface......36
Table 5: System configuration (hardware) used for tracking server and user interface ....37
Table 6: AJAX page actions play button click....................................................................46
Table 7: SSE page actions play button click......................................................................48
Table 8: WS page actions play button click.......................................................................50
Table 9: Distance between subsequent locations (in meter).............................................64
Table 10: Visualization Latency (in milliseconds) ..............................................................66
Table 11: Vehicle location count........................................................................................67
Table 12: Data transfer details (data size in bytes) ...........................................................70
Table 13: Summary of Analysis.........................................................................................72
List of Figures
Figure 1: Methodology.......................................................................................................21
Figure 2: GPS Logger screenshots ...................................................................................27
Figure 3: GPS Logger screenshots ...................................................................................28
Figure 4: PostgreSQL admin interface with created table .................................................31
Figure 5: Software Architecture Diagram...........................................................................38
Figure 6: New Layer formats .............................................................................................40
Figure 7: GetFeature response for output format - LiveSse ..............................................42
Figure 8: GetFeature response for output format - LiveWs ...............................................44
Figure 9: AJAX sequence diagram....................................................................................47
Figure 10: SSE sequence diagram....................................................................................49
Figure 11: WS sequence diagram .....................................................................................50
Figure 12: Sample log for distance and delay ...................................................................51
Figure 13: Filtering GeoServer traffic in Fiddler.................................................................52
Figure 14: Data usage information in Fiddler for AJAX .....................................................54

8
Figure 15: AJAX 2 seconds distance histogram................................................................54
Figure 16: AJAX 2 seconds visualization latency histogram .............................................55
Figure 17: AJAX 5 seconds distance histogram................................................................56
Figure 18: AJAX 5 seconds visualization latency histogram .............................................56
Figure 19: AJAX 10 seconds distance histogram..............................................................57
Figure 20: AJAX 10 seconds visualization latency histogram ...........................................58
Figure 21: SSE distance histogram ...................................................................................59
Figure 22: SSE visualization latency histogram.................................................................59
Figure 23: Data usage information in Fiddler for SSE .......................................................60
Figure 24: WS distance histogram.....................................................................................61
Figure 25: WS visualization latency histogram ..................................................................62
Figure 26: Data usage information in Fiddler for WS.........................................................62
Figure 27: Locations visualized vs Skipped Locations ......................................................68
Figure 28: Received locations vs duplicate locations ........................................................69
Figure 29: Data transfer per vehicle location (bytes) .........................................................71
Figure 30: Header vs Body (bytes)....................................................................................71
List of Maps
Map 1: World map highlighting India .................................................................................19
Map 2: India map highlighting location of Bangalore city...................................................20
Map 3: Study area - Jayanagar locality, Bangalore, India .................................................20
Map 4: Vehicle location data..............................................................................................35
Map 5: Visualization with AJAX – 2 seconds interval ........................................................53
Map 6: Visualization with AJAX – 5 seconds interval ........................................................55
Map 7: Visualization with AJAX – 10 seconds interval ......................................................57
Map 8: Visualization with Server Sent Events ...................................................................59
Map 9: Visualization with WebSocket................................................................................61

9
Chapter 1: Introduction
Background
Vehicle tracking system
Vehicle tracking system captures stores and visualizes the vehicles location for
multiple purposes. The purposes varies from traffic control, surveillance, security, tracking,
monitoring etc. This system utilizes the multiple hardware and software components for its
functionalities. The components of the vehicle tracking system are tracking device, tracking
server and the user interface.
Tracking device
The electronic receivers find the vehicle location using satellite navigation systems.
Satellite navigation system consists of a set of satellites orbiting the earth, transmitting radio
signals. The satellite signals contain its location and a synchronized timestamp. The
electronic receivers receives the satellite signals and calculates the receiver location
(latitude, longitude and altitude) using Trilateration (Wikipedia, Trilateration, 2014).
The satellite navigation systems are classified according to their coverage area of as
Global Navigation Satellite Systems (GNSS) and Regional Navigation Systems. The GNSS
are United States’ Global Positioning System (GPS), Russian GLObal Navigation Satellite
System (GLONASS), and Chinese BeiDou (Wikipedia, Satellite navigation, 2014).
These GNSS systems are either current operational or in development phase. The
GPS has 32 satellites operational since 1978, globally available since 1994. GLONASS
was fully functional from 1995. However, after a decline in its capacity, Russia revived it by
launching new satellites and enabled full global coverage in 2011.
More GNSS is in different stages of construction. Doppler Oribitography and
Radiopositioning Integrated by Satellite (DORIS) is a French GNSS. Galileo of the
European Union, has become operational in 2014, and fully be in service until 2020. China
has planned to complete BeiDou-2 by 2020.

10
Few countries are also building satellite navigation systems that covers their particular
country and their surrounding region. They are BeiDou-1 of China, Indian Regional
Navigational Satellite System (IRNSS) of India and Quasi-Zenith Satellite System (QZSS)
of Japan.
Since, the GPS is used mostly the GPS receiver is used in this study to find the
vehicle location. The location calculated by the GPS receiver depends on various factors.
The major factors affecting the accuracy of location are atmospheric effects, multipath
effects, geometry dilution of precision computation (GDOP) and ephemeris and clock errors
(Wikipedia, Global Positioning System, 2014).
This study is conducted in an urban location, so the major factors affecting the GPS
receiver location accuracy is Dilution of Precision (DOP) and the multipath errors. The
errors are caused when the set of satellites sending the signals to the GPS receiver are
located very closely and in a concentrated formation, prominently in a single direction from
the GPS receiver. For least DOP the satellites should be located uniformly distributed in all
directions of the GPS receiver (Wikipedia, Error analysis for the GPS, 2014).
The satellite signal reflection from terrain, buildings, canyon walls and hard ground
causes multipath errors. This effect is less severe on moving vehicles.
To help in reducing the errors and increase the confidence of the calculated location,
other infrastructure like cell phone towers assist the GPS receivers. This is done providing
data through an internet connection. This assistance can be classified as Mobile Station
Based (MSB) and Mobile Station Assisted (MSA). In MSB the almanac for the GPS
satellites and the precise time are provided to the GPS receiver. In case of MSA, the
position calculation is performed using the information sent by the GPS receiver (Wikipedia,
Assisted GPS, 2014).
Tracking server
The tracking server of the vehicle tracking system performs the functionalities of

11
receiving the location data from the tracking device, storing the received data in an efficient
way and servicing / publishing this information to the user.
The data received from the tracking device is through the internet using mobile GSM
connections. There are multiple vehicle tracking servers both proprietary and open source
available. The proprietary tracking server software are GpsGate server, Wialon and
GeoRadius. The popular open source ones are OpenGTS and Traccar (Wikipedia, GPS
tracking server, 2014).
The source code of OpenGTS and Traccar tracking server is observed. Both the
software is written in Java language. It is found that both of the software are using AJAX
polling techniques from client browser to fetch vehicle location data from server.
The vehicle location data from the tracking device is stored in an efficient manner
different file formats or in an RDBMS for efficient use of storage space and easy retrieval
for publishing. The data is modelled usually with fields to store the geometry, vehicle
identifiers and time stamps and any other additional required data.
The vehicle tracking data is served to the user interface for mapping purposes. The
Open Geospatial Consortium (OGC) standard Web Feature Service (WFS) provides an
interface for requests for geographical features on web using platform-independent calls.
Since the tracking server has the functionality of publishing the data, tracking server
and web server are used as synonym in this report.
User Interface
The user interface is an application that communicates with the tracking server. This
application is usually a web application. This application fetches the vehicle location
information and visualizes the same on a map for the end user. This application should
update the vehicle location data continuously since new vehicle location data might be
available at the tracking server for the set of tracked vehicles. Additionally if there are any
other sensors on the vehicles, the user is provided with the functionality to view the same.

12
Vehicle tracking Classification
The vehicle tracking is classified as two types, Active and Passive based on the when
the captured data is used. In passive tracking, the data is stored on a memory device in
the vehicle and downloaded at specific locations at the end of the trip. In Active tracking,
connectivity is provided to the vehicle location system to enable it to send the captured
information continuously to the central server known as tracking server (Wikipedia, Vehicle
tracking system, 2014).
The captured data usually is vehicle location from GPS device and along with any
other required information such as altitude, heading, timestamp, speed etc. In some cases
additional sensors are integrated for monitoring temperature, vehicle status etc. The data
is then sent to a central database server, to be stored in a spatial database of tracking
server.
The stored data is then published, through web using standard protocols such as
WFS to be served to the client applications for querying and visualization purposes. The
client applications usually browser based, mostly use the traditional AJAX web technology
to fetch the vehicle information. In case of passive tracking the captured data can be played
back using the timestamps of the collected data. In case of active tracking, the data is
received continuously from the vehicles for real time visualization. In case of passive
tracking, the entire track of the vehicle can be viewed at an instance or simulated with
playback functionality according to the timeline of the data captured.
In either case of tracking the playback simulation, in the web application, the browser
is fetching the data from the tracking server using AJAX requests. These requests are of
polling in nature, which are scheduled to repeat at specific interval, to visualize the
movement of the vehicle in the browser.

13
Factors affecting visualization
The real time nature of the visualization depends on various factors such as latency
(between location data capture time and visualization time) and distance between
subsequent captured vehicle locations. This also includes any vehicle locations skipped
from being visualized. The factors contributing to this latency and distance between
successive vehicle locations are as follows:
1) The GPS receivers are configured with parameters of capture time interval and
distance for use while capturing locations. These configuration settings depends on time
elapsed from the last capture, minimum distance travelled between the current location and
last captured location, positional accuracy of the GPS fix achieved. Individual vehicles
would be travelling at varying speeds for different durations of time, faster on straight
sections of road and slower at intersections. The resulting location data captured by
vehicles would be staggered in time.
2) There is no way for the web application, running on the browser, to know the when
the vehicle location is captured by different vehicles and available on the server. To
visualize the vehicle data, the web application uses a polling mechanism to the tracking
server (web server) at scheduled interval for receiving new vehicle locations. This is
achieved using timed AJAX requests to the server.
3) The AJAX requests, like any other traditional HTTP request and response, consists
of headers that are proportionally huge in data size when compared to a single vehicle
location information. To overcome this data size problem, the applications are designed
with a trade-off, in such way as to fetch a collection of vehicle locations at a larger time
interval. This helps in distributing the HTTP header data overhead to number of vehicle
locations.
Visualization issues
Due to the above factors, the visualization of vehicles on web map application is

14
affected in the following ways.
1) Lag in vehicle location display, on the map: The individual vehicle locations are
captured at staggered points in time. The data capturing is based on different parameters
configured on the data collection devices. The parameters include minimum distance
travelled from previous location, time elapsed from previous location captured time. The
same staggered nature of data is captured in the tracking server and available for
publishing. The browser tries to fetch data at regular specified intervals of time for
visualization. So, vehicle locations end up visualized, with lag in time, from the instance it
is captured to the time it is visualized. This lag value in time ranges from few milliseconds
up to the specified fetching time.
2) Less number of vehicle location visualized: Since the web application in the
browser is configured to request vehicle data at specified intervals. In addition, the vehicle
locations are captured according to the travelled distance and elapsed time, there might be
multiple locations captured, between subsequent AJAX requests. In such cases, only the
latest point captured becomes relevant to be visualized. The intermediate vehicle locations
captured would not be fetched by browser since the specified time has not elapsed. So few
locations are not rendered on the map, even though the system captures these intermediate
locations. This shows a gap with a bigger distance between subsequent vehicle locations
during visualization.
3) Duplicate vehicle location received by browser: Conversely to the visualization
issue described in point 2. If new vehicle data is not captured in between two requests from
the browser for visualization. The existing previous vehicle data is sent to the browser. This
results in duplicate vehicle location data being received by browser. There is no action
involved by the browser or it simply renders the vehicle data on top of existing data.
3) Inefficient bandwidth utilization: When no vehicle location points are captured
between subsequent requests, the response is with the same data as received in the
previous request. This request is considered unnecessary since the response contains
same content as the previous one. This results in waste of bandwidth since the request

15
and response was not necessary.
Motivation
The HTML5 has introduced new technologies for data transfer between web server
and the browser, such as Server sent events and WebSocket. These two technologies
have facilitated, push based data transfer from web server to web browser, with minimal
overhead, in terms of data size and latency. This helps in increased efficiency of the internet
usage and more realistic visualization of data.
In this thesis, the newly available web technologies for data transfer are studied to
understand their applicability and to find out the extent to which the visualization affects can
be minimized. The study is limited to the data flow from web application in the browser in
the form of requests and the responses from the tracking server. In case of SSE and WS,
the initial request is always initiated from the browser and further the web server continuous
ahead to push the information to the web browser.
Literature review
The literature related to the new technologies, its application is explored, and the
following information is found.
Many commercial websites providing tracking services are using Ajax as the current
data exchange technology. (MarineTraffic, 2014), (FlightStats, Flight Status & Track, 2014)
These websites are aware of the problem of the latency and the bandwidth issue.
HTML5 provides two alternatives to the real time data exchange problem. Server sent
events and the WebSocket. (Traldsvik, 2011)
What have others found out?
The server sent events technology is an improvement on the COMET push

16
technology where the connection is kept alive and open for streaming data to be received
in future. WebSocket upgrade the HTTP connection to a full duplex communication and
avoids the latency and overhead of request / response headers. (Traldsvik, 2011)
Web services using WebSocket can improve sensor web service performance using
the event processing to send messages to alert public in case of critical events.
(Hubnerova, 2014)
Why is the cited work relevant to your own work?
The cited literature is helps in understanding the possibilities that can be tried using
the newly available web technologies. The literature also helps in limiting or extending the
scope of the study. Various processes and methods that are relevant are also derived from
the cited work.
Solutions suggested for similar problems
The FlightStats site is trying to reduce the response sizes of its API to send the
minimal data to the web clients and has Alert API for push functionality from server. This
push functionality is achieved by using the callback function on the Http web request
parameters. (Flightstats, 2014), (FlightStats, Alerts API, 2014)
WebSocket are fast and are used in data exchange between web server and web
client, for generating faster graphics on the server side using R statistical package. This
helps in faster data transfer instead of usual file upload. (Ebrahim Jahanshiri, 2014)
Vector maps are published using progressive loading using a WebSocket technology
for data exchange, as and when a new set of data is required for the map. (Yongning Wen,
2011), (Padraig Corcoran, 2011)
WebSocket are used to visualize the vehicle locations overlaid on the Google Maps.
(Bo Mao, 2012)

17
Aims
The aims of this study are as follows:
 Understand the new web technologies available for data transfer over web. Find out
the web technologies, which can be used for efficient vehicle location visualization?
 To capture the statistics for the following parameters, using different web
technologies:
o Time delay between times of vehicle location capture in web server and is
visualization on web browser.
o Distance between subsequent vehicle locations visualized on browser,
o Duplicate locations received in browser for visualization,
o Locations skipped from being visualized in the browser
o Bandwidth usage of web application for transfer of vehicle location between web
server and browser.
 Compare the collected statistics for finding the level of improvements achieved by
using new web technologies.
Objectives
The objectives necessary to arrive accomplish the aims of this thesis study are as
follows:
 Find the data size in bytes transferred for each vehicle location between web server
and browser.
 Find the vehicle location count transferred from web server to browser.
 Find the ratio of vehicle locations visualized vs vehicle locations skipped being
visualized.
 Find the ratio of vehicle locations received by browser vs duplicate vehicle locations
received.
 Find the median of distances between subsequent vehicle locations received by

18
browser for visualization.
 Find the time delay between the vehicle location capture in web server and its
visualization on browser.
Areas of focus
The areas being concentrated in this study is limited to the AJAX, Server Sent Events
and WebSocket. Long polling is not considered for the study, because it is similar to AJAX
except that, the request is placed on hold / wait at the server end until new data is available.
The long polling would avoid the duplicate data being sent to the web application for
visualization. However, it will not avoid the data being skipped, due to time gap between
successive requests for location data.

19
Chapter 2: Methodology
The methodology, data formats, software and technologies used in this study is
described in this chapter.
Study area
The fleet tracking usually involves large areas covering multiple states and cities or
even countries. For this study purpose, a small locality is selected for collecting vehicle
movement data and using them for finding the study objectives.
The study area is a locality named Jayanagar in Bangalore, India. This area is
selected because of the grid pattern of streets in the locality. The grid pattern of streets
helps in better planning of vehicle location data collection and helps in reducing the clutter
and overlapping of multiple vehicle tracks during visualization. Map 1 shows the location of
India country.
Map 1: World map highlighting India

20
Map 2: India map highlighting location of Bangalore city.
Map 3: Study area - Jayanagar locality, Bangalore, India

21
Method
Figure 1: Methodology
The Figure 1 shows the methodology followed in this study. For this methodology,
first the software for simulating vehicle location data, tracking server and the web application
for visualization needs to be either configured or customized.
Vehicle location data collection – The vehicle location data is collected using the GPS
receiver on an android tablet phone, using a logger software named GPS Logger. The GPS
data of the vehicle movement saved as GPX files for simulation in the following steps of the
process.
Simulate Vehicle location data – The created GPX files are used to simulate the
vehicle location data to be captured and published by the tracking server. The vehicle data
is simulated with delays between, subsequent locations according to timestamps present in
GPX files. The GeoServer software is customized to perform this functionality of simulating
vehicle location data.
Store Vehicle location data – The simulated vehicle location data is stored in a spatial
database. The spatial database is used by web server to publish the vehicle locations same
for user interface receive and visualize on the browser for end user. The GeoServer
Collect Vehicle
location data
Store Vehicle
location data
Simulate Vehicle
location data
Publish Vehicle
location data on web
Visualize vehicle
location data in browser

22
software is customized to perform this functionality of capturing the vehicle location data. A
PostgreSQL database is designed to capture the simulated vehicle location data.
Publish vehicle location data – The web server connects to the spatial database and
publishes the vehicle location data to the web. The GeoServer is customized to perform
this functionality. The additional technologies that are not present in GeoServer, SSE and
WS is introduced.
Visualize vehicle location – The web application connects to the web server and
receives vehicle location data for visualizing the same on the browser.
Technologies
This section describes the technologies used in the study. The technologies
described here are the ones used for data exchange between the web server and the
browser application.
Web Feature Service
Web Feature Service (WFS), the data exchange interface specified by OGC
between the web server and the web application on the browser is used for all data transfer
(OGC, 2014). The JSONP format is used for transferring data. The JSONP provides
padding to the JSON data being transferred and is used to send back the call back method
name for client rendering action. It is also beneficial in supporting cross origin resource
sharing (CORS) of the web application (Wikipedia, Cross-origin resource sharing, 2014).
The WFS contains operations such as GetCapabilities, DescribeFeatureType,
GetFeature, LockFeature and Transaction. The GetCapabilities operation request provides
list of operations supported by the WFS. The DescribeFeatureType operation is used to
get the description of the features. The GetFeature operation is used to get the feature
using various filter parameters. In this study, explicit calls are made using GetFeature
operation by the web applications for polling purpose in case of AJAX and for getting the

23
URL in case of SSE and WS.
Sample GetFeature request is shown below:
http://example.com/wfs?service=WFSSIMPLE&version=0.5&REQUEST=GetFe
ature&BBOX=-71.00,42.00,-72.00,43.00&TIME=2006-09-12/2006-09-
22&OUTPUTFORMAT=text/xml
Asynchronous JavaScript + XML
AJAX stands of Asynchronous JavaScript and XML. This web technique is used to
send and receive data between web server and browser without disturbing display or
behavior of web page. The data is received using XMLHttpRequest, it supports XML, and
JSON data formats are request and response body. The AJAX is used to understand the
visualization of vehicles in the traditional way and to be used to find out the base statistics
to serve as a standard for comparing the new technologies. (Wikipedia, AJAX, 2014). Every
AJAX request to the web server is a new HTTP session altogether that requires the header
information in request and response to be transmitted for each request response cycle. In
addition, the session needs to be created between the web client and web server, which is
a time intensive process.
The jQuery is a fast, small and feature rich JavaScript library. It facilitates HTML
document traversal and manipulation, event handling, animation and Ajax simple to use in
different browsers (jQuery, 2014). The OpenLayers JavaScript library for mapping uses
jQuery for its functionalities. The same jQuery is used to send the Ajax requests for polling
the GeoServer for new vehicle location data.
A sample Ajax request is shown below:
$.ajax({
url :
“http://localhost:8080/geoserver/tracking_ws/ows?service=WFS&versi
on=1.0.0&request=GetFeature&typeName=tracking_ws:vehicleposition&o
utputFormat=json”,
datatype: ‘jsonp’});

24
Server Sent Events
Server sent events is a technology where the browser receives automatic updates
from the server through a HTTP connection. For consuming the Server-Sent Events in the
browser, Event Source API is standardized as part of HTML5 by the W3C. When this API is
used to create an eventsource object a HTTP request that accepts the content type of
“text/eventstream” is sent to the server. The response handler at the web server for
requests with a content-type of “text/event-stream” keeps open the HTTP session with and
sending updates through this open stream to the browser. (Wikipedia, Server-sent events,
2014). Since HTTP connection is kept open by the server, the data is sent to the browser
as soon as it is available reducing the lag time between the data capture time and
visualization.
Table 1: Web browser support for Server-Sent Events
Browser Supported Notes
Internet Explorer No
Mozilla Firefox Yes Starting with Firefox 6.0
Google Chrome Yes
Opera Yes Starting with Opera 11
Safari Yes Starting with Safari 5.0
The Table 1 lists out the browsers supporting the new SSE technology. As seen, only
the Internet Explorer among the popular browsers does not support the SSE technology as
of now.
The advantage of SSE over AJAX is that the web browser need not send requests for
updates at regular interval and unaware of whether a data update is available or not. Only
one request from the browser and an event subscription to the event source is enough. The
server keeps sending the updates in the form of events, whenever new data is available.
(Bidelman, 2014)
SSE Request (sample): In the request headers, the Accept parameter has a value of
“text/event-stream”. This request header denotes the server for creation of event source

25
and subscription of event handler.
GET
http://localhost:8080/geoserver/eventsource?type=tracking:vehicl
eposition
HTTP/1.1
Host: localhost:8080
Connection: keep-alive
Accept: text/event-stream
Cache-Control: no-cache
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64)
AppleWebKit/537.36 (KHTML, like Gecko) Maxthon/4.4.1.5000
Chrome/30.0.1599.101 Safari/537.36
Origin: http://localhost:81
DNT: 1
Referer: http://localhost:81/ssedemo.html
Accept-Encoding: gzip,deflate
Accept-Language: en-US
SSE Response (sample)
HTTP/1.1 200 OK
Date: Sun, 21 Sep 2014 19:31:02 GMT
Access-Control-Allow-Origin: *
Content-Type: text/event-stream; charset=UTF-8
Connection: close
Server: Jetty(9.2.2.v20140723)
WebSocket
WebSocket is a new protocol in HTML5 specification, which provides full-duplex (two-
way between browser and wen server) communication over a TCP connection. The
protocol prefix of “ws:” is used to create a WebSocket API object. The request from the
WebSocket is interpreted by web server as an upgrade handshake request and a
WebSocket is opened for further interaction with the client. This WebSocket is then kept
open for all data transfer between client and server (Wikipedia, WebSocket, 2014). The

26
client then subscribes to an event on the WebSocket to receive data from the web server.
The web server sends the data whenever available to the client, by raising the event.
Currently the latest version of all popular browsers support WebSocket.
The sample WebSocket request is shown below, which shows the handshake
information requesting for an upgrade to WebSocket.
GET
http://localhost:8080/geoserver/websocket?type=tracking:vehiclep
osition HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Host: localhost:8080
Origin: http://localhost:81
Pragma: no-cache
Cache-Control: no-cache
Sec-WebSocket-Key: KoWrPxzcvFoRb2V0Hfm21w==
Sec-WebSocket-Version: 13
Sec-WebSocket-Extensions: x-webkit-deflate-frame
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64)
AppleWebKit/537.36 (KHTML, like Gecko) Maxthon/4.4.1.5000
Chrome/30.0.1599.101 Safari/537.36
The sample WebSocket Response shows below the response from web server about
switching protocols and the upgrade of the HTTP connection to a WebSocket.
HTTP/1.1 101 Switching Protocols
Date: Sun, 21 Sep 2014 21:40:20 GMT
Connection: Upgrade
Sec-WebSocket-Accept: zPAR5wP+eFB+3Sr8MQHGeYIauDw=
Upgrade: WebSocket
EndTime: 03:14:40.170
ReceivedBytes: 444685
SentBytes: 6
Software
Multiple software components are used for the study. Few software are used as it is

27
with minimal configuration settings such as GeoServer and location data logging. Few were
customized to implement new features that was not part of the original versions available
for download like GeoServer, OpenLayers.
Data capture
The vehicle location data is captured using a GPS receiver available on an Android
tablet. The software used for logging the vehicle location data is named “GPS logger for
Android”, downloaded from Google Play store, (Mendhak, 2014). The GPX file format is
used as output format for logging. Additionally KML formats where also opted for to view
the captured data to get an overview using Google Earth.
The GPS Exchange Format is an XML schema designed as common GPS data
format for software applications for data transfer. It can be used to describe individual
waypoints, tracks travelled by the vehicle, routes calculated by a navigational software.
Figure 2: GPS Logger screenshots
The Figure 2 shows the screenshots of the GPS logger application in an android

28
tablet. This application has UI to view the current location coordinates, elevation, duration,
distance travelled, speed, points logged, accuracy and bearing.
Figure 3: GPS Logger screenshots
The Figure 3 shows the configuration screens of the GPS Logger applications where
the logging parameters such as capture interval, least distance for logging, logging location
can be configured.
The sample GPX file is shown below with a single point for reference. The data being
used for this study, such as vehicle location containing latitude, longitude and timestamp is
highlighted. The parameters denoting the accuracy of the data such as HDOP, VDOP and
PDOP is also captured in the found the GPX file.
Sample GPX file
<gpx xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance" xmlns="http://www.topografix.com/GPX/1/1" version="1.0"
creator="GPSLogger -
http://gpslogger.mendhak.com/" xsi:schemaLocation="http://www.topo
grafix.com/GPX/1/0 http://www.topografix.com/GPX/1/0/gpx.xsd">

29
<time>2014-09-15T01:06:28Z </time>
<trk>
<trkseg>
<trkpt lat="12.92835063637114" lon="77.60044786027773">
<ele>816.3553650127724</ele>
<time>2014-09-15T01:06:28Z</time>
<course>293.15225</course>
<speed>4.016636</speed>
<src>gps</src>
<sat>13</sat>
<hdop>0.74</hdop>
<vdop>1.88</vdop>
<pdop>2.02</pdop>
<geoidheight>-088</geoidheight>
</trkpt>
------ More trkpt elements
</trkseg>
</trk>
</gpx>
Data storage
PostgreSQL is an ORDBMS with primary function is to store data, securely and
supporting best practices for later retrieval by other software applicators on same computer
are running across internet. It provides concurrency, replication for security and scalability
(Wikipedia, PostgreSQL, 2014).
For storing the GPS data, the PostgreSQL database is used. In real applications, a
complex and huge database schema needs to be designed to store the data such as the
vehicle movement history, vehicle details, driver details, source and origin and so on.
For this study purpose since a small number of vehicles are used and there is no
requirement for any other kind of data to be stored in the database, the database schema
designed is a very simple one consisting of only one table named VEHICLEPOSITION
described in Table 2.

30
Table 2: Database schema
Column Name Data type
VEHICLEID Text
THE_GEOG Geography(Point, 4326)
CAPTURETIME Timestamp
This table is used to store the vehicle identifier, its location data and timestamp of
data captured time. The location is stored using a Geography data type available in
PostgreSQL with a point type of geometry. The vehicle location data is modelled as a point
and the table is designed to store the last captured position of each vehicle. When the new
vehicle location data is captured, it updates the existing location in the VEHICLEPOSITON
table.
The SQL statement for table creation.
CREATE TABLE VEHICLEPOSITION (
THE_GEOG geography(Point,4326),
VEHICLEID text,
CAPTURETIME timestamp without time zone,
)
VEHICLEID - The column stores the identifier of the vehicle. The file name without
the extension is used as value for this column in the GeoServer implementation.
THE_GEOG - This column stores the geographical information, the location of the
vehicle. The type of geometry stored is point. The EPSG:4326 is used to define the
coordinate system of the location coordinates. The EPSG:4326 is a Geographic Coordinate
System with WGS 1984 as datum, and coordinate units as decimal degrees specifying
latitude and longitude.
CAPTURETIME - This column stores the timestamp containing date and time of the
vehicle location. In this study, the system time when the record is updated / inserted is used
for the timestamp, since the GPS points are received from the simulator.
Insert query for vehicle position.

31
INSERT INTO VEHICLEPOSITION
(THE_GEOG, VEHICLEID, CAPTURETIME)
VALUES
(ST_GeographyFromText(
'SRID=4326;POINT(Longitude Latitude)'),
'id', 'time' )";
Update query for vehicle position.
UPDATE VEHICLEPOSITION
SET
THE_GEOG = ST_GeographyFromText(
'SRID=4326;POINT(Longitude Latitude)'),
CAPTURETIME = 'time'
WHERE
VEHICLEID = 'vehicleid';
Figure 4: PostgreSQL admin interface with created table
The PostgreSQL admin tool shown in Figure 4 is used for all database admin activities

32
such as connection, creating database, creating tables and verifying the stored data.
Data publishing
GeoServer an open source web server software, written in Java for publishing
geospatial data, is used to publish the vehicle location. The software is modified with
features, to support simulator functionalities, new data exchange technologies such as
Server Sent Events and WebSocket. GeoServer is an OGC compliant implementation of
open standards such as Web Feature Service, Web Map Service (WMS) and Web
Coverage Service (WCS). More formats and publication options such as Web Map Tile
Service (WMTS) and extensions for Catalogue Service (CSW) and Web Processing Service
(WPS) are also available (Geoserver, 2014).
Data visualization
OpenLayers an open source JavaScript library, for displaying the map data is used
for visualizing the vehicle location on the base map (OpenLayers, 2014). The application
is developed to use the OSM as base map, with play and stop controls for GPS simulator.
The applications is customized to use new data exchange technologies such as Server Sent
Events and WebSocket. The vehicle location data is received as part of the response in
case of AJAX trials. In case of SSE and WS trials, the vehicle location data is received as
part of the data in the events raised by the event source and the web socket. The map
navigation controls such as pan, zoom are also enabled using standard OpenLayers
methods.
Also since the vehicle location data is captured in EPSG:4326, WGS 84, Geographic
Coordinate System and the OSM base map is available In EPSG: 3857, Spherical Mercator
Project Coordinate System, an inbuilt coordinate transformation method in OpenLayers is
used for the fetching of data for vehicle location data from GeoServer. This method
transforms the base map extent coordinates in EPSG:3857 to EPSG:4326 values. These

33
new extent values fetch the vehicle location data of the map extent.
Hyper Text Transfer Protocol traffic Inspection
Data exchange happens between the web server and the browser when the vehicle
location data is visualized. To understand what is happening behind scenes an application
is required to inspect the traffic between them. Fiddler, a web debugging proxy from Telerik
is used to inspect the web traffic for the study (Fiddler, 2014). It provides values for the web
traffic such as request, response headers, size of data transported, content, protocol, host,
origin, time elapsed etc. Also summary of multiple request, response sessions can be
found, using the tool. Installing few add-ons for the Fiddler, the content of the request and
response with can also be viewed. The content can be of any type such as binary, text,
JSON, XML, image etc. There are different viewers for all formats of data in Fiddler.
Logging and summarizing visualization statistics
The details of the visualization such as vehicle id, distance between subsequent
locations and latency in visualization are all logged to a browser console using a JavaScript
library named log4Javascript (Log4Javascript, 2014). This library has functionality to log in
different locations such as a popup message box, browser console, using AJAX to log in a
web service etc.
For the study purpose, the logging is configured to be in the browser console. The
logged data is transferred to Microsoft Excel worksheets for summarizing the statistics and
creating graphs such as histograms and bar charts for analysis purposes.
Data
The data for this study is from two sources. The base map is from the OpenStreetMap
and vehicle locations are captured from a GPS receiver. The vehicle location data is
simulated to update the source as per the captured timestamps.

34
Base Map
There are multiple options for base map selection such as Google Maps, Bing Maps,
and OpenStreetMap. For this study, the OpenStreetMap is used as base map in the
visualization. The OSM is published in EPSG: 3857, Spherical Mercator Project Coordinate
System with meter as units of measure. (OpenStreetMap, 2014)
Vehicle location data
The vehicle locations are captured using a tablet containing GPS receiver. The output
file format of the GPS logger software is selected as GPX files. The GPX file format is
selected because it is a device independent GPS data transfer format and is in XML format,
which is easier to read and parse information.
Vehicle location data Collection strategy
For different applications such as traffic surveillance, fleet tracking, security the
vehicle movement collection strategies changes. For traffic congestion, it is required to
know where clusters of vehicles are formed and are slow moving. In case of fleet tracking,
it is required to know where the fleet of vehicles are present. Therefore, the application
drives the vehicles to be tracked, and changes for different scenarios.
For this study, the vehicle routes are planned to visualize as many vehicles possible
in a single map view. Routes are also planned to avoid clutter on the map and reduce
multiple vehicles rendering over each other. The routes are planned in four groups of
vehicles travelling from four different directions North, South East and West of study area.
They are planned to travel to the opposite side of the study area. The vehicle routes
planned are five vehicles from north to south, four vehicles from south to north route, 3
vehicles from east to west route and two vehicles from west to east route.
The GPS logger logging settings were set to collect points at maximum time interval

35
possible with minimum 3 meter for distance filter. This setting ensures that the minimum
distance between subsequent locations are 3m and the data is collected every second. If
the vehicle has not moved beyond 3 meter in a second, then those locations at every second
are not captured by the GPS Logger.
Since arranging multiple vehicles and collecting its movement data is expensive to
achieve without sufficient vehicle and human resource, a single vehicle is used for data
collection. The vehicle location data was collected in a single trip to cover all the 14 vehicle
routes, and individual GPX files were generated. The individual vehicle route data collected
at different instances of time are simulated at the together for analysis purposes.
Map 4: Vehicle location data
The collected vehicle location data is shown as tracks in Map 4. The GPX files are
named as 1.gpx, 2.gpx and so on up to 14.gpx. The total vehicle locations captured in 14
GPX files is found to be 2294.
Environment
In case of vehicle tracking, systems involve multiple hardware and software that
needs to perform more than normal working the environment. The vehicle-tracking device
such as GPS and transmission device GSM needs to be present on the vehicle that needs

36
to perform under different temperature range because it is outdoors. They also sustain
vibrations during vehicle movement. The tracking server needs to capture data from
multiple vehicle and store it efficiently in a large spatial database. The web server should
fetch the data from spatial database and provide to the numerous requests from different
end users. This means the vehicle tracking system has very high performance
requirements, consequently better hardware, and software system components integrated
and working in synch with each other.
For this study purpose, the hardware and software components used are limited to
the available smaller counterparts. The following are system configuration is used to
perform this study. Firstly the tablet used for GPS data collection of the vehicle locations.
Table 3: Tablet configuration for data capturing
Operating system Android 4.2.2 (Jelly Bean)
Memory 1GB
GPS Logger Version 51
Disk space 16GB
Table 3 shows the Android tablet that is used in data collection and it does not use a
GSM module to transfer data, instead the GPX files are transferred to the laptop via USB
connectivity.
The software and hardware on the machine used for vehicle data simulation, tracking
server, and visualization.
Table 4: System configuration (software) used for tracking server and user interface
Operating system Windows 8.1
Web server GeoServer 2.5.2
Client mapping library OpenLayers 3.0.0
Web Browser Chrome 37.0
Java Version 8 Update 11
Java Development IDE Eclipse Luna Release (4.4.0)
Servlet Engine Jetty Version 9.2.2
Geodatabase PostgreSQL 9.3

37
Table 5: System configuration (hardware) used for tracking server and user interface
System Type 64 bit
Processor Intel Core 2 Duo – 2.00 GHz
Memory 3.00 GB
Hard disk 128 GB

38
Chapter 3: Processes and Results
Software architecture
The software is configured and new functionality required is implemented to support
study of data transfer from web server to browser. The software architecture diagram of
the solutions is shown in Figure 5. The data sources used here are the GPX files for vehicle
location data simulation, PostgreSQL database for storage and the OpenStreetMap as base
map in the web application for visualization. GeoServer is used as the tracking server and
the spatial data publisher.
Figure 5: Software Architecture Diagram
GeoServer Customization for publishing vehicle location data
The GeoServer functioning as tracking server in this study is customized to add new
functionalities for this study. A GPS simulator is added that simulates the vehicle location
data captured as GPX files, sends to the server for capture, and publish. A set of 3 layer
formats for Real time data are added to include functionality in GeoServer. These set of
formats handles the GPS simulator functionality and publishes the vehicle location data in
a new way by creating URLs for SSE and WS. The GeoServer source code is in Java
format with Jetty as the servlet engine. Eclipse IDE for Java is used for all customization,
Customized GeoServer Web application
GPS
Simulator
Servlet
for SSE
Servlet
for WS
Event Source
WebSocket

39
build, debugging, testing purposes.
The SSE and WS required additional libraries components of jetty than that is used
in the GeoServer. These required libraries are found and added to the GeoServer
codebase.
In addition, the jetty library versions were changed to the latest ones because the
GeoServer contains jetty libraries that does not support the event source and the
WebSocket features. The JSONP data output format is enabled, since it is disabled by
default.
<context-param>
<param-name>ENABLE_JSONP</param-name>
<param-value>true</param-value>
</context-param>
Two new servlets named RealtimeEventsSourceServlet.java and
RealtimeWebSocketServlet.java is configured using servlet mapping in web.xml file. These
servlets provide the additional functionality required for the SSE and WS, by creating a URL
to subscribe to the events.
GPS simulator
A component to read the GPX files are of supposedly multiple vehicle location data is
implemented raise events at appropriate time delays between the two successive track
points as per the timestamps of GPX files. When the vehicle location data events are fired,
they are captured and stored in PostgreSQL database. An open source library named
libGpx4J is used to read the GPX files and retrieve all the track points (gpx4j, 2014). The
GPX files are in XML format and libGpx4J uses XML file reader internally to get the data.
New layer formats
A new set of format for the layers under the WFS are added in GeoServer software.

40
These formats are configured to return data in GeoJSON format. Additionally the formats
related to new technologies SSE and WS returns a URL of Event source and WebSocket
respectively. The Realtime – Ajax format has parameters to the play and stop GPS
simulator as request parameters. The SSE and WS real time formats starts playing the
GPS simulator when they are instantiated using their API. The new set of layer formats are
shown in the screenshot of GeoServer in Figure 6.
Figure 6: New Layer formats
Real time – AJAX
This layer format is used to collect the statistics of vehicle movement visualization
using AJAX technology for comparison with the newer technologies. Since AJAX is only a
request response sequence of functionality, the server is not aware of when to start the
GPS simulator. To add the play and stop functionality of GPS simulator a new parameter
named action is introduced. To start the GPS simulator a value of “action=play” is included
in the request URL and to stop the GPS simulator a value of “action=stop” is included in the
request URL.
The URL to start the GPS simulator is shown below:
http://localhost:8080/geoserver/tracking_ws/ows?service=WFS&versio
n=1.0.0&request=GetFeature&typeName=tracking_ws:vehicleposition&ou

41
tputFormat=LiveAjax&action=play
The URL to stop the GPS simulator is shown below:
n=1.0.0&request=GetFeature&typeName=tracking_ws:vehicleposition&ou
tputFormat=LiveAjax&action=stop
The rest of the functionality is similar to GeoJSON layer format present in GeoServer.
Real time – Server sent events
This layer format is used to collect the visualization statistics of vehicle movement
using Server Sent Events technology. This layer format provides additional functionality of
providing the client (web browser) with the URL of the Event Source. The Event source is
the location where the client needs to subscribe to in order for it to receive new data
updates.
GetFeature request with SSE is shown below:
n=1.0.0&request=GetFeature&typename=tracking_ws:vehicleposition&ou
tputFormat=LiveSse&format_options=callback:loadFeatures;id_policy:
vehicleid&srsname=EPSG:4326
The response for the “Real time – Server Sent Events” contains a URL to the event
source servlet. Forming this URL on server side is shown below:
HttpServletRequest req =Dispatcher.REQUEST.get().getHttpRequest();
WFSInfo wfs = getInfo();
Gjson gjson = new Gjson();
String url = "", workspace = "", layerName = "";
GetFeatureType request = (GetFeatureType)
getFeature.getParameters()[0];
String baseurl = request.getBaseUrl();
request.setMaxFeatures(BigInteger.valueOf(0));
for (QueryType query : (EList<QueryType>) request.getQuery()) {

42
QName typeName = (QName) query.getTypeName().get(0);
workspace = typeName.getNamespaceURI();
layerName = typeName.getLocalPart();
break;
}
url = getFullURL(req);
url = baseurl + "eventsource?type=" + workspace + ":" + layerName;
gjson.write(featureCollection, output, getFeature, wfs, gs, url);
Figure 7: GetFeature response for output format - LiveSse
Figure 7 shows the response of the SSE request. This response contains a URL
value. The URL property contains the URL for the event source location. This can be
further used by the web application from the client side to connect and subscribe to the data
updates.
The GPS simulator play is initiated in the GeoServer when the event source
connection is initiated from the browser. The event source servlet connect code creates a
new event source and an event sender to send the location updates. The creation of event
source and the initiation of GPS simulator play functionality on the server side is shown
below:
RealtimeEventSource eventSource = new RealtimeEventSource();
Publisher eventSender = CreatePublisher(request, eventSource);
Simulator simulator = SimulatorBuilder.getInstance);
simulator.setPublisher(eventSender);
Tivo.TivoAction("play");

43
return eventSource;
When new vehicle location is simulated by the GPS simulator, the following code on
the web server sends the vehicle location data through event source to the browser for
visualization.
String datatoSend = "{"type":"Feature","id":""
+ vehicleId
+ "","geometry":{"type":"Point","coordinates":["
+ longitude + "," + latitude
+ "]},"geometry_name":"the_geog","
+""properties":{"capturetime":""
+ time + ""}}";
eventSource.emitEvent(datatoSend);
Real time – WebSocket
This layer format is used to collect the visualization statistics of vehicle movement
using WebSocket technology. This layer format provides additional functionality of
providing the client (web browser) with the URL of WebSocket. The WebSocket is the
location where client needs to connect and subscribe in order for it to receive new data
updates.
GetFeature request with WS is shown below:
tputFormat=LiveWs&format_options=callback:loadFeatures;id_policy:v
ehicleid&srsname=EPSG:4326
The response for the “Real time – WebSocket” contains a URL to the web socket
servlet. The forming of the URL for the WS on the web server is shown below:
WFSInfo wfs = getInfo();
Gjson gjson = new Gjson();
String url = "", workspace = "", layerName = "";
GetFeatureType request = (GetFeatureType)

44
getFeature.getParameters()[0];
String baseurl = request.getBaseUrl();
for (QueryType query : (EList<QueryType>) request.getQuery()) {
QName typeName = (QName) query.getTypeName().get(0);
workspace = typeName.getNamespaceURI();
layerName = typeName.getLocalPart();
break;
}
baseurl = "ws" + baseurl.substring(baseurl.indexOf(":"));
url = baseurl + "websocket?type=" + workspace + ":" + layerName;
gjson.write(featureCollection, output, getFeature, wfs, gs, url);
Figure 8: GetFeature response for output format - LiveWs
Response for GetFeature request with WS is shown in Figure 8. The response
contains a URL property, which contains the URL for the WebSocket location. This can be
further used by the web application from the client side to connect and subscribe to the
vehicle location data updates.
The GPS simulator play is initiated in the GeoServer when the WebSocket connection
is initiated from the browser. The web socket servlet connect code creates a new web
socket and a data sender to send location updates. The code that creates the WS and
initiates the GPS simulator is shown below:
RealtimeWebSocket realtimeWebSocket = realtimeWebSocketCreator
.getSocket();
Publisher eventSender = CreatePublisher(request,
realtimeWebSocket);

45
Simulator simulator = SimulatorBuilder.getInstance();
simulator.setPublisher(eventSender);
Tivo.TivoAction("play");
When new vehicle location is simulated by the GPS simulator, the following code
sends the data through the web socket to the browser for visualization.
String datatoSend = "{"type":"Feature","id":""
+ vehicleId
+ "","geometry":{"type":"Point","coordinates":["
+ longitude + "," + latitude
+ "]},"geometry_name":"the_geog","
+ ""properties":{"capturetime":""
+ time + ""}}";
Session session = webSocket.getSession();
RemoteEndpoint remote = session.getRemote();
remote.sendStringByFuture(datatoSend);
Web application for data visualization
The web application is developed using OpenLayers 3. The functionalities of this
application is to visualize the vehicle locations on the base map. OpenStreetMap is used
as base map, with play and stop controls for GPS simulator.
This web application consist of three different web pages, one for each technology.
A legend of different vehicles is also shown in all the three different web pages. These web
pages log visualization statistics into a browser window for summarization and analysis
purposes.
The vehicle vector layer contains a callback function named “loadfeatures” for loading
vehicle locations into the vector layer for visualization. A logging functionality into a browser
console is also implemented.
Asynchronous JavaScript + XML
In the AJAX page, all the drawing of vehicle locations is performed by the callback

46
function. This is both in case of map extent change in case of user pan, zoom actions, and
in case of new data being found by AJAX call to GeoServer.
URL for the vector layer is shown below:
tputFormat=LiveAjax&format_options=callback:loadFeatures;id_policy
:vehicleid&srsname=EPSG:4326
On start button click, a request to start the GPS simulation is sent to GeoServer, and
the vector layer is refreshed using AJAX at predefined interval. This AJAX requests gets
new vehicle locations and then callback function draws it on map.
Code for play button click is shown below:
$('#play').click(function(){
$.ajax({url:'http://localhost:8080/geoserver/tracking_ws/ows?s
ervice=WFS&version=1.0.0&request=GetFeature&typeName=tracking_ws:v
ehicleposition&outputFormat=LiveAjax&action=play',
dataType:'jsonp'});
window.setInterval(refresh, 2000);
});
Table 6: AJAX page actions play button click
Code Description
action=play Starts the GPS simulator on GeoServer
window.setInterval(refresh, 2000); Starts the AJAX at an interval of 2 seconds
Table 6 shows the code and the functionality it implements. Sample response for the
vehicle vector layer URL.
loadFeatures({"type":"FeatureCollection","totalFeatures":14,"featu
res":[
{"type":"Feature","id":"1","geometry":{"type":"Point","coordinates
":[77.60044786027773,12.92835063637114]},"geometry_name":"the_geog
","properties":{"capturetime":"2014-09-28 09:29:57.480"}},

47
…… // more instances of features (total 14 features)
],"crs":{"type":"EPSG","properties":{"code":"4326"}}})
This response is a function callback to the loadfeatures function with the parameter
content as the set of features from the web server. The vehicle location data contained in
the parameter is added to the vector layer of the map application. This triggers the vector
layer rendering process and the new vehicle data is visualized on the browser.
Figure 9: AJAX sequence diagram
The sequence of the actions is shown in Figure 9. First, the user loads the map using
the URL in the browser (client). The client sends the map request to the web server. The
Map response is sent back from web server to the client. The Client loads the map for the
user to view. The user clicks the Play button, the client starts the AJAX requests at set time
interval to the web server. The web server returns the map responses according to the
requests. The client loads the map for user to see the movement of the vehicle. Later the
user clicks the Stop button to stop the AJAX requests.
Server sent events
In SSE page, vector layer callback function “loadfeatures” is used to load vehicle
locations only at the initial layer load. Later when the map extent is changed due to user
pan or zoom actions.

48
URL for the vector layer is shown below.
tputFormat=LiveSse&format_options=callback:loadFeatures;id_policy:
vehicleid&srsname=EPSG:4326
On initial load of the layer, the EventSource URL is stored for further use. On play
button click, an Event source object is created and the message event is subscribed for
new vehicle location.
Code for play button click:
eventsource = new EventSource(eventsourceurl);
eventsource.addEventListener('message',readFeature);
});
Table 7: SSE page actions play button click
Code Description
eventsource = new EventSource(eventsourceurl); Creates the EventSource
object using the received
URL
eventsource.addEventListener('message',readFeature); Subscribes to message event
for vehicle location updates.
Table 6 shows the code and the functionality implemented by it. Sample data
received when message event is occurred is shown below:
data:{"type":"Feature","id":"1","geometry":{"type":"Point","coordi
nates":[77.60040202951282,12.92835925031889]},"geometry_name":"the
_geog","properties":{"capturetime":"2014-09-30 01:33:19.22"}}
This data is received each time a new vehicle location is simulated. The event handler
uses this vehicle location data to add them to the vector layer.

49
Figure 10: SSE sequence diagram
The sequence of the actions is shown in Figure 10. The initial steps are similar to the
AJAX sequence. The map response contains a URL for the Event Source. The user clicks
the Play button, the client requests to the web server, with the SSE URL to create an event
source object. Then the client subscribes to the event on the event source for vehicle
location updates. The web server now starts sending the message event with vehicle
location to the client. The client renders vehicle location on the map for user to see the
movement of the vehicle. Later the user clicks the Stop button to stop close the event
source object.
WebSocket
Similar to the SSE page, the WebSocket the vector layer callback function
“loadfeatures” is used to draw vehicle locations only at the initial layer load. Later when the
map extent is changed due to user pan or zoom actions.
URL for the vector layer is shown below.
tputFormat=LiveWs&format_options=callback:loadFeatures;id_policy:v
ehicleid&srsname=EPSG:4326
On initial load of layer, WebSocket URL is stored for further use. On play button click,

50
a WebSocket object is created and message event is subscribed for receiving new vehicle
location updates. Code for play button click:
websocket = new WebSocket (websocketurl);
websocket.addEventListener('message',readFeature);
});
Table 8: WS page actions play button click
Code Description
websocket = new WebSocket (websocketurl); Creates the WebSocket object
using the received URL
websocket.addEventListener('message',readFeature); Subscribes to message event
for vehicle location updates.
Sample data received when message event is occurred.
data:{"type":"Feature","id":"1","geometry":{"type":"Point","coordi
nates":[77.60040202951282,12.92835925031889]},"geometry_name":"the
_geog","properties":{"capturetime":"2014-09-30 01:33:19.22"}}
This data is received each time a new vehicle location is simulated. The event handler
uses this data to add the vehicle location to the vector layer.
Figure 11: WS sequence diagram
The sequence of the actions is shown in Figure 11. The sequence and the process
are similar to the SSE sequence. In the case of WS a WS URL is used instead of SSE URL

51
and a WebSocket object is created instead of an eventsource object
Measurement and logging
For analysis purposes after each visualization with different technologies, data for
analysis is captured such as:
 Distance between subsequent locations
 Time delay in visualization
 Number of locations received, duplicate locations, skipped locations
 Data transfer details
Figure 12: Sample log for distance and delay
Different techniques are used to capture these identified measurements. The
distance between subsequent vehicle locations and lag in visualization is retrieved from the
log generated through log4javascript in a browser console as shown in Figure 12.

52
Figure 13: Filtering GeoServer traffic in Fiddler
Figure 13 shows configuring a filter is to view only the traffic of GeoServer in filters
tab. The bandwidth usage information is retrieved from Fiddler.
Data publishing and visualization
With the GeoServer customized to needs of study like reading GPX files, simulating
and publishing vehicle location data in different technologies such as AJAX, SSE and WS.
In addition, web application built to consume the vehicle location data from the web server
for visualizations. The visualization is now performed in all the three pages of web
application and data is collected for analysis.
To study visualization better the previous vehicle locations are not removed or cleared
from the map. The vehicle location data is visualized in AJAX with three different polling
intervals. Since the web server and browser are running on the same machine, the larger
polling intervals does not show significant variations of results. For this reason AJAX with
three polling intervals of lower values 2s, 5s and 10s are used.
Since the SSE and WS are push-based technologies from the server, only one trial is

53
sufficient for the visualization.
Results
The five visualization trials are conducted and the results consisting map screen shot
in the browser window, logging data in the browser console, and the bandwidth information
from the Fiddler application, are all collected and documented in this section.
Asynchronous JavaScript + XML with 2s polling interval
The AJAX with 2 seconds polling interval is performed and the results are as follows.
Map 5: Visualization with AJAX – 2 seconds interval
Map 5 shows the vehicle locations to be close to each other. The different vehicle
routes are rendered in different colors and the legend is provided for reference. The
visualization at this polling interval looks decent on the map covering the routes with
sufficient points. There is very little to no visible gaps in between adjacent vehicle location
points on the roads.

54
Figure 14: Data usage information in Fiddler for AJAX
In Figure 14, the bandwidth statistics are found for 15 AJAX requests. The request
count, sums of header and body data sizes of requests and responses are also available.
The icon and response content shows requests are of “application/json” type. Similarly, the
statistics for the entire requests trial is collected and summarized.
Figure 15: AJAX 2 seconds distance histogram
The Figure 15, the significant values to observe is 700 duplicate vehicle location
points are received and maximum count of is in range of 21 to 24m. Since minimum
distance configured in GPS logger is 3m, other values fall in range of 3 to 36m.

55
Figure 16: AJAX 2 seconds visualization latency histogram
In Figure 16, 0ms values are for the duplicate vehicle locations received for
visualization. Significant values to observe here is maximum vehicle location data are
visualized at 600 to 800ms and then 400 to 600ms.
It is found in the log that vehicle locations received are 1820, out of which 678 are
duplicate and 1142 are visualized, resulting in 1152 skipped locations.

56
Map 6 shows the vehicle locations to be away from each other, than in 2 seconds
polling interval. The visualization at this polling interval looks satisfactory on the map
covering the routes with sufficient points and visible gaps in between adjacent vehicle
location points on the roads.
The Figure 17, significant values to observe is 250 duplicate vehicle location points
are received and maximum count of is in range of 52 to 56m.
In Figure 18, the significant values to observe here is maximum vehicle location data
are visualized at 800 to 1000ms. It is found in the log that vehicle locations received are
728, out of which 253 are duplicate and 475 are visualized, resulting in 1819 skipped
locations.

57
Map 7 shows the vehicle locations to be away from each other, than in 5 seconds
polling time. The visualization at this polling interval is starting to look difficult to follow the
route of the vehicle since there are larger gaps between adjacent visualized locations. The
vehicle turns does not seems be visualized because of this larger gap.
The Figure 19, the significant values to observe is more than 100 duplicate vehicle
location points are received and maximum count of is in range of 80 to 90m and 100 to
110m.

58
In Figure 20, 0ms values are for the duplicate vehicle locations received for
visualization. Significant values to observe here is maximum vehicle location data are
visualized at 500 to 1000ms.
It is found in the log that vehicle locations received are 364, out of which 120 are
duplicate and 244 are visualized, resulting in 2050 skipped locations.
Server Sent Events

59
Map 8: Visualization with Server Sent Events
Map 8 shows the vehicle locations to be very close to each other, than in any of the
three AJAX polling trials. The visualization using SSE looks of very good quality clearly
showing the vehicle routes.
Figure 21: SSE distance histogram
The Figure 21, the significant values to observe are maximum count of vehicle
visualization of is in range of 11 to 12m and 12 to 13m.
Figure 22: SSE visualization latency histogram
In Figure 22, there are no duplicate vehicle locations received for visualization.
Significant values to observe here is maximum vehicle location data are visualized at 50 to
100ms. It is found in the log that vehicle locations received are all of 2294, out of which
there are no duplicates and all them are visualized, resulting in no skipped locations.

60
Figure 23: Data usage information in Fiddler for SSE
In Figure 23, the bandwidth statistics are found for a SSE request. The simulation is
stopped after few locations. The request count is one, header and body data sizes of
requests and responses are also available. The icon and response content type shows that
request is of text/event-stream type.

61
WebSocket
Map 9: Visualization with WebSocket
Map 9 shows the vehicle locations visualization similar to the SSE visualization.
Figure 24: WS distance histogram
The Figure 24: WS distance histogram, the significant values to observe are maximum
count of vehicle visualization of is in range of 11 to 12m and 12 to 13m, similar to the SSE
distance histogram.

62
Figure 25: WS visualization latency histogram
In Figure 25, there are no duplicate vehicle locations received for visualization.
Significant values to observe here is maximum vehicle location data are visualized at 50 to
100ms, similar to the SSE latency histogram. Observing the log, the details are similar to
SSE with all vehicle locations received and visualized without any duplicate or skipped
locations.
Figure 26: Data usage information in Fiddler for WS
In Figure 26 the bandwidth statistics are found for a WS request. The simulation is

63
stopped after few locations. The request count is one, header data size of requests and
responses are available. The data updates sent through are shown in Tunnel sent and
Tunnel received. The icon and description in statistics shows that request is of WebSocket
type.
Analysis
The analysis is performed broadly in four different sections as follows.
 Distance between subsequent vehicle locations
 Latency in visualization
 Duplicate and skipped vehicle Location data
 Bandwidth usage efficiency
For some of the above analysis there needs to be more data derived from the
captured data for better understand of phenomena. The data captured during visualization
are in terms of the delay in visualization, points skipped during visualization and bandwidth
utilization.
To support in analysis the following data is derived from captured data and both are
tabulated in tables from Table 9 to Table 12.
 Summary of distance between subsequent locations
 Summary of time delay in visualization
 Count of vehicle locations received, duplicates received, skipped, visualized.
 Data exchange details between web server and browser
Distance between subsequent vehicle locations
First result to analyze is the distance between subsequent vehicle locations visualized
by different technologies. This analysis shows how closely the moving vehicle is being
visualized. The closer the adjacent vehicle locations, the better visualization. The measure

64
of this closeness is the achieved by analyzing the distance between subsequent vehicle
locations.
The data for this analysis is summarized from the logging in the browser console. The
resulting data is summarized with mean, median, minimum, maximum and total values. The
Table 9 shows the statistics generated for the values of distance subsequent vehicle
locations visualized for all the five trials.
Table 9: Distance between subsequent locations (in meter)
Ajax
(2 sec)
Ajax
(5 sec)
Ajax
(10 sec)
SSE WS
1 Maximum 34.9 87.3 165.2 17.7 17.7
2 Minimum 0.0 0.0 0.0 0.0 0.0
3 Median 14.4 35.4 76.0 10.3 10.3
4 Mean 12.4 31.0 61.8 9.9 9.9
5 Total 22,623.3 22,573.8 22,484.1 22,644.7 22,644.7
From the overview of the table, it is observed that the values (the mean, median and
maximum) resulting in SSE and WS is lesser than Ajax. The AJAX with 2 seconds polling
interval results comes closer to the results of SSE and WS.
In detail, it is observed that in case of AJAX as the polling interval is increased, mean
and median distance between subsequent vehicle locations is increasing. This means the
vehicle has moved further away from the last visualized location before being visualized
again. The lesser mean and median values of SSE and WS produces a visualization, which
shows the moving vehicle at smaller distances on map. The user might have to wait for a
longer period in case of AJAX to visualize any movement than in case of SSE and WS.
In addition, total distance in this table shows the distance travelled by vehicles. Since
total distance values is reducing gradually, as the AJAX polling interval is increased, it
suggests that the entire vehicle routes are not visualized. This shows that the intermediate
vehicle locations that are not visualized are being skipped in AJAX. Few vehicle locations
where the vehicles are making turns are not visualized and those locations are ignored, so
the total distance is being reduced in the logging. Whereas in SSE and WS results, the

65
total distance is highest among all visualizations, suggesting that all the vehicle locations
are visualized on the entire routes.
When the SSE and WS results are compared, there is not much to choose from in
terms of how closer they visualize the vehicle movement.
The histograms for the distance values are generated for each dataset and shown in
Figure 15, Figure 17, Figure 19, Figure 21 and Figure 24. It is found in histograms that
AJAX methodology has many occurrences of zero distances, showing many locations being
duplicates for visualization. In case of histograms of SSE and WS, the distribution seems
uniformly raising and decreasing from 0m to 18m.
Comparing the resulting statistics and the histogram of the distance between
subsequent vehicle locations for all the 5 trials, it is found that the SSE and WS has a clear
advantage in terms of how closer vehicle locations are visualized to the user. AJAX with a
lower polling interval can come closer to the results of SSE and WS to an extent, but its
drawback is lots of duplicates and skipped records.
Latency in visualization
Next result to analyze is the latency between vehicle location capture time and the
visualization time experienced in different technologies. This analysis shows how quickly
the moving vehicle is being visualized once it is captured in the system. The smaller the
time duration of latency, the better visualization. The measure of this quickness is the
achieved by analyzing the time difference between vehicle location capture time and its
visualization time.
The data for this analysis is summarized from the logging in the browser console. The
resulting data is summarized with mean, median, minimum, maximum and total values. The
Table 10 shows statistics generated for the values of visualization latencies of vehicle
locations for all the five trials.
From the overview of the table it is observed, that the values (the mean, median and
maximum) resulting in SSE and WS is lesser than AJAX trials. The closest of AJAX trial

66
being with 2 seconds poll interval still more than double the values of the SSE and WS.
This can be seen in Table 10.
Table 10: Visualization Latency (in milliseconds)
Ajax
(2 sec)
Ajax
(5 sec)
Ajax
(10 sec)
SSE WS
1 Maximum 1,998.0 4,597.0 9,719.0 766.0 628.0
2 Minimum 0.0 0.0 0.0 2.0 8.0
3 Median 578.0 356.5 707.5 165.0 139.5
4 Mean 393.7 450.9 771.4 184.2 156.3
5 Total 716,494.0 328,255.0 280,800.0 422,531.0 358,477.0
In detail, it is observed that in case of AJAX that polling interval is not directly causing
changes in mean and median latency values, but has effect of direct proportionality on the
maximum latency values. This means the vehicle visualization time does not depends on
the AJAX polling interval. This is because the vehicle location data capture can occur
immediately after the polling or just before the polling. Nevertheless, as the AJAX polling
interval is increased few vehicle locations take more time to visualization. In case of SSE
and WS, mean, median and maximum visualization latencies are least, than all three values
of AJAX trials. This is because once the vehicle location data is captured it is immediately
pushed to the browser for visualization, resulting in minimal visualization latency. This
means the user can view the vehicle locations being visualized quicker in SSE than all than
the different AJAX trials. When comparing the SSE and WS values it is clear that the WS
sockets is taking less time to visualize than the SSE.
In addition, total latency values describes the amount of time spent in visualizing the
vehicle locations. It is found in the table that the visualizing time varies between the AJAX
trials, without any significant performance improvement any trials.
The histograms for latency values are generated for each dataset and is shown in
Figure 16, Figure 18, Figure 20, Figure 22 and Figure 25. It is found in histograms that
AJAX methodology has random variations in terms of visualization latencies. In case of
SSE and WS histograms, it clearly shows more values being visualized at lower latencies

67
in WS than in SSE.
Comparing the resulting statistics and the histogram of the latency between vehicle
location data capture time and its visualization time for all the 5 trials, it is found that the WS
and SSE has a clear advantage in terms of how quicker vehicle locations are visualized to
the user. Between WS and SSE, the WS has the advantage being 20% faster than SSE.
In AJAX, the decrease in polling interval allows the possibility of decrease in vehicle location
visualization latency, since this is also dependent on the relative timing of the location
capture.
Duplicate and skipped Vehicle location data
Vehicle location data with duplicate and skipped locations are the next one to be
analyzed. This analysis shows how many vehicles locations are visualized on the browser
during vehicle tracking. The vehicle location count visualized varies with the traditional and
new technologies. The more number of vehicle locations visualized, the more information
user can derive. This measure of this count achieved by analyzing the number of vehicle
locations captured and received for visualization.
The data for this analysis is summarized from the logging in the browser console and
counting the vehicle locations in the GPX files. The resulting data is summarized with
captured locations, locations received for visualization, duplicates in received locations,
locations visualized and locations not received. The Table 11 shows this summarized data.
Table 11: Vehicle location count
Ajax
(2 sec)
Ajax
(5 sec)
Ajax
(10 sec)
SSE WS
1 Captured locations 2,294 2,294 2,294 2,294 2,294
2 Received locations 1,820 728 364 2,294 2,294
3 Duplicate locations received 678 253 120 0 0
4 Locations visualized 1,142 475 244 2,294 2,294
5 Skipped locations 1,152 1,819 2,050 0 0
From the overview of the table, it is observed that the as the AJAX polling interval is

68
increased, the values for received vehicle locations, duplicate vehicle locations received
and locations visualized is decreasing. In case of SSE and WS there are no duplicate
locations are skipped locations.
To analyze in detail, a stacked column chart shown in Figure 27 is created to depict
visualized and skipped vehicle locations. The location count visualized is decreasing and
skipped location count is increasing in case of increase in AJAX polling interval. This means
that the user will see less vehicle location data on the browser in case of higher AJAX polling
interval. This also means the entire vehicle location data is not visualized resulting in
underutilization of the captured location data. In case of SSE and WS, the entire captured
vehicle location data is visualized by the user and has complete picture of the vehicle
movement as captured.
Figure 27: Locations visualized vs Skipped Locations

69
Figure 28: Received locations vs duplicate locations
Additionally, in Figure 28 received vehicle location count and duplicate location
received count is shown. As the AJAX polling interval is increased the received locations
is decreasing and proportionately duplicate location count is decreasing. This means that
less and less vehicle locations would be visualized for the user when the AJAX polling
interval is increased. There also a proportionate quantity of duplicate vehicle locations
received which is waste of bandwidth. Since in AJAX technique, the browser is unaware of
the availability of new vehicle location data, few requests results in duplicate location data
being received. In case of SSE and WS there are no duplicates received, since they are
push based model and send only new vehicle location data.
Comparing the resulting summary and the graphs, for the vehicle location counts, it
is found that the SSE and WS has a clear advantage, since there are no location data
skipped or duplicate data received. AJAX with a lower polling interval provides closer
results to SSE and WS in terms of locations received for visualization, but involves
drawback of proportionate quantity of duplicate data. Between the SSE and WS there is
nothing much to differentiate in terms of duplicate and skipped locations.
Bandwidth usage efficiency
Finally, the bandwidth usage is analyzed for the visualization of vehicle location data.

Master Thesis Web Tech Comparison

Master Thesis Web Tech Comparison

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Master Thesis Web Tech Comparison

Ähnlich wie Master Thesis Web Tech Comparison (20)

Master Thesis Web Tech Comparison