GeoJSON vs CSV for a WASH asset inventory: which one fits your workflow

You've just agreed on a satellite pass over your district, and the vendor asks how you want the output delivered. GeoJSON or CSV. If you've never had to choose before, it feels like a technical detail someone else should decide. It isn't. The wrong choice means your GIS person spends an afternoon converting files instead of loading them, or your M&E officer can't open the export at all.

The two formats hold the same information differently, and that difference decides which one fits how your team works day to day.

What's inside each file

A CSV is a plain table. Every borehole, tank stand or latrine block is a row, with columns for an ID, a name, a latitude, a longitude, maybe a condition note and the survey date. Open it in Excel, Google Sheets, or any field data tool, and you see exactly what's there. No special software needed. This is the format you already know from DHIS2 exports and old handpump surveys.

GeoJSON is a text file too, but it's structured as geometry plus properties, built for software that understands spatial data. Each point carries its coordinates as a single location object, paired with the same attributes a CSV would hold. QGIS, ArcGIS, Kobo's map view and most web mapping tools read it natively and plot every point correctly the first time, with no guessing about which column is latitude and which is longitude.

When CSV is the right call

If your district office runs on spreadsheets, if the output needs to go straight into a reporting template, or if someone on the team is going to eyeball the list and flag entries by hand, CSV wins. It opens on any laptop in the regional office without an install. You can sort by sub-county, filter out anything flagged "latrine block" to hand to the sanitation team separately, and paste a column straight into a funder report. The tradeoff is that coordinates sit as two plain numbers, and if a column header gets renamed or reordered during an export or import, your mapping software may misread which number is which, and points land in the wrong place on the map. It happens more often than teams expect, so always check a spot sample after any CSV import before you trust it.

When GeoJSON earns its keep

Once the inventory needs to sit on top of other layers, administrative boundaries, your existing borehole register, a drainage network, flood risk zones, GeoJSON is the format built to plot correctly without manual fixing. It loads straight into QGIS as a working layer, keeps geometry and attributes locked together, and plays nicely with most open-source WASH mapping tools your sector already uses. If your GIS desk is building the district's master asset layer, or if the output is going into a web map for partners to view, ask for GeoJSON from the start. Converting a CSV to points after the fact is possible but it's an extra step, and it's one more place for a coordinate mix-up to creep in.

Plenty of district teams end up wanting both: GeoJSON for the GIS desk, CSV for everyone else who just needs the list. If that's your situation, say so when you place the order rather than converting one into the other after delivery. A clean export in both formats costs the vendor almost nothing extra; a conversion done badly in a rush costs you a field trip to the wrong coordinates.

One more thing worth checking before you commit to either: does the export include a survey date on every point? A list of boreholes with no date attached tells you what was standing at some unknown time, which isn't much use for planning which sub-county to visit first. A point inventory pulled from one annual satellite pass solves that by dating every feature to the imagery it came from, and handing it over as either format, so your team can start planning site visits instead of reformatting files first.

If you're planning borehole and latrine coverage for an under-mapped district, it's worth seeing what that inventory looks like before your next field season.