Dash Sylvereye: A WebGL-powered

Library for Dashboard-driven

Visualization of Large Street Networks
ALBERTO GARCIA-ROBLEDO1 , MAHBOOBEH ZANGIABADY2
1
Conahcyt, CentroGeo, Querétaro, México (e-mail: [email protected])
2
University of Twente, Enschede, the Netherlands (e-mail: [email protected])
Corresponding author: Alberto Garcia-Robledo (e-mail: [email protected]).
arXiv:2105.14362v2 [cs.HC] 30 Sep 2023

ABSTRACT State-of-the-art open network visualization tools like Gephi, KeyLines, and Cytoscape are
not suitable for studying street networks with thousands of roads since they do not support simultaneously
polylines for edges, navigable maps, GPU-accelerated rendering, interactivity, and the means for visualizing
multivariate data. To fill this gap, the present paper presents Dash Sylvereye: a new Python library to produce
interactive visualizations of primal street networks on top of tiled web maps. Thanks to its integration
with the Dash framework, Dash Sylvereye can be used to develop web dashboards around temporal and
multivariate street data by coordinating the various elements of a Dash Sylvereye visualization with other
plotting and UI components provided by the Dash framework. Additionally, Dash Sylvereye provides
convenient functions to easily import OpenStreetMap street topologies obtained with the OSMnx library.
Moreover, Dash Sylvereye uses WebGL for GPU-accelerated rendering when redrawing the road network.
We conduct experiments to assess the performance of Dash Sylvereye on a commodity computer when
exploiting software acceleration in terms of frames per second, CPU time, and frame duration. We show
that Dash Sylvereye can offer fast panning speeds, close to 60 FPS, and CPU times below 20 ms, for street
networks with thousands of edges, and above 24 FPS, and CPU times below 40 ms, for networks with
dozens of thousands of edges. Additionally, we conduct a performance comparison against two state-of-
the-art street visualization tools. We found Dash Sylvereye to be competitive when compared to the state-
of-the-art visualization libraries Kepler.gl and city-roads. Finally, we describe a web dashboard application
that exploits Dash Sylvereye for the analysis of a SUMO vehicle traffic simulation.

INDEX TERMS Data visualization, data analysis, software libraries, component architectures, complex
networks, graphical user interfaces, graphics, vehicle dynamics

NE of the primary objects of interest of urban re- and other urban data change over time. Dashboards have
O searchers and planners are street networks. They study
street networks for a variety of applications such as traffic
become a standard visual analytics tool when trying to make
sense of multivariate data. Prominent dashboard tools in
engineering, transportation, and urban planning. Recently, the industry include Tableau [3] and Google Data Studio1 .
academics from seemingly unrelated fields, such as Networks However, these kinds of open tools are too general to support
Science and Computer Science, have joined to study the the practical analytical needs of real-world urban applications
complexity of large street networks and develop efficient [26].
algorithms to process them. On the other hand, the street network of large cities is made
With the advent of the OpenStreetMap (OSM) project [11] of dozens of thousands of nodes and edges. This imposes the
the street topology of virtually any city in the world became need to push the processing capabilities of graphics adapters
publicly available for analysis. Tools like OSMnx [5], [6] to render such large structures. These complex visualizations
make it easy for any researcher to download OSM street should also allow for user interactivity by enabling naviga-
network data with a simple query. However, the availability tion, panning, zooming, and clicking.
of such networks has also revealed the limitations of current The use of web technologies for developing visualization
tools like graph visualization. solutions is currently a tendency among practitioners. Open-
Urban researchers need tools to make sense of multivariate source programming libraries like the Dash framework en-
data associated with street networks. These data are hardly
static: vehicle counts, vehicle positions, traffic bottlenecks, 1 https://datastudio.google.com/

1
able data analysts to develop their own rich and interactive per second, frame duration, and CPU time. In Section VI we
web dashboards by exploiting a variety of coordinated web present a comparison of the animation performance among
plotting and UI components. Such dashboards can be dis- Dash Sylvereye and other two state-of-the-art road network
played in any modern web browser and be easily deployed visualization libraries. In Section VII we describe a non-
on the web. trivial example of a dashboard that uses Dash Sylvereye as
State-of-the-art graph visualization tools like Gephi, Key- its central component. Finally, in Section VIII we offer final
Lines, and Cytoscape are not suitable for studying city-scale conclusions and future work.
street networks since they do not support simultaneously
polyline2 drawing for edges, navigable maps, interactiv- I. BACKGROUND
ity, the means for visualizing multivariate data, and GPU- A. STREET NETWORKS
accelerated rendering. This paper is concerned with primal street graphs. A pri-
In this context, the research question we tackle is: how mal street graph is a non-planar directed multi-graph with
to fill this gap and exploit state-of-the-art visual analytics loops allowed where nodes represent street intersections or
techniques and web technologies to produce interactive vi- junctions, and edges represent street segments [6]. A street
sualizations of street networks on a city scale, along with its network is a kind of spatial network [1]: a graph that models
multivariate data, making this technology easily available to natural, sociological, or technological phenomena where the
researchers and practitioners alike? elements of the graph are mapped to the spatial dimension,
To answer the posed question, this paper presents a new usually to geographical coordinates. Urban networks have
Python library called Dash Sylvereye which produces inter- become the focus of many works in recent years. An example
active visualizations of primal street networks on top of tiled of such works is [14], which makes use of a new model for
web maps. Thanks to its integration with the Dash frame- analyzing urban network structures, combining them with the
work, Dash Sylvereye can be easily exploited to develop information provided by taxi trajectory data.
web dashboards around temporal and multivariate urban data
by coordinating the various elements of a Dash Sylvereye B. WEB-BASED VISUALIZATION
visualization with other Dash plotting and UI components. The wide availability of web browsers has turned them into
Dash Sylvereye can render large city-scale interactive an all-pervasive execution platform. Recently, an increasing
street networks as well as thousands of interactive markers number of web-based visualization applications have been
in commodity computers with the help of the system’s GPU proposed motivated by the new technologies offered by mod-
through WebGL. ern browsers [19]. The HTML5 standard gives programmers
The core contributions of this paper are as follows: an array of options to render graphics: the HTML canvas,
• A library tool for Python that generates street network SVG graphics, CSS animations, and WebGL. WebGL is a
visualizations that can draw atop web tile maps and that standardized JavaScript API for rendering GPU-accelerated
is designed from the ground up to be compatible with graphics in web browsers. A WebGL application consists
the widely used Dash dashboard visualization frame- of two parts: control code written in JavaScript and shader
work. code written in the GLSL language. WebGL has particularly
• A library tool that allows for the customization of attracted the interest of the data visualization community
colors, sizes, transparency, and visibility of individual since it allows programmers to exploit the GPU processor
street network elements as well as markers. Visual prop- regardless of the vendor.
erties can be also automatically scaled based on the A good example of a work that exploits state-of-the-art
values found in the street network’s data. web visualization technologies for graph analysis is Con-
• A library tool that provides fast software acceleration traNA. ContraNA [8] is a visual analytics framework that
and exploits hardware acceleration for redrawing, show- exploits machine learning to compare two networks for
ing panning speeds of close to 60 FPS, and CPU times learning the main specifications of one network with respect
below 20 ms, for street networks with thousands of to the other. Such comparison is challenging due to the
edges. complex structure of large graphs. The authors developed
The rest of this paper is structured as follows. Section I ContraNA as a web application. The back-end is developed in
provides additional background on topics that are relevant to Python whereas the front-end uses a combination of HTML5,
the proposed solution. Section II offers a review of the state- JavaScript, D3.js, and WebGL. WebSockets are used for
of-the-art on street graph visualization. Section III lists the back-end and front-end communication. Examples of works
requirements we identified were needed to meet and presents that exploit WebGL to produce visualizations of large graphs
details on the internal design of the Dash Sylvereye library. include [7], [12], [17], [22].
Section IV offers the reader a quick grasp of how coding with JavaScript has become the lingua franca for front-end web
the Dash Sylvereye library feels. In Section V we assess the development. There already exists a mature ecosystem of
animation performance of Dash Sylvereye in terms of frames open-source JavaScript libraries which are being exploited
for data visualization. Prominent examples of such libraries
2A sequence of connected segments that describe a curve. are D3.js and Three.js. More recently, WebAssembly has en-
2
abled developers to write high-performance code that rivals parameter at the moment the callback is triggered by another
in speed with native applications written in C and C++. This input parameter.
technology opens new possibilities for efficiently running
compute-intensive algorithms in the browser, such as graph II. RELATED WORK
layout algorithms. Many graph visualization tools have been developed over
the last few years to generate graph visualizations. In con-
C. DASHBOARD VISUALIZATION sequence, the landscape of such tools has become extensive.
Dashboards are one of the most common use cases for data We focus our state-of-the-art review on both open tools5 and
visualization [21]. Interest in developing web dashboards academic works that propose practical contributions with any
has recently increased in governments, universities, research of the two following features: 1) support for the development
centers, and health institutions due to the need of sharing real- of visualization dashboards around the reported tool, 2) some
time information about the state of the COVID-19 pandemic sort of geospatial visualization support, such as the ability to
in an open and accessible manner. render graphs on top of maps, and 3) rendering of large road
networks. We discuss in detail tools that provide any kind of
In urban studies, dashboards are being used to visualize
dashboard support in Section II-C.
real-time urban data from a variety of sources to provide an
easy-to-understand tool to decision-makers [9]. Dashboards
can be used to visually assess urban performance to support A. TOOLS IN LITERATURE
the sustainable development of smart cities [15], and for The following are works in the academic literature that report
transparent and accountable decision-making [18]. A good graph visualization libraries for a variety of programming
example of a work that exploits dashboards for city analytics languages. We focus our review on tools that can render large
purposes is [20], which proposes a dashboard-driven visual road networks (through GPU hardware acceleration).
tool for analyzing traffic accident and casualty trends. ccNetViz [22] is an open-source WebGL-based JavaScript
Python is one of the most-used languages among develop- library for network visualization. It supports animation fea-
ers who identify themselves as data scientists [13]. There is tures (nodes and links). Node colors, size, and transparency
a relatively new ecosystem of frameworks that are attracting can be manipulated in real-time. Similarly, the animation
the attention of data science practitioners in need of develop- of edges can be used to display information transmission.
ing web dashboard applications entirely in Python, without Animation features can be specified dynamically.
the need of learning front-end web languages like HTML, Carina [7] is a visualization tool that helps researchers to
CSS, and JavaScript. One such library is the Plotly Dash explore and visualize large graphs with millions of nodes.
framework3 . Carina supports fast graph drawing through WebGL and
The Dash framework is built around the concept of Dash supports both desktop (Electron) and mobile platforms. An
component. A Dash component is a Python class that pro- outstanding feature of Carina is it does not save the whole
vides an abstraction for a web UI element: from a single graph in RAM, enabling the tool to handle networks as big
HTML tag to more complex elements such as a slider, a chart, as 69 million edges.
a gauge meter, or a navigation bar. A Dash component has Authors in [12] developed a visualization tool for large
properties that can be set, read, and updated. Under the hood, graphs called NetV.js. It is a WebGL-based JavaScript library
Dash components are Python wrappers for components writ- that supports up to 50 thousand nodes and 1 million edges. It
ten with the widely-used React.js front-end UI framework4 . exploits the GPU to enhance the drawing performance and
This enables programmers to build their Dash components in create an interface for manipulating graph components.
JavaScript. Argo Lite [17] is an interactive network visualization tool
for web browsers. Users are enabled to modify the character-
Dash applications are composed of two parts. The first
istics of nodes (size, shape, colors), links (colors), and labels
part is the layout of the dashboard, which describes the
(size and length). It uses WebGL to draw graphs fast. Users
application’s appearance. It is specified as a tree of Dash
can import graph data from CSV, GEXF, and TSV files.
components. The second part is the callbacks, which defines
Authors in [23] developed a web-based application to
the interactivity of the application. Dash callbacks are Python
visualize detailed information of transportation networks for
functions that are automatically triggered when the properties
mobility analytics by exploiting reachability maps. It is pow-
of Dash components change.
ered by GLSL.
A callback receives the values of the changed properties as
Urban Network Analysis (UNA) [24] is a full-fledged
input and returns new values for other properties as output.
toolbox that can be used to visualize spatial networks, as
Every property of a Dash component can be updated through
well as computing network measurements. It is provided as
a callback. A special kind of input is the states: input param-
an extension for ArcGIS and Rhinoceros 3D. Support for
eters that do not trigger a callback, only store the state of a
GPU acceleration is not explicitly mentioned in the paper nor
3 https://plotly.com/dash/ 5 Tools that are publicly available as either open-source, free, or commer-
4 https://reactjs.org/ cial products.

3
TABLE 1. Feature comparison of state-of-the-art network visualization tools. To grant support for a given feature, it should be provided out-of-the-box or via
plug-ins/extensions. A N/A in the Language column means that the work is not a library but a web or desktop application. Notes: (1) Support of the feature is
granted only if the tool can draw polylines for edges. (2) OSMnx can generate static Web visualizations with Folium. (3) By using the TimestampedGeoJson Folium
plugin. (4) By using the Cytoscape.js library. (5) By using the Cytoscape.js Dash component. (6) A KeyLines visualization can be embedded in a Kibi dashboard. (7)
There is a Tableau extension for embedding Kepler.gl visualizations. (8) By combining the Dash component with, for example, a Dash slider component that
implements a timeline. (9) Since the tools are built on top of the Leaflet.js library, they may be able to display non-OSM tilemaps. (10) It supports OpenCL for
accelerating compute-intensive tasks such as graph layout calculation. Cytoscape.js is not powered by WebGL. (11) With Gephi Toolkit. (12) With Cytoscape.js. (13)
With PyGraphistry and GraphistryJS. (14) GPU acceleration is used for computing graph layouts. (15) It supports non-georeferenced polylines. (16) It supports
JavaScript if the standalone React component is used. However, dashboard framework integration (and by extension timeline support) will not be available. (17)
With graph-app-kit. (18) Support for GPU acceleration is mentioned neither in the paper nor webpage. Nonetheless, given that UNA is an extension, GPU
acceleration support could be provided through the base packages (ArcGIS and Rhinoceros 3D) which support OpenGL. (19 Python support is provided through
the keplergl module.

Rendering on GPU- Dashboard

Polyline Programmable Timeline
Tool Language top of a map accelerated framework
drawing (1) interactivity support
layer rendering integration
city-roads JavaScript Yes No WebGL No No No
OSM,
Folium Python Yes (2) Mapbox, No No Yes (3) No
Stamen (9)
Gephi Java (11) No No OpenGL No Yes No
OSMnx Python Yes OSM (2) No No No No
Cytoscape JavaScript (12) No No No (10) Yes (4) Yes (8) Yes (5)
KeyLines JavaScript No OSM (9) WebGL Yes Yes Yes (6)
Python,
Kepler.gl Yes Mapbox WebGL Yes Yes Yes (7)
JavaScript
Sigma.js JavaScript No No WebGL Yes No No
VivaGraphJS JavaScript No No WebGL Yes No No
Python,
Graphistry No No WebGL No Yes (17) Yes (17)
. JavaScript (13)
ReGraph JavaScript (19) No OSM (9) WebGL Yes Yes No
Ogma JavaScript No OSM (9) WebGL Yes Yes No
G6 JavaScript No (15) No No (14) Yes No No
yFiles JavaScript No (15) OSM (9) WebGL Yes Yes No
El Grapho JavaScript No No GLSL Yes No No
ngraph.pixel JavaScript No No GLSL Yes No No
react-force-
JavaScript No No WebGL Yes No No
graph
ccNetViz JavaScript No No WebGL Yes No No
Carina N/A No No WebGL No No No
NetV.js JavaScript No No WebGL Yes No No
Argo Lite N/A No No WebGL No No No
Schoedon et
N/A Yes Yes GLSL No No No
al. 2019
UNA N/A Yes Yes ? (18) No No No
D. Sylvereye Python (16) Yes OSM (9) WebGL Yes Yes (8) Yes

webpage. Nonetheless, given that UNA is an extension, GPU is built upon three widely used Python libraries, namely
acceleration support could be provided through ArcGIS or GeoPandas, NetworkX, and Matplotlib. It allows the user to
Rhinoceros 3D. extract street data from OSM for different transport modes
such as walking, cycling and driving with a single line of
B. OPEN TOOLS code. OSMnx can also visualize isochrone maps.
The following are tools that are made available openly Cytoscape [25] is an open-source graph visualization tool
through code repositories across the web. We limited our originally developed for biological network analysis. Cy-
review on programming libraries that are still active, that toscape provides visualization functions that make it easy for
show the aforementioned mentioned features, or with an researchers to interactively analyze complex graph datasets.
associated programming library. For the sake of comparison However, it doesn’t scale to high-volume graphs. Nonethe-
with the library reported in this paper, we gave priority to less, it supports offloading computationally intensive pro-
JavaScript and Python libraries, but we also covered the cessing on a GPU, multi-core CPU, or multi-processor card
widely-used Gephi tool, which is Java-based. by using OpenCL.
Folium6 is an open-source Python tool that allows users
to visualize data on an interactive Leaflet.js map. Users can Gephi [2] is an open-source visualization tool for users
zoom or click on the map to analyze the geo-referenced data. who seek to generate static visualizations of graphs. It is
OSMnx [5], [6] is an open-source Python library to easily a desktop application that supports a wide catalog of plug-
download, visualize, and analyze urban street networks. It ins. It is simple to use for beginners. Also, it makes it easy
to create CSV files from the network’s data. Graphs can be
6 https://github.com/python-visualization/folium exported to a variety of formats. It is powered by OpenGL.
4
Gephi provides the Gephi Toolkit7 , a standalone Java library ShaderMaterial from the Three.js 3D JavaScript library18 . It
that programmers can use to generate visualizations pro- supports both 2D and 3D graph rendering.
grammatically.
Anvaka’s city-roads8 is an open-source visualization web C. TOOLS WITH DASHBOARD SUPPORT
tool written in JavaScript that extracts data from OSM to The following are graph visualization tools that provide some
draw all the streets within a city. It is powered by WebGL. kind of integration with dashboard visualization frameworks.
Sigma.js9 is an open-source JavaScript library that sup- Cytoscape.js19 is a JavaScript library for visualizing and
ports HTML canvas and WebGL renderers for graph visu- interacting with graphs. It provides a rich set of features
alization, as well as mouse and touch support. Thanks to its and APIs for creating graph visualizations, performing graph
plug-in architecture, the library is extensible. It can import analysis, and implementing custom graph algorithms. Cy-
Gephi graphs in GEXF format. toscape.js allows the creation and manipulation of nodes and
VivaGraphJS10 is an open-source JavaScript library that edges, apply various layout algorithms, customizing visual
supports WebGL, Canvas, and SVG renderers for graph visu- styles, and the handling of user interactions. Cytoscape.js can
alization. It is built on top of the ngraph11 graph algorithms be integrated into Dash dashboards by exploiting the Dash
library. Cytoscape component20 . It does not provide WebGL support.
ReGraph12 is a commercial WebGL-powered React library KeyLines21 is a commercial JavaScript toolkit for visu-
for graph visualization by Cambridge Intelligence. It imple- alizing and interacting with network and graph data. It is
ments two visualization components: a chart and a time bar. powered by WebGL. Since it is neither free nor open-source,
It can render graphs on top of Leaflet.js web maps. Other users must purchase a license to use it. It supports events
geospatial features supported are geo-fencing, overlays, and to react to user actions such as mouse clicks and drag-
multiple coordinate reference systems. and-drop. Kibi, now known as Kibana, is an open-source
Ogma13 is a commercial graph visualization JavaScript data exploration and visualization platform primarily built
library by Linkurious. Ogma is powered by WebGL, but it for Elasticsearch. Kibana provides its own set of visualiza-
also supports HTML5, Canvas, and SVG renderers. Inserting tion components and plugins for creating dashboards and
a custom UI on top of Ogma is possible. Geographical mode exploring data. KeyLines visualizations can be integrated
allows the programmer to display the graph on top of a web into a Kibi dashboard by utilizing custom development and
map from different map providers. integration techniques. This may involve embedding Key-
G614 is a graph visualization JavaScript library. It supports Lines visualizations within Kibana’s dashboard panels or
drawing polylines for edges. However, it does not support incorporating KeyLines as a separate component within a
rendering graphs on top of maps. GPU acceleration is sup- Kibi dashboard.
ported for computing graph layouts. Kepler.gl is an open-source geospatial data visualization
El Grapho15 is an open-source JavaScript library for graph library. Kepler.gl has the ability to display millions of data
visualization that exploits GLSL shaders for quickly gener- points representing numerous trips and perform real-time
ating graph renderings of large graphs. The rendered graphs spatial aggregations by exploiting WebGL. By presenting
can be zoomed and panned. It supports multiple graph layout geospatial data within a unified interface, Kepler.gl enables
algorithms. Graph renderings in El Grapho are interactive. users to validate concepts and extract insights from these
visualizations. Users have the flexibility to visualize spatial
ngraph.pixel16 is an open-source JavaScript library by the
datasets with various map layers and explore the data through
creator of city-roads for visualizing non-road graphs. As city-
filtering, animation, and aggregation. The Kepler.gl Tableau
roads, ngraph.pixel is powered by WebGL. Unlike city-roads,
extension integrates a Kepler.gl map visualization directly
ngraph.pixel allows the programmer to listen to graph change
into the Tableau Desktop App, allowing users to interact with
events.
the map using the same user interface found in the Kepler.gl
react-force-graph17 is an open-source WebGL-powered demo app. Additionally, the map can be configured to interact
library for graph visualization. react-force-graph is imple- with other Tableau charts.
mented as a React library. Its graph renderer is based on
Graphistry is a commercial graph-based analysis tool. It
supports WebGL acceleration and provides a Python library
7 https://gephi.org/toolkit/ called PyGraphistry22 which acts as a client to extract,
8 https://github.com/anvaka/city-roads
transform, and load graphs into Graphistry. An alternative
9 http://sigmajs.org/
10 https://github.com/anvaka/VivaGraphJS
Graphistry client is the GraphistryJS JavaScript library23 .
11 https://github.com/anvaka/ngraph
12 https://cambridge-intelligence.com/regraph/ 18 https://threejs.org/
13 https://doc.linkurio.us/ogma/latest/ 19 https://js.cytoscape.org/
14 https://g6.antv.vision/en 20 https://dash.plotly.com/cytoscape
15 https://www.elgrapho.com/ 21 http://www.keylines.com
16 https://github.com/anvaka/ngraph.pixel 22 https://github.com/graphistry/pygraphistry
17 https://github.com/vasturiano/react-force-graph 23 https://github.com/graphistry/graphistry-js

5
Graphistry provides the graph-app-kit 24 , which is a toolkit represent such information in products such as Google
designed to help build custom graph analytics applications Maps and Waze is the use of markers. With this in
and dashboards. More specifically, the graph-app kit pro- mind, a street network visualization tool should provide
vides integration with a dashboard environment based on the support for drawing customizable markers on top of the
Streamlit library that can be deployed on the cloud. graph- map and the road network.
app-kit provides a set of reusable components and utilities to • R3. Good frame rate for large street networks on com-
assist with the integration of Graphistry’s graph visualization modity hardware. The visualization tool should provide
and analysis capabilities into dashboard applications. an animation frame rate of 24 FPS25 or higher, for street
networks with thousands of nodes and edges, to pro-
D. DISCUSSION vide the user a responsive experience when navigating
Table 1 shows a comparison of the discussed network visu- through the visualization (zooming and panning). Such
alization tools and academic works in terms of the following responsive experience should be achievable without the
features: 1) programming language (for libraries), 2) support need for a high-end GPU, on commodity hardware
for polyline drawing for edges, 3) support for rendering such as a laptop computer with a commodity integrated
graphs on top of a map layer, 4) support for GPU-accelerated graphics processor (e.g. Intel HD Graphics and AMD
rendering, 5) support for programmable interactivity, 6) sup- Ryzen with Radeon graphics).
port for a timeline and 7) support for integration with a • R4. Styles for nodes, links, and markers. The tool should
dashboard framework. We believe that these are the feature enable the user to customize the visual styles (e.g. color
a street network visualization tool or library should possess and size) of individual nodes, edges, and markers. Also,
to make it useful for real-world urban street analysis. it should facilitate the use of the data associated with the
As shown in Table 1, to the best of our knowledge, Dash street network for styling.
Sylvereye is the only tool written for Python that generates • R5. Interactions. The tool should allow the programmer
street network visualizations that can draw atop web tile to listen for events triggered when the user interacts
maps, that supports programmable user interactivity, that with the elements of the visualization to define custom
exploits hardware acceleration, and, most importantly, that is behavior such as retrieving and showing the data of a
designed from the ground up to be compatible with a larger clicked node, or showing a popup with custom data on
dashboard visualization framework. top of a clicked marker.
When ignoring the target programming language, Ke- • R6. Support for nodes, edges, and markers to store
pler.gl is the one tool that holds the most similarities with arbitrary data. The tool should enable the user to as-
Dash Sylvereye’s feature set. However, unlike Dash Sylver- sociate arbitrary data with individual elements of the
eye, Kepler.gl is not written with dashboard integration as visualization. For example, edges obtained from OSM
one of its core features. should be able to store its length, its road type (bridge,
highway), maximum speed, etc.
III. DASH SYLVEREYE DESIGN • R7. Integration with a dashboard framework. Most im-
A. REQUIREMENTS portantly, the tool should enable the street network visu-
We aim to provide a flexible and accessible tool that allows alization to work natively with a well-known dashboard
for the visualization of large road networks with associated framework to allow for the creation of dashboard visual-
multivariate data on commodity systems. This aim involves a izations of multivariate urban data that complement and
series of design requirements: enrich the street network visualization.
• R1. Support for polyline drawing on top of web tilemaps. Requirements R3, R4, and R5 have been previously iden-
An edge in a road network is defined as a sequence tified by the authors in [12] as relevant for high-performance
of coordinates that represent its shape in the actual complex graph visualization after interviewing experts in the
geography. Visualizations should be able to show edges field and reviewing a series of state-of-the-art tools. Authors
as a sequence of lines given the sequence of coordinates. in [14] also acknowledge that, when it comes to studying
Also, the road network should be rendered on top of urban networks with trajectory data, “the approach needs to
an interactive web tilemap such as those provided by handle a large number of city streets and massive trajectory
Mapbox or OSM, which allow the user to navigate data.” Regarding requirement R6, authors in [10] note that
through the map by panning and zooming. “node properties and edge weights play a fundamental role in
• R2. Support for markers. Street network visualization the field of multivariate network visualization,” in the context
is useful for practical applications insofar as it allows of multifaceted graph visualization.
for the graphical representation of events that happen To address the aforementioned requirements, we devel-
around the street network itself, such as traffic warnings, oped Dash Sylvereye, a visual analytics library for generat-
car accidents, and bottleneck spots, as well as places ing graph-based and interactive visualizations of large street
of interest (POI). A common practice in the industry to
25 The standard minimum speed needed to experience realistic motion
24 https://github.com/graphistry/graph-app-kit [16].

6
 (a)

(b)

(c)
FIGURE 1. Screenshots of a Dash Sylvereye visualization displaying the street network of Queretaro City, Mexico, on top of an OSM tilemap layer, at different
zoom levels and by showing different visualization layers. The visualized street network has 20,385 nodes and 49,137 edges.

7
networks and their associated multivariate data. It offers the 3) Node layer. Displays a clickable sprite for each node in
following solutions to the identified requirements: the street network. It can display nodes with different
sizes, transparency, and color.
• R1. GPU-accelerated rendering of nodes to represent
4) Marker layer. Displays a clickable sprite for each
junctions and street road polylines on top of Leaflet.js
marker. It can display markers with different sizes,
interactive web maps.
transparency, color, and icon.
• R2. GPU-accelerated rendering of fully customizable
markers. Popups with custom text are supported. Fig. 1 shows screenshots of a Dash Sylvereye visualization
• R3. Nodes, edges, and markers are rendered with We- displaying the street network of Queretaro City, Mexico, on
bGL for responsive and “smooth” navigation on net- top of an OSM tilemap, at different zoom levels and with
works with thousands of elements on any graphics different layers activated. The user can navigate through the
adapter supported by modern web browsers. visualization by panning and zooming it.
• R4. Nodes, edges, and markers styles are customizable:
color, size/width, transparency, and visibility. In the case 2) Data loading
of markers, the user can also customize the marker icon Dash Sylvereye provides various convenient routines for
by providing a custom image. Color scales are supported loading street networks out of NetworkX graphs and
and computed by the library. GraphML files generated by the OSMnx library. In this way,
• R5. Dash callback triggering when clicking individual the user can retrieve the street network of any city from OSM
nodes, edges, and markers. The user can also listen for for visualization with a simple query in a single line of code.
changes in the map zoom level and any other property
of the visualization component. 3) Styling
• R6. Individual nodes, edges, and markers can be asso- The style of individual nodes, edges, and markers is cus-
ciated with any arbitrary data. Functions are provided tomizable, allowing for the programmatic manipulation of
to load not only street network topologies but the data colors, sizes, transparency, and visibility of individual graph
associated with them from OSM. The library uses sim- elements. The user can also instruct Dash Sylvereye to
ple list-of-dictionaries data structures for easy loading automatically scale the size, color, and transparency based
of networks from any other source. on values found in the street network’s data. When using
• R7. The library is implemented as a component of this coloring option, the user can decide whether to use
the widely-used Dash framework. This enables Dash a predefined or a custom color scale. Markers can show
Sylvereye visualizations to be natively embedded into custom popup messages and the default marker’s icon can
custom dashboards. In this way, Dash Sylvereye allows be replaced by a custom SVG image.
for the display of multivariate data with the help of the
plotting components available in Dash, such as bar plots, 4) Interactivity and coordination
line plots, and scatter plots. Dash integration also allows As previously mentioned, nodes, edges, and markers are
the user to coordinate Dash Sylvereye visualizations clickable, allowing for the definition of custom behavior at
with a variety of Dash UI elements such as buttons, the user interaction. In addition, the callback architecture
sliders, dropdown lists, etc. of the Dash framework enables the interaction between a
A fully working and complete version of Dash Sylver- Dash Sylvereye visualization and other Dash components.
eye for the Python programming language has been im- More specifically, any of the visual styles, the street network
plemented. The following sections describe its design and data, and the street network itself can be updated at runtime
implementation. as a reaction to events emitted by other Dash components,
such as time sliders and buttons. In this way, for example,
B. DESIGN the transparency and color of edges can be scaled to their
vehicle count at different points in time selected via a Dash
1) Layers
slider. This specific example would add support for the time
Dash Sylvereye is implemented as a Dash framework compo- dimension to Dash Sylvereye, allowing for the visualization
nent. A Dash Sylvereye visualization is made of four layers: of dynamic events in the street network.
1) Tile layer. Displays a zoomable and pannable web map
generated by joining dozens of individually requested 5) Software and GPU acceleration
images in real time. Dash Sylvereye is built on top Dash Sylvereye exploits synchronous software (CPU) and
of Leaflet.js, enabling the user to select the tilemap GPU acceleration for displaying a large graph on a tiled web
provider of his/her preference (e.g. OSM and Mapbox). map as follows.
2) Edge layer. Displays a clickable polygon for each edge Dash Sylvereye uses PixiJS to draw the network. In a
in the street network. It also displays a direction arrow regular multimedia application (e.g. a videogame) written
sprite for each edge. It can display edges with different with PixiJS the main job of the GPU is to draw each frame
widths, transparency, and color. efficiently to give the feeling of a smooth animation. In Dash
8
FIGURE 2. Stack of the main libraries used to build the Dash Sylvereye library. The diagram can be read in the top-down direction as follows: the library in a given
layer uses the libraries in the layer located immediately below. The boxes in blue are Python libraries. Boxes in yellow are JavaScript libraries.

Sylvereye the drawing of a road network and the markers •Leaflet.PixiOverlay28 : Overlay class for Leaflet.js for
represents the redrawing of a single frame of such an ani- WebGL-accelerated drawing on top of tiled web maps
mation. Thus, the GPU function is to render that animation using PixiJS.
29
frame as fast as possible. To that end, Dash Sylvereye uses • Chroma.js : Library for computing color conversions
Leaflet.PixiOverlay which allows to draw over a Leaflet.js and color scales in the web browser.
30
overlay with PixiJS, which in turn uses WebGL for GPU- • JSTS : Library of spatial predicates and functions
accelerated drawing of thousands of objects. for processing geometries in web browsers. It is a
Due to the use of Leaflet.PixiOverlay, the GPU acceler- JavaScript port of the JTS Java library.
31
ation is involved when: (1) drawing the road network and • RBush : Library for 2D spatial indexing of points and
markers for the first time and (2) redrawing the road network rectangles in web browsers. It is built around a custom
and markers after the user has interacted with it. More R-tree data structure with bulk insertion support.
specifically, drawing/redrawing (and thus GPU acceleration) • React.js: Component-driven front-end library for build-
is triggered at three specific times: ing UI components maintained by Facebook.
32
• React Leaflet : Bindings between React.js and
1) At startup (first draw).
Leaflet.js. Exposes Leaflet.js layers as React compo-
2) After panning the map, i.e. after releasing the left
nents.
mouse button after panning.
3) After panning the map, i.e. after zooming in or zoom- Python libraries:
ing out. • Plotly Dash: User interface library for creating data-
driven web applications around dashboard visualiza-
The rest of the time (i.e. during the panning and zooming
tions entirely in Python.
animations) the CPU handles the drawing work with software 33
• NetworkX : Social Network Analysis library for net-
acceleration since the road network was already rendered.
work reading, creation, generation, manipulation, mea-
suring, and visualization.
C. SOFTWARE STACK 34
• Shapely : Library for manipulating geometric objects
The Dash Sylvereye library is built on top of the following in the Cartesian plane.
open-source JavaScript and Python libraries: Fig. 2 shows the library stack used to develop Dash
JavaScript libraries: Sylvereye. Leaflet.js provides a layer of tiled web maps as
• PixiJS26 : Cross-device 2D rendering library accelerated well as zooming and panning capabilities, whereas the Pix-
by WebGL for creating interactive graphics on web iJS library provides WebGL-powered street network draw-
browsers. It acts as an abstraction layer for the WebGL ing primitives (polygons and sprites). This is done by us-
API. ing Leaflet.PixiOverlay which provides a Leaflet.js overlay
• Leaflet.js27 : Mapping library for rendering interactive where PixiJS can draw.
tiled web maps hosted on public servers with (optional) 28 https://github.com/manubb/Leaflet.PixiOverlay
tiled overlays. Supports HTML5 and CSS3. It can create 29 https://gka.github.io/chroma.js/
30 https://bjornharrtell.github.io/jsts/
interactive layers.
31 https://github.com/mourner/rbush
32 https://react-leaflet.js.org/
26 https://www.pixijs.com/ 33 https://networkx.org/
27 https://leafletjs.com/ 34 https://github.com/Toblerity/Shapely

9
 Dash Sylvereye also makes use of other third-party update an H2 label component label with the edge’s polyline
JavaScript libraries, such as JSTS for defining edge-hit poly- coordinates.
gons, RBush for efficiently finding edge-hit polygons that The programmer can fine-tune the visuals of the street
have been clicked by the user, and Chroma.js for computing network visualization on an element-by-element basis by
color scales for edges, nodes, and markers. filling option dictionaries available for nodes, edges, and
React Leaflet is used to bring everything together: the markers. Table 3 lists the currently supported style option
Leaflet.js map, the tilemap layer, and the road network vi- methods. The user only needs to: 1) get an options dictionary
sualization layer that exploits Leaflet.PixiOverlay. All these pre-filled with default settings, 2) customize the options
elements are encapsulated into the SylvereyeRoadNetwork dictionary by selecting and setting up one or more visual
React Component. The React component is then wrapped option methods listed in Table 3, and 3) pass the dictionary to
to produce the SylvereyeRoadNetwork Dash component by the Dash Sylvereye component. Again, if the user passes an
using the toolchain provided by Dash. updated options dictionary to Dash Sylvereye at runtime, the
On the Python side, Dash Sylvereye network loading rou- visualization will update accordingly in an automatic fashion.
tines make use of NetworkX and Shapely, enabling Dash In Fig. 5, the transparency level (alpha) of all nodes is
Sylvereye to import street networks from the OSM project set to 0.25 to make them translucent. Also, the size method
via OSMnx or from OSMnx-generated GraphML files. is set to NodeSizeMethod.SCALE in order to set the
diameter of all nodes in proportion to their weight. As for
IV. USAGE EXAMPLE the visuals of edges, both the edge width and edge color
This section presents a simple usage example to illustrate methods are also set to EdgeWidthMethod.SCALE and
what programming with Dash Sylvereye looks like. The EdgeColorMethod.SCALE, respectively, in order to be
example is separated into three parts, namely initialization, scaled in proportion to edge weights. Fig. 6 shows the result-
interactivity, and styling. ing web dashboard when putting together the code provided
In Fig. 3, the street network of Queretaro City in Figs. 3-5.
is retrieved from OSM with the OSMnx library
and then transformed to Dash Sylvereye’s list-of- V. ANIMATION PERFORMANCE ASSESSMENT
dictionaries data structure by using the utility function We quantitatively assessed how “responsive” is to the user in-
load_from_osmnx_graph(). Dash Sylvereye also pro- teraction with Dash Sylvereye visualizations on a commodity
vides the function load_from_osmnx_graphml() to computer for a set of OSM street networks of varying sizes
load a street network from a graph file in GraphML format when exploiting software acceleration.
generated by OSMnx. Panning35 of a web map is an important operation since,
To insert a street network visualization in a Dash dash- in our case, it lets the user navigate the road network and
board, the programmer only has to insert an instance of explore its elements. We, therefore, assessed how smooth
the class SylvereyeRoadNetwork in the dashboard ap- is the panning of a network visualization by measuring the
plication layout. The street network topology (and data) is screen refresh rate of a web page in terms of the animation
provided via the nodes_data and edges_data param- frames per second (FPS). The CPU time and frame duration
eters. Apart from the road network, the user can provide can offer insights for explaining the observed FPS.
information about the map and the web tile layer by using We conducted the assessment on a commodity computer
an interface similar to that of Leaflet.js. with a dual-core AMD A9-9425 processor at 3.1 GHz, with
Table 2 shows the list of currently supported properties an Integrated AMD Radeon R5 (Stoney Ridge) GPU, and
in the SylvereyeRoadNetwork class. These properties 7.2 GiB in RAM. The computer was running Linux Ubuntu
allow the user to set up the tilemap (e.g. tilemap provider and 18.04.4 LTS 64-bits. Note that the processor used in the
attribution), the road network data (e.g. nodes and edges), experiments is a mid-end mobile CPU with an integrated
node/edge/marker style options, the layer visibility, and the GPU that can be found in budget laptops.
map itself (e.g. zoom level and center). Recall that any of The assessment methodology consisted of two main
these parameters can be updated at runtime, triggering the stages. In the first stage, we retrieved the data of street
automatic update of the visualization when changed. For networks from OSM by running OSMnx with the query
example, if the user wants to update the street network strings listed in Table 4 for four cities. We used the OSM
topology, it is enough to update the nodes_data and the website to get initial map center coordinates to open the test
edges_data parameters in a callback. dashboards and then choose the final map centers and zoom
Fig. 4 shows an example on the use of callbacks for levels. Final map centers and zoom levels were chosen in
reacting to user interaction by using the clicked_node such a way that the whole street network was visible.
and clicked_edge callback parameters listed in Table In the second stage, we conducted the following experi-
2. Every time the user clicks a node, a callback provided ment for each street network. We used the performance tab
by the programmer is triggered to update an H2 Dash label
component with the node’s coordinates. Likewise, every time 35 Panning consists in holding the left button of the mouse and moving the
the user clicks an edge the provided callback is triggered to mouse to navigate on the map.

10
FIGURE 3. Example showing how to embed a SylvereyeRoadNetwork component in a minimal Dash dashboard to display a street network obtained with OSMnx.

FIGURE 4. Example showing how to use Dash callbacks to react to mouse clicks on the street network’s nodes and edges.

11
FIGURE 5. Example showing how to configure the visual styles of nodes (transparency and size) and edges (width and color scale) in a Dash Sylvereye
visualization.

of the Chrome DevTools console to record the dashboard machine.

while manually panning the whole visualization by perform-
ing circular dragging movements. We used Google Chrome VI. ANIMATION PERFORMANCE COMPARISON
v85.0.4183.121. We also present a performance comparison between Dash
Next, we manually registered the frame duration, frame Sylvereye and other state-of-the-art visualization libraries
FPS, and frame CPU time of 31 recorded animation frames that can render large road networks: Kepler.gl and city-roads.
from the Chrome DevTools performance tab to obtain statis- We quantitatively measured and compared the responsive-
tically valid results. We repeated this experiment 10 times for ness to the user interaction of the three tools on a commodity
each street network. computer for the Alameda, Enschede, Queretaro, and Beijing
Fig. 7 shows the median frame FPS, duration, and CPU road networks.
time for each experiment and each city. Fig. 8 shows the The hardware setup and the two-stage methodology were
median values when merging all experiments for each city. the same as in Section V. We conducted the 10 experiments
We use the median because it is less sensitive to outliers than for each tool sequentially and continuously in time, without
the average. Cities are sorted from smaller to larger from left interruptions (no computer reset, no login-logout, etc.) to get
to right. numbers as accurate as possible. There were no other apps
Figures show that lower FPS values are associated with and tabs other than the web browser was open. The full city
larger CPU times and frame durations. This might be ex- map was always visible during the movements in all exper-
plained by the fact that the more the CPU has to work iments. All circular movements were performed manually,
the more the duration of an animation frame, negatively and clockwise in all experiments. We used the same manual
impacting the FPS in that animation frame. movements with regard to speed and diameter as humanly
From the FPS perspective, figures show that the larger possible. The center and zoom level in Kepler.gl and Dash
the city the lower the FPS, ranging from around 60 FPS Sylvereye were adjusted programmatically whereas for city-
for the Alameda city to around 10 FPS for the Beijing roads we had to set the center and zoom level manually. For
city. Nonetheless, Queretaro city, with 20k nodes and 49k this experimentation, we used Google Chrome v87.0.4280.88
edges, shows an FPS of above 24 FPS, suggesting that Dash on Ubuntu 20.04.1 LTS (64-bit).
Sylvereye can smoothly handle the panning of networks with Fig. 9 shows the median frame FPS, duration, and CPU
dozens of thousands of nodes and edges on the experiment time for each experiment and each city for the three tools.
12
FIGURE 6. Screenshot of the resulting dashboard example after putting together the code snippets shown in Figs. 3-5.

TABLE 2. The SylvereyeRoadNetwork Dash component supports an array of properties classified as follows: 1) data properties, 2) (style) option properties, 3)
show/hide properties, map properties, 4) tile layer properties, and 5) callback properties. All but the callback properties are provided and updated by the user to set
up and tune the street network visualization. Callback properties, on the other hand, are updated by Dash as a reaction to user-click interaction.

Property Category Brief description Observations

nodes_data Data List of the road network’s nodes Nodes can hold arbitrary data in the ’data’ field
edges_data Data List of the road network’s edges Edges can hold arbitrary data in the ’data’ field
markers_data Data List of map markers Markers can hold arbitrary data in the ’data’ field
node_options Options Visual options dictionary for nodes -
edge_options Options Visual options dictionary for edges -
marker_options Options Visual options dictionary for markers -
show_nodes Show/hide If false, all nodes will be hidden Hidden nodes will cease to be interactive
show_edges Show/hide If false, all edges will be hidden Hidden edges will cease to be interactive
show_arrows Show/hide If false, all direction arrows will be hidden -
show_markers Show/hide If false, all markers will be hidden Hidden markers will cease to be interactive
map_center Map Map center coordinates In (latitude, longitude) format
map_zoom Map Map zoom level As specified by Leaflet.js
map_min_zoom Map Minimum allowed map level As specified by Leaflet.js
map_max_zoom Map Maximum allowed map level As specified by Leaflet.js
map_style Map Map CSS styles Provided in dictionary form: {’style’: ’value’}
tile_layer_url Tile layer Tile layer URL template As specified by Leaflet.js
tile_layer_subdomains Tile layer Tile layer attribution HTML text As specified by Leaflet.js
tile_layer_attribution Tile layer Tile layer subdomains As specified by Leaflet.js
tile_layer_opacity Tile layer Tile layer opacity A value between 0 and 1
clicked_node Callback Used to invoke a callback when a node is clicked Data will be available as the property’s value
clicked_edge Callback Used to invoke a callback when an edge is clicked Data will be available as the property’s value
clicked_marker Callback Used to invoke a callback when a marker is Data will be available as the property’s value
clicked

TABLE 3. Style methods available for nodes, edges, and markers. For example, there are three color methods for nodes: NodeColorMethod.DEFAULT,
NodeColorMethod.SCALE, and NodeColorMethod.CUSTOM. DEAFAULT methods use the predefined settings provided by Dash Sylvereye, which can be
customized. SCALE methods, on the other hand, scale visual style values in proportion to a weight field. CUSTOM methods allow styling based on the data
associated with individual nodes, edges, and markers. For the case of visibility methods, ALWAYS instructs Dash Sylvereye to turn the visibility of all elements on.
Some other style methods are more specific to a given kind of element, such as the ORIGINAL method for marker icons, which makes Dash Sylvereye use the
original color of the SVG image specified as an icon.

Style Node methods Edges methods Marker methods

Color DEAFAULT, SCALE, CUSTOM DEAFAULT, SCALE, CUSTOM DEAFAULT, SCALE, CUSTOM, ORIGINAL
Size DEAFAULT, SCALE, CUSTOM N/A DEAFAULT, SCALE, CUSTOM
Alpha DEAFAULT, SCALE, CUSTOM DEAFAULT, SCALE, CUSTOM DEAFAULT, SCALE, CUSTOM
Visibility ALWAYS, CUSTOM ALWAYS, CUSTOM ALWAYS, CUSTOM
Width N/A DEAFAULT, SCALE, CUSTOM N/A
Icon N/A N/A DEFAULT, CUSTOM

13
TABLE 4. Details of the OSM street networks and the tilemap configuration used for the animation performance assessment.

Number of Number of
City name OSMnx query string Center (lat, lon) Zoom level
nodes edges
37.7618235,
Alameda, US Alameda, Alameda County, CA, USA 1,830 4,842 15
−122.2429843
Enschede, Overijssel, Netherlands, The 52.2271595,
Enschede, NL 5,337 13,587 12
Netherlands 6.9046205
20.6025256,
Queretaro, MX Santiago de Querétaro, Querétaro, México 20,385 49,137 12
−100.3886302
39.9116304,
Beijing, CN Beijing, China 63,347 153,120 9
116.4010405

Dash Sylvereye Dash Sylvereye Dash Sylvereye

60
Median frame duration (ms)
125 100

Median CPU time (ms)

50
100 80
Median FPS

40
30 75 60
20 50 40
10 25 20
0 Alameda Enschede Queretaro Beijing 0 Alameda Enschede Queretaro Beijing 0 Alameda Enschede Queretaro Beijing
City City City
(a) (b) (c)
FIGURE 7. Dash Sylvereye’s median frame FPS, duration, and CPU time for each experiment and each city. Cities are sorted from smaller to bigger from left to
right.

60 80 80
Tool Tool Tool
Median frame duration (ms)

50 Dash Sylvereye Dash Sylvereye Median CPU time (ms) Dash Sylvereye
60
60
Median FPS

40
40
30 40
20 20
20
10
Alameda Enschede Queretaro Beijing Alameda Enschede Queretaro Beijing Alameda Enschede Queretaro Beijing
City City City
(a) (b) (c)
FIGURE 8. Dash Sylvereye’s median frame FPS, duration, and CPU time when merging all experiments for each city. Cities are sorted from smaller to bigger from
left to right.

Fig. 10 shows the median values when merging all experi- performance was inversely proportional to the road network
ments for each city for the three tools. size. However, Fig. 9 also shows that Dash Sylvereye FPS
Figures show that, for the three tools, lower FPS values outperformed Kepler.gl in three out of four cities (Alameda,
are associated with larger CPU times and frame durations. Enschede, and Queretaro), whereas it outperformed city-
However, Figures also show that, unlike Dash Sylvereye, roads in one out of four cities (Alameda). Additionally, as
Kepler.gl and city-roads seem to be unaffected by the road city-roads, Dash Sylvereye showed FPSs above 24 for three
network size. This suggests that these tools might exploit out of four cities (Alameda, Enschede, and Queretaro). With
hardware acceleration during the panning process. In con- these results, Dash Sylvereye showed to be competitive when
trast, recall that Dash Sylvereye exploits hardware acceler- compared to both Kepler.gl and city-roads for road networks
ation only after panning (and zooming) for redrawing. with dozens of thousands of nodes and edges.
Nonetheless, note in Fig. 9 that Kepler.gl showed FPSs
lower than 10 in one experiment for Alameda, one exper- VII. DASHBOARD EXAMPLE: QUERETARO CITY
iment for Enschede, and two experiments for Queretaro. TRAFFIC SIMULATION
In contrast, for Alameda, Enschede, and Queretaro, Dash This section presents the design and implementation of an
Sylvereye’s FPS was higher than 20 whereas the duration example dashboard application written with the Dash frame-
and CPU remained low. For the largest city, Beijing, Dash work that exploits Dash Sylvereye for the analysis of post-
Sylvereye’s FPS was higher than 20 for three experiments. mortem simulation data on the street network of Queretaro
Overall, Figures 9 and 10 show that Dash Sylvereye’s City, Mexico. For simulations, we made use of the SUMO
14
 Dash Sylvereye Kepler.gl city-roads
60 25 60
50 20 50
40 40
Median FPS

Median FPS

Median FPS
15
30 30
10
20 20
10 5 10
0 Alameda Enschede Queretaro Beijing 0 Alameda Enschede Queretaro Beijing 0 Alameda Enschede Queretaro Beijng
City City City
(a) (b) (c)

Dash Sylvereye Kepler.gl city-roads

Median frame duration (ms)

Median frame duration (ms)

Median frame duration (ms)

400 50
60
40
300
40 30
200
20
20
100 10
0 Alameda Enschede Queretaro Beijing 0 Alameda Enschede Queretaro Beijing 0 Alameda Enschede Queretaro Beijing
City City City
(d) (e) (f)

Dash Sylvereye Kepler.gl city-roads

60 10
400
Median CPU time (ms)

Median CPU time (ms)

Median CPU time (ms)

8
40 300
6
200
4
20
100 2
0 Alameda Enschede Queretaro Beijing 0 Alameda Enschede Queretaro Beijing 0 Alameda Enschede Queretaro Beijing
City City City
(g) (h) (i)
FIGURE 9. Median frame FPS, duration, and CPU time shown by Dash Sylvereye, Kepler.gl, and city-roads on each experiment and each city. Cities are sorted
from smaller to bigger from left to right.

60
Median frame duration (ms)

50
50
Median CPU time (ms)

50 40
Tool Tool Tool
Median FPS

Dash Sylvereye 40 Dash Sylvereye Dash Sylvereye

40 30
Kepler.gl Kepler.gl Kepler.gl
city-roads 30 city-roads 20 city-roads
30
20 10
20
Alameda Enschede Queretaro Beijing Alameda Enschede Queretaro Beijing Alameda Enschede Queretaro Beijing
City City City
(a) (b) (c)
FIGURE 10. Dash Sylvereye’s median frame FPS, duration, and CPU time shown by Dash Sylvereye, Kepler.gl, and city-roads when merging all experiments for
each city. Cities are sorted from smaller to bigger from left to right.

15
FIGURE 11. Layout of the dashboard made with Dash and the Dash Sylvereye library for analyzing a SUMO traffic simulation. Labels in orange are the Dash
component identifiers referred to in Fig. 12.

urban traffic simulator [4], a well-known simulator in the A. STREET NETWORK RETRIEVAL AND SIMULATION
field of urban analysis. A street network from the center of the metropolitan area of
The purpose of this section is twofold. Firstly, we intend to Queretaro City, Mexico, was manually selected and down-
better illustrate the usefulness of Dash Sylvereye in assisting loaded in OSM format by taking advantage of the export fea-
a traffic analyst to observe how traffic bottlenecks build up tures of the OSM website. The resulting street network had
with time in a busy transportation area made of thousands of 8,713 nodes and 17,099 edges. The OSM network was con-
street roads and junctions through a dashboard visualization verted to SUMO’s XML format by using SUMO’s netconvert
centered around Dash Sylvereye. Secondly, we intend to tool. Finally, the SUMO XML network was converted to
offer the reader more details about how the Dash Slyvereye Dash Sylvereye’s list-of-dictionaries format with the help of
component can be integrated into a non-trivial dashboard the Sumolib Python library36 .
by coordinating it with other charts and UI controls for To create synthetic vehicle trip data, a simulation was
multivariate data visualization. run by using SUMO as follows: random trips for vehicles
36 https://sumo.dlr.de/docs/Tools/Sumolib.html

16
FIGURE 12. Callback graph of the SUMO simulator dashboard example, as generated by the Dash Dev Tools. Gray boxes represent Dash components. Labels on
top of gray boxes are the Dash component identifiers. Green rounded boxes represent callback functions. Blue boxes represent the input and output properties.
Solid gray arrows pointing to green rounded boxes come from input callback parameters. Solid blue arrows going out of green rounded boxes point to output
callback parameters. Dashed gray arrows pointing to green circles represent states.

were generated with SUMO’s randomTrips.py script. (transparency, width) to scale in proportion to the edge ve-
A SUMO simulation was run for 3,500 timesteps with the hicle count through the scale-by-checklist checklist.
--fcd-output flag to save the Floating Car Data (FCD) The dashboard shows a slider to allow the user to select the
of all timesteps in XML format. The produced FCD data was desired simulation time to display (time-slider). When
then processed to get CSV files that could be conveniently the user changes the simulation time, a callback is triggered
imported into the Dash dashboard application. CSV files to update:
included the vehicle count for edges at each timestep, the • The network edges, width, and transparency.
speed of vehicles at each timestep, total vehicle counts for • The position and the popup texts of markers.
each timestep, and average vehicle speed at each timestep. • A bar plot of the top-10 edges with the highest vehicle
count in the network (top-edges-graph)
B. LAYOUT DESIGN • A bar plot of the speed for the top-10 slowest vehicles

Recall from Section I that a Dash dashboard application is (top-vehicles-graph)

composed of two parts: 1) the layout which describes what When the user clicks either an edge, a node, or a marker,
the application looks like and 2) the callbacks that define the data about the clicked element is shown in the label at the top-
interactivity of the application. Fig. 11 shows a screenshot of right corner (clicked-edge-h5). Finally, the dashboard
the resulting dashboard layout. also shows a line plot showing the vehicle count over time
The dashboard includes a Dash Sylvereye visualiza- and a line plot showing the average vehicle speed over time.
tion as its main element (sylvereye-roadnet). The However, these two plots are static in the sense that they do
user can select which layers are visible through the not need to change as a result of the interaction of the user
show-layers-checklist checklist. Markers are dis- with the dashboard.
played at either the middle of edges with the highest vehicle
counts or atop the slowest vehicles, depending on the option C. CALLBACK DESIGN
selected by the user in the markers-at-select selection Fig. 12 shows the callback graph of the SUMO simulator
list. dashboard example, as generated by the Dash Dev Tools.
The user can also select which visual attributes of edges The application contains four main callbacks, callbacks A
17
 (a)

(b)

(c)
FIGURE 13. Radiography-like visualizations centered at the “Alameda Hidalgo” park at three arbitrarily selected but consecutive simulation time steps. The
visualization style was configured through the GUI components of the SUMO traffic dashboard developed with Dash and the Dash Sylvereye library. Note that the
large blue arrows are street roads rendered by Dash Sylvereye (images were not edited).

18
to D, which together define the interactivity of the whole of edges. We also found Dash Sylvereye to be competitive
application. when compared to the state-of-the-art visualization libraries
Callback A triggers when either: Kepler.gl and city-roads for road networks with dozens of
1) The value of markers-at-select changes its thousands of nodes and edges. With the help of a dashboard
value, in which case the callback outputs a new set of application example, we explored how Dash Sylvereye can
markers. be utilized as a convenient tool for interactively analyzing
2) The time-slider changes its value, in which case multivariate traffic data.
the callback updates the markers and both bar plots Visualization generation time is an important factor that
top-vehicles-graph and top-edges-graph impacts the experience of the end-user. Even with WebGL
to reflect the data at the new time step. acceleration, we have observed that the visualization first
drawing and redrawing of very large graphs in Dash Sylver-
Callback B triggers when any of the click attributes of the
eye may take non-negligible time on a commodity system,
Dash Sylvereye component changes its value as the result of
an overhead not present in other libraries like Kepler.gl and
a user clicking on a node, an edge, or a marker. The callback
city-roads. This overhead includes the time needed for the
updates the label clicked-edge-h5 with info about the
generation of the graphics (sprites and polygons) of the street
clicked element.
network and the computation of hit polygons for edge click
Callback C triggers when show-layers-checklist
detection. Future work includes methodologically assessing
changes its value because the user selected a different set of
visualization generation times on commodity computers and
layers to show. The callback updates the show/hide properties
evaluating optimization options.
of the Dash Sylvereye component accordingly.
Similar to other web-based visualization tools, one of
Finally, callback D triggers when the component
Dash Sylvereye’s main drawbacks is that the size of a street
scale-by-checklist changes its value because the
network the library can handle is limited by the system’s
user selected different scale options. The callback updates the
physical memory and the GPU memory capacity. In this
edge_options attribute of the Dash Sylvereye component
regard, an interesting research venue is to study efficient
accordingly to update the edge’s alpha and width style meth-
graph coarsening algorithms for edge bundling that 1) al-
ods.
low the tool to handle very large networks and 2) help
the researcher’s cognitive process of making sense of such
D. VISUALIZATION INSIGHTS
complex structures.
Fig. 13 shows screenshots of the Dash Sylvereye compo-
We plan to release Dash Sylvereye under an open-source
nent at three arbitrarily selected simulation time steps. The
license, enabling anyone to use it for their specific street
tilemap is centered at the “Alameda Hidalgo” park, a centric
network visualization needs.
place where traffic bottlenecks build up in real life. Edges
transparency and width were scaled to the vehicle count by
checking the corresponding checkboxes in the dashboard. REFERENCES
The map tile layer, as well as the nodes and markers layers, [1] T. Anderson and S. Dragićević, "Complex spatial networks: Theory and
geospatial applications", Geography Compass, vol. 14, no. 9, 2020. Avail-
were hidden by unchecking the corresponding checkboxes. able: 10.1111/gec3.12502.
The result was a radiography-like visualization of the vehicle [2] M. Bastian, S. Heymann, and M. Jacomy, “Gephi: An Open Source
traffic. The “radiography” in Fig. 13 clearly shows that, even Software for Exploring and Manipulating Networks”, ICWSM, vol. 3, no.
1, Mar. 2009.
with random trips, vehicle traffic builds up on the main street [3] S. Batt, O. Harmon and P. Tomolonis, "Learning Tableau: A
roads surrounding the park. Data Visualization Tool", SSRN Electronic Journal, 2019. Available:
10.2139/ssrn.3438993.
[4] M. Behrisch, L. Bieker, J. Erdmann and D. Krajzewicz, "SUMO - Sim-
VIII. CONCLUSION ulation of Urban MObility - an Overview", in The Third International
This paper presented Dash Sylvereye, a new Python library Conference on Advances in System Simulation, Barcelona, Spain, 2011,
for generating web-based visualizations of large street net- pp. 55-60.
[5] G. Boeing, "OSMnx: A Python package to work with graph-theoretic
works, delivered as a component for the widely-used Dash OpenStreetMap street networks", The Journal of Open Source Software,
framework. To the best of our knowledge, Dash Sylvereye vol. 2, no. 12, p. 215, 2017. Available: 10.21105/joss.00215.
is the first tool written for Python that generates street net- [6] G. Boeing, "OSMNX: New Methods for Acquiring, Constructing, Analyz-
ing, and Visualizing Complex Street Networks", SSRN Electronic Journal,
work visualizations atop web tile maps that supports pro- 2016. Available: 10.2139/ssrn.2865501.
grammable user interactivity, that is designed as a component [7] D. Fang, M. Keezer, J. Williams, K. Kulkarni, R. Pienta and D. Horng
of a dashboard framework from the ground up, and that sup- Chau, "Carina: Interactive Million-Node Graph Visualization using Web
Browser Technologies", in 26th International Conference on World Wide
ports WebGL. Dash Sylvereye can be combined with other
Web, 2017, pp. 775–776.
Dash UI and chart components to enable the development [8] T. Fujiwara, J. Zhao, K. Ma, F. Chen and K. Ma, "A Visual Analytics
of interactive dashboard visualizations around street network Framework for Contrastive Network Analysis", in 2020 IEEE Conference
data. on Visual Analytics Science and Technology (VAST), 2020, pp. 48-59.
[9] S. Gray, O. O’Brien and S. Hügel, "Collecting and Visualizing Real-Time
We showed that Dash Sylvereye can offer fast response Urban Data through City Dashboards", Built Environment, vol. 42, no. 3,
speeds (close to 60 FPS) for street networks with thousands pp. 498-509, 2016. Available: 10.2148/benv.42.3.498.

19
[10] S. Hadlak, H. Schumann and H. Schulz, "A Survey of Multi-faceted Graph MAHBOOBEH ZANGIABADY is a lecturer at
Visualization", in Eurographics Conference on Visualization (EuroVis) - the Design and Analysis of Communication Sys-
STARs, 2015, pp. 1-20. tems (DACS) group at the University of Twente.
[11] M. Haklay and P. Weber, "OpenStreetMap: User-Generated Street Maps", She holds a Ph.D. in computer science from the
IEEE Pervasive Computing, vol. 7, no. 4, pp. 12-18, 2008. Available: Centre for Research and Advanced Studies of
10.1109/mprv.2008.80. the National Polytechnic Institute. Her research
[12] D. Han, J. Pan, X. Zhao and W. Chen, "NetV.js: A web-based li- interests cover network virtualization, QoS, re-
brary for high-efficiency visualization of large-scale graphs and net-
source management, machine learning, and Net-
works", Visual Informatics, vol. 5, no. 1, pp. 61-66, 2021. Available:
work Functions Virtualization, Software-Defined
10.1016/j.visinf.2021.01.002.
[13] B. Hayes, "Usage of Programming Languages by Data Scientists: Networks (NFV/SDN).
Python Grows while R Weakens", Businessoverbroadway.com, 2020.
[Online]. Available: https://businessoverbroadway.com/2020/06/29/usage-
of-programming-languages-by-data-scientists-python-grows-while-r-
weakens/. [Accessed: 30-Apr-2021].
[14] X. Huang, Y. Zhao, C. Ma, J. Yang, X. Ye and C. Zhang, "TrajGraph:
A Graph-Based Visual Analytics Approach to Studying Urban Network
Centralities Using Taxi Trajectory Data", IEEE Transactions on Visualiza-
tion and Computer Graphics, vol. 22, no. 1, pp. 160-169, 2016. Available:
10.1109/tvcg.2015.2467771.
[15] C. Jing, M. Du, S. Li and S. Liu, "Geospatial Dashboards for Monitoring
Smart City Performance", Sustainability, vol. 11, no. 20, p. 5648, 2019.
Available: 10.3390/su11205648.
[16] M. Kuperberg, M. Bowman, R. Manton and A. Peacock, A guide to
computer animation. Oxford, U.K.: Focal Press, 2002.
[17] S. Li et al., "Argo Lite: Open-Source Interactive Graph Exploration and
Visualization in Browsers", in 29th ACM International Conference on
Information & Knowledge Management, 2020, pp. 3071–3076.
[18] R. Matheus, M. Janssen and D. Maheshwari, "Data science empower-
ing the public: Data-driven dashboards for transparent and accountable
decision-making in smart cities", Government Information Quarterly, vol.
37, no. 3, p. 101284, 2020. Available: 10.1016/j.giq.2018.01.006.
[19] F. Mwalongo, M. Krone, G. Reina and T. Ertl, "State-of-the-Art Report in
Web-based Visualization", Computer Graphics Forum, vol. 35, no. 3, pp.
553-575, 2016. Available: 10.1111/cgf.12929.
[20] A. Sakib, S. Ismail, H. Sarkan, A. Azmi and O. Yusop, "Analyzing Traffic
Accident and Casualty Trend Using Data Visualization", in IRICT 2018:
Recent Trends in Data Science and Soft Computing, 2018, pp. 84-94.
[21] A. Sarikaya, M. Correll, L. Bartram, M. Tory and D. Fisher, "What Do We
Talk About When We Talk About Dashboards?", IEEE Transactions on
Visualization and Computer Graphics, vol. 25, no. 1, pp. 682-692, 2019.
Available: 10.1109/tvcg.2018.2864903
[22] A. Saska et al., "ccNetViz: a WebGL-based JavaScript library for visual-
ization of large networks", Bioinformatics, vol. 36, no. 16, pp. 4527-4529,
2020. Available: 10.1093/bioinformatics/btaa559.
[23] A. Schoedon, M. Trapp, H. Hollburg, D. Gerber and J. Döllner, "Web-
based Visualization of Transportation Networks for Mobility Analytics",
in 12th International Symposium on Visual Information Communication
and Interaction, 2019, pp. 1-5.
[24] A. Sevtsuk and M. Mekonnen, "Urban network analysis. A new toolbox
for ArcGIS", Revue Internationale de Géomatique, vol. 22, no. 2, pp. 287-
305, 2012. Available: 10.3166/rig.22.287-305.
[25] P. Shannon, "Cytoscape: A Software Environment for Integrated Models
of Biomolecular Interaction Networks", Genome Research, vol. 13, no. 11,
pp. 2498-2504, 2003. Available: 10.1101/gr.1239303.
[26] Y. Zheng, W. Wu, Y. Chen, H. Qu and L. Ni, "Visual Analytics in Urban
Computing: An Overview", IEEE Transactions on Big Data, vol. 2, no. 3,
pp. 276-296, 2016. Available: 10.1109/tbdata.2016.2586447.

ALBERTO GARCIA-ROBLEDO holds a MSc.

and a Ph.D. in Computer Science from the Center
for Research and Advanced Studies of the Na-
tional Polytechnic Institute (Mexico). He was a
tech lead at the Geospatial Data Center of the Mas-
sachusetts Institute of Technology (US). Currently,
he is a Conacyt Research Fellow at the Center for
Research in Geography and Geomatics (Mexico).
His current research interests include HPC, Big
Data, Graph Analytics, and Visual Analytics.

20