For example at EGLC, runway 09 is missing fields 9, 10 and 11 (5.36 latitude, 5.37 longitude, 5.69 threshold displacement distance) (as are many other runways).
09 Jan 2019 Runway fields 9, 10 and 11 are no longer optional, but required
…suggests you use a Laminar-provided parser to convert from ARINC 424 to the native X-Plane format?
If so, could you ensure that you’re using the latest available version of said Laminar parser and, if necessary, kindly ask them to fix it so it produces output compliant with their published specifications?
Regards,
Tim
P.S. from the other thread:
this should be asked Laminar Research because since XP11/12 we use a own library/parser for these two datasets
FWIW, “a own” is ambiguous (and probably grammatically incorrect); I was able to infer from context (assuming I actually did understand it correctly) but it would be easier to understand if you used their own (that of Laminar Research) or, if you meant the opposite, our own (that of Navigraph)
Hi Tim,
please can you explain in detail what issue you have in XP11/XP12 with EGLC? I have tried it in XP11/12 but it works as expected.
I’m not sure about your question, but do you check the data format or do you report an issue with the data? For the first thing, please contact LMR directly. When there is an data issue, we will check it, when we can reproduce it. Therefore, it would be nice, when I can get more details of your report. Here on my XP12 EGLC works as expect it, but possible I misunderstood you here.
Thank you
Richard
PS: I will inform LMR to check their public documentation, even when this is not really our job
An issue with the data, albeit not causing any problems in practice.
Laminar’s own specification (XP CIFP1102 for X-Plane 11.30 or later) mandates that the threshold data (latitude, longitude, displacement) be included (required since 9 January 2019, was optional before) but some of the “RWY:” records in Navigraph’s data do not include it (looks like about a thousand or so).
Understood, the public documentation is correct so far but that doesn’t mean that this is the same logic what we use in our parser.
So, when you (a customer) create a procedure, this information is mandatory, to avoid issues with the procedure. But as you see it’s working without too but that happens only when some requirements are set correctly.
This is the difference now … the parser is doing some checks and validations before and remove double information in the output file.
Hi Tim,
“double information” means reducing multiple equal data in the sim on different places, means when some data are existing in the sim somewhere it can be re-use also, when as an example the runway-coordinates are zero.
