Reflections on teaching OpenStreetMap & other open map tools

Last week, I had the pleasure of helping a bit with the delivery of a workshop on “open tools for the production and use of cartographic data” in Venado Tuerto, that Silvina Meritano organised as part of her role as community ambassador for the UN Mappers. The workshop was supported and co-organised by the local municipal government, the Instituto Católico de Enseñanza Superior , the local branch of Cáritas and the Maná association, and managed to get more than 80 people interested in using maps, from a wide range of social organizations!

Split over two evenings and one morning, the workshop covered both remote and field mapping, using maps, as well as contributing directly to OpenStreetMap (OSM) and using OSM as a base-layer to enable individual map use cases. As always with workshops, some things worked better than others, and I thought it would be valuable to share some of the reflections about some of the technical and socio-technical challenges we encountered. If only to document those, but with some luck maybe to also help others with their workshop.

Editing on older hardware

On the first evening, beyond a general introduction to maps and cartography, the goal was to get folks to make their first map edits to OSM. For that, they’d have to create an OSM account, and then use the browser-based iD editor to make an edit - in our case: add their first building. Which turned out harder than expected.1

iD is generally very newcomer-friendly if and only if two conditions are met: Having a sufficiently fast internet connection and sufficiently powerful computing device. But, as a Javascript-based tool, iD easily downloads tens of megabytes of data, both to run itself and also in terms of the actual OSM data.

The internet connection in the cultural center we used as a workshop room was not always up to have that happen smoothly across 80 devices. But even when downloading the data works, processing and displaying that much data in Javascript isn’t exactly resource-friendly, especially in places that are already somewhat well mapped in OSM.

As a result, the many folks who used older (mobile) devices, e.g. tablets with a connected keyboard/mouse, really struggled. This fits with the larger performance inequality gap of web that Alex Russell has been documenting for many years.2

Matching tasks to learning goals

At the same time, finding editors that work independently of the device type, are light-weight in terms of resource usage and are easy to use isn’t that easy - despite the large diversity of OSM editors. Especially not if the editor should support editing more complex things like areas. One potential solution I see for that is moving away from using the mapping of buildings as the ‘first task’ for this type of more general workshop, and instead move to simpler editors, even if they don’t allow for that particular type of first edit. It would open it up to purely mobile-based editors like Every Door or Street Complete , which work on a wide range of mobile devices.

This could also fit better with the learning goals of such a more general workshop: Creating buildings is a widely used first task in the OSM world, in particular in the Humanitarian OpenStreetMap (HOT) world. Beyond it being a comparatively easy task, it is also the main task that remote-mapping volunteers with HOT are asked to perform.

But for workshop participants who want to use maps in their own work/practice, that is not necessarily the case (and maybe more often than not, it’s not?) They have their own motivations and learning objectives for joining, which will likely be more diverse than in the case of supporting existing humanitarian projects. Different first mapping tasks , which have the potential of being targeted to the participant audience, could potentially fit better in there. And by looking at node-based editing – whether that’s adding street lights, missing offices for social services, or even adding missing info like phone numbers on existing objects – as a first contribution, it opens up the use of simpler, mobile-based tools

Teaching mapping under malleability

The question of fitting the teaching to the learning goals highlights another, more systemic and abstract challenge of teaching how to use these tools: By its very nature, OSM is very malleable or open-ended in how it can be used, and the same applies for map-making tools generally. Which is both a blessing and a curse when it comes to teaching how to use them.

For peer-production efforts like OSM to work, it is necessary to have a clear research object that contributors collectively work on. In the canonical example of Wikipedia, that is an encyclopedia , but in the case of OpenStreetMap, it might seem like the answer should be a map but the reality is subtly different: It’s a database of geo-referenced information , which makes it both more flexible in how it can be used and harder to understand for newcomers, as it’s more the geo-equivalent to Wikidata and not Wikipedia.3

This extra layer of abstraction makes it not as easy for people to get started, as that framing can make it at the same time too easy and too hard to come up with a potential own -use case. In that sense, it mirrors what I have seen a lot in our work with personal science around health and well-being related research projects, and where the first step typically is operationalizing a research question. The malleability open-endedness of the task means that people can easily dream up large project ideas (e.g. “I want to cure cancer”) that are unachievable given the time, available resources etc. On the flip side, it’s also very hard to get a feeling of what a ‘realistic’ scope could be, as a lot of those boundaries end up being tacit knowledge.4

In the personal science space, Gary Wolf has at times talked about the unreasonable effectiveness of show & tell presentations,5 in which people talk about their personal research project by answering 3 questions: What did you do? How did you do it? And, what did you learn? By sharing projects in this way, others can learn from others and see what worked and didn’t work a lot more concretely than abstract teaching tasks could achieve. To achieve this, both the show and the tell are important. In the context of giving workshops around maps, this could mean giving enough space to showcase examples of how other people have appropriated these open tools for their own use cases and what they learned in the process.

In our case last week, we were lucky to get a small team of people present how they had worked with ChatMap to produce a map of art works across town by sending geo-located images and videos. Beyond being a lovely story in itself, it seems to have helped participants think more concretely about how they could use these methods in their contexts. Maybe in future iterations it would be great to make space for some more examples, and maybe put them closer to the start, to make the abstract more concrete.

Mapping outside OSM

In addition to the show & tell, our second evening also included working with the SketchMap Tool, which allows drawing on paper maps which can then be re-digitized into a map overlay. Participants gathered around maps in small groups to discuss and draw on those and had some good fun with those. And I think that was not just because of the technical challenges of the first evening, but also because there’s a real benefit of handling a tangible paper map and drawing directly on it, instead of engaging only via screens.

Similarly, the field mapping using ChatMap on the last day worked very well, with different small groups collecting data out in a neighborhood by recording videos and taking pictures, e.g. of areas that are prone to flooding during rain falls. Both methods allowed for collecting very targeted data, using simple methods, but came at the cost of not directly feeding into the OSM ecosystem.

On the one hand, that’s a shame, especially when it comes to types of data that would be compatible with OSM. On the other hand, there is a real tension between use cases and what OSM can be used for, e.g. when it comes to projects around private data, objects that are of more temporary nature or many other reasons why they wouldn’t fit the OSM data model.

Conclusion

I think overall people did learn a lot about how to use maps and, more importantly, create or contribute to maps and appropriate them for their own goals. At the very least enough to move how to use maps outside the quadrant of the unknown unknowns, giving enough ideas on how to get started. And from the feedback I heard, both all the co-organizing institutions and the participants were really happy!

I think it also gave some good ideas of what could be done even better next time: For example to ease people more into the topic, by maybe giving more community-based mapping examples and – for the OSM based mapping – on using more grounded examples, through tools that are less resource-intensive.

But I’d love to hear more from other folks who’ve tried giving similar workshops: What were your experiences, do those reflections generally resonate with yours? And what worked and didn’t work so well in your contexts - are the examples we could learn from? Please reach out!

References

1. Russell, Alex (2025) The Performance Inequality Gap, 2026. https://infrequently.org/2025/11/performance-inequality-gap-2026/
2. Greshake Tzovaras, B. (2025, August 11). The diversity of OpenStreetMap tools and how they help create a commons. Bastian Greshake Tzovaras. https://doi.org/10.59350/b6hse-mv263
3. Greshake Tzovaras, B. (2025, October 20). Being Social: Motivations in Citizen Science. Bastian Greshake Tzovaras. https://doi.org/10.59350/adffh-1xv53
4. Greshake Tzovaras, B. (2025, November 21). Mapping offline with CoMaps and Every Door. Bastian Greshake Tzovaras. https://doi.org/10.59350/8vcqj-tqe05
5. Kloppenborg K, Ball MP, Greshake Tzovaras B. (2021) A peer production model for citizen science: comparative analysis of three online platforms. https://doi.org/10.31235/osf.io/rw58y
6. Kloppenborg K, Ball MP, Jonas S, Wolf GI, Greshake Tzovaras (2024) Co-designing a wiki-based community knowledge management system for personal science. https://doi.org/10.1098/rsos.240275

Footnotes

1. Some participants also ran into issues when making an OSM account due to the login flow having had a small bug that’s been fixed now: The Cloudflare-based turnstile to verify you’re human didn’t properly load if the submitted user creation form didn’t validate (e.g for a too short password). As a result, all future attempts to re-submit a form that had solved the initial issues would be rejected as not human. Luckily, going back to the original sign-up form fixed that. ↩

2. One of the observations that Russell made to illustrate the current state: In 2026, the median mobile website not only would fit Doom but is larger than the total storage of the computer used for the moon landing! ↩

3. This might seem like a mostly academic distinction, but it makes a big difference when explaining what the project is and how it works: While explaining Wikipedia’s ambition for being an encyclopedia is straight forward, explaining the ambition of being a global, geo-referenced database is similar to explaining git by starting from it being an acyclical, directed graph, expect that for git one can side-step this for the initial intro, while for OSM it’s (imho) somewhat central for the project’s self-conception. For that reason “OSM is a database” has become a bit of a running gag when we give workshops, as it bears repeating many times. ↩

4. As per xkcd #2501, thanks to the curse of knowledge it can be hard to remember that the average person probably only knows the Mercator, Gall-Peters and Dymaxion projections. ↩

5. A homage to the The Unreasonable Effectiveness of Mathematics in the Natural Sciences lecture. ↩