New Weather Retrieval Method

[Carterpersall]

• 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
  • Note: Need to update Multithreading with Runspaces #150 with the variables if implemented
• 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

[Carterpersall]

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.

[Carterpersall]

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