As you may have read in our preceding post, the Search and Rescue (SAR) map we are building seeks to combine the vital features of USGS topographic maps with the ease of use, readability, and higher update frequency of a vector tile based map, in addition to providing supplemental data that may prove useful in SAR related work. This follow-up post is meant to further elaborate on the process behind the SAR map’s creation and current status.
To start things off, I love the old USGS topographic maps. I love their style. I have a 1984 Old Rag quadrangle hanging above my desk. Those older USGS topos featured more detailed surface features (e.g. trails and utilities) but are, unfortunately, limited by their age and format. Newer USGS topos are generally in GeoPDF, a format which allows for multiple layers that can be toggled depending on the view you want, all enveloped together in a PDF. This comes with its own advantages, however they do not include some of the more specific features one would want for SAR work, as reviewed in Jason’s post. In addition, GeoPDF not a particularly lightweight platform. With our SAR topo we hope to take everything that’s great about both the older and newer USGS topographic maps, add in any other data that will prove useful in a search and rescue situation, and provide a fully interactive map that can still be used in offline field situations.
When we were first exploring possible platforms for this project, we’d started with Mapbox and their new map design tool Mapbox Studio. The initial prototype for the SAR map was inspired by the Mapbox Outdoors style and source in Studio. However, we ran into two primary issues.
That being said, Mapbox Studio is a very powerful, and actively evolving design tool. The work we did initially in Studio really provided a foundation for how we decided to move forward with the project. Using both the OpenStreetMap data and the supplemental SAR data we’d compiled for styling in Studio, we created an
.mbtiles archive. MBTiles is “an efficient format for storing [large vector and raster tilesets] in a single SQLite database.” Once these sources are combined and exported, we can locally host them with relative ease. For this prototype, we’re using a simple Node server for hosting the tiles in concert with Mapbox GL, Mapbox’s OpenGL based vector tile renderer, for the client side rendering. This is further detailed below in Work Flow, followed by an overview of all the different datasets we used in Data Sources and Layers.
shelter_type!=public_transport(e.g. bus shelters, covered train platforms). Unfortunately there are a large number of shelter features that do not include the
amenity=shelter, there are a number of other tags that could contain shelters relevant to SAR: e.g.
building=hut. For the most part features with these more specific IDs are also tagged with
amenity=shelter, and those outliers were mostly private residences or paid lodging (at least within the US). Another potentially relevant shelter tag was
shelter_type=rock_shelter, unfortunately though there are no features currently tagged as such in the US (I guess I’ll have to start mapping those on my hikes).
You can view the map below and here.
There are still quite a few things to work on with this prototype, beyond improving general performance: there’s a whole lot to be done with the dynamic labeling, we need to add airport information (e.g. runways, boundaries, etc), distinguish dirt roads from paved roads with more distinctive styling, add styling for mines and caves, add pattern overlay for wetlands, update the land cover data, and refine a few of the OSM queries, just to name a few. Blue contour lines over snow or ice cover have been suggested, as well as differentiating between tree canopy type (e.g. deciduous vs coniferous). Please let us know of any additional features you feel could be potentially helpful to SAR efforts that you’d like to see included in the map!
Note: For the purpose of this web demo, a Mapbox API key is used for access to glyphs and sprites. At the moment I’m exploring a few of the tools in Mapbox’s repo for storing this information locally for offline use, e.g. fontnik, node-fontnik, and spritenik. However, I recently learned that Mapbox GL is working towards using HarfBuzz for this, which would render local storage for font rendering unnecessary.