GIS and Water Neutral Design

The magic of PostgreSQL view tables

What is the task?

Existing System

How can we improve?

WaND database:

Consists of 5 tables and 7 views.

The tables store the data related to the site geography, site information, and constants.

The views store the calculations performed based on the data in the tables.

Tables:

indoor_water_demand: constants for demands and percent reduction based on landuselanduse: landuse lookup tablescenarios: building and landscape data for parcels; multiple entries per parcel are allowedsites: parcel boundary and site information (contains geography)spatial_ref_sys: default PostGIS table

Sites versus Scenarios:

sites table:User create this (first step) as geometry

scenarios table snippet:User fills this out as tabular data (no geometry)

Views:

geography_columns: default PostGIS tablegeometry_columns: default PostGIS tableraster_columns: default PostGIS tableraster_overviews: default PostGIS tablescenario1_calcs: calcs for water demand and reduction based on landuse, summed by parcelscenario1_iwd: sums GFA by landuse per parcel and joins to indoor_water_demand tablescenario2_calcs: calcs for water demand and reduction based on landuse, summed by parcelscenario2_iwd: sums GFA by landuse per parcel and joins to indoor_water_demand tablesites_scenario1: joins calcs to geometry for map displaysites_scenario2: joins calcs to geometry for map display

scenario1_calcs view snippet:All this is run by the database automatically as sites and scenario1 are updated

scenario1_calcs view create SQL snippet:Heres a bit of what the create SQL code looks like. It is summing the calculations by parcel number (more on next slide).

scenario1_calcs view create SQL snippet:This shows the nested query (derived table) that calculates the water demand and reductions that are then used in the monthly calcs. This format allows it to be calculated once then reused by the monthly calcs (kind of like a variable).

scenario1_iwd view snippet:All this is run by the database automatically as sites and scenario1 are updated.

scenario1_iwd view create SQL snippet:This code joins the indoor water demand table to the user input scenario data based on landuse. The GFA are summed for that landuse type within the parcel. These numbers drive the scenario1_calcs view.

In GIS

sites_scenario1 view in QGIS:Colors and data will automatically update as the user inputs additional buildings or landscaping into the scenario1 table. Geometry will automatically update to match sites table.

sites_scenario1 view in ArcGIS Pro:First you need to connect to the database.

sites_scenario1 view in ArcGIS Pro:After connecting you can see all the tables and views. Tables without geometry can be added to the map for viewing.

sites_scenario1 view in ArcGIS Pro:To work with spatial tables/views, you will need to make a query layer.

sites_scenario1 view in ArcGIS Pro:Now we have a dynamic connection to our database.

sites_scenario1 view in ArcGIS Pro:In order to keep the data refreshed, well need to adjust the caching. This will auto-update the data, but if any fields change, the query will need to be re-run.

With linked views in ArcGIS Pro, you can compare multiple scenarios side by side. Shown below is annual business as usual water demand

Annual design reclaimed grey wastewater supply

In the Browser

Twitter: @bondaharper

Email: bond.harper@arup.com