SPDSS_Task95-1_EvaluateSpatialData_20050105

Home Browse Search

must be checked for precipitation and temperature data types. These layers can be made available with the other spatial data layers. The attributes for these layers should include only basic information including station identifier, name, and location information. See the HydroBase recommendations below for possible enhancements that could lead to additional attributes. Climate data are chosen for the additional layer because they are used by a number of software tools and required software changes were previously evaluated with success. Evaluate whether the CDSS modeling framework provides the proper level of detail for modeling tasks. For example, can StateDMI, TSTooI, StateCU GUI, and StateMod GUI utilize separate precipitation, temperature, and evaporation stations? Feedback from modelers should be obtained and, if appropriate, these tools should be updated in SPDSS Phase 3 to support additional spatial data. For example, StateDMI and TSTooI could display precipitation, temperature, evaporation, and streamflow station layers to help users evaluate data issues in time series. Although these capabilities already exist, the GeoView project files for these applications are not distributed by default. Modelers need to utilize the tools as appropriate. Modelers should not be forced to determine ways to view standard data but instead should be able to quickly utilize standard data in commonly used CDSS tools. • In StateView/CWRAT, evaluate whether additional spatial data layers are needed. For example, a few users may be interested in seeing the locations of precipitation and temperature stations on a map; however, if such information is not needed by most users and/or leads to confusion due to HydroBase limitations, it may be best to utilize the additional layers with TSTooI or ArcView software. • Evaluate whether additional layers are useful. The recommendation in this memorandum is to distribute layers for precipitation, temperature, and evaporation stations. However, layers could also be produced for snow, wind, solar, and other data types (e.g., see the TSTooI HydroBase Input Type appendix for a list of data types). Producing new layers will require making additional changes to the ArcCDSS tool. Additionally, the following recommendations are made related to the HydroBase design: • Consider changes to the structure and station tables so that the same identifier is used for real- time and historical locations. For example, would it be possible to use the WDID for gaged diversions, rather than the eight character abbreviations? Alternatively, use the WDID for the station identifier and use the abbreviation for the eight-character identifier. This would simplify the join between spatial and relational data. • Consider identifying real-time diversion records as a different data type that can be distinguished from streamflow records. This could simplify determining the relationship between real-time and historical data. • Consider converting all real-time data into historical records. This would eliminate the need for users to capture real-time data for administrative gages and process into historical records, potentially with conflicting results. • Consider making all real-time data available in HydroBase to allow end-users to utilize the data for decisions, as appropriate. This may require additional changes in StateView/CWRAT and TSTooI because these data types may not have been available during other development efforts. Ideally, the additional real-time data would also be transferred to historical records as indicated in the previous item. A number of real-time data types are supported by TSTooI but very little data were actually available for development and testing. Page 4 Of 5 ~RTversfde TeChnafogy, Inc, W.~fe: Resources Er`gineering and C.onsufting