Mapping prototypes - Design criteria

The primary goal of the DFM Maps Group will be represent information about dried fish value chains through static or interactive maps, depicting significant sites as well as flows of commodities and people between those sites.

Given that we are working primarily from unstructured datasets, a primary challenge will be to support the tagging, consolidation, and querying of geographic data embedded within diverse sources -- including interview transcripts, fieldnotes, reports, and spreadsheets.

Although we would like to accommodate the creation of professional maps based on data supplied by project researchers, a more important consideration is that researchers with limited technical skills should be able to develop and edit simple, reusable maps themselves.

General criteria

1. Standard, open source tools and workflow. All maps should be editable and usable with open-source tools and open-access datasets (e.g., Leaflet.js or similar tool to represent interactive maps, using OpenStreetMap layers for the base layer).
2. Geographic tagging. Researchers should have the ability to associate documents or document fragments to geographic places (countries, regions, markets, etc.) for representation and querying in interactive maps. Geographic tagging may occur through one or more of the following processes:
   • Qualitative Data Analysis of field data (coding in Atlas.ti)
   • insertion of geographic terms as metadata within individual documents hosted by DFM, such as reports or pages on the DFM wiki, for automated indexing
   • manual creation of lists or a database of URI references pointing to publicly accessible documents, within or outside DFM control, that relate to a specific geographic term
   • tagging of resources in the DFM Zotero library (Zotero items can also be referenced by URI).
3. Visual navigation of online resources. It should be possible to use an interactive map interface to navigate publicly accessible documents tagged for the place or region in focus, filtered by feature type. For example, if we have a set of online transcripts of interviews conducted in different markets across Asia, users should be able to retrieve the list of matching documents for each market by clicking on a corresponding map marker or through a similar action, then click through to the matching documents.
4. Simple value chains mapping interface. Ideally there is a very simple online interface that researchers can use to generate a simple map to visualize data on value chain points or flows, by selecting values in a basic configuration form (to set map scale, boundaries, etc.) and identifying a data source or query. We may also support additional settings that would allow advanced users to manipulate map layout prior to publication, and/or allow export to a professional mapping application.
5. Simple, extensible tabular data. The source data used to generate each value chains map should be stored in basic tabular format, editable by non-technical users. For example, in the simplest instance, we could have a tabular array with just two columns -- place name and annotation -- which can be parsed to generate an interactive map with markers and labels or pop-up descriptions, by looking up the coordinates for each place name in a separate database. More complex maps could draw on more complex tables, in which each row represents either a single point or a flow between two distinct points, with additional columns providing data corresponding to the marker type, flow volume, etc. The main criterion in this case is that non-technical users should be able to create, view, and edit data tables as easily as possible. These data tables should remain editable -- we do not want to convert them permanently to a more sophisticated format like GeoJSON, for example, even though such a conversion may be part of the map generation toolchain.
6. Tabular data can be embedded in unstructured documents. When generating maps, we should be able to accept input data provided in the form of tables within an arbitrary html document or similar. (We could also support docx or other formats, though these are already being converted to html for publication on the DFM wiki.)
7. External mapping to coordinates. In most instances, we will want to use normalized place names (e.g., “Cambodia”, “Phnom Penh”, “Tonle Sap Lake”) for data entry, rather than raw coordinates. These could be looked up against a published data source. In some cases, users will need to be able to enter custom coordinates for points that do not currently exist in any database (e.g., the site of a particular market or boat launch, or the temporary location of a floating village).