
I’m really pleased to announce that the Mapboard GIS geological mapping app is now available on the App Store for download and use! I’ve been working on this project since 2017, and its public release represents a major step towards a vision of a modern geological mapping process.
You can read more about the motivations driving the app in the summary of my GSA 2020 talk on the subject. Basically, they boil down to an observation that digital mapping is far too slow and clunky to match the level of detail we can observe and quickly capture with analog tools. Mapboard GIS is an attempt to improve the situation with a fundamentally new software design.
Mapping + software + design

I love drawing maps. They’ve been a fixture of my doodling since I was in elementary school. Hand-drawn maps are also nice-looking, quick to construct, and information-dense.
When I began working on Mapboard GIS in 2017, my small amount of geospatial database expertise was greatly overshadowed by an overriding sense that the new capabilities of tablet computers (to draw them! but also organize them digitally!) had a place in my mapping workflow.

This goal required a specific toolset to realize, and the project has pushed me towards new domains of software development. At the start, I began poking at iOS app examples and getting confused by XCode; this eventually built into experience coding in Apple’s then-newish Swift language. Coming from dynamic languages like Python and Javascript, Swift was my first experience writing type-safe code, and I was impressed with its effectiveness for building robust applications. Mapboard GIS v2.2.3
(the first public release on the App Store) is based on Swift, SwiftUI1, Mapbox GL, Spatialite. It connects to server components written in PostGIS and NodeJS.
The complexities of the software aside, the most important inputs to this work were the strong geoscience vision driving the process. This project has a clear goal that flows directly from my experience mapping in the field, and I built many of the technical skills (even fairly complex ones) as means to an end. At every stage, my decisions were guided by the underlying geoscience vision.
Overall, I see the existence of Mapboard GIS as a clear argument for prizing software skills alongside core domain capabilities when training scientists. Concretely, a high degree of comfort both as a geologist and as a software developer was required to conceive and build this tool. Scientists with deep expertise in complementary domains can build innovative approaches, even if their split focus diffuses their attention from the core field2.
Another subsidiary but important thread contributing to Mapboard GIS has been user-centric design. Research in human-computer interaction suggests that frustration with digital processes often arise from poorly designed interfaces between human and machine. This field emphasizes careful thought into how humans productively use software — at their best, digital systems can seamlessly work with and complement their operators’ capabilities3. I’ve tried to tap into this ethos in Mapboard GIS, and I think it underpins much of the simplicity and power of the system.
Building future capabilities

Fundamentally, Mapboard GIS pioneers a new approach to geologic mapping, and the underlying work has already come a long way. Next steps include making the tool easier to use and putting it in peoples’ hands.
I’d love to explore use cases in educational settings (where the iterative mapping workflow might provide a nice bridge from paper mapping to digital tools) and better integrate the field- and map-production workflows for use in professional mapping workflows (e.g. at state geologic surveys).
In the near term, I’ll be working on several features aimed at broad usability:
- Operation alongside systems for collecting other types of field data, such as Rockd and StraboSpot.
- Capturing notes and labels alongside contact and unit data.
- Integration with geological patterns and symbology to create more expressive and standards-compliant mapping outputs.
There are tons of directions to go from here, and I’m excited to start the process of getting this out into the world!
Man, UIKit is really hard to work with if you aren’t good at architecting applications. Things would have been much easier if SwiftUI had been around when I started this work. It’s nice to see the core tooling evolve in more user-friendly directions — if iOS apps were still bound to use Objective-C, I’m fairly certain this project would never have started.↩︎
This is not an idle concern. All of the timelines for core research work start to lengthen when you are simultaneously solving computing problems. There are only so many hours in a day, and time spent making software usable by others is taken from writing up scientific results.. Building new models for funding and collaboration will be important to make sure this type of cross-domain work can continue.↩︎
I have always been interested in design; in fact, at one point I thought my future lay in architecture. However, as my focus shifted to geoscience, I was lucky to take elective classes like INLS 318: Human-Computer Interaction in UNC’s path-breaking Information Science school, which gave me tools to think carefully about user interfaces and software process design.↩︎