Rachel Ramirez 2018-02-21

• 1.1 Provide a short name (either a single word or an acronym) for the analytic you plan to develop. NPS National Park Service (NPS) acoustic summary data

• 1.2 Provide a brief title (1-2 sentences) describing – at the 50,000-foot level – what your analytic does. Your title should be short and to the point, but should also be clear to an end user: Interactive Visualizer for National Park Service Acoustic Summary Data

• 1.3 Provide a description (2-3 paragraphs) of why this analytic data product will be useful for an end-user. This description should address the following points (where applicable): There are many variables in the National Park Service acoustic summary data, thus many ways to do exploratory data analysis or visual analysis. Even if an end-user owns JMP or is an expert programmer, taking time to code and visualize all the different ways to view the variables will take a long time and the time spent coding is wasted when one can be easily manipulating the data interactively.

  • 1.3.A Describe each of the features that your analytic will perform when complete: The “NPS” package/Shiny app will allow a novice to start tinkering with the dataset by location, season, specifying the amount of land type, the distance to different features, and incorporate acoustic summary data like frequencies, decibels, and equivalency acoustics.
  • 1.3.B Describe the typical end-user for whom this analytic is being developed: The typical end-user is anyone interested in viewing the acoustic summary data of the National Park Service.
  • 1.3.C Describe any specific knowledge/skills/abilities an end-user must have to use your analytic: The end user does not need to have any specific knowledge/skills/abilities, but a basic understanding of acoustic terms and geospatial variables may help.
  • 1.3.D If your analytic implements known statistical methods, specify them: **The analytic is mostly visual and will not likely implement any statistical techniques. **
  • 1.3.E If your analytic builds on existing statistical methods or R packages, specify them: The NPS analytic may need ggplot2, and different interactive visual packages such as map packages.

• 1.4 How will end-users access your analytic data product? End-users will access the NPS analytic via github or public webpage.

• 1.5 Are there any security concerns that need to be addressed? No security concerns need to be addressed.

• 1.6 Are there any appearance/design constraints that your analytic must adhere to? There are no known appearance or design constraints, however it would be nice if the data-analytic could adhere to the color-guidelines given in National Land Cover database for Land Cover Land Use Category Indicators. Those colors are provided by Red-Green-Blue schemes that may help an end-user visualize geographical data more easily.

• 2.1 Review the features you listed in Section 1.3.A. Construct a table with the following information
  • 2.1.A. The description of the feature
  • 2.1.B. A rank ordered priority number for this feature
  • 2.1.C. The status of the feature – should be either ‘finished’, ‘in-work’, or ‘not started’
  • 2.1.D. What value will this feature provide to an end-user?
  • 2.1.E. What input(s) must be provided by end-user to perform this feature?
  • 2.1.F. What output(s) will this feature return to the end-user?
  • 2.1.G. What do you envision an end-user will do with the output of this feature?
  • 2.1.H. Is there sufficient time to deliver this feature prior to the deadline?
  • 2.1.I. Does this feature need to be included in the current version of your analytic or can it be pushed to a future update?