UMEP-dev / UMEP-processing

GNU General Public License v3.0
7 stars 9 forks source link

Urock prepare: building footprint optional? #77

Open b-kode opened 6 months ago

b-kode commented 6 months ago

Hi @j3r3m1,

After trying the UROCK tutorial with Annadel data, I am now following the Urock steps with my own data. When running Urock prepare, without providing a building footprint dataset (as this is optional), I realized the building_urock.shp file is not created.

First I thought I made a mistake somewhere, in path definition. But then I did the same thing again with the tutorial data, again leaving out the building footprint dataset. Also here building_urock.shp file is not created.

I thought that in the case the building data layer is not provided, it would be created from the dsm - dem? But seems not?

Also, going further with actually processing Urock, I noticed that the Building polygons field is optional? Same for the vegetation field. The latter I can understand. But without knowing where the buildings are (and their height), then I am not sure what is being calculated?

So I guess my question is: How should I create the building footprint shapefile? In previous SOLWEIG steps, a building.tif file was created. But did I miss a part where the building footprint shapefile is created, that I can use in URock prepare to create the building_urock.shp file?

biglimp commented 6 months ago

I think this is a misstake from our side. A building footprint is required. We will change this in the next version.

b-kode commented 6 months ago

And is the creation of the building footprint layer an outcome of a previous step (that I missed?), or should this just be created by the user (eg. using the landcover, dsm, and dem data)?

j3r3m1 commented 6 months ago

As long as one may want to process a whole city with areas without building, it is not an error but made on purpose for areas only consisting of vegetation.

However, I see where is the misunderstanding: URock is a vector based model, thus we need as input a footprint and as attribute the building height (for now, all buildings are considered flat...). Thus the current preprocessing is actually quite simple: we calculate the diff between DSM and DEM within each building footprint provided by the user. We should warn a user who provide a DEM and a DSM without building footprint that there will be no building dataset as output.

biglimp commented 6 months ago

And is the creation of the building footprint layer an outcome of a previous step (that I missed?), or should this just be created by the user (eg. using the landcover, dsm, and dem data)?

The user need to have this layer. If you dont have it you can try download from OSM data using the DSMGenerator (or just download separately).

b-kode commented 6 months ago

The user need to have this layer. If you dont have it you can try download from OSM data using the DSMGenerator (or just download separately).

Ok, understood.

There are of course various ways to try to get building footprints.

But, in case a user is interested in developing spatial thermal comfort, than the building footprint should be consistent between what is used in SOLWEIG and Urock, correct? So in that case it makes sense to develop the building footprint layer from the LC data used in SOLWEIG, where it is also used to create the building.tif file in case "save generated building grid" is set?

Along these lines: perhaps this could be an additional feature in SOLWEIG, to store the building footprint vector layer already at this step, to be used in subsequent steps. Analoguous to saving some files that are relevant for Treeplanter?

biglimp commented 6 months ago

Sounds like a good idea. I will think on how to do this in a good and consistent way.

j3r3m1 commented 6 months ago

Sounds like a good idea. I will think on how to do this in a good and consistent way.

We can discuss this point if you think we try to have a more generic way of creating the spatial data used in UMEP.