University of Southern California Dissertations and Theses

A contributory Web-based application for documenting historic resources: French colonial era art deco architecture in Hanoi

(USC Thesis Other)

A contributory Web-based application for documenting historic resources: French colonial era art deco architecture in Hanoi

PDF

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content

A CONTRIBUTORY WEB-BASED APPLICATION
FOR DOCUMENTING HISTORIC RESOURCES:

FRENCH COLONIAL ERA ART DECO ARCHITECTURE IN HANOI

by

Annabel Lee Enriquez

A Thesis Presented to the
FACULTY OF THE USC GRADUATE SCHOOL
UNIVERSITY OF SOUTHERN CALIFORNIA
In Partial Fulfillment of the
Requirements for the Degree
MASTER OF SCIENCE
(GEOGRAPHIC INFORMATION SCIENCE AND TECHNOLOGY)

December 2015

Copyright 2015 Annabel Lee Enriquez

ii
ACKNOWLEDGMENTS
I am very appreciative to my thesis advisor, John P. Wilson, and the other members of my thesis
committee, Jennifer Swift and Robert Vos, who have been patient and supportive during the long
process of producing a web application and writing the corresponding thesis document.
I am also grateful for the advice and guidance given to me by Leen Meganck and Koen
Van Daele, both of the Flemish Heritage Agency. Their knowledge about heritage inventories
and heritage inventory applications has proven invaluable in creating and developing this project.
In addition, a special thanks is due to Troy Barbu, who has the distinction of being the
first contributor to the web application and whose candid feedback earlier during development
helped to shape the eventual application.
Lastly, I would like to acknowledge my many colleagues at the Getty Conservation
Institute, each of whom have helped to shape my thoughts and opinions about heritage
conservation in general, the importance of best practices in inventories and data management,
and the potential of new technologies in advancing the field.

iii
TABLE OF CONTENTS
ACKNOWLEDGMENTS ii
LIST OF TABLES viii
LIST OF FIGURES ix
LIST OF ABBREVIATIONS xi
ABSTRACT xiii
CHAPTER ONE: INTRODUCTION 1
1.1 Motivation 1
1.1.1 Cultural Heritage Inventories 2
1.1.1.1 Definitions 2
1.1.1.2 Importance of Cultural Heritage Inventories 4
1.1.1.3 Challenges to Creating and Maintaining Cultural Heritage Inventories 6
1.1.2 French Colonial Era Architecture in Hanoi 7
1.1.2.1 Survey Area in Hanoi 8
1.1.2.2 Cultural Heritage Resource Management and Inventory Activities in Hanoi 11
1.2 Objectives 12
1.3 Organization of Thesis 13
CHAPTER TWO: RELATED WORK 15
2.1 Current Web-based Heritage Site Inventories 15
2.1.1 Evaluating Web-based Heritage Site Inventories 15
2.1.1.1 Usefulness 16
2.1.1.2 Usability 19
2.1.1.3 Desirability 19

iv
2.1.1.4 Discoverability 22
2.1.1.5 Accessibility 23
2.1.1.6 Credibility 23
2.1.2 Findings 25
2.2 Documentation Standards for Built Cultural Heritage 25
2.3 Crowdsourcing as a Source of Cultural Heritage Site Documentation and Inventory 29
2.3.1 Crowdsourcing Definition 29
2.3.2 Applying Crowdsourcing to a Cultural Heritage Inventory 31
2.4 Web Application Development Technology 33
CHAPTER THREE: METHODOLOGY 39
3.1 Application Development 39
3.1.1 Target Workflow 39
3.1.1.1 Purpose 39
3.1.1.2 Requirements 40
3.1.2 Components 44
3.1.2.1 Input Data 46
3.1.2.2 Base Layer 49
3.1.2.3 Database and Mapping Platform 51
3.1.2.4 User Login and Authentication 52
3.1.2.5 Google Services 53
3.1.3 Programming 55
3.1.3.1 Client-Server Model for Web Applications 55
3.1.3.2 Programming Languages 58

v
3.1.3.3 Server-Side Implementation 59
3.1.3.4 Client-Side Implementation 61
3.1.3.5 Development Environment 62
3.1.3.6 Programming Challenges 64
3.2 Application Evaluation 65
3.2.1 Primary Evaluation 65
3.2.1.1 User Experience Requirements 65
3.2.1.2 Heritage Inventory Data Field Requirements 66
3.2.1.3 Crowdsourcing Task Requirements 66
3.2.2 Secondary Evaluation 67
3.2.2.1 Web Application Traffic 67
3.2.2.2 Contributions 67
3.2.2.3 Feedback Survey 67
CHAPTER FOUR: RESULTS 70
4.1 Application Description and Functionality 70
4.1.1 Home Page and Map 73
4.1.1.1 Home Page Map InfoWindow 73
4.1.2 Building Record Page 74
4.1.3 Login Page 76
4.1.3.1 Persona 77
4.1.3.2 Logout Page 77
4.1.4 Contribute Page 78
4.1.5 My (User) Contributions 80

vi
4.1.6 CartoDB Table View 81
4.1.7 Feedback Survey Form 81
4.2 Evaluation Results 81
4.2.1 User Experience Requirements 81
4.2.1.1 Usefulness Requirement 81
4.2.1.2. Usability Requirement 82
4.2.1.3 Desirability Requirement 83
4.2.1.4 Discoverability Requirement 83
4.2.1.5 Accessibility Requirement 83
4.2.1.6 Credibility Requirement 83
4.2.2 Heritage Inventory Data Field Requirements 84
4.2.2.1 Unique Identification Number Field Requirement 84
4.2.2.2 Recordation Date Field Requirement 84
4.2.2.3 Contributor Information Field Requirement 85
4.2.2.4 Location Information Field Requirement 85
4.2.2.5 Building Type and Category Field Requirement 86
4.2.2.6 Dating Field Requirement 88
4.2.2.7 Condition Status Field Requirement 88
4.2.3 Crowdsourcing Task Requirements 88
4.2.3.1 Correction Task Requirement 89
4.2.3.2 Contextualization Task Requirement 89
4.2.3.3 Classification Requirement 89

vii
CHAPTER FIVE: DISCUSSION AND CONCLUSIONS 90
5.1 Application Strengths 90
5.2 Application Weaknesses 91
5.3 Application Roadmap 93
5.4 Future Trends 94
5.5 Final Thoughts 96
REFERENCES 98
APPENDIX A: HANOI INVENTORY 103
APPENDIX B: ONLINE HERITAGE INVENTORIES 152

viii
LIST OF TABLES
Table 1 User Experience Evaluation Questions for Web-based Heritage Site Inventories 17
Table 2 Heritage Inventory Website Evaluation 26
Table 3 Comparison of mandatory fields specified by the Core Data Index to
Historic Buildings and Monuments of the Architectural Heritage and the
Core Data Standard for Archaeological Sites and Monuments 28
Table 4 Categorization of Crowdsourcing Projects in the Cultural Heritage Domain 30
Table 5 Classification of Crowdsourcing Initiatives in Cultural Heritage 31
Table 6 Comparison of Google Fusion Tables and CartoDB 37
Table 7 User Experience Elements and Web Application Requirements 42
Table 8 Core Data Index to Historic Buildings and Monuments of the Architectural
Heritage and Web Application Fields 43
Table 9 Crowdsourcing Tasks and Suitability for Contributory Inventory
Web Application 44
Table 10 Data fields for hanoifrenchcolonial table on CartoDB 51
Table 11 Feedback Survey Questions 68
Table 12 Dropdown field values on Contribute page 80
Table 13 Web Application Roadmap 93

ix
LIST OF FIGURES
Figure 1 Hanoi survey photograph locations, organized by architectural style 9
Figure 2 A sample of architecture styles in the Hanoi survey area 10
Figure 3 Thesis flow chart 14
Figure 4 User Experience Honeycomb by Peter Morville 16
Figure 5 Victorian Heritage Database 20
Figure 6 Recommended tours and Timeline browser sections from the Victorian
Heritage Database 21
Figure 7 CyArk Record for Chichen Itza. 22
Figure 8 Historic Preservation Screen from LA ZIMAS 24
Figure 9 Framework for public participation in scientific research projects 32
Figure 10 Framework for crowdsourced cultural heritage inventory based on Figure 9 32
Figure 11 CartoDB Integration with Web Applications 36
Figure 12 Web Application Components 45
Figure 13 An example of HoudahGeo locating a Hanoi photograph
along the GPS track 48
Figure 14 MapBox project screen 50
Figure 15 CartoDB visualization of hanoifrenchcolonial data layer 52
Figure 16 Google Analytics page for Art Deco Heritage in Hanoi 54
Figure 17 Programming Diagram 56
Figure 18 Client-Server Model 57
Figure 19 Development Environment Diagram 63
Figure 20 Application Flow Diagram 71

x
Figure 21 About page 72
Figure 22 Home page 73
Figure 23 InfoWindow screenshot 74
Figure 24 Building record page 75
Figure 25 Login page 76
Figure 26 Persona Pop Up Window 77
Figure 27 Logout Screen 78
Figure 28 Contribute page 79
Figure 29 My Contributions page 80
Figure 30 Feedback Survey on Google Forms 82
Figure 31 Main Record section of Building Record page 85
Figure 32 Contributions section of Building Record page 85
Figure 33 Location editing section of the Contribute page 86
Figure 34 Building Type dropdown list detail on Contribute page 86
Figure 35 Building (Functional) Type detail, accessed via hyperlink on
Building Record page 87
Figure 36 Free text field on Contribute page 88
Figure 37 Current Condition State dropdown list detail on Contribute page 88

xi
LIST OF ABBREVIATIONS
API Application Programming Interface
CIDOC Documentation Committee of the International Council of Museums
CIPA International Committee for Documentation of Cultural Heritage
CMS Content Management System
CRGIS Cultural Resources Geographic Information System
CRM Conceptual Reference Model
CSS Cascading Stylesheets
CSV Comma Separated Values
DSLR Digital Single Lens Reflex
EXIF Exchangeable Image File Format
FEMA Federal Emergency Management Agency
GIS Geographic Information System
GLAM Galleries, Libraries, Archives, and Museums
GLONASS GLObal NAvigation Satellite System
GPS Global Positioning System
GPX GPS Exchange Format
HDR High Dynamic Range
HTML Hypertext Markup Language
ICOM International Council of Museums
ICOMOS International Council of Monuments and Sites
JSON JavaScript Object Notation
KML Keyhole Markup Language

xii
KMZ Zipped KML File Format
PaaS Platform as a Service
PPSR Public Participation in Science Research
RDF Resource Description Framework
RDM Reference Data Manager
SaaS Software as a Service
SHPO State Historic Preservation Office
SKOS Simple Knowledge Organization System
SQL Structured Query Language
UNESCO United Nations Educational, Scientific and Cultural Organization
USC University of Southern California
UX User Experience
W3C World Wide Web Consortium
XML Extensible Markup Language
ZIMAS Zone Information and Map Access System

xiii
ABSTRACT
This thesis project consists of the development of a contributory web application to display and
gather information on French Colonial era Art Deco architecture in Hanoi, Vietnam. The goal of
this application is to create the foundation for a web-based spatial inventory of existing French
Colonial era buildings. The inventory is meant to advise policymakers and heritage organizations
on priority resources to protect the existing base of resources as well as to create a historic record
of the historic urban landscape. This is important because the push to modernize infrastructure in
emerging nations often leads to the destruction of the colonial heritage fabric in urban areas. An
inventory of what currently exists, and possibly what existed in the past, will help to digitally
record these sites, despite what occurred or may eventually occur in the physical places. Also as
part of its purpose, the application seeks to engage the general public, including interested
heritage professionals and scholars, by incorporating the ability to contribute information
through the correction and enhancement of current entries. The web application will incorporate
the minimum data standards for inventory of cultural heritage as specified in the Core Data
Index to Historic Buildings and Monuments (Thornes and Bold 1998). The initial dataset for the
application is based upon data collected during fieldwork in June 2012 and covers a self-defined
area of the French Quarter district of Hanoi. As a secondary purpose, the web application was
developed to be replicable by others who might choose to take and adapt the web application
model for their own heritage conservation-related purposes. As such, the web application
employs easy-to-use, relatively inexpensive, cloud-based tools and services, such CartoDB,
MapBox, Persona, Heroku, Bitbucket, and various Google products. In order to use many of
these services together, the web application was purpose-built using the well-documented and
flexible Python web development framework, Pyramid, in conjunction with the templating

xiv
system, Jinja2, along with the standard HTML, CSS, and JavaScript programming languages.
After instructional documentation is written and further development occurs as specified in the
application’s roadmap, the code, which is currently stored in a private repository on Bitbucket
will be opened for download and collaboration by others wanting to use and improve the
application model.

1
CHAPTER ONE: INTRODUCTION

1.1 Motivation
The economic growth of Southeast Asia, fueled by capital investment originating from outside of
the region, particularly from China, Japan, South Korea, and Australia, is rapidly modernizing its
urban landscapes, irreparably changing the character of its cities. For example, in 2010, the
construction of the South Korean-owned $1.05 billion Keangnam Hanoi Landmark Tower was
underway in Hanoi's new central business district, and plans for “the second tallest building in
Asia after the Burj Kalifa” were being circulated, prompting concern over the effects on Hanoi's
fragile architectural heritage (Stokes 2010).
Indeed, the push to become part of the developed world has the potential to create an
atmosphere in which the cultural heritage resources of the area are at risk of demolition or
significant alteration. In Asia, this pattern of sacrificing cultural heritage in the wake of
modernization is seen most prominently in Shanghai, where many of the city’s Art Deco
vernacular buildings were razed in order to build larger contemporary buildings (Girard 2007). In
the 1990s, approximately 600 of Beijing’s historic hutongs were destroyed in order build new
developments (Kaiman 2012).
As a result of the perceived threat to these resources, in 2012, the author of this thesis
project traveled to Southeast Asia to try to document what French colonial era buildings were
left. Because the region is fairly large, the informal field survey was limited to small areas in
several key cities, including Vientiane, Hanoi, and Phnom Penh. It consisted of taking photos
and recording geographic coordinates in order to create an eventual set of geo-referenced photos

2
of potentially significant buildings from the French colonial period.
Away from the field, each building was assigned a building style based on visual
inspection of the photograph and the initial assessment in the field. However, no other
information exists for each building documented. The purpose of this project, then, is to establish
a web application that facilitates the gathering of additional essential information for a subset of
the Hanoi photoset. This additional information will be defined by best practices in regards to
web-based geospatially-oriented cultural heritage inventories. However, before delving into
determining the requirements for the application, background information on cultural heritage
inventories and also French colonial era architecture in Hanoi are presented.
1.1.1 Cultural Heritage Inventories
In this section, the concept of a cultural heritage inventory is introduced, including definitions, a
discussion on why inventories are important in conserving cultural heritage resources, and an
outline of the challenges to creating and maintaining inventories.
1.1.1.1 Definitions
The conservation and management of built cultural heritage is dependent on adequate
documentation, primarily in the form of an inventory, of the actual heritage resources. One of the
most basic definitions of an inventory is "an itemized list of current assets" (Merriam-
Webster.com, 2015). However, an inventory can also refer to the process of creating this list in
the form of a survey (Merriam-Webster.com, 2015, 2). Both definitions are relevant for the
purpose of this project because a survey often determines what information is included in the
inventory list. (From this point forward, "survey" will be used for the process and "inventory"
will be used for the resulting list.) For example, in its Guidelines on Cultural Heritage, the
Council of Europe (an international human rights organization consisting of 47 European

3
member states) uses the survey definition of an inventory and defines it as "an official research
activity for the preliminary recording and documentation of cultural heritage assets. It provides
the basis upon which an evaluation may be made to: (1) determine whether or not the asset
should be legally protected; and (2) prepare a plan for its conservation whereby its value may be
permanently secured" (Council of Europe 2012, 19). This definition contains an imperative that
defines the contents of what information should be collected in a survey and hence, the eventual
inventory. In other words, in the cultural heritage field, an inventory may not be sufficient if it
does not provide sufficient information to evaluate a cultural asset or resource.
This project focuses on immovable cultural heritage, primarily in the form of buildings.
Immovable cultural heritage resources are literally resources that cannot be reasonably moved
from their respective locations and include architectural structures, archaeological structures and
features of cultural landscapes (Council of Europe 2012, 19). This highlights the importance of
geospatial information for such resources as location is intrinsic to their value as cultural
heritage. For example, the US National Register of Historic Places establishes a cultural
resource's integrity through the evaluation of seven qualities: location, design, setting, materials,
workmanship, feeling and association (National Park Service 2002). Two of these – location and
setting – are geospatial in nature. In the case of location, the geospatial information consists of
the actual location of the resource. In the case of setting, it refers to the resource's location
relative to its environment.
While a cultural heritage inventory is not explicitly geospatial in nature, it is implicit that
to be effective in its purpose (i.e. the conservation of cultural heritage resources) it requires
geospatial information for each resource. To fully utilize this and other data, a cultural heritage
inventory should be housed in some kind of geographic information system (GIS).

4
1.1.1.2 Importance of Cultural Heritage Inventories
Because a cultural heritage inventory contains information on what is considered a cultural
heritage resource and also sometimes, what is not, having a complete inventory of an area, city,
region or country is one of the first steps for conservation. For example, in the case of the US,
legal protection against the demolition or destruction of the historic integrity of a historic site
cannot usually be enabled unless the site is listed on a heritage register (a type of cultural
heritage inventory) at either the local, state or national level. In other words, policymakers and
heritage organizations cannot save resources that are not legally recognized as being worthy of
protection (Logan and McKay 2013, 10).
In addition, heritage inventories that are publicly accessible help to provide awareness
and support for conservation of cultural heritage. If a society recognizes that a resource is
historically important and part of its cultural identity, conservation of the resource perhaps
becomes an obvious and expected outcome by all stakeholders. For example, the Tower of
London has such cultural weight in the UK that the idea of demolition or alteration would
probably be considered a form of national sacrilege. By giving a resource some form of cultural
weight by inclusion, inventories help to conserve cultural heritage resources from one of the
largest sources of cultural heritage destruction – human development.
It should be noted, however, that publicly accessible heritage inventories can also create
problems for long term cultural heritage conservation management. If a resource becomes too
popular or if its material worth becomes known, then the problems of unsustainable tourism,
looting, or malicious destruction might become viable threats. For example, the UNESCO
World Heritage List is an inventory of the world's most important cultural heritage sites. For
cultural heritage tourists, the listed sites can become much sought after destinations, contributing

5
to unsustainable tourism. The Angkor Archaeological Park World Heritage site in Cambodia
receives more than 2 million visitors per year, and the resulting pressure on the site is causing
harm to the centuries-old structures (Sharp 2008). The publication of a heritage inventory can
also form a shopping list of sorts for looters, who seek to profit from illegally obtained portions
of a site. Alternatively, a heritage inventory can serve as a target for opposition forces during an
armed conflict. For example, immediately prior to the Croatian War of Independence, Croatia
submitted a list of important sites to be protected as required by the 1954 Hague Convention for
the Protection of Cultural Property in the Event of Armed Conflict, and those sites were
intentionally and maliciously damaged by the Serbian opposition as "cultural property was
targeted as part of a political strategy" (Stone 2013, 15).
However, in these and other cases, inventories of at-risk heritage act to counter any of the
unintended damage from the unsustainable tourism, looting or malicious destruction as well as
other threats. For example, the World Monuments Fund publishes a World Monument Watch list
biannually to draw attention to cultural heritage resources that are at risk from "the forces of
nature and the impact of social, political, and economic change" (World Monuments Fund 2015).
UNESCO also maintains The List of World Heritage in Danger to draw attention to at-risk
World Heritage sites. For nations that do subscribe to the Hague Convention, heritage
inventories can serve as lists of places to avoid and/or actively protect during an armed
conflict. Usually, armed conflicts present a list of priorities for which heritage conservation is
usually not a consideration; however, recently, military strategists have discovered the use of
cultural heritage protection in combat and occupied areas as a “force multiplier”, which makes
their work easier in regards to stabilizing the local area (Stone 2013). Cultural heritage

6
inventories, in this way, can become part of their positive strategic planning, and prevent
needless harm to cultural heritage resources.
Regarding natural disasters, existing heritage inventories facilitate recovery and decrease
the impact (McCarthy 2013) on cultural heritage resources during and after events. In the case of
Hurricane Katrina, the Federal Emergency Management Agency (FEMA) was required by law,
specifically the 1966 National Historic Preservation Act, to consider how its response,
particularly in dealing with properties deemed as unsafe, might affect sites that are eligible for
the National Register. However, a geospatial inventory of such properties did not exist at the
time, so working with the National Park Service's Cultural Resource GIS Facility (CRGIS), a
methodology was established so that surveyors could record potential National Register-eligible
properties (McCarthy 2013). This process led to the addition of 55,000 cultural heritage
resources to the GIS of the Louisiana State Historic Preservation Office (SHPO), demonstrating
how important it is to have an existing geospatial heritage inventory before a disaster occurs. In
addition, this information could have been used as a benchmark from which to measure the
damage sustained by an area affected by a natural disaster. During and after a natural disaster,
baseline inventory documentation allows decision makers to make better choices and allocate
appropriate resources to the conservation of heritage sites.
1.1.1.3 Challenges to Creating and Maintaining Cultural Heritage Inventories
While heritage inventories are generally seen as essential to cultural heritage conservation, there
are several challenges to both creating and maintaining them. First, often there is a lack of funds
to support a comprehensive and useful inventory. The costs associated with field surveys and
then the technical infrastructure to house an inventory might be too expensive for many heritage
organizations and governments. Second, the creation and maintenance of heritage inventories

7
require knowledgeable and skilled staff who are invested in the inventory process. In developing
areas where other foreign experts are brought in to help create a survey and inventory system, the
danger is that once foreign involvement ends, so does the maintenance of an inventory. For
example, in the Sana’a, a system was developed and local people were trained to use the system;
however, as the project manager, Daniele Pini, laments, “after five years, the GIS we set up is
completely useless because it’s never been updated.” (Grayson et al. 2013, 22) Third, issues
regarding the actual inventory data exist. These include: (1) a lack of access to data by both
heritage professionals and the public; (2) the interoperability of the data; and (3) the ability of the
data to be maintained and migrated as technology develops.
1.1.2 French Colonial Era Architecture in Hanoi
The French Colonial period in Southeast Asia began in 1887, with the establishment of French
Indochina, which initially consisted of the areas now known as Vietnam and Cambodia and
expanded in 1893 to include Laos. In 1898, a small outlying area on the southern coast of
Guangzhou, China was added. The colony lasted until 1954, when the French were defeated by
the North Vietnamese in the First Indochina War, and North Vietnam and South Vietnam were
created. Previously, Cambodia and Laos gained independence in 1953.
Hanoi was initially occupied by the French in 1873, and became the capital of French
Indochina in 1902 until 1954, with some temporary relocations of the capital due to World War
II and the First Indochina War. However, previous to this, Hanoi was always considered an
important city in Vietnam, as it was the capital from 1010, the year of its founding, to 1802,
when the emperor moved the government seat to Hue.
As a result of this long and illustrious history, much of the architectural heritage of Hanoi
can be divided by what existed during the imperial period and what existed during the colonial

8
period. Before French colonization, the center of Hanoi was the Imperial Citadel, which is now a
UNESCO World Heritage Site. To the east of the Citadel area and north of Hoan Kiem Lake, the
Old Quarter is perhaps the best known historic neighborhood in Hanoi. It consists of a tight
network of 36 main streets that each represent a particular type of commerce. This urban cultural
landscape consists of both tangible and intangible heritage that dates back to the founding of the
city more than 1,000 years ago. The remaining historic parts of central Hanoi are French colonial
in nature, as the French proceeded to apply some Haussmann-esque city planning principles (e.g.
wide Parisian-style boulevards with monumental buildings at key intersections) and in the
process, removed some traditional areas in order to redevelop them in this way. This French
concession, or the French Colonial Quarter is located to the immediate south of the Old Quarter
along the Red River.
1.1.2.1 Survey Area in Hanoi
For this project, the Hanoi survey area is primarily composed of the area west of Hoan Kiem
Lake, which comprises a portion of the French Colonial Quarter, which also includes a larger
area south of Hoan Kiem Lake. The survey area, which is approximately 0.35 square miles, also
overlaps to a small extent with the Old Quarter, which lies to the north of it. The Hanoi survey
included 140 photographs representing different architectural styles within the study area (see
Figure 1). The methodology behind the survey will be detailed in the data section of Chapter 3.
Examples of how the architectural styles were expressed in the Hanoi survey are seen in Figure
2.
In general, the architectural styles in Hanoi are typically a mixture of different
styles (Nguyen and Kammeir 1997, 5). This is both the result of organic and planned processes
that occurred during the French colonial period. On the one hand, French master planners and

9

Figure 1 Hanoi survey photograph locations, organized by architectural style

10
architects developed blended styles on purpose, and on the other, the adaptation of European
styles to a non-European climate and setting required the blending in of more pragmatic local
styles (Wright 1991). For the purposes of this project, only the Art Deco cultural heritage
resources will be used for the dataset, primarily because Art Deco, also known as Moderne, is a
style that is not necessarily well recognized as historically significant as earlier French colonial
era styles such as the Beaux Arts and Colonial French/Vernacular styles.

Figure 2 A sample of architecture styles in the Hanoi survey area

11
1.1.2.2 Cultural Heritage Resource Management and Inventory Activities in Hanoi
On paper, the management of cultural heritage resources by the Vietnamese government is
deemed a priority. However, cultural heritage conservation as a function of the government is
considered ineffectual due to a large body of "superficial", "ambiguous", impractical,
inconsistent, and sometimes contradictory laws, directives, plans and regulations as well as
"bureaucracy”, corruption, mismanagement and weak enforcement (Nguyen and Kammeir 1997,
7). As a result, several non-governmental domestic and foreign organizations have provided
assistance in cultural heritage conservation.
A recent example of this was the partnership between the city of Hanoi and the French
city of Toulouse and the Brussels Capital Region. Funded by the European Asia Urbs
programme, two projects were undertaken that included a strong focus on the architectural
heritage conservation of Hanoi's Old Quarter: the ASIA REHAB European Project (2000-2003)
and the Hanoi 2010 Project - Heritage and Cultural Identity (2004-2006). Generally, these two
projects focused on individual architectural conservation projects, large street improvement
projects, and implementing a GIS to record the Old Quarter's architectural heritage. Additionally,
the Hanoi 2010 Project was meant to prepare for cultural events to celebrate the 1,000th
anniversary of the official founding of Hanoi in 1010 (Hanoi 2010 Project 2014).
From 2006-2010, Toulouse continued the partnership with Hanoi, working on several
objectives having to do with the promotion of Old Quarter heritage. These included: (1) an
inventory of both tangible and intangible heritage resources; (2) developing a pilot street; (3)
creating a detailed conservation plan; (4) establishing five locations that showcase architectural
conservation and provide cultural gathering spaces; (5) architectural conservation projects on

12
individual structures; and (6) nomination of the Old Quarter for UNESCO World Heritage Site
consideration.
The inventory portion consisted of the 2007 systematic review of the 1,080 Old Quarter
houses that were initially identified as heritage properties in 1999 by Hanoi authorities.
Conducted by a Toulouse-based architectural expert, the purpose of this review was to quickly
verify and determine the state of the resources before a later more detailed study of each building
could be performed by a Vietnamese team after the end of the partnership. The findings indicated
that the 1999 inventory was incomplete and as a result, 880 houses were added, despite the fact
that only 300 of those maintained their historic architectural integrity. Even more alarming is that
between 1999 and 2007, only 30% of the originally-listed buildings have remained intact to
varying degrees (Hanoi, Heritage and Identity 2010).
This fact underscores the importance of a heritage conservation plan developed on the
basis of a cultural heritage inventory in Hanoi. While the above project focuses on the Old
Quarter, which is a well-known and highly-regarded pre-colonial historic area, other areas of
Hanoi that might contain cultural heritage resources may be overlooked, especially if those
resources are relatively younger, such as the city's Art Deco resources. As the city's population
increases and economic growth continues, its cultural heritage may suffer due to developmental
pressure and other stressors if strong heritage conservation methods, that not only include
statutory protections but also policies that promote a heritage-friendly environment, are not put
into practice.
1.2 Objectives
The main objective of this thesis project is a web application that uses geo-referenced
photographs as a starting point to gather useful information about cultural heritage resources

13
from both the general public and engaged cultural heritage enthusiasts and professionals. The
information collected will conform to recognized heritage data standards in regards to content.
The case study focuses on French Colonial Era Art Deco resources in the French Quarter of
Hanoi, Vietnam. The web application will not be fully deployed, but its usefulness will be
evaluated by cultural heritage professionals and others who have an understanding of heritage
inventories.
The secondary objective is to use web development tools that are easily deployable and
are relatively inexpensive to use in order to create a data collection model that can be applied by
heritage professionals who may have very few resources and technical skills. Ideally, for
example, if a geo-referenced photo catalog of a particular type of cultural heritage resource
existed with very little information, this web application model could serve as a method of
gathering information for a more complete inventory.
1.3 Organization of Thesis
The remainder of this thesis consists of four chapters covering: (1) Related Work, which is a
review of related literature, processes and applications; (2) the Methodology, which consists of
the methods and components used to first develop and then evaluate the web application; (3) the
Results, which showcase the functionality of the web application as well as the feedback from
the evaluation of the web application; and (4) the Conclusions, which highlight the web
application's strengths and weaknesses, identifies possible next steps and discusses future trends
with respect to web-based crowd sourced heritage inventories.
As seen in Figure 3, each section represents a part of the overall development of the web
application, based on the idea of requirements. The requirements here are the minimum goals
and elements that the web application needs to accomplish. The Related Work chapter forms the

14
Figure 3 Thesis flow chart

basis for the web application requirements. The Methodology chapter documents how those
requirements are actually used to develop the web application and its evaluation framework. The
Results chapter shows how the web application meets the requirements. Finally, the Conclusions
chapter determines to what degree the web application has fulfilled the requirements and if any
adjustments and or new requirements need to be incorporated.

15
CHAPTER TWO: RELATED WORK
Before developing the web application, it is important to review both past, current, and planned
web applications dealing with cultural heritage inventories and determine the best practices for
creating a collaborative heritage inventory on the Internet that involves both heritage
professionals and interested members of the public. This section will explore the following four
topics: (1) current heritage site inventories on the Internet; (2) documentation standards for
heritage sites; (3) volunteered geographic information and crowdsourcing as sources of heritage
site documentation and inventory; and (4) a comparison of web application development
technologies.
2.1 Current Web-based Heritage Site Inventories
In order to review the state of current heritage site inventories on the Internet, 25 websites were
evaluated based on the basic tenets of website user experience (UX), with an added layer of
further definition for the immovable cultural heritage domain. This evaluation method will also
form the basis for the evaluation framework employed after the development of the current web
application.
2.1.1 Evaluating Web-based Heritage Site Inventories
The goal of most websites is to provide value and meaning to their visitors or users. The
following “User Experience Honeycomb” diagram by Peter Morville illustrates the basic
components of what this entails.
For a website to be valuable, then, it should be useful, desirable, accessible, credible,
findable, and usable. The following table (Table 1) shows the distillation of each of these
elements by Usability.gov (the U.S. government’s web project to promote user experience

16

Figure 4 User Experience Honeycomb by Peter Morville
(Morville 2004)

best practices) paired with a more defined question for evaluating immovable cultural heritage
inventory websites. Sections 2.1.1.1 through 2.1.1.6 explore the above concepts in more detail,
citing examples from several web-based heritage site inventories. Section 2.1.1.2 shows the
results of testing those concepts against 25 diverse web-based heritage site inventories. The
purpose of this evaluation is to provide a quantitative summary of what current inventories do
well and what they can improve on, based on the user experience concepts.
2.1.1.1 Usefulness
Does the website present heritage site information that is not found elsewhere and is adequate
for user needs?
The range of information presented within an online heritage site inventory is dependent on the
audience targeted by the publishing organization, and often, the target is the general public or

17
those involved in the conservation of heritage sites or a combination of those two groups. Also,
while they are not the focus here, it is important to note that many heritage inventories are not
accessible online, and that these offline inventories generally serve the needs of government
officials and conservation professionals for particular projects or initiatives.
Table 1 User Experience Evaluation Questions for Web-based Heritage Site Inventories
Element General Evaluation Question
Useful “Your content should be original and fulfill a
need”
Does the website present heritage
site information that is not found
elsewhere and is adequate for user
needs?
Usable “Site must be easy to use” Does the website present heritage
site information in an easy to use
format?
Desirable “Image, identity, brand, and other design
elements are used to evoke emotion and
appreciation”
Does the website’s design evoke
positive emotions and
appreciation of heritage sites and
promote their conservation?
Findable (Discoverable) “Content needs to be navigable and locatable
onsite and offsite”
Does the website’s navigation
make it easy for users to find
heritage site information?
Accessible “Content needs to be accessible to people with
disabilities”
Does the website hinder access in
any way to the heritage site
information?
Credible “Users must trust and believe what you tell
them”
Does the website provide credible
information on heritage sites?
Source: Data adapted from Usability.gov.
Online heritage inventories geared towards public access usually present: (1) a subset of a
more detailed inventory database, which is generally either made available to conservation
professionals or other credentialed users via a different interface on the same website or some
other means; or (2) information that has been created primarily for public consumption.
For example, the Los Angeles Conservancy is a non-profit organization that is geared
towards public outreach and historic preservation advocacy within Los Angeles County. Their
website features original narrative descriptions with photographs and locations on more than 600

18
historic sites that are searchable by location, keywords, architectural style, architect, community,
decade, and property type. However, the historic places that are featured are a subset of what has
been designated as historic by local cities, the state of California, and the National Register.
Also, the information presented is primarily an overview of each site. As a result, the website is
very useful to the general public for outreach purposes, because while the same information is
available through research on other websites, the Conservancy assembles it in a clear and easily
digestible manner that highlights the overall theme of the importance of historic places in Los
Angeles County. The website is less useful to conservation professionals and others who need
more complete and detailed data on all of the designated and potential historic sites as
determined by other experts through an established and documented methodology.
A website that is a good example of providing useful information for heritage
professionals is the Australian Heritage Places Inventory. Each record contains: (1) photographs
of the historic place; (2) inclusions on heritage lists; 3) legal status; (4) place identification
number and file references; (5) a statement of significance; (6) how the historic place fulfils the
criteria of the state’s official values; (7) a detailed description; (8) a historical overview; (9)
condition and integrity; (10) a description of location; and (11) a bibliography. Collectively, this
information would help a heritage professional determine the status of the place and how best to
conserve it.
Two types of information that would increase the usefulness of the data contained in an
online inventory such as Australian Heritage Places Inventory would be some sort of spatial
reference, such as a polygon that defined the borders of the site, and references to related
records. In Section 2.1.2, an inventory must contain a geospatial reference for each record to
score a 5 or “Strong Yes” to the question posed.

19
2.1.1.2 Usability
Does the website present heritage site information in an easy to use format?
An online inventory might contain as much useful information as possible for its desired
audience. However, if the website’s users cannot easily view the information through the
interface, then the overall utility of such a site is lessened. This is a separate issue from that of
discoverability or the ability to find information on a site, which will be covered in Section
2.1.1.4.
As mentioned in the previous section, the Los Angeles Conservancy’s website is very
easy to use, because its primary demographic is the general public. An example of an online
inventory that is geared towards both the general public and heritage professionals is the
Victorian Heritage Database, which is administered by the Heritage Council in the Australian
state of Victoria. The Victorian Heritage Database (Figure 5) contains all of the information that
a heritage professional would need to conduct conservation work, but it presents the information
in a format that is easily digestible by a lay person. It contains much of the same information as
the Australian Heritage Places Inventory, but it also includes a timeline photo viewer, ways for
the public to provide input, and the ability to create tours of selected heritage places. The website
was relaunched in April 2015 with these new features as well as a responsive template that can
be viewed on both desktop and mobile browsers. Not surprisingly, the Victorian Heritage
Database is the highest rated online inventory in this evaluation, as seen in the Findings section
(Section 2.1.2).
2.1.1.3 Desirability
Does the website’s design evoke positive emotions and appreciation of heritage sites and
promote their conservation?

20
The idea of desirability is relatively subjective, but in this context, it is defined as how much of a
heritage inventory website is dedicated towards design features or narratives that evoke a
positive appreciation of the historic places that they represent. This can include the narrative
descriptions or images that exist as part of place records or extra features that exist outside of the
individual records. For example, the Victorian Heritage Database has recommended tours and a
timeline browser for photos on its homepage (Figure 6).

Figure 5 Victorian Heritage Database

21

Figure 6 Recommended tours and Timeline browser sections from the Victorian Heritage
Database
The CyArk website is not exactly an inventory but more a collection of heritage places
that the nonprofit has documented via laserscanning, high dynamic range (HDR) photography,
and other surveying methods. The site scores a 5 or “Strong Yes” for Desirability because it
seeks to tell the story of each of the heritage places it has documented and features large imagery
that is attractive and eye catching (Figure 7). It is included in this survey because some of its
website practices might also be used for a more a comprehensive inventory of sites, particularly
those that host large amounts of imagery for a historic place.

22
2.1.1.4 Discoverability
Does the website’s navigation make it easy for users to find heritage site information?

Figure 7 CyArk Record for Chichen Itza

The ability of users to find what they are looking for, at various levels of specificity, is a
key aspect of an online heritage inventory. If information cannot be found, whether on purpose
or through casual browsing, then it undermines the idea of publishing cultural heritage data
online for public and professional consumption. In this survey, many of the websites had
traditional advanced search screens, where users could filter results based on key data fields.
What distinguishes a “Strong Yes” from a “Yes” is the number of fields available to filter with
and the presence of a spatial search.
An interesting approach was that taken by the National Registry of Historic Sites and
Structures in the Philippines. The site was built using the Blogger platform, with each page

23
representing a historic place record. Each record was tagged with the appropriate label and all of
the tags are listed on each page as hyperlinks. The main categories are located in a right-hand-
side column box, and the name tags are listed at the bottom of each page. While the site is neatly
organized, the multitude of tags can make filtering daunting.
2.1.1.5 Accessibility
Does the website hinder access in any way to the heritage site information?
As mentioned in Section 2.1.1.1, some online heritage inventories choose to publish only a
subset of the data available. This is to be expected, especially in cases where there are issues
with confidentiality, access, or historic site security. For example, an online inventory might not
want to call attention to certain archaeological sites for fear of looting. However, what
accessibility refers to here is the ease with which a user is able to access the minimum amount of
data that is considered useful.
In order to control who sees the data, some sites require users to sign up for access, while
providing a stripped-down experience for those who do not want to go through the process of
signing up. For the purposes of evaluation, all of the online heritage inventories examined were
looked at as non-registered users, and websites that required credentials were seen as limiting
access. Any data that was accessed after logging in was not counted in the full evaluation
process.
2.1.1.6 Credibility
Does the website provide credible information on heritage sites?
It is important for a heritage inventory website to provide credible information because often
decisions regarding the conservation of each heritage place depend on it. For example, property
owners might refer to an online inventory to check the heritage status of their home or business

24
and what they find might affect whether they are able to make any improvements or demolish all
or part of the property. If there are incentive programs, such as the U.S. Federal Historic
Preservation Tax Incentives program, then a property owner might take advantage of his or her
property’s historic status. For local officials, especially in the U.S., an inventory might be used to
determine whether a demolition or development permit can be issued.
An example of this is the City of Los Angeles Zone Information and Map Access System
(ZIMAS), which is used by the city’s planners to determine if there are any historic preservation
designations, on either the city, state, or federal levels, for a given property. While ZIMAS is not
solely a heritage inventory, it functioned as one until the city launched its new historic resource
inventory, Historic Places LA, in February 2015. ZIMAS alerts planners and others to whether a
city parcel has a designated property on it, and provides some information on the designations
(Figure 8).

Figure 8 Historic Preservation Screen from LA ZIMAS

25
The majority of the inventories examined are the official inventories from government
entities. Because of that, the information contained within each of those websites is expected to
be authoritative and highly credible. For online heritage inventories that are not published by the
statutory authority, credibility can be achieved through a listing of sources and an explanation of
the methodology behind the information.
2.1.2 Findings
The results of the evaluation of the 25 heritage inventory websites are seen in Table 2. As
mentioned previously, the newly revamped Victorian Heritage Database scored the highest based
on the criteria with a 29 out of a possible 30. The median score was 24 and the mean was 23.68.
Because this evaluation was based on the input of one person (the author), the rankings are not
meant to be definitive. However, it was meant to be an exercise in how these online heritage
inventories performed under each of the components of what makes a website valuable.
In general, most of the websites met the minimum requirements as defined. Perhaps, the
area that was the least developed for most of the websites had to do with Desirability. This shows
how most online heritage inventories do not tend to be particularly engaging to casual users, who
may represent a large stakeholder group and who might need to be convinced of the value of
conserving heritage places. Making an online heritage inventory appealing to the general public
presents another opportunity for heritage organizations to advocate for their cause.
2.2 Documentation Standards for Built Cultural Heritage
In the last section, the idea of an online heritage inventory’s usefulness was discussed. A major
part of that has to do with whether the information presented is of value to the target audience,
which in this case primarily consists of those involved in the conservation of built cultural
heritage. Recognizing the importance of defining what data is of value to this domain, two data

26

Table 2 Heritage Inventory Website Evaluation

27
models have been developed, one for architectural sites and the other for archaeological sites,
which outline mandatory and optional data fields for documentation. These data standards not
only define what information is most useful, but also help to facilitate data sharing and transfer
between diverse heritage organizations:
“…compatibility is most readily achieved at the level of minimum or "core"
information, i.e., those categories of essential, basic information common to a
number of documentation projects. The adoption of such "core data" categories
makes it easier to record, retrieve, and exchange information
electronically” (Thornes and Bold 1998).

In 1992, the Council of Europe adopted the Core Data Index to Historic Buildings and
Monuments of the Architectural Heritage. This was the culmination of a process that started in
1985, when the Granada Convention for the Protection of the Architectural Heritage of Europe
was ratified by the Council. The Granada Convention, in Article 17, required the ratifying
countries to work towards information exchange in ways to take advantage of “the possibilities
afforded by new technologies for identifying and recording the architectural heritage” (Council
of Europe 1985). The data index outlines the minimum set of data necessary for each record, but
also provides a loose framework for incorporating a richer set of data for each heritage record
and also the ability to make cross references to other types of information.
In 1995, the Council of Europe adopted the Core Data Standard for Archaeological Sites
and Monuments, which was a collaboration with the International Committee for Documentation
(CIDOC) of the International Council of Museums (ICOM). The Core Data Standard was meant
to serve as the archaeological complement to the Core Data Index, and are closely related in
content, as the Council and CIDOC both realized that often both architectural and archaeological
heritage are housed in the same inventory system. A comparison of the mandatory fields of each
is seen in Table 3.

28
Table 3 Comparison of mandatory fields specified by the Core Data Index to Historic
Buildings and Monuments of the Architectural Heritage and the Core Data Standard for
Archaeological Sites and Monuments
Core Data Index to Historic Buildings and
Monuments of the Architectural Heritage
Core Data Standard for Archaeological Sites and
Monuments
1.2 Unique Reference Number
The number or combination of characters which
uniquely identifies each building recorded by the
organization.

2.1.1 Reference Number
The number or combination of characters which uniquely
identifies each monument or site recorded by the
organization within its database.
1.3 Date of Compilation
Date of compilation of the core data index record.
This date may be modified whenever the index
record is updated.
2.1.3.1 Date of Compilation
The date on which the core record was created.
2.1.3.2 Date of Last Update
The date on which the monument or site record was last
added to, altered, or amended.
1.4 Recording Organization
Name of the organization responsible for curating
the record. This information is useful in establishing
the provenance of the record when data is
exchanged between recording organizations.
2.1.4 Originator of Reference
The name of the individual or organization responsible for
curating the monument or site record. This information is
useful in establishing the provenance of the record when
data is exchanged between recording organizations.
2.1.1 Location – State (Country) 2.2 Location
This is a mandatory section which defines the spatial
location of the monument or site in terms of political,
postal, geographic, and cartographic criteria. Any
combination of sub-sections defined below may be
employed to identify the location of the monument or site:
2.2.1 Administrative Location (includes country)
2.2.2 Site Location (narrative descriptions)
2.2.3 Address
2.2.4 Cadastral Reference/Land Unit
2.2.5 Cartographic Reference (coordinates)
3.1 Building Type
Precise building type defined by function. This field
may be repeated to accommodate changes in type
over a period of time. Controlled vocabulary is
desirable.
2.3.1 Monument or Site Type
The term by which a monument has been indexed. This
will normally be the interpretation of the monument by
functional or descriptive criteria, e.g., Villa; linear
earthwork. Controlled vocabulary is desirable.
3.2 Building Category
Broad functional category to which the building
type belongs, e.g., Agricultural (Category); Barn
(Type). Controlled vocabulary is desirable.

29
4.0 Dating
This section allows for precise dating when it is
known, or date ranges or periods when it is
imprecise. Must consist of at least one of the
following:
4.1 Period
4.2 Century
4.3 Date Range
4.4 Absolute Date
2.4.1.1 Dating - Cultural Period
The cultural period to which the monument or site, or a
part or phase of the monument or site, belongs: e.g.,
Neolithic. A controlled vocabulary is desirable and must
include "unknown". Must be linked to 2.3.1 Monument or
Site Type

Source: Data adapted from Thornes and Bold (1998)

Currently, a data standard that combines and extends the Core Data Index and Core Data
Standard is in development by CIDOC with input from the International Documentation
Committee (CIPA) of the International Council on Monuments and Sites (ICOMOS).
The International Core Data Standard for Archaeological and Architectural Heritage will
incorporate much of the above in its mandatory fields. However, the standard has not yet
been accepted or published. For an inventory focusing on urban architecture, then, the Core
Index should be used.
2.3 Crowdsourcing as a Source of Cultural Heritage Site Documentation and Inventory
One of the main goals of this project is to include the ability to contribute information about the
each of the Art Deco buildings in the dataset within the web application. However, before that
can be incorporated, two questions must be explored: (1) what is crowdsourcing? and (2) how
can crowdsourcing be applied to a cultural heritage inventory of places?
2.3.1 Crowdsourcing Definition
Crowdsourcing is “the act of a company or institution taking a function once performed by
employees and outsourcing it to an undefined (and generally large) network of people in the
form of an open call” (Oomen and Aroyo 2011). The “crowd”, i.e. the people who answer that
call, can be compensated or not, but are still not considered employees of the sponsoring

30
organization. For example, the Amazon Mechanical Turk marketplace matches small tasks that
are difficult to automate (human intelligence tasks or HITs) with actual human operators who
complete each task for a small amount of money (Ipeirotis 2010). Typically, crowdsourced
projects, especially in the cultural heritage domain, try to leverage non-monetary motivators in
order to have people participate. These motivational factors are social in nature, and can be
divided into two groups: (1) connectedness and membership; and (2) sharing and generosity
(Shirky 2010).
Crowdsourced projects can also be categorized based on the interaction between the
sponsoring organization and the crowd. Table 4 highlights three models of crowdsourcing which
are defined by the level of participation by the members of the public. Amongst these,
contributory crowdsourcing projects involve the least amount of responsibility from the public
and require only some sort of data contribution. With collaborative crowdsourcing projects, the
public has an invitation to become more involved by possibly analyzing contributed data and
helping to define the project. Co-created crowdsourcing projects are still designed primarily by
the professionals at the sponsoring organization; however, the public participants interact with
each other and may also be involved in all aspects of the project.
Table 4 Categorization of Crowdsourcing Projects in the Cultural Heritage Domain
Crowdsourcing Model Definition
Contributory projects Designed by professionals, where members of the public contribute data.
Collaborative projects Designed by professionals, where members of the public contribute and analyze data,
help in refining project design, or disseminate findings.
Co-Created projects Designed by professionals, where members of the public are working together, and
some of those public participants are actively involve in (all) steps of a process.
Source: Oomen and Aroyo 2011

Regardless of the crowdsourcing model, crowdsourcing projects can involve many
different types of tasks. In the cultural heritage field, particularly as it relates to the digital

31
information workflow for Galleries, Libraries, Archives, and Museums (GLAM), there are six
types of tasks that can be incorporated into a project (Oomen and Aroyo 2011). Table 5 shows
those tasks with the corresponding ones for historic places. All of the tasks except crowdfunding
will be considered for this project.

Table 5 Classification of Crowdsourcing Initiatives in Cultural Heritage
Crowdsourcing type For Cultural Heritage Objects For Cultural Heritage Places
Correction and
Transcription Tasks
Inviting users to correct and/or
transcribe outputs of digitization
processes.
Inviting users to correct and/or
transcribe outputs of digitization
processes, such as spatial information
for historic places.
Contextualization Adding contextual knowledge to
objects, e.g. by telling stories or writing
articles/wiki pages with contextual data.
Adding contextual knowledge about
historic places e.g. by telling stories or
writing articles/wiki pages with
contextual data.
Complementing Collection Active pursuit of additional objects to
be included in a (Web) exhibit or
collection.
Active pursuit of additional places to be
included in an online cultural heritage
inventory.
Classification Gathering descriptive metadata related
to objects in collection. Social tagging is
a well-known example.
Gathering descriptive metadata related
to historic places. Social tagging is a
well-known example.
Co-curation Using inspiration/expertise of non-
professional curators to create (Web)
exhibits.
Using inspiration/expertise of non-
professional curators to create
collections of historic places to form a
historic narrative.
Crowdfunding Collective cooperation of people who
pool their money and other resources
together to support efforts initiated by
others.
Collective cooperation of people who
pool their money and other resources
together to support efforts initiated by
others.
Source: Adapted from Oomen and Aroyo 2011

2.3.2 Applying Crowdsourcing to a Cultural Heritage Inventory
One of the main applications of crowdsourcing occurs in scientific research. Because of this,
much of crowdsourcing methodology and best practices originates from citizen science projects,
also known as Public Participation in Scientific Research (PPSR) (Shirk et al. 2012). Figure 9
illustrates a framework for PPSR projects. First, the question or issue is identified through the
examination and input of both scientific and public interests. Second, a project to address the
question or issue identified is developed. Third, the project generates observational and

32
experiential outputs relating to the original inputs. Fourth, the outputs are analyzed to come up
with outcomes in the areas of science and social-ecological systems, and for the individuals
taking part. Finally, the impacts of the project, which are less specific and broader in scope, are
realized.

Figure 9 Framework for public participation in scientific research projects
(Source: Shirk et al 2012)

In order to apply the same principles towards an online cultural heritage inventory for
historic places, the framework was modified, as seen in Figure 10.

Figure 10 Framework for crowdsourced cultural heritage inventory based on Figure 9

33
In this adapted framework, the inputs from heritage and public interests are considered in
order to identify the crowdsourcing requirements for the online inventory site. Then, based on
those requirements, a web application is built that tries to facilitate the crowdsourcing goals. The
output of that web application is crowdsourced information about the buildings. The outcomes
are three-fold: (1) a more complete, accurate, and/or precise inventory; (2) a tool that gives
government agencies the ability to make informed policy decisions about historic places; and (3)
individuals who are more engaged with their cultural identity through the knowledge and
appreciate of their historic environment. The impact is that eventually the project will contribute
to heritage conservation both locally and globally, and that the public will recognize the
importance of conserving their heritage places.
In determining the crowdsourcing requirements, then, the process should involve looking
at both crowdsourcing models and crowdsourcing types through the lens of the heritage interests
and the public interests. Chapter 3 will go through this process to determine the best way to
employ crowdsourcing for this project.
2.4 Web Application Development Technology
In Section 2.3, standards for archaeological and architectural heritage were outlined that specify
data models for heritage inventory best practices. It is important to note that the standards
discussed are not dependent on particular hardware or software choices because of the rapidly
changing nature of technology and the variability in user needs and requirements. However,
technology choices for heritage inventories have been discussed in broad strokes and typically
consist of a relational database, preferably spatially-enabled, that is normalized and utilizes
controlled vocabularies. For online heritage inventories, the back end relational database and
map server would be accessed via a front end user interface.

34
In determining how to create a simple collaborative online inventory model, it is
important to think of the requirements of both those who would contribute and those who might
try to replicate the model for their own purposes, namely cultural heritage professionals and
organizations. Cultural heritage professionals are not typically experienced in web application
development and do not necessarily have the technical skills to successfully implement any of
the individual components outlined above. And many cultural heritage organizations are limited
by a lack of resources when implementing and maintaining a heritage inventory system and
staffing qualified people to do so. This is especially true when in developing areas, such as in the
project region of Southeast Asia and project area of Hanoi. For these reasons, it is imperative to
keep the limitations in funding, staffing, and technical knowledge and infrastructure in mind
when making choices in the technology used to power a cultural heritage inventory.
Of the components mentioned, the most critical is the choice of where and how to house
the data. As mentioned, typically a relational database is used, but often, proprietary database
programs, such as Oracle or SQL Server can be both costly and too unwieldy to manage without
the appropriate skills, especially those involved in spatially-enabling the database. In that case,
implementing a geodatabase solution within the Esri workflow might help streamline the spatial
visualization of the data, but again, the Esri software environment is expensive and proprietary.
In trying to eliminate the negatives of using proprietary software, an open source solution such as
a PostGIS/PostgreSQL database, which is spatially-enabled, could be used, but the difficult set
up and on-going maintenance might still be too much of a hurdle for a cultural heritage
professional. The above does not even take into account structuring the database in a normalized
fashion with as much standardization as possible through controlled values.

35
Because of these potential barriers to implementation, this project will look for low-cost
or free solutions that do not require extensive technical knowledge and provide a relatively easy
workflow. Given that, the requirements for the database component of this project are as follows:
(1) it should be cloud-based to limit exposure to complicated server and traditional database
setup; (2) it should be spatially-enabled with mapping capabilities; (3) it should be low-cost or
free; and (4) it should have an established application programming interface (API) that allows
access to the database to develop a web application. Two systems, which meet those criteria, will
be explored: Google Fusion Tables and CartoDB.
Google Fusion Tables (http://tables.googlelabs.com) is an experimental application from
the data management team at Research at Google. Launched in 2009 as part of Google’s free
ecosystem of applications available to the public, it leverages structured data that can be entered
directly into a fusion table or uploaded via different formats, such as CSV (Comma Separated
Values), KML (Keyhole Markup Language), and spreadsheet formats (Excel, Open Office,
Google Spreadsheets). The application allows collaboration and contribution in similar ways to
that of Google Docs, with synchronous editing, commenting, and a discussion feature, but also
allows the fusion tables to interact with each other in similar ways to that of a relational database.
This creates a way for contributors to share information while keeping datasets distinct. The
application also provides an easy path for the visualization of data, whether through graphs and
charts, temporally via a timeline, or as a layer or layer set on a Google map. Fusion Tables also
has an API that allows external applications to query and draw upon the database. (Gonzalez et
al. 2010)
CartoDB (http://www.cartodb.com) is similar to Google Fusion Tables in that it is
delivered as Software as a Service (SaaS), which means that the software is hosted from a central

36
server and accessed by users via a thin client, in this case, a web browser. Unlike Google Fusion
Tables, CartoDB is a freemium service, so while there is a free tier for light usage, other pricing
tiers exist for heavier and enterprise usage. A free account with CartoDB allows for unlimited
datasets and unlimited map views with a cap at 50 MB of data hosted via the server. Other plans
charge on a monthly basis for more hosted data as well as complete privacy of datasets and maps
and the ability to remove the CartoDB branding. While Google does not expose their source
code, CartoDB relies on open source software, such as PostGIS and PostgreSQL, and uses
JavaScript in its CartoDB Editor application, which uses the CartoCSS language to provide fine-
tuned control of map styling and visualization. Figure 11 diagrams how the CartoDB Platform
with its set of APIs integrates with the development of a web application.

Figure 11 CartoDB Integration with Web Applications
(Source: cartodb.com)

37
The CartoDB Platform consists of three APIs and one JavaScript library to aid in
developing web applications with CartoDB. They include: (1) the Maps API, which allows for
the creation and display of maps from the data; (2) the Data API, which allows data query and
retrieval, as well write, update, delete, and import data programming functions; (3) the Import
API, which allows for asynchronous upload of files and data; and (4) the JavaScript library,
CartoDB.js, which allows for the extension and creation of visualizations within websites and
web applications.
A comparison of the two platforms is seen in Table 6. Both Google Fusion Tables and
CartoDB eliminate the need for a traditional spatial database and map server and function as web
services which can be accessed by the web application via each service’s API. However, based
on the flexibility of CartoDB in styling and lack of limits on usage, even within the free pricing
tier, this project will be using CartoDB as the backend database and mapping platform.
Table 6 Comparison of Google Fusion Tables and CartoDB
Google Fusion Tables CartoDB
Up to five Fusion Table layers to a map via Google
Maps API.
No limitation on amount of layers displayed.
Up to five styling rules for one layer. No limitation on number of styles, using Carto CSS.
Only first 100,000 rows of data are mapped or included
in query results.
No limit on amount of rows to query on the CartoDB
SQL API or to display on maps.
500 vertices per map tile with a maximum of 5 million
vertices per table.
No limit on vertices.
250 MB size limit. Free version: 50 MB of data, unlimited datasets.
Proprietary Google database Open source PostgreSQL/PostGIS database, which can
be queried using full SQL.
Source: http://blog.cartodb.com/comparing-fusion-tables-to-open-source-cartodb/ and
https://developers.google.com/maps/documentation/javascript/fusiontableslayer

After choosing the database and mapping platform, the next component is the user
interface. Because of the need to adapt to the specific requirements determined in this chapter, it
is important that the method used to develop the user interface is flexible and extensible.
Common web development tools and languages, such as HTML, CSS, JavaScript, and Python

38
will be used to create the user interface. The application development process, along with
programming challenges in building an application from the ground up based on specific
requirements, will be addressed in Chapter 3.

39
CHAPTER THREE: METHODOLOGY
In this chapter, the methodology behind the development and evaluation of the cultural heritage
inventory web application will be discussed. This includes: (1) determining what the
requirements are for the web application by applying the principles introduced in Chapter 2; (2)
selecting the most appropriate and achievable ways to incorporate as many of the requirements in
the web application as possible; and (3) establishing a framework on which to evaluate the
successes and failures of the resulting web application in Chapter 4.
3.1 Application Development
3.1.1 Target Workflow
The target workflow for the development of the web application involves the following steps: (1)
Refine the web application’s main purpose (Section 3.1.1.1); (2) Determine the requirements
necessary to achieve that purpose (Section 3.1.1.2); (3) Determine the application components
best suited to achieve the requirements (Section 3.1.2); (4) Develop the web application (Section
3.1.3); (5) Evaluate the web application based on a defined framework (Section 3.2 and Chapter
4); and (6) Outline a possible roadmap to address the deficiencies found in the application
(Chapter 5).
3.1.1.1 Purpose
The main purpose of the web application is to publish data collected regarding Art Deco
buildings in Hanoi, Vietnam, and to collect additional information about the buildings from
application users. The target users are architectural historians and other heritage professionals, as
well as members of the general public, any of whom may be able to provide some information

40
about each of the buildings. A secondary purpose is to develop the web application in such a way
that it becomes a reusable application model for others to implement in other areas.
3.1.1.2 Requirements
In Chapter 2, a review of Related Work was conducted in order to help determine the
requirements of the web application. The four areas examined were: (1) existing websites used to
publish information on heritage sites; (2) heritage inventory and documentation standards; (3)
crowdsourcing in cultural heritage; and (4) web development technologies for inventory
databases.
Regarding heritage site inventories made available to the public online, most of the
evaluated websites were generally found to be fit for their purpose. However, the evaluation in
Section 2.1 exposed some issues that could be improved in each of the categories explored. Most
of the websites scored either a “Yes” or a “Strong Yes” in the area of Usefulness, which
measured how useful the information provided in the online inventory was. The key to how
useful the data was often hinged on two things: (1) the breadth of information; and (2) whether
the heritage places were spatially referenced and shown on a map. Because one of the purposes
of this project is to gather additional information about each building, the resulting web
application will not have the breadth of information necessary. However, because the
information collected includes the location where each photo was taken, a map should be central
to the web application.
In the area of Usability, it is important that the information that is featured is easy to
understand and clear, and that the web application has intuitive navigation and workflows. The
requirement in this area, then, is that the web application have a simple layout with explanatory
text and links that clarify how to use the web application.

41
In regards to Desirability, the online inventories were evaluated by looking at how the
content and features worked together to evoke positive emotions toward the conservation of the
heritage places featured. It should be made clear in the branding and design of the web
application, then, that its ultimate goal is indeed heritage conservation. The resulting requirement
is that there be some content that speaks to the ultimate goal.
With Discoverability, it was found that the ability to find information was just as
important as the information itself. Users of the web application must then be able to find a
particular place to either learn or contribute more information about it. Because each record does
not yet have a richer set of data associated with it, searching at the initial stage will primarily be
map-based.
Accessibility, as defined for this project, measures whether there are any barriers to
access the information contained with the web application. It is assumed that users will have
access to the internet via a high speed connection. The web application will be fully functional
on either Google Chrome or Mozilla Firefox, as both of these web browsers are free to download
and widely used, regardless of operating system. In the evaluation process, most of the online
inventories did not restrict access to the information by requiring users to establish login
credentials, and the resulting requirement for this web application is that the information be
accessible without a login. However, in order to contribute information to the application, some
type of login was found to be necessary in order to be able to keep track of the information being
submitted and to establish the credibility of the information.
Because the web application is not sponsored by an official government body, users will
need other evidence of the credibility of the information as well as the credibility of the
publisher. This Credibility will be established by exposing as much of the methodology as

42
possible in regards to the existing data and to include information as to the purpose of the web
application.
The above requirements that resulted from Section 2.1 are summarized in Table 7.
Table 7 User Experience Elements and Web Application Requirements
Element Requirement
Usefulness Map, showing each record’s location.
Usability Simple layout with explanatory text and links that clarify how to use the web
application.
Desirability Content that promotes the application’s purpose of heritage conservation.
Discoverability Map-based search.
Accessibility No requirement to login or sign up to view information.
Credibility An About section dedicated to exposing the purpose and methodology of the
application.

Regarding the required information that needs to be collected to meet the minimum data
model standards for architectural heritage, the Core Data Index to Historic Buildings and
Monuments of Architectural Heritage’s minimum mandatory requirements will be incorporated
into the web application as either specific fields or as part of a general description text field that
can be contributed to. See Table 8 for a listing of fields.
As shown in Section 2.3, crowdsourcing projects can take on any combination of
characteristics. Based on the scope of this project, a contributory model of crowdsourcing, in
which the users’ involvement consists only of contributing information will be used. Table 9
shows the type of tasks that can be associated with the project and how they will actually be
deployed, if at all.
The last requirement as determined from Chapter 2 involves the use of CartoDB as the
both the mapping platform and the backend database. The web application development will
mostly involve leveraging CartoDB’s capabilities in order to provide a simpler way to store,
manage,

43
Table 8 Core Data Index to Historic Buildings and Monuments of the Architectural
Heritage and Web Application Fields
Core Data Index to Historic Buildings and
Monuments of the Architectural Heritage
Corresponding Application Field
1.2 Unique Reference Number
The number or combination of characters which
uniquely identifies each building recorded by the
organization.

Each record will have a unique identification number.
1.3 Date of Compilation
Date of compilation of the core data index record.
This date may be modified whenever the index record
is updated.
Each record will show the original date of compilation,
as well as the dates of contributions and modifications.
1.4 Recording Organization
Name of the organization responsible for curating the
record. This information is useful in establishing the
provenance of the record when data is exchanged
between recording organizations.
Because the original records were all recorded by the
author, this information will be noted in the
methodology. However, all contributions will be logged
with information on who contributed the information.

2.1.1 Location – State (Country) All of the records are located in Hanoi, Vietnam.
However, because this project includes spatial
information, the map location of each record will be
both viewable and editable.
3.1 Building Type
Precise building type defined by function. This field
may be repeated to accommodate changes in type over
some period of time. Controlled vocabulary is
desirable.
Building type and category will be combined in one
dropdown list.
3.2 Building Category
Broad functional category to which the building type
belongs, e.g., Agricultural (Category); Barn (Type).
Controlled vocabulary is desirable.

4.0 Dating
This section allows for precise dating when it is
known, or date ranges or periods when it is imprecise.
Must consist of at least one of the following:
4.1 Period
4.2 Century
4.3 Date Range
4.4 Absolute Date
This project will provide a free text field for recording
all types of information. Because there are many
methods of dating that consists of different data formats,
any information on dating will be directed here.

Although not required, this project will incorporate a
dropdown field where users can contribute information
on the condition of a building, i.e. whether the building
is still there or if it has been altered.
Source: Data adapted from Thornes and Bold (1998)

44
Table 9 Crowdsourcing Tasks and Suitability for Contributory Inventory Web Application
Crowdsourcing type For Cultural Heritage Places For Web Application
Correction and
Transcription Tasks
Inviting users to correct and/or transcribe
outputs of digitization processes, such as
spatial information for historic places.
Users will be able to submit an edit
regarding the location of each record.
Contextualization Adding contextual knowledge about
historic places e.g. by telling stories or
writing articles/wiki pages with
contextual data.
Users will be able to submit a free text
description that may enhance
understanding of a record’s
significance.
Complementing Collection Active pursuit of additional places to be
included in an online cultural heritage
inventory.
Adding records is not within the scope
of this project, but may be included in
some future phase of the project.
Classification Gathering descriptive metadata related to
historic places. Social tagging is a well-
known example.
Users will be able to classify each
record in regards to building type.
Co-curation Using inspiration/expertise of non-
professional curators to create collections
of historic places to form a historic
narrative.
This is not within the scope of this
project or within the scope of most
online inventories.
Crowdfunding Collective cooperation of people who
pool their money and other resources
together to support efforts initiated by
others.
This is not within the scope of this
project.
Source: Adapted from Oomen and Aroyo 2011

and visualize data. This will be discussed further in the following sections which focus on the
web development components and programming.
3.1.2 Components
For its major components, the web application uses several web services (Figure 12), which for
this small implementation are provided at a free pricing tier. The survey data was processed
using software that adheres to traditional models, such as those provided by Microsoft, Adobe,
and Esri. However, the remainder of the application components follow the Software as a
Service (SaaS) or Platform as a Service (PaaS) model. Essentially, the web application’s code
accesses CartoDB (where the survey data and new contributor data is stored), MapBox, Google

45

Figure 12 Web Application Components

46
Fonts, and Persona through their respective APIs (Application Program Interfaces). The
application’s code is stored in a free code repository, Bitbucket, with free and open source
version control between it and the local virtual enviroment handled by Git. The application is
then deployed using Git to push to Heroku, a platform that enables web applications, with the
necessary dependencies, to run in the cloud. Finally, a feedback survey powered by Google
Forms is enabled by a URL link embedded in the application’s user interface. These components
will be discussed in more detail in the following sections.
3.1.2.1 Input Data
In this section, the design and methodology behind the collection of data for the web application
will be described. As mentioned in the Introduction, the input dataset consists of geo-tagged
photographs taken within a defined survey area around Hoan Kiem Lake in Hanoi. More than
140 photographs were taken (see Appendix A) while also recording a separate GPS track. The
two types of recording that were necessary to arrive at the final input dataset—image recording
and location recording—as well as the post-processing efforts will be described in this section.
The image recording instrument, the photographic camera, had to be able to capture
buildings accurately and also had to be available to the general public, per the goals of the study.
At minimum, a wide angle lens was required to capture as much of the full extent of a building
as possible. To that end, a Canon L Series F4.0 17-40mm lens was used in conjunction with a
full-frame Canon EOS 5D DSLR camera. As a backup, a Canon G9 point and shoot camera with
a maximum focal length of 28 mm (equivalent) and full manual capabilities was also available.
The location recording instrument had to be able to receive either a GPS or GLONASS
signal. Because they are ubiquitous, an iPhone 4s enabled with the trail tracking app, Easy Trails,
was used to record the location track.

47
Ideally, the two types of recording could be combined into one device. At one point,
using an iPhone as the only recording device was considered, but was ultimately discounted as
an option due to the focal length of the lens and resulting inability to capture an entire building at
the necessary angles.
The main software used for the survey included: (1) EasyTrails for iOS; (2) Adobe
Lightroom and Photoshop; (3) HoudahGeo; (4) Microsoft Excel; and (5) Esri ArcMap 10.1.
EasyTrails for iOS is an iPhone app that records the user's trail path via GPS. It indicates the
strength of the GPS signal, location in longitude and latitude, altitude, timestamp, and speed. The
tracking information can then be exported in GPX, KMZ or CSV formats.

GPX is the most
common format for GPS tracking information. KMZ is the Google Earth/Map format. CSV or
Comma Separated Values is a text file with information separated by commas to be imported by
spreadsheet programs, such as Microsoft Excel. For the purpose of this study, tracks were
exported in GPX format for later integration with the images.
Adobe Lightroom is a photo management software application with batch editing
capabilities, while Adobe Photoshop is a photo manipulation software application. Adobe
Lightroom was used to manage the large groups of photographs and their metadata as well as to
perform light color correction operations of image batches. Adobe Photoshop was used primarily
to create photo panoramas via the automatic setting of the Photomerge function.
HoudahGeo is a software application for Mac that merges GPS tracking information with
photographs based on timestamp information of each. In other words, this application creates
geotagged images (Figure 13).
The software gives users the option of exporting the merge information as metadata for
each photograph in EXIF format or providing a CSV file with the image filename, timestamp,

48
Figure 13 An example of HoudahGeo locating a Hanoi photograph along the GPS track
latitude, longitude and altitude. This CSV file can be used to create a point feature class in
ArcMap to plot out the locations of where the photographs were taken.
Microsoft Excel was used to edit the CSV file, so that other categories of information
could be added to each image file. For this project, two category fields, Style and Comments,
were added. Style refers to the predominant architectural style of the main subject building in
each photograph, while Comments specifically refers to any obstructions or impediments to
capturing a clean image of the building or area. In addition, each photograph was given an ID
number, which would serve as its identifier in any maps or catalogs.
Esri ArcMap 10.1 is the mapmaking software application that is included in the Esri
ArcGIS bundle. As a geographic information system (GIS) application, it was used to create
thematic maps using the geotagged photographs and the software-provided satellite imagery
basemaps. Using the CSV file and the Display XY Data function, point feature classes were

49
created that showed the locations of the geotagged photographs. For the Hanoi maps, a region-
specific geographic projection, the 1927 Hanoi geographic projection, was used so that the points
would appear in the correct location. Once the point feature class was created, simple thematic
maps based on architectural style and obstructions were created. These maps also used the ID
field to label each location.
For the web application, the data was imported into CartoDB using the CSV file. Upon
import, using CartoDB’s import interface, a table, hanoifrenchcolonial, was created with the
existing information.
3.1.2.2 Base Layer
The web application uses a street and satellite hybrid base layer generated via MapBox
(http://www.mapbox.com). It was determined that the base layer needed to show satellite
imagery so that users might be able to correct the location of each record with more accuracy. In
order to be able to use the MapBox hybrid street and base map, the steps were as follows: (1)
create a free MapBox account; (2) start a new Project; (3) select the Street/Satellite Hybrid base
map; (4) publish the Project (Figure 14); (5) insert the Map ID of the project and User API Key
into the map layer URL specified by the MapBox API; and (6) use the map layer URL in the
JavaScript code that initiates the maps in the application.
The satellite imagery of this base layer does not display at zoom levels higher than 17 (or
1:4,000 scale), but because the streets still display, the map is still functional. The Mapbox
Satellite imagery includes commercial imagery from DigitalGlobe, Geodatastyrelsen, FOT
Orthophoto, LGV Hamburg, National Survey of Finland, NLS Orthophotos, Geoportal Berlin,
DOP orthophotos, and other public sources. The Streets information is provided by
OpenStreetMap.

50

Figure 14 MapBox project screen

51
3.1.2.3 Database and Mapping Platform
Much of Section 2.4 was dedicated to describing CartoDB and the reasons why it is being used
for this project. This section will discuss the implementation of CartoDB for this web
application.
As mentioned in Section 3.1.2.1, the project’s survey data was imported into CartoDB,
after establishing a free account. The table, hanoifrenchcolonial, was created from this data. For
the purposes of the web application, the additional field, functional_type, was added to this table.
Table 10 describes all of the fields for the hanoifrenchcolonial table.
Table 10 Data fields for hanoifrenchcolonial table on CartoDB.
Field Name Type Description
cartodb_id number Identification number; generated by CartoDB.
the_geom geometry Spatial reference in decimal degrees; generated by CartoDB.
altitude string Altitude information; part of imported data.
city string City name; part of imported data.
comments string Survey comments; part of imported data.
country string Country name; part of imported data.
functional_type string Building type, by function; added to table for application.
id string Identification number; part of imported data.
latitude string Latitude in decimal degrees; part of imported data.
longitude string Longitude in decimal degrees; part of imported data.
name string Name; part of imported data.
photo_url string URL of photograph; part of imported data.
style string Architectural style; part of imported data.
the_geom_webmercator geometry Spatial reference for Web Mercator projection; generated by CartoDB.
timestamp string Photograph date/timestamp; part of imported data.
created_at date Record date/timestamp; generated by CartoDB.
updated_at date Record update date/timestamp; generated by CartoDB.

Using the hanoifrenchcolonial table, a map visualization, hanoi_2, was created on
CartoDB (Figure 15). This visualization is a standalone map that includes all of the survey
records and is categorized by style. This visualization is important because some of the layer
properties for hanoifrenchcolonial are specified via the options selected here. For example, as
seen in Figure 15, the hover properties for each map marker are specified here. The

52
implementation for the web application involves specifying the hanoifrenchcolonial layer and
querying it via SQL to SELECT for Art Deco records only.
Figure 15 CartoDB visualization of hanoifrenchcolonial data layer
A second table was created in CartoDB to house the data on the contributions collected
by the web application. Essentially, a copy of the hanoifrenchcolonial table and data was made
with the addition of fields specific to contributions: contribution_id, contributor, and state. The
original id field was renamed heritage_id. For the existing original records, the contribution_id
was populated with the number “1” to indicate its primary status. Also, for these original records,
the contributor field was populated with the author’s email address, since contributors will be
identified by email address, as described in the next section (Section 3.1.2.4). Any new records
will result from contributions from the web application and will be assigned a contribution_id
based on order for each heritage_id.
3.1.2.4 User Login and Authentication
Because the crowdsourcing aspect of this project involves the automatic publishing of
contributions submitted by contributors alongside the main record, it is important that
the contributors are real people who can be held accountable for what they submit. Because of

53
this need, this project uses the Mozilla service Persona to authenticate users via email. Persona
(http://www.persona.org) is hosted by Mozilla as a service to developers to enable easy
implementation of a password-free sign-in process to websites, without having to deal with
password management. Basically, users choose which email address to sign in with and the
service has them sign in through that email program's authentication screen. Similar to signing in
with social media, such as Facebook or Twitter, the service only requires the inclusion of
the Persona JavaScript file (include.js) script reference and the associated JavaScript embedded
in the application's code for the sign in/out buttons as well as for establishing the user's session
on the site.
3.1.2.5 Google Services
While Google Fusion Tables were not chosen and used for this project, three other Google
services are being used—Google Fonts, Google Forms, and Google Analytics.
Google Fonts (http://www.google.com/fonts) provides the ability to use 700 font families on any
website. Google hosts the fonts on their server, and developers can use the font by simply
referencing the font’s stylesheet URL and specifying the font style in the application’s CSS
document(s). For this application, the Google font, Josefin Sans, in both bold and semi-bold
weights were used for the headings, because of its Art Deco-like characteristics.
Google Forms (http://www.google.com/forms) is part of the Google Drive constellation
of services and offers an easy way for anyone to create an online survey. The survey forms are
hosted on Google’s servers, and can also be embedded, with the provided embed code, within
another website or web application. Responses can be captured via a Google Sheets spreadsheet
document, and then exported to another format, if required. For this application, a Feedback

54

Figure 16 Google Analytics page for Art Deco Heritage in Hanoi

55
Survey was created via Google Forms, and a link to the survey was included in the footer of
every page of the application. For more information about the contents of the Feedback Survey,
see Section 3.2.2.3.
Google Analytics (http://www.google.com/analytics) is being used to track the web
application’s traffic (Figure 16). Generally, the implementation for Google Analytics involves
the insertion of a script into a webpage that references the Google Analytics JavaScript file,
analytics.js, as well as the Google Analytics tracking key, which is established by signing up on
the Google Analytics website. However, for this implementation, Google Analytics is deployed
using a macro that is part of the Jinja2 templating engine for Python, which is being used for this
project (see Section 3.1.3.3).
3.1.3 Programming
Once it was established that a secondary purpose for this project was to develop the web
application in such a way that it could become a model for deploying similar types of
applications, the need for some robust programming became apparent. While the project employs
as many relatively easy to use services as possible, as seen in Section 3.1.2, solid programming is
required to ensure that all of the services work together harmoniously and in a way that promotes
best practices. Figure 17 provides an overall view of what will be discussed in this section as the
outside circles represent the development environment (Section 3.1.3.5), and everything within
the triangle represents the actual programming and implementation. However, before delving
into those topics, it is important to understand the basics of how a web application works.
3.1.3.1 Client-Server Model for Web Applications
Most web applications adhere to a traditional 2-tiered client-server model. A client (a web
browser on a desktop or laptop computer, smartphone, tablet, or other device) connects to a

56

Figure 17 Programming Diagram

server (the web application), and exchanges data with it. To facilitate this data exchange, the
client and the server use HTTP (Hypertext Transfer Protocol) to communicate with each other
(Figure 18).
For example, the client will request a website in the form of a URL (i.e. http://ale-
hanoi.herokuapp.com, the current URL for this project's web application). The server receives
this request and tries to generate an appropriate response. It will indicate how appropriate the
response was by using a status code. If the server understood the request and could find an
appropriate response, it will be reply by sending the response and adding a 200 OK status. But, if
it understood the request but could not find the resource in question, then it will reply indicating

57

Figure 18 Client-Server Model
a 404 Not Found error. While the HTTP protocol is the backbone of the operations behind the
web, it is largely invisible to most end users.
Another important part of the web to understand is the actual format of the response
being sent back to the client from the server. In a traditional website, this is almost always in the
form of HTML (Hypertext Markup Language). In combination with HTML, CSS (Cascading
Stylesheets) is used to provide style to the markups designated by HTML. While HTML and
CSS present web pages to clients that are meant for people, there are other protocols used to send
data for machines. Traditionally, the XML (Extensible Markup Language) format was used for
this purpose, but now, the lighter JSON (Javascript Object Notation) format is more common.
Both XML and JSON allow a client to ask a server for data without the presentation that HTML
and CSS provide. The client can then use these data for any purpose without having to deal with
the presentation layer. For this web application, both types of responses will be used. HTML is
sent to the client to present a certain page. And when requesting data from the CartoDB database,
the responses are returned in JSON.
Lastly, it is important to note that unlike earlier static versions of web pages, most web
pages are now generated dynamically. This means that if a website has 1,000 web pages, its
server does not need to store all of those web pages and then look for them once a request is
made by the client. Instead, the server will pass a request onto a program, which will

58
dynamically create a response to the request and pass it back to the server, which will, in turn,
pass it on to the origin of the request, the client. In this way, each web page can potentially be
tailored to each request.
3.1.3.2 Programming Languages
Most web applications today use more than one programming language, usually specific to
certain purposes. First, a programming language needs to be used on the server to generate
HTML output. For this purpose, several languages can be used, such as PHP, Ruby, Python, and
Java. For this web application, Python has been selected to generate the dynamic content. The
reasons behind this selection are as follows: (1) it can be used for a wide variety of purposes,
from generating content to GIS analysis and general scripting; (2) it is easy to read, understand,
and hence, learn; and (3) it is a mature language and as a result, has an equally mature set of
frameworks and libraries for generating content, communicating with web services and dealing
with spatial operations. Second, because the web application will also require programming on
the client side, JavaScript will be used, as it the standard for this purpose.
Apart from these two main programming languages, a couple of other languages were
used as well. In addition to HTML and CSS, which have already been discussed in the previous
section, the other language used is SQL (Structured Query Language). SQL is primarily used for
retrieving and inserting data into databases. In a traditional web application, a database server
would be hosted in addition to the web server, but for this application, the web service, CartoDB
will take the place of a traditional geodatabase. Regardless, SQL will be used to communicate
with CartoDB, which is built on top of a PostGIS/Postgres database, through the CartoDB API.

59
3.1.3.3 Server-Side Implementation
As discussed, Python will be used to generate a response on the server. Python's maturity also
means that there are several well documented and well used Python frameworks for web
development. A framework gives a developer a way of structuring the code, with some
scaffolding tools, and a set of best practices that help prevent the developer from needlessly
starting with a blank page. The three most popular Python frameworks are: Django, Flask, and
Pyramid. Because Flask is more of a microframework suited for smaller applications, Django
and Pyramid were compared for the purpose of determining which was a better fit for this web
application.
Django is a very opinionated full-stack framework, meaning it comes with a clear set of
tools and libraries for typical tasks that a developer might need to execute. In contrast, Pyramid
has a well-defined core, but gives the developer lots of flexibility to choose which tools are best
for which tasks. With Django, these choices have been largely determined by the framework, and
require a lot more effort to be changed.
Because of Pyramid's flexibility in this way, it was chosen as the framework for the web
application. As opposed to Django and Flask, it does not assume a local database will be used. It
is also very flexible in the authentication mechanisms it supports. As such, it has been configured
to run with Mozilla Persona, but due to the framework's flexibility, another identity provider
could be substituted, if the need arose. In addition, a library was found within the framework that
made it easy to incorporate a SKOS thesaurus for the controlled list of building types in our
application without much additional programming.
The main purpose of the Pyramid application is generating the response to a certain
request. In broad strokes, it does this in the following way:

60
1. It analyzes the incoming request. The requested resource is matched against a set of
routes. If the request matches one of these, a corresponding view is selected. If not, the
application generates a HTTP 404 Not Found response.
2. The selected view is compared to the user's credentials. If the view requires certain
credentials, and the user is not yet logged in, they are redirected to a login form. If the
user is logged in and has the required credentials, they are passed to the next step. If the
user does not have the necessary credentials, they are told they have insufficient
privileges.
3. The view is executed. This is a piece of code that can do whatever the developer needs it
to do. It is where the main activity takes place. For this web application, a view generally
connects to CartoDB using the Python requests library either to request data from the
CartoDB database, or to add new data to it. In the end, the view returns some data.
4. Pyramid then takes the response of this view and determines what renderer to use. A
renderer is responsible for turning the data returned by a view into the actual output to be
sent to the client. In this web application, either the Jinja2 renderer (cfr.infra) is used to
generate HTML or the JSON renderer is used to generate JSON data.
5. The renderer response is then returned as the body of an HTTP response, with the
necessary HTTP status code added to it.
Since most of the responses generated by the web application are HTML, the Jinja2
renderer is used extensively. Jinja2 (http://jinja.pocoo.org/) is a templating language that was
developed outside of the Pyramid framework. It can be used with both the Flask and Pyramid
frameworks, and recently support for it was added to the Django framework as well. A
templating language serves several purposes. First, it is a simplified programming language

61
aimed at generating output. So, it has a very narrow focus. A good templating language is also a
security measure. It creates a sandbox within which only a limited set of operations are possible,
making it more difficult for attackers to hack a system. And because it is focused on
presentation, it is easy for a web designer or non-programmer to learn because all of the details
of a complete programming languages are not necessary to understand.
For the web application, Jinja2 was set up with a simple inheritance model. Every
template created extends a base.jinja2 template. This base templates defines the general HTML
structure of each page on the site and allows the templates that extend it to inject content into
well-defined blocks. Also, there is a macro.jinja2 file that is used by the other templates in order
to take advantage of frequently used HTML macros. This file contains micro templates that can
be used as functions would be in other programming languages.
3.1.3.4 Client-Side Implementation
Although the server is essential, some programming had to be accomplished on the client-side, as
well. As mentioned, for this, Javascript was used. To make it easier to style the web application,
the Foundation CSS framework was used. Just as with the Python framework, this provides a set
of tools and best practices to help in creating useful and rich interfaces. One of its main strengths
is that it creates fully responsive web pages as a default. This means that with little effort by the
developer, a website using this CSS framework will run on very diverse screen sizes, from a
small smartphone to a larger desktop. Foundation CSS relies on the jQuery library, which is one
of the most popular JavaScript libraries, and makes certain tasks such as animating parts of the
screen or doing AJAX requests easier.
One of the focal points of the web application is the interactive map on the Home page
(see Figure 22). This is typically the kind of functionality that would require a lot of custom

62
JavaScript. However, because the web application model is using CartoDB, the map rendering
and functionality is largely taken care of by CartoDB's simple library (which itself is powered by
the Leaflet mapping library).
3.1.3.5 Development Environment
After describing the different components of the web application, the next step is to define the
process by which the application will actually be developed and deployed. Because the
application is eventually meant to be put forth as a model that can possibly be used for other
deployments, the process has been geared towards working in a development environment that
facilitates this.
As such, the most essential component in developing the application is Git. Git
(http://www.git-scm.com/) is a version control system that allows tracking of all the files used
for an application and all modifications made during development. It keeps a full history of who
changed what, where, and when. This kind of tracking comes in handy when a bug is detected
and needs to be resolved. In contrast to a version control system such as Subversion, Git is
decentralized, meaning that there is no single master copy that controls all of the other copies.
Multiple copies (clones) of a repository exist that contain all of the code needed to deploy a web
application. Usually, one is designated as a master copy, but the clones can easily take the place
of that copy if something goes wrong. In a sense, it serves as a sort of backup.
In order to host the "master" copy of the web application's code, Bitbucket
(http://www.bitbucket.org) is being used. This web service hosts git repositories, with features
such as a ticketing system for bugs and a wiki, that helps to facilitate usage by others and
collaboration. The development workflow with Git and Bitbucket for the web application is
illustrated in Figure 19. In addition to the code being hosted on Bitbucket, a local git repository

63
was maintained where most of the programming and development took place. Once changes
were made locally, git was used to push those changes to the Bitbucket repository in order to
keep both versions in sync. In a more collaborative development enviroment, the Bitbucket
repository would be the master source for the code and individual developers would both pull
changes from it and push changes to it.
Figure 19 Development Environment Diagram

During the development process, a local server was run on the development machine. In
this case, the development machine was a MacOS laptop. Because our web application required
certain dependencies, primarily Python, a virtual environment was set up with those
dependencies and the application code installed. This is a generally accepted best practice in web
development as it creates a separation between the normal operations of one's development
machine and those required for the development of a specific web application. For example,
virtual environments enable developers to run local servers for two different applications with
different dependencies without creating problems due to issues having to do with different
versions. In other words, an application running on Pyramid 1.0 can exist on the same machine
as one written for Pyramid 1.5.

64
Once the application development is complete, the final step is to publish it onto the web.
While running a server locally is expected for development, this is not an option for a production
web application. After doing research on cloud-based hosting platforms, Heroku was chosen due
to its ease of use. Setting up a Heroku account created a git respository for the application on the
Heroku servers. At this point, the local repository could be pushed using git to the Heroku
repository, triggering a build. At that point, Heroku looks for the requirements.txt file in the
repository and installs all of the dependencies listed in that file and restarts the application.
3.1.3.6 Programming Challenges
Admittedly, the majority of the Python programming was challenging because it was a relatively
new language for the developer/author. However, as discussed in the sections above, much of the
harder work was handled by the Pyramid framework, which is very well documented and has a
very active community for support, despite not being as popular as Django. Because the
developer/author is well-versed in HTML, CSS, SQL, and to a lesser-extent, JavaScript, much of
the client-side implementation was easy, especially working with the Jinja2 language. Given all
of that, most of the programming challenges had to do with interacting with CartoDB, which
does not offer the same level of documentation or support for its service, especially at the free
pricing tier, and can be somewhat buggy given this type of implementation.
For example, initially building names contained a “#”, such as “Building #123.”
Unfortunately, the inclusion of that character within the HTML of the jinja2 template somehow
rendered the call to CartoDB useless, and contributions were not being logged. After trying to
find a way to fix this, looking through existing documentation and also doing internet searches
on the same problem, it was determined that the best fix was just to change the names and
remove the “#” so that they would appear as “Building 123.”

65
In addition, functionality that is currently specified in the application roadmap (Section
5.3) such as giving contributors the ability to create new records was beyond the ability of the
developer in the midst of development. However, that functionality is within better reach given
the experience of developing the current web application.
3.2 Application Evaluation
The evaluation of the web application is divided into two categories: primary and secondary.
Primary evaluation refers to the immediate assessment that will take place after the initial
development as described in Section 3.1. It is the only type of evaluation that will be completed
for this thesis project. The secondary evaluation is not part of this thesis project, but will be
described because the tools to initiate it long after the scope of this thesis were built into the
application.
3.2.1 Primary Evaluation
Upon completion of initial development, the web application will be evaluated by determining
whether it has met the requirements put forth in Section 3.1.1.2. These requirements are phrased
as yes or no questions, and are grouped by user experience, standard inventory data fields, and
crowdsourcing tasks. An evaluation using these questions will be detailed in Chapter 4.
3.2.1.1 User Experience Requirements
These questions correspond to the requirements outlined in Table 7:
• Does the application feature a map showing each record’s location?
• Does the application feature a simple layout with explanatory text and links that clarify
how to use the web application?

66
• Does the application feature content that promotes the application’s purpose of heritage
conservation?
• Does the application feature a map-based search?
• Does the application feature no requirements to login or sign up to view information?
• Does the application feature an About section dedicated to exposing the purpose and
methodology of the application?
3.2.1.2 Heritage Inventory Data Field Requirements
These questions correspond to the requirements outlined in Table 8:
• Does each record have a unique identification number?
• Does each record show the original date of compilation, as well as the dates of
contributions and modifications?
• Are all contributions logged with information on who contributed the information?
• Is the map location of each record both viewable and editable?
• Does each record have a field for building type and category with controlled values in a
combined dropdown list?
• Is there an area to contribute dating information on the building?
• Are users able to contribute information on the basic condition status of a building?
3.2.1.3 Crowdsourcing Task Requirements
These questions correspond to the requirements outlined in Table 9:
• Are users able to submit an edit regarding the location of each record?
• Are users able to submit a free text description that may enhance understanding of a
record’s significance?

67
• Are users able to classify each record in regards to building type?
3.2.2 Secondary Evaluation
The secondary evaluation is not a part of this thesis project. However, once the web application
has been deployed and efforts at dissemination have been made, it is intended that a secondary
evaluation will occur and as a result, the tools needed to conduct a secondary evaluation were
incorporated into the web application. The three measures that will be used after the thesis
project to evaluation the application are: (1) web application traffic; (2) contributions; and (3)
responses to the feedback survey.
3.2.2.1 Web Application Traffic
The web application currently logs traffic via Google Analytics (see Figure 22). When the
secondary evaluation is undertaken in the future, the appropriate web application traffic statistics
will be analyzed.
3.2.2.2 Contributions
The number and quality of contributions will be taken into account during the secondary
evaluation, as well as a look at the unique contributors. A request for information will likely be
sent to the email addresses used to log in via Persona to the application.
3.2.2.3 Feedback Survey
A link to a feedback survey is included on every page of the web application. This links to a
Google Forms-hosted survey that focuses on the user experience of visitors to the application. As
such, the questions asked are closely aligned to the user experience questions used for evaluating
other heritage inventory websites as well as those used for the primary evaluation. Table 11
details the feedback survey questions.

68
Table 11 Feedback Survey Questions
Category Question Type
Usefulness Does the website present information on the buildings
that is new and/or unique?
Scale
(1-5; 1=Strong No/5=Strong Yes)
Usefulness Does the website present information on the buildings
that is useful?
Scale
(1-5; 1=Strong No/5=Strong Yes)
Usefulness How would you improve the usefulness of the
information on the website?
Paragraph Text
Usability Does the website present information on the buildings
in an easy to use format?
Scale
(1-5; 1=Strong No/5=Strong Yes)
Usability How would you make the website easier to use? Paragraph Text
Desirability Does the website's design evoke positive emotions and
appreciate for the buildings?
Scale
(1-5; 1=Strong No/5=Strong Yes)
Desirability Does the website promote the conservation of the
buildings?
Scale
(1-5; 1=Strong No/5=Strong Yes)
Desirability How would you improve the website's design to
enhance its ability to contribute to the conservation of
these buildings?
Paragraph Text
Discoverability Does the website’s map make it easy for you to find the
buildings and the information on them?
Scale
(1-5; 1=Strong No/5=Strong Yes)
Discoverability How would you improve the website and/or map to
make it easier to find the buildings and the information
on them?
Paragraph Text
Accessibility Does the website hinder access in any way to the
information on the buildings?
Scale
(1-5; 1=Strong No/5=Strong Yes)
Accessibility How would you improve access to the information on
the website?
Paragraph Text
Credibility Do you think the website provides credible information
on the buildings?
Scale
(1-5; 1=Strong No/5=Strong Yes)
Credibility How would you improve the credibility of the
information on the website?
Paragraph Text
Contributions Did you log in to the website and contribute
information?
Yes or No
Contributions If yes, was it easy to contribute information to the
website?
Scale
(1-5; 1=Strong No/5=Strong Yes)
Contributions Is the website collecting information on the buildings
that is not found elsewhere?
Scale
(1-5; 1=Strong No/5=Strong Yes)
Contributions Is the website collecting information on the buildings
that is adequate for your needs?
Scale
(1-5; 1=Strong No/5=Strong Yes)
Contributions How can we improve the contribution process on the
website?
Paragraph Text
General Questions Are you...
• a student?
• a heritage and/or conservation professional?
Check Boxes
(Instruction: Check as many boxes
for which your answer is "Yes".)

69
• an architectural historian, architect, or
historian?
• a current or prior resident of Hanoi?
• a current or prior visitor of Hanoi?
• a current or prior tourist of Hanoi?
• interested in the conservation of Hanoi's
architectural heritage?
• involved in government or public policy in
Hanoi?
General Questions Did you...
• access the website from a desktop computer?
• access the website from laptop computer?
• have access to a high speed internet
connection?
• use Chrome as your browser?
• use Internet Explorer as your browser?
• access the website from a mobile device (i.e.
tablet or phone)?
• use Safari as your browser?
• use Firefox as your browser?
Check Boxes
(Instruction: Check as many boxes
for which your answer is "Yes".)
General Questions General Comments Paragraph Text

70
CHAPTER FOUR: RESULTS
In this chapter, the results of both the application programming and the application evaluation
will be discussed. In the first section, titled Application Description and Functionality, all aspects
of the resulting web application will be shown. In the second section, titled Application
Evaluation, the application will be measured using the evaluation framework that was outlined in
Chapter 3. That framework was itself the result of the process shown in Figure 3, in which an
emphasis on requirements was shown to be central to the organization of this thesis project.
4.1 Application Description and Functionality
Figure 20 illustrates the information architecture of the web application, which can be found at
http://ale-hanoi.herokuapp.com. Starting at the Home page, users immediately encounter a map
of the project area, which they can interact with and explore the various records through. After
clicking on a map marker, an InfoWindow pops up with an image of the subject building as well
as a button with the option to view the full record, and a link to log in to contribute to the record.
If the user has already logged into the application, then a button to contribute to the record will
appear. If the logged-in user clicks the button to contribute, then he or she will be taken to a
contribution form for the record.
Based on the login status of the user, the top bar navigation changes from having links to
the Home page and map, the About page, and the Login page, to having links to the Home page
and map, the About page, the My Contributions page, and the Logout page. The About page
(Figure 21) has relevant information about the project background and will have a link to this
thesis document so that users can see the methodology behind the project.
The diagram highlights one external link, the Feedback Survey Form, which opens a new
window with a Google Form where users can evaluate the application based on the established

71

Figure 20 Application Flow Diagram

framework and also offer other comments on how best to improve the application.
As mentioned previously the web application has been built on a responsive template, so
that it can be viewed on both traditional and mobile screens with the same utility. As a result, the
site is relatively simple, using similar colors to that of the Vietnamese flag paired black and
grey for impact. Two sans serif fonts are used in order to provide design continuity throughout
the site. For the titles and headings, the Art Deco-inspired Google Font Josefin Sans is
used. Arial is used for the body and other smaller sized text. Each page is based on a similar

72

Figure 21 About page

73
template which has at its minimum top navigation bar, and a simple footer. The content between
those two elements changes depending on the page.
4.1.1 Home Page and Map
It was important that users encounter the main map immediately so that they could explore the
main content of the application the building records. As a result, the map takes up most of the
area of the page (Figure 22). Each of the markers on the map can be rolled over to reveal a
tooltip that shows the building's name as given for this project. Upon clicking the marker, a
InfoWindow pops up.

Figure 22 Home page
4.1.1.1 Home Page Map InfoWindow
The map InfoWindow (Figure 23) contains the building name, the associated photograph, a
button for the full record ("See the record!"), and depending on the login status of the user, either

74
another button to contribute to the record ("Make a contribution!") or a link to login to the
application. When viewed on a mobile phone, the InfoWindow fills the entire screen.
Figure 23 InfoWindow screenshot

4.1.2 Building Record Page
The full record of the building (Figure 24) contains two tiers of information. The first, the Main
Record, is the original record that resulted from the June 2012 survey. The second,
Contributions, includes that initial record and any subsequent contributions that were submitted
afterward.
The Main Record contains the original photo, and a table of information that was
assigned in the post-processing stage of the input data preparation: (1) the project ID number; (2)

75
Figure 24 Building record page
the Country, which is "Vietnam" for this dataset; (3) the City, which is "Hanoi" for this dataset;
(4) the Style, which at this stage should all be "Art Deco"; (5) the Functional type, which is blank

76
because this information is awaiting contribution; (6) the Survey date; and (7) the date of the
Last Update.
The Contributions section has entries that contain: (1) either a new photo or the default
photo for the record; (2) a Contribution ID number, (3) the Style, which can be left unchanged
from the original; (4) the Functional type, which can be left blank, if unknown; (5) the State of
the building compared with the original 2012 record; (6) any Notes made by the Contributor
about the record; (7) the Contributor's email address, which serves as their login ID; and (8) the
Date of contribution.
4.1.3 Login Page
The Login page can be accessed via two links. The first and most prominent link is through the
top bar navigation. The second link is located inline within the text of the map InfoWindow. This
page (Figure 25) has some text briefly describing what can be viewed with and without signing
into the site. The Sign In button is a standard Persona-branded Sign In button. Once pushed, the
Persona pop-up window is activated.
Figure 25 Login page

77
4.1.3.1 Persona
As described in Chapter 3, Persona is a Mozilla service that provides user sign in and
authentication via a valid email address. The Persona pop-up window (Figure 26) contains the
necessary fields for users to enter their email address and associated password. The password
information is not stored by the application at all. Once the email address is verified, the site
shows the user as logged in.
Figure 26 Persona Pop Up Window

4.1.3.2 Logout Page
Clicking on the logout link in the top bar navigation will lead to the logged in version of the
login page which has a logout button instead of the Persona signin button (Figure 27).

78
4.1.4 Contribute Page
After logging into the application, users can return to the map and contribute to each record by
Figure 27 Logout Screen
selecting the "Make a contribution!" button. The Contribute page (Figure 28) has fields for: (1)
the Building ID, which cannot be changed; (2) the Name of the building, which is a text field; (3)
Map Marker edits, where the user can reposition the record's marker on the map; (4) the Current
Condition State, which consists of a selectable dropdown list; (5) the Architectural Style, which
is prepopulated with Art Deco, but also gives contributors the opportunity to disagree with the
style assessment and select another style from the dropdown list; (6) the Building Type, also
known as the Functional Type, which also consists of a dropdown list; (7) a Photo URL, where a
new contributor-supplied URL for a photo can replace the existing URL for the contribution; and
(8) a free text field which contributors can use to provide notes or other relevant information.
For the dropdown fields, the controlled values help to enforce consistency. The values for
each of these fields and source for the values are detailed in Table 12. The editable map marker
is powered by Leaflet Draw, and the map source is the same as the main map on the home page.

79
Once the contributor submits the entry via the "Submit" button at the bottom of the page, the
information is automatically sent to the CartoDB table, hanoifrenchcolonial_contributions, where
Figure 28 Contribute page

80
Table 12 Dropdown field values on Contribute page
Field Name Values
Current Condition State Unaltered; Altered; Demolished
Architectural Style Art Deco; Beaux Arts; Colonial Vernacular; Modern; Other
Building (Functional)
Type
schools (buildings); pre-primary schools (buildings); elementary schools (buildings);
middle schools (buildings); junior high schools (buildings); high school (buildings);
university and college buildings; academies (buildings); secondary schools (buildings);
office buildings; government office buildings; corporate plazas; corporate headquarters;
administration buildings; health facilities; multipurpose buildings; religious structures;
public accommodations; hotels (public accommodations); hostels; commercial
buildings; markets (structures); market halls; supermarkets; stores; restaurants; bars;
financial institutions (buildings); institutes (buildings); residential structures; institutions
(buildings); museums

the application administrator can view them. The contributor can either visit the Building Record
or the My Contributions page.
4.1.5 My (User) Contributions
Each contributor can see what they have contributed by clicking on the "my contributions" link
in the top navigation bar or via the inline link on the login page. The My Contributions page
(Figure 29) has every contribution made while logged in with the contributor's email address.
Figure 29 My Contributions page

81
4.1.6 CartoDB Table View
While not necessarily part of the web application, it is important to note that at this stage in
development, there is no administrator tool built into the web application with which to evaluate
user contributions. The information in the CartoDB contribution table will have to be evaluated
by the administrator via some other external method or process.
4.1.7 Feedback Survey Form
In addition to a link for the personal website of the author, the footer includes a link to a survey
(Figure 30) for users to provide feedback on the site. Hosted by Google Forms, the survey is
based on the evaluation framework developed in Section 3.2. The results are captured in a
Google Sheets spreadsheet.
4.2 Evaluation Results
Overall, the web application fulfilled all of the requirements established in Chapter 3 for the
primary evaluation. The primary evaluation set minimum requirements based on a survey of
related work. The extent to which these minimum requirements lead to a successful web
application in the long term will eventually be measured in a secondary evaluation, which will
not occur until the web application has been used by both the general public and those involved
in cultural heritage conservation.
4.2.1 User Experience Requirements
As mentioned in Chapter 3, this set of requirements relates to the application’s user experience.
4.2.1.1 Usefulness Requirement
Does the application feature a map showing each record’s location?
The web application features a map that occupies most of the Home page (see Figure 24).

82

Figure 30 Feedback Survey on Google Forms

4.2.1.2. Usability Requirement
Does the application feature a simple layout with explanatory text and links that clarify how to
use the web application?
Because the web application is built on a responsive template, much of the layout is simple
because of the potential need to collapse content containers to accommodate smaller mobile

83
screens. The navigation is clearly labeled, and most pages contain explanatory text and links that
instruct the users on how to use the application.
4.2.1.3 Desirability Requirement
Does the application feature content that promotes the application’s purpose of heritage
conservation?
The About page (see Figure 21) provides some background on heritage conservation in the area
as well as some information about the project’s purpose.
4.2.1.4 Discoverability Requirement
Does the application feature a map-based search?
Because each original record consists mainly of a photograph and a spatial reference, searching
on anything but the map is unnecessary at this point. The map on the Home page (see Figure 24)
is interactive, so users can zoom in and out, and pan around the map in order to find records.
4.2.1.5 Accessibility Requirement
Does the application feature no requirements to login or sign up to view information?
As stated on the Login page (see Figure 25), “You may browse the site and view all of the
information (including contributions) on the buildings in the system without signing in.”
However, if the user wants to contribute information to the site on any building record, then he
or she must log in using Persona button.
4.2.1.6 Credibility Requirement
Does the application feature an About section dedicated to exposing the purpose and
methodology of the application?

84
The web application features an About page (see Figure 21) with content as to the project’s
purpose, as well as link under Methodology to this thesis document. In addition, information on
the author is provided via a link to her personal website.
4.2.2 Heritage Inventory Data Field Requirements
As described in Chapter 3, this set of requirements relates to the most essential data fields needed
for a heritage inventory of historic architecture. The illustrative figures for this section come
from the Building Record (see Figure 24) and Contribute pages (see Figure 28), which
accommodate the capture of all necessary data fields.
4.2.2.1 Unique Identification Number Field Requirement
Does each record have a unique identification number?
This unique identification number was automatically generated when the photographs were
initially processed and also forms part of the record name. The unique identification number can
be found in the Main Record section of the Building Record page in the ID field (Figure 31). In
addition, each Contribution is automatically assigned a Contribution ID, which is a combination
of the original record’s ID and the order number of the contribution (Figure 32).
4.2.2.2 Recordation Date Field Requirement
Does each record show the original date of compilation, as well as the dates of contributions
and modifications?
Each record shows the original compilation or survey date, which in this case, refers to when the
photograph was originally taken. The web application automatically shows the date of any
update to the main record (see Figure 31), as the CartoDB table automatically logs the date of
any changes to the record. In addition, the date of each contribution is recorded (Figure 32).

85
Figure 31 Main Record section of Building Record page
4.2.2.3 Contributor Information Field Requirement
Are all contributions logged with information on who contributed the information?
With each contribution, the web application also logs and displays the email address of the
contributor (Figure 32).
Figure 32 Contributions section of Building Record page
4.2.2.4 Location Information Field Requirement
Is the map location of each record both viewable and editable?
In addition to being able to view the location of each record on the Home page map (see Figure
21), the Contribute page features the ability to edit the location of the map marker for each
building record (Figure 33).

86
Figure 33 Location editing section of the Contribute page

4.2.2.5 Building Type and Category Field Requirement
Does each record have a field for building type and category with controlled values in a
combined dropdown list?
Users are able to classify each building by function using the controlled values in the Building
Type field dropdown list (Figure 34). These values combine both building types and categories.
On the Building Record page, each type is hyperlinked with information (Figure 35),
corresponding to the Getty Art and Architecture Thesaurus, from which the values were selected.
Figure 34 Building Type dropdown list detail on Contribute page

87
Figure 35 Building (Functional) Type detail, accessed via hyperlink on Building Record
page

88
4.2.2.6 Dating Field Requirement
Is there an area to contribute dating information on the building?
Because dating and time period information regarding when a building was built can come in
different formats, and can be hard to verify without additional research, this information was
grouped in the set of information that could potentially be provided in the free text field (Figure
36).
Figure 36 Free text field on Contribute page
4.2.2.7 Condition Status Field Requirement
Are users able to contribute information on the basic condition status of a building?
This information was not required, but because it provides basic information on whether the
building still exists, it was included (Figure 37). By making the dropdown choices simple, most
users who have had a recent experience with or a photograph of the building can compare that
with the original photograph to determine whether the building is unaltered, altered, or
demolished.
Figure 37 Current Condition State dropdown list detail on Contribute page

4.2.3 Crowdsourcing Task Requirements
The crowdsourcing requirements for the web application relate directly to the submittal of
contributions by users who have logged into the site. Three types of contributory tasks --
correction, contextualization, and classification -- have been included in the web application.

89
4.2.3.1 Correction Task Requirement
Are users able to submit an edit regarding the location of each record?
This was answered in Section 4.2.2.4.
4.2.3.2 Contextualization Task Requirement
Are users able to submit a free text description that may enhance understanding of a record’s
significance?
While contributors are given suggested topics for the free text description, they can provide any
type of information or narrative in the free text field (see Figure 35).
4.2.3.3 Classification Requirement
Are users able to classify each record in regards to building type?
This question was answered by Section 4.2.2.5.

90
CHAPTER FIVE: DISCUSSION AND CONCLUSIONS
In this final chapter, the web application’s observed strengths and weaknesses will be discussed.
This discussion will then lead into a summary of the next steps for the project and the web
application. Building upon this, an example of an emerging trend in online heritage inventories,
the Arches platform, will be explored with possible implications for this project in the future.
5.1 Application Strengths
The evaluation in Section 4.2 demonstrated that the application fulfilled the minimum
requirements that were determined in Section 3.1.1.2. This section will further outline the
strengths of the web application, and also, discuss the strengths of the resulting web application
model.
Generally, the web application’s strengths are as follows: (1) it publicizes Art Deco
buildings that might not necessarily be well known in the area; (2) it invites anyone to get
involved and contribute information to each record that might be able to be used by others in the
process of conservation; (3) it is easy to use and can be accessed on any computer or device that
has an internet connection; and (4) it incorporates heritage inventory data standards so that the
eventual collected information can be useful for inclusion in a statutory or other type of heritage
inventory that follows best practices.
As mention in Section 3.1.1.1, part of the purpose of this project is to develop the web
application in such a way that it can serve as a web application model for others. Taking this into
account, the web application model’s strengths are: (1) it does not require advanced database
management setup and maintenance skills; (2) once the code repository is opened on Bitbucket,
the code can be customized and extended to better suit a project’s requirements; (3) the

91
application’s components are either free or relatively inexpensive compared to setting up similar
services hosted on one’s own servers; and (4) it enables technically skilled individuals to become
involved in cultural heritage conservation.
5.2 Application Weaknesses
The web application's weaknesses stem from the execution of some of its strengths. For example,
while in theory, anyone can contribute to the project, one major hurdle to overcome is the local
language. The official language in Vietnam is Vietnamese, and while English is becoming more
popular as a second language for the younger generation (Nguyen 2012), the majority of the
population speaks Vietnamese. As a result, the web application is effectively inaccessible to
most of the local community, many of whom might have relevant information to contribute. For
this reason, translation of the web application into Vietnamese is included in the application’s
roadmap for future development.
In terms of publicizing Art Deco buildings that are not well known, because the project
started with a smaller survey area, much smaller than the entire Hanoi metropolitan area, there
are likely many more Art Deco buildings that can be included. However, the application
currently lacks the ability to add new records, which would facilitate the real discovery of
possibly underappreciated buildings of the style and era. Again, this functionality has been
placed on the roadmap as a high priority item. Also related to this as a medium priority is the
ability to load photographs without the need for contributors to host the image somewhere else
and generate a URL. Photographs are the main source of information for these buildings so far,
and not being able to load new photograph without this barrier limits the amount of information
about the existing records that can be collected.

92
Also, in regards to recording additional information, the application does not have a way
to record a user’s location on the map using mobile geotracking or geolocation. The application
is already responsive and as such, is optimized to be viewable on a tablet or mobile device.
Adding the ability to see and record actual spatial coordinates will add a new level of usefulness
for those who might want to use the application as a survey tool. There are several ways that this
can be accomplished without creating a non-browser-based mobile application. The application
uses the Leaflet javascript library to serve the map, and a Leaflet plug-in, Leaflet.Locate,
provides the ability to geotrack the user on the map. In addition, Esri has some developer tools
that prompt additional research, such as its Geotrigger Service, which can alert users when they
are near a recorded building site and can prompt them to record or confirm information.
On the administrative side, no application interface exists to manage, vet, and push
contributions to the main record. Currently, the administrator will have to perform that analysis
through a comparison of the hanoifrenchcolonial and hanoifrenchcolonial_contributions tables.
This does not even take into account the veracity or accuracy of the contributions, and perhaps a
public vetting process is also in order.
In regards to using the web application as a development model for similar projects, apart
from the already-mentioned weaknesses of the application itself, implementation will require
some technical expertise and programming experience, despite all efforts to make the application
as easy to implement as possible, with the use of several different user-friendly web services. In
order to counteract this, the Bitbucket repository will not be made accessible until good
documentation for installation and usage is included.

93
5.3 Application Roadmap
During the development process, it became clear that there were some features that would
improve the web application despite not being within the scope of the initial requirements or
perhaps being too difficult at this stage to program or implement. These, along with other
initiatives, have been included in the web application’s roadmap for future development, which
has been categorized by level of importance (Table 13).
Table 13 Web Application Roadmap
Future Web Application Feature or Activity Importance Notes
Translation into Vietnamese High
This would expand the possible contributor
pool for the project area.
Ability to add new records via application High
This would allow contributors the ability to
add records from outside the pilot survey
area.
Refine navigation Low
Once the site has more records and
information, this would help users to find
what they are looking for.
Integrated interface to manage contributions Medium
This would give the application
administrator and/or users the ability to vet
contributions and push changes to the main
record.
Ability to upload images without user-supplied
URL
Medium
This would give users the ability to include
an image with a contribution without having
to host the image online.
Add geotracking/geolocation ability to map Medium
This would give users the ability to see and
record their actual location in relation to the
building records while viewing and/or
contribution to the application.
Open Git repository on Bitbucket and provide
documentation for web application model
implementation
High
This would allow others the ability to
implement and improve the web application
model.
Secondary evaluation activities described in Section
3.2.2.
Medium
This would provide an actual user
perspective to the evaluation of the web
application.

94
The importance of each item on the roadmap is determined by looking at the item’s
ability to improve the project as well as the ease of execution and amount of effort. For example,
the ability to add new records is a feature that does not currently exist for contributors and would
expand the amount of data collected on Art Deco buildings in Hanoi and possibly beyond.
Whereas, refining the navigation only marginally improves the user’s experience and might
require a substantial amount of programming to execute.
5.4 Future Trends
For online heritage inventories, future trends involve leveraging new semantic technologies and
incorporating geospatial features more heavily. An illustration of this will be described below.
In 2013, the Arches Project, a joint effort between the Getty Conservation Institute and
the World Monuments Fund, released the first version of a purpose-built geospatial immovable
heritage inventory and management system as free open source software. It is an enterprise-level,
server-hosted platform that is accessed via a web browser and can be used as is or customized for
each individual deployment. In 2015, the project released a third version of the inventory
platform, Arches Version 3.0. This version restructured the platform to include a core system,
Arches Server, that serves as the backbone for various Arches web applications, such as the
Arches Heritage Inventory Package (HIP) web application, which provides a heritage inventory
data model and user interface. The system consists of four basic components: (1) a server tier
built in Django using Python; (2) a responsively designed user interface built using Bootstrap,
Javascript, and CSS; (3) a PostGIS/PostgreSQL database; and (4) a semantically-driven search
engine powered by ElasticSearch.
One of the goals of the project is to provide an inventory platform to cultural heritage
organizations that incorporates the latest semantic technologies to facilitate data interoperability,

95
longevity, and discoverability. To that end, the Arches platform models its data through a graph
structure that incorporates an ontology based on the CIDOC Conceptual Reference Model
(CRM). The CIDOC CRM ontology is an event-based model that creates defined relationships
(Properties) between entity types (Classes). For example, a historic place would be given a class
number of E18, which represents a Physical Thing, and its name would be given a class number
of E41, which represents an Appellation. The relationship between them is defined through a
property number of P1, which says that the historic place (E18) “is identified by” an appellation
(E41). Working in conjunction with this was the unpublished data standard mentioned earlier,
the International Core Data Standard for Archaeological and Architectural Heritage.
Another way in which Arches supports its semantic goals is through its Reference Data
Manager (RDM) module, which manages controlled vocabularies for the dropdown fields in the
Arches data entry forms. The RDM is compliant with the Simple Knowledge Organization
System (SKOS), which is a set of specifications that take advantage of the Resource Description
Framework (RDF) to represent knowledge systems such as controlled vocabularies, taxonomies,
and classification schemes. Currently, SKOS specifications are published as World Wide Web
Consortium (W3C) Recommendations.
Despite the complexity of the Arches system, much of that complexity is hidden via a
highly usable user interface for both those interacting with the public face of the system to view
and search through the data and those editing and managing the data by logging into the system.
The geospatial capabilities allow for the assignment of multiple types of geometries to a single
record, as well as the in-system geometry digitization for defining a site location as well as a
search area.

96
Arches was not used for this project because of several factors. At the time of the initial
development of this project, Arches Version 2.0 was the stable version of the software, and the
system setup required technical knowledge that is beyond what most heritage professionals
would reasonably have. Version 3.0 streamlines the setup process significantly, but even in this
case, customization from the generic Arches inventory application requires intermediate
programming skills in Python and JavaScript. In addition, in order to deploy a functional version
of the Arches platform, investment in and management of a server, whether traditional or cloud-
based, would be required. Arches is a robust system, and taking into account the setup of the
PostGIS/PostgreSQL database and ElasticSearch engine that it depends on, as well as other
requirements, it does not fit the goals of this project. In addition, at the time of development of
this project, it did not have an internal contributor workflow in place to deal with the
requirements of crowdsourcing information.
However, because the data fields for the web application are based on similar standards
to Arches, it should be possible to import the information from the web application to Arches
once enough information has been gathered through user contributions.
5.5 Final Thoughts
In April 2015, a colleague was able to visit Hanoi and take photos of many of the Art Deco
buildings in the project area. As a result, it was confirmed that after almost three years since the
June 2012 survey, 14 out of the 24 Art Deco buildings in the project are still extant, many in a
similar condition or improved. While this can be attributed to the project area being in the French
Quarter, a well preserved part of Hanoi that houses many government buildings and tourist sites,
it is still a heartening indicator that at least some of the French Colonial architectural heritage in
the city is of value to the area.

97
Hopefully, this project will grow to contribute to a sense in the community that these
buildings are worthy of conservation, not just in the tourist areas, but also in areas that might not
traditionally be considered part of the usual tourist routes. There are many instances of urban
landscapes that were preserved because of benign neglect or some similar type of conservation
by accident that later experienced a resurgence due to the numbers of extant historic buildings.
An example of this is the Downtown Los Angeles area. For much of the latter part of the
20th century, Downtown Los Angeles was considered an undesirable place to be within the city,
for both work and personal pursuits. As a result, little development took place within the area
and the existing early 20th century commercial buildings stood with retail establishments on the
street level but with upper floors that were often used for storage or data centers. But the point is
that the buildings stood. In the beginning of the 21st century, people began to move into the
historic buildings as a city ordinance made it easier to redevelop the commercial buildings for
residential purposes. And in 2014, the New York Times named Downtown Los Angeles as the
fifth highest ranked place out of 52 to visit in the world for its emerging food scene and the
historic environment in which it is flourishing.
This example shows that public opinion about the built environment can change over
time and that a built environment rich in history can be of great value to a community. The
French Quarter and Old Quarter areas of Hanoi are definitely prized for their unique character,
but other historic areas of the city might just be waiting for their time to be rediscovered. And
this is the important role that cultural heritage inventories have to play. They have the power to
alert policy makers, community members, and visitors to the presence of other lesser-known
places that can contribute to the economic livelihood, environmental quality, and overall
experience of a city.

98
REFERENCES

Council of Europe. 1985. Convention for the Protection of the Architectural Heritage of Europe.
http://conventions.coe.int/Treaty/en/Treaties/Html/121.htm

Council of Europe. 2012. Guidelines on Cultural Heritage: Technical Tools for Heritage
Conservation and Management. Strasburg: Council of Europe. September.

Girard, Greg. 2007. Phantom Shanghai. Toronto: The Magenta Foundation.

Gonzales, Hector, Halevy, Alon Y., Jensen, Christian S., Langen, Anno, Madhaven, Jayant,
Shapley, Rebecca, Shen, Warren, Goldberg-Kidon, Jonathan. 2010. “Google Fusion
Tables: Web-Centered Data Management and Collaboration.” Proceedings of the ACM
SIGMOD conference. http://www.cs.washington.edu/homes/alon/files/sigmod10.pdf

Grayson, Gillian, Janet Hansen, Daniele Pini, David Myers, and Jeffrey Levin. 2013. “Taking
Stock: A Discussion about Inventories and Heritage Decision Making.” Conservation
Perspectives: The GCI Newsletter. Volume 28. No. 2: 18-23.

Hanoi, Heritage and Identity. 2010. “Architectural heritage Inventory.” Accessed February 17,
2014. http://www.toulouse-hanoi.org/english/co-operation-initiatives/architectural-and-
urban-heritage/architectural-heritage-inventory.html

99
Hanoi 2010 Project. 2014. “The Old Quarter of Hanoi.” Accessed February 17, 2014.
http://www.hanoi2010.org/uk/pagesEditos.asp?IDPAGE=57&sX_Menu_selectedID=m1
_8D9EE853

Ipeirotis, Panagiotis G. 2010. “Analyzing the Amazon Mechanical Turk marketplace.” XRDS 17,
2 (December 2010), 16-21. http://doi.acm.org/10.1145/1869086.1869094

Kaiman, Jonathan. 2012. “Razing History: The Tragic Story of a Beijing Neighborhood’s
Destruction.” The Atlantic. February 9.
http://www.theatlantic.com/international/archive/2012/02/razing-history-the-tragic-story-
of-a-beijing-neighborhoods-destruction/252760/.

Logan, David, and Richard Mackay. 2013. “Inventories and Heritage Management: The
Australian Experience.” Conservation Perspectives: The GCI Newsletter. Volume 28.
No. 2: 10-12.

McCarthy, Deirdre. 2013. “Facing Disaster: The Importance of Heritage Inventories in
Preparation and Response.” Conservation Perspectives: The GCI Newsletter. Volume 28.
No. 2: 16-17.

Merriam-Webster.com. “Inventory.” Accessed August 6, 2015. http://www.merriam-
webster.com/dictionary/inventory

100
Morville, Peter. 2004. “User Experience Design.” Accessed June 3, 2015.
http://semanticstudios.com/user_experience_design/

Myers, David, Yiannis Avramides, and Alison Dalgity. 2013. “Changing the Heritage Inventory
Paradigm.” Conservation Perspectives: The GCI Newsletter. 28 (2): 4-9.

National Park Service. 2002. National Register Bulletin 15. Washington, DC: National Register
Publications. Accessed February 8, 2014.
http://www.cr.nps.gov/nr/publications/bulletins/nrb15/nrb15_8.htm

Nguyen, Ngan. 2012. "How English Has Displaced Russian and Other Foreign Languages in
Vietnam Since 'Doi Moi.'" International Journal of Humanities and Social Science.
Volume 2. No. 23, 259-266.
http://www.ijhssnet.com/journals/Vol_2_No_23_December_2012/29.pdf

Nguyen Quang and Hans Detlef Kammeir. 1997. Case study: Conservation program for the
French colonial quarter in Hanoi. The Economics of Heritage: UNESCO Conference on
Adaptive Re-use of Historic Properties in Asia and the Pacific. Hanoi.

Oomen, Johan and Aroyo, Lora. 2011. “Crowdsourcing in the cultural heritage domain:
opportunities and challenges.” In Proceedings of the 5th International Conference on
Communities and Technologies (C&T '11). ACM, New York, NY, USA, 138-149.
http://doi.acm.org/10.1145/2103354.2103373

101

Sharp, Rob. 2008. “Heritage site in peril: Angkor Wat is falling down.” The Independent.com.
March 14. http://www.independent.co.uk/news/world/asia/heritage-site-in-peril-angkor-
wat-is-falling-down-795747.html

Shirk, Jennifer L., Heidi L. Ballard, Candie C. Wilderman, Tina Phillips, Andrea Wiggins,
Rebecca Jordan, Ellen McCallie, Matthew Minarchek, BruceV. Lewenstein, Marianne E.
Krasny, and Rick Bonney. 2012. “Public participation in scientific research: a framework
for deliberate design.” Ecology and Society 17(2): 29. http://dx.doi.org/10.5751/ES-
04705-170229

Shirky, Clay. 2010. Cognitive surplus: Creativity and generosity in a connected age. New York:
Penguin Press.

Thornes, Robin and John Bold. 1998. Documenting the Cultural Heritage. Los Angeles: J. Paul
Getty Trust.

Stokes, Connla. 2010. "Is Hanoi losing its Asian-ness?" CNN.com. November
25. http://travel.cnn.com/explorations/life/skys-limit-hanoi-077265

Stone, Peter. 2013. “War and Heritage: Using Inventories to Protect Cultural Property.”
Conservation Perspectives: The GCI Newsletter. Volume 28. No. 2: 13-15.

102
World Monuments Fund. 2015. “The Watch.” Accessed August 6, 2015.
http://www.wmf.org/watch/about-watch

Wright, Gwendolyn. 1991. The Politics of Design in French Colonial Urbanism. Chicago: The
University of Chicago Press.

103
APPENDIX A: HANOI INVENTORY

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152
APPENDIX B: ONLINE HERITAGE INVENTORIES
Name URL Description
Andorra Inventari
d'Patrimoni
http://www.cultura.ad/inventari/cercador-
inventari-patrimoni
A searchable inventory of cultural heritage in
Andorra. Each record includes a photo, key
information, and a narrative description.
Asian Historical
Architecture
http://www.orientalarchitecture.com/index.php A contributor-based site of photographs, maps,
and descriptions for more than 855 Asian historic
architectural resources distributed over 21
countries. Each record is represented differently
depending on the information contributed.
Australian Heritage
Database
http://www.environment.gov.au/cgi-
bin/ahdb/search.pl
Searchable inventory of heritage resources within
Australia that are on the National Heritage,
World Heritage, Commonwealth Heritage lists
and the Register of the National Estate. Each
record contains photos, and narratives regarding
history, significance, and description.
Australian Heritage Places
Inventory
http://www.heritage.gov.au/ahpi/index.html Searchable inventory of heritage resources within
Australia that are contributed by the
Commonwealth, State and Territory governments
via various registers and statutory lists. Each
record has a brief summary with significance,
description, and some basic information, with a
link to the source of the entry for more detailed
information.
AZSITE - Arizona's
Cultural Resource
Inventory
https://azsite3.asurite.ad.asu.edu/azsitepublic/p
rotected/Default.aspx
Public site for state cultural resource inventory
GIS. No locations are provided in the public site,
which only shows broad information layers, such
as resource sensitivity, which displays the extent
to which each 1 mile square grid area might have
cultural heritage restrictions. An application to
the State Historic Preservation Office is required
for more information.
CRGIS - Pennsylvania
Historical and Museum
Commission
http://www.portal.state.pa.us/portal/server.pt/c
ommunity/crgis/3802
A cultural resources GIS that generates a map of
cultural resources based on user inputs. First, the
user must conduct a text-based search to obtain a
key number for a property that the map will be
centered on. Then, the user can select the map
layers and areas of interest. After that, the map
can be generated. This site requires a login for
professional users who need access to sensitive
archaeological data, but the public can view all
non-sensitive historic resource information.

153
CyArk http://archive.cyark.org A searchable archive of heritage sites that have
been digitally documented via laser scanning,
photography, and GIS. The archive is relatively
small (under 100 sites), but searchable via
interactive map or by photo grid. Each record
contains access to 3D and 2D imagery, virtual
tours, narrative descriptions, and a project
specific GIS with interactive layers.
GIS-ZH - Canton of
Zurich GIS
http://maps.zh.ch/ The GIS for the Canton of Zurich, Switzerland.
This includes numerous layers, including a
heritage resource one, that enable spatially-based
information searches.
Guia Digital del
Patrimonio Cultural,
Instituto Andaluz del
Patrimonio Historico
http://www.iaph.es/web/canales/conoce-el-
patrimonio/guia-digital/buscador/
After selecting a province and city from a
dropdown list, users are directed to a page for
that area with a launcher for a GIS of the area.
The GIS contains all of the heritage resources in
the area, with narrative information and links to
photographs, panoramas, 3D imagery, videos and
other information (if available) housed in the
infowindow for each resource.
Inventaire du Patrimoine
Architectural, Region de
Bruxelles-Capitale
http://www.irismonument.be/index.php?lg=fr A searchable inventory of architectural cultural
heritage in Brussels, Belgium. Each record
contains images and narratives about each
resource.
Los Angeles Conservancy
- Historic Places
https://www.laconservancy.org/explore-
la/historic-places
An inventory of more than 400 historic places in
Los Angeles County that is searchable by a
filterable map. A summary of each record with
an image is available via map infowindow. The
full record contains a narrative description, key
information, photos, map location, related
information, and related locations.
National Inventory of
Architectural Heritage,
Ireland
http://webgis.buildingsofireland.ie/niahviewer/
index.html
An esri-powered GIS that enables the display and
search of surveyed buildings. Each record has a
photograph, some basic information, and a
description.
National Registry of
Historic Sites & Structures
in the Philippines
http://nhcphistoricsites.blogspot.com/ Photos and descriptive information of sites and
structures on the National Registry in blog
format, searchable by grouped category.
New South Wales
Heritage Inventory
http://www.environment.nsw.gov.au/heritagea
pp/heritagesearch.aspx
This searchable inventory contains records for
25,000 heritage items from different
agencies/governments within the Australian state
of New South Wales. It also features a map-
based search for items on the State Heritage
Register only. Each record features detailed
narratives and photos for each item.
SAHRIS - South African
Heritage Resource
Information System
http://www.sahra.org.za/allsitesfinder Searchable inventory of heritage sites, including
a map based search.

154
Saint Helena Historic
Environment Record
http://www.blackfreighter.net/sainther/ An searchable inventory of more than 1000 sites
and structures on the island of Saint Helena. The
search is via name, reference number or
significance grade or via the interactive map.
Each record contains basic information, historic
context and significance, condition, photographs
and drawings and possibilities for reuse.
UNESCO World Heritage
List
http://whc.unesco.org/en/list/ An interactive map and list of 981 heritage
resources that are UNESCO World Heritage-
listed. Each record includes photos, narrative
descriptions, key information, and map location.
US National Register of
Historic Places NPS
FOCUS
http://nrhp.focus.nps.gov/ A searchable inventory of heritage resources on
the National Register of Historic Places. It
features an advanced search on geographic
location, subject, name, keywords, and dates.
Each record contains information for the
searchable fields and links to downloadable
PDFs on the resource image and National
Register Nomination Form.
Victorian Heritage
Database
http://vhd.heritage.vic.gov.au/vhd/heritagevic A searchable inventory of Heritage Places and
Precincts within Victoria. Each record contains
statements of significance, physical descriptions,
historical information, builder, architectural
style, photographs and heritage overlay number.
A link to a window with Google Map and Street
View locations is also included.
WISAARD, Washington
Information System for
Archtiectural and
Arcaheological Records
Data
https://fortress.wa.gov/dahp/wisaard/ Architectural and archaeological cultural
resource GIS containing locations/records for
register and inventory properties.
ZIMAS - Zoning
Information and Map
Access System
http://zimas.lacity.org/ A GIS powered by the Planning Department of
the City of Los Angeles. It features parcel-based
information on jurisdictional, planning and
zoning areas, tax assessment, and seismic
hazards. It also provides basic information
indicated whether a parcel has a historic
designation or eligibility for designation attached
to it.
National Heritage List for
England
http://list.english-
heritage.org.uk/mapsearch.aspx
A searchable inventory of National Heritage
Listed buildings, via advanced search and map
search. Each record has some descriptive
information.
Texas Historic Sites Atlas http://atlas.thc.state.tx.us/index.asp An esri-powered GIS that displays historic
county courthouses, National Register
propertoes, State Antiquities Landmarks
(Buildings only), Historical Markers, cemeteries,
museums, military sites, sawmills, and
neighborhood surveys for the State of Texas.
Each record has a polygon or point map location
and one or more reports, each corresponding to a
designation or survey program.

Abstract (if available)

Abstract This thesis project consists of the development of a contributory web application to display and gather information on French Colonial era Art Deco architecture in Hanoi, Vietnam. The goal of this application is to create the foundation for a web-based spatial inventory of existing French Colonial era buildings. The inventory is meant to advise policymakers and heritage organizations on priority resources to protect the existing base of resources as well as to create a historic record of the historic urban landscape. This is important because the push to modernize infrastructure in emerging nations often leads to the destruction of the colonial heritage fabric in urban areas. An inventory of what currently exists, and possibly what existed in the past, will help to digitally record these sites, despite what occurred or may eventually occur in the physical places. Also as part of its purpose, the application seeks to engage the general public, including interested heritage professionals and scholars, by incorporating the ability to contribute information through the correction and enhancement of current entries. The web application will incorporate the minimum data standards for inventory of cultural heritage as specified in the Core Data Index to Historic Buildings and Monuments. The initial dataset for the application is based upon data collected during fieldwork in June 2012 and covers a self-defined area of the French Quarter district of Hanoi. As a secondary purpose, the web application was developed to be replicable by others who might choose to take and adapt the web application model for their own heritage conservation-related purposes. As such, the web application employs easy-to-use, relatively inexpensive, cloud-based tools and services, such CartoDB, MapBox, Persona, Heroku, Bitbucket, and various Google products. In order to use many of these services together, the web application was purpose-built using the well-documented and flexible Python web development framework, Pyramid, in conjunction with the templating system, Jinja2, along with the standard HTML, CSS, and JavaScript programming languages. After instructional documentation is written and further development occurs as specified in the application’s roadmap, the code, which is currently stored in a private repository on Bitbucket will be opened for download and collaboration by others wanting to use and improve the application model.

Linked assets

University of Southern California Dissertations and Theses

Conceptually similar

PDF

Cal ToxTrack: a full stack Web GIS for mapping pollution in California

PDF

Development of a Web GIS for urban sustainability indicators of Oakland, California

PDF

A unified geodatabase design for sinkhole inventories in the United States

PDF

Assessing the impact of a web-based GIS application to promote earthquake preparation on the University of Southern California University Park Campus

PDF

Web-based relational spatiotemporal geodatabase of glaciers in California

PDF

Generating trail conditions using user contributed data through a web application

PDF

Cartographic design and interaction: An integrated user-centered agile software development framework for Web GIS applications

PDF

Development of a Web GIS application to aid marathon runners in the race selection and planning process

PDF

GIS data curation and Web map application for La Brea Tar Pits fossil occurrences in Los Angeles, California

PDF

Recreational Off-road Adventure Motorcycle mapping System (ROAMS): a web application facilitating adventure motorcycling in Idaho public lands

PDF

Walkability study for school accessibility: case study of the San Juan, Puerto Rico elementary schools

PDF

Tracking Santa Barbara County wildfires: a web mapping application

PDF

A user study of GIS infused genealogy with dynamic thematic representation and spatiotemporal control

PDF

Light rail expansion in Houston using viable path corridors and least cost path: alternatives for the failed University and Uptown lines

PDF

Automating “Ethington Transections”: a new visualization tool

PDF

Finding the green in greenspace: an examination of geospatial measures of greenspace for use in exposure studies

PDF

Geospatial web application development to access irrigation asset data: Veterans Affairs Palo Alto Health Care System

PDF

Development of a historical urban land use web application for the city of Hong Kong

PDF

Trojan Food Finder: a web-based GIS campus food sharing application

PDF

Precipitation triggered landslide risk assessment and relative risk modeling using cached and real-time data

Asset Metadata

Creator Enriquez, Annabel Lee (author)

Core Title A contributory Web-based application for documenting historic resources: French colonial era art deco architecture in Hanoi

School College of Letters, Arts and Sciences

Degree Master of Science

Degree Program Geographic Information Science and Technology

Publication Date 09/17/2015

Defense Date 08/25/2015

Publisher University of Southern California (original), University of Southern California. Libraries (digital)

Tag art deco architecture,crowdsourcing,cultural heritage inventories,geographic information systems,Hanoi,Heritage Conservation,Historic buildings,OAI-PMH Harvest,Vietnam,Web development

Format application/pdf (imt)

Language English

Contributor Electronically uploaded by the author (provenance)

Advisor Wilson, John P. (committee chair), Swift, Jennifer (committee member), Vos, Robert (committee member)

Creator Email alenriqu@usc.edu,annabel.lee.enriquez@gmail.com

Permanent Link (DOI) https://doi.org/10.25549/usctheses-c40-183765

Unique identifier UC11276212

Identifier etd-EnriquezAn-3927.pdf (filename),usctheses-c40-183765 (legacy record id)

Legacy Identifier etd-EnriquezAn-3927.pdf

Dmrecord 183765

Document Type Thesis

Format application/pdf (imt)

Rights Enriquez, Annabel Lee

Type texts

Source University of Southern California (contributing entity), University of Southern California Dissertations and Theses (collection)

Access Conditions The author retains rights to his/her dissertation, thesis or other graduate work according to U.S. copyright law. Electronic access is being provided by the USC Libraries in agreement with the a...

Repository Name University of Southern California Digital Library

Repository Location USC Digital Library, University of Southern California, University Park Campus MC 2810, 3434 South Grand Avenue, 2nd Floor, Los Angeles, California 90089-2810, USA