Posted on 01 Dec 2014 by
NPMap is growing, and we're looking for a Data Engineer and a Cartographer to join us in defining the future of National Park Service maps.
As part of our team, you can expect to work on a wide variety of projects for parks, programs, and partner organizations. If building custom tools for digital mapping and making government more open and transparent interest you, we encourage you to apply!
Follow the links below to read the full position descriptions and apply.
If you have additional questions, feel free to contact me at email@example.com.
Posted on 04 Aug 2014 by
With an average of ten million visitors each year, Great Smoky Mountains National Park experiences many visitors who get lost in the park because of inaccurate Location-Based Services (LBS) or outdated maps. Park-issued maps are available at visitor centers, but many visitors rely on navigation assistance from their mobile phones or other GPS devices. This is a major problem because the map data used by many LBS providers does not reflect authoritative data - causing many visitors to follow poor navigation directions.
Great Smoky Mountains National Park is a 276,344 acre park located on the border of North Carolina and Tennessee.
In Comes OpenStreetMap
When the NPMap team announced several initiatives built around OpenStreetMap (OSM), the Smokies quickly saw an opportunity to get accurate maps and data into the hands of an increasingly technologically-savvy public. All National Parks must make their authoritative map data available through the NPS Data Store, but few park visitors possess the knowledge or the software required to manipulate the data or load it onto their personal electronic device. OpenStreetMap, on the other hand, is built specifically for non-technical users, and it gives them the ability to edit and interact with the data in a platform of their choosing.
During the summer of 2013, the Smokies approached the OSM community through the Imports-US mailing list with their proposal for uploading the park's authoritative data to the OSM database. The park engaged with the community because any significant addition or alteration of OSM data usually requires a discussion to:
- Ensure that the data is a good fit for the OSM model
- Reach agreement with the community on how the data will be entered into the database
Initially, the park struggled with some of the feedback received during the import discussion process. Like any federal agency, the Park Service must follow strict rules when publishing map data in any format. For example, federal regulations prohibit a government entity from publishing the name of a geographic location unless that name has been approved by the United States Geological Survey's Board of Geographic Names. Given that the OSM database is based on “crowd-sourced” input, many OSM members felt that the park's official names for many features were not inline with local, common, or well-known geographic names that members of the public might recognize. Ultimately, consensus was achieved when the park agreed to add an “Official Name” tag to data it was contributing to OSM.
Experienced OSM mappers were also able to help the Smokies work through some challenging “tagging” questions, such as how to tag buildings, deal with TIGER data, and document National Park Service tagging guidelines on the OSM Wiki. The value of this feedback emphasizes the importance of reviewing import proposals with the OSM community.
Following agreement on how the park would proceed with its OSM import, the park converted its authoritative base data into shapefile format - allowing it to be imported via the Java OpenStreetMap (JOSM) application. For the many features that already existed in the OSM database, park mappers simply conflated (replaced old with new) geometries, such as road and trails, with the more accurate park data, then attributed the tags according the NPS tag wiki. They completed a portion of the park and made the OSM database available for public review before completing the import and posting all of the data to the production OSM database.
A Lesson Learned
One important lesson was learned when the park ran into significant data validation issues related to the amount of data they were uploading at one time. This was related to the length of time it took to edit such a large geographic footprint. During the few weeks that the park was uploading data, many changes were still occurring to the “live” OSM database, which led to an increase in time spent re-validating data. In addition, the park experienced the ubiquitous computer crash during an upload of several hundred thousand objects (each node edit is counted as an object), resulting in a hair-pulling, all-night-long correction of a duplicate upload to the OSM database.
Because of this experience at the Smokies, the NPMap team is now discouraging bulk uploading and editing of NPS data in the OSM database - at least for the time being. The team now recommends that no more than a few features be edited or uploaded at once. The team is investigating ways to simplify the process of getting data from internal NPS databases into OSM.
The entire process, including import discussion and editing, took about 400 hours for the park to complete. The NPMap team and Smokies staff spent much of that time documenting tagging guidelines on the OSM wiki. These guidelines are meant to make it much easier for other National Parks to contribute their data to OSM. The NPMap team expects that parks following those guidelines would be able to complete a park-wide update of their data in OSM in 40 hours or less.
The park is well-mapped in OpenStreetMap now.
The Smokies update to OSM has been complete for over a year now. Present in the OSM database, available for public use, is what the National Park Service considers essential base data for visitor services: transportation networks, points of interest, and visitor services infrastructure. For example, anyone can consume OSM data from the Smokies and make a map showing the location of visitor centers, ranger stations, campground, and hiking trails - no specialized skills required!
The continued maintenance of the Smokies data in OSM is a dynamic process. Through the OpenStreetMap editor and specialized tools like MapRoulette, other OSM mappers continue to improve upon the park's contribution by, for example, updating feature that have too many nodes or making cartographic improvements to feature geometry.
The National Park Service does not monitor or endorse commercial mapping applications, but the Smokies has noticed that many smartphone and web-based applications are using the park's OSM data. This demonstrates that OpenStreetMap is a great way for the Smokies to make their authoritative data available for public usage in an open way - with no restriction on how the data is used or distributed.
Posted on 11 Jun 2014 by
We just released a new version of the state page maps for each of the NPS.gov state pages. These maps are intended to demonstrate the breadth of the impact the National Park Service has on communities across America. They include National Parks as well as locations from various NPS programs like the National Register of Historic Places, Federal Lands to Parks, the Rivers, Trails, and Conservation Assistance Program, and more.
The previous version of the state page maps used out-of-the-box Bing tiles. The maps now use our custom basemap, Park Tiles. The design of Park Tiles pushes National Park unit boundaries and program locations to the forefront of the map.
About the Technology
NPMap.js is built on top of Leaflet and uses the Leaflet.markercluster plugin internally to support marker clustering. This makes it possible to display the more than 100,000+ program locations across the country while maintaining good performance across all platforms and browsers.
The point data for each of the maps is stored and served directly from GitHub using GitHub Pages.
Take a Look
You can access the state pages directly from the NPS.gov home page. Simply select a state from the dropdown at the top right-hand corner of the page.
Posted on 04 Jun 2014 by
The National Park Service manages 401 special places across America, ranging from small cultural parks to some of the world's most iconic natural parks. Unfortunately, under the traditional GIS paradigm many of these parks don't have the resources to develop or maintain their own geographic information. The Places project aims to address this problem by making it easy for non-technical Park Service employees to contribute their own information and local knowledge through an easy-to-use web interface.
Data collected through Places is rendered in our Park Tiles basemap, which is used on many National Park Service web pages and will soon be used by Park iOS and Android apps built on top of the Places Mobile app framework. Data from Places can also be accessed by developers and other systems through a set of REST-based web services.
Our goal is to refresh Park Tiles with changes/additions made in Places on a daily basis, although this refresh is currently a manual process.
Built on OpenStreetMap
As demonstrated by the user stats, the OpenStreetMap project has done a tremendous job building tools that make mapping more accessible to everyone - including those who have no previous experience creating or maintaining geospatial data. Places is built on these same tools, allowing us to take advantage of the hard work done by the OpenStreetMap community as well as contribute resources back.
Existing OpenStreetMap users will recognize the tagging style and the Places Editor itself, which is a slightly-customized version of iD. New users will be able to get up-and-running quickly, allowing them to contribute their knowledge to the map.
This initial release is limited to the National Park Service's Points of Interest dataset. The editor includes presets and icons for the Harpers Ferry Center map symbols.
We intentionally limited the scope of this release to give us some time to incrementally build out the internal system architecture. We will, however, soon add support for buildings, roads, trails, and other "core" data themes.
Integration with GIS
We see the Places system as being a good complement to, and not a replacement for, the National Park Service's GIS program. To that end, we are working on ways to more tighly integrate Places with our internal GIS. We also plan on automating the upload of "GIS-friendly" datasets to the National Park Service's Data Store, where they can be downloaded by NPS employees and members of the public.
Places is only available to those who can access the National Park Service network. NPS employees, partners, and volunteers can access the Places Editor at http://insidemaps.nps.gov/places/. The first time you start editing, you will be given the option to run through a demo. You can also walk through a Getting Started tutorial and find out more about the system on the project wiki.
You can also jump directly into editing Places (and OpenStreetMap) by clicking on the "Improve Park Tiles" link in the bottom right-hand corner of every map that utilizes Park Tiles.
As always, please let us know what you think by reaching out via email or Twitter. You can also create bug or enhancement requests in the Places issue tracker.
Posted on 28 May 2014 by
We're excited to share the newest addition to our suite of custom NPS basemaps: Park Tiles Imagery.
Park Tiles Imagery is a reference overlay that can be placed on top of imagery services licensed by the NPS, including Bing, Esri, and Mapbox. NPS employees can now seamlessly switch between Park Tiles and Park Tiles Imagery for their mapping needs.
Stay tuned for more news about how we are customizing Park Tiles for different use cases - including mobile and multiple overlay types. And make sure you view the map above on your retina device!