Eko: Geospatial Data Collection

From a Survey to Usable Data

Eko supported data collection for organisations and government agencies in Lagos, Nigeria. Collecting an answer was one part of the workflow. The application also needed to know which survey it belonged to, who submitted it, and which location or organisation the survey concerned.

I worked on the backend at FindWorka. I built APIs for creating surveys and collecting responses, along with database queries that made those submissions available to lists, summaries, and activity reports.

Letting Surveys Change

A survey’s questions were stored as records, with a field type, label, required flag, and answer options. I built the creation and editing workflows around those definitions, so different surveys could carry different sets of questions.

Editing brought a specific problem: an existing question could be updated, but a newly added question had no matching record to update. I extended the field-saving logic to create a record when it did not find an existing field. Existing-field lookups included the survey identifier, keeping the update tied to the survey being edited.

Location was part of the survey’s context. I worked on the relationships connecting surveys to locations and locations to local government areas, and later added a radius field alongside the stored coordinates. These records gave the collection workflow a geographic reference.

Showing Collectors Their Work

Collectors needed a list of surveys relevant to them. I added queries that retrieved their assignments and combined those results with their existing responses to mark each survey as filled or unfilled.

That distinction mattered in the interface: an assigned survey and a completed survey are different states. Returning completion information with the survey list gave the client the data to show both.

I also worked on submission validation, connecting responses to the authenticated collector and checking their survey assignment. The checks covered individual submissions; they did not establish how simultaneous requests would interact.

Getting the Relationships and Reports Right

One bug came from how the application represented survey responses. A survey could receive responses from several collectors, but its data model described only one response. I changed that mapping to a one-to-many relationship while fixing duplicate survey results. The association needed to reflect the data the application actually collected.

I also wrote queries for submission totals, collector rankings, and activity charts. I filtered and grouped the records in the database so the API could return aggregates for the chart instead of sending individual responses for the client to count.

Response lists used pagination, while survey lists included completion information. These served different needs: browsing collected records and helping a collector decide what to fill in next.

Following Through on Bugs

I continued maintaining these workflows as the application changed. Alongside the survey-field and relationship fixes, I added a guard for a missing survey before attaching its fields. That let the controller handle the missing record instead of failing while building the response.

I also added HTTP request logging to help trace failed requests and understand response times. Together with application monitoring and bug investigation, this gave me concrete information to work from when something went wrong.

The Eko360 website shows the wider platform today. My contribution here was to the survey and data-collection backend at FindWorka.