ODK is an open-source tool that allows users to build forms for data collection using either a mobile app or a web app. Data collection can include GPS locations, photos, numerical values, categorical data, etc., and can be collected offline, with synchronization occurring once an internet connection is available. The gathered data can be sent to and retrieved from a server called Central, either using ODK Cloud services or a self-hosted infrastructure.
This guide outlines the quick setup of forms on a Central server to make them accessible to different app users, whether via a mobile app or a web app. The guidelines include a description of how to conduct field observations and later access the data through the Central server or an API that allows querying and loading data locally.
The workflow is built using available documentation from ODK Docs and online tutorials from the ODK YouTube channel. This guide does not cover the installation of the Central server on own infrastructure or its setup using ODK Cloud services. It assumes that the Central service is already deployed, tested, and fully operational.
For more information on setting up the Central server, visit the official documentation.
ODK forms are created using spreadsheets (e.g., Excel or Google Sheets) following the XLSForm standard. The process is intuitive, as users can easily add ODK form fields in a table, where they can define associated survey questions, answer restrictions, linked questions, data types, and more.
ODK provides a template in both Excel (ODK XLSForm Template) and Google Sheets (ODK Google Sheets Template) that can be filled out with the form requirements and later uploaded to the Central server. The template has multiple sheets, the majority with complementary information to fill out the template. The most important sheets for the basic set up are the ‘survey’, ‘choices’ and ‘settings’ tabs.
The ‘survey’ sheet is structured as a table where each row represents a field in the form. Taking as example the third form element in the Table 1 (row 4), we can see that the data type, in this case, a geopoint or GPS position, is defined in the ‘type’ column, the field name is specified in the ‘name’ column, and the field question or text in the ‘label’ column. Additional text providing details about the question or requirements of the field is added in the ‘hint’ column. Finally, in the ‘required’ column, we can indicate whether the field is mandatory in the form.