TAF - Forecast times incorrect
pejeio opened this issue · 11 comments
Expectation
According to the raw TAF, the first weather group should end at 2020-05-02 1200Z.
Result
end_time.dt returns 2020-05-02T10:00:00+00:00Z
end_time.repr returns 0210
How to reproduce
curl --location --request GET 'https://avwx.rest/api/taf/EBBR'
Going to paste the raw report here for clarity.
EBBR 010520Z 0106/0212 23012KT 9999 SCT024 PROB30 TEMPO 0108/0122 22015G28KT 4000 SHRA BKN014CB PROB30 TEMPO 0205/0212 23015G28KT 4000 SHRA BKN014CB BECMG 0210/0212 30013KT
This is parsing as expected. The 0106/0212 element signifies the valid time window of the entire report (which can be seen in data.start_time and data.end_time). The end time of the first forecast period differs from this because of the BECMG 0210/0212 30013KT time period.
For time periods not of type PROB or TEMPO, the start and end times of each remaining period is matched with the remaining elements. The BECMG period starts at 0210, so the base forecast time period ends then.
Thanks for the clarity. I see. So the BECMG overrides the entire report.
Eventually yes. While the report does not say this explicitly, the interpretation becomes “at the end of the becoming time period, these will be the prevailing conditions.” In this example, it just happens to line up with the end of the report’s valid time period.
See this explanation
https://aviation.stackexchange.com/questions/74323/how-to-interpret-becmg-and-tempo-in-taf
@flyinactor91 I do have my concerns about this decoding.
"raw": "ELLX 082300Z 0900/1006 05008KT CAVOK BECMG 0909/0912 16008KT PROB40 TEMPO 0910/0916 SHRA BKN017CB TEMPO 0921/1005 RA SCT010 BKN050" "sanitized": "BECMG 0909/0912 16008KT",
"end_time": {
"repr": "1006",
"dt": "2020-05-10T06:00:00Z"
},
"raw": "BECMG 0909/0912 16008KT",
"start_time": {
"repr": "0909",
"dt": "2020-05-09T09:00:00Z"
},
"summary": "Winds SSE-160 at 8kt"As the raw TAF states, the BECMG weather 16008KT is valid within a small time frame: 0909/0912
Nevertheless, 1006 is returned in the end_time instead of 0912.
@studio-pj the meaning of BECMG is not what you seem to think it is. Check the explanation on NOAA's Aviation Weather Center.
Basically BECMG 0909/0912 means "Sometimes between 0900z and 1200z of the 9th, the following groups will BECOME what follows and permanently remain as such until changed again".
This is opposed to TEMPO where the condition TEMPOrarily changes only between the times indicated, for less than half of the timespan specified.
The only argument that could be made about the avwx implementation is that the times between which the variation occurs are lost, and this could make some implementations difficult.
For example, most Operations Manuals (for EASA operators in OM-A chapter 8) will say that change indicators should be interpreted in a conservative way. For example, if BECMG indicates an improvement, the latest time at which that is expected to happen should be considered; if instead it indicates a worsening of the conditions, then the earliest time should be considered.
But defining "improvement" and "worsening" in code is rather difficult.
I think there's a middle ground here between what the report directly represents in the text and how a time period should be represented in the API. The BECMG flag specifies a time period of change where there are no precise conditions, just what it will end up being like.
BASE conditions -> BECMG (start/end transition) -> BECMG conditions
The current forecast structure requires there be a raw report snippet for each discrete time period, but BECMG implies two discrete time periods: the transition and the new conditions. This requires the client to correctly interpret the meaning of a .type = "BECMG" period rather than iterating through the start/end times naively.
If we want to represent this time period more accurately in the API response, would it be better to split it into two separate forecast periods or add a new element like .transition_start to indicate a transitionary period before the new conditions go into effect?
TEST 121200Z 1212/1412 36010KT CAVOK BECMG 1300/1302 09010KT
1212 -- BASE -- 1300 -- transition -- 1302 -- BECMG -- 1412
Option 1:
[
{"type": "BASE", "start": "1212", "end": "1300"},
{"type": "trans", "start": "1300", "end": "1302"},
{"type": "BECMG", "start": "1302", "end": "1412"}
]
Option 2:
[
{"type": "BASE", "start": "1212", "end": "1300"},
{"type": "BECMG", "transition_start": "1300, "start": "1302", "end": "1412"}
]
The second option is more appealing, personally.
Also my vote on the second option!
@flyinactor91 Also my vote for the second option.
The most confusing part for me:
EBBR 010520Z 0106/0212 23012KT 9999 SCT024 BECMG 0210/0212 30013KT
{
"clouds": [
{
"repr": "SCT024",
"type": "SCT",
"altitude": 24,
"modifier": null,
"direction": null
}
],
"sanitized": "0106/0212 23012KT 9999 SCT024",
"visibility": {
"repr": "9999",
"value": 9999,
"spoken": "nine nine nine nine"
},
"wind_direction": {
"repr": "230",
"value": "230",
"spoken": "two three zero"
},
"start_time": {
"repr": "0106",
"dt": "2020-05-01T06:00:00Z"
},
"end_time": {
"repr": "0210",
"dt": "2020-05-02T10:00:00Z"
}
}I agree that this forecast ends at 0210 because the wind conditions are overwritten by the BECMG group. But what about all the other values like visibility and clouds? These values are not overwritten by the BECMG group.
The way I interpret it now is that all conditions end at 0210, which is not true.
Between 0210 and 0212, what is the visibility?
Between 0210 and 0212, what are the clouds layers?
BECMG is it's own report period. No inheritance. This page has an example of a larger BECMG period.
https://aviationweather.gov/static/help/taf-decode.php
I've made the proposed change in the core library which is now pushed into the API
To your example, BECMG specifies a time of conditions changing. There are no exact forecasted conditions. Merely, the wind is in the process of turning from 23012KT to 30013KT during the period of 0210 and 0212. Because the BECMG period ends at the same time as the report, the normal interpretation would be, "The wind will be 30013KT by the time of the report's end."
Omission of report elements in a forecast don't signal absence of those elements, just that the conditions aren't known with enough certainty to warrant including them.
There's another possibility, albeit a less likely one. Many reports are not fully automated. This could be the result of someone manually producing a report and not understanding the implication of setting a BECMG period to match the end of the TAF's valid time period. Human error has been more of an issue with METARs, but it's possible.