Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New Weather Retrieval Method #158

Draft
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

Carterpersall
Copy link
Contributor

@Carterpersall Carterpersall commented Sep 30, 2022

  • Replaces the method of fetching the weather with a new one
    • First grabs the location of the user using ip-api.com
    • Uses the location to determine whether to use Metric or Imperial units
    • Takes the coordinates found and calls OpenWeatherMap's API using a key I created to get the current weather conditions
      • Might be best if you create a key so you don't have to depend on me keeping the key in the long-term future
      • Stored in a variable for easy changing
    • Uses a lookup hashtable for the current weather conditions using returned conditions ID
      • Created because OpenWeatherMap's provided conditions string isn't very user-readable
      • 30 Lines long
      • I'm open to suggestions for better wording of the returned strings
  • This new method is faster than grabbing the info from wttr.in due to its high latency
    • Ping:
      • wttr.in = 115ms
      • ip-api = 20ms and api.openweathermap.org = 25ms
      • This is with my favorable conditions (fast fiber internet)
      • This could vary based on location but is likely to stay faster
    • Overall Speed:
      • Old:
        • wttr.in = 280ms
      • New:
        • ip-api.com = 75ms
        • api.openweathermap.org = 126ms
        • Combined = 200ms - 260ms
  • The new method is less prone to failure due to wttr.in running out of queries as it did this morning or going away one day as has happened to many other "no key" weather APIs

Maybe:

  • Add the ability to change the API key and unit type (Metric or Imperial) in the config file
  • Add graphics like wttr.in's
  • Add an option for hourly/daily forecast
    • Maybe have in its own dedicated function
  • Add more details (Pressure, Max/Min temp, humidity/feels like temp, wind speed)
    • All configurable through the config file

- Replaces the method of fetching the weather with a new one
  - First grabs the location of the user using ip-api.com
    - TODO: First try to grab location using Windows Location services (If not disabled)
  - Takes the coordinates found, and calls OpenWeatherMap's API using a key I created to get the current weather conditions
- This new method is faster than grabbing the info from wttr.in due to the high latency of wttr.in
  - wttr.in Ping is 115ms vs ip-api's 20ms and api.openweathermap.org 25ms under my favorable conditions
  - This could vary based on location
@Carterpersall Carterpersall mentioned this pull request Sep 30, 2022
16 tasks
@Carterpersall
Copy link
Contributor Author

Carterpersall commented Oct 4, 2022

It seems that Windows' reverse geocoding api (System.Device.Location.CivicAddressResolver) always fails within Powershell for whatever reason, which means I can only get the coordinates of the user and nothing else. I also tried using the UWP reverse geocoding API (Windows.Services.Maps.MapLocationFinder) and hit a wall where FindLocationsAtAsync was returning an empty System.__ComObject when it should be returning a MapLocationFinderResult object, along with it only working in PowerShell 5 for some reason.

- The .NET calls are ~10% faster than `Invoke-RestMethod`
@Carterpersall
Copy link
Contributor Author

It seems that Windows' reverse geocoding api (System.Device.Location.CivicAddressResolver) always fails within Powershell for whatever reason, which means I can only get the coordinates of the user and nothing else. I also tried using the UWP reverse geocoding API (Windows.Services.Maps.MapLocationFinder) and hit a wall where FindLocationsAtAsync was returning an empty System.__ComObject when it should be returning a MapLocationFinderResult object, along with it only working in PowerShell 5 for some reason.

Using System.Device.Location.GeoCoordinateWatcher works and is quite fast

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant