Recommended
More Related Content
Viewers also liked
Viewers also liked (20)
Similar to Building a US National Park Service Online Basemap
Similar to Building a US National Park Service Online Basemap (20)
Building a US National Park Service Online Basemap
- 1. Building a US National Park Service Online Base Map Mamata Akella
- 2. NPMap Who we are ● Build, maintain, and support a JavaScript web mapping library (NPMap) ● Design and develop project specific web maps ● GIS Server and data management
- 3. Online Basemaps What we currently use ● Current Basemaps ● Bing, Esri, Google, MapBox
- 4. NPS Styled Online Basemap Why we're building it ● An online basemap that has the “look and feel” of the NPS brand ● Transfer NPS printed park map cartography to the web ● Build a basemap that can be used by visitors and for NPS specific web applications ● At large scales, display detailed park data
- 5. Data Data and the NPS ● Data + National Park Service ● Data store, some internal data collection projects underway (trails, poi's) ● Data + Harpers Ferry Center ● Printed map products, starting to move to a GIS system ● Data + Individual Parks ● Data collection not standardized, no staff available to collect data ● Base data ● Looking into openly available sources to use in our products
- 7. Technology How we're building our map ● Data Management/Processing ● osm2pgsql > PostGIS (looking into Imposm) – High Roads ● SQLite, Shapefile ● QGIS ● Design ● TileMill (basemap design) ● Dymo (labeling at smaller scales) ● InkScape (marker symbol design) ● ArcGIS (vignettes) ● Natural Scene Designer/Adobe Photoshop (relief)
- 8. Technology How we're serving our map ● Serving ● TileStream and our NPMap JavaScript library ● Overlay patterns
- 9. Future Work Data collection ● NPS OSM Editor ● Work with Park Service employees, volunteers, and OSM data contributors ● NPS specific tags/review process
- 10. Future Work Multi-scale cartography ● More than just the area of a feature ● Significance to the National Park ● Add hierarchy for POI's, trails ● Introduce features (and labels) through scale using an “importance” attribute
- 11. Resources NPMap ● NPMap Website ● www.nps.gov/npmap ● Follow us on Twitter ● @npmap ● Use our tiles ● tiles.mapbox.com/nps
- 12. Appreciation Thanks for your help!
Editor's Notes
- Hello, and thanks for attending my talk. My name is Mamata Akella and I am a Research Associate at Colorado State University working at the National Park Service as a Web Map Specialist. Today I am going to talk about a big project we're working on this year which is building a National Park Service online basemap.
- Here is an outline of what I'm going to talk about... I'll start with a brief overview of our team and what we do followed by a brief discussion about why we've decided to build our own basemap. I'll then talk about the current state of data for mapping at the NPS and talk about how we're using OSM data in our basemap I'll go a little bit into the technology we're using to build this map and point out some cartographic challenges we've encountered mapping with OSM data I'll conclude with some thoughts on how we see OSM and NPS working together to create and maintain data in National Parks
- The NPMap team is responsible for a few primary tasks: 1. we build and maintain a web mapping library called NPMap that is used by NPS employees to easily create fast, good-looking web maps 2. we works with NPS employees and partners to build custom web maps and applications 3. we manage NPS data and ArcGIS Server projects and licenses.
- Currently, the NPS uses basemaps from various providers including Bing, Esri, Google, and MapBox. While these basemaps are extremely useful and provide us with a good selection to use, these are general reference type maps where National Park Units are often times pushed to the background. We also don't have much stylistic control over these basemaps. We can modify some things like color and turn some layers on and off, but often times when we mash up our content on these basemaps, there is a lot of overlap and our mashed up content doesn't always come to the foreground.
- So why are we thinking of building our own basemap? 1. There is a very strong cartographic tradition that has been developed at Harpers Ferry and we want to work on transferring that look to the web. This means that we are doing things like aligning our colors, symbols and fonts as much as we can with the NPS graphic identity. Another example of an organization that's done this is National Geographic. Basemap with Esri. 2. We're also thinking of different ways to serve our basemap which will give us greater flexibility in its use – I'll talk about this more later in my talk.
- Naturally, one of the first conversations you have while in the initial planning stages of building a basemap is about data. The data situation at the park service is interesting and varies at all levels. The National Park Service as a whole has a data store where all available NPS data can be downloaded and used. This includes features like POI's and trails but some of these data are over 10 years old. Under consideration is a service wide project to collect trails data from all parks into an enterprise system. We're also working on starting a similar effort for POIs. As I mentioned earlier, Harpers Ferry does all of the print park mapping. Traditionally, these have been graphical products meaning that the data are not necessarily geographic in nature. There is currently an effort underway to convert all of this data to a GIS system – this has already been done for 120 out of ~400 parks so far. There are some parks with great data that have collected it on their own. But with these data there is no standard in place YET as to what features should be collected and how they should be attributed. There are other parks with no GIS staff to take on such a task. In terms of base data for our basemap, we're looking into free and open data because we don't manage any datasets like that.
- Here I have a diagram that breaks down by zoom level what data sources we are using for different features in our map. For National Park Service units, we are using our own data. For small scale base data we are using Natural Earth which in most cases holds up very well until about zoom level 8. For larger scales we are incorporating data from various sources including US Census Bureau for urban areas, NOAA for coastline data, and the majority of our large scale data are coming from OpenStreetMap. For relief, we are using DEMs of varying resolution from the USGS. For the three feature types highlighted here at the bottom, if a park has their own data, we would like to use it. OK! Now that we've got some context behind this map, let's take a look at it!! DEMO: talk about the design of the map shaded relief light enough as to not interfere with other mapped information with enough exaggeration to do justice to the beautiful landscapes in parks. Very little information on the map, light colors, leaves lots of color space for mashuped content. NPS fonts
- We are using a variety of technologies to manage our data and design and serve this basemap. To manage our OSM data, we are using the osm2pgsql/PostGIS framework. Now that we have a better idea of the features that we want to extract from OSM, we are going to start looking into using Imposm to speed up drawing times and queries. We're also using high roads (from Stamen) to simplify our road queries and styling. We manage our park data in SQLite and the remainder of the data seen in this basemap are in shapefile format. For data processing we use tools like QGIS and ArcGIS. The primary tool we're using for design is TileMill. TileMill is great because we can use all of these different data formats we have in one unified experience. We use InkScape to manage our marker symbols so things like this campsite here and highway shields. Our beautiful relief was created by Tom Patterson using Natural Scene Designer and Adobe Photoshop. For labeling at smaller scales we are using Dymo.
- We're serving our map using TileStream and consuming services through our NPMap javascript library. As I mentioned at the beginning of my talk, one of the reasons we have decided to build our own basemap is so we have greater flexibility. Especially with overlays. Here I have some screenshot examples of overlays with point, polygon, and line examples. The points are ok, the middle example of Ammonium Deposition in parks obscures all of the information below it while the line example showing our National Trails run right over park and city labels. There is a lot left to be desired. So let's go back to the app showing our map, and look at how we have decided to serve this map based on these problems. DEMO: show the exploded basemap and how we can turn features on and off to make better looking web maps with overlays.
- Given that we have an opportunity at the Park Service to essentially define a data collection system, we're thinking of different ways to approach it. One of the things we'd like to try out is to create a NPS OSM editor and install it on our own infrastructure. This is something similar to what the USGS is currently doing. The reason government agencies are building their own OSM editor is so we can put the collected data back out to the public domain. With this infrastructure we'll also be able to collect our data into both the File Geodatabase and OSM data formats. We'll then make these data available back to the OSM community.
- Since we have the opportunity to collect our data and build up a schema, we're thinking of different attributes to collect for multi-scale mapping. Typically with this type of basemap work, we use data that are already collected and we are tied to the attributes that are available in these data for our mapping purposes. By us collecting our own data, it also gives us an opportunity to do some up front attribute collection which will enable us to make smarter decisions about how we introduce data through scale. This is another tradition that we are modeling after the work at the Harpers Ferry Center. At HFC, they've had to determine at the scale they are mapping, what features are important in the overall context of the park map – they are not always able to show all features given the scale they're working at. The selection process is a meaningful one where park staff are asked what the important features are. From a multi-scale mapping perspective, this will enable us to add features that are “important” to the parks at smaller scales, and slowly introduce more and more information in this way at larger scales. For example, we would like to first symbolize ranger stations and information centers before picnic areas.