Request: Location cache

[kg4zow]

This started as a request to use airport codes as locations, but then I looked at the output using -owm-debug and realized that the location is just being passed along to the weather API, and not all weather APIs support airport codes as locations (for example, openweathermap does not).

AirportDB offers an API to look up airport information, including their coordinates. API keys allowing up to 5000 requests per month are free.

My original suggestion was going to be to use this API, and have it create a local cache of airport coordinates, so that if somebody runs wego as part of a cron job, each airport's coordinates would only need to be looked up once rather than every time the command runs, since airports' coordinates generally don't change very often. 😁

But then, as I was typing this, I realized that if I'm going to suggest having a local cache of locations and coordinates, it might be nice if users could manually add their own custom locations (or "aliases") to that cache. This could be done either by telling the user to manually edit the cache file (assuming it's stored as JSON, YAML, INI, or some other human-editable format), or by adding command line options.

I'm thinking ...

• wego -airport KTPA would ...
  • convert the name to lowercase
  • if ktpa is in the cache, get the coordinates from the cache
  • if not, use the AirportDB API to look up its coordinates and write them in the cache file
  • send the coordinates as part of the weather API request
• wego -alias home (or -a home) would ...
  • convert the name to lowercase
  • if the name is in the cache, get the coordinates from the cache
  • if not, throw an error
  • send the coordinates as part of the weather API request
• wego -alias-add home 27.35,-82.49 would ...
  • convert the name to lowercase
  • manually add an entry in the cache
• wego -alias-list would list the cached entries and their coordinates
• wego -alias-remove home would remove an entry from the cache
  • this could also be used to remove an airport, since it would just be another alias in the same file

I'm also suggesting that the alias names in the cache file would be lowercased, so it wouldn't matter if somebody enters an alias name (or airport code) as uppercase, lowercase, or mixed.

[kordianbruck]

AirportDB requires an API key, that just sounds like bad UX for users to have to setup two API keys. But its built on https://ourairports.com/data/ which has a CSV download that could just be loaded into the binary and updated on occasion? (Surely the main aiport codes won't change that much)

[kg4zow]

The users already have to acquire and configure API keys for weather data, especially if they want to be able to query multiple weather data sources. They're already familiar with the idea of setting up API keys to get data, airport locations would just be another data source. I don't think setting up another API key is a huge stretch - especially since (1) it would be a one-time thing, and (2) not all users are going to need it.

As for embedding a list of airport coordinates into the app itself, it sounds like a lot of extra manual work to me. I've seen other apps use the same approach, including RepeaterBook (which I use on a semi-regular basis). If you look at that app's version history, you'll see that at least 90% of its updates are just "Database Updates".

As you say, the list of airport locations shouldn't change very often, but the fact is that it does happen. Airports are opened and closed, and there are occasionally updates to fix typos. The FAA (who maintains the primary list, at least for the US) tells their users (such as AirportDB) to update their local copies at least once a month (although this is because the FAA's information includes a lot more than just the airport's location, and some of that information changes over time - think radio frequencies, fuel vendors, and ground contact phone numbers).

Another thing to consider is this - updating the app once a month means that users would have to update their copies of the app every month, if they want the latest and greatest airport locations. It also means that the app itself would be larger (because it would contain the airport locations).

This isn't a huge deal for mobile apps, where the "app stores" have built-in mechanisms to udpate apps automatically. But on a computer, where different people install apps using different methods, users have to remember to do that. Making the user do extra work "once a month" is more intrustive than making them do an extra step "one time".

It also means that users who update "because a newer version is available" would be getting updates they don't really need, unless they're using the airport locations.

I'll be honest, what I'm really hoping for is the "alias" functionality. If the airport code thing were in there, I would only ever use it to look up five or six airports anyway, and never need it again. This is likely true for other people as well. If the "alias" functionality existed without any connection to AirportDB, people could manually look up the airport coordinates on their own (which I've already done) and create the aliases they want. For example, some people might want "kmco", some might want just "mco", some may want "orlando", and some may want something like "grandma" or "work" (if they work at the airport).

Right now I'm using shell aliases (like kmco='wego 28.4311,-81.3077') but that means I have to run my alias instead of an actual wego command. I think it would be "cleaner" to be able to type wego -a kmco, and have it look up kmco as an alias to find the real coordinates. If that functionality existed, I would add aliases for the handful of airport codes I normally check, and never need to think about it again (because as you say, airports' locations generally don't change).