ICT for Civic Data — Turin University 2025-26
# From Data
to Map
Crash Course — Day 2
civicliteraci.es
--- # From Data to Map Note: "Yesterday we analysed the RFP and built a first map. Today we practice a structured process: find a data source, get the data, and put it on a map. First together, then on your own." --- ## Today's plan **Morning:** - Shared exercise: everyone works with the same dataset to practice the process - Discussion: how to go from a concrete example to a proposal angle **Afternoon:** - Define your own angle - A quick look at data formats and sources - Individual exercise: find data for your angle and map it Note: Set expectations. The morning is guided and shared. The afternoon is individual. By end of day everyone should have a map with data they found themselves. --- ## A note on tokens Your CLI tool (Gemini CLI, Claude Code) has **token limits** that reset periodically. Use them wisely. - Use the **web chatbot** (gemini.google.com, chatgpt.com) for questions, discovery, and exploration - Switch to the **CLI** only when you need to work with files: building maps, running scripts, pushing to GitHub For this morning's exercise, start with the **chatbot**. We will move to the CLI when it is time to build the map. Note: Important practical point. Students burned through tokens yesterday on simple questions. The chatbot is free and unlimited for discovery work. The CLI is for file operations. --- # Shared Exercise:
Mapping Flood Data Note: "We're all going to do the same thing together. This way I can help everyone, and you can focus on learning the process rather than struggling alone." --- ## Step 1: start with a simple prompt Before downloading anything, ask your AI tool what exists. Start simple:
"What data sources exist for floods?"
Compare results across the class. You will see very different answers: some US-focused, some about storms instead of floods, some about insurance data. Note: Do this live together. Have several students share what they got. The variation is the teaching moment. Some results will be irrelevant (storm data, US-only sources). This sets up the next slide. --- ## Why the answers vary Think of AI tools as **assistants**: - Two **beginner** assistants asked a vague question will do their best, but their answers will be imprecise, sometimes irrelevant, and very different from each other - Two **expert** assistants asked a precise question will give relevant, useful answers, and their answers will be much more similar AI is **non-deterministic**: it will not give the same answer twice. But precision in your prompt narrows the range of variation dramatically. Note: The assistant analogy works well here. The simple prompt is like asking a beginner assistant. The detailed prompt on the next slide is like asking an expert. The difference in answer quality and consistency is visible. --- ## Now try a precise prompt
"I'm looking for open datasets of historical flood events with geographic coordinates. What sources exist? For each, tell me what it covers, what format the data is in, and how to access it. I'm a beginner, so please use simple language."
Compare results again. They should be **much more similar** across the class. This is the **Find** step: you are discovering what exists, not downloading yet. Note: Have students share again. The convergence should be visible: most will now get FloodArchive/Dartmouth, EM-DAT, GDACS, and similar results. The precise prompt specifies: historical, flood events, geographic coordinates, open, accessible. Each qualifier narrows the search space. --- ## Step 2: download the FloodArchive dataset We will use the **Dartmouth Flood Observatory archive**: ~5,000 flood events worldwide, 1985-2024, with coordinates. Download it from the source and **upload it to your GitHub repository**. [ckan.rimes.int/dataset/global-active-archive-of-large-flood-events](https://ckan.rimes.int/dataset/global-active-archive-of-large-flood-events) This is the **Get** step. The data moves from a source to your workspace. Note: Students go to the CKAN page, download the Excel file, and upload it to their GitHub repo. This is itself part of the exercise: finding where the actual data lives and getting it. Make sure everyone has the file in their repo before moving on. --- ## Step 3: look at the data before asking questions Before you ask Gemini to do anything with this data, **look at it yourself**.
"Open the file FloodArchive_clustered.csv and show me the first 10 rows. Also tell me how many rows there are, what columns exist, and what countries are covered."
If you don't know what the data looks like, you will ask imprecise questions. Imprecise questions produce imprecise results. Note: This is a key habit. Students should always look at the data before asking the AI to process it. Otherwise they ask vague things like "make a map of the floods" and get surprising results because they didn't know the data had a Severity column or that coordinates were in separate lat/long columns. --- ## Step 4: pick an area and build a map Now that you know what's in the dataset, choose a region and visualise it.
"Filter the FloodArchive data to [your country or region]. Build a Leaflet map in index.html that shows each flood event as a circle. Use the Severity column to set the circle size. Add popups with the date, cause, and number of displaced people. I'm a beginner, please explain what you're doing in simple terms."
Push to GitHub and check your GitHub Pages URL. Note: Everyone does this. Circulate and help. Common issues: coordinate columns swapped, map centered on the wrong place, popups not showing. The browser console is the debugging tool. If students finish quickly, suggest colour coding by MainCause or adding a time filter. --- ## Check: does the map make sense? Look at your map and ask: - Do the events appear **where you expect** floods to happen? - Are there **areas with no events**? Does that mean no floods, or no data? - Does the **severity** match what you know? (a severity-1 event with 80,000 displaced seems odd) This is the **Verify** step. The map is your first verification tool. Note: Quick whole-class discussion. Ask 2-3 students to share their map. The "no data" question is important: FloodArchive captures large flood events; small ones are missing. Some countries have better reporting than others. The data reflects reporting infrastructure as much as flood reality. --- ## What we just practiced
Define, Find, Get, Verify, Clean, Analyse, Present
Three pipeline steps in sequence: 1. **Find**: asked Gemini what flood data sources exist 2. **Get**: downloaded the FloodArchive file into our repo 3. **Verify**: put it on a map and checked if it looks right Working step by step is even more important when working with AI agents. Note: Name the steps explicitly. Connect to the pipeline from the lectures. The point: if something goes wrong, you know where it went wrong because you did each step on its own. --- # From Example
to Angle Note: "You each found a concrete example yesterday: a territory and an issue. Now let's think about how to turn that into a proposal." --- ## Two kinds of RFP, revisited
Precise RFP
The funder knows exactly what they want. Specific technology, specific deliverables. You deliver expertise within their box.
Floaty RFP
The funder has field expertise but is **vague about data and AI** because they don't really know what they need. You have to figure out what would actually help them.
Our practice RFP is floaty. The funder mentions data-driven approaches and AI, but the vagueness tells you they are not clear on how to use them. Note: Recap from Day 1, but now applied to the practical challenge of writing a response. The vagueness is a signal: this organisation needs help thinking through their data strategy, not just a technical product. --- ## The problem with floaty RFPs You cannot answer a vague RFP with a vague answer. You still need a **concrete, grounded story** of how you will help them. But you also cannot address all their needs: - They don't know all their needs themselves - It won't fit the budget - A proposal that tries to do everything does nothing convincingly So you need to **narrow down** to something specific, realistic, and impactful. Note: This is the core tension. Students will want to address the whole RFP. The skill is choosing an entry point that is narrow enough to be credible but significant enough to matter. --- ## Start from concrete examples The way to find that entry point is to start from **concrete examples**. Yesterday you each found a specific case: a territory, an issue, a population at risk. That concrete case is what **grounds your thinking**. It inspires a common thread, and that thread becomes your **angle**. The angle is not the case study. The angle is the **insight you draw from it**. Note: This is the logic: RFP is vague → you cannot answer vaguely → you need to narrow → concrete examples help you find a thread → the thread becomes your angle. Walk through this sequence explicitly. --- ## From case study to angle
The case study
Flood risk in remote Indonesian communities. No monitoring system for quick response.
The thread → the angle
**Monitoring** is the common thread. Once identified, pull it further: - **Prevention**: better data for campaigning - **Protection**: better data for resource allocation - **Response**: early warning systems Monitoring is relevant across all three phases of disaster management. It is also cheap to start (e.g., water level monitors with solar panels).
The case study **inspires** the angle. The angle **gives the case study significance**. Note: Walk through the Indonesia example step by step. The concrete case (no monitoring, remote communities, floods) leads to a thread (monitoring), which leads to an angle (monitoring as entry point across all disaster management phases). Then ask: what thread does YOUR case study suggest? --- ## What makes a good angle A good angle is: - **Grounded** in a concrete example - **Realistic** given the budget and timeline - **Approachable** as an entry point for an organisation that is learning to use data - **Impactful** enough to tell a compelling story Many funders expect tangible outputs: a dashboard, a map, a monitoring tool. Even when the real value is the strategy behind them, a "shiny" deliverable makes the proposal feel concrete. Note: The tangible output point is important. A proposal that says "we will develop a data strategy" is less compelling than one that says "we will build a flood monitoring dashboard AND develop the strategy to sustain it." The shiny object gets attention; the strategy creates lasting value. A good proposal includes both. --- ## Who does what in a project | Role | What they do | |---|---| | **Funder** | Funds, coordinates, sometimes facilitates field access | | **Implementing partner** | Field presence, training, community engagement | | **Technical partner (you)** | Data, tools, methodology, capacity building | Your proposal should make clear what **you** deliver and what the **client's team** does with it. Funders often care as much about capacity building as about the product itself. Note: Students were confused about this. The technical partner builds the dashboard; the implementing partner trains field staff to use it; the funder pays for it and coordinates. Your proposal should describe all three roles, not just your own deliverables. --- ## Discussion For each of your examples: 1. What is your **concrete case**? (territory, issue, affected population) 2. What **thread** do you see? What common theme emerges? 3. How could that thread become an **angle** for your proposal? 4. What **tangible output** would make it feel real to the funder? Let's go through several together. Note: Whole-class discussion. Go around the room. Help students connect their specific case to a proposal-level argument. Some will need help seeing the thread. Others will go too broad and need to be brought back to something concrete. Write everything on the whiteboard. --- ## What we covered this morning - Practiced Find → Get → Verify with a shared dataset - Built a flood map from real data - Started connecting concrete examples to proposal arguments **This afternoon:** define your own angle, learn about data formats and sources, then find and map data for your proposal. Note: Quick recap before lunch.