PostgreSQL for calcs with geogrphic data

1. The magic of PostgreSQL view tables

2. What is the task?

5. Existing System

8. How can we improve?

9. 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.

10. Tables:
1. indoor_water_demand: constants for demands
and percent reduction based on landuse
2. landuse: landuse lookup table
3. scenarios: building and landscape data for
parcels; multiple entries per parcel are allowed
4. sites: parcel boundary and site information
(contains geography)
5. spatial_ref_sys: default PostGIS table

11. Sites versus Scenarios:

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

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

14. Views:
1. geography_columns: default PostGIS table
2. geometry_columns: default PostGIS table
3. raster_columns: default PostGIS table
4. raster_overviews: default PostGIS table
5. scenario1_calcs: calcs for water demand and
reduction based on landuse, summed by parcel
6. scenario1_iwd: sums GFA by landuse per parcel
and joins to indoor_water_demand table
7. scenario2_calcs: calcs for water demand and
reduction based on landuse, summed by parcel
8. scenario2_iwd: sums GFA by landuse per parcel
and joins to indoor_water_demand table
9. sites_scenario1: joins calcs to geometry for map
display
10. sites_scenario2: joins calcs to geometry for map
display

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

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

17. 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).

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

19. 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.

20. In GIS

21. 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.

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

23. 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.

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

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

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

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

28. Annual design reclaimed grey wastewater supply…

29. In the Browser

33. Twitter: @bondaharper
Email: bond.harper@arup.com