Click on your picture in the top right corner, go to Preferences and select your notification preferences.
Please keep in mind:
1. To only comment on the topic where the discussion is about. Do you have a new question or topic? Please start a new discussion.
2. Be kind to other users!
Buildings within range
A question we sometimes get in regards to spatial calculations is why a building is only partially covered by a given result. And sequel to that: how to properly create a map or other result of which buildings (not just parts of buildings) are touched by a spatially calculated result, such as a Travel Distance.
The basis to make this possible is trivial: a TQL UPDATE statement can be used to write an Attribute value to all Buildings which have a certain grid value overlap with them. However, it will quickly also become neccesary to not only write an attribute to buildings when it overlaps with a certain value, but also to undo that attribute when a building does not overlap with that value. In theory, this would simply require the use of 2 TQL statements: one to set the attribute if it overlaps, and one to unset the attribute if it doesnt.
The challenge currently lies in an order of operations. Queries are generally not explicitly sorted before execution, which means there is some uncertainty as to their order of execution. In an ideal case, Buildings would first have their attribute set to 0 to "reset" them, and then to "1" if they have any proper overlaps with the desired result.
The most stable way to create this logic is through the use of an API Trigger. Using Tygron's (BETA) Trigger library, it's possible to start (and/or end) each calculation cycle with a specific set of TQL statements. You can try this out yourself as follows:
- Open the Demo 3-30-300
- Add an Average Overlay, with an averaging distance of 0, and set for the Attribute "R300IN_RANGE".
- Add a "Before" API Trigger.
- For the "url" of the API Trigger, enter the following:
https://triggers.utils.tygron.com/task/?trigger=Verbatim&echo={
"UPDATE_BUILDING_R_300_IN_RANGE_WHERE_GRID_WITH_ATTRIBUTE_IS_OVERLAY_RULE_300": 0,
"UPDATE_BUILDING_R_300_IN_RANGE_WHERE_GRID_WITH_ATTRIBUTE_IS_OVERLAY_RULE_300_AND_MINGRIDVALUE_IS_1.0_AND_CATEGORY_IS_SOCIAL" : 1,
"UPDATE_BUILDING_R_300_IN_RANGE_WHERE_GRID_WITH_ATTRIBUTE_IS_OVERLAY_RULE_300_AND_MINGRIDVALUE_IS_1.0_AND_CATEGORY_IS_NORMAL" : 1,
"UPDATE_BUILDING_R_300_IN_RANGE_WHERE_GRID_WITH_ATTRIBUTE_IS_OVERLAY_RULE_300_AND_MINGRIDVALUE_IS_1.0_AND_CATEGORY_IS_LUXE" : 1
}
- Recalculate the Session, and then recalculate the session again.
- The results of the Overlay should now show fully-colored-in buildings of categories SOCIAL, NORMAL, and LUXE, where they overlap.
- Switch to the future design, and activate the measure available in the action menu.
- After the plan is activated in the 3D world (and the resulting recalculation has completed), recalculate again.
- There are now additional buildings colored in.
- Deactivate the measure.
- Again, wait for the plan to disappear from the 3D world (and the resulting recalculation has completed), and then recalculate again.
- Notice the buildings which were colored due to the plan have now lost their coloring.
What the trigger does is set the attribute R_300_IN_RANGE to 0 for all Buildings. Then, the next queries look at the overlay with the attribute "RULE_300" (which is the overlay with the results of the "rule 300" travel distance claculation). All buildings which are at least a bit overlapped with the calculated travel range get the R_300_IN_RANGE attribute set to 1. The result is that all buildings within travel distance, and only buildings within travel distance, get the specified attribute.
Although this approach is not yet ideal (requiring 2 calculation cycles instead of 1), it is a reliable way to perform this particular operation with minimal overhead.
Sprawling spreadsheets so intricate Alexander the Great cuts them in half.