U.S. METAR Visibility incorrect at most airports

In all fairness tho, METARS also aren’t a great weather source… They are local conditions at the airport and are only valid for as far as the observer can see.

In order to get really accurate ‘weather’ (rather than ‘local conditions’) they’d need to average the Metar against the larger scale data from Meteoblue and sort out what the big picture really is. But if you have a METAR that says ‘x’, and you know the weather in the area is ‘y, z, w,’ its pretty easy to figure out why the Vis is 10, or if it might be actually unlimited.

Thats what they need to bake into the engine… Does 10sm sound real based on pressure and humidity and so on? Or is it 95F and 9% humidity and 30.05 altimeter (in which case its almost certainly unlimited).


Yeah I agree, at least with the first half of your post. That is why I have been saying all along that using METARs as a weather input is a bad idea, they should stick with their weather modeling and improve that instead. Looking at Meteoblue’s weather products at their webpage the necessary data is already there. Just use the visibility from the models to drive the visibility in the sim.

As for estimating visibility based on pressure and humidity, that does not work. That approach overlooks visibility restrictions due to haze, dust, smoke, and maritime aerosols, which in large parts of the world are the dominating visibility impairments most of the time.

Haze, smoke etc have encodings that should appear in the Metar if they are present, just like snow, etc.

Can’t speak to maritime aerosols, but there are lots of informational codes that can pop up in there and as long as they are properly interpreted by the sim, it’d work just fine.

In principle yes, but I think this part is the problem:

It is too complicated to try to implement a mechanism to properly interpret METARs to derive data that is not actually in the METARs, i.e., try to estimate actual visibility from a METAR that only has a lower limit on visibility. It is a fundamentally hard problem. With the limited resources that can be put into solving it I have little hope a good solution will be obtained.

Much better in my view to rely on Meteoblue weather data. That way we can leverage work done for other weather data consumers, which means more resources are available to address it.

I have had to deal with providing time-accurate nowcast or aftercast visibility data for specific locations professionally in a previous job, based on data similar to METAR data. It is a very complex thing to do, and we spent an awful lot of effort on it with rather unsatisfactory results. I do not think it is realistic for a flightsim to try to implement something like that on top of everything else it needs to do.

1 Like

Hard to guess. But, they sure did make big whoop about being partnered with Meteoblue at first, so they just need to get the integration working better.

I would not under-estimate the capability to get it to work tho, MS has a big wallet if they choose to deploy it. But, I definitely agree that they have underestimated the complexity of this feature. No big surprise really, they have under-estimated a lot of things over the last year. But to their credit, once they fully wrap their heads around the problem they have been getting them worked out. Hopefully this will just be another of those.

This the solution. Vote!

I think there is more than one problem, so more than one solution, so hopefully you’ve voted here also?

I voted on the one you posted, as I agree its a factor.

1 Like

I’m interested in your experience.

What were the challenges you faced in the previous situation. Was it collection of individual METAR data? Was it interpolation of METAR data between stations?

What part seemed to you to be insolvable? Are you sure that applying cloud compute at scale could not produce a satisfactory solution? Why?

Can you provide any details to support your position?

I can’t really, as I am sure you understand, when we deal with professional activities it gets tricky to go into details. The information is not mine to share, my employer at the time owns that know-how.

But at a high level: We needed to know the meteorological visibility, at particular well-defined but widely scattered points across the world, with an accuracy of a few hundred meters and at timescales of less than an hour. E.g., for what percentage of time is the visibility less than 3 km at any time from 3 pm to 9 pm at a particular spot in Rio de Janeiro on a particular day. The available data is, e.g., NOAA databases, crowdsourced data, or commercially available data, much of which is actually ASOS or AWOS data (or a national equivalent) at the nearest airport. Since the data is very coarse (e.g., pilots by regulation do not really care if the visibility is 4 km or 4.5 km, they only care if it is 3 km or 5 km) and quite inaccurate (measuring visibility with various sensors is nowhere near as easy as it sounds or as visibility sensor manufacturers claim), you try to combine different types of weather observations such as visibility, rain rate, and humidity, with climate data for that region (Koppen climate classifications), with theoretical visibility models (measured and published rain drop size distributions combined with optical scattering models for what a drop size does to visibility), and even local knowledge such as interviewing local staff about typical weather patterns or looking at online webcams and trying to identify visible buildings with Google map overheads. Then you combine accurate (you think!) observations from a controlled location with available data for that location, use that to build a model that you believe is generic, and try to apply that model to uncontrolled locations where you only have database data available. And hope that your model output is accurate for those locations as well.

The conclusion is: Trying to extract data from observations that do not really contain that data to begin with only results in extracting the assumptions you combined with the observations to refine the data. It is a fundamentally difficult problem, not just on an engineering level but on a science level. A couple PhDs over hundreds of manhours does not cut it. And we were just trying to interpolate data. To guess at the real visibility when the METAR just says “10SM” and you know that means “at least 10 sm” means extrapolating, which is even harder.

At which point you realize: Rather than trying to solve that yourself with your own weather data, leverage the expertise of the meteorologists and their models. Someone like Meteoblue, whose very business model is to compile, process, and derive information from such data and sell it for profit to various customers can apply much more resources to the problem. You are just one of many customers who purchase that data and you all share the cost of Meteoblue researching and developing and productizing the required models and dataflows. Including the cloud compute at scale that you mention.

So in conclusion: I think Microsoft made the right decision in partnering with a company specializing in weather data. I think they would make a mistake if they tried to leverage METAR data along with homegrown algorithms instead of the professionally developed commercially available models.


the real issue is , they do not test properly with knowable people.
this is so asap nooticable…

1 Like

Thanks for the thoughtful response @FlyingBear01

I’d suspected this was a tough problem but you’ve touched on complexities I hadn’t thought of. Illuminating!

I tend to agree with your reasoning. Dropping Metroblue was a mistake, if in fact Microsoft’s motivation was improving the customer/user experience.

I don’t think it’s cynical to conclude that Microsoft’s real motivation was to eliminate on going payments to Metroblue and improve the M$ bottom line.

The have not dropped Meteoblue! The MB forecast model is still the core of Live Weather. The “new thing” that came with SU7 is that real time METAR-reported clouds and visibility are being blended with the model forecast.


I’m surprised more people aren’t affected by this… would expect more votes.

Today its dry and the winds are blowing 50mph out of the mountains in Los Angeles county and its severe clear everywhere, absolute CAVU… but heavy haze all over the area as far as MSFS see it…

Totally broken.

1 Like

Yep, the haze turned a severe clear day into an MVFR day. I couldn’t even see the end of the runway until I was about 5NM out.

1 Like

I did a flight today from New York to North Carolina and return. It was also severe clear today along most of the eastern seaboard. In my case, there was no excessive haze. Both airports were reporting 10M in the METAR, and visibility at both was easily 20 miles. Very light haze was present, but about exactly what you would expect to see on a clear day in autumn.

I will have to try a flight tomorrow on the west coast.

1 Like

It’s been discussed a lot here and elsewhere, but chiming in to update my initial posts after testing this for a few days. There is indeed an issue of inaccurate visibility affecting likely thousands of airports, and again it’s because the sim is misreading 10sm or greater in the METAR as verbatim 10 miles of visibility. Further, this 10 miles of visibility is often far lower than 10 miles depending on the lighting and possibly other conditions.

Thousands of airports are now defaulting to 10 miles of visibility and this is way too low at most of these locations at most times. It’s especially problematic in areas that generally feature really high visibility, such as very dry locations and airports at high elevation:

Las Vegas, Nevada:

Cheyenne, Wyoming:

My home field of Springfield, IL can indeed get quite hazy in the summer, but going into the cool season, visibility is often great with cold front passages that leave crisp, dry, and exceptionally clear air in their wake. Yet the simulator is always in a default low vis state every time I load it up:

Here are some potential fixes:

  • Treat a value of “10sm” as a default unlimited value, and use the simulators default clear weather visibility. Quickest and easiest fix, and would be great to see in a hotfix. Sure if the visibility actually is 10sm, then the sim visibility will be inaccurately way too high, but I think this situation is far more favorable than all affected airports always defaulting to 10 miles and effectively less.
  • Treat a value of “10sm” as a default value, and use an approximation based on the relative humidity instead. The approximated value needs to be above 10 miles (not a value that turns out to be less than 10 like it is now). This will likely not be accurate, but may be a better solution than locking visibility at either 10 miles or unlimited. SU8 bug fix maybe?
  • Use a numerical forecast model parameter from Meteoblue instead. An aviation specific visibility parameter developed by Meteoblue that preferably uses a METAR visibility value as input into the parameter, instead of the METAR overriding the model’s visibility parameter output at runtime in the simulator. A fix for when the weather system is overhauled in the next year or two hopefully.

I’ve noticed this issue is not affecting coastal areas nearly as much. I had tens of miles visibility at New York, San Francisco, Hawaii, and some locations on the Florida gulf coast. Every inland airport in the US I’ve loaded into that’s reporting 10sm or greater is defaulting to this low visibility condition though.


I believe you, but it is not always defaulting to exactly 10 miles with a 10SM METAR. That was the point of my test flights yesterday. I am very familiar with specific landmarks in the vicinity of my home airport (KELM) and their horizontal distance. One in particular, Connecticut Hill near Ithaca, requires at least 20 miles horizontal visibility to see it when on the ground at Elmira, and it was clearly visible. Seneca Lake, whose southern terminus at Watkins Glen is exactly 15 miles due north of the airport can be seen when over 1000 feet AGL on takeoff or landing if visibility is good, and approaching runway 06 last evening (just before sunset), I could not only see the southern end of the lake, but was able to see all the way up to Peach Orchard Point, which is 30 miles away.

And it was not a case that Live Weather was inop. There was a thin broken cloud layer at 11,000 feet, and a very light haze layer filling the river valley in which the airport is located, but after landing, and actually in the haze, I had no problem making out the mountain near Ithaca that is 20 miles away. I had a similar experience yesterday at two airports in North Carolina with which I am very familiar from r/w flights, KRDU and KCLT. Both had light haze, but surface visibility was easily 20+ miles with both having a METAR of 10SM.

FWIW, Most of the eastern seaboard yesterday was generally severe clear in both r/w and the sim due the the passage of a cold front the previous day, with surface pressures quite high, and light northwesterly flow aloft. It was 30.25 (at KELM) and 30.46 (at KCLT), with very dry air.

Those surface METAR pressures were accurately injected into the sim at both airports. Perhaps ambient pressure is being factored into the haze algorithm? That might have an effect if the new zero to 20 “humidity” slider actually represents mixing ratio.


You might find this of interest. As we know, Live Weather uses the MeteoBlue “NEMS Global” model. I did some research on that. “NEMS” is not a model per se, but an analysis framework that can be used to quickly create non-standard datasets from any GRIB-based input model.

NEMS was developed by the US NOAA, and the acronym stands for NOAA Environmental Modeling System. It was originally created to be used in conjunction with the US NAM model, but can apparently be used with other input models as well.

There is some background information here:


One thing I found of interest looking at some of the other documentation at the above web site, is that there are several variables contained in a NEMS model analysis for “aerosols” - a term not found in the native NAM or GFS GRIB datasets, put which (perhaps) could be derived from other parameters, and which first made an appearance in the initial MSFS weather settings menu.

So apparently NEMS itself is not a MeteoBlue product - although the specific way they are using it may be proprietary to them. I am curious what base model is actually being used? All I know for sure is that it has a 30km grid spacing and worldwide coverage.


Yep, it would be great to know what actual data they are using.

1 Like

I flew from Elmira (KELM) up to Rochester (KROC) using crude pilotage. Just heading in the general cardinal direction of major landmarks on the sectional. No GPS in the T-6 I was flying, didn’t fire up Foreflight, and didn’t plot the headings. I flew up to Watkins and Lake Seneca, followed the lake and kept going until I hit Lake Ontario, a left turn until I hit Rochester. Thanks for that inadvertent flight suggestion by the way. A gorgeous and super fun flight. Lots of great cloudscapes along the way and scenery to look at:

Seriously how pretty is that?

So my tldr; weather observations from this flight and the simulator’s behavior:

  • One hard transition of the clouds occurred while I was still on the ground, perhaps a loading glitch.
  • The default 10sm visibility haze was present at every airport I flew near, which is the thread identified issue that needs to be addressed.
  • This quickly and smoothly blends to tens of miles of visibility a few miles from the airport, suggesting METAR to model transition is smooth/continuous.
  • Cloud bases were too low in reference to METARs (had 600 agl and 2800 agl reported), perhaps the model data was being pulled in this instance.

So right off there’s my (new) old friend 10sm haze at KELM. While I was sitting on the ground doing a preflight, the clouds abruptly changed their pattern. I had some form of Live Weather before and after the transition. I’m guessing the METAR updated at that point making for an abrupt METAR to METAR transition.

I can see landmarks in town a few miles out, but I’d be hard pressed to find anything in a valley at 10 miles.

But lo and behold the haze clears shortly there after and I can see for tens of miles now. The transition was smooth and volumetric, meaning I flew away from the haze. It didn’t just fade out around the aircraft like a METAR injector such as REX would do.

I saw Watkins and Lake Senese easily from more than 10 miles out and was ability to home right in on it. Following the lake north was a treat and visibility remained high for the most part. Bases were generally too low everywhere and I was scud running the whole flight. That made it fun and interesting though.

Every METAR reporting airport I approached enroute was surrounded in a blanket of low visibility haze/mist. KPEO, KIUA, and KSDC I’m assuming. I didn’t actually have a visual on them.

Scud running in that kind of visibility, I would have gotten lost for sure if it wasn’t for the easy to follow lakeshore and the improved visibility around the lake. The transition to what I’m assuming is the default high visibility model based weather is the only thing that allowed the pilotage to work on this flight. I would have had to have computed headings and timings for each leg otherwise.

So my thoughts are that the sim can smoothly transition from METAR to model weather, but it’s still fairly unrealistic as you know you’re near a METAR reporting airport because a blanket of mist appears in the distance. It’s like an anti-rotating beacon that announces the presence of an airport but simultaneously hides its actual location. And again these conditions are likely both overdone for 10sm and also over done in terms of the real world accuracy of the weather in general.

Flights that quickly climb above the METAR range ( a few thousand feet?) or travel between sparse METARs will quickly leave this mist blanket behind. I assume a lot of sim flyers who don’t find the visibility to be a major issue are doing this. Low and slow VFR flyers in the US operating in a METAR dense area will likely be the most affected as low visibility conditions will always prevail along with lots of hard transitions.