Weather Model - MXIV
Project Summary
The weather model will provide the team with a variety of weather information on the route throughout the day. Information such as temperature, predicted precipitation, and wind, is used by other models to help with their decisions. It also provides an idea to the team on if weather could have a negative impact on the racing ahead or if the team will have to trailer through a storm.
Goals
Obtain weather data along the race route on a day to day basis
Have predicted weather data for up to two to three days in advance
Be alerted to bad weather in advance
Stretch Goals:
Meteorological weather maps on the visualization dashboard (think weather channel maps showing precipitation)
Quantify the impact of winds
Inputs
The weather model will take in a set of longitude and latitude values that will refer to locations along the race route for the day.
Outputs
Spreadsheet with the following:
Latitude/longitude location
Time
Temperature → Forwarded to Solar Model
Wind
City
Precipitation
Specifications
Selected API: OpenWeather
Note: OpenWeather can only query one location and has a limited number of calls per day. ETS currently uses a cloud server that will ping OpenWeather along their route as they drive and retrieves the data from the server. Our implementation will be more direct, but we cannot predict the upcoming weather very accurately (fallback will be the full route weather data pulled beforehand)
Current Roadmap Overview/Solar + Weather Intersect
Will need a directory for solar, weather API calls/parsing
Solar API: Solcast [STRAT-95 DOC]
Good point of reference is
routemodel
=> common.py, speedlimits.py, routes.py, elevations.py
-- > how they built a query, parse data from query, stored API key/handled error
First major task: what do we need from the API?
What information is needed + how do we convert this into energy data when parsing API response?
Solar -> power across energy cell, day, solarArray; adapt existing as needed!
Weather -> solarCell for the efficiency decrease ; otherwise, precipitation and wind speed, wind direction info is kept but not used directly from energy
Second Q: How are we calling mid-race?
Multiple calls + in the future (we're moving along the route, so can we make a call at some future location given our expected time of arrival at this location - so a couple hours from now)
(strictly optional) How can we make the calls efficiently? Are we worried about blocking main thread?
With all this information, how are we saving into some form -> @Emma Wai (Deactivated) will create a chart of potential points, lat, lon, city names (hopefully you can create city IDs in a table if necessary) -> try API requests that will fill this table
Suggested table format:
Speed | Lat | Lon | City Name | City ID | Time | Temperature | Efficiency Correction | Wind Speed | Wind direction | Precipitation | Energy from solar | Energy once corrected |
---|
[time, lat, long, city ID/name], temperature, temperature correction, wind speed, wind direction, precipitation, energy from solar, energy once corrected
solar: energy from solar, energy once corrected (optional -> energy per cell)
weather: temperature, temperature correction, wind speed, wind direction, precipitation
Inputs: [table], solar API, weather API
Outputs: table