Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Master Thesis
submitted within the UNIGIS MSc. programme
at the Department of Geoinformatics - Z_GIS
University of Salzbur...
2
Science Pledge
By my signature below, I certify that my thesis report is entirely the result of my own
work. I have cite...
3
Acknowledgements:
This thesis study was completed successfully largely due to the effort of a number of
people who have ...
4
Abstract
Vehicle tracking system with the components such as automatic vehicle location and
software publishes fleet loc...
5
Table of Contents
Contents
Science Pledge..................................................................................
6
Hyper Text Transfer Protocol traffic Inspection.................................................33
Logging and summarizi...
7
Future work areas .....................................................................................................7...
8
Figure 15: AJAX 2 seconds distance histogram................................................................54
Figure 16...
9
Chapter 1: Introduction
Background
Vehicle tracking system
Vehicle tracking system captures stores and visualizes the ve...
10
Few countries are also building satellite navigation systems that covers their particular
country and their surrounding...
11
receiving the location data from the tracking device, storing the received data in an efficient
way and servicing / pub...
12
Vehicle tracking Classification
The vehicle tracking is classified as two types, Active and Passive based on the when
t...
13
Factors affecting visualization
The real time nature of the visualization depends on various factors such as latency
(b...
14
affected in the following ways.
1) Lag in vehicle location display, on the map: The individual vehicle locations are
ca...
15
and response was not necessary.
Motivation
The HTML5 has introduced new technologies for data transfer between web serv...
16
technology where the connection is kept alive and open for streaming data to be received
in future. WebSocket upgrade t...
17
Aims
The aims of this study are as follows:
 Understand the new web technologies available for data transfer over web....
18
browser for visualization.
 Find the time delay between the vehicle location capture in web server and its
visualizati...
19
Chapter 2: Methodology
The methodology, data formats, software and technologies used in this study is
described in this...
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...
22
software is customized to perform this functionality of capturing the vehicle location data. A
PostgreSQL database is d...
23
URL in case of SSE and WS.
Sample GetFeature request is shown below:
http://example.com/wfs?service=WFSSIMPLE&version=0...
24
Server Sent Events
Server sent events is a technology where the browser receives automatic updates
from the server thro...
25
and subscription of event handler.
GET
http://localhost:8080/geoserver/eventsource?type=tracking:vehicl
eposition
HTTP/...
26
client then subscribes to an event on the WebSocket to receive data from the web server.
The web server sends the data ...
27
with minimal configuration settings such as GeoServer and location data logging. Few were
customized to implement new f...
28
tablet. This application has UI to view the current location coordinates, elevation, duration,
distance travelled, spee...
29
<time>2014-09-15T01:06:28Z </time>
<trk>
<trkseg>
<trkpt lat="12.92835063637114" lon="77.60044786027773">
<ele>816.3553...
30
Table 2: Database schema
Column Name Data type
VEHICLEID Text
THE_GEOG Geography(Point, 4326)
CAPTURETIME Timestamp
Thi...
31
INSERT INTO VEHICLEPOSITION
(THE_GEOG, VEHICLEID, CAPTURETIME)
VALUES
(ST_GeographyFromText(
'SRID=4326;POINT(Longitude...
32
such as connection, creating database, creating tables and verifying the stored data.
Data publishing
GeoServer an open...
33
new extent values fetch the vehicle location data of the map extent.
Hyper Text Transfer Protocol traffic Inspection
Da...
34
Base Map
There are multiple options for base map selection such as Google Maps, Bing Maps,
and OpenStreetMap. For this ...
35
possible with minimum 3 meter for distance filter. This setting ensures that the minimum
distance between subsequent lo...
36
to perform under different temperature range because it is outdoors. They also sustain
vibrations during vehicle moveme...
37
Table 5: System configuration (hardware) used for tracking server and user interface
System Type 64 bit
Processor Intel...
38
Chapter 3: Processes and Results
Software architecture
The software is configured and new functionality required is imp...
39
build, debugging, testing purposes.
The SSE and WS required additional libraries components of jetty than that is used
...
40
These formats are configured to return data in GeoJSON format. Additionally the formats
related to new technologies SSE...
41
tputFormat=LiveAjax&action=play
The URL to stop the GPS simulator is shown below:
http://localhost:8080/geoserver/track...
42
QName typeName = (QName) query.getTypeName().get(0);
workspace = typeName.getNamespaceURI();
layerName = typeName.getLo...
43
return eventSource;
When new vehicle location is simulated by the GPS simulator, the following code on
the web server s...
44
getFeature.getParameters()[0];
String baseurl = request.getBaseUrl();
for (QueryType query : (EList<QueryType>) request...
45
Simulator simulator = SimulatorBuilder.getInstance();
simulator.setPublisher(eventSender);
Tivo.TivoAction("play");
Whe...
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 fo...
47
…… // more instances of features (total 14 features)
],"crs":{"type":"EPSG","properties":{"code":"4326"}}})
This respon...
48
URL for the vector layer is shown below.
http://localhost:8080/geoserver/tracking_ws/ows?service=WFS&versio
n=1.0.0&req...
49
Figure 10: SSE sequence diagram
The sequence of the actions is shown in Figure 10. The initial steps are similar to the...
50
a WebSocket object is created and message event is subscribed for receiving new vehicle
location updates. Code for play...
51
and a WebSocket object is created instead of an eventsource object
Measurement and logging
For analysis purposes after ...
52
Figure 13: Filtering GeoServer traffic in Fiddler
Figure 13 shows configuring a filter is to view only the traffic of G...
53
sufficient for the visualization.
Results
The five visualization trials are conducted and the results consisting map sc...
54
Figure 14: Data usage information in Fiddler for AJAX
In Figure 14, the bandwidth statistics are found for 15 AJAX requ...
55
Figure 16: AJAX 2 seconds visualization latency histogram
In Figure 16, 0ms values are for the duplicate vehicle locati...
56
Map 6 shows the vehicle locations to be away from each other, than in 2 seconds
polling interval. The visualization at ...
57
Asynchronous JavaScript + XML with 10s polling interval
Map 7: Visualization with AJAX – 10 seconds interval
Map 7 show...
58
Figure 20: AJAX 10 seconds visualization latency histogram
In Figure 20, 0ms values are for the duplicate vehicle locat...
59
Map 8: Visualization with Server Sent Events
Map 8 shows the vehicle locations to be very close to each other, than in ...
60
Figure 23: Data usage information in Fiddler for SSE
In Figure 23, the bandwidth statistics are found for a SSE request...
61
WebSocket
Map 9: Visualization with WebSocket
Map 9 shows the vehicle locations visualization similar to the SSE visual...
62
Figure 25: WS visualization latency histogram
In Figure 25, there are no duplicate vehicle locations received for visua...
63
stopped after few locations. The request count is one, header data size of requests and
responses are available. The da...
64
of this closeness is the achieved by analyzing the distance between subsequent vehicle
locations.
The data for this ana...
65
total distance is highest among all visualizations, suggesting that all the vehicle locations
are visualized on the ent...
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.
T...
67
in WS than in SSE.
Comparing the resulting statistics and the histogram of the latency between vehicle
location data ca...
68
increased, the values for received vehicle locations, duplicate vehicle locations received
and locations visualized is ...
69
Figure 28: Received locations vs duplicate locations
Additionally, in Figure 28 received vehicle location count and dup...
Gopi_Master_Thesis
Gopi_Master_Thesis
Gopi_Master_Thesis
Gopi_Master_Thesis
Gopi_Master_Thesis
Gopi_Master_Thesis
Gopi_Master_Thesis
Gopi_Master_Thesis
Gopi_Master_Thesis
Upcoming SlideShare
Loading in …5
×

Gopi_Master_Thesis

148 views

Published on

  • Be the first to comment

  • Be the first to like this

Gopi_Master_Thesis

  1. 1. 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. 2. 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. 3. 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. 4. 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. 5. 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. 6. 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 Asynchronous JavaScript + XML ......................................................................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 Server Sent Events ...........................................................................................58 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 Asynchronous JavaScript + XML ......................................................................73 Server Sent Events ...........................................................................................73 WebSocket........................................................................................................73 Chapter 4: Conclusions .....................................................................................................74
  7. 7. 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. 8. 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. 9. 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. 10. 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. 11. 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. 12. 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. 13. 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. 14. 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. 15. 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. 16. 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. 17. 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. 18. 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. 19. 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. 20. 20 Map 2: India map highlighting location of Bangalore city. Map 3: Study area - Jayanagar locality, Bangalore, India
  21. 21. 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. 22. 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. 23. 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. 24. 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. 25. 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. 26. 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. 27. 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. 28. 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. 29. 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. 30. 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. 31. 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. 32. 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. 33. 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. 34. 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. 35. 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. 36. 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. 37. 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. 38. 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. 39. 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. 40. 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. 41. 41 tputFormat=LiveAjax&action=play The URL to stop 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 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: http://localhost:8080/geoserver/tracking_ws/ows?service=WFS&versio 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. 42. 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. 43. 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: http://localhost:8080/geoserver/tracking_ws/ows?service=WFS&versio n=1.0.0&request=GetFeature&typename=tracking_ws:vehicleposition&ou 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. 44. 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. 45. 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. 46. 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: http://localhost:8080/geoserver/tracking_ws/ows?service=WFS&versio n=1.0.0&request=GetFeature&typename=tracking_ws:vehicleposition&ou 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. 47. 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. 48. 48 URL for the vector layer is shown below. http://localhost:8080/geoserver/tracking_ws/ows?service=WFS&versio n=1.0.0&request=GetFeature&typename=tracking_ws:vehicleposition&ou 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: $('#play').click(function(){ 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. 49. 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. http://localhost:8080/geoserver/tracking_ws/ows?service=WFS&versio n=1.0.0&request=GetFeature&typename=tracking_ws:vehicleposition&ou 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. 50. 50 a WebSocket object is created and message event is subscribed for receiving new vehicle location updates. Code for play button click: $('#play').click(function(){ 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. 51. 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. 52. 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. 53. 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. 54. 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. 55. 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. Asynchronous JavaScript + XML with 5s polling interval Map 6: Visualization with AJAX – 5 seconds interval
  56. 56. 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. Figure 17: AJAX 5 seconds distance histogram 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. Figure 18: AJAX 5 seconds visualization latency histogram 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. 57. 57 Asynchronous JavaScript + XML with 10s polling interval Map 7: Visualization with AJAX – 10 seconds interval 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. Figure 19: AJAX 10 seconds distance histogram 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. 58. 58 Figure 20: AJAX 10 seconds visualization latency histogram 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. 59. 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. 60. 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. 61. 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. 62. 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. 63. 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. 64. 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. 65. 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. 66. 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. 67. 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. 68. 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. 69. 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.

×