More than just a digital analogue of our road maps of old, digital maps can transcend serving as interface devices and become vehicles for data visualization and powerful visual storytelling. I’ve worked with teams to develop rich, multi-dimensional data-driven maps that engage viewers in historical events and citizen science observations across both time and geography.
In one project, I helped a Digital Humanities team bring historical literature to life, stepping through a timeline-based tour of London with the characters in Daniel Defoe’s A Journal of the Plague Year. In another project, I supported the nonprofit Journey North, leveraging their 25-year—and ongoing—database of observations and sightings, allowing viewers to compare species’ migration patterns or arrival, departure, and emergence dates.
The majority of digital maps you encounter depend upon one of those map providers listed above. There’s simply too much overhead in hosting your own map tiles on a performant server that can respond to all those requests as users pan and zoom. It can be done, but unless you can allocate resources to maintain a responsive map server, it’s better left to the professionals and platform providers. Which one to choose?
If you’re working on a nonprofit project trying to make the most of your budget, I’d like to share the toolkit I’ve put together, which leverages robust, developer-friendly APIs, open source libraries, and free-for-non-commercial-use service plans.
Choosing a direction
Before looking at which combination of platforms and services provides the most mileage, I established an important distinction in the types of maps we were producing and the support we would need.
In contrast, the maps I’ve worked on plot data on a standard map as markers (or pins, or shapes, or paths). In the Digital Humanities project (“Itinerary“), this is all that was needed. We also went this route with the Journey North data for a number of reasons, including but not limited to pricing considerations. We do have maps that feature more than 3,000 pins, which is something of a performance threshold. Things start to lag when you exceed that volume of markers and flattening your data points as map tiles mitigates that overhead. But our maps feature real-time data every season, with the latest approved sightings appearing on maps as those sightings are posted. Periodically manually uploading data to generate map tiles to render snapshot maps was not logistically realistic.
Bring your own data
Your map-making journey begins with data: data residing in a database you have access to; data that you’ve compiled from other sources; or data that you’re recording to display in the future or in real time. The only real requirement to put that data on a map is that each data point has latitude and longitude values, or a corresponding set of latitude and longitude coordinates to define a path or shape. Data points in the maps I’ve worked on also include dates, which we use to render those points on a time scale. Because these data points represent a location at a specific time, I call our data points events.
In both the Itinerary and Journey North projects I’ve process data to output it in the GeoJSON format. Because our data points—events—have additional properties, they’re formatted as feature objects in GeoJSON. We can store any additional data attributes as properties for each feature object, allowing us to pass image URLs and comments for the popup; date and time values for our timeline; and design cues to our map layer.
Our use of GeoJSON on the Itinerary project was limited to reference files we manually created to define the boundaries of parishes or paths taken, which a corresponding event would light up. We used Jekyll to generate the shell of the map application, and looped through CSV files to generate JSON data files that we looped through to create markers on the map or to highlight a corresponding parish.
Making your map
If Google Maps API was completely free and not subject to pay-as-you-go pricing thresholds, I might be compelled to go that route despite my reservations about placing all our eggs in Google’s basket. But I think there are better choices out there, from providers dedicated to developing and supporting mapping platforms, and have been rather determined to make those work. Ultimately that mission paid off for Journey North from a pricing perspective as well. (Note: We replaced a number of legacy Google Maps API dependencies for geolocation and location picker tools from Journey North in 2018 with the following solutions to reduce costs due to pay-as-you-go. Journey North receives many map views, and API hits for associated services, during peak season updates.)
Esri‘s offerings were suggested for Journey North, as they’re well-established in the scientific and GIS communities. I’ve always been a big fan of Mapbox and recommend reading their values statement.
Which came first: Choosing a mapping platform compatible with the library you like, or choosing a library compatible with the mapping platform you’ll use? In our case, it was a little bit of both, and we ended up with something of a combination of Mapbox and Esri offerings.
Charting a course
Exploratory projects like Itinerary, accessed by a smaller audience, can fly under the radar when it comes to pricing, with any of the mentioned platforms at your disposal as long as one is willing to put a credit card on file. As is often the case in web and application development, though, the choices we make tend to comprise our go-to toolkit—we become well-versed in those platforms and libraries we choose for our first project and they facilitate our efforts in the future, along with efficiencies that help us work effectively amidst budget and time constraints.
The toolkit I’ve outlined here has served Journey North well, supporting a few hundred thousand views a month during peak sightings season. As any nonprofit can relate to, Journey North is under continual pressure to do a lot with a little, and while maps are a cornerstone of the website and community, there are other priorities and objectives. Saving money on recurring expenses and third party services affords more time to work on enhancements and optimization.
A great thing about developing digital maps is that all of the platforms behave pretty similarly, and you can translate your experience with one platform into diving into another. I encourage you to experiment with all of them—and with different types of maps—as you build your own toolkit. What’s worked well in my case may not suit your needs, and you may not be subject to the same constraints as my projects. At the same time, I can attest that the approach outlined here has empowered us with an affordable, stable, robust platform for rich, data-driven interactive maps that we’ve come to rely on to engage a community of users and tell their stories.
I hope your map-making journey is as rewarding.