Anyone familiar with the contemporary cartographic landscape knows that the climate is shifting swiftly away from the static and towards the interactive. People want maps they can play with, maps that are responsive to user needs, and maps that can be accessed with nothing more than an internet connection and a few directed search terms. Particularly for those seeking to create a community resource (or just something that folks can access on the go) a web map is a good design choice. Yet I personally still find something uniquely beautiful and important about static, print maps. Perhaps it is Jeff Howarth's voice in the back of my head, reciting a treatise on the pleasure of dwelling with a well-designed map. Perhaps it is the frustration I get from a little extra padding hidden somewhere deep in my CSS, mucking up my legends and selectors. Even so, it is hard to ignore the simple reality that web maps are 1) just plain cool, and 2) a powerful way for democratizing, distributing, and telling stories through geographic data. Their beauty lies in their ability to create multiple vantage points of the same data nearly instantaneously, and to bring these vantage points to the same map in a harmonious way.
But as I've discovered throughout this senior research, the process of self-learning doesn't hinge so much on your prior familiarity or formal instruction with the tools. It really hinges more on 1) your ability to find good, reliable help at your level, 2) the availability of a worked example to base your work on, and 3) the stubbornness to persist in the face of setbacks. Fortunately, I had all three to help me with this project. Because Leaflet is an open-source library maintained and improved by a global user community, there is a strong support community for it online (particularly on Stack Exchange). People have figured out and shared all kinds of nifty hacks to make challenging things happen; moreover, their explanations of their code are surprisingly coherent for a programming language that can so easily behave in unpredictable ways. Joe was also kind enough to provide a worked example of a Leaflet map he had made so that I could parse through its different elements and understand how they work. While things like pulling map tiles from a tile server or rendering vector features from a GeoJSON object are not particularly difficult to pick up, other bits of interactivity (turning layers on and off, changing layer symbology based on multiple variables, etc.) can be. Lastly, I drew on a healthy dose of stubbornness to make it through this project. Each fix often introduces its own problems, and being able to maintain a positive trajectory really comes down to not getting discouraged. This also entails celebrating every little victory you can get.
One of the biggest challenges I originally faced with this map was pulling in Mapbox's Maki markers. To do this, I relied on a Leaflet plug-in developed by jseppi on Github. To get this bit of functionality required drawing on Leaflet's L.icon function and setting some custom CSS to style them with appropriate colors and sizes. Finally – and this is probably the coolest thing happening on the map – the actual styling applied to the trails layer changes when the basemap changes. I have to give credit here to Professor Holler for getting this to work. When we looked at how the trails layer looked against the USGS topo map, we found that a few of the trails were getting lost in the background due to hue and brightness similarity. To deal with this, we wired up a function that does a few things – 1) checks if the USGS basemap is active, 2) checks if the trails layer is on, and 3) if these two conditions are met, places a semi-transparent reddish-brown line beneath the trails. This effect gives just enough contrast to bring the trails layers to the top of the visual hierarchy.
Special thanks again to Professor Joseph Holler for his ingenuity and assistance on the development of this map, and for spearheading this project with ZYEP.