ARCHIVE:  REMAPS

The following article on REMAPS was written by David Baxa, Vice President, VISTA. For questions and comments on REMAPS, please contact David at (703) 561-4067, or via e-mail at david.baxa@vistait.com.

In response to a UN Department of Humanitarian Affairs (DHA) request at the Second ReliefWeb Conference in Washington in 1998, the US Department of State coordinated the development of a prototype for a standard field-based mapping software application for relief workers, called REMAPS (Relief Emergency MAPping System). The prototype was demonstrated in displaced persons camps near Khartoum, in South Sudan in 1998-2000, and to NGOs in North America such as the International Medical Corps and Doctors Without Borders. The prototype application was also demonstrated at the 1996 ReliefWeb Conference and the 1997 US Institute for Peace Virtual Diplomacy Conference in Washington DC, where it was very well received. Out of these initial discussions, and others more recently, has grown significant interest in the relief community in the concept of dedicated GIS products for relief operations, which was the goal of REMAPS.  Some of the best such products are developed by ESRI. 

Although it was a project in support of ReliefWeb and GDIN, REMAPS iwas a US government/GDIN experiment. This effort was being developed for consideration of the UN Office of the Coordinator of Humanitarian Assistance (OCHA), a successor organization to UNDHA. It was strictly an experimental initiative and  the United States government did suggest that OCHA develop a portable computer-based mapping and database system suitable for use by those providing humanitarian assistance, as well as enhance its own GIS on-line capabilities.)

Try to imagine yourself as a relief worker just sent to a crisis zone. In front of you are maps showing the country to which you are traveling and briefing papers describing the situation as of eight hours ago when you got on a plane with relief supplies and a mandate to help. When you arrive, you discover that outside the airstrip is a brand new camp with 200,000 refugees. You are flooded with new information, so many people have a particular disease, the water supply will only last five days, and so on. You are told that a fresh source of water has been discovered and that to get to it, one must go over a road that doesn't exist on your maps! Driving along the road, you come across an unexploded bomb in a ditch near a village that also is not on your map and the people in the village do not like those in the refugee camp. You then learn that a relief worker from a different NGO has seen the village and has written a report on the inhabitants. How would you report your information back to your HQ? Where would you find the report on the village inhabitants? How will you report all of your findings in a way that is most useful to and can be shared with all organizations helping to resolve this crisis?

ReliefWeb and sites like it can address some of these questions (if you have a satellite uplink or perhaps an HF radio), and ReliefWeb has developed a way to regularly update users by email. But, what if you have no link to the outside world other than a weak radio or a truck that could take your report on a floppy disk to an airstrip where it could be flown to a place with internet access?

Although the Internet is a powerful tool, until we get full compliance with the Tampere Convention, it is not necessarily a practical tool for sharing information in many field situations. Relief workers in South Sudan, for example, do not have access to the internet outside the village of Lokichokio. Further, relief workers need a tool to help them log information and package it in a way that is both sharable and directly useful to them and to their headquarters, as well as, to others in the UN relief community. Workers with no internet access and those with access but little money for extended connection time, should find value in this idea. The REMAPS concept is to develop a portable map-based application to serve users with no direct Internet link who must use it in a stand-alone configuration. At the same time, a web version of the application, with a very similar appearance and functionality could be developed for users who have direct access to ReliefWeb and other disaster sites.

In its final form, REMAPS would allow field workers to use a notebook computer to map their operations, add data to maps, view images and other useful operational information. The user would be able to conduct data analysis and provide linkages to the Internet. REMAPS is intended to illustrate the practical utility of a simple map-enabled software kit whose suggested content is based on advice from such organizations as Doctors Without Borders, along with many other NGOs, international organizations and governments. The intent is to make information interoperable, because specific categories of data would be collected according to common rules and then placed in files according to a common format. That way, vital relief information could be posted on a centralized repository such as ReliefWeb and would be easier to use by a much wider audience than is currently the case. The demonstration prototype form of REMAPS is was designed to illustrate an ability to add information to existing maps (i.e. new villages and roads) and to describe their current condition. The proposed system would also allow users to use the map to do analytical work, for example, showing the pattern of disease or the movements of refugees, planning when to move food and medicine, and determining which locations pose the least threat to the delivery of supplies or the staging and care of refugees.

Relief information is often gathered on an ad hoc basis, frequently redundant, and of an inconsistent quality. Not enough common data standards exist and there is disjointed cooperation between various organizational headquarters, though field cooperation among NGOs and others working in a relief situation generally is good.

A common data gathering software application could help standardize information, thus making it easier to use by more organizations. By providing such a standard application, relief workers could begin to generate data in consistent ways. That works to everyone's advantage.

Cooperation among relief organizations concurrent with the development of REMAPS is the best means to establishing sound standards. Cooperation now can promote wider access to better data and help keep equipment and software costs to a minimum in the future. Current efforts to promote data standardization as part of GDIN will also help satisfy this need.

The primary use of the REMAPS application is envisioned to be as a stand-alone tool for field personnel to gather and update data, analyze a situation, and develop alternative actions. As a means to exchanging information between relief organizations, ReliefWeb could be the repository for all REMAPS data and offer a REMAPS interface so that a humanitarian assistance organization could download or query the most up-to-date information available.

An important ingredient of ReliefWeb's success and the early design of GDIN is based on the premise that a majority of users will have low-cost, efficient access to the Internet. However, not all users have such Internet access. In fact, many potential users of (and contributors to) the ReliefWeb information repository must, of necessity, work at the forefront in an emergency situation where basic living conditions are rudimentary, harsh, and often hostile.

Consequently, these users often do not have ready and cost-effective access to ReliefWeb or GDIN via the Internet. Even with recent advances in worldwide reach and effectiveness of telecommunications technology, it is not reasonable to expect that users at deep field sites will have on-line access because of the exigencies of a typical relief field site.

This shortcoming can be addressed by implementing alternative means of providing for the exchange of information between field sites and higher headquarters with internet-based libraries. An approach to support this missing link is to provide a mapping and database application system based on portable notebook computers with CD-ROM drives and GIS technology.

The objective of REMAPS would be to develop a basic set of enabling tools and processes for humanitarian relief mapping and information gathering, consisting of a database subset (including digital maps), a user application, and the necessary hardware and software needed to operate under rudimentary conditions in a remote, potentially hostile environment.

The REMAPS package would include a custom application for accessing data and displaying and analyzing it on a digital map. Much of the data contained on the system could be extracted from ReliefWeb (including maps, narrative reports, reference documents, and statistical data), NOAAÕs home page, or the home pages of various National Disaster Information Network sites(NDINs)Ñtailored for the particular locale where the system is to be deployed.

As a side benefit, a standard system that operates on a stand-alone portable notebook computer in the field could also help resolve critical information management problems by giving relief workers an easy method for accessing core data in a consistent format. REMAPS would be of even greater value if the relief worker could display the data in a meaningful chart or map and then create a prepackaged report that could be sent to higher headquarters by floppy disk or Email.

Neither the UN nor the NGOs could afford a system like REMAPS that would rely completely on satellite communications technology. Furthermore, in many cases, until the Tampere Convention is fully implemented, local authorities may not allow such satellite linkages. Even if money were available and there were no conflict with local authorities, satellite links may not be appropriate for downloading large images or running complex database queries. The use of CD-ROM technology coupled with the use of floppy disks and/or high frequency (HF) radio voice communications could provide a practical alternative to satellite links to relay information to and from both deep field and mid field sites. Thus, such a software package, properly configured, has the potential to provide off-line mapping, as well as, a vital link between remote sites and the larger relief community.

It is envisioned that both the data and the software application would be distributed on CD-ROM and regularly updated by OCHA or other disaster organizations. This way, relief workers in the field would have a CD-ROM-based portable system to access maps and information needed to support their ongoing relief operations.

In addition to the portable version that supports the relief worker in the field, the concept for REMAPS includes a web server-based version of the same application that would be readily accessible by users in the relief community who have regular access to the internet. This means that such users would be able to retrieve, display, and print information in the ReliefWeb or other central repository in the same manner as those who are using the system in the field.

It should be noted that the version of REMAPS accessible on a server such as ReliefWeb or GDIN would initially be "read-only" data that can be queried or downloaded, but not edited. Editing will only be done using the stand-alone version of REMAPS designed for use in the field. Once edited, new data can be E-mailed or sent by floppy disk to the central repository for posting to the web-site itself. Later, as the field version is finalized and REMAPS is ready to be deployed and used on a wider scale, the internet server version of REMAPS will be opened up to on-line editing to facilitate its full use by those with consistent internet access.

Further, through the establishment of country teams and in-country information centers at field headquarters and mid-field sites to support relief operations, or perhaps by using existing disaster centers like WHOÕs draught center in Harare, it would be possible to facilitate the exchange of vital data to and from field sites and internet-based repositories. The functional responsibility of these teams and centers could be to regularize the timely posting of field data and the distribution of updated CD-ROMs to the field sites. The centers would maintain a satellite link and a systems operator to act as the communications clearinghouse, enabling the data repository to be kept up-to-date with relief conditions as they change over time.

Using the information center concept, deep field sites would radio time critical data (i.e. road wash-out, explosive hazards, etc.) to the mid-field sites which would maintain hazard and road condition information. The updated information would be immediately available to all with radio capability, but it would also be E-mailed to information repositories through the center to assist those planning missions locally. Information that is not time-sensitive could be recorded on a floppy disk at the deep field site and sent to the information center via the regular rotational flights and subsequently E-mailed to the central repository. It could also be kept on the information center computer to help those planning missions locally. REMAPS, under this concept, is the data gathering process and repository for vital relief information. Not only is REMAPS able to record the data but it also provides a common format to make data more valuable to planners and those aiding in relief operations.

Since the core REMAPS system is intended for use at deep field sites for humanitarian relief operations, it needs to run on portable notebook computers that are appropriate to these situations. While the system should also be able to run on fairly standard desktop computers as well, the lowest common denominator as far as a hardware environment is concerned would be a stand-alone IBM-compatible portable notebook computer running MS Windows9x.

This computer should have at least a Pentium-class 400 MHz processor, 32 MB of RAM, 4 GB hard drive, color display, a 24X CD-ROM player, and a 3.5 inch floppy drive. While a modem or other communications hardware would not be essential for operation, it would be needed if the user wished to take advantage of direct linkage to ReliefWeb or other data repository or to use the ties to E-mail capability.

The REMAPS application is intended to be a display, analysis, and reporting system that will be easy to use and compatible with ReliefWeb. The functional requirements to develop such an application are listed below. These describe the ultimate form and features of the REMAPS application once it has been fully developed.

1. The field-based version of REMAPS should provide basic query, data update, display, and reporting capability based on the data extracted from ReliefWeb. It should include data access and mapping tools that are operationally practical and designed for the relief community, allowing the display and analysis of data on a digital map. The web-based version on ReliefWeb should have the same look and feel and provide similar functionality, except it would not directly support data updates.

2. The application should be designed with an intuitive user interface that requires only a web browser for access. The objective should be to provide an application that can be readily used by those with only rudimentary computer skills and a minimum of training.

3. The application should have the ability to retrieve and present spatial data (points, lines, polygons, etc.) in a GIS environment along with geographically-referenced character and image data. The application should make maximum use of commercially-available off-the-shelf (COTS) GIS technology in order to keep software development costs down.

4. The application should make significant use of pull-down menus, pick lists, check boxes, buttons, etc. to minimize the volume of keyboard entry required to build a query, retrieve data, select a display, or generate a report.

5. The application should be able to integrate map retrieval, data entry, statistical analysis, word processing, bibliographic research, and Email connectivity into one relatively seamless package. For instance, the user should be able to spin out to an Email utility to send messages and documents to other individuals in the relief community or query them for information not in the REMAPS database. As part of this capability, the system should provide the capability to access a suite of pre-defined relief networks (ReliefWeb, Hazard.Net, etc.) and the ability to Email reports to user selected addresses.

6. The application should be able to access a special library of essential reference documents as contained on the CD-ROM, using geographic or other key word search criteria.

7. The application should be able to tag sensitive data and/or reports that are to be maintained on the user's computer and not transmitted or otherwise conveyed to ReliefWeb.

8. The field version of the application should be able to overlay ReliefWeb maps and other spatial data with new and/or additional information based on the observations of persons in the field (i.e. new refugee camps, location of new explosive hazards, updated road conditions, etc.) In other words, field personnel and headquarters staff should be able to create or amend operational maps in an intuitive manner with minimal training.

9. The application should provide the user with the capability to easily create a variety of graphs and charts based on repository data contained on the CD-ROM.

10. The application should provide a facility for capturing data updates generated in the field either by posting them directly to ReliefWeb via a telecommunications connection or by saving a file to the userÕs floppy drive for later use by a ReliefWeb Information Center to post it to ReliefWeb.

11. The application should allow the user to create statistical reports for distribution to the relief community (via ReliefWeb) or within a userÕs own organization (i.e. to higher headquarters).

12. Ultimately, database structure and application should be flexible enough to allow some supplementary data (i.e. additional data fields, a memo or narrative report, etc.) to be added to the database even though this data was not specifically planned for in the original application.

13. The application should be flexible enough so that the selection of certain data for inclusion in the data extract from ReliefWeb (i.e. maps, scanned images, situation reports, etc.) can be tailored for the locality where the system is to be deployed. For example, a different data set may be "packaged" and distributed for users in Africa as compared to users in Southest Asia or Central America. Further, there may be slight differences in the data sets for users in Southern Africa compared to West Africa.

14. Initially, the application should be developed exclusively in English, as it is the most common relief language. As the relief community needs require and as funds permit, the application is envisioned to add on shells in other languages, such as French.

15. The field version of the application should be designed such that it will fit on one CD-ROM along with the data extracted from ReliefWeb to support deployment to the field.

16. The application should allow the user to query the database through a map display for essential information (e.g. disease information) that might be relevant to a specified coordinate or polygon or to a specified data element.

17. The application should allow the user to describe new information to be added to the database and to either add its exact location (i.e. coordinates) or, if the exact location is not known, to provide a general location, such as an approximate polygon on a digital map.

18. The application should be able to display images that are stored in one of several commonly used file formats (e.g. .bmp, .jpg., etc.). This would facilitate the attachment of photographs, satellite images, or scanned hand-drawn diagrams of villages or runways to a particular point on a map.

19. The field version of the application should allow the user to easily mark the movement routes of refugees, displaced persons, supply convoys and other typical relief movements and overlay these routes on maps showing related information such as the location of water sources.

20. While not an immediate requirement, the field version of the application should be designed to allow a connection to GPS receivers for determining the position of points, lines, and polygons that need to be added to the database. Similarly, the application should provide for an interface with a digital camera so that photographic images can be directly captured into the database.

21. The application should provide the ability for the user to readily prepare thematic maps, representing data on a map using colors, fill patterns, line types, symbols, and graphs.

22. The application should provide the capability to encrypt certain sensitive information that is stored on the CD-ROM or sent out via telecommunications or floppy disk, making the reading of such data difficult without a proper password.

23. The application should provide the user with a standard set of tools to report on relief matters in a uniform way by providing core fields of data that must be entered in a pre-designated format. For example, when reporting on runways, a standard set of fields might include coordinates, name, communications frequency, elevation, surface, runway diagram, etc.

The REMAPS application should be initially developed, consistent with established priorities and available funds, for a pilot program with one or two NGO's at a single humanitarian relief location. (Under strong consideration at this time is to pilot REMAPS in the South Sudan under the auspices of the International Medical Corps.) For the purposes of the pilot program, the NGO would have access to REMAPS at various levels within their hierarchy (both field sites and headquarters). ReliefWeb would be responsible for maintaining the overall data repository, and for enforcing data standards. The REMAPS application developer would be responsible for:

• Maintaining the application software and version control;
• Packaging the application and data extracts on CD-ROM and distributing to target users;
• Initially installing the application and training the users; and
• Providing on-going user support (via Email) during the pilot program period (3-6 months).

This draft is based on comments collected over the last 36 months by a wide range of organizations such as Delorme, MapInfo, VISTA/GAC, Doctors Without Borders, International Medical Corps, the Red Cross, and many other organizations. No statement here is intended to represent the views of any one organization.

ReliefWeb
The worldÕs premier electronic clearinghouse for those needing timely information on humanitarian emergencies and natural disasters Ð designed specifically to help the humanitarian community improve its response to emergencies. Contains daily information updates on more than 40 humanitarian emergencies. Find out more...

An example of REMAPS for South Sudan
Click here to see an evacuation map (~1.6 M image) built by the software based on hypothetical data at Gogrial, South Sudan. The map was used to demonstrate how to solve the following problem. What would you do if you learned that a group of people was leaving point A for B because an outbreak of EBOLA occurred at point A? In less than five minutes, REMAPS told the user where air strips were in a designated area, which roads were mined, where the NGO's are and if they have vehicles, how to call the NGO's and where land mines might be. In addition, it allowed the used to map out a flight route for the displaced persons. The result is the attached map, which can be easily emailed or placed on a floppy, along with a narrative report. Behind the map is all the analysis that went into the development of the map. The entire package can then be sent to HQ, posted on ReliefWeb or be printed out for field staffs.

Click here to DOWNLOAD REMAPS DEMO!
This demo is currently available only in an IBM-compatible version, and can be downloaded to your hard drive as an .exe file, which must be clicked on to install onto your computer.