Testbed tutorial: Difference between revisions

From Tygron Support wiki
Jump to navigation Jump to search
mNo edit summary
mNo edit summary
Line 17: Line 17:
Testbeds can serve the following purposes:
Testbeds can serve the following purposes:
* Quick investigations into how a specific functionality works
* Quick investigations into how a specific functionality works
* Testing for (and demonstrations of) bugs or other issues
* Overview demonstrations of multiple functionalities
* Overview demonstrations of multiple functionalities
* Testing for (and demonstrations of) bugs or other issues
* Forming a baseline for consistency testing
* Forming a baseline for consistency testing



Revision as of 11:30, 30 April 2019

Please note: This page is currently being updated.


Template:Learned

Prerequisites

The following prerequisites should be met before starting this tutorial:

  • This tutorial relies on base knowledge about the editor interface. If you have not yet followed the tutorials related to those subjects please do so first.
  • This tutorial can be followed in an empty project area. 

Preparations

Take the following steps as preparation for following this tutorial:

  • Create a new, empty project, sized to 500m by 500m. Ensure the unit system is set to "International". Also ensure it's an empty project area, not based on a real world location.

Introduction to testbeds

A testbed is a controlled setup, in which there are as few variables as possible which could influence a given situation.

In the Tygron Platform, whenever you create a project based on real-world data, the project is populated with a wide range of data. Virtually every project area contains numerous constructions, height differentials, and terrain types. If any calculation takes place, especially spatial calculations, all that data can serve as input. That makes it a lot more difficult to see exactly how a specific element factors into a specific result, or where the difference between an expected and actual result comes from.

Testbeds can serve the following purposes:

  • Quick investigations into how a specific functionality works
  • Testing for (and demonstrations of) bugs or other issues
  • Overview demonstrations of multiple functionalities
  • Forming a baseline for consistency testing

For this reason, what characterizes a testbed most is the absence of data. Anything that is not requires for a specific case is left out, or at least left in a uniform, invariable state.

Starting point

For each testbed, the starting point is the empty project.

An empty project contains no constructions or terrain features.

An empty project contains the following data:

  • There is a uniform height map, with the height of the terrain set to 1m relative to datum.
  • The surface of the terrain is of the "Open Land" type. The underground terrain is of the "Unknown" type.
  • There is only a single municipal stakeholder, as a stakeholder to select for an editing user. The entirety of the 3D world is owned by that stakeholder.
  • There are 4 neighborhoods (north-west, north-east, south-west, south-east), or if the project area is small, 1 single neighborhood.
  • There is no zoning plan.
  • There are no construction.
  • The upper-left spatial coordinates of the project area are set to 0 degrees latitude and longitude.

Quick functionality testing

Testbeds can be used to test specific implementation questions. The question you're going to investigate is how the average overlay calculation functions in cases where the calculation takes place near the edge of the project area.

The average overlay functions by, for any given grid cell, looking at the surrounding grid cells, calculating the average value of the cells found. In most locations in a project area this calculation is very straightforward. However, if any of the cells looked at would fall outside the project area, any number of behaviors could be reasonable. For example: the cells outside the project area could be assumed to have a certain default value, or the cells could be disregarded for the calculations. You will configure the testbed to reveal how the average overlay deals with cells outside the project area.

Start by adding the overlay we're going to test. Add an average overlay to the project.

Add an average overlay.

Prepare the overlay in such a way that it will calculate the spatial average of a user-defined attribute. As Filter Attribute, enter "AVGTEST". Also set the Cell averaging distance to 50m. This will ensure that multiple entities can be drawn in the map and be spatially calculated, without necessarily affecting each other's outcomes.

Configure the average overlay to calculate using a user-defined attribute, and a relatively small radius.

With this configuration, the calculation will result in a value of 0 in every location.

In the first setup situation, the result of the average calculation is 0, everywhere.

Now add a construction to the project, and place it more or less in the center of the project. Make sure you use the block-based brush, and draw in exactly 1 block (10m by 10m, for a total of 100m²).

Draw a construction, with the size of a single 10m by 10m block.

Add an AVGTEST attribute to the construction, with a value of 1000.

Assign an AVGTEST attribute with value 1000 to the construction.

Switch back to the average overlay in the editor, and select "Update Now" to recalculate the content

Now, if you open the average overlay, you will see the construction is the center of a large area where the average value of AVGTEST is higher than in all other locations in the project area.

The average value at the location of the construction is around 130.

This setup creates a first look into how the average overlay functions. In the exact location of the construction, and its direct surroundings, the average value of AVGTEST is around 130. It tapers of at a distance of about 50 meters.

Note that you may see a value lower than 130, based on the exact location you have placed the construction. This is due to the construction's alignment on the calculation grid. This is expected, and does not affect the principles explained next. Take note of the value you see in your project, and continue.

We can now add another construction to the project, again with an AVGTEST attribute set to a value of 1000, and place that construction in the corner of the project area. Again, making sure that the construction is exactly 1 block of 10m by 10m, for a total of 100m².

Recalculating the overlay and looking at the average value at the location of the new construction gives an average value of 180.

The average value at the location of the construction is around 180.

The fact that the calculated value in the corner is higher indicates that the cells outside the project area don't have an assumed value of 0 or lower.

Increase the AVGTEST attribute value of both constructions to 2000, and check again what average values are calculated in the locations of the constructions.

Change the value of the AVGTEST attribute to 2000, double what it was before.

Now when you look at the calculated average value at the location of the construction, you will see that after doubling the attribute of the construction, the calculated value has doubled as well (give or take a rounding).

The value calculated has doubled.

We can now put the following facts together:

  • An average is a value calculated as follows: The sum of all values found in the calculation area, divided by the calculation area.
  • The calculated average scales linearly with the value of the object we place. This means that the cells outside the project area do not have a positive or negative value. If they did, the impact of raising or lowering the attribute value would have been more or less impactful.
  • An object at the edge of the project area has a greater impact on the calculated spatial average than a construction in the middle of the project area. This means that either the sum of all values increases as we get closer to the edge, or the surface area we divide by decreases.

We can determine that because the summed value does not change, the surface area used in the calculation must decrease in order to see the higher result. Thus our conclusion is that potential cells outside the project area are not used in the calculation of a spatial average.

Considerations

Note that based on the conclusion we have drawn, you may be tempted to expect the calculated values to match more neatly. Specifically, if the construction in the middle of the map has a full circle around it in which to perform its calculation, the construction in the edge of the map must have a quarter of the area of similar circle, thus the values should differ by a factor of 4. However, due to the layout of the constructions on the grid this is not the case.

Schematic functioning of the grid for spatial averaging calculations. Left: the circle taken into consideration given a specific cell in the middle of the map. Right: the section of the circle taken into consideration when the specific cell is at the corner of the map. Notice the area of the section on the right is not an exact quarter of the section on the left.

Also note that based on the exact size, placement, and rounding of values and polygons, it may be difficult to derive the outcomes seen from the base values without greater insight into the exact interpretations the Tygron Platform makes. This is to be expected, and the approach used here functions regardless of those exact calculations.

Assignments

These assignments are designed to demonstrate further means of experimentation.

  1. Knowing the radius of the spatial calculation is 50m, place a construction with the same attribute and value as close to the edge of the map as possible without the calculated average value differing from the construction in the middle of the project area.
  2. Change the average attribute of the constructions back to 1000, and instead expand both constructions with another block of 10m by 10m. Both constructions should be exactly twice as large as they were.
  3. Knowing the grid cell size is exactly 10m by 10m, find an explanation for the fact that both 'sides' of the construction in the middle of the map have the same calculated average, but the sides of the construction in the corner of the map do not.