Skip to content

StateDMI / Command / ReadParcelsFromHydroBase

Overview

The ReadParcelsFromHydroBase command (for StateCU and StateMod) reads parcels and related supply data from HydroBase and creates data objects in memory that provide data to other commands, in particular commands with Parcel in the name. This "data map" design provides consistency, increases software performance, allows for data quality control, and minimizes the need for redundant logic in other commands, specifically:

Model / Parcel / Supply Data

Irrigated lands data are digitized using geographic information system (GIS) software, resulting in a spatial data layer for each major basin for a year. The following image illustrates the basic data objects, which rely on the unique identifiers shown to enforce relationships. Ditches are identified using a water district identifier (WDID). Wells are identified WDID if the well has a water right or other administrative data, or a well permit receipt identifier if WDID is not available.

parcel-supply-objects

Parcel and Supply Data Objects (see also the full-size image)

The above data objects do not including modeling constructs such as model identifier, aggregations of structures, etc. The parcel and supply data are loaded into HydroBase and relationships are defined to connect to other information such as structures (ditches and wells), and well physical data. StateDMI software keeps a list of all individual parcels that are part of the dataset, with associated supply information, similar to the original GIS data. Only one copy of each unique year/parcel exists in this list.

The addition of model constructs is represented in the following figure and indicates how parcels are associated with model locations.

model-parcel-supply-objects

Model, Parcel, and Supply Data Objects (see also the full-size image)

Model locations can be a single diversion (single ditch), a diversion system/aggregate that includes multiple ditches, or a well system/aggregate (one or more wells). Currently single wells are not supported and must be defined as a list of 1 well in an aggregate/system. Model locations that are diversions may result in wells automatically being added as supply because diversions relate to parcels, which relate to wells. Parcels can be served by supplies that are in more than one model location. Therefore it is necessary to store the relationship between supply and model location, as shown in the following figure, in order to facilitate data processing.

model-parcel-supply-objects2

Model, Parcel, and Supply Data Objects with full Relationships (see also the full-size image)

Care must be taken to avoid double-counting irrigated area, which would inflate consumptive use and water demand estimates. To account for this, the supplies that are associated with a parcel are handled as follows:

  • The parcel's fractionalal area irrigated by each surface water supply ditch is 1/(number of ditches).
  • The parcel's fractionalal area irrigated by each groundwater supply well is 1/(number of wells).

Consequently, when calculating irrigated area such as for crop pattern time series (*.cds file) and irrigation practice time series (*.ipy), the supplies for the parcel can be processed and acreage summed as necessary, such as by crop type, irrigation method, and whether surface or groundwater supply.

The following is a summary of data objects used by StateDMI to process parcel-related data:

  1. A list of all parcels in the dataset, each of which is uniquely identified by year and parcel identifier.
  2. For each parcel, a list of supplies identified by ditch (WDID) or well identifier (WDID or receipt).
    1. Because StateDMI processes model data, each supply's identifier also allows a reference to the model location that includes the supply (next item).
  3. A list of model locations (StateCU locations or StateMod stations), each of which has a list of the parcels associated with the location.
    1. The list of ditches and wells for each location is defined by the model dataset.
    2. The list of ditches and wells determines the associated parcels (from above).

Therefore, relationships are circular and provide a cross-reference between data objects. The above data are used when processing specific model data files and logic is implemented to ensure that irrigated land is counted only once, regardless of overlapping parcel/supply relationships. Model data files are organized by model location and therefore processing logic typically loops through the list of model locations and accesses other data objects as needed.

Processing Logic

Processing logic uses internal objects defined in the previous section to ensure that the acreage for a parcel is only counted once for consumptive use calculations. Wells can provide supplemental supply to ditches (commingled supplies), and the acreage in this case is only assigned to the ditch.

The following summarizes the processing logic for each model location (StateCU Location) that is processed. Within each top-level step, processing is limited to years that have parcel data that are also in the requested period.

  1. If the CU Location is not a collection (is a single diversion structure), for example corresponding to a StateMod DIV or D&W node:
    1. Read "parcel use" data (HydroBase vw_CDSS_ParcelUseTSStructureToParcel view) for the single structure, which provides the following data:
      • calendar year
      • crop type
      • total acres for the crop type
      • irrigation method
      • structure information
    2. For parcels that are returned, add a parcel record to the data model for each unique year and parcel ID, if not already stored.
    3. For each structure associated with the parcel, add a surface water supply record for the parcel.
    4. Read "well to parcel" data (Hydrobase vw_CDSS_WellsWellToParcel view) to determine if the parcel is associated with wells and for each well, add a groundwater supply to the parcel.
  2. If the CU Location is a collection and the collection part type is Ditch, for example corresponding to a StateMod DIV or D&W node that is an aggregate or system::
    1. For each structure in the collection, run the process as described above for a single diversion part in the collection, which adds parcels and related water supply if not already added.
  3. If the CU Location is a collection and the collection part type is Well, for example corresponding to a StateMod WEL node for groundwater only model node specified as an aggregate or system:
    1. For each well in the collection, read data from the HydroBase vw_CDSS_WellsWellToParcel view, which returns the list of parcels associated with the well and associated well. The well identifier can be either a structure WDID or well permit receipt.
    2. For parcels that are returned, add a parcel record to the data model for each unique year and parcel ID, if not already stored.
    3. Add a groundwater water supply record to the parcel for the well.
  4. If the CU Location is a collection and the collection part type is Parcel:
    1. This case is not currently handled but would be similar to the previous case except that parcel/well relationships would be queried using the parcel identifier.
  5. Else, the input is not understood and a warning is generated.

Command Editor

The following dialog is used to edit the command and illustrates the command syntax.

ReadParcelsFromHydroBase

ReadParcelsFromHydroBase Command Editor (see also the full-size image)

Command Syntax

The command syntax is as follows:

ReadParcelsFromHydroBase(Parameter="Value",...)

Command Parameters

Parameter             Description Default          
ID
required		 A single CU Location identifier to match or a pattern using wildcards (e.g., 20*). None – must be specified.
InputStart Starting year to read data. All available parcel data will be read.
InputEnd Ending year to read data. All available parcel data will be read.
Div Water divisions to process, separated by commas. Specifying this will increase performance slightly. Determine divisions based on location identifiers that match the format of water district identifiers (WDIDs) .

Examples

See the automated tests.

Troubleshooting

The following are troubleshooting suggestions based on experience.

Error Example Suggestion
CU location "10_GW104 part ID "1005163" has HydroBase vw_CDSS_ParcelUseTS (as ditch) and vw_CDSS_WellsWellToParcel (as well) data records. Possible causes include:
  • The original supply source for the parcel was coded as a ditch and a well, where only one should be used.
Error getting well/parcel data for year 2017, receipt=9078680 (java.lang.IllegalArgumentException: The water district (-1) is invalid. Must be 1+). Possible causes include trying to use a well receipt that cannot be found:
  • Water districts for all locations in the dataset are used to determine water districts to query to optimize performance. If a well is in a water district outside of this list of water districts, the SetWellAggregateFromList and SetWellAggregate commands WellReceiptWaterDistrictMap parameter can be used to add additional water districts to process.
  • If the above does not resolve the issue, the well identifier have an error and is not in HydroBase

See Also