Workflow: DTE/4PEDs Viewer

[anderslogg]

Workflow for supporting DTE (energy viewer). See workflows/workflow_dte.py in DTCC module.

Questions to be answered:

Overview: Explain what the overall idea is

Input data: List input data, file formats etc in detail. How to obtain the data? Also attach example data to this issue.

Output data: List input data, file formats etc in detail. How is the output data used?

How is this done today: Explain the workflow as it is today with existing tools.

Comments: Any comments? How would this work in an ideal world?

[andreasrudena]

Overview:

The scenario data of Gothenburg buildings are currently built into tiles containing (too) much information about the different indicators and result from the simulations. We need to off-load the tiles with a geospatial database accessible through an API so that the client can fetch scenario data dynamically.

Input data:

Data is based on 1. GeoJSON (from Shapefile) with buildings of Gothenburg and 2..n. Scenario data that maps to the buildings with id. The data has two version depending on if is the current state of the city or the future state of the city, e.g:

• 1.a Buildings of "today" (2018 or so..)
• 1.b Buildings of the future
• 2.a Climate scenarios for city 2018
• 2.b Climate scenarios for city 2050
• 3.a. Renovation scenarios for city 2018
• 3.b. Renovation scenarios for city 2050

.. etc (we have only 2 and 3 above from Claudio, but for example 4. Solar potential is on discussion

(note that 1 is protected by license from Lantmäteriet and cannot be hosted publicly)

On top of this there are 6 aggregation boundary levels represented by GeoJSON:

• 3 different administrative borders
• 3 levels of grid

The data should be aggregated by those boundaries so that boundary features are queryable.

Output data:

The buildings should be queried from a REST API (preferably in a standardised way)

• Building data by one or several ids
• Building data from bounding box or polygon (including the aggregation boundaries mentioned)
• Building data by property values (different level of measurements) .. etc

(The tiles are not taken into consideration at this stage of discussion)

How this is done today?

1. Data is loaded and mapped to merge the attributes from scenario data to the building polygons of the features
2. The attributes a aggregated into statistical values and put on aggregated boundaries
3. Colors and some other values are precalculated for different indicator levels
4. Tiles are generated to file
5. Tiles are hosted on a tile server

Ideal world?

1. Create different processes to be run in data pipeline workflows
2. Allow for reusable indicators (and project specific indicators)
3. Generate tiles and host them from a tile server API
4. Load data into one or several databases and give access to the data through standard REST API
5. Let the user modify parts of the data depending on need (might need to rerun pipelines)

Comments

• This does not take into consideration the comment system, where users can click on a building and write comments visible to others (in realtime). This might need a separate discussion as it is more connected to the "IoT"-parts of the platform.

[andreasrudena]

@vbassn A new dataset of scenario data arrived recently. Better check directly with Claudio to get access directly to the source.