Page Comparison

Input data is specific to the component models that you use, but typically consists of climate, topography, land use, rainfall, and management practices. Examples of these are provided in Tables 1 and 2.

Table 1. Model calibration and validation (required data sets)

Base layers and data	Common data formats	Description and use
Observed flow data preferably at the same time-step as model	Time series	Typically, you can use daily time-step gauging station data (ML/day or m3/s) in the hydrological calibration/validation process, or as a substitute for modelled runoff as an observed flow time series at relevant nodes. You need to assess the length of time for which records are available, data quality and data gaps to determine how useful the data sets are for calibration/validation. It is preferable to have data sets that are at least 10 years in duration and that cover both wet and dry periods. Image Modified When extracting gauged flow time series data from databases such as HYDSTRA (commercial software used across Australia for archiving gauge data), it is important to align the time bases for flow with other climate data sets. For example, SILO data is collected each day at 09:00am, so each data point is the total rainfall for the previous day. Therefore, when extracting flow data from HYDSTRA, ensure that the "end of day" option is selected, so that the flow data will align with the SILO rainfall data. It is important to understand the conventions used by your organisation as well as those that send you data - they may not be the same!
Observed water quality data	Time series	Data used in the water quality calibration/validation process. You need to assess the length of time for which records are available, data quality and data gaps to determine how useful the data sets are for calibration/validation. It is preferable to have data sets that cover both storm event and ambient conditions that include both wet and dry periods.
Existing reports	Report or spreadsheet	Existing reports for the region may assist in hydrology and water quality calibration process, eg. load estimation.

Table 2. Optional data sets

Optional data sets	Common data formats	Description and use
Visualisation layers (eg. roads, towns, soils, streams)	Polygons, polylines or points	You can add (drag and drop) additional layers into the Layer Manager and turn these layers on or off as required. These layers are not used in model development and are more a visualisation tool. The layers need to have the same projection and resolution as the DEM or sub-catchment map (but can have different extents).
Aerial and satellite imagery	Image	Image Modified You can use aerial or satellite imagery to ensure the node-link network generated (either drawn manually or generated by Source) is correct. You can also use imagery to check the accuracy of the DEM-generated sub-catchment map. The layers need to have the same projection and resolution as the DEM or sub-catchment map (but can have different extents).
Local or relevant data on best management practices	Reports or spreadsheets	This includes information on locally-relevant best management practices that could be used when creating scenarios.
Existing hydrology and water quality reports and data	Relevant format	Image Modified Existing reports for the region may help when you parameterise water quality models (eg. EMC/DWC derivation. For example, an existing IQQM model of a region that uses the Sacramento rainfall runoff model can be used to parameterise a Sacramento model in Source. Climate data sets may be used to speed up calibration of rainfall runoff models.

Note that all spatial data must use the same supported projections:

...

Table 3. Building models (required data sets)

Data formats

For gridded spatial data files, formats should be in ESRI text format (.ASC) or ESRI binary interchange (.FLT). Vector data should be in shape files. Gridded rainfall data can be ordered from either:

...

Table 4. Zero-padded data (sorting example)

Anchor
DateFormat DateFormat

Time and dates in data files

The TIME framework (used by Source) uses a subset of the ISO-8601 standard. The central part of this subset is the use of the format string:

...

The TIME framework will always write dates in the following format and it is recommended that you follow the same format and use zero padding within dates. For example, "2000-01-02" is preferred over "2000-1-1" to avoid ambiguity.:

yyyy-MM-dd

Annual data can often be entered by omitting a day number and using month number "01" (eg 01/1995; , 01/1996, 01/1997).

Where a date-time specifier only contains a date, the reading is assumed to have occurred at time 00:00:00.0 on that date.

...

• If the format is ISO 8601 compliant, this format will be used to read all subsequent dates;
• Failing that, an attempt is made to detect the dates and time-step with English-Australia ("en-AU") settings, for backward-compatibility reasons; and
• Last, the computer configuration is used for regional and language settings.

Possible problems with time-steps

Incorrectly-formatted date and/or time entries will result in errors if Source is is unable to interpret your data file. You may also need to check your data if you use an ambiguous date format rather than the recommended ISO-8601 format. 

There are two known problems where a time step may be incorrectly detected. First, when reading a file on a computer with U.S settings, because of the mm/dd/yyyy date format. This may happen if the whole of a daily time series covers less than 13 days, or less than 12 months for a monthly time series. Users working on such computers should use the recommended ISO 8601 format to prevent ambiguity. Second, when reading a file which has years in two digit format (eg. 30/01/99) instead of four digit format (eg. 30/01/1999).  

Examples

Parsing the following file would raise an exception. Missing entries are not allowed since their interpretation may lead to ambiguities (ie. missing data, or zero record).

2000-01-01,0.9
2000-01-02,2.2
2000-01-05,1.1
2000-01-06,1.1

The following file, generated with Excel, will be recognised as a monthly time series on a computer with U.S culture (locale) settings, but loading it on a computer with different culture settings will likely fail:

01/01/2000,0.1
02/01/2000,0.8
03/01/2000,0.6
04/01/2000,0.9
05/01/2000,0.6
06/01/2000,0.4
07/01/2000,0.6
08/01/2000,0.2
09/01/2000,0.8
10/01/2000,0.6
11/01/2000,0.3
12/01/2000,0.1
01/01/2001,0.389
02/01/2001,0.389

...