A few first steps towards calculating with walls

Rudolf

The Tygron Platform is optimized for spatial calculation based on 2D data. Constructions are polygons, water stress we model on a grid, and even points and lines are (unless they are abstract concepts) converted to polygons through buffering. However, sometimes you might find you want to approach a certain challenge from a different direction. It's encouraged to think outside the box, as most problems really can be solved, albeit perhaps in a slightly more roundabout way.

What if you need to know the exposed walls of a construction?

For context, a question from @jpueyo came up regarding vertical gardens. Using the walls of a construction to plant gardens and provide green-related benefits to the environment. His use-case had 2 manageable constraints:

• A vertical garden should only count the walls of a construction. Not the full lotsize.
• A vertical garden cannot function if that wall is right up against another construction.

We can approach the definition of a wall with a bit of 2D math. Imagine we have a generic polygon. We want to know approximately how much edge this box has.

However, we cannot query the line directly. What we can do, is draw a slightly larger box around it.

If we know exactly how much larger the second box is, we can:

Subtract the smaller box from the larger box, leaving us with a line with an approximately fixed width.

Divide the surface area of the line by that fixed width, to obtain the approxiate length of the line.

So that would give us the an approximation of the circumference of the box we started with.

We can automatically create such a box using a distance zone in Tygron. Try the following steps:

1. Add a construction to your project, and draw it somewhere in the 3D world
2. Add an attribute "WALL_DISTANCE" to the construction, with a value of 2
3. Add a Distance Zone Overlay to the project, and set it's distance key (the attribute it's looking for) to WALL_DISTANCE
4. Set the grid size to 2 meters
5. Notice that the overlay highlights the cosntruction red (distance = 0), and an area around it green (distance is more than 0). There's your line! You can query the surface area of that line by using the following query:
6. SELECT_LANDSIZE_WHERE_GRID_IS_3_AND_MINGRIDVALUE_IS_0.1
7. Divide the result by 2 (the width we've configured for the distance zone), to get a fair approximation of the length of the walls.

My construction was 50m by 50m, which should have an edge of 400m. This method gixes 416, which isn't exact, but is a reasonable approximation.

So for a free-standing construction, this can help approximate the length of walls. Looking at the second constraint, the walls should not be up against another construction. If we say that "2 meters" is too close by, then we're already haldway there. Because we can easily query how much of the surface area of the land that we find is in fact occupied by another construction:

SELECT_LOTSIZE_WHERE_GRID_IS_3_AND_MINGRIDVALUE_IS_0.1

So try the following:

1. Run the following query SELECT_LOTSIZE_WHERE_GRID_IS_3_AND_MINGRIDVALUE_IS_0.1, and note that the resullt is 0.
2. Now add another construction to the project, right up to one of the walls of your first construction.
3. Rerun the query, and you will see some lotsize was found.
4. Subtracting this found lotsize from the total landsize of the entire line, yields only as much line as _isn't_ blocked by aother construction.

Now, this approach isn't complete yet. What if the construction is next to a road? or a park? You'll have to fine-tune the query so that only the "blocking" functions or categories are found. But this I leave as an excersize to the reader ;).

See if you can recreate these steps, and experiment from there!

jpueyo

Hi,

I suppose that the solution is doing and additional query filtering the category (roads, parks or whatever) and adding the length to the result or the previous query. However, this implies doing a new query for any category that is not interfering with green walls (roads, gardens, parks, agriculture...). I believe it will be easier doing a query just filtering buildings with height > 0, something like this:

SELECTLOTSIZEWHEREGRIDIS_3_AND_MINGRIDVALUE_IS_0.1_AND_ATTRIBUTE_IS_HEIGHT_AND_ATTRIBUTE_MIN_IS_0,1.

This will calculate only the lot size for buildings that are interfering with the green walls, saving a lot of additional queries.

In addition, what about if we have a building with 4 floors and closeby one with one floor. The green wall could be constructed in the 3 upper floors, but I guess Tygron is not able to consider this casuistic, am I right?

Thank you for your tutorial! Really insightful.

jpueyo

Green walls are intervening in several indicators. So I was wondering if I can use an excel to calculate the surface of green walls in the city and update it as a global value. This way, with one query in the different excel indicators I could get the green walls surface and add to the rest of green surfaces, for instance, in water storage indicator or in the green area indicator.

I'm also was wondering how it should work in relation to heat effect. The heat effect of the roof (which is the one considered by Tygron) is not changed by green walls, but green walls have an obivous influence on heat island. So, how could I consider green walls in the heat effect indicator?

Thank you.

Rudolf

Interesting questions!

There is some trickyness when considering buildings of different heights next to one another, as there isn't really a "height" attribute for constructions. Constructions do have a floor height attribute (FLOOR_HEIGHT_M), and you can retrieve a lotsize and a floorsize and divide one by the other to get the amount of floors, which combined with the floor height attribute would allow you to compute a construction height. But that approach is fraught with its own rabbit holes as well (many more queries, can't average all constructions in a given area due to varying sizes, what about constructions with sections of varying heights, etc). I would recommend an approach of simplification and consider the entire wall blocked. Both for your calculation model setup, as well as for the expectation or understanding of your end-users.

Heat effect is an interesting one as well. For this question too, I would ask you to explore how simple you can make it before descending into gibberish. For any construction, you could perform the calculation, determine how many green walls it has, and store the result as the attribute of the construction. However, this is infeasible in dynamic session where constructions can be created and demolished at will. You could also perform the calculation per neighborhood and store the results per neighborhood. You might be able to add that result to the heat effect indicator's overview of heats and scores. Or, if you really want to factor it into the overlay's calculations, use an UPDATE_BUILDINGS_WHERE_NEIGHBORHOOD_IS_... query to write an average heat effect to all construction in the area. But in that route we already approach a challenge of averaged heat effects being less realistic.

Either way these questions do require careful consideration to get to a sufficient implementation, but it will be one where some concession needs to be made.

Hedi

Some more context can be viewed here:

You can click to the subject 'vertical garden' at 52:55 using the shortcut in the comments.