...
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
...
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
...