Laserfiche WebLink
locations where data are collected and time series are the date/value information collected at those <br />locations. <br />General issues with identifying new spatial data layers that could be created from HydroBase include: <br />• What tools will use the data layers (e.g., is a data layer suitable for general StateView/CWRAT <br />users or is it more suitable for modelers who are preparing data sets with tools like TSTooI and <br />StateDMI)? <br />• What will be the mechanism by which spatial and relational data are linked? Typically, this is <br />through one or more data keys. <br />• What is the granularity of the classification of point features? For example, is it sufficient to <br />describe a point layer as "climate stations" or is it more suitable to have separate layers for <br />precipitation, temperature, evaporation, and other stations? In many cases, the physical stations <br />share an identifier but may provide more than one data type, depending on the sensors that are <br />installed at the station. <br />• Is the main purpose of providing data layers to allow spatial displays and to allow links to other <br />data sources like HydroBase, or is the attribute data for the station more valuable to users or both? <br />For example, if a user is interested in the average monthly precipitation at a station, is it important <br />to include such data as attributes with the spatial data or is it sufficient to provide tools that <br />generate such information from HydroBase, using only the station identifiers to cross-reference <br />the spatial data? <br />• How sophisticated are the end users? For example, will they understand that a climate station <br />might have attributes associated with different data types? Or is it better to split out separate <br />layers so that one layer is associated with one data type? <br />Can HydroBase evolve to meet additional needs of users or should the focus be on generating <br />spatial data products that are derived from HydroBase, but which may not have matching raw <br />data in HydroBase? In other words, GIS users may find it convenient to simply query spatial data <br />layers for useful information. However, if the information is not stored in HydroBase in a similar <br />form, then software development must occur to create the derived data, and there may be issues <br />maintaining the derived data and tools. <br />Considering the above, a fundamental design issue when creating spatial layers for point data is to decide <br />if a single layer should contain attribute data for multiple time series data types, or should separate layers <br />be created. For example, for climate data, the following approaches could be taken: <br />Approach 1-One layer with attributes for each time series data type: <br />Climate stations layer: <br />station_id <br />station name <br />is~recip <br />is temp <br />...other attributes... <br />Page 2 Of 5 ~RTversfde TeChnafogy, lnc, <br />W.~fe: Resources Er`gineering and C.onsufting <br />