Ambiguity: cloud height AGL/MSL


New member
It seems that when setting cloud bases in Active Sky, one is instructed to enter base altitude in MSL. But upon reaching the METAR formatted summary, these base altitudes are displayed as ceilings. In the real world, ceilings are always reported/forecast in AGL. But in Active Sky, they instead display the MSL values as ceilings, which are not the same thing.

It seems to me that if I am setting the bases in MSL, then the METAR should provide different ceilings for every station.
Alternatively, if I could set the bases as ceilings in AGL, then it could adjust cloud height across the region to keep the ceiling always the same AGL.
I can see advantages to both approaches, but the main thing is that it should be consistent and clear. If I set it in MSL, then calculate the proper AGL value instead of treating them as the same thing.

I noticed this too. Cloud bases are measured as AGL but landing at KATL one day where the metar reported OVC014, I didn't come out of the clouds on final until about 400-500ft AGL. KATL elevation is about 1,000ft


Staff member
The issue is that when "setting" weather over an area up to many hundreds of miles wide (default 100nm), you must use MSL reference for altitude consistency. If you used AGL and "translated" altitudes for each and every station, small variations in elevations of different stations within a single weather depiction cell would lead to different cloud layer altitudes and non-seemless, unacceptable cloud layers. Thus we use MSL altitude specification in manual weather configuration, and only in manual weather configuration. We try our best to notify users of this in the UI, at various points, including at the end before application, but we do understand that this is not intuitive and goes missed quite often.

We have considered changes here, in different ways, such as allowing "station specific" setting which uses AGL reference, and "range specific" using MSL, but this was also deemed too confusing. Another idea was to identify when a station ICAO was entered a METAR string, and use that station's elevation for MSL translation before application (which I liked the best) but ended up also being confusing especially when an incorrect or ambiguous ICAOID was used. We keep coming to the conclusion that an entire re-design of weather customization and UX is ideal, and we are working on that in new product versions. Unfortunately we've been set back quite a few times due to major changes in the various platforms requiring priority to be spent in other more critical areas. But we're getting there.

We appreciate the feedback. For now, until we have a better way, we recommend embracing MSL as the reference for all customized weather sky conditions/cloud layer parameters.
Thanks for the explanation. Could a possible suggestion be to use the departure and arrival airports, that you've set in the flight plan in ActiveSky and have the cloud bases set as AGL for those airports?