NPMap wraps functionality and a look-and-feel that is specific to the National Park Service around each of these base APIs, making it possible to build web maps without understanding the complexities and nuances of the underlying APIs.
Why support multiple base APIs? Each of the APIs has its own set of strengths and weaknesses, and we like to have a variety of tools available in our toolset. When we kick off a project, we analyze the project requirements and then choose the base API that best meets those requirements. The flexibility built into NPMap allows us to make technology decisions based on actual requirements and not arbitrary or self-imposed restrictions.
A few examples of how we decide which base API to utilize for a project:
- The National Park Service has an enterprise license agreement with Microsoft for the use of Bing Maps, so the Bing Maps API is a viable option. This API includes access to full geocoding, routing, and static maps functionality, and the cartography/design of the Bing Maps "streets" tileset is ideal for layering data on top of. Bing Maps also has high-resolution "oblique" aerial imagery for the United States.
- Leaflet is a minimalistic, yet powerful, API that produces beautiful web maps (it utilizes CSS3, where supported). It is ideal for a number of scenarios, and web maps built with the Leaflet base API work well on both desktop and mobile devices. Leaflet can also be easily extended with a growing number of plugins.
- We use the Modest Maps base API primarily in projects that utilize TileStream layers. Like Leaflet, Modest Maps is very lightweight, so it is also ideal for maps that need to work well on mobile devices.
NPMap uses the native classes of the base API you define in your
NPMap.config object, along with the other information you specify in the config object, to build out your map. After NPMap builds the map, it returns control back to you, meaning that you can then interact with the map programatically via either NPMap's API or the underlying objects and classes made available by the base API. You can access the base API's map object like this after the NPMap
init load hook has fired:
NPMap tries to avoid duplicating functionality that exists in the base API whenever possible. The library is designed to sit on top of each individual base API and provide access to commonly-needed functionality that does not exist natively in the base APIs. There are, however, exceptions to this rule.
One good example is the way NPMap handles markers. All of the base APIs that NPMap supports have their own marker class. These marker classes support basic functionality like the creation of markers, marker click events, etc. NPMap, however, also has its own marker creation method. This method creates markers using the base APIs marker class and then adds extra functionality to the markers it creates (NPMap stores important information it needs for the InfoBox and modules and creates a set of event handlers on the marker objects that act consistently no matter which base API is being utilized). This makes it easier to write code that works consistently across the different base APIs.
There are other examples like this. They are documented in the API reference.
The bottomline: If the NPMap API supports whatever you are looking to do, we strongly recommend that you use its modules and methods over the classes and methods exposed by a base API.
Because of development priorities (internal NPS development on NPMap is primarily project-driven), feature support for the different base APIs can vary. The table below outlines the current status of feature support for each base API. This information reflects the status of feature support in the
Master (or "Experimental") branch of NPMap, so if you are using the latest production release, you may not have access to all of the functionality outlined below.