Great Smoky Mountains National Park
|Part of WikiProject United States.|
- 1 Overview
- 2 Schedule
- 3 Dedicated Import Account
- 4 License
- 5 Accuracy
- 6 Software
- 7 Transportation
- 8 Relations
- 9 Manmade Features
- 9.1 Observation towers and viewing platforms
- 9.2 Survey Bench Mark
- 9.3 Cemeteries
- 9.4 Historic Structures
- 9.5 Gift Shops
- 9.6 Food
- 9.7 Rentals
- 9.8 Toilets
- 9.9 Parking
- 9.10 Ranger Stations
- 9.11 Front Country Camping
- 9.12 BackCountry Camping
- 10 Natural Features
- 11 See also
- 12 Frequently Asked Questions
Great Smoky Mountains National Park is in the process of performing a final review and due dillegence assessment of a 4-year GIS data collection effort which includes updates to trails, roads, streams, points of interest, and topography. These data are considered "Core Base Data" and are being thourougly vetted to present "Authoritative Data" to the public. This update/import project will involve migrating that data into OSM. Where vector lines (roads, streams) cross the park boundary, nodes will be edge matched for linear continuity of features that cross the boundary. We plan on only editing small geographic regions of the park at one time, which limits node updates to 1 or 2 roads and a dozen trails at one time, as to avoid issues associated with massive, bulk imports. Given that some park visitor services are closed seasonally, appropriate tags will reflect hours/months of operation. There are no plans to include unplanned closure tags, such as those due to construction or natural disaster.
Updates will be targeted to provide Location Based Service Providers (GPS, on-line mapping, map publishers, on-line routing) necessary map data in order to provide the public SAFE and ACCURATE navigation options within the park and assist in locating visitor services. This is not the case now!
ONLY data which is made available to the public via the [NPS Data Store] will be included in this update. Under no circumstance can the National Park Service "make exclusively available" data to a third-party, such as a mapping web page. Data that will not be made available to the public includes data that is protected by federal law.
We are planning to test a small import (Cades Cove Section) during early summer 2013 to make sure that data replacement/adds meet community approval, and that current commercial applications using OSM source data are not affected. Following success of that import, we plan to roll up imports based on geographic sections of the park (E.g. Cataloochee, Cosby, Greenbrier, etc...), one at a time. Completion is anticipated by fall 2013. Restricting edit sessions to small geographic areas will alleviate the data integrity issues often causes by large, bulk imports.
What's been updated so far
Dedicated Import Account
Data is considered "Public Domain". Only data that is made publically available on the NPS.GOV web site will be edited/imported into OSM.
All data entered by the NPS into the public domain meets National Map Accuracy Standards.
The workplan involves moving the core base GIS data from an enterprise GIS database to shapefile format, and using JOSM to perform tagging and uploading. Prior to import/upload of any data to OSM, raw GIS data is extensively reviewed in native GIS software where topology, network, and attribute consistency rules are enforced.
We have found that JOSM picks up topology errors that ESRI Arc Map does not consider to be an error, which is a good thing!
Roads and trails will follow multi-modal transportation principles, which suggest that a LBS provider can serve mechanical and non-mechanical navigation solutions within the same architecture. Roads and trails have been digitized such that topology rules allow navigation on road, to a parking lot, and onto the trail. Each type of linear travel category (roads, parking lots, and trails) exisist within the same node-topology network.
The possible permutations of relations are far too numerous to detail here, but it's sufficient to assume that post-edit, we will revisit all the possible relation tagging for roads and trails. There are several national trail systems within the park, as well as "Auto Tour" loops. Tagging these ways with relations enhance visitor services by providing navigation choices based on a desired activity.
There are no substantial changes proposed to roads and tracks compared to existing OSM data. In most cases, changes include minor geometry edits or an increase in node count. Great Smoky Mountains National Park ONLY publishes roads data which are shown on the official park visitor map and inventoried by the Federal Highway Administration. Updates to OSM will include road surface, commercial vehicle restrictions, and seasonal road closures. We intend on keeping existing tags, notably the TIGER tags. On the topic of TIGER tags, while we will keep the tags, tag values will change as TIGER is notorious for attribute errors such as incorrect road name and CFC code.
This example covers the most detailed road tagging we encounter, with MV restrictions:
- bicycle=conditional:yes @ (Wd 00:01-1000, Sa 00:01-1000)
- motor_vehicle=conditional:no @ (Wd 00:01-1000, Sa 00:01-1000)
- name=Cades Cove Loop Road
Road with like tags are "combined" in JOSM (not the case when imported from ESRI!). OSM preference is for ways NOT to be split at every intersection unless tags change!
One-way roads will follow digitized direction.
We do not anticipate turn restrictions.
Following Manual Conflation guidelines, we see no need to conflate to Tiger roads. However, by using the "Replace Geometry" tool in JOSM, we are, in a sense, achieving conflation, which keeps the important edit history.
We have no plans to include addressing in this import, as we do not maintain addressing for a transportation network that covers 8 different jurisdictions, each with its own addressing schema. OSM contributers wishing to enable addressing roads within the park footprint should contact the two states and six counties for specific addressing data.
At this time, we are not yet loading or tagging bridges until we have confirmed load limits.
Overlooks and Vistas along roads
Typically an overlook is associated with a parking way. In this case, a node of the parking way is tagged as the vista.
There are no substantial changes to trails and ways compared to existing OSM data. Great Smoky Mountains National Park ONLY publishes trails data which are shown on the official park visitor map. Some geometry edits are anticipated. Emphasis will be given to differentiating hiker only, versus hiker and horse trails. We intend on keeping existing tags.
- name=Cades Cove Nature Trail
It is important to note that on trails where a horse restriction starts in along the trail, and not at a junction, the trail will be "split" at a node. There are several trails in the park where a horse restriction begins in the middle of a trail. Following the Cades Cove import, we were pleased to see that the default OSM renderer colors horse and hiker trails differently!
Where trails meet or intersect another way, correct topology will result in a node and split at the intersection.
We do not plan on providing a trail rating classification, as trail difficulty is a subject of some different opinions by many. However, this is perhaps the number one question we get, so we may look to some hiking clubs to come up with a consistent application of trail rating tag(s).
Each trail in the park consists of very many trail segments, which will be tagged with relations for the trail name. Example:
- name=Appalachian Trail
- operator=Appalachian Mountain Club
- symbol=white-paint blazes
Many man-made features in the park are a building. In most cases, a building usually contains a single visitor service. In that case, simply adding the service type as an additional tag to the building feature will suffice. In the case where a building hosts more than one visitor service, the nodes outlining that building will each receive a tag (separate service tag for each node). E.g. a building with four nodes will have one node tagged as ranger station, and another node tagged as toilette.
Some buildings will not be named, such as sheds and some storage buildings.
Observation towers and viewing platforms
Survey Bench Mark
Associated with former places of worship
Not associated with former places of worship
Former Places of Worship
There are many old churches within the park.
The most important man-made feature in the park! All restroom facilities are located in some sort of structure, which will be reprented using the building feature, with the following tags:
In this manner, both a building and a toilet graphic can be shown.
Some restroom facilities are only available to groups whom have reserved the facility that the rest room is a part of, thus some may be tagged with:
We will use node icons for parking. As there are several hundred parking areas in the park, there are no plans to delineate parking area polygons. Parking areas will be denoted by selecting a single node approximately in the middle of a parking way and adding the following:
Parking ways will be represented as a line representing the approximate direction of traffic through the parking area. There are no plans to depict parking spaces or capacity. During peak seasons, assume parking is at capacity! The following tags will be used for a parking way:
The general idea is to allow LBS providers to depict travel on a parking way and display the name of the parking area (e.g. "Turn Left on Cades Covee Picnic Area Parking A"). Some of our parking areas are quite large and contain many ways. Node symbology will also allow LBS providers to display a parking icon (based on preferred rendering scale).
Long-range plans could allow for delieating actual parking "curb and gutter" but not with current staff resources...perhaps a "crowd sourcing" project. The challenge is getting the curb and gutter from plans in propietery format (CAD) which only exists in hard-copy format!
We have found that in areas where many parking areas are clustered closely together, it is not necessary to add a Parking Node every,say, 10 feet. A single Parking node dropped in the vicinity of the parking area will suffice. The intent to convey where one can park, and enjoy the view or engage in some activity. For those "lonesome" parking areas, a Parking node along the parking way perfectly conveys the function of that area.
Ranger Stations will be reprented as a TAGGED NODE of a building, with the following tags:
The name of the Ranger Station (or name of building) is included in the building name tag, which may have more tagged nodes.
Front Country Camping
There are several categories of camping in the park. Where more than one type of camping group is accomodated, separate nodes will represent those types. Several LBS providers do not handle "icon stacking" very well (where one node can represent several ameneties). All front country camp features will include:
Large campgrounds (large areas with a variety of car, tent, and group camp sites) will be represented by a single node in the approximate middle of the camping area:
RV Camp Grounds
Some campgrounds also allow RV's, and will be depicted by a separate node in the approximate middle of the camping area:
RV Dump Stations
In addition, to make sure there are no "spills" in the park, RV dump stations will be tagged as a node on a way with:
For those campground that allow pack animals, the best we can come up with is:
All camp ground features will include:
Beginning in 2013, Great Smoky Mountains National Park requires fee-advance reservation for back-country camping.
Back Country Shelters
Camp Shelters (along the AT) will be delineated using the building feature:
Back Country Sites (Primitive)
All back country camp site features will include:
Mountains, rivers, valleys, waterfalls, springs, minor canyons, rock formations and other points of natural interest. We intend on keeping existing tags, notably the GNIS tags.
There are siginificant changes to the streams that have been mapped in the park. Using the NHD 2.0, there is a 40% increase in the number and length of streams in the park. We intend on keeping existing tags, notably the NHD tags.
We haven't worked out the exact technical proposal for updating streams in the park, but any import/update will consider mimizing the number of nodes per stream in consideration of the fact that NHD imports can cause significant size increase of the OSM database. Using ArcMap to smooth or simplify lines before upload is the likely solution. At this time, after consultation with IMPORT-US list members, we are holding off on stream imports until a methodology is agreed to.Link title
Waterfalls and Cascades
Frequently Asked Questions
One question about what I saw on the wiki page. I can understand not wanting the public to drive on administrative roads, but are those roads closed to hikers as well as vehicular traffic? I can understand keeping hikers off of the roads under normal circumstances but if I was out hiking a trail that crossed an administrative road I'd be pretty confused if the map on my GPS didn't show it. I'd find them useful as navigational references if nothing else. I would think that it'd be useful in emergency situations as well. For example if a group of hikers was trying to evacuate an injured/sick person an administrative road could be a quicker way to get to more advanced medical care. Or for volunteers conducting a search for lost hikers.
There are many trails that follow the footprint of a road bed, and thus, will be shown as a trail. There are few, if any, road beds that are closed to all access, merely some older road beds that are no longer passable for vehicles.
You may get push back on not creating a dedicated import account. Assuming contributors are cutting and pasting data into OSM and using Bing images to verify what is being changed, I don't see a problem. I would add a specific changeset to each upload such as gsmnp_import=yes to help identify the import.
We are in fact disussing how to "tag" edits made by NPS staff, with a demo on 4/29 on how we might implement that. We have identified a need to identify which OSM data is "authoritatively sourced" versus "user contributed", without discouraging user-contributed data. One option is a "NPS" tag, like you suggest. More as this as it develops.
I'm curious about the NHD portion of the import. Out west we have many unnamed streams that are seasonal (intermittent.) In fact they are more numerous than named streams. I would recommend not adding unnamed seasonal stream. They don't add much value and I understand that if all were added the OSM database would probably require additional storage space. .
We plan on including the same streams that we are conflating into the NHD "Local" resolution. To my knowledge, we haven't mapped any ephemeral streams. Most streams in the eastern-us are unnamed, and most of the stream updates involve a realignment of streams shown in the original NHD, versus adding previously unmapped streams. We consider a "new" stream for local resolution NHD if it meets the intermittent or perennial definition in the North Carolina Stream ID Manual Version 4.11. We are not mapping emphemeral, or "dry" seasonal streams. Our NHD update is being performed in conjunction with the states of NC and TN, with the technical assistance of the USGS, so the stream edits are going to hit OSM one way or the other.
This sounds like a great undertaking, and one that will be useful for the community. I'm working on a Maryland State Park import and have been reading through the wiki and reconsidering some tags. Have you looked into the boundary=protected_area tag? Certainly, the boundary data for the park is already in OSM, but there may be individual areas within the park that are protected to varying degrees. I'm interested in the different protect_class levels, and what they might mean for the NPS. You might be able to add such areas to the map.
We're not going to dive into the very sensitive boundary issues with this project. Legally, boundary updates/edits by and for NPS units can ONLY be performed by a licensed surveyor. All we do is download it from the NPS.GOV web site and use it in our maps. Public OSM contributors are free to add/tag/edit boundaries as they wish. More: