Apparently French TAFs are often software-generated.
Again from France Meteo publication:
Noticed
The evolution of the TAF over the successive amendments to ICAO Annex 3 has had the effect of
tend towards a synthesis of the forecast on an aerodrome with the thresholds in focus
significant operational requirements for IFR flights.
Météo-France’s aeronautical forecasters are trained in this regard and the resources
teaching and self-training emphasize compliance with the code so as not to overload
the message unnecessarily, always having in mind the user receiving the TAF (flight pilots
IFR) for which only these operational thresholds are important, according to ICAO Annex 3.
As has already been said previously, the VFR pilot has other products at his disposal.
It was published as research showed that many pilots did not know how to read the new ICAO Annexe 3 TAFs.
For some reason my auto correct is putting a line through Meteo Publication. I don’t know why.
[ you used the strike-through coding – see Posting Tips … also I put the actual quote in italics ]
The phrasing here exactly matches what I learnt in the training (which is quite recent and updated since 2013 for sure)
“Les TAF sont émis par des météorologues. Ces derniers utilisent des modèles de prévision et leur connaissance des effets locaux afin de prévoir les conditions météorologiques.”
For a more official source, this document from Meteo France (2020) explains the difference in perspective between forecasters (“prévisionnistes”) and users (i.e. pilots), with not a single mention of automatically-generated TAF.
If anything, I would assume that the “automation” rumored 10 years ago consists of using many more automated tools for generation, but I have a hard time believing that the TAFs are completely released without human oversight and arbitration. If it requires 10% of the workforce, you’ve also solved the staff shortage problem (one guy can probably do the ~30 TAFs required for the whole of France).
Any change in tools used and generating methods would result in observable differences in forecasts, which would fit with the pilots’ observations.
Mooney_Driver wrote:
Those slashes indicate convective clouds but unable to determine which…
Annex 3 doesn’t specify that the clouds have to be convective. Is that a regional European rule?
Airborne_Again wrote:
Annex 3 doesn’t specify that the clouds have to be convective. Is that a regional European rule?
No, but that is how i see it work most of the times in Autometar tools I am familiar with, which for where I work are not yet active other than in non-operational hours. Those slashes don’t appear unless it’s such stuff or rarely enough that I have not noticed them. However, if the system smells a CB or has detected lightening (even if it originates from a railway line at times 
) then it will very likely generate such groups.
Mooney_Driver wrote:
However, if the system smells a CB or has detected lightening (even if it originates from a railway line at times )
Omitting the “///” implies that the clouds are not convective. So if you do have some means of detecting convective clouds (even with false positives) then it makes sense to only include the “///” when you have. If you can’t detect them then you always have to include the “///”.
From French AIP GEN3.5, /// is used for non convective clouds when the cloud type can’t be detected and ////// is used for convective clouds when base or oktas can’t be measured (TCU or CB are detected using rain radar and lightning data and their base gets correlated to airport ceilometer)
On a side note, does anyone know how far TCU or CB from airport? there has to be an automatic cutoff to appear in METAR? 5nm? 10nm? 30nm?
3 – The cloud layer is calculated using a telemeter and a cloud layer evaluation algorithm. On average, the representation is correct, but depends on the meteorological conditions.The symbol /// is inserted after the cloud coding group to indicate that the type of cloud cannot be observed by the automatic system. The abbreviation NCD (No Cloud Detected) is inserted in place of the cloud coding group when no cloud (below CAVOK height) has been detected by the automatic system and when the system is not able to detect the absence of CB and TCU. The abbreviation NSC (No Significant Cloud) is inserted in place of the cloud coding group when no cloud has been detected by the automatic system (below CAVOK height) and when the system is able to detect the absence of CB or TCU. In France, the identification of the convective conditions (CB, TCU) is ensured via an algorithm using the data from the precipitation radars and lightning detection. The ////// symbol is used in front of CB (or TCU) when the automatic system has detected a CB (or TCU), as the cloud amount and the cloud height cannot be observed.
Ibra wrote:
////// is used for convective clouds when base or oktas can’t be measured
Using “/////” when cloud base or amount can’t be detected is standard. The interesting thing is with equipment that can detect this in some cases and not in others. E.g. the practice that you and Mooney_Driver describes (although quite in accordance with the standards and I’m not saying it’s bad) can lead pilots to believe that “///” everywhere means that the clouds are convective.
Indeed, it’s easier to think //// means convective clouds, altough more conservative and resonable classification (if system can’t distinguish clouds, it’s likely that they have not decided between low startus and towering cumulus), the standard is documented in GEN3.5 under “AUTO METAR”, under “Different or missing information”
My guess the automated system will have difficulty detecting cloud base or type when fronts meet each other near airport, say cold front catching warm front: radar equipement usually have difficulty with precipitations in low convective clouds and airport equipment have difficulty with oktas or base when low stratus gets lift-off by convection
This was BKN003 in AUTO METAR, you can see the low clouds on top of the ceilometer: with an algorithm, one has to write few threshold on the data to get it to work, while with human observer (MET or ATC), it’s easier to guess by looking outside window
Airborne_Again wrote:
Using “/////” when cloud base or amount can’t be detected is standard. The interesting thing is with equipment that can detect this in some cases and not in others. E.g. the practice that you and Mooney_Driver describes (although quite in accordance with the standards and I’m not saying it’s bad) can lead pilots to believe that “///” everywhere means that the clouds are convective.
They way I have experienced it mostly was that the system appears to have no problem determining some cloud type as long as there are no convective clouds, hence you hardly ever see /// or ///// without them. Obviously those algorithms get updated once in a while and will do things differently thereafter, where you will need to find out what it’s doing with the new implementation….
Different systems may “detect” clouds differently. (That they detect something does not necessarily mean they are right however.)
