geometry, but creates a new version of it. All versions are kept
indefinitely thereby adding a temporal dimension to the system.
Propesttes Sensis onus
Polygon psaperties
Obstacle Route
ir rr e Ter Th deem
, e
Figure l. The desktop interface. Polygons denote real-world
obstacles.
Figure 2 shows an overview of the system's components.
Users’ observations are saved in the PostGIS database first and
move later to GFT. GFT holds the latest snapshot of the data,
whereas PostGIS stores all data ever entered.
Analysis and cooperation: One of the presented application’s
main merits is the stimulation of crowdsourced data collection.
As already noted, the crowd is capable of more than data
collection only. To leverage this capability, the built application
supports the calculation of the shortest route. The routing
functionality turns the application into more than a data silo.
The purpose of this analysis is twofold. On one hand it
provides rescue workers with an automated shortest path
analysis tool. On the other hand it acts as a return of investment
for the crowd as they can use their own data for their own
routing needs. The people's usage of their own data acts as an
incentive to generate better and accurate data, and keep it up to
date.
Users are encouraged to cooperate on several different levels.
First, they can work together on collecting the most accurate
information they can find through all the means they are
comfortable with. For instance, some may draw information
from their Twitter network, whereas others may have some
experience working with satellite images. Both types of users
can enter their data in the application and compare the results. A
third user may then check both of their results. Another type of
cooperation is found between the desktop and mobile users. The
mobile users’ task is to make quick and numerous observations
which the desktop user then synthesizes into polygons. Both
users benefit: the mobile user can work autonomously without
worrying about what other mobile users are doing, while the
desktop user can observe the whole operation from a higher
vantage point using more powerful hardware without needing to
worry about the difficulties of working in the field.
The tools available for collaboration are the comments section
on the desktop and mobile interfaces and the communication
facilities of GFT. GFT allows users to discuss all facets of the
data in its tabular view. Users can place comments on columns
rows and individual cells.
(Social media
| Information
sources
ER / Desktop | / Mobile |
iinterface : Interface |
Official t j rer
sources | i Nd Dia
AJAX, JSON
bo Geometnes, um.
Fs —-U| comments Bau
GM Fusion |
PostGIS Python API Tables |
it id
th |i
En Ec £a i
HE i
Remote Hi il
sensing | sus E
products | i T r
{ 60 : i © 5 X
Developers General public
Figure 2. The system's components. Data streams are represented
by arrows. The users on top are the data collectors. They gather
data and enter it through the desktop and mobile interfaces. The
text on top and left of the lines denote the payload of the data
stream while the text on the bottom and right of the lines denotes
the used technology
Data presentation, visualisation and sharing: as discussed in
section 2.2, crowdsourcing initiatives are successful and gain
momentum when they are open and tuned to the user's
capabilities and needs. In terms of storage, open means that the
data is easy to access. Two user groups are targeted here:
"normal" users (informal part of second tier) who are not able or
willing to work with raw data and prefer a pre-processed
version of it, and savvy computer users (volunteers in the third
tier) who want access to the raw data. The built application
satisfies the needs for these two groups through the following
means: the web and mobile interfaces, GFT's export
functionalities and visualisations, and the developer API. The
web and mobile interfaces allow people to not only input data,
but to also browse the collected information. GFT's web-
interface supports tabular and mapped visualisations. The data
can be extracted as KML. The API gives access to the data in
developer friendly formats such as Well-known Text, KML,
GeoJSON, etc.
5. CONCLUSION
Crowdsourcing is the unplanned coming together of a highly
diverse group of people who use the latest technology and data
formats and sources available to aid a certain disaster
management cause. It is difficult to predict beforehand how
many people with what skills will participate and which tools
they will deploy. Designing an application for a crowdsourcing
effort therefore seems counter to its volatile nature. What 1s
needed, rather, is not a complete system, but a set of
components which are well developed, well documented and can
450
seamlessly bi
needs. This v
disaster mana
The main str
disaster mane
analysis in th
data for othe
as they too c
information i
first-hand hoy
the routing s
might change
“contribute cc
communicatio!
community .
Parallels betw:
initiatives and
notice and fos
technology th
they have mo
used technolo
hackers to ada
sourcing a pro
turn results in
The applicati
deploying it ir
and principles
research enviro:
Trust is an in
Mechanisms
trustworthiness
implemented.
brought forwai
current app lice
instance an ap]
able to discus:
obstacles. Imp
strengthens th
examination
Àn in-depth s
performed. Dra
input method ax
to assess the bes
Currently, an ir
to function. T|
Cannot be taken
Mechanism need
to function in th
Google Maps is
the time of th