Open Data Sources for 3D Data Visualisation
Generating 3D Worlds based on OpenStreetMaps Data
Almar Joling
Deltares, Delft, The Netherlands
Keywords: OpenStreetMaps, Procedural Mesh Generation, World Generation, Virtual Worlds, GIS.
Abstract: Georeferenced data is becoming increasingly more available through open source licenses. In this paper, an
approach is explained to build a real-time interactive 3D virtual world using the Unity 3D engine by using
the freely available OpenStreetMaps data. This virtual environment can serve as a base for the visualisations
of spatial and georeferenced data. By making use of OpenStreetMaps this virtual environment can be kept
up to date with changes in the world. This paper provides an introduction to OpenStreetMaps, discusses
some of the challenges and provides examples how to process this data in order to generate a virtual
OpenStreetMaps (OSM) data (OpenStreetMap,
2016) has the advantage of being a single data
source which can provide information about any
location on Earth. Users can edit the maps through
different online tools available on the OSM website
or standalone applications. The size of the database
is continuously increasing (Stats - OpenStreetMap
Wiki, 2016).
Various side projects have also emerged, which
aim to improve the available map data in areas of
need during emergencies or calamity situations. One
of these is the Humanitarian OpenStreetMap Team
project (, 2016). Many other services and
tools use the OSM data to provide routing
information for GPS devices
(, 2016) or smartphones
(, 2016). OSM data is also used for
offline visualisations such as city layout posters
(, 2016) and 3D tactile maps
for people who are visually impaired (Kärkkäinen,
2016). Indeed, open and freely available map data
allows the creation of many diverse applications.
This paper describes the results of a research
project aimed at visualising spatial data in a virtual
environment, which is based upon data provided by
OpenStreetMaps. The origin of the visualised spatial
data could come from output of model simulations,
GIS data files or real-time data provided by online
data services. We started with the generation of a 3D
world (Figure 1) based upon OSM data to create a
solid base for adding other data sources, as well as
creating a visual reference point when the spatial
data is viewed. In order to create a realistic
experience, the Unity (Unity, 2016) game engine
version 5.4 is used.
Figure 1: Generated visualisation of the port of Rotterdam,
Various tools have been developed or are currently
in development to visualise OSM data in 3D. Some
tools generate their visualisations in a web browser
such as F4Maps (F4map Demo - Interactive 3D
map, 2016), Vizicities (UDST/vizicities, 2016) and
OSMBuildings (, 2016).
Joling A.
Open Data Sources for 3D Data Visualisation - Generating 3D Worlds based on OpenStreetMaps Data.
DOI: 10.5220/0006164902510258
In Proceedings of the 12th International Joint Conference on Computer Vision, Imaging and Computer Graphics Theory and Applications (VISIGRAPP 2017), pages 251-258
ISBN: 978-989-758-228-8
2017 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
Other tools are standalone applications, such as
osm2world (Knerr, 2016) and can save 3D model
files, which in turn can serve as an input for other
applications. All of these tools use the same OSM
database as input, and have to process the data in
order to generate the 3D worlds.
Few projects use a game engine to load OSM
data. ActionStreetMap (,
2016) generates 3D worlds in Unity and allows a
player to walk through and interact with the map as
well as saving a scene back to the OSM XML file
format. It also features the ability of dynamic
loading of world elements, which is not present in
our own project.
OSM data can be downloaded from various
websites. One way to acquire this data is by
downloading a data extract based upon
administrative borders such as countries, provinces
and states (, 2016). Another
way is to perform an actual query to receive an
extract of a data set. One such query language is the
OSM Extended API (Xapi - OpenStreetMap Wiki,
2016), which was used in this project. Our query
uses only the bounding box query option, as all data
is potentially useful for 3D visualisation. Therefore
the data of interest is extracted at a later step. The
Xapi query language always returns the latest
version of the dataset, previous versions of nodes
(map elements) are not returned. The API returns
files in the OSM XML format which can then be
used by other software.
3.1 Processing the Data
There are many tools that can operate on OSM files.
A large single XML file is difficult to index for a
real-time application, which is why additional pre-
processing is required before we start generating
world geometry. OSMFilter (Osmfilter -
OpenStreetMap Wiki, 2016) is used to select the
nodes that are interesting in the virtual environment:
land use, buildings, waterways and infrastructure
such as roads, railroads, high voltage towers and
windmills. Some objects, such as windmills, have
been selected for their generality. These objects are
created as Unity prefabs that can easily be placed on
the terrain and do not require extra processing. They
add an extra dimension to the terrain as they are
often landmarks in an area. After filtering, the
command line application ogr2ogr.exe (,
2016) is used to convert the OSM XML file to a
SQLite database. This will automatically categorise
the sources of data in tables with the names equal to
the type of data stored: lines, multilinestrings,
multipolygons and points. Geometry data is stored in
the Well Known Binary (WKB) format.
3.2 Challenges of the OSM Data
Using OSM data does come with potential
challenges when creating visualisations. Although
the amount of data in the database is steadily
growing, many areas in the world are still
incomplete which can leave lots of gaps between
buildings in cities. Aside from that, the actual nature
of OSM has both pros and cons; everyone can edit
the database after making a free account. The
advantage of this is that changes in the real world
are accounted for quickly in the database.
Unfortunately it also means that data can be
incomplete (Figure 2) or mapped incorrectly.
Figure 2: A city which is incompletely mapped.
Tallahassee, USA.
Therefore, certain assumptions in visualisations need
to be made. For example, some of the problems that
have been noticed are nodes with a building tag
which are part of storage underneath a bridge. Or
small wind turbines placed on roofs which in the
generated world become large turbines. This is a
challenge that every 3D OSM visualisation must
All terrain and objects are generated as triangles and
use Unity’s Mesh object to be rendered. In order to
improve performance most of the geometry is
marked as static geometry and aggregated as much
as possible in one single mesh object.
IVAPP 2017 - International Conference on Information Visualization Theory and Applications
In this project five elements have been marked as
having significant influence for the visual
representation of the terrain. These are: roads, trees,
buildings, water surfaces and ground textures. Of
course, there are many more man-made objects,
some of which are tagged, but many of these do not
add an extra sense of positional awareness on the
average scale of our map; they are too small and far
away to be seen.
4.1 Terrain Mesh Creation
The terrain is generated using tiles based on the
OSM zoom level 14 (Zoom levels - OpenStreetMap
Wiki, 2016). This was an early design choice based
upon the average expected zoom level of the world,
a trade-off between required tiles and expected map
detail. OSM tiles use a Cartesian coordinate system
based upon EPSG:3857. The actual downloaded
OSM data makes use of the EPSG:4326 (WGS84)
coordinate system.
The elevation of the terrain is based upon the
SRTMv3 (Shuttle Radar Topography Mission, 2016)
global elevation map. This data is freely available
and has accuracy from 30 to 90 meter depending on
the area of interest.
All terrain related information is generated and
rendered per tile using Maperitive (,
2016). One single tile always represents an OSM tile
at zoom level 14. Terrain is generated by building
square geometry with a variable number of vertices.
Originally a 32x32 regular grid was used to build
the terrain tiles. But in order to reduce triangle
count, a simple method of Level of Detail (LOD) is
implemented by making use of an error threshold to
determine where to place the vertices. This
technique is loosely based on existing algorithms
(Garland and Heckbert, 1995). The threshold is
configured to be a 15% difference in elevation
between the last vertex and the vertex that is being
processed. When the threshold is exceeded, a new
vertex is inserted at the location and will serve as the
new starting point for the next difference
comparison. Every terrain tile is built using this
algorithm (Figure 3). For convenience, however, all
terrain tiles will have vertices inserted at the four
corner points, such that these will always connect
properly and also guarantees that later tile
tessellation algorithms generate a square exactly the
size of a single OSM tile.
For all the edges of the terrain we store the
vertices in a list. We keep track of these as
neighbouring terrain tiles will need to share the same
vertices at the same location in order to prevent
seams from appearing at the mesh boundaries due to
differences in the elevation.
Neighbouring tiles are quickly determined by
using the OSM coordinates (x -1 or +1 for horizontal
neighbours, y-1 or y+1 for vertical neighbours).
Figure 3: An unoptimised (left) and optimized (right) tile.
When the terrain geometry for a tile has been
processed and all vertices have been created, the
tessellation LibTessDotNet (speps/LibTessDotNet,
2016) library is used to create renderable triangles
using Delaunay triangulation.
This process is repeated three times with
different tolerance values in order to create meshes
for the LOD system. The vertices at the mesh
boundaries will always be kept the same, however.
This allows for a seamless transition from one LOD
level to another while preventing holes from
appearing between the meshes in different LOD
levels. The highest LOD level (with the most
vertices) is used for this.
This algorithm results in geometry which has a
lower polygon count in flat areas, while areas with a
more diverse elevation will have a higher polygon
count where detail is needed.
4.1.1 Texture Generation
Terrain textures are generated using Maperitive.
Maperitive reads the downloaded OSM file and can
then render tiles in the OSM coordinate system, for
different zoom levels. These tiles are generated with
styling information based on rulesets which define
the visual representation of elements on the map.
Maperitive can be run headless (without user
interface) to load large OSM XML files and is
programmable with Python scripts.
Open Data Sources for 3D Data Visualisation - Generating 3D Worlds based on OpenStreetMaps Data
After the tiles have been generated, the tool
DXTCrunch (BinomialLLC/crunch, 2016) is used to
optimize and reduce the memory footprint of the
tiles as well as creating mip-maps in order to provide
LOD for textures and reducing moiré effects. The
files are saved in the compressed image format
DXT1 which is common for use in game engines.
Alternatively an aerial map can serve as a base
layer by providing a Web Mapping Service (WMS)
for such tiles (Figure 4). This creates a better
understanding of the terrain type and land cover. But
it comes with the risk of being low in resolution or
having colour differences between tiles due to
different times of photography or cloud cover.
Figure 4: Difference between an aerial WMS layer and tile
generated with Maperitive.
Additionally, georeferenced shapefiles can be
loaded on top of the created geometry to visualise
different kinds of data (Figure 5).
Figure 5: City of Colombo, Sri Lanka with the May 2016
flood extend map added (data courtesy of Survey
Department of Sri Lanka).
4.1.2 Mesh Colliders
The default “mesh colliders” of Unity are used to
build a collision mesh for the generated terrain tiles.
These can be used to perform hit detection using ray
casting techniques. Raycasts are used to position
certain objects (trees, roads) exactly on the terrain,
such that they do not float above the terrain.
All LOD levels share the collider of the highest
and most accurate LOD level. This could lead to
some floating objects on the terrain, but only when
these object are so far away from the camera that
such errors are practically invisible. When the user
gets closer to the terrain objects, the terrain will be
shown in the highest LOD level and therefore
objects should match with the terrain.
4.2 Building Generation
The building data that OSM contains is most of the
time a “floor plan”. So only the vertices are provided
that composes the outline of the building.
Before buildings are generated, some pre-
processing scripts using the GDAL libraries
(, 2016) are used to clip the buildings that
belong to a certain tile. The tile’s x-y coordinates are
stored for each row in the database to make it easy to
Buildings are generated for each tile rather than
as one big mesh. The latter would make it
impossible to load data dynamically depending on
the camera frustum position. Currently these tiles are
not loaded on demand yet, which is a feature that is
planned for the future. Using tiles the rendering can
also effectively cull buildings that are not visible to
the camera. If it were just multiple large meshes
covering the whole terrain area, one building could
trigger the rendering of thousands of other buildings,
therefore increasing the number of rendered
Some buildings have additional information such
as height (height of the building), number of floors
and minimum height (distance from the ground). A
single building can be made of several parts. In this
case the OSM attribute building:part will be set to
“yes”. Combined with the attribute min_height, this
is a powerful option to create buildings which are
more than just an extruded floor plan, as building
parts can be stacked on top of each other (Figure 6).
Figure 6: Euromast tower in Rotterdam, the Netherlands.
It consists of multiple geometry elements using the
“building:part=yes” tag.
If the height of the building is available, this
information is used directly in order to extrude the
mesh. Otherwise, when the number of floors is
IVAPP 2017 - International Conference on Information Visualization Theory and Applications
known, the “formula for calculating the height of a
‘mixed-use’ or ‘function unknown’ tall building”
(, 2016) is used to determine building
height. When none of these are available, a default
height of 6 meters is used.
To generate 3D buildings several steps need to
be performed. The building information is already
stored per OSM tile in an earlier step. To make
culling of buildings straightforward, all buildings are
attached to the tile on which they are standing. For
each tile we execute the following steps:
Query SQLiteDB for buildings of tile
For each building in tile
Merge adjacent vertices to remove
building walls
Tessellate outline to triangles
Copy outline and elevate by building
height to create ceiling
Build walls between floor and
Boundary information is returned by the tessellation
library, which we use to build the “roof” of the 3D
building. This is a copy of all floor plan vertices
where the y component has been increased by either
the calculated height or a fixed default height value.
Then we generate the walls by looping through
the edges of the buildings and generating triangles
for each inner or outer edge.
All these generated vertices are added to the
meshbuilder class which will automatically build
meshes taking into account Unity’s maximum vertex
limit of 2
(65536) vertices into account.
Each building has a white diffuse colour. OSM
data sometimes contains wall colour information but
this is not so common. Therefore it was decided to
proceed with a uniform colour approach, while
skipping efforts to texture buildings with a collection
of premade wall textures.
4.2.1 Fixed Model Buildings
A number of buildings are not dynamically
generated. Often buildings or structures are
described by a point object (feature) instead of a
polygon and therefore do not have the necessary
information to generate a 3D model.
In this case some prebuilt meshes are used. For
example, for objects such as: high voltage towers,
windmills and wind turbines. Occasionally more
information is available for an object: the type of
high voltage tower (Tag:power=tower, -
OpenStreetMap Wiki, 2016) or the blade diameter of
a wind turbine (Tag:generator:source=wind -
OpenStreetMap Wiki, 2016). With this information,
it is possible to select a 3D mesh from a library of
prebuilt 3D meshes. Currently in this project only
one pre-made mesh is used per recognized point
4.3 Trees and Forested Areas
Tree placement in this application takes three types
of OSM data sources into account. The land use type
landuse=forest is used for random tree placement
while sometimes an actual single tree is defined
(natural=tree) or a row of trees (natural=tree_row).
4.3.1 Forest Areas
The land use type forest is used to randomly place
trees in a specified area. No trees should be
generated outside these areas. Therefore a tree
placing algorithm has been implemented. Polygons
in this algorithm are created using the
LibTessDotNet library which also takes care of
holes in the geometry.
For each polygon of natural type forest
Tessellate to a 2D mesh using the
polygon outline
Calculate expected tree count
Begin loop for expected tree count
Choose random triangle of polygon
Get random point in selected
triangle by using barycentric
Determine if there is already a
tree at the given random location
using a radius test
If no tree nearby
Place tree and continue
Try another random location up
to three times.
If no acceptable location is
found, skip tree and continue.
The maximum number of trees that are placed
per polygon is calculated using the area of a polygon
multiplied with a tree density factor. A density of 1.0
means that there will be one tree per square unit of
the polygon. An absolute maximum regardless of
polygon size ensures that very large polygons will
not generate thousands of trees.
Open Data Sources for 3D Data Visualisation - Generating 3D Worlds based on OpenStreetMaps Data
4.3.2 Reducing Uniformity of Trees
The vertices of trees are modified by a randomiser
function to give each tree more of an individual and
unique look (Figure 7). First, the size is uniformly
modified using a scale of 0.9 1.1 times the actual
size. Therefore, all the trees vary in size. Secondly,
the rotation of the tree is changed. Rotation of the x-
axis is from 0 to 360 degrees and on the y- and z-
axis the angle is between -2 and 2 degrees to make
sure that trees are not all pointing upwards and
perfectly straight. Finally, all trees have some colour
variation applied by using vertex colours. For each
tree a random greyscale colour is determined
(between RGB 100 to 255), which is then applied to
all the tree vertices. The trees are then added to the
meshbuilder class which will again make sure that
meshes are split when reaching Unity’s mesh limit,
similar to the construction of buildings. The trees
object will become a child of the terrain tile in order
to perform efficient frustum culling. When the tile
becomes invisible to the camera, so will all the trees
on top of it.
Figure 7: Trees without variation (left) and with (right).
When rendering, the fragment shader will multiply
the tree’s texture colour with the vertex colour,
giving each tree a different colour. All these steps
combined lead to a tree placement system which
creates diverse forests, while keeping the rendering
batches intact. This means that there is no
performance loss for having many randomised trees
compared to non-randomised trees.
4.3.3 Level of Detail for Trees
Unity’s own LOD system is used to reduce the
number of triangles rendered for trees that are far
away. A LOD system tries to lower the number of
rendered triangles by replacing detailed meshes with
meshes that have a lower polygon count. These
systems work, using the fact that in perspective
views, objects become smaller when distance to the
camera is increased. With properly setup LOD
levels, it is unlikely for the user to notice the
changing geometry.
For each tree type, three different meshes have
been created in 3D modelling software: A normal
“base” tree and two types of low-polygon meshes
based upon the base tree (Figure 8).
Figure 8: Two types of trees and their three LOD levels.
The simplified trees are made like this to prevent
“popping” of the geometry. Three meshbuilder
classes are used simultaneously to generate the LOD
meshes. Each tree that is placed inside the first LOD
(high detail) meshbuilder is also automatically added
to the other two mesh builders. This will
immediately create the meshes for the medium and
low-polygon trees. Unity’s LODGroup component is
then added to this object so that Unity can
automatically determine when to render which mesh
at what distance.
4.4 Infrastructure
Various types of infrastructure are visualised as
well: Most types of car roads and railways are
visualised. The 3D models of the roads are generated
using the linestrings that are available from the OSM
data. OSM provides many categories for these. The
data is specifically filtered as follows: ‘unclassified’,
‘motorway_link’, ‘road’, ‘motorway’, ‘trunk_link’,
‘primary_link’, ‘service’, ’secondary_link’,
‘tertiary_link’, ’primary’, ’secondary’, ‘tertiary’
and ’residential’. Some categories are currently
skipped (e.g. trails) because they are rather small
and do not add significant detail to the virtual world.
They might be visible on the ground layer tiles.
An important aspect of roads that requires
attention is multiple layered roads such as
intersections, tunnels and bridges. OSM data has a
solution for objects which share the same x-y
coordinates but not elevation. The attribute layer
makes it possible to distinguish these. This way 3D
roads can be constructed which are layered on top of
each other or join two different levels together, such
as intersection junctions.
The default width of the roads is 5 meters.
Additionally, width is calculated when properties are
available such as the number of lanes or if an actual
IVAPP 2017 - International Conference on Information Visualization Theory and Applications
width has been set. The width of a single lane is
currently configured to be 3.5 meters. This number
varies internationally, however. The road meshes are
generated by using a quadratic Bézier curve
algorithm. Corners become rather angular when road
sections are drawn straight from point to point.
These quadratic curves provide much smoother and
more realistic representation of the roads (Figure 9).
Figure 9: Top-down view of point to point roads (left) and
quadratic curves (right).
4.5 Water Surfaces
Various sources of water surfaces can be found in
OSM data; these are of the type multipolygon in the
earlier generated SQLite database. OSM data has
many classifications of water types (e.g. rivers,
lakes, canals, etc.). These polygons are tessellated
directly without additional processing. One aspect
that has to be considered is that some water surfaces
such as oceans might not be mapped in OSM as
polygons. Rather, their coastlines have been
mapped. Datasets which contain these as polygons
can be downloaded freely (,
2016). Texture mapping of these water surfaces is
based upon their absolute position in the virtual
world. A variation of flow maps (Vlachos, 2010)
gives these surfaces more water-like dynamics.
Normal implementations of the flow maps
commonly use textures for velocities of the water.
But in our water surfaces vertex colours are used
instead, as there is no need for high resolution
flowing water, while also reducing the memory
footprint for each surface. In order to make sure
there are no unexpected colour changes in the water,
the polygons do not share their vertices and every
triangle has unique vertices.
This paper covered an approach to generate a 3D
virtual world based upon OSM data (Figure 10).
Various approaches have been shown that were used
to generate terrain tiles, perform tree placement,
create infrastructure of roads and railways, plus
generating polygons of water surfaces.
There is still room for improvement by
implementing various other techniques for
generating efficient geometry. Recent versions of
Unity support GPU instancing. This creates
opportunities in displaying massive amounts of
geometry, such as trees, without having an enormous
performance impact. Recent DirectX versions
support dynamic tessellation which allows the
creation of details on the vertex shader itself without
having to generate additional vertices on the CPU
Another improvement would be to generate
geometry on the fly instead of only once during start
up. Dynamic creation of tiles makes it possible to
explore any place in the world without running into
potential memory issues, as well as reducing loading
times at the start of the virtual environment.
Batching of terrain tiles could be further
optimized by making use of texture atlases. A single
4096x4096 pixels texture can fit up to 16x16 terrain
textures. This would reduce the number of draw
calls by a factor of 256. Care needs to be taken
regarding the mip-mapping of these texture atlases
as border pixels might bleed to the texture of
neighbouring tiles. It is very likely that some of the
pre-processing can be skipped by making use of the
OSM Spatialite-tools (, 2016). These tools
create a SQLite database with spatial extensions
which provide a fast way to query geometry from
the database. As well as keeping OSM node
references, which potentially allows better merging
of geometry.
Figure 10: Visualisation of Hamburg, Germany.
This research is part of the Strategic Research
Programme on Software Innovation of Deltares,
Open Data Sources for 3D Data Visualisation - Generating 3D Worlds based on OpenStreetMaps Data
funded by the Ministry of Economic Affairs, the
REFERENCES (2016). ActionStreetMap.
Available at:
(Accessed 17 Oct. 2016).
BinomialLLC/crunch. (2016). BinomialLLC/crunch.
Available at:
(Accessed 17 Oct. 2016). (2016). Calculating the height of a tall building
where only the number of stories is known. Available
GB/Default.aspx (Accessed 17 Oct. 2016). (2016).
Available at: (Accessed
17 Oct. 2016).
F4map Demo - Interactive 3D map. (2016). F4map Demo
- Interactive 3D map. Available at: (Accessed 18 Oct. 2016). (2016). Free worldwide Garmin
maps from OpenStreetMap. Available at: (Accessed 17 Oct.
Garland, M. and Heckbert, P. (1995). Fast Polygonal
Approximation of Terrains and Height Fields. (2016). GDAL: ogr2ogr. Available at: (Accessed 17 Oct.
2016). (2016). Projects | Humanitarian
OpenStreetMap Team. Available at: (Accessed 17 Oct. 2016).
Kärkkäinen, S. (2016). Tactile Maps Easily | Touch
Mapper. Touch Mapper - Tactile Maps for the
Visually Impaired. Available at: https://touch- (Accessed 17 Oct. 2016).
Knerr, T. (2016). OSM2World. Available
at: (Accessed 17 Oct. 2016).
OpenStreetMap. (2016). OpenStreetMap. Available at: (Accessed 17
Oct. 2016). (2016). Coastline datasets | Data
| OpenStreetMapData. Available at: http://openstreet (Accessed 17 Oct. 2016). (2016). OSMBuildings Index.
Available at:
OSMBuildings/ (Accessed 17 Oct. 2016).
Osmfilter - OpenStreetMap Wiki. (2016). Osmfilter -
OpenStreetMap Wiki. Available at:
(Accessed 17 Oct. 2016). (2016). OsmAnd - Offline Mobile Maps and
Navigation. Available at:
(Accessed 17 Oct. 2016). (2016). Maperitive. Available at: (Accessed 18 Oct. 2016).
Shuttle Radar Topography Mission. (2016). Shuttle Radar
Topography Mission. Available at: (Accessed 18 Oct.
2016). (2016). spatialite-tools: spatialite-tools.
Available at:
tools/index (Accessed 20 Oct. 2016).
speps/LibTessDotNet. (2016). speps/LibTessDotNet.
Available at:
(Accessed 17 Oct. 2016).
Stats - OpenStreetMap Wiki. (2016). Stats -
OpenStreetMap Wiki. Available at: (Accessed 17
Oct. 2016).
Tag:generator:source=wind - OpenStreetMap Wiki.
(2016). Tag:generator:source=wind - OpenStreetMap
Wiki. Available at:
wiki/Tag:generator:source%3Dwind (Accessed 17
Oct. 2016).
Tag:power=tower. (2016). Tag:power=tower -
OpenStreetMap Wiki. Available at: (Accessed
17 Oct. 2016).
Triangle.NET. (2016). Triangle.NET. Available at: (Accessed 17 Oct.
Unity. (2016). Unity - Game Engine. (online) Available at: (Accessed 20 Oct. 2016].
UDST/vizicities. (2016). UDST/vizicities. Available at: (Accessed 17 Oct.
2016). (2016). urban shape - paolo
gianfrancesco. Available at: http://www.paolo (Accessed 17
Oct. 2016).
Vlachos, A. (2010). Water Flow in Portal 2. Slides at:
raph2010_vlachos_waterflow.pdf (Accessed 17 Oct.
Zoom levels - OpenStreetMap Wiki. (2016). Zoom levels -
OpenStreetMap Wiki. Available at: http://wiki. (Accessed 17
Oct. 2016).
Xapi - OpenStreetMap Wiki. (2016). Xapi -
OpenStreetMap Wiki. Available at: (Accessed 17
Oct. 2016).
IVAPP 2017 - International Conference on Information Visualization Theory and Applications