st responders and
ation.
and applications,
arted to move GIS
gies make it easy
vers through the
ices have become
graphical data and
d lightweight GI
point of view, a
d GIS operations,
them on the road.
>ment systems are
them are limited.
ems and based on
s, have identified
sary for disaster
| as
ind dynamic access
cy at hand.
1 Archives
n presentation
aching author and
ion
outing application
Location Services
s shortest path
by allowing users
ip plication is built
Isourcing powers.
rface, speed and a
anagement design
;mall WebGIS has
ind automate the
; with information
ıration. The client
nunicates through
( with a RESTful
sed to implement
esentational State
buted hypermedia
sso et al. 2008). In
a server and has à
unique identifier. In web-based systems, this identifier is known
as à Unified Resource Identifier (URI). Clients access and
manipulate the resources by standard HTTP methods.
Obtaining the current state of a resource, for instance, is done by
sending a HTTP GET request to a resource's URI. The server
processes the request and sends a representation of the
resources current state as a XML, JSON (the lightweight data-
interchange format JavaScript Object Notation) or simply as a
plain text document.
REST is implemented using Django”. Django is a Python web
application framework that cases web application development
by automating and abstracting low-level tasks and operations
and by automatically building the database schema. Developers
can then focus on the application logic. The GeoDjango plugin
makes Django spatially enabled. GeoDjango uses open source
libraries such as GDAL/OGR and GEOS to interact with and
manipulate geographical information. Django is chosen for its
simplicity, ease of deployment and very high quality
documentation. Alternatives such as GeoServer are full-fledged
applications. that offer more functionality than is currently
required.
Data is stored in two databases: PostGIS and Google Fusion
Tables. PostGIS is chosen as the main data store as it is a well-
known, powerful, open source spatial database. It enjoys the
momentum discussed in section 2.2. Google Fusion Tables“ is "a
cloud-based data management and integration service" that is
designed specifically with collaboration, data sharing, the Web
and usage by non-technical users in mind (Gonzalez et al.
2010b). Fusion Tables stores (geographical) data in tabular form.
Tables can be shared with the world or a selected group of
people all of which can have different roles i.e. viewers and
editors. The data is accessible through a Web interface and can
be visualized in several different ways including as geometry on
a map. Tables storing geographical information can be exported
as KML.
The used mapping framework is Google Maps. The WebGIS
application is hosted on the author’s website’. The source code
is hosted on the code collaboration website Github®.
4. METHODOLOGY AND IMPLEMENTATION
Geographical Information Systems have four main capabilities:
data gathering, data storage and management, data analysis and
presentation. The application presented in this paper extends
these by implementing the design patterns and crowdsourcing
mechanism described earlier on in order to create a WebGIS fit
for disaster management.
Non-expert users interact with the application through a
desktop interface and a mobile interface. To identify any
———— re
5 . .
https://www.djan goproject.com/
6 Www Eoogle.com/fusiontables
7
http://gmer.ndkv.nl/
http://www. git hub.com ndkv/gmer/
obstacle, users draw a polygon on the map or put a simple
marker at the location of the blockage. Desktop users asses the
condition of the infrastructure by tapping into geographical
information sources such as satellite images, official reports,
etc, but also into social media data sources such as blogs,
Facebook, Twitter, etc. The mobile interface allows for the
collection of data through a mobile device such as a smartphone.
Mobile users act as sensors and report on the status and health
of the infrastructure. Expert users interact with the application
by way of an API.
The following sections cover the four GIS components and
discuss how these have been extended, what user interactions
take place and which disaster management and crowdsourcing
design patterns are implemented.
Data gathering, storage and management: The two types of
interfaces have similar functionality: users are able to mark
blocked streets and areas, create routes, read obstacle metadata
and read and write comments about individual obstacles. Both
interfaces display the same information i.e. the desktop users
see what the mobile users have mapped and vice versa.
The desktop interface has four panels: a map, obstacle and route
creation controls, obstacle properties panel and a comments
panel (Figure 1). Users create obstacles and routes using the
controls under the map. An obstacle is defined by drawing a
polygon on the map that represents a blockage. Users define
routes by providing a point of departure and a point of arrival
after which the implemented routing algorithm finds the shortest
path around all obstacles. See Nedkov and Zlatanova (2011) for
a detailed discussion on the routing algorithm.
The panels to the right of the map harbour the crowdsourcing
mechanisms discussed in section 2.2. The properties panel
provides an overview of obstacle metadata (e.g id, owner,
creation date, type, etc.), and controls to modify obstacle
geometry and delete obstacles. The comments tab acts as the
main communication channel. Users can discuss the each
obstacle separately. As such, discussion can be held on the
origin, validity, history, etc. of each obstacle.
The mobile interface looks simpler than its desktop counterpart
but contains almost the same functionality. Users select
polygons by tapping on them. Obstacles are created by entering
points instead of polygons since we believe that drawing
polygons may prove too cumbersome on a touch screen device.
However, the routing algorithm needs polygons to operate
properly so the points must be turned into polygons. This is
done by the desktop users who look at the points and connect
them in order to create polygons. The points are removed once
the polygon is drawn.
PostGIS acts as the main data store while Fusion Tables acts as
a non-expert data dissemination and backup, and cooperation
facility. PostGIS stores obstacle geometries which are versioned
i.e. modifying obstacle geometry does not overwrite the original
449
