Field Information Geospatial-database System (FIGS) for the United Nations Office for Coordination of Humanitarian Affairs (OCHA)

Proof of concept and state of the art in FOSS Geospatial Technology

Report by

Sean Ahearn, Ph.D., Hunter College - CUNY David Almeida, Hunter College CUNY Software Engineer, TTSI Mark Gahegan, Ph.D. Pennsylvania State University

To

Mr. Suha Ulgen

Technical Coordinator Field Information Support Project Office for the Coordination of Humanitarian Affairs One UN Plaza DC1-1368 New York, NY 10017

March 2006

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 1 Geospatial Technology 3/15/2006

Table of Contents Page number

Executive Summary 5 1.0 Introduction 7 2.0 Purpose of broader project 9 2.1 Phase 1: Proof of Concept and state of the art in FOSS Geospatial Technology 9 2.2 FIGS Development 9 2.3 Phase 3: FIGS Field Implementation 11 3.0 Background 11 4.0 Phase I: Proof of Concept and state of the 12 art in FOSS Geospatial Technology 4.1.1 Initial overview of the use of geospatial 12 technology for disaster relief management. 4.1.2 Introduction: Humanitarian Information Centers (HIC) 13 4.1.3 Tsunami (South-east Asia) 16 4.1.4 Earthquake (Pakistan-India) 17 4.2 Within the context of these emergencies, conduct a 20 preliminary data needs assessment and establish functionality requirements for geospatial query, analysis and cartographic output. 4.2.1 Current software systems used 21 4.2.2 Required functionality of Geospatial environment 21 4.2.3 Critical information needs 22 4.2.4 Operational conditions 24 4.3 Assemble, integrate and test Free Open Source Software 24 (FOSS) systems for storage, maintenance, access and analysis of geospatial information. 4.3.1 State of Geospatial FOSS (core substrates for geo-processing) 24

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 2 Geospatial Technology 3/15/2006

4.3.2 Set up test environment 43 4.3.3 Matrix of Interoperability among software components 46 4.3.4 Integrated stack evaluation 49 4.4 Identify and load a preliminary data set of global, 67 regional and local data into FIGS as part of testing. 4.5 Design FIGS for maximum interoperability with other 68 existing disaster management systems 4.5.1 Geo-Network 69 4.5.2 WDWW 69 4.6 Integration with existing or emerging data and software networks 70 4.6.1 GEON 70 4.6.2 GOOGLE 73 5.0 Conclusion and recommendations 75 6.0 References 78 Appendix A 79 Appendix B: Simple Database Load Script (DOS) 95 Appendix C: JUMP Evaluation: 96

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 3 Geospatial Technology 3/15/2006

List of Figures and Tables Page number

Figure 1: Lifecycle of a Humanitarian Information Centre: 14 from emergency to Reconstruction Table 1 Imagery and data available at time of deployment 22 Table 2 Relevant imagery and data obtained in the field 23 Figure 2 Portal and Web Services Implementation Overview showing the 29 various OGC web services. Table 3 Matrix of Interoperability 49 Figure 3 Thin Client Access 50 Figure 4: Map Builder thin client and GeoServer web services tier 51 Figure 5: Zoom in showing UN facilities using MapBuilder client 52 Figure 6 GOOGLE Earth Access 53 Figure 7 Google Earth client showing thin client and Geoserver 54 Figure 8 Google Earth client showing IDP camps, HIC hubs, UNJLC roads 55 and administrative boundaries . Figure 9 Thick Client Access 56 Figure 10: UDIG client with data obtained from PostgreSQL via GeoS 57 Figure 11 ArcMap client with data obtained from PostgreSQL via GeoServer 58 Table 4 Matrix of Functionality 67 Figure 6 GEON project architecture summary. 71

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 4 Geospatial Technology 3/15/2006

Field Information Geospatial-database System (FIGS) for the United Nations Office for Coordination of Humanitarian Affairs (OCHA):

Proof of concept and state of the art in FOSS Geospatial Technology

Executive Summary Geospatial technology is becoming a critical component in disaster planning, response, recovery and mitigation. This report focuses on the state of Free and Open Source Software (FOSS) for geospatial analysis, their level of maturity, completeness and necessary functionality for providing essential support for disaster management. The context for this analysis will be provided by reviewing how geospatial technologies have been used in two recent major disasters, the Tsunami in Southeast Asia and the earthquake in the Kashmir region of Pakistan and India.

As a proof of concept into the capabilities of emerging, open-source, open-standards GIS, a test environment was created which integrated several FOSS components in a multi-tier configuration we will call the FIGS stack . It is composed of three layers: the data tier, the web services tier and the client tier. The data tier is composed of PostgreSQL/PostGIS which forms the heart of the GeoSpatial system. It is the most mature open source object/relational solution available for DBMS and is based on the OGC simple feature specification, which is a non-topological data model. The GiST Spatial indices within PostGIS provide for high-performance spatial indexing as was evident in the ease with which the system handled a 1.2 million polygon data set for New York City. GeoServer 1.3.0-PR1 was the implementation base for the web tier of the FIGS stack. It was chosen because it implements both the WFS/WFS-T and WMS functionality. Our testing showed GeoServer to be quite stable. GeoServer also supports FIGS Working Group Document: Proof of Concept and state of the art in FOSS 5 Geospatial Technology 3/15/2006

a cache of on-board styles to be used with its WMS. A number of SLDs (Styled Layer Description documents) were developed to correspond to UN/OCHA symbology and were illustrated in the FIGS video demo (attached). Both thick and thin clients were implemented in the client tier. A Mozilla Firefox Browser was used to drive a GOOGLE Earth application which tapped into the PostgreSQLql/Post GIS data tier via GeoServer WMS and returned KML via the GeoServer in a combined thin/thick implementation. MapBuilder (thin client), an open-source AJAX-like toolkit, was implemented and tested. Several thick clients, uDig 1.06 and 1.1.1, JUMP, ArcGIS and Quantum GIS were also integrated into the FIGs stack as part of the client tier. The client tier was perhaps the least mature component of the FIGs stack and lacked in sophisticated cartographic, analytic and data management capabilities. The exception was the ArcGIS platform, which is not FOSS, but was included because of its ubiquity.

The FIGS stack was tested using several data sets: a 1.2 million polygons tax lot file for New York City, a 200,000 polygons building file for Manhattan, VMAP0 data covering the world, VMAP1 data tiles 132 and 131, covering Pakistan, selected Global Discovery data in OCHA s standard directory format, and Pakistan HIC Data provided by OCHA (shapefiles).

The FOSS Geospatial Technologies show real promise, with a solid foundation in the data tier with PostgreSQL/PostGIS, a very impressive web services tier founded on the GeoServer 1.3.0-PR1 technology and a number of interesting options for the client tier. The FIGS stack, in its entirety, is not yet at the stage where it can offer a comprehensive environment for HIC applications that was not the intention of this pilot study. However the data tier and web services tier as implemented here could form the basis of a more comprehensive system. The client tiers are actively being developed by many groups also interested in open-source GIS, and the input of OCHA could very well drive this development effort.

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 6 Geospatial Technology 3/15/2006

1.0 Introduction

Document s Focus The discussion and analysis that follows will be centered on the integration of a Free and Open Source Software (FOSS) software stack for geo-spatial technology (excluding remote sensing) that can be used for disaster management. Its level of maturity, completeness and necessary functionality for providing essential support for disaster management will be examined in a pilot study that integrates a multi-tier stack of FOSS geospatial technologies. Technology, however, cannot be analyzed without regard for the structure and needs of the operational environment in which it is deployed. Therefore, we will first review how geospatial technologies have been used operationally for disaster management by OCHA in two instances, the Tsunami in Southeast Asia (December 26, 2004) and the earthquake in Pakistan (October 8, 2005).

Role of Geospatial technology in disaster management The role of Geospatial technology (instruments, data, information and systems) is increasingly becoming a key component of disaster planning, response and recovery (Cutter et al., 2003). In emergencies, accurate and timely information is essential for saving lives in the initial response to a disaster and to insure a rapid recovery in the restoration and reconstruction phase (GDIN, 1997). Data associated with disasters is inherently spatial (Goodchild, 2003) and geospatial technology has been shown to be central to the integration, analysis, visualization, knowledge generation and communication during an emergency (Leidner, 2005). Due to its complexity, the effective use of geospatial technology for disaster management can fall short of its potential for a number of reasons. These include: (i) a lack of suitable software in place, (ii) a lack of understanding of the technology by responders, (iii) a disconnect between the producers of geospatial data and the consumers of it, (Zerger and Smith, 2003), (iv) poor integration of the information gleaned from this technology into the decision making process (van Borkulo et al., 2005) and (v) the existence of data gaps, scale inconsistencies, data currency (Leidner, 2005) and lack of meta-data.

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 7 Geospatial Technology 3/15/2006

General issues associated with the use of Geospatial Technologies for disaster events are: Selection of the most appropriate geographic unit of analysis (scale) for the different problems associated with the disaster; Overcoming the barriers to greater cooperation and data sharing among the stakeholders; Effective integration of the Geographic Information Systems (GIS) and related components and data into the Management Information System (MIS) framework; Adherence to data exchange standards and the importance of meta-data; The use of cartographic standards for information presentation; The selection, deployment and integration of remote sensing technologies; Fusion of remotely sensed data types into a single geographic framework; Effective dissemination of geospatial information, via the Internet and other means; both to planners and back out into the field to enhance situational awareness.

Decision making in a crisis environment The operational environment and resultant decision making in a crisis is fundamentally different from decision making in most other instances. Crisis response has several unique characteristics (van Borkulo et al., 2005): There is a complex brew of many actors from different disciplines that all need to coordinate; These actors are under extreme stress; Uncertainty in the information associated with the crisis leads to intuitive decisions being made in an ad-hoc fashion; External pressures from politics and the media warp the process; Evaluation of the process of decision making is done de pos facto.

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 8 Geospatial Technology 3/15/2006

A typology of decision proposed by Snowden (2002), characterized the decision space as comprising information that is: (i) known, (ii) knowable, (iii) complex and (iv) chaotic. In the first two spaces, known and knowable, predictions are possible, in the second two, the inherent uncertainty in models and systems may dominate the decision-making process. Emergencies can operate in any of these four spaces and evolve from one to the other. In emergencies, the situation tends to evolve towards the complex space (French and Niculae, 2005). The broader framework for discussion is: How does the integration of the geospatial technologies affect the space in which decision are made? In effect, does it reduce the complexity of the problems confronted in emergency situations and result in the provision of better humanitarian services to the effected populations? To answer this question effectively, we must first understand how GIS technology can support disaster situations, with the relevant question here being: What are the essential data needs and geospatial functionality required for disaster management and what are the barriers to their discovery and adoptation?

2.0 Purpose of broader project The overall purpose of this project is to develop a Field Information Geospatial System (FIGS) for disaster relief management. The project will have several phases.

2.1 Phase 1: Proof of Concept and state of the art in FOSS Geospatial Technology (November 15, 2005 March 3, 2006): 2.1.1 Initial overview of the use of geospatial technology for disaster relief management (e.g. terrorism, tsunami, earthquake, slow-onset disasters and hurricane). 2.1.2 Within the context of these emergencies, conduct a preliminary data needs assessment and establish functionality requirements for geospatial query, analysis and cartographic output. 2.1.3 Assemble, integrate and test Free Open Source Software (FOSS) systems and components for storage, maintenance, access and analysis of geospatial information,

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 9 Geospatial Technology 3/15/2006

2.1.4 Identify and load a preliminary data set of global, regional and local data into FIGS as part of testing. 2.1.5 Design FIGS for maximum interoperability into the future, and with other existing disaster management systems (i.e. Geo-Network, WDWW, GDACS, FTS, etc.).

2.2 Phase 2: FIGS Development (TBD) 2.2.1 Explore solutions for identified limitation of alpha FIGS. a. Stability b. FIGS maintenance c. Interoperability limitations d. Ease of input/output e. Data maintenance f. Spatial-temporal data management g. Applications and supported functionality h. Other 2.2.2 Development / acquisition of required end-user functionality 2.2.3 FIGS developer and user documentation. 2.2.4 Configuration management 2.2.5 Implement the disaster management data model. a. Integrate into geo-spatial database b. Examine data sources in relation to model c. Analyze completeness of the data model. d. Iterate and refine data model. 2.2.6 Continuation of FIGS development a. Version management b. Spatial temporal analysis c. Visualization 2.2.7 User acceptance testing 2.2.8 Iteration of development.

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 10 Geospatial Technology 3/15/2006

2.3 Phase 3: FIGS Field Implementation (TBD) 2.3.1 Software roll-out a. Support documentation b. Hardware configuration 2.3.2 Training 2.3.3 Monitoring and performance 2.3.4 Support (i.e. patches, bug fixes, critical updates). 2.3.5 Development of global network of data nodes. 2.3.6 Hosting of data and software 2.3.7 Training 2.3.8 Regional/local database development

In this report, we detail our responses to the first phase of the project, as described above in Section 2.1.

3.0 Background

The Field Information Support (FIS) Project is responsible for advising for the Office for the Coordination of Humanitarian Affairs (OCHA) information management (IM) strategy in the field. The project supports field offices by developing tools and services and providing technical support. Additionally, the Inter-Agency Standing Committee has endorsed OCHA as the steward of Humanitarian Information Centers (HIC), a common service provided to the humanitarian community during an emergency. HICs are service orientated, working to support coordination through the provision of information products and services, and contribute to the creation of a common framework for information management within the humanitarian community.

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 11 Geospatial Technology 3/15/2006

The FIS group is implementing a Field Information Management Strategy (FIMS) to develop a minimum standard IM capacity, products and services in selected OCHA field offices. These IM systems include: i. A Who, What, Where directory system. ii. A contacts management system. iii. A content management system (aka Web template). iv. A document sharing, cataloguing and archiving system. v. An e-mail and field connectivity solution. vi. A geospatial database and data preparedness facility.

The development of FIGS (Field Information Geospatial database System) is in support of the Open Spatial Information Management Infrastructure, as proposed by Suha Ulgen (the Technical Coordinator of the Field Information Support Project). It will provide a geospatial framework for information collection, coordination, management and analysis at HQ, in OCHA field offices and at HICs. This will increase efficiency and effectiveness in the field, facilitate more effective response to Humanitarian Crises, and create a critical tool for managers and decision makers.

4.0 Phase I: Proof of Concept and state of the art in FOSS Geospatial Technology

4.1.1 Initial overview of the use of geospatial technology for disaster relief management. This section is meant to provide an overview of the use of geospatial technology for disaster relief management. It is based on a subset of documents that this team received concerning HICs and their implementation in different situations and locations. It is not a comprehensive review and analysis but is intended to provide a context for how geo- spatial technologies are used for disaster relief and some of the issues that surfaced during the life of the HICs. FIGS Working Group Document: Proof of Concept and state of the art in FOSS 12 Geospatial Technology 3/15/2006

4.1.2 Introduction: Humanitarian Information Centers (HIC) Humanitarian missions are characterized by an intense, chaotic, fast-changing environment, in which multiple players converge on a given geographic region in response to a natural or human-induced disaster. These disasters are of such a magnitude that they results in the loss or disruption of lives, shelter, and the physical, social and political infrastructure of the region. In this highly charged atmosphere, geo-spatial information is critical to understanding the nature, extent and dynamics of the disaster. Different disasters have differing characteristics but they have fundamental similarities in that they all require data collection, management, analysis and reporting instruments for the logistics, assessment, response, and recovery efforts associated with the crisis. Some of the questions that need to be answered are1: 1. How many people are affected and what are their needs? 2. Where are the affected areas and affected population located? 3. What is the extent of the damage and needs? 4. Who is providing assistance and where are they working? 5. What factors affect security and access of emergency workers to the affected population?

Having a single Center for information management, whether physical or virtual, is vital to fostering a coordinated response to humanitarian disasters among the various players who are all involved in these efforts. The Center acts as a focal point for establishing a set of data standards and providing all the players with the collective knowledge concerning the status of the operations a common operating picture. This reduces redundancy, increases efficiencies and leads to more informed decision making by all. It is essential to establishing a closed loop between information gathering in the field, its synthesis in the office and its dissemination back out into the field. To ensure consistency among the different agencies and organizations collecting information in the

1 Structured Humanitarian Assistance Reporting (SHARE) By Dennis King http://www.reliefweb.int/symposium/SHAREarticle.htm: direct quote. FIGS Working Group Document: Proof of Concept and state of the art in FOSS 13 Geospatial Technology 3/15/2006

field, a clear set of standards and data schema need to be put forth. A general framework for these standards is the Structured Humanitarian Assistance Reporting (SHARE)2 which suggests that information collected should include: a. Geo-referencing of the data, either point, line or area. b. Time-stamp indicating when data is collected and frequency of collection. c. Metadata or information about the data such as who collected the data, when it was collected what standards were used and how data was measured or derived.

Evolution of HIC The need for a centralized facility for information management was recognized during the Kosovo crisis in 1999 where the first Humanitarian Information Center (HIC) was established. Its creation was driven by the need to ensure access to reliable and timely data in the field through data sharing and through the establishment of standards for data collection, management, and maintenance. As HICs matured, their function expanded to include the creation of a Who does What, Where (WWW) database and an increase in the use of geospatial technologies (i.e. remote sensing and Geographic Information Systems) to better coordinate humanitarian response among relief organizations. Remote sensing technologies are critical for obtaining a synoptic view of the disaster and in obtaining an understanding of what has been damaged as a result of the event. These technologies can also be used to monitor progress during the recovery and re- development process. Geographic Information Systems (GIS) provide the relief effort with a geographic framework in which to visualize, analyze, and document the status of various aspects of the crisis. GIS is also used as a decision support tool to guide the organizational efforts in the office and activities in the field.

2 Structured Humanitarian Assistance Reporting (SHARE) By Dennis King http://www.reliefweb.int/symposium/SHAREarticle.htm FIGS Working Group Document: Proof of Concept and state of the art in FOSS 14 Geospatial Technology 3/15/2006

Life Cycle The transition in a emergency from response and recovery, to long-term development corresponds to the morphing of the HIC from a center of quick response, high impact, data integration and decision support into an information center for planning and development3. It s dynamic and reactionary mode in the first 2 months of operation changes into one that focuses on creating a common strategy for long-term development. As depicted in Figure 14 the HIC is often transferred over to the government of the given country in the final stage and can have a very positive affect on development and organization of the countries IT infrastructure.5

Figure 1: Lifecycle of a Humanitarian Information Centre from emergency to Reconstruction6

Crisis Interim Transition Normal - HIC established. Transition - consider Development - CAP preparation - Begin possible - HIC capacity and including early development of processes of HIC infrastructure recovery medium/long- migration ideally migrated - UNDP participates term recovery - Use HIC to to government in HIC steering programming. support structure. committee - Preliminary PCNA/Transition - adequate capacity - Consider early evaluation of al Recovery created to assist recovery elements how HIC Matrix Processes. government in and how HIC can capacity and - Ongoing implementing long- assist in developing infrastructure can participation in term development early recovery be migrated to HIC steering strategies including programs. ensure long-term committee for through - Consider sustainability medium/long CCA/UNDAF integrating UNDP - participation in term recovery process staff into the HIC HIC steering programming - Ongoing HIC committee - Consider steering committee assuming participation oversight of the HIC

3 Joe Crowley, David Saunders: Afghanistan Information Management Service; Digitizing, Data and Development What Follows a Humanitarian Information Center.doc 4 Structured Humanitarian Assistance Reporting (SHARE) By Dennis King http://www.reliefweb.int/symposium/SHAREarticle.htm 5 Joe Crowley, David Saunders: Afghanistan Information Management Service; Digitizing, Data and Development What Follows a Humanitarian Information Center.doc 6 UNDP/BCPR-OCHA/FIS Technical Guidance Note:

Development and the Humanitarian Information Centre

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 15 Geospatial Technology 3/15/2006

There has been a series of recent humanitarian disasters which cover a significant range of possibilities, from natural disasters (e.g. SE Asia Tsunami and the Pakistani earthquake) to politically induced disasters (e.g. Sierra Leon, and Afghanistan) in which the commonalities between, and comparative effectiveness of the Humanitarian Information Systems set up in response to these crises can be examined. The following is a summary of reports from the field on the successes and difficulties encountered in the set-up, execution and transition of HICs for different disasters and in different conditions.

4.1.3 Tsunami (South-east Asia) The HIC in Sumatra focused on developing standardized assessment forms, a WWW data base, products summarizing and mapping demographics, and in networking with sector groups, NGOs and local government in the first weeks of the crisis7.

The standard assessment form developed by the HIC in Banda Aceh, was not used by the various organizations working in Aceh. Given the problems with enforcing a standard data collection form, it was suggested that at least the geographic unit of collection and analysis should be standardized. Connectivity in the early stages was a problem with no LAN (wireless) or internet connectivity established.

The second phase saw the installation of kit hardware which resulted in a secure (trailer) environment for a server-based computation environment and proved to be a very significant enhancement to operations.

The third phase was marked by a shift of focus to long-term reconstruction and re- habilitation8. Transitions between the waves of personnel working at the HIC tended to be problematic with a need for greater overlap. Handover to the appropriate government body became another issue of concern.

7 OCHCA HIC Sumatra-Tsunami Crisis Response Andrew Alspach, 07 Jan 03 Mar 2005. 8 OCHCA HIC Sumatra-Tsunami Crisis Response Andrew Alspach, 07 Jan 03 Mar 2005. FIGS Working Group Document: Proof of Concept and state of the art in FOSS 16 Geospatial Technology 3/15/2006

General crosscutting issues were: geographic unit standardization with a suggestion of using a block level 9 scale geography, how to resolve the problem of enforcing use of a standardized forms for rapid assessment, how best to use raster data with a suggestion that raster processing is best off-site, and the problem of getting personnel on short notice for remote assignments.

4.1.4 Earthquake (Pakistan-India) The strategy and deployment plan for the HIC in Pakistan-India10 laid out the goals and objectives for deployment. It included establishment of a data survey of existing information and potential data gaps, primary data acquisition (e.g. land cover, land use, urban plans, administrative divisions, demographic information, population movements, health and education facilities), creation of a contact information directory, development of a WWW database to track the humanitarian groups and their areas of operation, and a web-based portal for information input and dissemination.

A review of the Pakistan HIC pointed out a number of shortcomings of this deployment.11 The report analyzed the strategic level problems of the HIC. These problems included: a lack of analysis of information produced by the HIC for utilization in operational and strategic decision making; a need for clearly defining the HIC role in assisting the wider humanitarian community, managing their expectations and making them understand their obligations; and the need for OCHA to take ownership of the cluster approach in order to foster the cooperation and coordination of the information management (IM) role of HICs. The report describes findings on the Pakistan Deployment of the HIC; the HIC concept and its perception by the greater humanitarian community; and the need for humanitarian agencies to give greater priority to information management. While some technological limitations were cited in the report,

9 This is a level used by the US Census Bureau that defines blocks as being surrounded by roads. 10 Humanitarian Information Centre Pakistan: strategy and deployment Plan (HIC Pakistan Concept Note 10 Oct 05.doc) 11 Humanitarian Information Center in Pakistan, Joint Review Mission Report February 06. FIGS Working Group Document: Proof of Concept and state of the art in FOSS 17 Geospatial Technology 3/15/2006

the structure and context for the deployment of information technologies was cited as a prime factor in the inability to achieve greater success for the HIC.

In addition to the Joint Review Mission Report, there are three accounts from the field that describe some of the issues confronted by several IT professionals from the OCHA.12 13 14 These accounts highlight the general lack of support for IM in many UN agencies, and the difficulty of making different agencies associated with the cluster groups15, NGOs and government groups adhere to common assessment tools, common platforms and the principle of data sharing.16 Some of the reasons for these problems are illuminated by a report which surveys the responsible individuals in each of the cluster groups.17 General issues associated with hand-off between the first wave of IT professionals and subsequent waves were: insufficient overlap between departing and arriving IT experts, a lack of meta-data and documentation of processes that could be transferred between them, and loss of key contacts and forgotten commitments made to partner agencies and local governments.

The deployments of the HIC module ( HIC in a box ) was seen as a very significant improvement over past operations which required sourcing of equipment and enable the HIC to ramp up very quickly. Some gaps in equipment were the lack of a large format scanner and color laser printers (A3 size), and the need for more reliable laptops.

Geographic data standards were a particularly acute problem. There was no geography and population figures below third level administrative (Tehsil) boundaries, which prooved too coarse a unit for the specificity required in the relief effort. There were at least 3 additional levels below this that were either not in digital form or not released by

12 Craig Williams: Observations on IM Tools used in the Southeast Asian Earthquake 13 Philip Chinnici: Observations on Humanitarian Information Centres IM and GIS operations in the Southeast Asian Earthquake

14 Akiko s mission report in Manshera 15 e.g. UNHCR shelter, WFP nutrition, WHO health and UNICEF water and sanitation. 16 Craig Williams: Observations on IM Tools used in the Southeast Asian Earthquake 17 Akiko s mission report in Manshera FIGS Working Group Document: Proof of Concept and state of the art in FOSS 18 Geospatial Technology 3/15/2006

the Pakistani government. As a result, organizations developed inconsistent geographies that added further to the divergence among different organizational information systems. The other problem was the lack of consistent place naming and the need for p-codes18 which seems to be a common problem. A proposed solution to the lack of sufficiently fine scale administrative geographies was to create a 2.5 or 5km grid as a standard for data collection19.

Rapid Village Assessment (RPA) is a tool to collect information on the conditions of populations and structures within areas affected by the earthquake. This would appear to be an opportunity to establish a standard assessment tool but proved to be an elusive goal in the Pakistan relief efforts. A number of organizations created their own assessment tools resulting in no single comprehensive evaluation of village/population status for the effected areas20.

The W3 database suffered from the coarse geography of the Tehsil (administrative level 3). Another problem was the difficulty at the central office of updating information obtained in the field due to the lack of experience with the Access DBMS. Later migration of the database to a web format using MySQL and PHP (a web scripting language) proved to be a more effective means of data input and update between the field and central office. There were also issues associated with report generation from the DBMS.

In a report chronicling the interview of personnel from various cluster groups during HIC operations in Pakistan, a number key issues emerged related to information flow, cartographic output, interaction with local resources and understanding of geospatial data21. Two way information flow between regional offices and the central office

18 Craig Williams: Observations on IM Tools used in the Southeast Asian Earthquake 19 Philip Chinnici: Observations on Humanitarian Information Centres IM and GIS operations in the Southeast Asian Earthquake

20 Craig Williams: Observations on IM Tools used in the Southeast Asian Earthquake 21 Akiko s mission report in Manshera meetings from 24 to 26 November 2005 FIGS Working Group Document: Proof of Concept and state of the art in FOSS 19 Geospatial Technology 3/15/2006

(Islamabad) appeared to be a problem as was the flow between the field and the regional offices and back out to the fields. In fact the lack of participation in the RVA (i.e. they gave up filling out the forms ) may have been the result of the field surveyors not getting any product associated with the data that they collected, from the regional office. Cartographically, the general feeling was that there was a lack of consistency in terms of scale, colors, and symbology and a feeling that the maps lacked clarity.22 There was a general consensus that the scale of the maps being used was not fine enough; the preference was for union council or village/settlement level geographies. Confusion concerning the meaning of p-codes was pervasive with some lacking any understanding of what they are and others confusing them with GPS points.

The use of remote sensing technologies appeared to be limited and suffered from a major void in analytical processes. 23 An urgent need to evaluate the role that remote sensing technologies can play in a disaster event with respect to OCHA HIC operations was expressed. Much of its current use seems to be as a backdrop for vector overlays, although other organizations seem to have made greater use of these technologies (e.g. UNHCR, UNHAS, UNJLC) 24.

4.2 Within the context of these emergencies, conduct a preliminary data needs assessment and establish functionality requirements for geospatial query, analysis and cartographic output.

Section 4.2 could not be addressed in a comprehensive manner due to the lack of information associated with these issues. To address the dearth of information on data needs and geospatial functionality requirements at HICs a straw man survey was

22 Akiko s mission report in Manshera meetings from 24 to 26 November 2005 23 Philip Chinnici: Observations on Humanitarian Information Centres IM and GIS operations in the Southeast Asian Earthquake

24 Philip Chinnici: Observations on Humanitarian Information Centres IM and GIS operations in the Southeast Asian Earthquake

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 20 Geospatial Technology 3/15/2006

developed. The survey questions (including enhancements, additions and modifications from OCHA) and some initial critique from the UN GIS community are given in Appendix A. This survey will need to go through several iterations and testing before it can be deployed in earnest but it provides a valuable first step in determining software systems currently in use, geospatial functionality requirements and data needs; for the HIC disaster management. Below is a preliminary discussion of the data needs assessment and functionality requirements for geospatial query, analysis and cartographic output based on a number of OCHA reports from the field.

4.2.1 Current software systems used

The primary platform for geo-spatial analysis used at most HICs is ArcGIS. Many of the operation appear to rely on a personal database (Microsoft Access) which limits functionality. Shape files are the primary form for much of the data including for data sharing. Shape files are non-topological, so errors in geometry can proliferate in such environments. There are many copies of ArcView 3.x that seem to be in circulation and are heavily relied on for many basic GIS functions.

Databases used in the office and field have included Access, MySql and MS-Sequel Server. A standard has yet to have been established as well as could be fathomed. None of these systems are available without payment, and they typically require Microsoft Windows (also not free) as their operating system.

4.2.2 Required functionality of Geospatial environment

Very few of the field reports discuss the geospatial functionality that is required in the HIC environment. Key functions appear to be quality cartographic output and geospatial data management. Maps are still critical tools for communications.

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 21 Geospatial Technology 3/15/2006

4.2.3 Critical information needs

Key geospatial data sets for disaster response are fine-scale administrative boundaries and consistent places locations with population figures. 25 Meta-data is an essential, but sometimes overlooked, component of geospatial data. Tables 1 and 2 below lists critical information needs for disaster management.

Scale/Spatia Type Source Use Comments l resolution Unknown Outdated boundaries, poor UNHC Level 3 admin. (probably None georeferencing/poor R 1:1M) geometry. Admin. Boundaries Unknown Found Outdated boundaries, poor Only used in products printed in Level 3 admin. (probably on georeferencing/poor New York 1:1M) internet geometry. Still the best settlement layer after over a month since Global deployment. However: Still used in several products Settlements Major settlements 1:1M Discov location error can be greater (03/02) ery than 10 km, mountain names B or landmark names are found a among settlements names. s Global e Still used in several products Major airports 1:1M Discov (03/02) ery m a Global Still in use (03/02) although other p Transportation Road network 1:1M Discov sources are available for Aceh and ery Northern Sumatra Global Still used in several products Railroad network 1:1M Discov (03/02) ery Global Hydrology Lakes 1:1M Discov Still in use as of 03/02 ery Used in all map products that Terrain DEM 90 m NASA display topography T Ciensin Never used h 1 Km ORNL Never used e The government publishes m Population Population admin. level 5 census data a estimates 5 Km UNEP Never used (2003) t i c

25 Philip Chinnici: Note for the File: Observations on Humanitarian Information Centres IM and GIS operations in the Southeast Asian Earthquake

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 22 Geospatial Technology 3/15/2006

T Cover limited Banda Aceh Eastvie Used in products printed in the first o 1:50K and part of the West coast of w days after deployment p Aceh o s h Eastvie e 1:250K Not used w e t s I UO Only used products for printed in Cloud cover (Meulaboh m Landsat 30 m Maryla New York in cloud) a nd g Space Free tiles: small area, not e Hi-Res Ikonos 2 m Imagin None georeferenced, high r g compression. y Table 1 - Imagery and data available at time of deployment.

Scale/Spatial Type Source Use Comments resolution

Level 5 admin. Unknown (probably VAM All Aceh products Processing required Admin. (NAD) 1:250K) Boundaries Level 5 admin. Unknown Nat l Dev. Agency Northern Sumatra products Processing required (SUMUT) (probably 1:250K) Improved Major Georeferencing Base map Settlements Unknown NGA None settlements over NIMA gazetteer.

Transportation Road network Unknown Nat l Dev. Agency Not used yet Processing required

Hydrology Lakes Unknown Nat l Dev. Agency In use Processing required Roads & Bridges UNJLC In use No topology, an Derived from Damaged & Roads & Bridges UNOSAT None arbitrary choice of Thematic 1:50K toposheets Destroyed roads were digitized Derived from Affected areas USGS In use Landsat Used in updating National VAM and other 1:50K settlement Aceh province cover mapping agency sources information Toposheet s 1:100K US Army Never used Aceh province cover Banda Aceh city 1:20K In use map Only used in 1 poster and SPOT 2.5 m ? to georeference city map Imagery Free tiles: small area Space Imaging, Ikonos, cover, not Hi-Res 2 m Digital Globe, None Quickbird georeferenced, high NUS compression. Table 2 Relevant imagery and data obtained in the field.26

26 FIS DATA AND IMAGERY ACQUISITION, Paolo Palmero, March 2005 modified from Michal Smolka.

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 23 Geospatial Technology 3/15/2006

4.2.4 Operational conditions

Key factors associated with the type of operational conditions are: power availability, access to the Internet, availability of computing resources, operating systems and their compatibility, and storage and backup of data.

4.3 Assemble, integrate and test Free Open Source Software (FOSS) systems for storage, maintenance, access and analysis of geospatial information.

This section begins with a description of what makes a computing system truly open , showing that it is more than free access to source code. Following from this description we discuss operating systems, geospatial information standards and finally review current systems and projects that might play a part in an emerging UN system for disaster management.

4.3.1 State of Geospatial FOSS (core substrates for geo-processing) Taking a cursory look at today s Geographical Information Systems, you could be forgiven for concluding that we already know everything about the world: data structures are fixed, methods can only be used with certain data structures, new methods can be difficult to add, and utilizing the functionality in external systems can be a challenging or even impossible task. In short, our current systems to support GIS activities are typically quite inflexible and closed ; it is almost as if they assume that the needs of the analyst are all known and are fixed. This is at odds with the notion of disaster relief, since by definition, a disaster is something which is usually unforeseen and not easy to plan for. The world remains an elusive open system and field personnel in disaster situations and researchers alike are engaged in the development of new techniques and associated tools in response to immediate need, which must be rapidly integrated with the old, and deployed into difficult settings.

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 24 Geospatial Technology 3/15/2006

Whereas substantial progress has already been made in the sharing of data (as exemplified by the Open Geospatial Consortium s recent standards, including WFS, GML and WMS), the effective interoperation of functionality (procedures, methods, components) is still a largely unresolved issue. To bring the point home, the GIScience, Geocomputation and Geoscience communities invest significant time and effort in the development of new methods to solve complex, emerging problems, but it is very rare that these methods can be shared effectively with other researchers or incorporated into foreign systems. Apart from being a terrible shame, this situation leads to a high level of redundancy because many methods end up being implemented repeatedly by different groups. In disaster situations the costs of failure to integrate may be much higher. Moving beyond the closed world, single system solutions that we are currently tied to is a big step, and involves a change of culture as well as the adoption of new computing technology and standards.

Open systems are clearly desirable here, in that any system designed for disaster response must be flexible, easily extendable and ideally impose as few barriers to uptake as possible (with cost being just one such barrier). But achieving true openness in computational systems involves more than just using software for which the source code is freely available. In fact open systems are less defined by the availability of code and more by the interfaces and standards used throughout the system by which it might be extended, or integrated with other components. So a GIS with source code available via an LGPL license, but using non-standard data formats and without a well-documented Application Programmer Interface (API) to support extensibility should be considered less open than a commercial product, where the code is unavailable, but all the interfaces and data formats used are well documented and follow established, community- developed standards. Cost of purchasing a system is a separate consideration, and should not be confused with openness .

Open systems can be thought of as involving three distinct qualities.

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 25 Geospatial Technology 3/15/2006

Open Source Code is freely available to all parties, or at least to all not-for-profit users Thousands of examples of open source projects can be found on SourceForge (www.sourceforge.net). Examples of software licenses pertaining to open source are GPL and LGPL. The main advantage that open source contributes is that the code is open to public scrutiny, so that at the very least details of the workings of interfaces and file formats can be gleaned from the code albeit with considerable effort:the details are not deliberately withheld.

Open Standards The use of well-documented, relevant and public standards should insure that the engineering difficulties in utilizing the software (e.g. customizing, integrating with other software or understanding data formats) are minimized Organizations such as the OGC, FGDC, and ISO develop public standards via a community process involving position papers, calls for comment, revisions, public meetings and fixing, followed by extensive documentation and compliance testing software.

Open Systems Truly open systems require both of the above but may go further in terms of actively minimizing the conceptual barriers and ontological commitments between components of the system especially those that potentially form the interface to other systems. Good logical design helps here, as does careful planning as to how third parties might wish to extend the software (i.e. designing for modification and extension). For example, the use of wrapper technology, as available in Java, can help repurpose generic software components to the specific needs of an application, yet without leading to a proliferation in versions of components, nor a strong a-priori commitment to a specific conceptual model.

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 26 Geospatial Technology 3/15/2006

With this general ethos in mind we review some of the geospatial standards, operating systems and available systems and applications that might form part of our development efforts.

a. Operating system issues While the Microsoft Windows operating system is ubiquitous throughout many organizations in the USA and Europe, it is less conspicuous in the developing nations. Windows is not free, neither does it always follow community standards for data or programming interfaces, preferring instead to rely on its market share to dictate standards. Obviously though, the majority of desktop applications are developed for this platform, including the leading GIS, ESRI s ARC-GIS.

By contrast, many systems designed to be truly open tend to avoid the Windows platform and are developed instead for the Linux platform (e.g. the GRASS GIS), since Linux itself is (largely) an open-source, community project.

The use of Java or similar programming languages circumvent many of the operating system issues; Java programs run on a virtual machine (an operating system dependent layer that provides a consistent environment for the Java language independent of the underlying hardware and operating system), hence the codebase is (usually) the same across all platforms. This condition is not always true for software that makes use of hardware capabilities (such as the Java3D libraries, originally developed for Linux and Windows from two entirely different codebases.

One significant problem that remains is that the development and deployment tools can differ significantly across platforms, particularly with older languages such as C and C++, where the compilation and include sequences can significantly complicate the problems of deploying systems across multiple, heterogeneous computing platforms.

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 27 Geospatial Technology 3/15/2006

b. OGC Open Geospatial Consortium (OGC) The Open Geospatial Consortium defines itself as a not-for-profit, international, voluntary consensus, standards organization and currently has over 260 members drawn from industry, government, and academia. The OGC s core mission is to deliver interface specifications for geospatial data and systems that are openly available for global use. In practice this means that the OGC guides the industry to develop agreed and public specifications for interfaces maximizing the possible interchange between different systems. Note that this follows the second and third qualities of open systems described above, not necessarily the first.

The OGC was founded in 1994 and has currently developed and delivered many complete interface specifications and is currently working on many others. These range from standards for cataloging of web services to the exchange formats for geospatial data. The OGC works closely with ISO (e.g. via TC 211 and 204), W3C and other standards organizations when appropriate. Currently, all the major GIS vendors are active in the various OGC initiatives and are pursuing the implementation of these standards within their products. Those vendors with most to gain from increased openness tend to be at the forefront of efforts to embrace the standards. OGC technology supports a number of different mapping services, based on the OGC Reference Model, itself, derived from the Reference Model for Open Distributed Processing (RM-ODP, ISO/IEC 10746), a widely used methodology for architecting open, distributed processing systems. Portal-based, and Browser-based clients are supported by several web mapping technologies, including standards for maps, map content, imagery and associated cataloging services. Figure 2 gives an overview of how these various web mapping pieces fit together.

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 28 Geospatial Technology 3/15/2006

Service Implementation Via A Portal Web Browser (Thin Client) Applications (Thick Client)

Internet

Web Feature Service Web Map Service Web Coverage Service Catalog Service @portal User Community host site

WFS WFS WMS WCS Cat Clients

(gazetteer) Internet

Services

Data Provider Organizations Figure 2 Portal and Web Services Implementation Overview showing the various OGC web services. Diagram taken from the OGC_Introduction document available from: www.opengis.org

Four of the most relevant OGC standards are described in the following sections.

1. Simple Feature Specification (SFS) The OGC s first contribution to geospatial interoperability was in the pioneering of open interchange formats for geospatial data. The abstract specification this interchange format takes is known as the Simple Feature Model (or more usually now simply the Feature Model) and forms part of the OGC s Information Architecture specification, as opposed to the Services Architecture, of which WMS and WFS (described above) are components. The Feature Model specification is now in its second major version, and provides geospatial representation capabilities that can embrace almost all current GIS proprietary formats, hence when concretized in an implementation is an ideal interchange format. An its name suggests, it addresses geographic map features, and not imagery (which is tackled in other OGC initiatives and also by GeoTIFF described below). A significant limitation of the Simple Feature Specification is that the model lacks

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 29 Geospatial Technology 3/15/2006

topology. This is a significant limitation and impacts the ability to create valid networks and polygon coverages and to conduct certain types of geospatial analysis. The OGC specification for a Topological Feature Specification is yet to be finalized.

2. Styled Layer Descriptor (SLD) The Styled Layer Descriptor is a specification for controlling the cartographic appearance of map features. This specification is important because it allows the appearance of a map to be shared, along with (but separate from) the actual data. Hence, it is possible to define and share a common operating picture to all parties involved in an initiative. Each person and organization will see the same data, displayed in exactly the same way, even if using different map rendering engines (such as ARC-IMS and GeoServer, which both support SLD).

SLD can control any aspect of a maps appearance, from the colors used to render a polygon, to the thickness of a hatching line or the orientation of a symbol. SLD, like many other spatial standards, is a dialect of XML that contains a set of Rule clauses. Each Rule is comprised of a Filter that specifies which map elements are to be assigned certain visual characteristics, and a set of Symbolizers that actually define the visual characteristics to all elements selected by the Filter. SLD files can be sent to an OGC- compliant Web Mapping Service such as GeoServer. In the absence of query languages to interact with data provided by Web Mapping Services, SLD is becoming somewhat of a default query language, since by using it, map features can be filtered out (given an invisible appearance).

SLD is not without limitations. For example, the OGC-SLD spec section 14.2 (MIL- 2525B) is not supported. SLD is also somewhat cumbersome to write and would benefit from SLD editors. An open Java implementation of a visual SLD editor and legend is available from the GeoVISTA Studio development team (www.geovistastudio.psu.edu).

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 30 Geospatial Technology 3/15/2006

3. Web Mapping Service (WMS) A Web Mapping Service, as defined by the OGC, is a web application that serves maps (or more realistically pictures of maps) to web clients (and browsers). The actual map features contained within the map are not accessible the service converts the features into an image format on the server and it is this image that is sent to the client. The OGC WMS specification defines the following functionality: GetCapabilities, GetMap, GetFeatureInfo, DescribeLayer, GetLegendGraphic.

Basic though it is, a WMS is nevertheless useful in the current context since it is uses simple, tried-and-tested software, requiring little by way of local (client-side) capabilities. WMS can be easily mapped onto Palm-type hand-held devices, thus are useful in field- settings. A WMS is powerful enough to be able to create maps of the current operating picture, including symbols added to coverages that might describe evolving ground conditions. But users cannot select these symbols, nor interact with them. They could choose to add or remove various layers of such symbols, but individual map features are not differentiated in the image sent to the client.

4. Web Feature Service (WFS) By contrast, a Web Feature Service passes collections of features from the server to the client. Thus the client-side application has the responsibility of turning the features into a map. More importantly, the user can interact with individual features, or feature collections, effectively the user has direct access to the geospatial data hosted on a server. So a user can add, edit and delete features, and can query features and their definitions. The following are some of the operations that are typically supported: GetCapabilities, GetFeature, GetFeatureWithLock, DescribeFeatureType, Transaction, LockFeature. Since a WFS accesses features, not constructed maps, the features can be passed to other applications that offer GIS-type functionality, to manipulate them or process them in other ways. WFS and SLD work together to provide query functionality and control over the appearance of the map (see above description of SLD).

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 31 Geospatial Technology 3/15/2006

c. Data Formats and Standards

1. OGC (GML) The Geography Markup Language (GML) is an Encoding Specification for the modeling, transport and storage of geospatial information, and forms the schema implementation for many web mapping and other OGC services. Like SLD, it is a variant of XML. The scope of functionality embraced by GML is very wide, where early versions concentrated on geometry, the current specification embraces: geographic features, coverages, observations, topology, geometry, coordinate reference systems, units of measure, time, and value objects. (http://xml.coverpages.org/geographyML.html). The GML Simple Feature Profile is the implementation of the Feature Model described in the previous paragraph, thus restricting the scope of the specification to a more manageable size for implementers. The current GML specification (Version 3.1.1) is available from the Open Geospatial Consortium at http://portal.opengeospatial.org/files/?artifact_id=4700, and the GML 3.1.1 schema documents can be accessed from http://schemas.opengis.net/gml/3.1.1/base/.

Web Feature Services typically use GML as their data transport mechanism. GML can also be used to specify geometry inside of SLD documents, hence it is possible to define a mapping symbol or icon externally from a GIS database, and pass that symbol around as part of an SLD document. Note that this mechanism is not an efficient means to distribute map data, and should only be used for small amounts of geometry. The GML community of developers and users is very established and its members cover a wide range of perspectives from urban planning to geology to computer science. At this point in time, indications suggest that this format will become dominant among all possibilities. It suits the UN purposes here very well it is flexible, open, and well engineered; it requires no investment in proprietary systems to use or produce and it has a lot of support among the various developers of open geospatial technology.

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 32 Geospatial Technology 3/15/2006

2. KML The Keyhole Markup Language (or KML) is Google s own Earth Science data transport format, used to describe the various components that comprise the Google Earth displays. Like GML it is an XML-based language, designed to encode the various aspects of geometry, overlay and cartography that control displays in the Google Earth application. KML was originally developed by the Keyhole company before it was acquired by Google. A KML file contains a basic description of a place, associated longitude, latitude, tilt and other positional information (such as a specified camera view) that support Google Earth functionality. It encodes the various place-marks, ground overlays, paths and polygons within in the Google Earth client. KML is in some senses a variant of GML, or at least shares many similar features. However, it conflates styling/appearance information and geometry within the same document (which has attracted some criticism), something which the OGC avoids by devoting the SLD specification to all visual encoding and presentation aspects. It is rumored that in the future, Google may try to align itself more closely with existing community-built standards for mapping by revising KML.

3. Shapefiles The shapefile is a proprietary data exchange format developed by ESRI as a convenient means to export and exchange geospatial datasets. Shapefiles can encode geometry, and also associated attributes (though these can also be exported separately). The shapefile format was not originally in the public domain but was extensively reverse-engineered. Its specification is now (almost entirely) public and is available for download from www.esri.com/library/whitepapers/pdfs/shapefile.pdf.

The shapefilee format is widely used, mostly because of the market share that ESRI has accrued, so vast quantities of data are already available as shapefiles. Most non-ESRI GIS consequently include data import facilities for shapefiles. Whereas the OGC s Simple Feature Model and its implementations are consensus-built, the shapefile is designed to suit the needs of the ARC range of software products. Nevertheless, it serves

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 33 Geospatial Technology 3/15/2006

well for many tasks and since it has been around for a while, it is stable. Currently, there is some convergence evident between shapefile workings and OGC specifications.

4. VMAP The Vector Smart Map or VMAP initiative originates with the US Defense Mapping Agency (now the National Geospatial Intelligence Agency) and is both a technology for encoding geoinformation via the Vector Product Format (VPF) and a series of data coverages, organized into libraries by theme and available in three distinct spatial resolutions as follows: VMap Level 0 equivalent to 1:1 million-scale or 1:2 million-scale paper charts. VMap Level 1 equivalent to 1:250,000-scale paper charts. VMap Level 2 - equivalent to 1:50,000-scale and 1:100,000-scale paper charts. VMap Level 0 datasets are in the public domain within the USA, and are widely distributed in a derived form as the Digital Chart of the World. Some VMap level 1 datasets are also available. To give some idea of data volumes, VMap Level 0 world coverage fits onto 4 CDs, whereas Level 1 requires over 200 CDs. Themes covered include: Boundaries, Data Quality, Elevation, Hydrography, Industry, Physiography, Population, Transportation, Vegetation and Utilities (source: http://exchange.manifold.net/manifold/manuals/5_userman/mfd50Import_Drawing__VMAP.htm)

VMAP represents the most comprehensive global data collection in existence. The main obstacle to its deployment is access. It is not available to all countries, though is widely distributed to US allies. There may be problems in gaining access to higher resolution data for some locales.

5. Geo-Tiff GeoTIFF is a geographically-referenced image format, derived from the Tagged Image File Format (TIFF) for raster imagery. The GeoTIFF community is comprised of over 160 different remote sensing, GIS, cartographic, and surveying related companies and organizations to establish a TIFF based interchange format for georeferenced raster imagery. (http://www.remotesensing.org/geotiff/geotiff.html) The GeoTIFF specification extends the TIFF specification by providing all the tags and ancillary FIGS Working Group Document: Proof of Concept and state of the art in FOSS 34 Geospatial Technology 3/15/2006

information needed to tie an image to a known position and map projection, in other words to geographically locate (geo-locate) an image. It became popular during the late 1990 s and has remained so, due in part at least to the relative slowness of the OGC in developing exchange formats for imagery (though these exist now).

GeoTIFF provides tags to deal with a wide variety of projection types, coordinate systems, datums, and ellipsoids and has basic compatibility with the US National Spatial Data Infrastructure (NSDI). GeoTIFF is also extensible (though extensions are of course not exchangeable with other systems) so for example missing local projections can be developed as required.

d. Existing Geo-spatial FOSS stacks

The GIS Knoppix Project (Germany): http://www.dei.isep.ipp.pt/pac/sig/sig-livecd The GIS Knoppix comprises a bootable Linux disk that contains a number of different open-source GIS, mapping and remote sensing tools and associated databases, including: UMN MapServer, MapLab, TerraView, MapDesk, PostgreSQL/PostGIS and Jump. This is a useful resource, and gives a glimpse of what might be possible within this project. It suffers from the fact that although the component systems included are mostly mature, useful and proven tools, they do not integrate very closely. Some tools will connect to others, notably the PostgreSQL/PostGIS Database, whereas others work in isolation. It emphasizes the point that many free, open-source tools do not in themselves make a unified system.

GisMorphix (India): http://freesoftware.keltron.org/gismorphixcd.html GisMorphix is similar to the Knoppix described above, a bootable Linux CD distribution that contains a number of open-source GIS and mapping tools: GRASS-the Geographic Resource Analysis Support System (the oldest and most established open source GIS, Thuban, an interactive map viewer, QGIS, a specifically Linux-based GIS, Generic Mapping Tools (GMT) a Unix GIS methods set, and some more general scientific and FIGS Working Group Document: Proof of Concept and state of the art in FOSS 35 Geospatial Technology 3/15/2006

support applications (though no heavyweight spatial database). As above, these tools are no doubt useful but they are not integrated together into a single system, in fact the technology and standards used to build these tools would make connecting them together operationally a very difficult task. Nevertheless, a commendable effort and a useful, and free, resource.

Social Change Online (Australia): http://online.socialchange.net.au/ Social Change Online builds scalable, stable, established, IT consultancy and turnkey solutions involving data integration and mapping. It is not an open source project, but does use open standards and (though perhaps not available to users) is at its base an open system in terms of design. Extensive use is made of existing standards for schema specification and editing, as well as for mapping and data integration via its Aims4 Content Management System. Because of this, and good underlying design, new applications can be rapidly prototyped and deployed and new content can be easily assimilated and distributed. For example, it can easily integrate web mapping tools such as GeoServer. Documentation is excellent, and the product is stable and well-proven. However, the system is not free, the UN would need to pay for each new application developed, and negotiate a rate.

Existing Open Geospatial Projects and Communities GeoTools (originally Uk, now international): http://www.geotools.org/ GeoTools is perhaps the broadest collection of developers currently working towards the development of open source, open standards geospatial functionality. The project began at the University of Leeds in the 1990 s, producing mapping tools and associated GIS methods. In its second revision, GeoTools has re-oriented itself around the spatial data and schema-level tools and services, providing implementations of the OGC s (Simple) Feature Model, back-end database connections, and similar infrastructure. It will connect to many databases, including PostgreSQL/PostGIS, Oracle, and MySQL. GeoTools developers are a tight-knit community, spanning the globe, and as well as using open standards; they also run an open development process, where all interested parties can participate. Their technology (based in Java) pervades many other open geospatial FIGS Working Group Document: Proof of Concept and state of the art in FOSS 36 Geospatial Technology 3/15/2006

initiatives, including GeoServer, uDig, GeoVISTA Studio and GeoWidgets (See below for descriptions of these). The GeoTools community website maintains open software archives and hosts an open forum for discussing and planning the trajectory of the project A full range of documentation is available.

Geoserver (originally Canada, now international): http://docs.codehaus.org/display/GEOS/Home GeoServer is an open-source web mapping server, which implements both the OGC s Web Mapping Service and Web Feature Service standards. It builds on GeoTools functionality. GeoServer s strengths are its ease of use and adherence to standards, so although it is not (currently) the fastest web mapping server, it is perhaps the safest in terms of its underlying technology. It maintains an excellent range of documentation for users and developers, and, as GeoTools, the developer community is well organized and coordinated. uDig (Canada/international): http://udig.refractions.net/confluence/display/UDIG/Home uDig sets its goal to be a user-friendly, Desktop Internet GIS, and is another open-source project, this time from the Refractions group (Canada). Like GeoTools, uDig also boasts an open-development process. It strongly follows OGC standards and shares some of its (Java) code with GeoTools and GeoServer. It is a relatively new codebase (version 1.0.5 is the current stable release) but nevertheless contains some very useful functionality for internet-based mapping, including a new complete map feature editing suite. Its functionality is discussed in greater detail below. The uDig website contains comprehensive documentation for users, developers and contributors.

GeoWidgets (International): http://sourceforge.net/projects/geowidgets/ GeoWidgets is a new initiative that builds on the core technology provided by GeoTools, to offer some higher-level (more user-oriented) functionality such as map panes and legend tools, and thus may be useful for this project to help wrap methods from our software stack with user-level interfaces and tools. This is a project to watch into the future. FIGS Working Group Document: Proof of Concept and state of the art in FOSS 37 Geospatial Technology 3/15/2006

GeoAPI (International): http://docs.codehaus.org/display/GEO/Home GeoAPI is a new project, related to GeoTools, GeoWidgets, GeoServer and uDig in that it shares developers and ethos. GeoAPI aims to provide pure OGC and ISO interfaces, and in doing so reduce the amount of duplication occurring since several open-source GIS projects all require these interfaces. The codebase is open and in Java. This is perhaps the best place to look for reference implementations.

IMPORTANT NOTE: All the above projects are commendably striving at an open- source, open standards model of design and distribution, and all use Java technology and open code repositories. However, it is fair to say that, for the most part, these projects are fairly new and definitely still works in progress. GeoTools has been around for the longest time, about 10 years, but the current version (v2) differs markedly from the original version, in that it has concentrated all its efforts so far at the lower-level aspects of GIS functionality. In fact all the projects described above have this factor in common: a concentration on the lower-level data, server, database and query aspects of a GIS, and less focus on the user-level features and interfaces. There is every expectation that these projects will address user-level functionality in the coming months and years, but as yet it is largely absent, thus requiring any new system to provide some functionality of its own, geared towards more high level interactions and operations.

MapBuilder: http://docs.codehaus.org/display/GEOSDOC/MapBuilder), (http://mapbuilder.sourceforge.net/) Mapbuilder is an AJAX-like toolkit that allows OGC Web Service calls to be made by thin clients. Base support for MapBuilder is included in GeoServer releases. There are minimal server-side requirements. If MapBuilder development continues, it may be a reasonable platform for delivering thin-client geospatial applications using OGC Web Services.

JUMP, The Java Unified Mapping Platform, is an open-source GIS developed byVividSolutions Inc. for GeoConnections, Canada (Canadian Spatial Data FIGS Working Group Document: Proof of Concept and state of the art in FOSS 38 Geospatial Technology 3/15/2006

Infrastructure). VividSolutions is also the creator of the Java Topology Suite (JTS). JUMP Development continues with several interested groups: Open-JUMP: (http://jump- pilot.sourceforge.net/), The JUMP Project: (http://www.jump- project.org/index.php?PID=PID) and GeoConnections Canada Canadian Spatial Data Infrastructure (http://cgdi.gc.ca/CGDI.cfm/fuseaction/aboutGcs.welcome/gcs.cfm). JUMP has a pluggable architecture, and a growing number of extensions available (http://www.jump-project.org/portal.php?PID=PL).

JUMP represents perhaps the most advanced and mature editing capabilities available in an open-source GIS product. It may have been an early influence on uDig, as some of the same developers were involved, and currently recommend JUMP for sophisticated editing. JUMP also integrates the Java Conflation Suite (JCS), which has some very unique abilities compared to other suites evaluated here, and may be quite suitable for some OCHA-related functions such as redistricting data and detecting and repairing errors in polygon layers automatically/semi automatically, as well as other tasks such as topologically stitching together tiled datasets. The connectivity is not as sophisticated as uDig (currently no direct WFS/WFS-T connectivity), but shapefile, GML, and PostGIS capabilities are available. One current limitation is that the datasets being used need to fit into memory. Use for specialized applications such as global tile stitching may be aided by 64-bit machines and 64-bit OSs with large amounts of memory to perform such large, one-time operations.

MapServer (originally USA, now international): http://mapserver.gis.umn.edu/ MapServer, from the University of Minnesota, USA, is a high quality (and fast) web mapping engine. It is an open source project, will run on a number of platforms (Linux, Windows, Mac OS) and supports a variety of development environments, currently: PHP, Python, Perl, Ruby, Java, and C#. It can connect to a large number of databases, including MySQL, PostGIS and Oracle. MapServer implements the OGC s WMS and WFS standards, with support for GML and SLD (see descriptions of these above). It can produce higher quality cartographic output, via a library of literally thousands of map

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 39 Geospatial Technology 3/15/2006

projections, legend and scale-bar tools, support for thematic mapping and even intelligent label placement and scale-dependent generalization.

According to its website, MapServer does not aspire to be a GIS, which may limit its usefulness in the long run; though since it offers a high degree of connectivity, other applications can provide analysis and editing support. MapServer has around 20 developers currently and has good tools and documentation for both users and developers.

GeoVISTA Studio (USA): www.geovistastudio.psu.edu Studio is an open source, Java-based, visual programming environment that allows for the rapid development of complex data exploration and visualization applications to support geographic analysis. It achieves this by leveraging advances in geocomputation, software engineering, visualisation and machine learning. At the time of writing, Studio contains a number of geovisualization and analysis components including: parallel coordinate plots, scatterplot, visual classifier, 2D map and image viewer, sophisticated colour selection (including Munsell colour-space), spreadsheet, statistics package, starplots, boxplots, Radviz and many visual data mining tools.

Studio utilizes JavaBean technology, and can automatically construct data pipelines between components. Its primary design aim is to allow ease of integration of foreign components (in JavaBean form), hence it might provide useful technology in the medium term to rapidly build and deploy custom applications, e.g. to suit emerging crisis needs. It integrates and builds on some GeoTools back-end functionality, thus also uses OGC open standards, and implements a visual Style Layer Description editor (see description of SLD above). Studio is currently used by NCI and NCHS analysts. Tutorials are available for some of the graphical tools.

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 40 Geospatial Technology 3/15/2006

STARS (USA): http://stars-py.sourceforge.net/index.html) and GeoDa (USA): https://geoda.uiuc.edu/ Space-Time Analysis of Regional Systems (STARS) and GeoDa are both open-source packages designed for the analysis of regional data time series (STARS) or descriptive and exploratory spatial analysis and cluster detection (GeoDa). They are bracketed together here because of a large degree of collaboration and exchange between the two projects. They both implement many recent spatial statistical and graphical tools to uncover clusters and trends in space-time datasets, such as demographic, and health data. STARS and GeoDa functionality could form the backbone of an open-source spatial analysis toolkit in a larger open GIS project that might follow from this pilot study. Both are implemented in Python, which enables rapid development of new methods. Via Jython bridging technology, Python code can be tightly integrated with other Java-based tools, thus should not be considered a barrier here. The GeoVISTA Studio team (see above) has developed Java-Python bridging technology specifically to access STARS and GeoDa from a Java-based environment. User-level documentation is available for both projects and the GeoDa project runs periodical tutorials to train new users.

OSSIM (USA): http://www.ossim.org OSSIM (Open Source Software Image Map), pronounced awesome is a longstanding image processing system, under development since 1996. It provides a good deal of highly sophisticated image processing capability including the option to run on parallel architectures (something that only it and GRASS can do), and some (more limited) GIS functionality mostly related to importing and displaying GIS data layers. OSSIM is developed and distributed using an Open Source license, but unlike most of the other tools and systems described here, OSSIM is written in C++, not Java, hence is problematic to integrate directly with the software stack developed here (although Java C++ bridging technologies are widely available). It s development was funded by US intelligence and defense agencies, and it has been used in crisis/disaster settings previously. Good user-level documentation is available.

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 41 Geospatial Technology 3/15/2006

GRASS (originally USA, now international): http://grass.itc.it GRASS (Geographic Resources Analysis Support System) is, in many ways, the system that started it all. Developed originally for the US Army (Corps of Engineers) over a long period from 1982-1995, it has since resided in the public domain, and is currently hosted by ITC, Trento, Italy. So it is the most long-standing, complete, open-source GIS currently available. GRASS will run on many computational platforms, including: Sun, SGI, IBM and Cray (high performance supercomputers), and PC but not under MS Windows (it needs some form of Unix/Linux). The codebase is largely ANSI C (about 1 million lines), and is now in its 6th major release. In reality, GRASS is an assemblage of functionality that covers 2D and 3D imagery, 2D and 3D vector-based GIS. It contains a large and comprehensive set of remote sensing tools as well as spatial analysis and terrain modeling functionality. As Ossim, one of the problems with GRASS is that it was not originally conceived of as an open system in the way we understand them today (see Section 4.3.1 above), though it certainly now attempts to be one.

The codebase of GRASS is entirely open, but the architecture is not based around open standards at its core (though it can interoperate with some OGC-style formats). Along with the language incompatibility, this makes integrating GRASS functionality in a Java software stack designed around OGC standards problematic. Java bridge technology will overcome the C Java connection problems, but by taking on a C codebase we would also inherit all the problems of utilizing C across different platforms, making maintenance and deployment rather more complicated. Nevertheless, GRASS is a good place to look for methods that might be required, and is an excellent product in its own right. It seems sensible to include GRASS in a UN software stack though as a stand- alone system to be used whenever more heavyweight analytical GIS functionality is needed, and using its file conversion capabilities to pass data in and out. At the time of writing, the documentation for GRASS is undergoing an overhaul, though the reference documentation appears comprehensive, it requires a new user tutorial.

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 42 Geospatial Technology 3/15/2006

4.3.2 Set up test environment (Note that administrative-level access is assumed for the test platform setup and installation).

a. Setup and install POSTGRESQL/POSTGIS environment. (http://www.postgresql.org/) and (http://postgis.refractions.net/). The setup of the PostgreSQL/PostGIS environment has several steps. This is truly the heart of the GeoSpatial system, so it is worth taking the time to set it up carefully. The easiest way is to start with Postgresql version 8.1 or above, which has GiST indices available for higher-performance spatial indexing. The installation for this version and above already contains an embedded version of PostGIS that can be installed at the same time, with a few extra steps. The version of PostGIS available in PostgreSQL 8.1 is (was at the time of the test installation) PostGIS 1.0.4 (whereas the most current version is now PostGIS.1.1.1). The documentation at the time of the installation was not an exact match to what needed to be done to get the system operational. For Wintel operation, running the system as a Windows service is the recommended option. Choose a Service Name for the Database service, and both an Operating System user for the service to run, as well as a database administrator username and password. The installation will prompt for these. Minimum space required is approx 7Meg (with much more recommended). Also choose a default database name (e.g. postgres, etc). Note that the database server host can contain a number of databases , which are logically distinct sets of data (ie, one Windows service installation can contain many databases for example golden_copy , public_access , unprocessed_data , etc..) The installation will prompt for a number of options as it progresses it is important to select the correct ones: - select the checkboxes for: - GiST indexing, -enable PostGIS functions, -load Reference data (ie, Spatial Reference systems, etc.), -create language psql. After the installation executable is finished, it is necessary to run some commands manually in order to enable PostGIS. At the command line: cd to the POSTGIS_INSTALL/share/contrib. directory. Run createlang U plpgsql . Next, run psql U -f lwpostgis.sql d . FIGS Working Group Document: Proof of Concept and state of the art in FOSS 43 Geospatial Technology 3/15/2006

Then, run psql U -f spatial_ref_system.sql d . PostGIS should now be installed and enabled.

b. Set up and install a java environment. In the case for development, (http://java.sun.com/j2se/1.4.2/download.html) the Java Software Development Kit (SDK) J2SDK 1.4.2_10 was loaded. For client-only installations, it may be possible to use just a java runtime environment (JRE) rather than the full SDK.

c. Setup GeoServer (http://docs.codehaus.org/display/GEOS/Latest) GeoServer supports both WFS-T and WMS. Since this project is initially more concerned with newer functionalities such as WFS-T and initially deals only with Feature (vector) data, it was decided to use GeoServer for both WFS-T and WMS capabilities. It is also advantageous to administer one rather than multiple server processes, particularly for a field implementation, where administrative ease will be important. UMN Mapserver capabilities are already mature and widely proven, so if the GeoServer WMS proves unsatisfactory, UMN MapServer will be added in another phase. For Win32 platforms, GeoServer is available as a self-extracting executable. GeoServer 1.3.0-PR1 (pre-release 1) was used for the demo. GeoServer 1.3 production has since become available. Note that basic setup of GeoServer is distinct from the configuration of GeoServer to contain Server-specific identification, contact information, and administrative option setup, as well as Feature content (covered in section 4.3.4).

Install UDig. (http://udig.refractions.net/confluence/display/UDIG/Home)UDig is easily installed on Win32 via a simple self-extracting executable. Multiple versions: stable 1.0.6 and unstable 1.1.M4 can coexist on the same machine, but may interfere with each other if the same project files are used.

d. Install GAIA/Carbon Project tools (http://www.thecarbonproject.com/products/gaia.html). These tools are Windows-only, as they are intended to add Geospatial Web Services to the Microsoft Dot Net environment. As such, the Microsoft Dot Net runtime FIGS Working Group Document: Proof of Concept and state of the art in FOSS 44 Geospatial Technology 3/15/2006

(http://msdn.microsoft.com/netframework/) must first be installed on the machine where GAIA and Carbon tools will be used. After that, a simple self-extracting executable is run.

e. Install OGR/GDAL. The easiest way to do this is to download and install fwtools (http://fwtools.maptools.org/), yet another self-extracting executable for Wintel platforms. Note that this package includes OpenEV raster/vector desktop data viewer and analysis tool and MapServer as well.

f. Import Global, Regional and Local data sets. The selection and purpose of the test data sets used is detailed in section 4.4. There are several methods to import data sets into PostGIS, our selected database for the Data Tier. The two main sets of FOSS data conversion utilities are: 1) those included with PostGIS shp2pgsql, and 2) the OGR/GDAL utilities. Each has somewhat different capabilities, and supports shapefiles. VMAP0 and VMAP1 data is in VPF format, which is not supported in either of these utility sets, so it was converted to shapefile format with a commercial utility, and then converted to PostGIS format with the shp2pgsql utility. The issue here is what to call the geometry fields once converted to sql format. The default geometry field name for PostGIS using shp2pgsql is the_geom (vs. Shape in a shapefile). A simple DOS script (see Appendix B) was written to permit all shapefiles in a directory to be processed at once, using shp2pgsql to create a schema, spatial indexing, and statements to insert the data. The script loads the shapefiles specified (without extensions) in the FILES file in the directory where the shapefiles are located. This file can be created by using entering (in a DOS window) DIR /b *.shp > FILES . and editing the file to remove the extensions. The name of the database table created can be altered in the script to be _. For VMAP1 data, for example, all of the table names were postpended with _vmap1. Storage of Geometry data can be in either WKB (Well- Known Binary) or WKT (Well-known Text)

Formats. WKT is less subject to floating-point drift . Either form can be directly displayed as text using the free OGR/GDAL utilities. Choices as to geometry field name FIGS Working Group Document: Proof of Concept and state of the art in FOSS 45 Geospatial Technology 3/15/2006

and format should be made before attempting conversions. Conversions produce sql files that can be loaded into the PostgreSQL/PostGIS database using the psql command-line utility.

g. Import NYC bench-mark data sets. Data were converted to shapefiles from SmallWorld format, and imported the same way as in g. above. No difficulties were encountered, and speed was surprisingly fast given the large number of polygons.

h. Setup Google Earth Pro/Google Earth (HTTP://earth.google.com). Google Earth is installed via a self-extracting executable. Note that this is currently available for Wintel only.

i. Setup JUMP ( http://www.vividsolutions.com/jump/), (http://www.jump- project.org/credit.php). JUMP 1.1 simply needs to be unzipped. JUMP_INSTALL_DIRECTORY/bin/jump.bat batch file starts the Wintel version.

j. Setup JUMP/JCS (Java Conflation Suite). (http://www.vividsolutions.com/JCS/) Java Conflation Suite menus can then be seen in the JUMP menus and interface.

k. Setup Quantum GIS. (http://qgis.org/), (http://sourceforge.net/projects/qgis/) Quantum is a C++-based cross-platform system. Again, for Wintel platforms, a self- extracting executable is available to perform a complete install.

4.3.3 Matrix of Interoperability among software components

a. Java vs. C++ Components considered here fall into three camps based on computer language used for implementation, Java (the most popular) C / C++ and Python (less of an issue immediately as the two applications using Python are geared towards advanced spatial analysis, not mapping support). As noted above, Java is inherently cross-platform, so its use avoids the sometimes problematic cross-platform compilation and maintenance issues that typically affect C and C++ applications. Java also has the FIGS Working Group Document: Proof of Concept and state of the art in FOSS 46 Geospatial Technology 3/15/2006

advantage of directly supporting many standards for inter-process communication and web services. Its disadvantage when compared to C and C++ is its speed of execution: Java code runs on a virtual Java machine, which then maps on to the local hardware. This extra layer leads to runtime inefficiencies, typically ranging from 10%-30% slower runtime execution.

b. Standards and versions GML: All GML is not written alike. The GML Relay (http://www.gdmc.nl/events/relay4/) is sponsored to observe who can pass the baton between vendors and systems with GML. It is a grave mistake to assume that data will be interoperable just because the GML moniker has been attached by a marketing person.

c. Interoperability assessment Interoperability is a many-faceted concept, so while there are examples among the software tools described above that are clearly interoperable to a very high degree, there are others that are interoperable only in the sense that they can import and export data in the same format (thus files can be passed between them. In some situations, this may be sufficient, or at least adequate. We evaluate interoperability in two stages. The first stage addresses general big picture concerns and issues relating to the potential to integrate code from the various projects and systems described above, and is summarized by a table, below. The second stage (in Section 4.3.4) is based practically on our experience of integrating the chosen components into a working system, and testing their compatibility and the reliability of their interfaces

Theoretical concerns Building a closely-integrated software stack does imply a higher degree of interoperability than just file transfer though; specifically, it implies that the software can be connected together into a single (logical, perhaps even physical) application to the user it appears as one single system with none of the seams showing. The matrix of interoperability included below in Table 3 attempts to make a finer distinction between components than simple yes or no compatibility. Accordingly, we offer three levels: FIGS Working Group Document: Proof of Concept and state of the art in FOSS 47 Geospatial Technology 3/15/2006

(1) Sharing data (coded Green) Here we score 1 if the systems can only share files by import and export of a mutual format (e.g. shapefile), 2 if (OGC) open formats are supported by both applications and 3 if the data connections can be made directly between applications using OGC interface specifications, without the need for an intermediate file.

(2) Language compatibility (coded Blue) Here we score 1 if languages are bridgeable but not straightforward to produce a single system (as is the case for C (or C++) and Java, 2 if simple bridges will suffice (as is the case from Python to Java), 3 if there are no difficulties or complexities anticipated

(3) Can be built together into a single, (virtual) system (coded Red) Here we score 1 if the systems are not really designed to fit together at all, 2 if they might be engineered into a single entity with some developer effort and 3 if the systems are designed to fit together by their creators.

Note that both Ossim and GRASS (and to some extent GeoDa and Stars) are designed to be stand-alone, complete systems that try to include all required functionality rather than being engineered so that they can be easily integrated with other systems and components. This is in direct contract to GeoTools, GeoServer, uDig, GeoAPI and GV Studio (and to a slightly lesser extent MapServer) that are designed to be integrated with each other, or any other components and systems that follow OGC specifications.

Note also that GeoAPI cannot be assessed for data compatibility since it is not an application that accepts data, but a series of interfaces that define how data are passed. Finally, note that interoperability is the key design ethos of many of the later, java-based projects reviewed above such as GeoTools, GeoVISTA Studio, GeoServer, etc.. Thus they score highly in the table below. However, if an alternative table were to be constructed for end-user functionality, it is likely that the scores would be reversed, with these new projects scoring badly, and GRASS and Ossim coming out as clear winners FIGS Working Group Document: Proof of Concept and state of the art in FOSS 48 Geospatial Technology 3/15/2006

G G u W G G S M G S O G / D e t e e e e V s R G a a i r s o o o o i d r v p A g e i s T S A S g m e o S t e e o r P d u r S t o I s a d v l i e s o r

GeoTools 3 3 3 3 3 3 3 3 3 - 3 3 3 3 3 3 3 3 1 2 2 1 1 1 3 1 1 GeoServer 3 3 3 3 3 3 - 3 3 3 3 3 3 3 3 1 2 2 1 1 1 3 1 1 uDig 3 3 3 - 3 3 3 3 3 3 3 3 1 2 2 1 1 1 3 1 1 GeoWidgets - 3 3 3 3 3 3 3 3 1 2 2 1 1 1 3 1 1 GeoAPI - 3 3 - 3 3 - 2 2 - 1 1 - 1 1 MapServer 3 3 3 1 2 2 1 1 1 3 1 1 GV Studio ( 1 2 2 1 1 1 3 1 1 Stars / Geoda 1 2 2 1 2 2 Ossim 1 3 2 GRASS

Table 3. Matrix of Interoperability. Green numbers are for data compatibility, blue for language compatibility, red for system compatibility. Three is highest, 1 is lowest. A dash means that an evaluation makes no sense. See text for further details.

4.3.4 Integrated stack evaluation

Schematics of the FIGS integrated stack are shown in figures 3, 6 and 9. The schematics show the three tiers: the data tier, the web, tier and the client tier and show how data are passed between these three layers, enabling them to be implemented as distinct physical entities. Note that although we have made specific choices as to which systems to implement in each of the layers, any system meeting the OGC interface specifications we have used could be substituted. Figure 3 shows the data tier with the thin client access shown27. The Thin Client makes a request of the Web Services Tier which communicates with the Data Tier which gathers the information and sends to the Web Services Tier which sends the data to the Thin Client. This process is shown in Figures 4 and 5. Figure 4 shows the MapBuilder thin client and the GeoServer Console Window (black box). Figure 5 shows a zoom in on the UN facilities in Pakistan.

27 Note: arrows denote direction of data flow FIGS Working Group Document: Proof of Concept and state of the art in FOSS 49 Geospatial Technology 3/15/2006

Figure 3: Thin Client Access see text for full details28.

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 50 Geospatial Technology 3/15/2006

Figure 4: Map Builder thin client and GeoServer Console Window web services tier (black box)

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 51 Geospatial Technology 3/15/2006

Figure 5: Zoom in showing UN facilities using MapBuilder client

Figure 6 shows a schematic of access to the GOOGLE Earth Client. While Google Earth itself is a Thick Client, a thin client was used to drive Google Earth. The Thin Client makes a request of the Web Services Tier which communicates with the Data Tier which gathers the information and sends it to the Web Services Tier which sends the data to the GoogleEarth client. Figure 7 shows Google Earth client depicting the thin client browser accessing GeoServer to obtain Pakistan administrative boundaries from the PostgreSQL database. Figure 8 shows IDP camps, HIC hubs, UNJLC roads (white) and administrative boundaries (yellow) obtained the same way.

.. FIGS Working Group Document: Proof of Concept and state of the art in FOSS 52 Geospatial Technology 3/15/2006

Figure 6: GOOGLE Earth Access.

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 53 Geospatial Technology 3/15/2006

Figure 7: Google Earth client showing thin client browser (white box) accessing GeoServer (black box) which access PostgreSQL to obtain Pakistan administrative boundaries (green).

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 54 Geospatial Technology 3/15/2006

Figure 8: GOOGLE Earth Client showing IDP camps, HIC hubs, UNJLC roads (white) and administrative boundaries (yellow).

Figure 9 shows access for a Thick client. The ThickClient makes a request of the Web Services Tier which communicates with the Data Tier, which in turn gathers the FIGS Working Group Document: Proof of Concept and state of the art in FOSS 55 Geospatial Technology 3/15/2006

information and sends it to the Web Services Tier, which then passes the data to the Thick Client.

Figure 9: Thick Client Access.

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 56 Geospatial Technology 3/15/2006

Two thick clients tested are shown in figures 10 and 11. Figure 10 shows a UDIG client with Pakistan data that includes; IDP camps, HIC hubs, UNJLC roads (grey) and administrative boundaries (green). Note that Thick Clients can also bypass the Web Services Tier for direct access to the Data Tier if needed.

Figure 10: UDIG client with data obtained from PostgreSQL via GeoServer

Figure 11 show an ARCMap client with the same data. ARCMap is not a FOSS but is a common platform used by HICs and others for emergency response

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 57 Geospatial Technology 3/15/2006

Figure 11 ArcMap client with data obtained from PostgreSQL via GeoServer

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 58 Geospatial Technology 3/15/2006

Figure 12 shows PostgreSQL tables for some of the Pakistan data used in testing the stack. These data were accessed via the Geoserver web tier and sent to the various clients discussed above.

Figure 12: One of the data tables contained in the PostgreSQL database

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 59 Geospatial Technology 3/15/2006

a. Completeness

The Data Tier The relational and object/relational databases component is a very mature technology. The Data Tier is the most solid and complete tier in the stack. Its structure is based on the Simple Feature Specification (SFS) which is a non-topological, OGC format for representing geographic (map) features (described above in section 4.3.1. Without an on- the-fly topological construction this data structure has some limitation with respect to data integrity and maintenance.

PostgreSQL, PostGIS and some other systems implementing the OGC SFS are reliable enough to be used both in data centers, in the field or at a workgroup level.

The Web Tier WMS, WFS and WFS-T servers are based on mature premises and technology. GeoServer, which implements WFS-T and WMS functionality for this proof-of-concept, is based on solid, well-tested, industry-standard J2EE (Java 2 Enterprise Edition) technology, implementing the Web Tier of J2EE ie, Servlet Containers and Java Server Pages. There are multiple ways that this tier can be deployed, including using the bundled Jetty Java Servlet Container (http://jetty.mortbay.org/jetty/index.html), or as a deployable Web Application on the Apache Tomcat Servlet Container (http://tomcat.apache.org/), the JBOSS application server (http://www.jboss.com/developers/index) or the Resin application server (http://www.caucho.com/index.xtp).

The Web Tier and Thin Client Tier Combined Thin clients with simple and reliable feature editing capabilities show promise for field- entry of geo-spatial data for Humanitarian-disaster. Being able to reliably record geographic data along with attribute data for a Real-time RVA (Rapid Village Assessment) may deliver the largest benefit for the least amount of development effort. It could enable many cooperating organizations to share accurate, updated humanitarian

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 60 Geospatial Technology 3/15/2006

data in almost real-time using a centralized database architecture integrated with the Web.

Services Tier A strength of both the Web Services Tier and the Client Tier is the ability of thin clients, particularly with the maturity and completeness of WMS, to easily provide interactive kiosks at HICS, if internet access or a wireless bubble is available at the theater s site. Such kiosks would need little involvement of the HIC personnel other than ensuring that relevant data gets into the Data Layer, while potentially supporting many users and relief actors.

Thick Clients The least developed capabilities of the thick Client Tier are the feature editing and cartographic capabilities (ability to support cartographic templates, etc.). These limitations are being actively addressed by the development community. uDig and JUMP are based on modular, extensible frameworks. uDig uses the Eclipse Framework (http://www.eclipse.org/), and plug-in creation is documented at (http://udig.refractions.net/confluence/display/DEV/3+Working+with+Plugins). JUMP has its own plug-in extension framework, documented in the JUMP Developer s Guide (http://www.vividsolutions.com/jump/). GeoTools is strictly a library for Software development, and not currently directly used in the FIGS project, though it does offer some potentially useful functionality to support filtering and map styling. That being said, GeoTools is used as a code base for two of the GSS components being evaluated, GeoServer, and uDig, so in that sense it is already part of the FIGS stack.

b) Level of functionality and standards compliance (for each stack component)

Data Tier 1. DBMS PostgreSQL is the most mature open source object/relational solution available, and enjoys good documentation (including commercial publications FIGS Working Group Document: Proof of Concept and state of the art in FOSS 61 Geospatial Technology 3/15/2006

such as those listed at (http://www.postgresql.org/docs/books/), implementing all of the latest ANSI-SQL 92/99 standards and has features typical of an enterprise-level heavily- transactional database, including native interfaces for C/C++, Java, Perl, Python, Ruby, Tcl, and ODBC. A concise summary of features with comparison to commercial databases is located at (http://www.postgresql.org/about/). Extensive support is available from (http://www.postgresql.org/community/lists/) and via a number of commercial support companies such as (http://www.enterprisedb.com/) and Red Hat Linux (http://sources.redhat.com/rhdb/). Graphical facilities such as PgAdmin III are available to assist in database administration (Figure 12).

2. GIS Core. PostGIS (http://postgis.refractions.net/), the GIS Core of the system, as implemented according to the OGC Simple Features Specification for SQL, is among the most robust and mature of Geodatabase implementations. PostGIS uses GEOS (Geometry Engine Open Source) (http://geos.refractions.net/), a C++ port of the Java Topoplogy Suite for SFS support (thus in a way creating a close tie to the GeoTools/JTS code base). It enjoys a large following of users and developers, and is under very active development in conjunction with new versions of PostgreSQL. Runtime performance observed during testing was quite acceptable.

3. Data conversion and loading. The OGR/GDAL utilities and PostGIS data conversion facilities together cover most standard vector formats well, with the notable exception of VPF. These utilities performed well, and seemingly without error on our test data sets.

Web Tier GeoServer 1.3.0-PR1 was the implementation of the Web tier for the FIGS stack (http://docs.codehaus.org/display/GEOS/Home). It was chosen to implement both the WFS/WFS-T and WMS functionalities, for a variety of reasons including: the simplicity of maintaining one rather than two servers, its specialized functionality such as KML and shapefile output, and its ease of administration and integration. The installation option used for FIGS employed the default Jetty Servlet Container. GeoServer connects to a FIGS Working Group Document: Proof of Concept and state of the art in FOSS 62 Geospatial Technology 3/15/2006

wide variety of data sources, but we chose the most tested and venerated of sources, PostGIS and shapefiles. GeoServer s administration interface is excellent and well thought out. It is under active development both as a WFS-T and WMS platform support for a number of non-vector formats is actively being added. GeoServer enjoys an ever-expanding set of documentation, and has a number of very active developers involved, including the Open Planning Project (http://www.openplans.org/) and Refractions Research. Our testing showed GeoServer to be quite stable with the datasets listed in 4.4. GeoServer serves GML v2.1.2 and supports WFS 1.0.0. GeoServer also supports a cache of on-board styles to be used with its WMS. A number of SLDs (Styled Layer Descriptor documents) were developed to correspond to UN/OCHA symbology and were illustrated in the Figures 5, 8, 10 and 11 above . These included OCHA_IDP_point, OCHA_UN_point, OCHA_health_point, and OCHA_dynamic_symbols_point (which dynamically changed symbology according to a standardized feature symbology added to certain test datasets). The OCHA symbols used can be observed in the video demo of FIGS.

The WMS settings did prove a bit sensitive when rendering with non-default-symbols. GeoServer WMS was also somewhat sensitive to the correctness of the SLDs strange behavior was observed when SLDs were not quite correct eg, GeoServer WMS is not a good SLD development environment . Since at least two rudimentary SLD editors are now available, this is not a significant limitation.

Client Tier

Thin Client (and Google Earth) Evaluation: The Mozilla Firefox Browser was used in this evaluation. It is cross-platform, open-source and contains features that are superior to Microsoft Internet explorer for development, including a Javascript debugger plug-in to assist in developing AJAX-like (Asynchronous Javascript with XML) content. It is also more functional and less susceptible to security exploits than Internet Explorer. It is

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 63 Geospatial Technology 3/15/2006

a good example of an open-source product that is every bit as functional as its closed- source equivalent.

Thin clients developed included:

1. A simple html page that makes direct WMS (OGC Web Service calls) to GeoServer 1.3 PR-4 (the latest version of GeoServer at the time 1.3 is an official release now as of Jan 22, 2006). This client was used in the video demonstration (also see Figures 7 and 8) and created the Paris OCHA presentation to drive the Google Earth component. Note that Google Earth itself also accepted the GeoServer WMS-generated KML. For the video demo, some additional styling was added outside of Geoserver, in particular to support OCHA symbology and display of attributes in pop-up bubbles (although these were generated from the test data).

Note that Google Earth itself should be able to function as a client of the WMS (to request KML) if links are embedded in Google Earth KML text for callouts/bubbles.

2. MapBuilder (http://docs.codehaus.org/display/GEOSDOC/MapBuilder), (http://mapbuilder.sourceforge.net/). This type of approach (AJAX and Web Services) may really be the wave of the future, as sophisticated applications can be delivered to a Web Browser on-the-fly without any special software installation. MapBuilder consists of a set of widgets useable from Javascript, and a few back-end components, available in either PHP or J2EE (java servlets/JSPs). MapBuilder uses WMS calls for display of the map itself, and WFS-T calls for modification of content. A simple MapBuilder demo for Tasmania is included in the default installation of GeoServer 1.3-PR1 package.

The default Tasmania demo was used to examine basic functionality. On the positive side, querying of WMS data worked well as expected, including when changing styling information. Also, the addition of geometries of new points thru WFS- T worked as expected.

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 64 Geospatial Technology 3/15/2006

1. On the negative side, firstly, no feature information retrieval icon was present (ie, select feature X with an (I) icon and retrieve its Feature attributes). Since this would most likely be an important requirement, feature attribute retrieval icon was added to the Tasmania demo, but found that it was not working. The MapBuilder site and FAQ mentioned that this option did not work in older versions of MapBuilder, so the solution was to upgrade the version of MapBuilder used. The version was upgraded, and the Feature attribute retrieval began to work, but then the feature creation stopped working. Secondly, although WFS-T feature creation itself worked for feature geometries, feature attributes were always instantiated with the initial values from the embedded MapBuilder WFS-T request, instead of what was typed onscreen from the editable text fields that appear during feature creation. To test that this was not just due to the user interface, the demo itself was modified to try to hardcode feature values in, which were again not accepted, although the geometry itself was.

A MapBuilder-based application for Pakistan is also shown in Figures 4 and 5 above, and this was developed from the Tasmania MapBuilder demo, to examine functionality and performance with a realistic example of data size and complexity. As in the Tasmania demo, an overview map is used. The main map was enlarged to present a reasonably-sized, printable cartographic product for an on-the fly inquiry.

Layers used were: Second-level administrative Boundaries (polyLine), HIC Hubs (point), HIC Hub Regions (polygon), and WHO teams. Positive aspects of the testing were that styling options worked, UN symbology and text were displayed well, and interactive performance was acceptable with a realistically-sized dataset. Negative aspects were as above for Tasmania demo. More development time is needed to examine synchronizing the latest versions of GeoServer and the MapBuilder server-side components into a coherent demo with full interactive attribute retrieval and full WFS-T interaction including consistent geometry and attribute information entry.

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 65 Geospatial Technology 3/15/2006

Thick Client Evaluation

Notes:

1. Not all tasks were attempted for all clients due to time and resource constraints. Specifically, there was insufficient time to do exhaustive; realistic thick client functionality testing within the schedule constraints of this first exploratory phase. The matrix below does, however, attempt to demonstrate the wide range of functionality of different components available.

2. Google Earth, really a thick client, was treated in the Thin Client evaluation section above.

3. JUMP is a special case in regard to edit capabilities. See Appendix C JUMP Evaluation for more information on capabilities.

4. Quantum GIS test included only edit capabilities for shapefiles, since these were reputed to be reliable. PostGIS connectivity was not tested.

5. A suggestion for next phase testing is to attempt heads up digitizing according to some raster background.

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 66 Geospatial Technology 3/15/2006

Table 4 Matrix of Functionality

Capability uDig 1.0.6 uDig 1.1.1 JUMP ArcGIS Quantum (unstable) GIS 1. Displaying points with default symbology and text for name/identifier from: shapefile yes yes Yes, but no yes Yes, SLD/non- but default No symbology SLD/non- support default symbolog y support PostGIS yes yes N/A plug-in N/A (maybe N/A not installed with $ product) WMS, with yes non-default yes N/A yes N/A symbology (OCHCA SLDs) WFS, with non- yes: if default symbology no OCHA SLD is N/A N/A N/A (OCHCA SLDs) entered for layer on uDig SLD 2. Attempt to edit the attributes of already-created features from: shapefile no no yes yes yes PostGis no no N/A N/A N/A WFS-T no no N/A N/A N/A

3. Attempt to create new point features (with default attribute values): shapefile yes yes yes yes yes PostGis yes yes N/A N/A N/A WFS-T mixed, core mixed, N/A dump point core dump N/A N/A appear point appear on restart. on restart.

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 67 Geospatial Technology 3/15/2006

4.4 Identify and load a preliminary data set of global, regional and local data into FIGS as part of testing.

Our test data consisted of a number of very realistically-sized data sets:

New York City COGIS tax-lot data for all five boroughs (approximately 1.2 million polygons), and Manhattan Building data (approximately 200,000 polygons).

VMAP0 data covering the world, converted from VPF to shapefile format before entry into the GeoDatabase.

VMAP1 data tiles 132 and 131, covering Pakistan, converted from VPF to shapefile format. The tiles were not topologically stitched together before entry into the GeoDatabase.

Selected Global Discovery data, in OCHA s standard directory format, provided by OCHA.

Pakistan HIC data was provided by OCHA (shapefiles), in OCHA s standard directory format. Specific data sets tested included IDP camps, WHO_TEAMS, UNJLC data, including roads in the affected region and helicopter landing zones, HIC Hub locations and polygons representing areas of coverage.

Note that all data was set up to be entered into the Geospatial Database with EPSG(European Petroleum Survey Group) code (Spatial Reference ID) of 4326: decimal degrees with WGS84 datum. Note also that raster data was not part of the test set.

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 68 Geospatial Technology 3/15/2006

4.5 Design FIGS for maximum interoperability with other existing disaster management systems (i.e., WDWW, GDACS, FTS, etc.). It is rather premature to analyze the interoperability of FIGS with other existing system given that this is a pilot study. Below are some preliminary observations associated with the FIGS stack as currently tested and some of these existing systems.

4.5.1 Geo-Network (http://sourceforge.net/projects/geonetwork) GeoNetwork normally deals with files e.g. download entire file (typically shapefiles, ERDAS files, etc.) based on a catalog entry. It is hoped that in the future GeoNetwork will be able to use a URL rather than a file. Paolo Palmero (UN) is investigating whether GeoNetwork is capable of issuing any sort of query through a filter specification or SQL, etc. FIGs is intended to present seamless data access wherever possible. Querying for extracts for ROI s (Regions of Interest) is one potential method for getting data from FIGS. If GeoNetwork can be made to operate with WFS via URLs, this may present a solution.

Extisting GEONetwork installations are: OCHA GeoNetwork http://geonetwork.unocha.org/geonetwork/srv/en/main.home FAO GeoNetwork http://www.fao.org/geonetwork/srv/en/main.search WFP GeoNetwork http://vam.wfp.org/geonetwork/srv/en/main.home WHO GeoNetwork http://www.who.int/geonetwork/srv/en/main.search

4.5.2 WDWW FIGS will be PostGIS-based, while WDWW has used a number of RDMS including MySQL. One approach for integration with WDWW and FIGS is via OGC Web Services. An issue with respect to this approach is that OGC web services were developed before the standardization of standard SOAP/WSDL web services they are correspondingly currently under revision.

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 69 Geospatial Technology 3/15/2006

Incompatibilities of OGC Web Services and SOAP (ie, W3C standard ) web services (http://www.w3.org/TR/soap/) may be an issue as more web services come online. An OGC document (OGC-03-014) describes some experiments in OGC/SOAP Web Service interoperability and compatibility.

4.6 Integration with existing or emerging data and software networks Providing ubiquitous access to geospatial data and software is a critical component in the success of any field system. With the advent of GRID computing and Web services architectures, it becomes possible to access both data and methods in new ways, relying simply on an Internet connection (that could be provided by satellite link) rather than on datasets and software being pre-loaded onto all local machines. This section of our report examines the possibilities of using two existing, large-scale, distributed data collection technologies, exemplified by Google and the Geosciences Network (GEON), as part of a field-based response to disasters. Both Google and GEON are examples of Grid technologies, that offer large-scale data replication and redundancy strategies that usually result in better performance as well as being inherently more robust important aspects when confronted with unreliable or unpredictable local conditions.

4.6.1 GEON The Geosciences Network (GEON) is recent large-scale CyberInfrastructure project funded by the National Science Foundation (www.geongrid.org). Dr. Dogan Seber, the lead Geoscience PI has indicated a willingness to host both software and data related to this UN initiative. Many of the goals of GEON are shared with the UN, since both seek to enable greater access to data, engage local communities, offer better tools to local practitioners and facilitate on-the-fly data integration.

GEON technologies are based around a server-oriented architecture, and a network of GEON Point of Presence or PoP nodes that has good coverage within the USA and some growing presence overseas, including in India, China and Japan. GEON nodes form a distributed collection of data servers, with (usually) high bandwidth Internet connections FIGS Working Group Document: Proof of Concept and state of the art in FOSS 70 Geospatial Technology 3/15/2006

between them. Data collections and other analysis, mapping and data integration tools form a part of GEON and can be accessed via the GEONsearch and GEONworkbench environments, and are deployed using Web Portal technology thus they only require the availability of an Internet connection and Web Browser. The overall GEON architecture is shown in Figure 13.

Figure 13. GEON project architecture summary.

Each PoP node in GEON runs a Linux software stack that, once initially configured, can be centrally administered and updated, thus, were FIGS software to form a part of this stack, if could be deployed, managed and kept up-to-date at remote locations using GRID technology administered under GEON. This might remove some problems with deployment and reliance on local expertise.

In some sense, the UN and GEON share a similar goal with regard to establishing a local presence in different countries. By deploying a PoP node, GEON hopes to:

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 71 Geospatial Technology 3/15/2006

(i) identify and engage geoscience researchers across the globe, (ii) establish a community of expertise around each node and (iii) help facilitate the formation of large geoscience data collections. Clearly, all of these goals would be of benefit to this project as well.

GEON Grid technology is based on the Globus standard and is used in a variety of large- scale cyberinfrastructure projects within the USA that form a part of the National Partnership for Advanced Computational Infrastructure (NPACI) research and development program (http://www.npaci.edu/) GEON data management technology allows local data custodians to choose who can access their data, so it is possible to maintain local private collections, with access restricted to key members of the local science community, and/or UN workers. As a Geon data custodian, the UN could, then, manage its own local collections of data on GEON PoP nodes.

The GEON software stack contains a suite of data administration tools as well as tools for data integration (whose development is currently ongoing) and eventually will contain many geoscience applications as well, many of which will be unrestricted in terms of licensing.

OPPORTUNITY: The goals of GEON and the UN are closely aligned, so much so that a partnership with GEON should be pursued. GEON is similarly interested in teaming with the UN to seek funding that will allow additional nodes (and associated training and community-building activities) to be deployed throughout the developing world. GEON has very limited funds to extend its Pop node network beyond its current size, yet there has been a great deal of interest among science communities in many countries to become involved with GEON. Perhaps some kind of foundation funding, under a joint UN/GEON umbrella, would prove an effective means to get infrastructure in place prior to an urgent need.

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 72 Geospatial Technology 3/15/2006

Contacts within the GEON Community Dr. Dogan Seber, GEON Lead Geoscience PI, San Diego Supercomputer Center, University of California, San Diego, email: [email protected] Dr. Chaitan Baru, GEON Lead Computer Science PI, San Diego Supercomputer Center, University of California, San Diego, email: [email protected] Prof. Mark Gahegan, 302 Walker Building, The Pennsylvania State University, PA 16802, email: [email protected] (and a co-author of this report)

4.6.2 GOOGLE Google has greatly impacted the world of maps in a very short time with two innovative products. The first, Google Earth, uses technology acquired from the Keyhole Group to provide seamless integration of imagery for the whole globe. The second, Google Maps, provides a simple Web Mapping application (and application builder) that allows users to package Google map data for specific uses and to annotate and communicate information presented in map form. Google already effectively has the largest distributed data infrastructure ever created, and is able to index and provide access to massive quantities of digital information, including maps and geographical imagery.

A second strategy to be pursued here is to try and establish disaster- and crisis-related data collections within Google, using Google infrastructure to provide the means to both access and view the data, via the Google Earth Desktop Client. The sheer retrieval power and data replication and redundancy that the Google infrastructure already possesses, along with ease of use, are highly desirable qualities for the FIGS. At a most basic level, the use of Google Earth and Maps could begin with simply building a Google Maps application (e.g. using MapBuilder: www.mapbuilder.net [NOTE: not the same as MapBuilder (http://mapbuilder.sourceforge.net/) used in the FIGS demo]) using customized sets of labeled icons as a way to communicate between field personnel. But to become a really useful option, users need to be able to access the underlying data, so that these data can be assimilated into other geospatial tools and applications, such as GIS and image processing systems. In other words, we need a map data server, as well as a map picture server. A successful field system will require both. So, current barriers here FIGS Working Group Document: Proof of Concept and state of the art in FOSS 73 Geospatial Technology 3/15/2006

include the lack of a detailed Application Programming Interface into Google Earth (allowing it to function as a data server) and a deviation from the open GML standard adapted by Google so that it contains both geographical data and styling and presentation information, and resulting in an currently non-open and non-standard data format. We believe (from informal conversations with folks involved with Google Maps) that both of these barriers (lack of suitable API and deviation from accepted community standards) will be remedied in the medium term. Note that it is already possible to (1) embed Google Maps applications into larger applications, and (2) embed data as annotation layers into Google Earth, as exemplified by SocialChangeOnline s AIMS-4 product (http://online.socialchange.net.au/products_services/aims/). Integration with Google Earth is also demonstrated in the above evaluations (Section 4.5). Overtures to Google as part of this project have met with some recent success, in that Google have responded favorably to discuss possible collaboration. From Google s perspective, they have two things to gain. The first is publicity from being seen to help in disaster situations, the second is that they will gain additional layers of data into their collections, which will help them to improve the quality of their service. A potential conflict here may arise if local data custodians are not at liberty to release data coverages and images into the public domain (as indeed it would be if included in Google Earth). There may need to be local agreements and safeguards in place to effectively hide some data layers, which is somewhat in conflict with the business ethos of Google. These matters will need to be discussed in negotiations with Google.

OPPORTUNITY Google has requested a phone conference with this team to discuss how we might collaborate in providing crisis/disaster-related datasets. To make best use of Google technology, this project also needs access to the API used internally for map/image related functionality. (Ideally we would like access to data collections via a WFS-type service, though this may not yet be available. The key contact personnel at Google are: Noah Doyle: [email protected] Andria Ruben McCool: [email protected] Daniel Lederman: [email protected] FIGS Working Group Document: Proof of Concept and state of the art in FOSS 74 Geospatial Technology 3/15/2006

5.0 Conclusion and recommendations

Geospatial technology is becoming a critical component in disaster planning, response, recovery and mitigation. The analysis above focused on the state of Free and Open Source Software (FOSS) for geospatial analysis, their level of maturity, completeness and necessary functionality for providing essential support for disaster management. The context for this analysis was provided by reviewing how geospatial technologies have been used in two recent major disasters, the Tsunami in Southeast Asia and the earthquake in the Kashmir region of Pakistan and India. It is clear from the analysis of the documents provided to the FIGS Working Group that the integration of geospatial technologies into the disaster management process falls well short of its potential. Significant progress can be made both at the strategic and tactical levels. There is a clear recognition of the shortcomings at the strategic level as chronicled in the HIC in Pakistan, Joint Review Mission Report29 . At the tactical level, the geospatial technological requirements for the HIC disaster management are not as clearly defined. It is the intent of the Geospatial survey developed by the FIGS Working Group (Appendix A) to elucidate these requirements. This survey will need to go through several iterations and testing before it can be deployed in earnest but it provides a valuable first step in this regard. It is our recommendation that the Geospatial HIC survey be finalized and implemented.

The test environment created, integrated several FOSS components in a multi-tier configuration we call the FIGS stack . It is composed of three layers: the data tier, the web services tier and the client tier. The data tier is composed of PostgreSQL/PostGIS which forms the heart of the GeoSpatial system it is the most mature open source object/relational solution available for DBMS. Its one limitation is that it is based on the OGC simple feature specification, which has no explicitly stored topology. Without a front-end to create topology on the fly , issues associated with the integrity of the geospatial data are a factor to consider. The efficiency of the GiST Spatial Indexing of

29 Humanitarian Information Centre in Pakistan; Joint Review Mission Report 7-15 February 2006 FIGS Working Group Document: Proof of Concept and state of the art in FOSS 75 Geospatial Technology 3/15/2006

PostgreSQL/PostGIS was tested with the 1.2 million polygon data set for New York City and had no problem handling this rather large data set. PostgreSQL/PostGIS also has a powerful spatial SQL query engine that makes a solid basis for a good analytic tool for geospatial analysis though further work is needed to identify which analysis functionality is required and to develop suitable user-interfaces to that functionality. Administrative tools are impressive and comparable with what would be expected in an industrial standard DBMS. This tier is a solid foundation on which build a geospatial environment for OCHAs HICs.

GeoServer 1.3.0-PR1 was the implementation for the web services tier of the FIGS stack. It was chosen because it implements both the WFS/WFS-T and WMS functionality. For the FIGS stack we connected to both PostGIS and shapefiles. GeoServer s administration interface is excellent and well thought out. It is under active development both as a WFS-T and WMS platform. Support for a number of non-vector formats is actively being added. GeoServer enjoys an ever-expanding set of documentation, and has a number of very active developers involved, including the Open Planning Project (http://www.openplans.org/) and Refractions Research. GeoServer also supports a cache of on-board styles to be used with its WMS. A number of SLDs (Styled Layer Description documents) were developed to correspond to UN/OCHA symbology and were illustrated in the FIGS video demo (attached). GeoServer connects to a wide variety of data sources. While not as mature as PostgreSQL/PostGIS, this tier is a solid foundation on which build web services for OCHAs HICs geospatial environment. Data versioning would be a significant addition/enhancement to this environment.

Both thick and thin clients were implemented in the client tier. A Mozila Firefox Browser was used to drive a GOOGLE Earth application which tapped into the PostgreSQL/Post GIS data tier via Geo-Server WMS and returned KML via the Geo- Server in a combined thin/thick implementation. MapBuilder (thin client), an open- source AJAX-like toolkit, was implemented and tested. Several thick clients, uDig 1.06 and 1.1.1, JUMP, ArcGIS and Quantum GIS were also integrated into the FIGs stack as FIGS Working Group Document: Proof of Concept and state of the art in FOSS 76 Geospatial Technology 3/15/2006

part of the client tier. The client tier was perhaps the least mature component of the FIGs stack and lacked in sophisticated cartographic, spatial analysis and data management capabilities. The client tier needs significant development before it can realistically be used to fulfill all of OCHAS HIC operational needs. The primary weak points are in data editing and cartographic output. In the interim ArcMap or other non-FOSS clients could be used as the thick client for the FIGS stack.

Both the web services tier and the client tier have the ability to easily provide interactive kiosks at HICS, and online if internet access or a wireless bubble is available at the theater s site. Such kiosks would involve little involvement of the HIC personnel other than ensuring that relevant data gets into the Data Layer, while potentially supporting many users and relief actors.

Thin clients with simple and reliable feature editing capabilities may be the area where the most is to be gained for field-entry Humanitarian-disaster type data. Recording information relevant to assessments need not deal with complicated input. Being able to reliably record positional information along with attribute data, perhaps on a very-thin PDA client for a Real-time RVA (Rapid Village Assessment) may deliver the largest benefit for the least amount of development effort, enabling many cooperating organizations to share accurate, updated Humanitarian data in almost real-time, facilitated by a centralized database architecture integrated with the Web Services Tier.

GOOGLE Earth proved to be an exciting client for displaying HIC information through the web services and data tier. This client is particularly powerful because it has an existing global data database and geodesic framework on which to project any of the data stored in an HICs PostgreSQL/PostGIS data tier, via the GeoServer web services for observation world-wide. This would be a very effective tool for enabling headquarters to see the same data as is available in the field.

The FIGS stack, in its entirety, is not yet at the stage where it can offer a comprehensive environment for HIC geospatial applications. However, certain FIGS Working Group Document: Proof of Concept and state of the art in FOSS 77 Geospatial Technology 3/15/2006

components, such as the data tier and web services tier, could be adopted as a start. New functionality within client tiers is actively being developed by a number of different communities and projects described in section 4.3, and the active involvement of OCHA could very well shape this development effort. It is our recommendation that funding be pursued to further develop the components of the FIGS stack described in this document with particular emphasis on the client tier.

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 78 Geospatial Technology 3/15/2006

6.0 References Cutter, S., D. Richardson and T. Wilbanks editors. 2003. The Geographical Dimensions of Terrorism Routledge, New York and London. Pp. 274.

French, S., C. Niculae, 2005. Believe in the Model, Mishandle the Emergency . Journal of Homeland Security and Emergency Management. Volume 2, Issue 1.

GDIN, 1997. Harnessing Information and Technology for Disaster Management . Disaster Information Task Force Report. November 1997.

Goodchild, M., 2003. Geospatial Data in Emergencies in. The Geographical Dimensions of Terrorism Editors: Cutter, S., D. Richardson and T. Wilbanks. Routledge, New York and London. Pp. 274.

LaLonde, William OGC Styled Layer Descriptor Implementation Specification OGC 02-070

Leidner A. 2005. The Geospatial Response to 9/11: A recount of accomplishments and unfinished business. GeoWorld, September 2005.

Snowden, D. 2003. Complex Acts of Knowing: Paradox and Descriptive Self Awareness . Bulletin of the American Society for Information Science and Technology. Pp. 23-28.

URISA Exemplary Systems in Government 2002 Award http://urisa.org/ESIG_Awards/ESIG_history.htm

Van Borkulo, H. Scholten, S. Zlatonova and A van den Brink, 2005. Decision Making in Response and relief Phases .

Zerger. A. D. I. Smith, 2003. Impediments to using GIS for real-time disaster decision support Computers, Environment and Urban Systems. Vo 27, Issue 2, March 2003, Pages 123-141.

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 79 Geospatial Technology 3/15/2006

APPENDIX A

OCHA FIS Geospatial Technology and Base Map Data Needs Survey

OCHA-FIS is collecting information on the use of Geospatial technologies and base map data needs at OCHA Field Offices and HICs to inform 2006 capacity building and application development plans. We would like you to reflect on your experience and provide information for the following survey.

A. Professional Profile

1) First and Last name (optional)

2) E- mail address (optional)

The email format is "[email protected]"

3) Title(s) held (check all that apply) *

HIC Manager

Liaison Officer

Data Coordinator

GIS Officer Other

4) Skill type(s) held (check all that apply) *

GIS operator/programmer

Remote sensing specialist

Database developer/administrator

Data processor FIGS Working Group Document: Proof of Concept and state of the art in FOSS 80 Geospatial Technology 3/15/2006

Data collection/conversion specialist

IT specialist Other

5) Your HIC or Field Office Deployments *

Site 1

Position at Site 1

Site 1 start date

The date format is "dd/mm/yyyy" Site 1 end date

The date format is "dd/mm/yyyy" Site 2

Position at Site 2

Site 2 start date

The date format is "dd/mm/yyyy" Site 2 end date

The date format is "dd/mm/yyyy" Site 3

Position at Site 3

Site 3 start date

The date format is "dd/mm/yyyy" Site 3 end date

The date format is "dd/mm/yyyy"

B. Geospatial Operations

Please rate each geospatial operation you conduct listed below for frequency (Often, Sometimes, FIGS Working Group Document: Proof of Concept and state of the art in FOSS 81 Geospatial Technology 3/15/2006

Rarely or Never)

1) Data capture *

Heads-up digitizing

Scanning raster to vector conversion

Establishing P-codes for the territory

P-code assignment (geocoding)

GPS-enabled field data collection

Text entry (non-spatial attributes)

Other (specify)

2) Data management *

Multi-user GIS

Version management

GIS-DBMS connectivity

Metadata collection and entry by object (feature) class

Metadata collection and entry by object (feature)

Editing tool 1 (specify)

Editing tool 2 (specify)

Editing tool 3 (specify)

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 82 Geospatial Technology 3/15/2006

Other (specify)

3) Spatial operations *

Map overlay

Classification

Watershed analysis

Buffer zone

Cost surface

Routing

Selection by attribute

Selection by spatial feature

Interpolation of points to surface

Interpolation of area to new defined area

Projection/coordinate transformation

Other 1 (specify)

Other 2 (specify)

Other 3 (specify)

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 83 Geospatial Technology 3/15/2006

4) Cartographic output *

Scale/graticule

Legend creation

Map annotation

Adding symbolization

Selecting color/line styles

Other 1 (specify)

Other 2 (specify)

Other 3 (specify)

C. Software Tools

1) GIS software Criticality and Usage *

Criticality of GIS Software

No. of sites ArcGIS with personal database (Access) was used

No. of sites ArcGIS with ArcSDE and a DBMS was used

No. or sites ArcView was used

No. of sites Mapinfo was used

Other 1 GIS Software (specify)

No. of sites Other 1 GIS software was used

Other 2 GIS Software (specify) FIGS Working Group Document: Proof of Concept and state of the art in FOSS 84 Geospatial Technology 3/15/2006

No. of sites Other 2 GIS software was used

2) Remote Sensing software Criticality and Usage *

Criticality of Remote Sensing Software

No. of sites Idrisi was used

No. of sites ENVI was used

No. or sites ERDAS was used

Other 1 Remote Sensing Software (specify)

No. of sites Other 1 Remote Sensing software was used

Other 2 Remote Sensing Software (specify)

No. of sites Other 2 Remote Sensing software was used

3) DBMS software Criticality and Usage *

Criticality of DBMS software

No. of sites MS Access was used

No. of sites MS SQL Server was used

No. or sites MySQL was used

No. of sites PostgreSQL was used

Other 1 DBMS software (specify)

No. of sites Other 1 DBMS software was used

Other 2 DBMS software (specify)

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 85 Geospatial Technology 3/15/2006

No. of sites Other 2 DBMS software was used

4) Internet Map Server software Criticality and Usage *

Criticality of Internet Map Server software

No. of sites ArcIMS was used

No. of sites MapServer was used

No. or sites GeoServer was used

Other 1 Internet Map Server (specify)

No. of sites Other 1 Internet Map Server was used

Other 2 Internet Map Server (specify)

No. of sites Other 2 Internet Map Server was used

D. Data Needs

1) Administrative Boundary *

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 86 Geospatial Technology 3/15/2006

Criticality of Administrative Boundary data

Primary use of Administrative Boundary data

Desired scale(s) 1:1M 1:500K 1:250K 1:100K 1:50K To make multiple selections, press the "Ctrl key" and click on the items to choose.

2) Populated Places (Settlements) *

Criticality of Populated Places data

Primary use of Populated Places data

Desired scale(s) 1:1M 1:500K 1:250K 1:100K 1:50K To make multiple selections, press the "Ctrl key" and click on the items to choose.

3) Road Network *

Criticality of Road Network data

Primary use of Road network data

Desired scale(s) 1:1M 1:500K 1:250K 1:100K 1:50K To make multiple selections, press the "Ctrl key" and click on the items to choose.

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 87 Geospatial Technology 3/15/2006

4) Railroad Network data *

Criticality of Railroad Network data

Primary use of Railroad Network data

Desired scale(s) 1:1M 1:500K 1:250K 1:100K 1:50K To make multiple selections, press the "Ctrl key" and click on the items to choose.

5) Terrain data *

Criticality of Terrain data

Primary use of Terrain data

Desired scale(s) 1:1M 1:500K 1:250K 1:100K 1:50K To make multiple selections, press the "Ctrl key" and click on the items to choose.

6) Hydrology data *

Criticality of Hydrology data

Primary use of Hydrology data

Desired scale(s)

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 88 Geospatial Technology 3/15/2006

1:1M 1:500K 1:250K 1:100K 1:50K To make multiple selections, press the "Ctrl key" and click on the items to choose.

7) 30- 15 m. satellite imagery (Landsat TM) data *

Criticality of 30-15 m. satellite imagery (Landsat TM) data

Primary use of data 30-15 m. satellite imagery (Landsat TM)

8) 20- 10 m. satellite imagery (SPOT) data *

Criticality of 20-10 m. satellite imagery (SPOT) data

Primary use of 20-10 m. satellite imagery (SPOT) data

9) 5 - <1 m. satellite imagery (Ikonos/QuickBird) data *

Criticality of 5-<1 m. satellite imagery (Ikonos/QuickBird) data

Primary use of 5-<1 m. satellite imagery (Ikonos/QuickBird) data

10) Other data need (1) *

Specify

Criticality of Other 1 data

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 89 Geospatial Technology 3/15/2006

Primary use of Other 1 data

Desired scale(s) 1:1M 1:500K 1:250K 1:100K 1:50K To make multiple selections, press the "Ctrl key" and click on the items to choose.

11) Other data need (2) *

Specify

Criticality of Other 2 data

Primary use of Other 2 data

Desired scale(s) 1:1M 1:500K 1:250K 1:100K 1:50K To make multiple selections, press the "Ctrl key" and click on the items to choose.

D. Lessons Learned

Highlighting the different stages of humanitarian response operations you have been involved in, state what worked and what didn t. Your observations regarding deficiencies in software environments that inhibited your work, creation of valid geospatial data and data sharing practices will be especially appreciated.

1) Comments and observations (optional)

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 90 Geospatial Technology 3/15/2006

Critique of OCHA FIS Geospatial Technology and Base Map Data Needs Survey

In reference to the planned survey of geospatial technologies to be conducted by FIS the following comments about the survey instrument have been observed.

General comments:

1. Working with the assumption that the intended output of the survey is the identification of OCHA field office s existing capacities in terms of expertise field offices may have and to establish existing platforms and products being used. It is also assumed that the intended target audience of the survey will be OCHA IM staff in the filed 2. Based on the assumptions above it is also assumed that this survey will be used in conjunction with other survey instruments to match existing capacities with the requirements and needs of OCHA clients on the ground and thereby develop a holistic geospatial needs analysis and an OCHA geospatial field strategy. This could be in the form of an information consumer survey. 3. The survey attempts to identify the existing types of geospatial functions presently being undertaken by the field office and which platforms are used to perform these functions 4. Every section should have an explanatory note to survey users explaining the objective of the section 5. A Pre-test of the instrument should be conducted to identify if responses match desired outputs. 6. The survey results may be difficult to analyze in regards to desired outputs. Additionally based on limited sample size overall confidence in the survey data may be low and inconclusive.

Technical observations/comments

1. Overall the survey is lengthy in consideration of the intended objectives of the survey, questions can be grouped and reduced to facilitate responses and to ensure compliance. Specifically each question should be reviewed under the auspice of whether the response captures the desired intended outputs of survey. 2. a. Section A. personal -Consider requesting personal optional information at the end as this may put survey users on the defensive, additionally site locations of users may not be relevant to survey b. Section B Geospatial Operations- Questions can be more generalized and reduced, for example FIGS Working Group Document: Proof of Concept and state of the art in FOSS 91 Geospatial Technology 3/15/2006

types of Spatial output (3) can be reduced to single question Do you presently use geospatial operations to produce products for the office and if so please check all that apply. c. Section C Software tools- Identification of software tools and experience identified, however correlation with products not established. Consider using questions such as please select in order of signification the following applications I have used to produce a topographical map for my office d. Section D- Data needs Question is ambiguous in regards to if survey is requesting needs in terms of missing spatial data, or if it an inventory and prioritization survey of existing spatial data. e. Section E- lessons learned-Section should be expanded and facilitated in order to identify what work and what did not in survey clients previous experiences.

3. Consideration should be make to expand the survey to include perceived OCHA office/Client needs from the perspective of the information producers being queried in this survey. This will enable further identification of gaps when combined with an information consumer survey.

======GENERAL

No mention of sources in the survey - might be interesting to poll operators to see where they think their data sources are? I would separate the survey into different pages if possible - otherwise the size is a bit daunting for users. I assume that the asterisk * indicates a field that must be filled out - but I couldn't find any explanation for this on the survey page itself.

SECTION A

3) I would add Titles for "Database Developer" and "Web Manager", since these are common positions 5) I would make the date format mm/yyyy (for people with poor memories like me!) I would also add the option to list other HICs / other information projects, since these may be relevant.

SECTION B

1) I would add "Boundary and Settlement Verification" as one of the tasks - it's not quite the same as p-coding, but is still quite important. Q: what is "establishing p-codes for the territory"? 2) Under data management, I would make a specific query on Excel used for data management - this is usually standard in the early stages. 3) Most spatial operations seem to be included here, but I'm not expert enough to comment. It might be useful to add a field for each operation, asking what data sets each operation tends to be applied to, i.e. what analysis is performed on which data.

SECTION C

I think that for all the sub-categories here, it would be useful to ask for specific examples of use. These can then be followed up later on for case studies, etc.

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 92 Geospatial Technology 3/15/2006

1) Can we not assume that GIS Software was critical? I'm not sure how criticality will be judged or compared. I'm also not sure what "No. of sites" refers to - does it mean "No. of HICs"?

SECTION D

1) do we need to be more specific - administrative boundaries at what level? 4) Railroad is listed, but not waterways (sometimes critical). Perhaps have an expanded section on transport infrastructure? would also include airfields/ports/etc 5) Is terrain data just topography, or are you including other categories? If it's just topography, then we should call it that for clarity. 7-9) good to separate out different providers

SECTION D. Lessons Learned

This needs to be listed as E - D is already taken! 1) Most people don't fill text boxes in unless it's simple. Maybe separate boxes, with "What worked?", "What didn't work?", "What is the biggest problem in terms of field data management?", etc.

======

Will you be providing a definition of each of the headings? For example, under Data Management what do you mean exactly by Multi-User GIS? you may want to ask in the beginning which stage(s) of the emergency the staff member has worked in all of these questions could vary considerably at the different stages. And of course an IMU person vs a HIC person will most likely have quite different priorities, frustrations, etc. I doubt that Bangkok would suffer from no electricity while the field may have issues continually. Under the technology section are you trying to establish the skills a GIS officer applies in the field to help with recruitment? In Cartographic Outputs building templates is a typical function and then you don t have to make the graticule, scales, legends every single time. Creating atlases is typical although that may be noted under the other category. Also whether the output is hard, soft or both is good to know. If soft, in what format? Typical output paper size might be interesting too since determines the use of the plotter vs A4/A3. Under Software you should ask about versions, i.e. ArcGIS9, Arcview 3.2 etc and which components/modules they have/use. For example in Liberia, we had ArcGIS8 with only Arcview, no Arceditor. Also asking about extensions used will be informative I still make use of AV3.2 with certain extensions especially for editing and used ArcGIS for cartographic output due to limitations in our license. Internet Map Server would you also like to know that they are indeed serving the maps on the internet? I ask because I have used shareware to create browser based maps that were delivered on CD not on the internet. Also use ArcPublisher for interactive, non-internet based products. In my opinion far more useful to clients in the field. In Data Needs section you can bet that under desired scales everyone will put the larger scales because it s what we desire! However you may desire to know which scales are possible to work with and/or what they are working with. Lessons learned: I see that you re making Lessons Learned optional and so that tells me it s not what you re really interested in in this survey. Of course finding this information would be very useful and therefore a need to ask more specific questions.

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 93 Geospatial Technology 3/15/2006

======I ve had a chance to review the survey and contemplate my initial thoughts. Overall, I believe the survey is very good, and if you can get a representative response it would provide an excellent basis upon which to (1) plan application development and (2) to build HIC capacity/capability.

Given that these are the principle survey objectives, here are some thoughts for your consideration:

1. Professional Profile: would it be worthwhile to collect some information on the formal training in remote sensing and GIS? It would be very helpful to correlate the utilization of geospatial technology with the education that staff have obtained prior and during their deployments.

2. Geospatial Operations: the types of operations listed are neither comprehensive nor mutually- exclusive, and may have multiple meanings to respondents. If the survey cannot be beta-tested, it might be worthwhile to hyperlink each operation type with a short definition/description to minimize confusion. The list of geospatial operations also excludes image analysis operations, such as orthorectification, fusion, multitemporal/multiband merge, etc. (I presume that if HICs have ENVI/ERDAS/etc licenses, they would be manipulating raster image files before exporting them to their GIS software.)

With respect to the list of Spatial Operations (section 2.3), here is an alternative way to list GIS operations. Paul Longley et al in their book "Geographic Information Systems & Science" (Wiley & Sons: 2001) proposed that types of geospatial analysis falls under the following general headings: 1. Queries & Reasoning - no changes or additions to the database...just simply and well-defined queries such as "how many shelters in this district?" or "how many warehouses are within 1 km of this airport?" 2. Measurements - simple numerical values which describe the data, e.g length or area of an object or the distance between two objects, eg. "what is the distance between Islamabad and Muzaffarabad?". 3. Transformations - changes to the database and creation of new datasets, using geometric, arithmetic and logical rules....eg. raster to vector conversion, vector to raster conversion, buffering, polygon overlays, etc. 4. Descriptive Summaries - no changes to the database. A statistical analysis of geospatial data that capture the essence of an entire dataset, e.g. calculating centroids, generating scatterplots, measuring fragmentation or spatial dependencies. 5. Optimization - analysis of the data to select the best location(s), path(s) or route(s) for certain well- defined criteria. Point optimization using Minimum Aggregate Travel (MAT) could be used by HICs to located relief distribution centers. Path optimization could be used to plan a corridor along which to lay fibre optic cable or power lines. Route optimization could be used to plan the fastest or least expensive option for visiting a series of points along accessible roads. (Note that path optimization is done over a continuous space within certain restrictions, but route optimization is based upon a network of defined route alternatives) 6. Hypothesis Testing - analysis of a limited data sample which allows generalizations of potential interventions or events, Very sophisticated and data/modeling rich applications that are designed to answer "what if" questions, such as "what is the impact of an cholera epidemic in this disaster-affected region over 24 and 72 hours?". I may go even further and suggest that the above are simply forms of geospatial analysis, not operations, since operating a GIS includes data collection, input, editing/preparation, maintenance, and manipulation (i.e. actual analysis). The core purpose of geodatabases is to streamline this process, and to support data sharing .it would be helpful to capture this dimension in the survey if you can. 3. Software Tools: This purpose of this section was unclear to me: does the criticality and usage of software indicate HIC staff member preferences, or is it a proxy of the importance of each type of software to delivering essential products & services? (Also note that useless is incorrectly spelled on the pull-down menu). If this section is simply intended to take an inventory of HIC software by location and type, perhaps that could be done more efficiently through direct inquiry of HIC managers - the survey could then be used to ask respondents about their most/least favored software, why they like certain packages over others, pet peeves, etc, etc.

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 94 Geospatial Technology 3/15/2006

4. Data Needs: Although desired scale originates from the traditional hard copy manner of displaying geospatial data, in a digital environment what tends to be more relevant is the spatial accuracy of the data itself, since the data can be displayed at any scale. Therefore, it would be interesting to understand what HIC staff believe to be the minimal spatial accuracy of base layers in order for them to be able to confidently undertake geospatial analysis and to meet user expectations. For example, irrespective of whether the final plot is made at 1:10K or 1:25K, does the location of a wadi (i.e. seasonal river) need to be within 10 or 25 m of where it actually flows, in order to anticipate a flood zone and plan accordingly?

Appendix B: Simple Database Load Script (DOS) rem UN OCHA SCHEMA CREATION SCRIPT rem @ECHO OFF set OUTDIR=C:\Pakistan_Data\extract set DATADIR=C:\Pakistan_Data set HOME=C:\ \UN_OCHA_PROJECT\Database_operations set POSTGRES_BIN=C:\"Program Files"\PostgreSQL\8.1\bin set LISTFILE=FILES cd %DATADIR% echo %DATADIR%\%LISTFILE%

FOR /F %%f IN ('TYPE %DATADIR%\%LISTFILE%' ) DO echo %%f

FOR /F %%f IN ('TYPE %DATADIR%\%LISTFILE%') DO %POSTGRES_BIN%\shp2pgsql -c - I %DATADIR%\%%f.shp %%f > %OUTDIR%\%%f.sql

FOR /F %%f IN ('TYPE %DATADIR%\%LISTFILE%') DO psql -d postgres postgres -f %OUTDIR%\%%f.sql cd %HOME%

Appendix C: JUMP Evaluation:

Editing this is mature, and recommended by Paul Ramsey at Refractions as the most full-featured FOSS editor.

- creating a layer. FIGS Working Group Document: Proof of Concept and state of the art in FOSS 95 Geospatial Technology 3/15/2006

- Editing a layer o Adding points o Adding lines o Adding Polygons - Symbology o Much more sophisticated than uDig probably enough to do most tasks o Does not cuurently support non-default icons.

Editing capability: Elaborate has actual capability (versus, for example, current uDig).

Select features, select parts, select linestrings, move selected items, draw rectangle, draw polygon, draw linestring, draw point, insert vertex, delete vertex, move vertex, snap vertices, snap vertices to selected vertex.

Editing options: snap to grid, check geometries, snap to vertices and lines, prevent edits resulting in invalid (OGC SFS) geometries (list), snap vertices tools, ability to edit

Transaction model: Has Undo/Redo (ie, rollback) not sure how many levels.

Note: Feature Info Selection capability is more advanced 6 modes:

As table, Show geometry as: -Well-known text (SFS) - GML - CL

Show attributes on/off FIGS Working Group Document: Proof of Concept and state of the art in FOSS 96 Geospatial Technology 3/15/2006

Show as table:

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 97 Geospatial Technology 3/15/2006

Note also the capabilities of the JUMP Java Conflation Suite, which may be applicable to Administrative District alignment and change problems.

FIGS Working Group Document: Proof of Concept and state of the art in FOSS 98 Geospatial Technology 3/15/2006