Introducing Our New Map Symbols

Posted on 08 Oct 2015 by Jake Coolidge

This week, version 2.0 of the NPMap Symbol Library goes live. One feature of this release is improved documentation on the tool's landing page, so be sure to take a look. For this post, I'll spotlight the new symbols included in this release that we look forward to using in our various tools. A couple are wholly original designs, like entrance station and food cache, while most adapt widely adopted iconographies to fit the look and feel of our existing symbols, like automated external defibrillator (AED) and flagpole.

  • aed


  • entrance station


  • entrance station

    entrance station

  • flagpole


  • food cache

    Food Cache

  • laundry


  • railroad crossing

    Railroad Crossing

  • spring


  • statue


When designing a symbol, we always start by consulting the symbol sets developed by the Harpers Ferry Center. If HFC hasn't yet developed a symbol that we need, we move on to the internet, where a wealth of material at the Noun Project and Mapbox Maki, among many others, help kickstart the brainstorming process.

Taking the example of the entrance station symbol, we didn’t find symbols on the web that suggested possible solutions, so we consulted images of entrance stations around the NPS. Not surprisingly, entrance stations vary widely from park to park. An early concept used the iconic Roosevelt Arch at the north entrance of Yellowstone National Park, but we ultimately opted for something that indicated entrance station in a more general way. The result is a small guard station and sign flanking an entry, and despite the number of features integrated into the design, it scales down the smallest size relatively gracefully.

  • entrance station


  • entrance station


  • entrance station


  • entrance station


If you're in Minneapolis next month for the NACIS annual meeting, I'll be discussing our work designing web map symbols for the NPS. Find more details here. I hope to see you there!

You can access these and all other symbols in the library at our Github repository. SVG and PNG versions are available.

Preparing for the NPS Centennial

Posted on 05 Oct 2015 by Chad Lawlis

On July 31st we released a data call (NPS-only) to kickstart the process of geospatial data collection for the National Park Service's Centennial through our Places system. It has been just over two months since, and with the passing of the initial data collection deadline of September 30th we wanted to post about our progress thus far.

What is the Centennial and why Places?

In 2016 the National Park Service is celebrating its 100th birthday, or its "Centennial". In celebration of this is undergoing a major redesign, including the transition to a database driven model called "Structured Data" whose spatial component will be powered by Places. All of this will drive completely new individual park pages, including an interactive map for every park, and it will be available to the public in the form of an open application programming interface (API) including park feature coordinates and associated attribute data (e.g. a visitor center's address, operating hours, applicable fees, etc).

So, why Places? As we have blogged about before, Places is an internal data collection system for the National Park Service's "core" geospatial data: points of interest (visitor centers, trailheads, campgrounds, etc), buildings, roads, trails, and parking lots. Currently, the Park Service does not have the servicewide data coverage needed to build a high-quality map for every park, and this is where Places comes in. Places has been developed with the "OpenStreetMap-as-a-platform" model, using a customized fork of the iD editor (what we call "Places Editor") to fit the National Park Service's data collection needs. We built Places so that all NPS employees, both technical and non-technical, can contribute their knowledge to the map -- removing the legacy barriers that have historically prevented non-GIS staff from having a role in the data collection process. A map is only as good as the data it is built with, and with Places our goal is to lay the groundwork for an accurate, beautiful map of every park in time for the 2016 Centennial.

Progress thus far

We have been hard at work over the past two months on a variety of data call related efforts including outreach, documentation, and a long list of data and user experience improvements.

Outreach and documentation

On August 14th we kicked things off with a data call webinar for the NPS GIS community, joined by three of the National Park Service's regional GIS coordinators who discussed the data seeding workflow for their respective regions. This was followed by a Places webinar on August 27th for the NPS web community, introducing Places to web authors (non-GIS staff) and reviewing best practices for heads-up-digitizing in Places Editor.

We have also released the Places Tracing Guide (NPS-only), the first in what will be a series of guides for contributing to Places and working with Places data.

Data improvements

Major data improvements have been made in terms of seeding existing park GIS data, the implementation of new and updated park management boundaries, and a complete revamp of our underlying data schema.

GIS data seeding

Data from thirty-two parks across four regions (Southeast, Pacific Northwest, Northeast, and Midwest) have been seeded from existing GIS data to date, while comprehensive regional data aggregations for all parks in the Pacific West, National Capital, Intermountain, and Alaska regions are in the works. See below for a list of each park that has been seeded thus far, along with the feature types included:

Park Unit Feature Types Seeded
Abraham Lincoln Birthplace National Historical Park Trails
Andersonville National Historic Site Trails
Assateague Island National Seashore Points of interest, roads, trails, parking lots
Biscayne National Park Trails
Cape Cod National Seashore Points of interest, roads, trails
Cape Hatteras National Seashore Points of interest, roads
Canaveral National Seashore Trails
Carl Sandburg Home National Historic Site Trails
Channel Islands National Park Points of interest, roads, trails
Cowpens National Battlefield Trails
De Soto National Memorial Trails
Ellis Island Buildings
Eleanor Roosevelt National Historic Site Trails
Timucuan Ecological & Historic Preserve Trails
Fort Donelson National Battlefield Trails
Fredericksburg & Spotsylvania National Military Park Points of interest, parking lots, trails
Governors Island National Monument Buildings, trails
Guilford Courthouse National Military Park Trails
Gulf Islands National Seashore Trails
Horseshoe Bend National Military Park Trails
Home Of Franklin D Roosevelt National Historic Site Trails
Jean Lafitte National Historical Park and Preserve Trails
Moores Creek National Battlefield Trails
Natchez Trace Parkway Trails
Ocmulgee National Monument Trails
Russell Cave National Monument Trails
San Juan National Historic Site Trails
Statue Of Liberty National Monument Buildings
Stones River National Battlefield Trails
Theodore Roosevelt National Park Points of interest, roads, trails
Timucuan Ecological & Historic Preserve Trails
Virgin Islands National Park Trails

The data collection effort goes beyond data seeding, however, with other parks relying on heads-up-digitizing directly in Places Editor (especially parks lacking GIS support). See below for statistics on all data contributed to Places since the data call release on July 31st, by the number of geometries per "core" feature type, along with all data contributed to Places to date:

Feature Type # of Geometries Since Data Call Total # of Geometries
Points of interest 1,514 13,764
Buildings 307 26,890
Roads 759 13,662
Trails 2,114 18,982
Parking Lots 158 5,349

Although still early in the data collection process the progress in Places has been significant, bringing some parks from a practically blank slate to better data coverage than some of the leading map platforms. See below for a handful of before/after screenshots that we have recorded thus far using our X-Ray View, Places Editor Viewer, and Park Tiles 3 (in development) basemap styles:

Channel Islands National Park, before and after seeding points of interest, roads, and trails. Basemap: X-Ray View.

Channel Islands National Park, before and after seeding points of interest, roads, and trails. Basemap: X-Ray View.

A northern section of Theodore Roosevelt National Park, before and after seeding points of interest, roads, and trails. Basemap: Places Editor Viewer.

A northern section of Theodore Roosevelt National Park, before and after seeding points of interest, roads, and trails. Basemap: Places Editor Viewer.

The Province Lands area of Cape Cod National Seashore, before and after seeding points of interest, roads, and trails. Basemap: Park Tiles 3 (in development).

The Province Lands area of Cape Cod National Seashore, before and after seeding points of interest, roads, and trails. Basemap: Park Tiles 3 (in development).

The Pilgrim Heights area of Cape Cod National Seashore, before and after seeding points of interest, roads, and trails. Basemap: Park Tiles 3 (in development).

The Pilgrim Heights area of Cape Cod National Seashore, before and after seeding points of interest, roads, and trails. Basemap: Park Tiles 3 (in development).


We have also updated the management boundaries for twenty-two parks in Places, including five new park units, ensuring the most accurate reflection of National Park areas available:

No. Park Unit Status
1 American Memorial Park Updated
2 Blue Ridge Parkway Updated
3 Fort Monroe National Monument Added
4 Fort Point National Historic Site Updated
4 Gateway National Recreation Area Updated
6 Gloria Dei Church National Historic Site Added
7 Governors Island National Monument Updated
8 Haleakala National Park Updated
9 Hampton National Historic Site Updated
10 Honouliuli National Monument Added
11 Jefferson National Expansion Memorial Updated
12 Grand Canyon-Parashant National Monument Updated
13 Pullman National Monument Added
14 Richmond National Battlefield Park Updated
15 San Antonio Missions National Historic Park Updated
16 Shenandoah National Park Updated
17 Statue Of Liberty National Monument Updated
18 Ellis Island Updated
19 Tule Springs Fossil Beds Added
20 World War II Valor in the Pacific National Monument Updated
21 Weir Farm National Historic Site Updated
22 Wind Cave National Park Updated

Disclaimer: boundaries in Places are not authoritative.

Data schema

Finally, we have been working closely with the larger "Places Team" - which includes regional GIS representatives from the Alaska, Intermountain, and Southeast regions - on ironing out the underlying Places data schema. We are currently supporting over 260 presets including a wide variety of points (points of interest), lines (roads and trails), and polygons (building footprints and parking lots) which together meet the fundamental needs of both the NPS GIS community and our vision for the redesign. Our schema uses the OpenStreetMap tagging model at its core and it is structured using an object-oriented approach. Each type, for example a "Trailhead", is contained within a class, "Trail", and again within a superclass, "Land Recreation". In this way, the data we come away with is both OpenStreetMap-friendly, should we want to contribute it down the road, and easier to work with in our platforms of choice (Postgres, CartoDB, and Mapbox Studio, among others).

What's to come

Despite the progress thus far, we still have a long way to go before we are ready for the Centennial and the release of, among the other projects we're working on (NPS Places Mobile (NPS-only), Park Tiles 3, NPMap Builder, NPMap Symbol Library, etc). Below is a timeline of data call related efforts to expect from us in the next three months:

1 month

  • Data seeding: Seed all available GIS data to Places.
  • Places Editor Viewer: Implement an improved Editor basemap to allow for easier Places data navigation and identification of areas of interest.
  • Frequently Asked Questions: Publish a help/reference guide for Places contributors.

2 months

  • Places Notify: Develop a system to notify park data stewards when data in their park has been added or changed.
  • Data status update: Publish a blog post identifying the status of Places, remaining gaps in our data, etc.
  • Technical User Documentation: Publish a guide outlining Places data integration with our platforms of choice (querying from the CartoDB API, designing with Mapbox Studio, etc).

3 months

  • Places Validation: Develop a system for managing park data validation tasks.
  • Places Tasking Manager: Develop a system for prioritizing park data needs, geared towards heads-up-digitizing in Places Editor.

Feel free to reach out to us on Twitter at @npmap or via email if you would like to get in touch. Otherwise, sign up for our mailing list to stay up to date on all things NPMap.

Announcing NPMap.js 2.0

Posted on 25 Aug 2015 by Nate Irwin

I am happy to officially announce the first release of NPMap.js, 2.0.0!

Why not 1.0.0? NPMap.js is the successor to the NPMap JavaScript Library, a web mapping abstraction library we first released in 2012. This library served us well for several years, but improvements in JavaScript and other web technologies have pushed web mapping forward in a big way since then.

NPMap.js is our response to these changes. It is a natural evolution of the work done on our first library, so we decided to start versioning it at 2.0.0. This means that all version numbers < 2.0.0 are connected to the original library and all versions >= 2.0.0 are connected to NPMap.js.


Like some other open source mapping libraries, NPMap.js is built as a plugin to the rock-solid Leaflet. It wraps Leaflet with customizations that address specific National Park Service (NPS) requirements and use cases. Before diving into detail about these customizations, I'd like to address a question we often get asked: Why does the National Park Service need its own web mapping library? There are two primary reasons.

None of the existing libraries meet our needs

With the exception of the two open source libraries, Leaflet and OpenLayers, most other libraries (like the ArcGIS JavaScript API, CartoDB.js, Mapbox.js, and others) are built specifically to facilitate connecting to one specific platform. Remaining platform-independent has, however, long been a priority for us, and we need a solution that allows us to connect to a variety of platforms.

Maintaining our own library maximizes our limited development resources

Maintaining a library allows us to address critical organizational needs, like Section 508 compliance and graphic identity, in a single place. These needs would never be addressed by an off-the-shelf library, but building them into our own library means our team, along with other NPMap.js contributors, can take care of tough technical problems and share the work. Others can then take advantage of it without having to start at square one. This paradigm is much more efficient than the alternative where different groups within the NPS build one-off web maps against their library of choice. Not only does this approach lead to duplication of effort, it also results in a reduction in quality. Most groups within our organization simply don't have the resources to spend on tough, but important, problems. Because of this, they often work around these problems and our customers, the American public, end up with a subpar product.


Maps built with NPMap.js are more maintainable than one-off maps built against other mapping libraries. This is true because NPMap.js imposes a rigid, yet flexible (and powerful!), scaffolding that ensures that maps built against the library follow a consistent structure. Advanced developers can always choose to build their maps directly against NPMap.js' classes, but this is not recommended for most.

Maps that follow the recommended approach are configured via a simple JavaScript configuration object. Creating a map is straightforward: You create a configuration object and then load the npmap-bootstrap.js file:

var NPMap = {
  div: 'map'

(function () {
  var s = document.createElement('script');
  s.src = '';

Once the npmap-bootstrap.js file is loaded, it takes care of everything else for you. As you can see, this approach to building a map hides a lot of complexity and does not require previous experience with JavaScript. This is a major positive for an organization like the National Park Service that doesn't have many developers but does have a large number of passionate employees who want to build their own maps.

We feel so confident about the long-term viability of this approach that we are willing to support your mapping endeavors. If you are a National Park Service employee and you build a map using either the "bootstrap" or "hybrid" approach (outlined here), we will help deploy your map on a National Park Service website and maintain your map over time. We can make this commitment with straight faces because maps built with NPMap.js can be maintained centrally. This allows us to fix a bug or add an enhancement in one place and then roll out this change to all maps without having to touch each one individually.

NPMap Builder

Although NPMap Builder hasn't officially been released, I feel the need to mention it here. For those of you who aren't familiar, Builder is a graphical interface that walks you through the process of building a map on top of NPMap.js, step-by-step. If you are intimidated by the thought of developing a configuration object like the one above, you may want to start with Builder. It is still in beta, but fairly solid and well-tested (close to 500 maps have been built with it so far!). NPS employees connected to the internal network can get to it here:

We plan on officially releasing NPMap Builder in a few weeks, and we'll post detailed information about the release here on the blog when it is ready-to-go.


Most of the customizations implemented in NPMap.js are intended to make it easier for others to take advantage of the work our team has done over the last several years. These customizations include many accessibility and usability "best practices", along with a tremendous amount of design and development work.


Out of the box, Leaflet does a great job addressing most accessibility needs. There are, however, accessibility requirements that are more implementation-specific and do not belong in Leaflet itself. NPMap.js takes care of some of these requirements:

  • Focus indicators: NPMap.js adds an indicator around the map when it is focused. It also creates prominent focus indicators for all elements of the map interface, including modules and controls.
  • Keyboard-friendly: The tabindex of the map div, top toolbar, left-hand modules panel, and map controls are modified by NPMap.js so the keyboard navigation flow works more intuitively for those using a keyboard to interact with a map. NPMap.js also adds support for a few additional keyboard shortcuts that aren't already supported by Leaflet.
  • Color-blind friendly: NPMap.js encourages usage of our Park Tiles basemaps that are designed to be color-blind friendly. It also supports "preset" curated colorblind-friendly color palettes that are designed to work well with the Park Tiles suite.

These enhancements/fixes are just the beginning. NPMap.js recently underwent a third-party accessibility audit, and we are currently fixing a number of issues highlighted by this audit. We are tracking the fixes in a GitHub issue, and have also proposed implementation of some of these fixes upstream in Leaflet itself. Stay tuned here on the blog, as we plan on posting more about this accessibility audit in the coming months.

Graphic identity

The National Park Service has a rich mapping tradition, and it is imperative that our digital maps meet the high standards established by our print maps. A lot of this graphic tradition has been rolled directly into NPMap.js:

  • Integration with NPS Bootstrap: NPMap.js' stylesheet is designed to work with the National Park Service's frontend framework, NPS Bootstrap. When used together, Bootstrap's styles (typography, buttons, etc.) cascade cleanly down to the map - overwriting any of NPMap.js' base styles.
  • Custom-designed modules and controls: NPMap.js' modules and controls are designed to fit in with the look-and-feel of the NPS' other digital products, including and park iOS/Android applications.
  • Basemap and color presets: When used together, NPMap.js' basemap and color "presets" present a cohesive cartographic design that serves as a natural extension to the NPS' print cartography tradition.


Establishing and maintaining software licenses in the federal government is not easy. Our team takes on the burden of maintaining licenses with a number of providers, but we often phase existing providers out and new providers in as our requirements and the technologies available to us evolve. This makes it difficult for an NPS employee who wants to build a map to know which services are available for them to use. NPMap.js takes the guesswork out of this by hiding technologies away internally and making it easy for NPS employees to switch between basemap, geocoding, and routing providers.

For instance, NPMap.js currently supports geocoding via services offered by Bing, Esri, and Nominatim. Switching between these providers is as easy as switching a single parameter:

geocoderControl: {
  provider: 'esri'

If we decide to let a license expire (because of cost, changing requirements, or something else), we can easily phase out a service and fallback to an alternative without requiring employees to update their maps. This approach allows employees to rest easy knowing that their maps are using services that have approved terms of service and a valid license.

The beauty of open source

As already noted, NPMap.js is built on the solid foundation of Leaflet. I would be remiss if I didn't also mention at least a few of the other amazing open source projects NPMap.js uses internally. An incomplete list:

Get started

You can get started today using NPMap.js in your own web mapping project! We recommend that you load the library directly from the National Park Service's content delivery network:, as this will ensure your map gets bug fixes as soon as they're released. Here are some links to help get you started:

The developer examples page is probably the best place to start. You can download and/or fork source code directly from the individual example pages and then go about modifying an example with your own code. Feel free to reach out on Twitter or via email if you have questions or run into any problems.

Park Tiles: Data and Design Updates

Posted on 19 Aug 2015 by Mamata Akella

This week, we are excited to release updated versions of our National Park Service basemaps: Park Tiles, Park Tiles Imagery, and Park Tiles Slate.

The major changes in this release are:

  • improved boundaries for several parks,
  • park boundaries are now visible on top of water,
  • each park is now labeled with its designation (e.g. "NP" for "National Park") until its full name appears,
  • the icons for points of interest within park boundaries rendered from our internal data collection system, Places, are using our new Symbol Library,
  • the map's hillshade has been updated to Mapbox Terrain Version 2,
  • and many other design enhancements!
Park boundaries that extend into water are visible.

Park boundaries that extend into water are visible.

Each parks designation has been added to its label.

Each parks designation has been added to its label.

Points of interest within park boundaries are symbolized using icons from our enhanced NPS Symbol Library.

Points of interest within park boundaries are symbolized using icons from our enhanced NPS Symbol Library.

You can use the Park Tiles Viewer to take a closer look at the design and data updates or the Park Tiles Compare Tool to compare previous versions of Park Tiles (along with other commercially-available basemaps) to Park Tiles 2.1 (on the left).

We are actively monitoring and addressing issues with these maps in our Park Tiles issue tracker. Please feel free to add any comments and/or issues you find with the maps there.

Upcoming NPMap Webinars

Posted on 18 Aug 2015 by Nate Irwin

We are in the midst of big rollouts of our Places and NPMap Builder tools and are planning two webinars to help get the word out. These webinars are only available to National Park Service employees, but we plan on recording them and making them available to everyone here on the website. Hope you can join us!

Places: Help Build Your Park's Map

Join us on Thursday, August 27th at 1pm ET as we walk through the Places system and detail how anyone in the National Park Service can use the web-based Places Editor to improve their park's map.

The NPMap team, with a tremendous amount of support from many park and regional GIS programs, recently released Places, an internal data system for the National Park Service. This system is designed to eliminate traditional barriers to entry that have prevented employees from contributing their knowledge to the Park Service's geospatial datasets. The goal is to quickly build out accurate and complete servicewide datasets - and then improve and maintain them over time. We hope to meet this goal by getting more people involved in the data creation and upkeep process.

Places is focused on five "core" geospatial datasets (points of interest, buildings, trails, roads, and parking lots) needed to support several new Centennial initiatives, including a brand new, further development of the National Park Service's basemap, Park Tiles, and park iOS and Android applications. We are hoping to have a solid start to these datasets ready to support the release of the new in early 2016, which means we have less than five months to go!

NPMap Builder: Build Beautiful Maps

Join us on Thursday, September 10th at 1pm ET as we talk about using the NPMap Builder to build beautiful, accessible, and performant web maps and deploy them to

NPMap Builder is a graphical interface that walks National Park Service employees through the process of building web maps step-by-step — no coding required! It has all of the best practices developed by the Harpers Ferry Center, the team, and the NPMap team built into it, so you can be sure your maps meet Section 508 accessibility standards and fit into the National Park Service's graphic identity. Builder is also platform-agnostic, so you can use it to pull in data from a variety of technologies and formats, including Esri, CartoDB, Mapbox, KML, and more.

This webinar will start with the basics and build up to a more advanced use case: Using Builder to start a map and then exporting it out and using the NPMap.js web mapping library to add custom functionality to it.