Park Tiles 3 Beta Release

Posted on 23 Nov 2015 by Taylor Long

Park Tiles 3 Beta is an internal release, viewable only by NPS employees, partners, and contractors.

We are pleased to release Park Tiles 3 Beta for internal review! Many parks have submitted data as part of the recently completed data call memo. This beta release includes data submitted as part of that data call, in addition to other style updates we’ve made to Park Tiles. We encourage parks to review how their NPS Places data appears in the new basemap and submit initial feedback by the end of January 2016. After this initial period of review, Park Tiles 3 will be made available for use on public-facing maps.

About Park Tiles 3

Park Tiles is a suite of online basemaps designed to fit the National Park Service's graphic identity. The currently available version of Park Tiles, 2.1, displays crowd-sourced data from OpenStreetMap and overlays points of interest from the NPS Places database. With the release of Park Tiles 3, our basemaps will now feature only NPS Places data within park boundaries. This means that for the first time parks can maintain all their own Park Tiles basemap data for roads, trails, buildings, parking lots, and other points of interest. Instructions are provided below on how Parks and Regions can manage data NPS Places. Click the button below to open the Park Tiles 3 Beta viewer (NPS-only: must be on NPS network to view).

Park Tiles 3 release plan

This beta release of Park Tiles 3 allows parks to see how their NPS Places data looks on the new basemap before the basemap becomes available for use on public-facing sites. Parks have until the end of January 2016 to submit feedback. Additionally, please work with your colleagues in national programs such as transportation, cultural resources and facilities to ensure features are properly displayed and labelled. After the review, NPMap will release Park Tiles 3 in February 2016.

Keep in mind that adding and updating NPS Places data is an iterative process, and no park will be forced to use Park Tiles 3. On new NPS.gov sites, parks will have the option to show Park Tiles 3 or a zoomable version of their print brochure map. The February public release simply means that Park Tiles 3 will made available for use in NPMap Builder and NPMap.js.

NPS Places data in Park Tiles 3

Data management workflows

The NPS Places database was designed to store general reference map data appropriate for display on public-facing digital maps. NPMap is working to support two different workflows to maintaining this data:

  1. NPS Places workflow: In the Places workflow, parks can edit their own data directly in the NPS Places Editor. Updates made in the editor will go live in Park Tiles 3 within 24-48 hours. This workflow is currently operational.
  2. GIS workflow: For parks managing their data in a GIS, an alternate workflow that pulls data directly from the GIS can be put in place. NPS Places Editor will be locked for parks using this workflow (no features within the parks will be editable). NPS Places data will be synced directly from existing GIS databases so edits can be made directly in the GIS. The GIS workflow is currently planned for parks in the Alaska region and most parks in the Intermountain region. We are still developing and testing this workflow with these two regions. If you have any questions, concerns, or feedback about this workflow, feel free to contact us or your regional GIS Coordinator.

You can also read more about these two workflows in our support doc.

What you'll see in Park Tiles 3

Park Tiles includes most but not all features entered in the NPS Places Editor. Park Tiles is meant to serve as a simple basemap that shows the most important general reference data for all parks. As such, Park Tiles 3 has been styled to highlight an essential subset of five data themes within park boundaries:

  1. Roads
  2. Trails
  3. Buildings
  4. Parking Lots
  5. Points of Interest
    • Visitor Centers
    • Ranger Stations
    • Information
    • Lodging
    • Campgrounds
    • Campsites
    • Shelter
    • Picnic Areas
    • Stores
    • Food Service
    • Parking
    • Trailheads
    • Restrooms

How are features styled in Park Tiles 3?

To learn more about how NPS Places features are styled in Park Tiles, check out the Park Tiles 3 Style Reference.

How long does it take for edits to show in Park Tiles?

Edits made in the NPS Places Editor may take 24-48 hours to appear in the Park Tiles basemaps. If you're still not seeing changes after this amount of time, it may help to clear your browser's cache since some of the older tiled map images may have been saved and stored for efficiency. The data you see in the NPS Places Editor will always be the most up-to-date – if you're curious about a feature in park tiles, it's best to find the feature in the editor to learn more.

Why can't I see the data I sent to NPMap for the data call?

As part of the Places Data Call, we invited parks to add data directly in the NPS Places Editor OR send us GIS data so we could add it for them in bulk (we call this "data seeding"). For some parks, data seeding is still in progress, but should be completed shortly (see open github issues). Some regional GIS offices have requested special workflows we are still working to accommodate. If you don't see the data you sent us, feel free to contact us for a progress update.

How should I handle data outside my park boundary?

As mentioned above, Park Tiles 3 shows NPS Places data inside park boundaries and OpenStreetMap data outside park boundaries. As such, the transition between roads outside and inside park boundaries is not seamless - roads inside parks are intentionally styled to stand out. We are researching ways to make this transition appear more seamless and these updates will be integrated into Park Tiles 3 on an ongoing basis. Parks that have features outside of park boundaries can still include these features in NPS Places and they will be rendered on top of OpenStreetMap data. For advice resolving specific issues, contact us at npmap@nps.gov.

Submitting feedback

As a beta release, Park Tiles 3 is meant to evolve in response to feedback from parks. Because this is the first time parks will see their NPS Places data in Park Tiles, we anticipate changes to the data (which can be made through the NPS Places Editor (NPS-only)) and requests for bug fixes and style modifications to Park Tiles 3 itself.

Parks may submit feedback by clicking the Submit Feedback button in the Park Tiles 3 Beta viewer (NPS-only). This will open an email compose window with a link to the current map view embedded in the body of the email. Please leave this link and add a detailed description of your feedback at the top of the email body. Also feel free to take a screenshot and mark it up to add more context.

We hope you enjoy Park Tiles 3 Beta, and we look forward to your feedback!

Virgin Islands Marine Visitor Use Map

Posted on 13 Oct 2015 by Jeremy Cantor

This is a guest post from Jeremy Cantor, a Colorado State University Research Associate who works with the National Park Service's Ocean & Coastal Resources Branch. In this post, Jeremy gives an overview of a map he built using the NPMap toolset.

Introduction

Virgin Islands National Park and Virgin Islands Coral Reef National Monument are two National Park Service-managed units found both on the terrestrial lands of St. John, US Virgin Islands and in its offshore waters and coral reefs. The coral reefs are under attack from natural causes such as coral disease, coral bleaching, and sedimentation as well as from man-made impacts caused by visitors to the park. While it may be difficult to slow down naturally caused damage, there is plenty that can be done to prevent man-made destruction of the reef. In order for park managers to better protect their fundamental resources, they requested assistance in building a tool that provided marine use information to visitors that could be accessed from multiple devices.

Needs

We needed the map to be lightweight, be accessible on all devices, not require any browser extension or app downloads, allow custom symbology, and include popups, legend, and table of contents elements. We used several NPMap tools to develop a map that met all of these needs. The NPMap Builder was used to build the basic functionality and style of the map. In order to add further functionality to the original map, we used NPMap.js, a web mapping library built specifically for use by the National Park Service.

The map being designed in NPMap Builder.

Map Design

The map has two buttons for zooming in and out. A user can also use the scroll wheel on their desktop mouse or a two-fingered pinch for touch screens to zoom in and out. There is a home button that, when clicked, will take a user back to the initial extent of the map. The table of contents and legend have been combined into one element in order to avoid having too much clutter. When a user clicks on a feature, a text popup is shown providing information on things such as regulations on use of boat moorings, how much it costs to use an overnight anchor, or a description of popular snorkeling areas.

A screenshot of the final product.

Three different basemaps can be switched on. The default basemap is set to the ESRI Imagery service. For the Virgin Islands, this imagery provided the most cloud-free and highest resolution imagery available. A user can also switch to the Park Tiles Imagery basemap which uses Mapbox imagery with some customized NPS labelling. Or a user can switch to the Park Tiles basemap which maintains the NPS graphic identity found in paper visitor maps.

A very useful feature is the full-screen mode, found in the upper-right corner of the map. When clicked, the map will expand to fit the entire screen of a user’s device. This functionality makes the map feel more like an app and is very useful if a user is on a device, such as a smartphone, that has a smaller screen.

The last feature adds some very useful functionality to the map. When a user clicks on the Locate button, the map will display his/her location using a small blue dot. This functionality will make it very easy for park visitors to figure out where they are, understand park regulations, and help protect and preserve our critical natural resources.

To see the map for yourself, visit Virgin Island National Park’s website. For more information, you can view the webinar on Vimeo or send me an email.

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

    AED

  • entrance station

    Entrance

  • entrance station

    Entrance Station

  • flagpole

    Flagpole

  • food cache

    Food Cache

  • laundry

    Laundry

  • railroad crossing

    Railroad Crossing

  • spring

    Spring

  • statue

    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

    32px

  • entrance station

    24px

  • entrance station

    16px

  • entrance station

    12px

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 NPS.gov 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).

Boundaries

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 may be different than legislative boundaries and should only be used for reference purposes. They are not legal documents and are not intended to be used as such.

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 NPS.gov 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 NPS.gov, 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.

Approach

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.

Maintainability

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 = 'http://www.nps.gov/lib/npmap.js/2.0.0/npmap-bootstrap.js';
  document.body.appendChild(s);
})();

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: http://insidemaps.nps.gov/builder/.

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.

Customizations

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.

Accessibility

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 NPS.gov 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.

Licensing

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: http://www.nps.gov/lib/npmap.js/2.0.0/npmap-bootstrap.min.js, 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.