Hi Mark

I have just noticed a color discrepancy. The Military airport LSME shows VFR on the map instead of LIFR. Here is the printout of the link you provided above, note that I included the two last METARs, as the current one, showing the wrong information, does not report a flight category, whereas the one before did, and I don't really understand why... I went a few hours back in time and this seems like a random thing...

Being a non-US airport, the METAR data may be structured differently. If you will do me a favor and post the same data for the same airport once you notice that the LED is properly reporting the weather then I can compare the two and figure out what might be going on. - Mark

Hi Mark

Here is an example where the LED reports the right color. Note that in this example the visibility and flight category are reported, as opposed to when the LED displayed the wrong color.

<METAR>

<raw_text>LSME 091520Z 05003KT 9999 SCT009 OVC016 01/M01 Q1002 RMK WHT</raw_text>

<station_id>LSME</station_id>

<observation_time>2021-02-09T15:20:00Z</observation_time>

<latitude>47.1</latitude>

<longitude>8.3</longitude>

<temp_c>1.0</temp_c>

<dewpoint_c>-1.0</dewpoint_c>

<wind_dir_degrees>50</wind_dir_degrees>

<wind_speed_kt>3</wind_speed_kt>

<visibility_statute_mi>6.21</visibility_statute_mi>

<altim_in_hg>29.586615</altim_in_hg>

<sky_conditionsky_cover="SCT"cloud_base_ft_agl="900"/>

<sky_conditionsky_cover="OVC"cloud_base_ft_agl="1600"/>

<flight_category>MVFR</flight_category>

<metar_type>METAR</metar_type>

<elevation_m>427.0</elevation_m>

</METAR>

Thanks Julien, I'll have to look at the routine in relation to the XML data being returned to see if there is a difference that is causing the software to decode it differently. Feel free to nudge me from time to time so I don't let this fall through the cracks. - Mark

From what I understand, by looking at the METAR decoding routine, the software checks for a flight_category report in the XML data. If not provided, it checks sky_conditionsky_cover, then visibility_statute_mi.

When I get the wrong color displayed, it is, from what I have seen, because neither see a flight_category or a visibility_statute_mi are available and therefore the software might not be displaying the right color as it can only judge the weather from sky_conditionsky_cover, which might not be the limiting factor. So my questions about this are:

- Is it possible to get the visibility from another source? Maybe the data is available as visibility_kilometers somewhere else?

- Wouldn't a fallback procedure, such as "if visibility_statute_mi N/A = no_WX_data", be a good transition solution, while we figure a way to decode these special METARs? If you do not judge it necessary to be added to the LiveSectional code, I could modify my unit accordingly, I would just need and appreciate some coding/wording advice 😇 

Julien

Yes, that would work fine. It's odd that the METAR would not provide either the flight_category and the visibility and cloud cover. Why publish a METAR at all if that's the case.

As far as another source, the FAA does provide other weather products but none that I know of that provide different data. So if you know of another source that can be poled by an automated script, please let me know and I'll be happy to investigate. - Mark

Well the METAR is technically published with a visibility, in one of the above examples it was 0900NDV, being 900m = 0,55mi, No Directional Variation, which is apparently a thing at Swiss military airports. So the METAR is available for people to decode themselves, but I guess the FAA cannot decode the meaning of NDV, as I have yet to see the visibility correctly reported when NDV was in the METAR.

Regarding another source, I just noticed that the Airport Editor page reports the METAR and flight category correctly, even when the XML file does not list a category or visibility! Could the flight category be extracted from this source?

Still, just in case of a need for a fallback procedure, could you help me write that code part and specify where I should insert it in the METAR decode routine? I'm guessing it should look something along the lines of the following, but I really know too little about coding to really know:

if metar.find('./forecast/visibility_statute_mi') is not None: #check XML if visibility value exists
   visibility_statute_mi = metar.find('./forecast/visibility_statute_mi').text #get visibility number
   visibility_statute_mi = float(visibility_statute_mi)

   if visibility_statute_mi < 1.0:
      flightcategory = "LIFR"

   elif 1.0 <= visibility_statute_mi < 3.0:
      flightcategory = "IFR"

   elif 3.0 <= visibility_statute_mi <= 5.0 and flightcategory != "IFR": #if Flight Category was already set to IFR by clouds, it can't be reduced to MVFR
      flightcategory = "MVFR"

   elif metar.find('./forecast/visibility_statute_mi') is None:
      color = color_nowx

Thanks a lot for your help.

Julien

Never mind, I think I figured out the fallback by modifying the code as follows:

if metar.find('./forecast/visibility_statute_mi') is not None: #check XML if visibility value exists
   visibility_statute_mi = metar.find('./forecast/visibility_statute_mi').text #get visibility number
   visibility_statute_mi = float(visibility_statute_mi)

   if visibility_statute_mi < 1.0:
      flightcategory = "LIFR"

   elif 1.0 <= visibility_statute_mi < 3.0:
      flightcategory = "IFR"

   elif 3.0 <= visibility_statute_mi <= 5.0 and flightcategory != "IFR": #if Flight Category was already set to IFR by clouds, it can't be reduced to MVFR
      flightcategory = "MVFR"

else:
   flightcategory = "NULL"

This seems to work as I intended, it does not display weather when there could be a discrepancy. I'll check to make sure this does not have any unwanted consequences. Please tell me if you think this workaround isn't a good idea.

Julien

Nice job! Please let us know if this works the way you are expecting. Then I'll look at the code to see if I can/should include this. Thanks - Mark

I'm seeing a conflict between what the category is in the airports editor page and the map as shown.

Foreflight is showing the airports as VFR

Ron, I have to use 2 different weather products for this information. One for the LED's and another for editor. I found that the two products are not synced, so I'm not surprised that there are discrepancies. Also, the data provided on the editor is not updated live. You would have to refresh the page to update the weather, so this could be older data. 

Next time you see this, please refresh the editor and see if it becomes more in line with the LED's. If its still way off, then I've got some detective work to do. Let me know. - Mark

@markyharris Interesting. I think I did reboot the RPI but I'll pay attention next time. Thanks for the info.

Posted by: @markyharris

I have to use 2 different weather products for this information. One for the LED's and another for editor.

Hi Mark, may I ask which source you use for the editor? In which file of the NeoSectional folder is this coded?

Julien

Hi Julien,

I needed to use AJAX to inject the METAR data into the 'apedit.html' file depending on what the weather is when the editor was loaded. So I had to use the api provided by 'api.weather.gov'. See https://www.weather.gov/documentation/services-web-api for details.

The code that handles this is at the beginning of 'base.html' in the '/templates' directory. https://github.com/markyharris/livesectional/blob/master/templates/base.html

The 'get_badge' routine in 'base.html' is called towards the bottom of 'apedit.html'. https://github.com/markyharris/livesectional/blob/master/templates/apedit.html

Let me know if you have questions about it. - Mark

<METAR>

<raw_text>LSMM 172050Z AUTO 26004KT 220V340 7000NDV -SHRASN FEW006 BKN013 OVC016 01/01 Q1021 RMK</raw_text>

<station_id>LSMM</station_id>

<observation_time>2021-03-17T20:50:00Z</observation_time>

<latitude>46.75</latitude>

<longitude>8.12</longitude>

<temp_c>1.0</temp_c>

<dewpoint_c>1.0</dewpoint_c>

<wind_dir_degrees>260</wind_dir_degrees>

<wind_speed_kt>4</wind_speed_kt>

<altim_in_hg>30.147638</altim_in_hg>

<quality_control_flags>

<auto>TRUE</auto>

</quality_control_flags>

<wx_string>-SHRA SN</wx_string>

<sky_conditionsky_cover="FEW"cloud_base_ft_agl="600"/>

<sky_conditionsky_cover="BKN"cloud_base_ft_agl="1300"/>

<sky_conditionsky_cover="OVC"cloud_base_ft_agl="1600"/>

<metar_type>METAR</metar_type>

<elevation_m>570.0</elevation_m>

</METAR>

And the corresponding extract of the logfile

[I 210317 22:21:04 metar-v4:1159] LSMM Not Reporting Flight Category through the API.

[I 210317 22:21:04 metar-v4:1166] FAA xml data does is NOT providing the forecast field for this airport

[D 210317 22:21:04 metar-v4:1169] Sky Cover = FEW

[D 210317 22:21:04 metar-v4:1169] Sky Cover = BKN

[D 210317 22:21:04 metar-v4:1169] Sky Cover = OVC

[D 210317 22:21:04 metar-v4:1184] Cloud Base = 1600

[D 210317 22:21:04 metar-v4:1233] LSMM flight category is Decode script-determined as MVFR

Shouldn't the Cloud Base be 1300 in this case, refering to the BKN013, which is more limiting than the OVC016?

- Julien