You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We want users to be able to view weather data in the context of how it will affect their activities. Using the REMAP function, and a set of thresholds, we can remap weather values into “Favourable”, “Marginal” and “Unfavourable”, relative to the activity. The thresholds at which the values are remapped would be something like;
• Favourable is FROM wind speeds of 0 m/s TO 3 m/s
• Marginal is FROM wind speeds of 3 m/s TO 7 m/s
• Unfavourable is FROM wind speeds of 7 m/s TO 2000 m/s
Storing these ranges of values within each of the raster functions means that they are somewhat inaccessible for editing / checking / updating / re-use. However:
• At present the values are stored within the raster functions themselves because the REMAP function will not allow the use of an external table with remap ranges.
o But even if we could use a table for the remap ranges, nevertheless every time a user wanted to look at the impact of a weather variable on a new activity (e.g. the effect of temperature on running performance) they would need to create a new table – even though they are really just creating new data under a pre-defined schema.
• What we would prefer is for all the activities, weather variables and threshold values to be held in a single table so that users can add / edit / delete thresholds all in one place. For this to occur any one raster function would need to be able to query against that table using both activity and weather variable in the WHERE clause to pull out the correct REMAP values. The table columns would be something like: [ACTIVITY, WEATHERVAR, FROMVAL, TOVAL, UNITS, REMAPVAL], where REMAPVAL would represent ‘Suitability’, and a typical set of values might be: [“Running”, “Temperature”, -30, -20, “Centigrade”, -2], where -2 might represent ‘Unfavourable’.
The text was updated successfully, but these errors were encountered:
We want users to be able to view weather data in the context of how it will affect their activities. Using the REMAP function, and a set of thresholds, we can remap weather values into “Favourable”, “Marginal” and “Unfavourable”, relative to the activity. The thresholds at which the values are remapped would be something like;
• Favourable is FROM wind speeds of 0 m/s TO 3 m/s
• Marginal is FROM wind speeds of 3 m/s TO 7 m/s
• Unfavourable is FROM wind speeds of 7 m/s TO 2000 m/s
Storing these ranges of values within each of the raster functions means that they are somewhat inaccessible for editing / checking / updating / re-use. However:
• At present the values are stored within the raster functions themselves because the REMAP function will not allow the use of an external table with remap ranges.
o But even if we could use a table for the remap ranges, nevertheless every time a user wanted to look at the impact of a weather variable on a new activity (e.g. the effect of temperature on running performance) they would need to create a new table – even though they are really just creating new data under a pre-defined schema.
• What we would prefer is for all the activities, weather variables and threshold values to be held in a single table so that users can add / edit / delete thresholds all in one place. For this to occur any one raster function would need to be able to query against that table using both activity and weather variable in the WHERE clause to pull out the correct REMAP values. The table columns would be something like: [ACTIVITY, WEATHERVAR, FROMVAL, TOVAL, UNITS, REMAPVAL], where REMAPVAL would represent ‘Suitability’, and a typical set of values might be: [“Running”, “Temperature”, -30, -20, “Centigrade”, -2], where -2 might represent ‘Unfavourable’.
The text was updated successfully, but these errors were encountered: