We propose that we continue to develop the two prototype IMS applications that were previously outlined; 1) ParkLocator - as a Navigation tool to zoom/pan identify & query NPS units, link to ParkAtlas, and link to the traditional NPS webpages. Visually the ParkLocator should look and feel like the National Park System Map and Guide (www.nps.gov/carto/data.html) as developed by the Harpers Ferry Center (HFC). And 2) ParkAtlas that should look and behave like an electronic version of the traditional NPS Brochure as developed by the HFC (e.g., http://data2.itc.nps.gov/hafe/hfc/carto-detail.cfm?Alpha=YELL or http://data2.itc.nps.gov/hafe/hfc/carto-detail.cfm?Alpha=ANTI).

ESRI et.esri.com/nps review with respect to:

How will this effort fold (link) into www.nps.gov? We need to have a product that is much closer to production before addressing exactly how IMS applications will be linked into www.nps.gov. In this phase of the prototype the ParkLocator featured an entry point from the "FIND ON MAP" link from http://www.nps.gov/parks.html. There would be two access points to the ParkAtlas. The simple link would be from each www.nps.gov "traditional" webpage "MAP" link (e.g., www.nps.gov/yell). The other is a continuation of the IMS application ParkLocator when the user has "selected", or chosen to focus on, a specific Park Unit.

What design scheme or "skin" do we use? To stay mainstream and National Park Service focused. We recommend NPS Brochure layout as basic format in conjunction with the NPS Messaging Project ( http://www.graphics.nps.gov/). We want to stay focused on the NPS messaging project and use our energy and resources in the creation of usable capabilities.

The ParkLocator is the application that was linked to http://www.nps.gov/parks.html "Find On Map" link. The application makes use of the functions of: zoom, pan, query of layers, identification of features, and hyperlink to ParkAtlas ("zoomed" to appropriate NPS Unit extent).

Look & Feel Visually the ParkLocator should look and feel like the National Park System Map and Guide developed by the HFC ( http://data2.itc.nps.gov/hafe/hfc/carto-detail.cfm?Alpha=nps). These are defacto standards and widely recognized in both the public and private sectors. The same standards follow with respect to issues including projection of data and representation of geographically dispersed entities (i.e., HI, American Samoa, AK out to the end of the Allutian Chain, Puerto Rico, etc.).

In addition we have the federal accessibility requirement standards and NPS usability guidelines (http://www.nps.gov/access/new.htm) which we are required to conform with.

• zoom - default IMS capability
• pan - default IMS capability
• identify - default IMS capability
• query - ability to query ParkProfiles data and display the results graphically
• link - hyperlink to extent of identified park unit using the ParkAtlas (e.g., zoom to extent of YELL or ANTI)

Display Layers Based on available NPS data which make up National Park System Map and Guide and augmented with National Geographic and Geography Network data to enhance the user experience (e.g., DRG and/or NHD raster backdrop, Aerial Photography from terraserver, lighthouse soils server, etc.). Data layers need to be tuned for performance and used at appropriate scales.

Default Active Layer NPS Boundary layer related to ancillary tabular attributes (e.g., ParkProfiles MS-SQL DB, NILS, and the like)

Scale Dependency of Layers Basic Cartographic representation of et.esri.com/nps is OK with data clean-up exceptions such as labeling problems in HI, etc.

Theme/Layers, do we need more/less? Both more and less. The et.esri.com/nps/ site shows detailed YELL & ANTI data. The ParkLocator mode should only display layers that are relevant to navigation and identification of NPS units and their attributes (e.g., Road network, NPS Boundaries, Cities), not internal Park data.

Also, explore capabilities such as NHD, aerial photography, Satellite imagery, bathemetry, etc. as backdrops.

Visible Attributes Attributes that are displayed should be relevant either to a query or the NPS as a whole. Displaying every attribute for a layer is overkill (see attached All-Comments under "Visible Attributes" for an example).

Symbology & Rendering The HFC is developing Adobe Illustrator (version 10) styles and symbol pallets for use across the service. These pallets include road symbology and rendering at various scales.

The basic ESRI et.esri.com/nps cartographic rendering is close to the mark. But, we would like better resolution (the county names should include the word, "county" (i.e. Teton County), because in Yellowstone for instance, the Teton county label is right under the Yellowstone label, and if someone doesn't know that it's referring to counties, it might be confusing).

There are two entry points to access the ParkAtlas application. The simple link would be from each www.nps.gov "traditional" webpage "MAP" link (e.g. from www.nps.gov/yell). The other is a continuation from the ParkLocator when the user has " selected" a specific Park Unit

Look & Feel ParkAtlas, or ParkBrouchure, which should look and behave like an electronic version of the traditional NPS Brochure as developed by the Harpers Ferry Center (e.g., www.nps.gov/hfc/carto/YELL.html or www.nps.gov/carto/ANTI.html).

• zoom - default IMS capability, w/ option at scale X in relation the Park unit size get sent back to ParkLocator (e.g., small park [Washington Monument] as compared to a large Park unit [Wrangles St. Elias National Park and Preserve])
• pan - default IMS capability
• identify - default IMS capability
• query - ability to query attributes or combination of attributes across layers
• prominent hyperlink to NPS webpage(s) (e.g., www.nps.gov/yell/)
• hyperlink to source data (inside or outside NPS)

Display Layers Based on available NPS data which make up that National Park Unit's brochure and augmented with National Geographic and Geography Network data to enhance the user experience (e.g., DRG and/or NHD raster backdrop, Aerial Photography from terraserver, lighthouse soils server, etc.).

Default Active Layer NPS Boundary layer related to ancillary attributes (e.g., ParkProfiles MS-SQL DB, NILS, and the like)

Scale Dependency of Layers Basic Cartographic representation of et.esri.com/nps is OK with data clean-up exceptions such as labeling problems in HI, etc. But, augment with Brochure's cartographic representations.

Theme/Layers, do we need more/less? Both more and less? The et.esri.com site should focus on the individual Parks detailed (e.g., YELL & ANTI data). And we would like to explore capabilities such as NHD, aerial photography, Satellite imagery, bathemetry, etc. as backdrops.

Visible Attributes Attributes that are displayed should be relevant either to a query or the NPS unit that is the focus of the query. Displaying every attribute for a layer is overkill (see attached All-Comments for an example). Unique park legend elements (layers) should not have layers from other parks.

Symbology & Rendering The HFC is developing Adobe Illustrator (version 10) styles and symbol pallets for use across the service. These pallets include road symbology and rendering at various scales.

The basic ESRI et.esri.com/nps cartographic rendering is close to the mark. But, we would like better resolution (the county names should include the word, "county" (i.e. Teton County), because in Yellowstone for instance, the Teton county label is right under the Yellowstone label, and if someone doesn't know that it's referring to counties, it might be confusing).

• NPS involvement in Application Development (involve NPS personnel on site at ESRI or ESRI personnel at NPS facilities)
• NPS involvement in Data management. Need to collaborate on DataBase schema for each layer.
• Updated understanding of evolution Geography Network (Hardware, OS, Software, etc.) Please provide list of HW/SW and what portion is housing NPS data. Need to know long term Geography Network plans to guide future development.
• recommendations for maintaining NPS parallel environment to the Geography Network scaled appropriately to NPS use and needs
• how are these applications to be integrated into ESRI's Geography Network
• methodology for NPS participation in data, application, and GIU development, implementation, and maintenance
• needs a production schedule for next 6 weeks and then for rest of the life of this contract phase
• mocked up prototype for December 3 demo by Jack Dangermond and Don Nessi at NPS conference Spatial Odyssey