You don't need a geography degree. You might need to stop opening the wrong software.
There is a specific kind of meeting (you've been in it) where someone shares a screen with a shapefile open in Excel. Columns of coordinates, a baffled room, and a project manager saying "can we just put this on a map?" The answer is yes. It has always been yes. Getting there, however, requires navigating a small industry of tools that each assume you are either a cartographer or a JavaScript developer. Most of us are neither.
This is not a tutorial. It's more of an honest accounting of how people in the field actually end up doing spatial analysis: M&E officers, programme coordinators, research analysts, the occasional very organised logistician. I've been on both sides. The person frantically georeferencing in the field, and the person explaining to a donor why their pretty map has a small administrative unit misclassified as ocean.
The GIS world has a problem. It rewards people who already know GIS. QGIS (free, open-source, genuinely powerful) has an interface that looks like someone tried to fit a cockpit into a laptop screen. ArcGIS (expensive, corporate, also genuinely powerful) has an interface that feels like it was designed by committee in 2008 and gradually improved by further committees. Both tools are excellent. Both tools will make a new user feel like they are bad at maps.
The honest thing is to say: you probably don't need either of them for most tasks. A large share of what happens under the label "GIS work" in humanitarian and development contexts is really just: join a dataset to a geography, make a choropleth, export a PDF. That's it. For that job, you have options that won't require you to understand projections before breakfast.
Approximate positioning. Your mileage will vary depending on whether you have a GIS team to ask. The "sweet spot" region represents tools where the effort-to-output ratio is reasonable for occasional practitioners.
The figure above is deliberately approximate. Capability is hard to measure and depends entirely on what you're trying to do. If your analysis involves network routing, raster algebra, or anything with the word "topology," you'll eventually need the heavy tools. But if you're making thematic maps for a situation report, you can probably stay in the lighter tier and sleep better.
Here is the thing that trips up most non-GIS people when they first encounter spatial work: the map is the easy part. The data is the hard part. You can have a beautiful Leaflet map set up in an afternoon. Getting your Excel spreadsheet of health facility locations to align correctly with your administrative boundary files is a different matter entirely. That can take a week, depending on how the data was collected and who named things.
Coordinate reference systems are the first surprise. A GPS point collected in WGS84 (the default for basically everything) looks identical to a point in a local projection, right up until you try to overlay them. At that point one of them ends up in the sea near Madagascar. This is not a hypothetical. I have seen it. The facility was in Chad.
"The map is the easy part. The data is the hard part. You can have a beautiful Leaflet map in an afternoon. Getting your Excel sheet of facility coordinates to align with your admin boundaries is where the week goes."
The second surprise is naming inconsistencies. Administrative boundaries are political. They change. They are spelled differently across datasets. The district called "Bahr el Ghazal" in your Health Management Information System is called "Bahr El Ghazal" in the UN OCHA shapefile and "BEG" in the government dataset that your M&E team has been using for three years. Joining these requires either a lookup table, a fuzzy matching script, or someone who has memorised all the variants. Usually it's the third option, which is not sustainable.
Based on accumulated field experience and a certain amount of trauma. "Making the map" is the last 8% of most spatial analysis tasks.
Rather than recommend a single tool, I find it more useful to think in terms of what you're actually trying to produce. The questions that matter are: Does the map need to be interactive? Does it need to update from a live data source? Does it need to be reproducible, as in, can a colleague run the same process next quarter without calling you? Does it need to be defensible to a GIS specialist who will review it?
The answers to those questions point you toward different parts of the stack. Datawrapper and Flourish are fast, polished, and require no code, though they don't reproduce well and have real limits with custom geographies. Kepler.gl is remarkable for exploratory analysis of large point datasets and costs nothing, though it's not built for print outputs. Python + GeoPandas is reproducible, scriptable, and endlessly flexible; the entry cost is that you need to write code. QGIS sits between those worlds: reproducible via processing models, visual enough to reason about spatially, but slow to learn and occasional in its behaviour.
The honest recommendation for most people coming in from an M&E or programme background: start with Kepler.gl for exploration, graduate to Python + GeoPandas when reproducibility matters, and learn just enough QGIS to handle the edge cases that Python won't help with easily (georeferencing, on-screen digitising, printing).
Simplified. Real decisions also involve procurement budgets, institutional lock-in, and whether the GIS focal point is currently in the field.
One of the genuine improvements in the last decade is how much good geodata is now free and reasonably accessible. OpenStreetMap has become the default basemap for humanitarian work and, in many contexts, is now more current than official government data. It's updated by people living there, not by government mapping agencies operating on five-year survey cycles.
The Humanitarian Data Exchange (HDX) has become the primary data clearing house for crisis contexts: admin boundaries, population estimates, health facility locations, displacement figures. It is not perfect. Data quality is inconsistent, metadata is often sparse, and you will occasionally find a dataset that was last updated during a different crisis that happened to involve the same country. But it's the right first stop.
For satellite imagery, the options have expanded substantially. Sentinel-2 (ESA) gives you free 10m resolution optical imagery on a five-day revisit cycle. Planet has a humanitarian programme. Maxar provides post-disaster imagery through the Open Data Program. None of this requires specialist software to access; the data is increasingly available through browser-based tools like Google Earth Engine, which has its own learning curve but rewards the investment.
Coverage and quality vary significantly by context. "Free" sometimes means free-as-in-beer with registration; occasionally means free-as-in-actually-free.
There's a gap between what the GIS community recommends and what actually gets used by people doing spatial work in humanitarian contexts. In my experience, a significant fraction of maps produced under operational pressure get made in PowerPoint. Not as a joke, as a genuine workflow: screenshot a Google Maps area, paste it in, draw boxes on top with shapes. It is terrible practice and it produces maps that look exactly like what they are. It also takes five minutes and requires no training, which is why it keeps happening.
The goal of improving the tool landscape for non-GIS practitioners is not to eliminate the PowerPoint map. That battle is lost. The goal is to make the next rung of the ladder accessible enough that people climb it. If the five-minutes-in-PowerPoint map is the floor, the next level up is something like a Datawrapper choropleth: still fast, still accessible, but spatially accurate and properly projected. That's achievable. That's a reasonable ask.
The further aspiration (reproducible spatial pipelines, version-controlled geodata, systematically updated maps for reporting) is worth pursuing, but requires institutional will as much as technical capacity. You need someone who cares enough to build it once, and an organisation that cares enough not to let it atrophy when that person moves to the next context.
There is a version of this field where everyone learns Python, everyone uses proper projections, and all spatial data is stored in PostGIS with appropriate metadata. It is a beautiful vision. It is also not the world we operate in, where the satellite connection is 200 kbps, the GIS shapefile is on a USB stick that someone's cousin brought from Nairobi, and the meeting with the donor is in three hours.
The right tool is usually the one you actually have, used by someone who understands its limits. A choropleth in Datawrapper made by someone who knows why they're using it (what it can and can't show, where the data comes from, what the projection does to relative areas) is more useful than a sophisticated GeoPandas pipeline made by someone who doesn't know what they're communicating. Spatial literacy matters more than spatial software fluency. The tools are a vehicle. The thinking is the work.