Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
NCHRP Project 25-48 8 Project Deliverables The NCHRP 25-48 Project Deliverables were organized into seven tasks. These are described briefly below. Task 1: Assessment of Existing Tools and Design Architecture Task 1 gathered and synthesize information on project-level emissions analysis. Drawing upon established contacts with mobile emissions modelersâin the private and public sectors, academia, and including panel membersâthe RSG-Lakes Environmental team conducted research to define a preliminary architecture for the interface and to inform the stakeholder outreach in Task 2. The features described below include the original software development plan for the TRAQS interface. During the Phase II implementation of the TRAQS interface design changes were made in the interest of completing the project within the constraints of its fixed budget, while also responding to the feature requests from the Panel and other project stakeholders. Finally, the development of TRAQS needed to be responsive to changes in regulatory guidance from the U.S. EPA. Major Functional Design Elements Figure 1 illustrates the major functional design elements and interactions original recommended for inclusion in the proposed software solution. Figure 1. Design Overview The RSG-Lakes Environmental team decided to develop a desktop software solution around a centralized user-friendly GUI that includes the features necessary to complete a Project-Level air quality analysis. The GUI provides the mechanism by which users create new projects, enter model inputs, configure model options, and manage modeling runs, including MOVES, EMFAC, and AERMOD.
NCHRP Project 25-48 9 In July 2015, EPA proposed a rulemaking for the Guideline on Air Quality Models (https://www3.epa.gov/scram001/11thmodconf.htm) to replace the models based on CALINE3 with AERMOD due to the âmore scientifically sounds basis for AERMOD, improved model performance over CALINE3, and the availability of more representative meteorological dataâ¦â. The Project Team discussed the EPA rulemaking with the panel at Software Webinar #4 (July 8, 2016). The panel concurred that the CAL models should not be incorporated into the TRAQS software as this would only take away development resources for other more important TRAQS requirements. Other capabilities include mapping features and a powerful data visualization and extensive reporting module. The GUI was developed following modern industry design standards and relies on intelligent wizards to guide users through the process of conducting a Project-Level air quality study from start to finish. TRAQS, the âTransportation Air Quality Systemâ provides a convenient means of referring to the solution. TRAQS manages the mobile emissions models MOVES and EMFAC, and the air dispersion model AERMOD, while the unaltered regulatory models remain external to the GUI. Keeping the existing analytical models external to the GUI is essential to the regulatory process and will simplify adapting TRAQS when future versions of these models are issued. Further, any limitations of the existing mobile emissions and air quality models, such as the constraint of only being able to model one off-network source in MOVES, is also a limitation of TRAQS. Minimally Acceptable Product Features To facilitate and manage the collection and prioritizing of user feedback (Task 2), it is first necessary to define a set of minimally acceptable product features. This step is necessary before consideration and prioritization of additional features. A set of minimum feature requirements will enable the RSG-Lakes Environmental team to design a more effective outreach program. The online survey proposed in Task 2 will provide practitioners with a basic understanding of what features have already been identified for inclusion in the software. With these objectives in mind, we recommended that the following features define the minimally acceptable product features that the proposed solution must provide: 1. Centralized GUI to seamlessly integrate the process of selecting appropriate mobile emission and air dispersion models, prepare model inputs, configure model run options, execute model runs, and generate results for further analysis and data visualization. 2. Intelligent step-by-step wizards to guide users through the process from start to finish, including creating a new project, entering data, model configuration, model execution (including batch run manager), and results analysis and reporting. 3. Quality assurance tools to provide real-time feedback on data quality and identify data quality issues that are outside anticipated ranges or of incorrect formats, which would cause model run errors. 4. Standard report-ready summary templates specifically designed based on Project-Level documentation requirements. 5. Context-sensitive help. 6. Advanced reporting tools and export options, including common file formats such as MS Excel and pdf.
NCHRP Project 25-48 10 Desktop-Based Application The RSG-Lakes Environmental team recommended that TRAQS be developed as a desktop application. This recommendation is based on careful consideration of requirements specified in the RFP, combined with extensive experience of both companies in developing applications utilizing both desktop and web-applications. The recommendation to develop TRAQS as a desktop application in no way precludes the future option of migrating to a web-hosted solution. A web-hosted solution introduces significant complexity, including: â¢ The requirement for dedicated hardware/software and IT staff to manage a centrally hosted system in an operational environment; â¢ The server performance requirements necessary to accommodate mobile emissions models, MOVES and EMFAC, and AERMOD, require significant hardware/software resources to operate at performance levels achieved by todayâs PC desktop applications; â¢ The requirement for robust hardware with multiple dedicated processors (min: 8 + core I7s); â¢ The requirement for adequate RAM to meet scalable modeling demands (min: 32GB); â¢ The requirement for high-capacity storage (min: 10+ TB) and significant bandwidth requirements for data inflow and outflow demands; â¢ The requirements of air dispersion models for high-performance hardware, especially considering the intended use for performing localized assessments where the resolution of road links can result in managing thousands of sourcesâlocal assessments also generally require numerous modeling runs to estimate pollutant-specific concentrations and evaluate multiple build/no-build scenarios, etc. These factors result in large file sizes that make less desirable the option of transferring project data between multiple users via a centralized web-hosted application for visualization and reporting purposes. In sum, our recommendation is grounded in real-world experience gained in developing and maintaining both desktop and web-based applications for environmental regulatory clients. Although the majority of todayâs modern regulatory agencies have dedicated IT staff that provide a wealth of services, the management of application-specific webserver software solutions introduces additional complexities that most regulatory agencies are not equipped to manage. The use of a client-server desktop application removes IT barriers. This solution allows performance and storage demandsâalong with IT staff costsâto be managed by the user. Distribution as Open-Source Software TRAQS is licensed as an open-source software application following the GPL2 license provisions (or equivalent). In summary, open-source software, following the GPL2 license provisions, provides the license rights to study, copy, modify, and redistribute the source code without copyright restrictions. The TRAQS solution requires the use of multiple open-source software applications and sophisticated programming languages. As a result, the RSG-Lakes Environmental team adhered to rigorous development principles to create a fully functional, bug-free, and maintainable code. These requirements are also fundamental to supporting new functionality and to prevent software code from needing to be partially re- written in order to accommodate minor changes to future model updates or input formats. Based on collective experience working with hundreds of different open-source applications, many of which have significant limitations, the team originally proposed to develop the TRAQS solution using a combination of the open-source applications and programming languages described in Table 3.
NCHRP Project 25-48 11 Table 3. Applicable Open-Source Models OPEN-SOURCE SOFTWARE DESCRIPTION OpenStreetMap (OSM) Open-source mapping solution that provides extensive worldwide map layers such as transportation networks, points of interest, and imagery. Python An open-source, high-level dynamic programming language with extensive libraries and active development community making it one of the most stable and commonly used programming languages in the world; Python is easily configured and embedded in standalone desktop applications. SQL-lite Powerful relational database management system packaged in a small C programming library and one of the most popular imbedded databases for local client storage in application software. SQL-Alchemy Powerful Python SQL toolkit and object relational mapper that provides extensive flexibility and sustainability as classes can be mapped to the database in open- ended, multiple ways, allowing the object model and database schema to develop in a cleanly decoupled way. NumPy NumPy is an extension to the Python programming language, adding support for large, multi-dimensional arrays and matrices, along with a large library of high-level mathematical functions to operate on these arrays. MATPLOT LIB Extensive plotting library for the Python programming language and its NumPy numerical mathematics extension; it provides an object-oriented API for embedding plots into applications, including hundreds of chart types for data analysis and visualization. SciPy Advanced computing environment and open source ecosystem of software for the Python programming language commonly used by scientists, analysts, and engineers performing scientific computing and technical computing; SciPy also refers to a specific open source library/Python package of algorithms and mathematical tools that form a core element of the SciPy environment for technical computing. PANDAS Software library written for the Python programming language to perform advanced data manipulation and analysis; in particular, it offers data structures and operations for manipulating numerical tables, XML-based schemas, and time series data. AERMOD (V15181), MOVES2014a, EMFAC2014, Regulatory emission and air quality models.
NCHRP Project 25-48 12 TRAQS Bug Fixes Typical to the industry, Lakes Environmental implemented a comprehensive test program to verify software functions before deployment and to minimize the introduction of bugs. During the software development process, extensive effort was invested in eliminating bugs or other defects before deployment for beta testing. Lakes Environmental also utilized an issue-tracking and ticketing system to document any observed issues, assign a relevant priority status based on significance level, and assign issues to the development team for correction. Software Development Plan The Software Development Plan (SDP) documented the developer's plans for conducting the software development effort including all aspects of the project. The SDP defined the format and development approach for the software products generated by specific and discrete task requirements. The SDP was intended to provide stakeholders with insight into the processes that were used to complete software development. Key elements of the SDP plan included: 1. Definition of minimum acceptable features 2. Data and process flows 3. UI and database design 4. Alpha mockup 5. Software architecture 6. Test plan 7. Documentation Throughout this project extensive information gathering and synthesis took place to guide the development process. To manage this information, the Project Team maintained a project knowledgebase which is intended to serve as a repository for managing applicable regulatory guidance documents, presentations, example projects, related software applications, and use cases that govern project level analysis. Functionally, the TRAQS interface consists of two primary preprocessors and a postprocessor module. The preprocessors are functionally responsible for managing data for use in the EI models (i.e., MOVES, EMFAC) and ADM model, AERMOD. The postprocessor is functionally responsible for calculating design values, comparison with NAAQS, and aiding in the analysis of build / no-build determination. In addition, the post processor will manage model outputs into a format that can be analyzed and displayed on the map or reported using plots, charts, and tabular reports. The postprocessor is also responsible for exporting data into supported export formats which include MS Excel, PDF, and TXT files. Note TRAQS does not directly support import/export of AutoCAD or MicroStation files. Accounting for all the non-standard meta data that is typically found in AutoCAD files is overly complicated and would require significant development of user selection options and conversion code, which is not necessary and would only take away development resources for other more important TRAQS requirements. The EI preprocessor manages the individual MOVES and EMFAC project files, which, in turn, manage output from traffic simulation models and other required vehicle input variables for each road âlinkâ including total vehicle hours traveled (VHT), distribution of VHT by vehicle type, average speed, grade, road type, a link drive schedule or an operating mode distribution. The EI preprocessor also manages off- network data including vehicle population starts and extended idling (Figure 2).
NCHRP Project 25-48 13 Figure 2. Preprocessor Figure 3 illustrates the primary model outputs including concentration contour plots, charts (e.g., line, pie, bar graphs), and tabular output for common formats.
NCHRP Project 25-48 14 Figure 3. Post Processor The post processor enables users to calculate design values by entering background concentrations, compare these values with NAAQS, and allow users to compare results from multiple project scenarios such as build / no-build scenarios.
NCHRP Project 25-48 15 Task 2: Stakeholder Input The central objective of Task 2 was to implement outreach to an expert community of Project-Level practitioners in order to obtain input regarding the features of TRAQS. Within Task 2, RSG convened a Stakeholder Panel, referred to as the Stakeholder Outreach Group (SOG), to provide ongoing feedback on interface features. Table 4 describes the stakeholder engagement process. Table 4. Stakeholder Engagement Process NCHRP 25-48 TASK ENGAGEMENT PROCESS OBJECTIVE TARGETED # OF PARTICIPANTS 2 Online Survey Definition of Software Functionality 25-50 3 Follow-Up Phone Interviews Obtain Feedback and Greater Detail on Survey Responses 8-12 4 Software Inspection Webinars Obtain Reactions to Software Status 10-25 4-6 E-mail Updates Bi-Weekly Updates to Original Stakeholder Group 25-50 6 Beta Test Sites Independent Testing of Interface, Bug Recording 5-10 Stakeholder Outreach Group The SOG was invited to inspect the progress of the interface within Task 4 through Software Inspection webinars. The Project Team also issued a periodic e-mail (originally planned as bi-weekly) on software progress to any stakeholders who indicated their interest in receiving this information. The Project Team also solicited from the Stakeholder Panel a set of Project-Level case studies for interface testing (Task 5) and beta test sites (Task 6). It was agreed to include all of the NCHRP 25-48 project panel members in this group. In total, a group of 50 professionals were assembled from the following agencies: â¢ NCHRP project panel, â¢ MPOs, â¢ DOTs, and â¢ FHWA (including staff from the FHWA Resource Center Air Quality Team). The SOG consisted of 50 professionals from public agencies and from private sector companies. Additional members were added during TRAQS beta testing. Online Survey We initially engaged the Interface Panel through an online survey. The Project Team drafted the outreach survey after internal review. Ten SOG members were contacted to complete an initial draft of the online survey and to provide comments, of which eight completed surveys were returned with comments. The pretest occurred in October and November, 2014. The survey was finalized and sent out to the 50 SOG
NCHRP Project 25-48 16 members on November 19, 2014. The survey was closed on January 15, 2015. A total of 24 completed surveys were recorded. In addition, three surveys from the pretest in developing the final statistical analysis of the MaxDiff section are used in the analysis of the survey. Based on discussions with members of the SOG and on the Project Teamsâ understanding of the challenges in developing the TRAQS software, a total of 16 attributes were tested. Figure 4 shows the prioritized results from the SOG responses to the MaxDiff section of the survey. Importance values in this chart should be interpreted relative to one another. Figure 4. Results of the MAXDIFF Experiment (n=27) With regard to TRAQS features, the MaxDiff results indicate strong preference for the following attributes: 1. The software should show mobile emissions and air dispersion results on a map. 2. The software should enable comparisons of model scenarios (e.g. no-build/build). 3. The software should support the MOVES average speed approach for inputting traffic activity information. 4. The software should show mobile emissions and air dispersion results in a table. 5. The software should allow editing the network on a map. 6. The software should include context-sensitive help. The Project Team considers the six attributes above to be essential, and these have been incorporated into TRAQS. The MaxDiff results for the remaining features could point to software elements that are discretionary or unnecessary, as further discussed below. Survey Findings A representative group of future TRAQS users, including federal and state DOT staff, state and MPO air quality specialists, private contractors and academic researchers, completed the online survey. The
NCHRP Project 25-48 17 responses of this group to the survey provide good guidance to the Project Team in classifying aspects or features of TRAQS. We consider three classifications as: â¢ Necessary/Essential â (âmustâ statements) â these are discussed below; â¢ Discretionary â would be nice to include in TRAQS v1.0, or in subsequent versions (âmayâ statements); â¢ Unnecessary/Non-Essential â (âwill notâ statements). These include out of scope items. Necessary/Essential Findings 1. TRAQS must support Project-Level conformity analysis, support NEPA documentation, and support other general transportation air quality analysis. 2. TRAQS must support complete modeling â mobile emissions linked with air dispersion â for PM2.5 (annual standard); PM2.5 (24-hour standard); PM10; CO; and NOx. 3. TRAQS must support the analysis of a variety of Project types, including: a. Intersections on unrestricted access highways/streets; b. Ramps to/from restricted access highways; c. Highway segments for an unrestricted access highway; d. Highway segments for a restricted access highway. 4. TRAQS must support the analysis of off-network activity. 5. TRAQS must support regulatory approved MOVES and EMFAC (California only) emission models. 6. TRAQS must support the AERMOD air dispersion model. 7. TRAQS must support the average speed and the operating mode distribution approaches to modeling traffic activity in MOVES. 8. TRAQS must support the use of MOVES defaults for Meteorology, Fuel Supply, Fuel Formulation, Vehicle Types, and Vehicle Age Distribution inputs. 9. TRAQS must support the importing of custom or local data for Meteorology, Fuel Supply, Fuel Formulation, Vehicle Types, and Vehicle Age Distribution inputs. 10. TRAQS must support the use of polygon area sources for off network and Line sources for links when AERMOD is used. 11. TRAQS must support the modeling of one off-network source in AERMOD. 12. TRAQS must support as many receptors as can be modeled in AERMOD. Practical limits apply as model runs times must be considered and vary with performance level of individual PCs. 13. TRAQS must support Uniform Cartesian, Uniform Polar, and Discrete Cartesian receptor types in AERMOD (NOTE: TRAQS supports Uniform Cartesian and Discrete Cartesian receptor designation. Use of Uniform Polar coordinates is extremely rare in air dispersion modeling and not supported by TRAQS). 14. TRAQS must support applicable default regulatory options. 15. TRAQS must support SFC and PFL AERMOD input formats. 16. TRAQS must support inclusion of Background Concentrations when calculating design values. 17. TRAQS must support the modeling of queuing links when using CAL3QHC/R and CAL3QHC 18. TRAQS must support as many receptors as can be modeled in regulatory versions of CAL3QHRC/CAL3QHC (see note associated with Finding 17) 19. TRAQS must support run outputs that facilitate usage/visualization within ArcGIS, Google Earth, and Excel in the form of x,y,z files (NOTE: at the completion of Phase I, the Project Team felt that allowing the user to access mapping through ESRI mapping products would be a useful feature. TRAQS includes a mapping capability that is easy to use, and results in automatically scaled links within defined geographies. With the panelâs concurrence at the July 8, 2016 Software Webinar #4, it was agreed to continue improving the custom mapping features of TRAQS and not to devote
NCHRP Project 25-48 18 remaining project resources on the ESRI and Google Earth mapping capabilities. This limitation applies to Findings 21 and 22 as well). 20. TRAQS must support data import from Excel. 21. TRAQS must support the import of ArcGIS shapefiles for use in defining Project links (specified shapefile format must be followed) (see note associated with Finding 19). 22. TRAQS must support the custom definition of Project links by the user using map-based drawing tools. 23. TRAQS must support conducting a mobile emissions analysis only (unconnected to an air dispersion analysis). For example, NEPA GHG emission modeling. 24. TRAQS must support air dispersion modeling of PM2.5, PM10 and CO. 25. TRAQS must operate on Windows operating systems, versions 7 and higher. 26. TRAQS must operate on a local desktop or laptop computer. Task 3: Phase I Summary With the conclusion of Phase I, the RSG-Lakes Environmental Project Team summarized and reviewed the preliminary work conducted to develop actionable tasks for the software development phase of the project. The Project Teamâs summary included Workflow Illustrations and a Use Case document, and the results of the Task 2 Stakeholder Survey.