That’s the name of the workshops I facilitated last week, with the goal of introducing/promoting OpenStreetMap, along with introducing tools like FieldPaper, OpenAerialMap, Sketch-Map Tool and Umap, to meet the objectives of local DRR practitioners’ upcoming mapping initiative.
Last Friday I had conducted two workshop in Iloilo, one (unplanned) for Iloilo’s Provincial DRRMO (disaster agency), and another for Iloilo City own DRRMO. In the Philippines, city charters may provide them autonomy from the geographic province they’re part of. These Disaster Risk Reduction Management Offices (a tongue-full, I know) are the government agencies responsible for mitigating localized disaster risks, and planning for disaster prevention for their respective territories.
Last year, in a random visit in Iloilo, I met some folks from the City DRRMO team and since then, I found out that they’ve capturing community-based hazard risks and perceptions using FieldPapers. Unfortunately, FieldPapers uptime wasn’t as reliable as before, and eventually the built-in Bing imagery became unavailable, too.
I’ve kept in touch with the City’s DRRMO team, and when I told them of a planned (gustatory) visit, they asked if I could run another training workshop for them. The small workshop was planned for a dozen people, but the day before the workshop I was surprised to learn than they confirmed 28 participants, and couldn’t even accommodate my own guests.
Well, that’s how I ended up with two separate workshops, discussing the same topic, but interestingly, the engagement was different with one group being more technical, and familiar with geodata/GIS/maps, and the other are more focused on being able to collect local spatial knowledge.
Anyway, with the feedback about issues they’ve been encountering with FieldPapers, I ran into the updated Sketch-Map Tool which now has built-in ESRI Aerial Imagery included.
FieldPapers (FP)
One of the earliest Pen & Paper tools I’ve learned to like, especially when working with folks averse to “tech”. It’s cheap, and it (used to be quite) reliable.
Creating maps could be tedious, manually requiring people to manually define their area of interest. I think it’s been years since the search function last worked properly.
The participant’s favorite feature is FP’s ability to use external TMS endpoints, and in our case, I demonstrated how OpenAerialMap imagery taken from drones can be used to deploy fresh maps that can be used as background of maps they wish to deploy on the ground.
They participants also like how FP serves TMS tiles of the uploaded snapshot (marked-up) map, which they can use as a background layer on iD (or another editor) for digitizing on OpenStreetMap.
Maximum paper size is ISO A3, which isn’t probably big enough when you expect participants to work together as large groups. That size is more than sufficient for individual mappers though.
If the users aren’t conscious about it, they may inadvertently create atlases with snapshots that may reveal personal or private information, so that’s one thing users should really watch out for.
Sketch-Map Tool (SMT)
This recently revamped tool now comes with built-in satellite imagery from ESRI, but you’re limited to that or the Mapnik (OpenStreetMap’s default layer) background for your maps.
The interface for creating maps is more friendly, and the OHSOME map quality report helpful, but it becomes tedious when you need to create separate maps for a large area, which one has to to create one-by-one.
One of the favorite features for SMT is it’s built-in ability to digitize (properly) marked features and create GeoTIFF and GeoJSON files out of the marked-up map. The data is not stored in HEIGIT's servers, so the risk of accidental disclosure of private information is minimized. Update: 2024-04-22 According to mschaub’s comment, the data is actually stored in HeiGIT’s server, but becomes inaccessible after a day:
One small correction I would like to make (or maybe I misunderstood you): We do store the original sketch map and the uploaded sketch map with markings on them on our servers. The first one, we need to be able to do georeferencing of the sketch map after it was uploaded. The second one we store to be able to improve our machine learning models which are responsible for detecting the markings. We do point this out to the users (see text on the upload dialog). But it is not possible, even with the right URL, to download any of those files one day after they were created. So data is stored on our server, but the risk of accidental disclosure of private information is also minimized.
During the role-playing segment, we experienced how quick the process may be like, from map creation, to the mark-up/reporting process, and the automatic digitization, then visualizing the created GeoJSON files quickly, using Umap.
Over-all, everyone found the tools easy-enough to learn, and accessible for their capacity level.
At it is, these two tools are complementary and one could be more useful than the other, depending on the users’ priorities. To wit:
| FieldPapers | Sketch-Map Tool | |
|---|---|---|
| supported layer | Mapnik, HOTOSM, TMS | Mapnik, ESRI Imagery |
| interface | functional, but search doesn’t work | more user-friendly, works as expected |
| registration | optional | none |
| max. paper size | ISO A3 | ISO A1 |
| geodata | GeoTIFF | GeoTIFF, GeoJSON |
| TMS of marked-up map | yes | no |
| multi-map support | yes | tedious |
| privacy risks | moderate | low |
I’m excited by the initiatives being drawn-up by both DRRMOs, though they are still working independent of each other.
The search and rescue team, and the local fire department, were very enthusiastic about using Pen & Paper to help map location of water wells (parts of the city are experiencing drought), while the search and rescue intends to use them for mapping highways attributes (width and access) and missing footways and paths, to improve response times during emergencies.
I see a potential to make more use of OpenStreetMap data in their local communities, encouraging local contributors to keep the map updated and relevant for their own needs, and the participatory approach they are undertaking, in collecting local spatial knowledge and experience, which could lead to improved usability of gained results for local capacity assessments, and the role of the OSM ecosystem of data and tools serving as a bridge into their formal DRR process.
I would’ve loved to see more of the local active mappers participating in the event and planned activities, but unfortunately, we failed to receive any word from the folks we reached out to.
Gallery
Below is a collage of some photos from the activity.