Hi, I’m Parker Ziegler. Today, I’m going to talk about what’s difficult about
working with geospatial data—how we find it, transform it, analyze it, and visualize it.
Specifically, I’ll share findings from a need-finding study we ran
with domain experts using geospatial data in their research and reporting.
To give you a sense of where we’re headed, I’ll start by providing background on geospatial data.
Next, I’ll briefly describe our contextual inquiry study design. The bulk of the talk
will highlight our findings, zooming in on two challenges our participants faced. Finally,
we’ll discuss design opportunities for geospatial analysis and visualization systems.
Alright, let’s dive into geospatial data.
Geospatial data describes the location and attributes of phenomena on the Earth’s
surface. It augments tabular data by linking attributes to geometric representations of
real-world geographies. For example, this dataset ties housing data from the 2020
American Community Survey to U.S. counties, allowing us to visualize patterns in renter
occupation or analyze spatial relationships between homeownership and education.
Geospatial data is everywhere today, from satellite imagery to environmental sensor networks
to crowdsourced datasets like OpenStreetMap that power all modern mapping applications.
As this data grows in scale and accessibility, domain experts from Earth and climate science,
the social sciences, data journalism,
and other fields are tapping into this data to explore spatiotemporal change.
To give examples from our participants’ work, Earth and climate scientists are using satellite
imagery to train computer vision models that can predict the growth of harmful algal blooms.
Data journalists are using air monitoring data to identify
communities disproportionately affected by harmful pollutants.
However, barriers to working with geospatial data are high.
Many domain experts lack formal training in the theory of geospatial data and the
specialized Geographic Information Systems, or GISs, used to work with it. HCI researchers have
found that GISs are especially difficult for non-geographers to use, mainly because
they rely heavily on concepts and terminology from geography, cartography, and databases.
Some domain experts have turned to programming as an alternative. While geospatial libraries
are increasingly common in Python, R, and JavaScript, domain experts must
develop proficiency in at least one of these languages to benefit from these abstractions.
Despite this landscape of challenges, research has yet to explore the specific obstacles domain
experts face in their work with geospatial data. Prior work has primarily evaluated GIS usability,
but modern geospatial workflows extend to other tools like computational notebooks,
design software, and geospatial analysis and visualization libraries. Moreover,
these studies have focused solely on challenges in analysis and visualization,
ignoring hurdles in data discovery, data transformation, and analysis representation.
This research aims to fill this gap by identifying
the computing needs of domain expert geospatial data users.
Alright, so now let’s talk about our study design. We conducted a contextual inquiry
study with 25 participants from Earth and climate science, the social sciences, and data journalism.
In addition to domain diversity, we recruited participants with varying levels of prior
experience working with geospatial data. Our goal with this approach was to observe
a diverse set of users and identify challenges that recur across a highly varied population.
Our session structure involved roughly hour-long observations of participants working on tasks of
their choice related to finding, transforming, analyzing, and visualizing geospatial data.
Having participants bring their own tasks gave us a high-context view of real challenges they
face in their everyday work. We then performed an inductive thematic analysis of the video
recordings to create a hierarchy of challenges. Let’s now move to our findings.
We identified 12 challenges across five phases of participants’ work with geospatial data:
data discovery, data transformation, analysis, analysis representation,
and visualization. We’re going to focus on two of these challenges.
First, let’s talk about aligning geospatial datasets. Participants needed to transform
datasets to a shared spatial and temporal reference for analysis,
but alignment required complex preprocessing. Many of the preprocessing steps participants
struggled with were unique to geospatial data, involving operations like reprojecting data
to a shared coordinate reference system, resampling gridded geospatial data—called
raster data—to a common spatial resolution, clipping data to a shared geographic extent,
and aggregating data collected at different temporal ranges and intervals.
To make this concrete, let’s look at an example from Participant E2.
This participant was developing a random forest model to predict groundwater withdrawal in the
midwestern US. Their inputs to the model included evapotranspiration data from NASA’s MOD16 dataset,
precipitation data from the PRISM climate dataset, and land cover data from the USDA-NASS Cropland
Data Layer. These datasets were all collected at different spatial resolutions, temporal intervals,
and geographic extents. Therefore, before feeding these inputs to the model for training,
Participant E2 had to transform them into a shared spatial and temporal frame. This
involved resampling finer-resolution datasets to the coarsest resolution,
accumulating datasets collected at more frequent temporal intervals to the coarsest interval,
and clipping datasets to a shared geographic extent.
As this example demonstrates, aligning geospatial datasets required participants to
have significant fluency in geospatial data theory in addition to contextual information about the
datasets themselves. They had to identify the correct sequence of transformations to apply,
which entailed choosing among hundreds of operators available in modern geospatial tooling.
They also had to determine when selected transformations produced undesirable results.
Alright, so that was our first challenge. Now let’s talk about our second challenge,
Sketching Cartographic Variants.
Participants wanted to visualize their data using many different cartographic
representations to identify the map type that represented their
data most effectively and produce tangible artifacts for collaborators to evaluate.
For example, Participant J5, a data journalist, created over 20 draft maps for a story on biased
predictive policing algorithms. They experimented with choropleth and dot density representations,
gridded heat maps, and maps combined with visualizations like bar charts
before reaching a final design. However, this exploration was time-consuming.
A key reason is that producing most map variants required going through the entire analysis and
visualization pipeline, which involved applying additional data transformations and shuffling
data across code, GISs, and design software. Participants tried to speed up the drafting
process in creative ways. One common technique involved screenshotting in-progress maps.
For example, Participant J6 took screenshots of maps in QGIS and
Mapbox Studio during design to capture many variants. They then designed webpage
layouts around these screenshots in Figma and provided the mockups to editors for feedback.
However, screenshotting came with limitations. First, this strategy only allowed users to
capture cartographic changes within a map type rather than across map types. Second,
participants’ screenshotted maps weren’t production-ready;
once a final map design was chosen, participants had to reproduce the selected draft in code.
Having given you a sense of the challenges domain experts face
working with geospatial data, let’s talk about our design opportunities.
We synthesized six opportunities for designers and developers of
geospatial analysis and visualization systems. We’re going to zoom in on two.
First, given that participants wanted to visualize
their geospatial data using multiple map types but transitioning between types was difficult,
cartographic design tools could focus on reducing the “viscosity” of map type transitions. Related
work in visualization has demonstrated success using grammars of graphics for similar tasks.
However, geospatial data isn’t a core emphasis for these grammars,
which restrict the geospatial file formats, data models, and map types that users can work with.
Accordingly, these tools could not express many of the maps participants made.
In rethinking a grammar of graphics for cartography, our findings indicate that
supporting more cartographic representations and minimizing the number of program edits
required to switch representations are critical design considerations.
Second, given that participants drafted maps using direct manipulation design
software but later had to reproduce these maps in code, cartographic design tools
could pair programmatic and direct manipulation paradigms for map construction. In this area,
we draw inspiration from systems like Sketch-n-Sketch that allow users to edit
either a source program or a program’s visual output while propagating edits bidirectionally.
For cartographic design, this approach could allow users to design maps using their preferred
modality—direct manipulation—while giving them automated access to program representations.
We have so much more to share, and a talk of this length can only convey a sliver of
the richness of our study. We encourage you to read the paper to learn about all 12 challenges,
review our six design opportunities, and hear directly from our participants.