OK, but for at least one airport I know of (S50) the runways didn’t change visually at all, they were simply renumbered to reflect magnetic variation drift, so regenerating the airport with new numbers would be just fine. I can’t speak for any others b/c I haven’t studied the data, but I would appreciate if my home airport could get those runways renumbered so I could actually practice with my new SID and approaches.
3 Likes
im not sure if i understand your answer completely, so sorry if you aware of this. But runway designator changes dont happen because the airpots physically shifted, just the magnetic variation did. So from a visual standpoint, the airport obviously still matches the satelleite data. Of course, the layout might have changed for taxiways etc. but that doesnt matter, just the runway designators in the scenery have to be changed, thats it.
Of course, there are occasions where they actually built a new runway, but thats usually not the main reason for this mismatch.
Was that for me or CrandallMalcolm?
The answer remains the same - someone needs to touch the BGL file that contains S50. The appearance is indeed close enough, but this is more a niche case rather than the gross changes required in other airport scenarios.
Either Asobo can do it, or maybe - just maybe, someone overrides the BGL file with a Community Mod.
The answer was indeed meant to you. 
As an example, i just got a mail today from my local airport that the runway designators have to be changed. And thats not because the airport phisically changed in anyway, but the magnetig field shifted enough over the years that now the numbers arent correct anymore. This will probably be reflected in the next navdata update, but phisically, absolutely nothing changed. Just the numbers have to be scraped off and new ones painted.
But yeah, someone needs to change the airport bgl. Asobo should find a way for that. Or peoples have to accept that they just have to live with this issue.
If the navdata would override the scenery designators, or the sim would read from the navdata instead of the sceneryfile, this could be a fix. But im not sure how msfs handles the data.
Would this ussue also exist if one uses the navigraph navdata or is this a default navdata issue?
It’s an underlying airport file issue. I checked and 16-34 shows up no matter if it’s Navblue or Navigraph.
1 Like
As I have mentioned earlier in this thread, I have dissected (decompiled) the shipped BGL files and they do NOT contain any legs at all for any procedure for a number of airports. My definition of a leg is a waypoint within a procedure, either a fixed one with predefined lat/lon or a calculated one depending on factors current at the flight. So the procedures are there but… they are empty.
Maybe there are more than one problem in this area but what I describe is what I filed a ticket for. Either MS is removing the legs on the server during BGL creation or the incoming navdata to MS from the provider is wrong. The net result is that you cannot use the procedures in any aircraft.
Hi,
to be clarified again - there ARE terminal procedures with legs on the greece airports - as an example: LGSA which is part of your list. And that has nothing todo which navdata provider you´re using (MSFS or Navigraph).
Here, when I use the stock MSFS LGSA scenery, with the stock navdata:
So, when there are no legs existing, you can´t select any of these procedures. So, the statement is simple wrong. Some airports have no proedures but that´s normal.
… and now back what I have written before with a specific example LGSA - in the stock scenery of MSFS you see following airport-layout/runways:
In reality, the runways are completely! different (11L/29R):
That means the MSFS can´t assign any existing terminal procedure to the existing stock runways and therefore the procedures will not be shown.
When you now install a 3rd party scenery, which reflects the real-world (ie. this one), you will see following:
… the correct runways as in the real-world. From now on, without installing anything else, the Navigraph terminal procedures are available and selectable. Everywhere - in the WorldMap and in all stock addons.
Conclusion:
Compare the real-world airport-diagram/runway idents with the the runway-idents in MSFS. When they are equal, and you don´t see terminal procedures than
- the airport hasn´t one
- the stock navdata MSFS hasn´t one included
When they don´t match - look, if you find any 3rd party scenery, which reflects the reality or enter the terminal procedures manually in your navigation-device.
The main reason is not an empty procedures, because there are no empty procedures (procedures without any legs) available, not in the stock MSFS data, nor in the navigraph data.
It is the limitation in the MSFS, that when the MSFS can´t assign a terminal procedure to a runway, the MSFS disable this part. Therefore the workaround from Asobo/MS to define such procedure with “ALL”, that the procedures will be shown even, when the runway-idents are changed. See the example with LGSA - in my screenshot you see the BAVE1A ALL, which means for all runways but that´s not correct, BAVE1A is only for departures for 29R … with the “ALL” assignment, the MSFS doesn´t make the runway-ident check and therefore you can use the procedures (but in reallity its wrong).
Here, 3rd party scenery installed and Navigraph AIRAC 2407 installed:
BAVE1A is assigned to 29R only and due the 3rd party scenery with the correct runway ident, available/selectable in MSFS. When you would use the default/stock scenery, you wouldn´t see this list due the reasons above.
Hope that helps
Richard
2 Likes
I submit that making airports and their approaches conform to their actual runway headings and published data is something that the developer should do. Making buildings more colorful seems like a community effort.
You can open a Zendesk to get it logged.
Done (https://flightsimulator.zendesk.com/hc/en-us/requests/219539) but the larger point remains - this is an issue that MSFS and Asobo can detect and deal with programmatically and this should not require user input or mods to deal with.
I get what you say but how is it then possible that I find no legs for some procedures in the default navdata? If you are interested I can send you a small zip with c# source code for my console app where I analyze the BGL files. Of course it might have bugs but if so, you are more than welcome to enlighten me!