I’m re­ally pleased to an­nounce that the Mapboard GIS ge­o­log­i­cal map­ping app is now avail­able on the App Store for down­load and use! I’ve been work­ing on this pro­ject since 2017, and its pub­lic re­lease rep­re­sents a ma­jor step to­wards a vi­sion of a mod­ern ge­o­log­i­cal map­ping process.

You can read more about the mo­ti­va­tions dri­ving the app in the sum­mary of my GSA 2020 talk on the sub­ject. Basically, they boil down to an ob­ser­va­tion that dig­i­tal map­ping is far too slow and clunky to match the level of de­tail we can ob­serve and quickly cap­ture with ana­log tools. Mapboard GIS is an at­tempt to im­prove the sit­u­a­tion with a fun­da­men­tally new soft­ware de­sign.

Mapping + soft­ware + de­sign

I love draw­ing maps. They’ve been a fix­ture of my doo­dling since I was in el­e­men­tary school. Hand-drawn maps are also nice-look­ing, quick to con­struct, and in­for­ma­tion-dense.

When I be­gan work­ing on Mapboard GIS in 2017, my small amount of geospa­tial data­base ex­per­tise was greatly over­shad­owed by an over­rid­ing sense that the new ca­pa­bil­i­ties of tablet com­put­ers (to draw them! but also or­ga­nize them dig­i­tally!) had a place in my map­ping work­flow.

This goal re­quired a spe­cific toolset to re­al­ize, and the pro­ject has pushed me to­wards new do­mains of soft­ware de­vel­op­ment. At the start, I be­gan pok­ing at iOS app ex­am­ples and get­ting con­fused by XCode; this even­tu­ally built into ex­pe­ri­ence cod­ing in Apple’s then-newish Swift lan­guage. Coming from dy­namic lan­guages like Python and Javascript, Swift was my first ex­pe­ri­ence writ­ing type-safe code, and I was im­pressed with its ef­fec­tive­ness for build­ing ro­bust ap­pli­ca­tions. Mapboard GIS v2.2.3 (the first pub­lic re­lease on the App Store) is based on Swift, SwiftUI¹, Mapbox GL, Spatialite. It con­nects to server com­po­nents writ­ten in PostGIS and NodeJS.

The com­plex­i­ties of the soft­ware aside, the most im­por­tant in­puts to this work were the strong geo­science vi­sion dri­ving the process. This pro­ject has a clear goal that flows di­rectly from my ex­pe­ri­ence map­ping in the field, and I built many of the tech­ni­cal skills (even fairly com­plex ones) as means to an end. At every stage, my de­ci­sions were guided by the un­der­ly­ing geo­science vi­sion.

Overall, I see the ex­is­tence of Mapboard GIS as a clear ar­gu­ment for priz­ing soft­ware skills along­side core do­main ca­pa­bil­i­ties when train­ing sci­en­tists. Concretely, a high de­gree of com­fort both as a ge­ol­o­gist and as a soft­ware de­vel­oper was re­quired to con­ceive and build this tool. Scientists with deep ex­per­tise in com­ple­men­tary do­mains can build in­no­v­a­tive ap­proaches, even if their split fo­cus dif­fuses their at­ten­tion from the core field².

Another sub­sidiary but im­por­tant thread con­tribut­ing to Mapboard GIS has been user-cen­tric de­sign. Research in hu­man-com­puter in­ter­ac­tion sug­gests that frus­tra­tion with dig­i­tal processes of­ten arise from poorly de­signed in­ter­faces be­tween hu­man and ma­chine. This field em­pha­sizes care­ful thought into how hu­mans pro­duc­tively use soft­ware — at their best, dig­i­tal sys­tems can seam­lessly work with and com­ple­ment their op­er­a­tors’ ca­pa­bil­i­ties³. I’ve tried to tap into this ethos in Mapboard GIS, and I think it un­der­pins much of the sim­plic­ity and power of the sys­tem.

Building fu­ture ca­pa­bil­i­ties

Fundamentally, Mapboard GIS pi­o­neers a new ap­proach to ge­o­logic map­ping, and the un­der­ly­ing work has al­ready come a long way. Next steps in­clude mak­ing the tool eas­ier to use and putting it in peo­ples’ hands.

I’d love to ex­plore use cases in ed­u­ca­tional set­tings (where the it­er­a­tive map­ping work­flow might pro­vide a nice bridge from pa­per map­ping to dig­i­tal tools) and bet­ter in­te­grate the field- and map-pro­duc­tion work­flows for use in pro­fes­sional map­ping work­flows (e.g. at state ge­o­logic sur­veys).

In the near term, I’ll be work­ing on sev­eral fea­tures aimed at broad us­abil­ity:

• Operation along­side sys­tems for col­lect­ing other types of field data, such as Rockd and StraboSpot.
• Capturing notes and la­bels along­side con­tact and unit data.
• Integration with ge­o­log­i­cal pat­terns and sym­bol­ogy to cre­ate more ex­pres­sive and stan­dards-com­pli­ant map­ping out­puts.

There are tons of di­rec­tions to go from here, and I’m ex­cited to start the process of get­ting this out into the world!

---

1. Man, UIKit is re­ally hard to work with if you aren’t good at ar­chi­tect­ing ap­pli­ca­tions. Things would have been much eas­ier if SwiftUI had been around when I started this work. It’s nice to see the core tool­ing evolve in more user-friendly di­rec­tions — if iOS apps were still bound to use Objective-C, I’m fairly cer­tain this pro­ject would never have started.↩︎

2. This is not an idle con­cern. All of the time­lines for core re­search work start to lengthen when you are si­mul­ta­ne­ously solv­ing com­put­ing prob­lems. There are only so many hours in a day, and time spent mak­ing soft­ware us­able by oth­ers is taken from writ­ing up sci­en­tific re­sults.. Building new mod­els for fund­ing and col­lab­o­ra­tion will be im­por­tant to make sure this type of cross-do­main work can con­tinue.↩︎

3. I have al­ways been in­ter­ested in de­sign; in fact, at one point I thought my fu­ture lay in ar­chi­tec­ture. However, as my fo­cus shifted to geo­science, I was lucky to take elec­tive classes like INLS 318: Human-Computer Interaction in UNC’s path-break­ing Information Science school, which gave me tools to think care­fully about user in­ter­faces and soft­ware process de­sign.↩︎