Landsize of area with just buildings

Ward van Laatum

Hi hi,

Is there a query to determine the area [m²] of area that contains a building (not roads and gardens)? I tried the Catetegory, but it would mean I'd have to ask for multiple categories. Works probably, but is there a faster option?

SELECT_LOTSIZE_WHERE_CATEGORY_IS_HEALTHCARE_AND_CATEGORY_IS_OFFICES, ect.

Thank you.

Godelief

Hi Ward,

Every building has a BAG_ID attribute (see below), so you can use that to filter the buildings from the roads, gardens and other objects in the Platform.

For example with the query: SELECT_LOTSIZE_WHERE_NEIGHBORHOOD_IS_3_AND_ATTRIBUTE_IS_BAG_ID

Ward van Laatum

Hi Godelief,

Thank you for your answer. However, your sollution is fine, but it doenst help me. Perhaps I should post my follow-up question as a new question, do tell me if I have to.

I am trying to make an overview of the PET temperature for an area. So, in oder to do so, I ask TYGRON 5 questions, one for each temperature limit (shown in the query below with an i).

SELECT..LANDSIZE..WHERE..AREA..IS .. (id area) .. AND..GRID..IS .. (id overlay PET) .. AND..MINGRIDVALUE..IS .. (i)

After subtracting the next value from each value, I get a surface for each temperature (i). (The landsize with mingridvalue of 1 minus the mingridvalue of 23, mingridvalue of 23 minus the landsize of 29, ect.)

But I would like to convert this area to a percentage. A percentage of the specific area. Therefore I also request the landsize of ​​my specific area

SELECT..LANDSIZE..WHERE..AREA..IS .. (id area)

However, the sum of the different perceived temperatures was not 100%. And after looking carefully at the grid (overlay Heat stress) I saw that the buildings had no value (NA). Hence my previous question if I could query the surface of just the buildings.

SELECT..LOTSIZE..WHERE..AREA..IS .. (idarea) ..AND..ATTRIBUTE..IS..BAG..ID

I did that and substracted that surface from the surface of the specific area. Unfortunately, the sum is still not 100% (but rather 85%), see my table below. What am I missing? Could it be that not only buildings, but also other objects are not included in the outcome of the PET analysis?

Godelief

Hi Ward,

Water terrain is also not included in the calculation of the Heat stress. If you also query the landsize of water in your project and add that to the other values, do you then get 100% ?

Ward van Laatum

Hi Godelief,

No, still not a 100%. Below the area I am checking. And below the image my results.

I did look at the grid again (overlay Heat stress). And not sure if this is related but there is some terrain (in this case grass) that does not have a PET.

RudolfNL

Hi Ward,

to ensure that this thread contains the answer to the question posed I'll write what I've also explained during our live support session.

The inequality is caused by the difference between vector data and rasterized results. Vector data, such as the polygons of constructions and the polygons of water terrain types, are very exact. Their position and size is defined with an accuracy of around a centimeter (0.01 meter) or less. The calculation, and subsequent results of the Heat Overlay, are performed on a grid. This means the entire world is rasterized (turned into grid cells), and calculation(s) are performed on the uniform data of each individual cell. This is also the "blocky" effect you see in the results of a calculated grid overlay, especially when the grid cell size is high.

Skipping over much of the details of the calculation, the default configuration for the Heat Overlay (which we've established based on the DPRA report on heat stress), is to exclude constructions and water from the results, as the results may be skewed or difficult to interpret there. This is implemented as a check in the Platform that if a cell contains a construction, it is excluded from results (colored black, and no value is returned there). If a cell is partially covered by a construction or water, the entire cell is excluded.

This is where the difference comes from: If a cell is 100m² (10m by 10m), and a construction covers just over half of it (60m²), then 100m² of the project area does not have a result, but adding the surface area of the construction to that will still leave a 40m² "gap", which is not itself construction or water terrain, but is part of a cell which is excluded due to that rule.

To minimize this discrepancy, your best option is to lower the grid cell size so the rasterization of the project area better approximates the vector data it bases its calculations on. In addition, you can also compute this "gap", and report it explicitly as part of your total "balance". However, it should be stressed that there will always be this gap in the results, as there is an inherent difference between the vector data going in, and the grid form in which the calculation can be performed.

Godelief

See also the corresponding video with Rudolfs answer: