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

Out-of-date TAF returned for nearest airport #32

Open
flaparoo opened this issue Dec 4, 2023 · 1 comment
Open

Out-of-date TAF returned for nearest airport #32

flaparoo opened this issue Dec 4, 2023 · 1 comment

Comments

@flaparoo
Copy link

flaparoo commented Dec 4, 2023

Hi

My interpretation of requesting a TAF for the nearest airport would be that the nearest valid report is returned. However, the API currently returns a TAF from the nearest airport, regardless whether or not it is still valid.

For example, the request https://avwx.rest/api/taf/-31.52,115.94?onfail=nearest resulted in (filtered for end_time, meta and raw):

{
  "end_time": {
    "dt": "2023-12-04T09:00:00Z",
    "repr": "0409"
  },
  "meta": {
    "stations_updated": "2023-10-28",
    "timestamp": "2023-12-04T11:28:55.201236Z"
  },
  "raw": "YGIG 032209Z 0400/0409 20008KT 9999 SCT025 FM040200 22016KT 9999 FEW035 RMK T 22 26 27 23 Q 1016 1016 1016 1016"
}

Note the report end-time of "0409" but the request was made almost 2.5h later (ie. after "0411").
Also note that I've tried the onfail=nearest option, but it didn't make a difference.

An airport with a 24/7 TAF (YPEA) would be available only slightly further away from the requested location.

@devdupont
Copy link
Collaborator

I agree with your assessment. Right now, the only validity check is made against the cached version, not one that comes in as a new report, which is what I guess happened here.

Under normal circumstances, the API is designed to return expired reports if that is still the latest one provided by the regional service. However, I do agree that an invalid report, even if it's the most recent, should trigger the nearest fallback when explicitly specified. I don't agree with changing it under other circumstances.

This work can be included alongside #33 since they both involve the nearest onfail handling.

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

No branches or pull requests

2 participants