Hi all,
I’m in the final stretches of setting up my own OFP layout as php, matching a real-world one as close as possible. I’ve run into a few issues with the given JSON flight file:
-
A MORA key is given for each waypoint in the main flight log (origin->destination) but not in the alternate flight logs (destination->alternates). Since in my example, the layout of the alternate flight log is the same as the main one, MORA is also displayed here but I can’t find it in the JSON.
-
ETOPS alternates: Any chance we can include these variables?
a) approach type
b) required minima (ceiling+vis)
c) correct the fcst_vis (that’s always returning 9650 metres for some reason)
here’s an example:
ENRTE ALTNS (WEATHER SUITABILITY PERIOD)
EINN/24 CAT1DME 12:38 17:22 WX MIN: 400-1350 FCST WX: 9999-9999
CYYT/28 CAT1+DM 14:51 17:22 WX MIN: 600-3218 FCST WX: 800-9999
-
<sid_ident> and <star_ident> are, like Simbrief in general, displaying the SID/STAR identifier shortened by 1 character. I’ve never come across this in the many OFP layouts I’ve seen to date. Can we get the JSON to display SID/STAR ident fully instead of shortened (e.g. OBOKA4G iso OBOK4G)
-
Is there a list of all supported NOTAM Q-codes and the respective <notam_qcode_category> that Simbrief uses? I’m grouping NOTAMs into categories like +++RUNWAY+++, +++APPROACH PROCEDURE+++, etc. but this would be easier to complete with a cohesive list of what Simbrief can and can’t show.
Thank you very much for taking into consideration, looking forward to hear back from you!
For the approach mins, published Apch Mins are usually NOT a part of the generic Arinc 424 navigation data, so SBF will probably not have them. Some flight planning systems/airlines have a full staff whose sole purpose in life is to load all of the AIP data (Mins) to populate a Mins database to output that - like what some Lido OFPs have done for their operators who choose a standard Lido format. Lido does have a NavData staff (not sure whether they are in Zurich or Gdansk) and that is one of the things they do, as AIPs change, they go in and load the mins for the ILS at so-and-so airport.
I’d agree with Number 3.
Good morning Doug,
happy to hear back! And thanks so much for your insights, super interesting! You do have a background in real-life dispatch too if I’m not mistaken, right?
Now that I’m reading it, it does make sense not to put approaches and minima into the ARINC-OFP xml-file. It is so exciting to learn how things are done in real airlines, and just diving a little into this OFP coding has made me wonder how “my” airline does things, too.
So, the approach types and minima are likely to require a different solution, I can manage that, just put a placeholder in and call it a day for the approach type.
The array key ‘mora’ in the JSON however, is that something we could possibly implement? For any given waypoint, if it appeared in the main flight log, the array key would exist, so the data would be there, technically.
Grid Mora is a part of the ARINC 424 data file. When I was a key user for a flight planning system, the monthly A424 file contained a data table of Grid MORAs.