Crater Lake National Park

NPMap

Digital maps for the National Park Service

Help Beta Test the NPMap Builder

Posted on 12 Nov 2013 by Nate Irwin

Help Beta Test the NPMap Builder

I am happy to announce that a project our team has been pondering, fleshing out, and working on for close to a year is almost ready for release!

The NPMap Builder is a graphical interface that walks Park Service employees through the process of building a map and then deploying it to internal or public-facing nps.gov web sites. We will post more detailed information about the Builder soon, but for now I'll get to the point of this post.

We are looking for ~50 National Park Service employees, contractors, and partners to help us beta test the first version of the Builder. We've conducted some internal testing, but need more "eyes" to help us discover and squash bugs before releasing the tool to a wider audience.

If you are interested in becoming a beta tester, send an email to npmap@nps.gov with the name of your NPS Active Directory account (the name you use to log on to your computer) and a description of a map you want to create with the Builder. Two important notes:

  1. You must be a National Park Service employee, contractor, or partner to participate in this beta (please make sure you send your request from an nps.gov email address)
  2. Only apply if you have time, over the next month or so, to test and are willing to submit detailed feedback

Welcome, Jim McAndrew!

Posted on 30 Sep 2013 by Nate Irwin

And just like that our team has grown from three to five in less than two weeks. I'm excited to welcome our newest team member, Jim McAndrew!

Jim will be taking over the reins of Places of Interest, which will eventually integrate OpenStreetMap and crowdsourcing into the National Park Service's internal data workflows. His expertise and work will be a huge benefit to both Park Tiles and our larger enterprise GIS efforts.

Jim brings a tremendous amount of experience working with OpenStreetMap to the team. He has been an active member of the OpenStreetMap community since 2009, a board member of the US Chapter of OpenStreetMap for the last two years, and Vice President of the US Chapter for the last year.

Take a look at Jim's team page for more information about his background and interests. You can also find him online on Twitter, GitHub, or the talk-us-nps OpenStreetMap mailing list. Welcome, Jim!


Welcome, Alicia Tyson!

Posted on 04 Sep 2013 by David Warren

We are excited to welcome our newest team member, Alicia Tyson!

Alicia joins the NPMap team as a data manager. Alicia loves data – particularly geospatial data. Her primary duty will be working hand-in-hand with our partners to massage data and build out databases and services that feed National Park Service apps.

Alicia recently received her Masters of Science degree from the University of Denver, where her research focused on GIS modeling of landslides and risk perception in Machu Piccu, Pueblo, Peru. She also interned in the Park Service's National GIS Office for the past year, gaining valuable experience in the realm of Enterprise GIS.

When asked about what she is looking forward to in regards to this new position, Alicia replied, “I just want to help protect, preserve, conserve and otherwise celebrate this beautiful natural world we find ourselves in. I look forward to learning from and with the NPMap team and exploring and pushing as many frontiers as we can!”

Take a look at Alicia's team page to find out more about her. Welcome, Alicia!


How We Build Internal Apps

Posted on 22 Aug 2013 by David Warren

While the most visible projects we work on are visitor-facing, our team also provides design and development support for applications that target our more technical internal users. The Esri server suite (ArcGIS Server and ArcSDE) is a critical component of these applications, as most National Park Service employees use ArcGIS Desktop to create and maintain their GIS data. In this post, I'll explain how our internal map portal, InsideMaps, leverages ArcGIS Server to allow users to quickly visualize and edit their GIS data in a targeted, usable, and accessible web environment.

The new version of InsideMaps, v2, is under active development, and two launch partners are currently utilizing it: the Division of Fire and Aviation Management and Cape Hatteras National Seashore.

The Anatomy

InsideMaps v2 is built, first and foremost, on top of ArcGIS Server map and feature services. It does, however, use the NPMap Library internally, so it also includes full support for a number of other layer types, including, but not limited to: CartoDB, GeoJSON, KML, and MapBox Hosting.

All InsideMaps applications have the same look-and-feel: The black NPS bar with the application name at the top and the legend and modules to the left-side of the screen. These applications can be built using any four of the base APIs that are supported by the NPMap library: Bing, Google, Leaflet, or Modest Maps. Because of this, it is possible to bring in base map services from a large number of sources, including Bing, Esri, Google, MapBox Hosting, MapQuest, and any other provider that uses either the Tile Map Service or XYZ format.

Although the NPMap library includes a number of modules and tools, InsideMaps v2 overrides most of these with interfaces built specifically for use by a more technical audience. These tools include advanced functionality like uploading Shapefiles and GPX files (coming soon), printing via templates, advanced query/reporting functionality, and edit forms that include full support for ArcGIS Server aliases, default values, field types/constraints, domains, subtypes, and relationships. The support for relationships even includes the ability to access feature classes and tables that are more than one "hop" away.

In addition, InsideMaps v2 supports bringing "live" data in from external systems like the Facility Management Software System, NPS Focus, and the NPS Data Store. This integration of services is where InsideMaps really shines.

An Example

In the data panel in the screen shot above, you can see a legend displaying two different ArcGIS Server services published and maintained by Cape Hatteras National Seashore. “Access Line” is a map service that displays the current beach access status of roads at the park. “CAHA Birds” is a feature service, running on top of an ArcSDE geodatabase, that displays bird data created by wildlife biologists and technicians working in the field. The InsideMaps application was built to both simplify the workflow for getting data into the system and make interacting with the data easier. This simplification is necessary for two reasons: 1) Most wildlife biologists/technicians don't have access to and aren't familiar with using ArcGIS Desktop, and 2) the ArcSDE geodatabase is highly-relational, and therefore unintuitive and difficult for non-technical employees to use.

By publishing the data as a feature service using ArcGIS Server 10.1, the InsideMaps app is able to wrap the service with an easy-to-use interface and allow users to insert, update, and delete spatial and tabular data. Simplified forms help users navigate the relationships - some of which are four "hops" away from a feature class.

About Those Forms

InsideMaps v2 is built using ExtJS 4. ExtJS is an app framework that makes it possible to quickly develop high-performing, usable, and accessible desktop-class applications for the web. The forms you see below allow the user to easily traverse the hierarchy of the database schema. They also, as mentioned above, support all of the features of an ArcGIS geodatabase, including aliases, default values, field types/constraints, domains, and subtypes.

When we start work on a new InsideMaps app, we prefer to simplify the database schema as much as possible up front, as this enhances the user experience and makes everyone's job easier. In some cases, however, this isn't an option. In the case of the Cape Hatteras Birds app, the database utilizes the National Park Service's Natural Resource Database Template. This template is a standard for collecting Natural Resource data, so we didn't have any flexibility in making changes to the schema. This added quite a bit of complexity to the app development, but we were able to hide some of this complexity by building targeted forms for the various workflows defeined and used by the wildlife biologists and technicians working in the field.

Editing Geometries

InsideMaps also includes the ability to insert, update, and delete feature geometries using ArcGIS Server feature services. On the frontend, InsideMaps uses the Google Maps drawing tools, the Leaflet.draw plugin, and some custom JavaScript code to allow users to edit geometries.

This edit functionality works in conjunction with a layer's edit form to streamline the overall edit process, and all of this works seamlessly behind-the-scenes with ArcGIS Server feature services, so it is fully integrated with Cape Hatteras' GIS operations. Feature services utilized by InsideMaps can also be brought into ArcGIS Desktop, where they behave like any other layer.

And Finally, Versioning

ArcSDE versioning has proven to be a valuable function for Park Service GIS programs. Both the Cape Hatteras and Wildland Fire geodatabases are maintained by multiple users. In the case of Wildland Fire specifically, park and regional users update spatial data for their area(s) of interest. New data edits are checked by a data manager at the national level and pushed up the default (vetted) version of the geodatabase. Each version that exists in the geodatabase has its own set of services (both map and feature) that the InsideMaps application uses, based on which perspective of the app is being used.

Conclusion

Although the work we do doesn't always overlap with "traditional" GIS, in the case of our internal apps it is imperative that we provide full support and integration with the Esri suite of tools, as they are the primary tools used by our GIS employees. Because of this, InsideMaps v2 is built with "Class A" support for ArcGIS Server. As we continue to develop v2 out, we will enhance and add new features that increase our integration with ArcGIS Server and make it easy to build simple yet full-featured apps for Park Service employees, contractors, and partners. This is our primary focus for InsideMaps, and we look forward to making the platform a good complement to ArcGIS Server and other Esri server products like ArcGIS Online.


NPS + OSM = Places of Interest

Posted on 12 Jun 2013 by Nate Irwin

Places of Interest Coming Soon

Like many others, we are huge fans of OpenStreetMap (OSM). We use OSM data in many of our projects, and it is also a critical component of our basemap, Park Tiles.

Because of the important role OpenStreetMap plays in our projects and workflows, we have an interest in ensuring OSM coverage for our National Parks is as complete and accurate as possible. Therefore, we want our Parks to be active and engaged citizens in the OpenStreetMap community, and we also want the Park Service as an organization to contribute back to the community in substantive and meaningful ways.

Given all of this, we are excited to announce a new project our team is undertaking for the National Park Service called Places of Interest (or POI). We've established two overarching goals for POI:

  1. Streamline the process of getting National Park Service data into OpenStreetMap
  2. Make it as easy as possible for both the public and non-technical NPS employees to help improve Park Service maps

This post will outline our initial thoughts about how we might be able to meet these goals. Our plan is a work-in-progress, and we expect it to evolve as we work our way through the project and learn more from the knowledgeable OpenStreetMap community.

The Plan

Our vision for Places of Interest is an integrated system that facilitates moving data back and forth between OpenStreetMap and our internal NPS datasets. The system will include several different components:

  1. A public-facing instance of the new OSM editor, iD, that the public can use to contribute data to the Park Service.
  2. An internal instance of iD that our employees can use to contribute to OpenStreetMap and/or our datasets.
  3. A set of internal tools that Park Service employees can use to validate data coming in from public contributors and other NPS staff.
  4. Services and tasks that publish data (validated or raw) via web services and file downloads for usage in our digital maps and other applications.

Raw data coming in through the public interface will be pushed to both OpenStreetMap (under the ODbL license) and internal NPS databases, where it will be considered public domain.

If relevant, data created via the internal interface will be pushed to both OpenStreetMap and our internal databases. An example of non-relevant data would be something like the location of water stops along a trail race in a park. We will house this data in a separate system and publish it so it can be consumed by our digital maps, but it would never be pushed into OpenStreetMap or one of our internal enterprise databases.

Relevant data that make it through our internal approval processes will be pushed into the corresponding NPS dataset and will also be tagged as nps:approved=yes and pushed back out to OpenStreetMap.

Here's a flow diagram to help illustrate how all the different pieces fit together:

Places of Interest Flow Diagram

Benefits

The benefits to be gained from integrating OpenStreetMap into our internal workflows and data structures are numerous. Places of Interest will allow us to:

Take advantage of an untapped resource

Our National Park Service GIS community does a tremendous job developing and maintaining geospatial data for our Parks, but they are limited in number (some Parks don't even have local GIS support) and often overtasked. Places of Interest will allow us to take advantage of the 1,000,000+ OpenStreetMap contributors and the 22,000+ Park Service employees who likely don't even know what GIS stands for. These groups make up a huge untapped resource of motivated individuals who are passionate about our National Parks and willing to help improve our data and maps.

Tell our stories

Places of Interest will also enable those 22,000+ non-technical Park Service employees to tell stories they've never been able to tell before. These employees work on-the-ground to protect some of the world's most beautiful and iconic places, and the knowledge they've gained from their experiences needs to be shared.

Up to this point, if a Park Service employee wanted to build a map, they had to overcome numerous hurdles - technical and otherwise. Places of Interest, coupled with a few other tools our team is working on (namely Park Tiles, the NPMap JavaScript library, and the NPMap Builder), will eliminate these hurdles and enable our employees to build and deploy high-quality digital mapping products.

Open up our data and processes

Places of Interest moves the Park Service in the direction defined by President Obama's Open Government Initiative, which has three primary tenets: Transparency, participation, and collaboration.

One of the primary goals of Places of Interest is to mirror authoritative National Park Service geospatial datasets out to OpenStreetMap, so it can be used by the public, other government agencies, and private organizations in any way they choose. If we can accomplish this goal, we will also be in compliance with President Obama's May 9, 2013 Executive Order: "Making Open and Machine Readable the New Default for Government Information."

Further our mission

Places of Interest also fits right in line with NPS Director Jon Jarvis' "A Call to Action" initiative, which is intended to prepare the National Park Service "for a second century of stewardship and engagement." Specifically, Places of Interest falls in line with two actions:

  1. Go Digital: "Reach new audiences and maintain a conversation with all Americans by transforming the NPS digital experience to offer rich, interactive, up-to-date content from every park and program. To accomplish this we will create a user-friendly web platform that supports online and mobile technology including social media."
  2. Out with the Old: "Engage national park visitors with interpretive media that offer interactive experiences, convey information based on current scholarship, and are accessible to the broadest range of the public. To that end we will replace 2,500 outdated, inaccurate, and substandard interpretive exhibits, signs, films, and other media with innovative, immersive, fully accessible, and learner-centered experiences."

Next Steps

This post is just the beginning. Places of Interest is a huge project, and we are not going to be able to change the way the National Park Service "does" geospatial data overnight.

Over the coming months, we are going to tackle a few specific tasks to help move Places of Interest forward:

  1. Introduce our parks to OpenStreetMap and (hopefully) get them excited about engaging with the OSM community.
  2. Work with the NPS and OpenStreetMap communities to improve coverage for our Parks.
  3. Define priority themes and tags for National Park Service data. We will utilize existing OSM tags, where available, and propose new tags and/or use interim tags, where necessary.
  4. Build out the system and pilot its usage and the worfklows in a few parks. Data that our parks contribute to OSM will be tagged nps:verified=yes.

Get Involved

We are excited to work with the OpenStreetMap community, and would also love to have you involved!

If you are interested in helping out, join the talk-us-nps mailing list, where we'll be posting project updates and Park Service employees will be interacting with members of the OpenStreetMap community. We would also love to hear any feedback you might have. You can reach us at npmap@nps.gov or get in touch on Twitter: @npmap.