Runway Visual Markings Need to be Fixed

[CharlieFox00]

Many of the runway markings are incorrect in the sim. This may seem trivial to some, but to people looking for immersion and realism, and those who are used to real-world application, it’s very noticeable. The incorrect markings can also lead to mis-identification of the runway environment and depth perception needed for landing.

Understandably, there are exceptions to these rules, on a case-by-case basis, but in general, the following errors are occurring in procedurally-generated (non-bespoke) airports:

• Centerline stripes are too narrow. Standard minimum centerline stripe width should be 36" for precision runways, 18" for non-precision, and 12" for visual runways. The stripes in the sim are often set to 12" wide, even on precision runways.

• Runway designators (numbers) are too small. Most designator numbers and letters should be 60’ tall (long). They should be shortened proportionately for narrower runways only in order to meet a minimum 2’ clearance from the runway edges. In the sim they seem to be about 1/2 the height they should be, most specifically on smaller, narrower runways. This makes it incredibly hard to identify the runway in many situations.Here is a side-by side, scaled image of Auburn Airport (KAUN) runway 25 - sim on the left, reality on the right. Note the correct runway number size at right.

  

• Threshold bars are incorrectly quantified. The standard is pretty clear on this:

  

  Here is a side-by-side, scaled comparison of Oakdale Airport (O27) runway 28 - sim left, reality right. We see only two threshold bars in the sim, when in reality there should be six for this 75’ wide runway. Also note the incorrect number size again, and the presence of edge markings in the sim.

  

• 500’ touchdown zone markings are incorrect. The 500’ TDZ in the sim is a single bar close to the centerline. In reality, it should be three bars on each side of the centerline. This is misapplied on almost all US airports that require them.Here is a side-by side, scaled image of Midland Airport (KMAF) runway 34L - sim on the left, reality on the right. Note the correct 500’ touchdown zone marking at right.

  

• Runway marking borders are missing. All runway and taxiway markings (except runway/taxiway edge and rwy demarcation bars) on Portland Cement Concrete runways should have black borders to enhance contrast and visibility.Here is a side-by side, scaled image of Rapid City Regional Airport (KRAP) runway 32 - sim on the left, reality on the right. Note the black borders on the right.

  

My analysis was performed using Google Maps, facility databases, and FAA publications such as FAR/AIM, and Advisory Circular 150/5340-1M "Standard for Airport Markings (warning:PDF)." (Note my area of expertise is in US systems, not rest-of-world, but I’m sure those are worth a look as well).

[Speed1994]

The different markings would also help to remove the element of ‘sameness’ you get with the runway markings/textures. This has my vote.

I wonder if we can find an ICAO resource on markings to use as the standard before regional localization?

p.s. @CharlieFox00 you forgot to vote for this wishlist request

Edit: The FAA specifications can be found here in chapter 2-3 of the AIM
https://www.faa.gov/air_traffic/publications/atpubs/aim_html/chap2_section_3.html

Edit2: I found this (I’m still hunting for an official ICAO resource)

ICAO recommended Airport Signs, Runway and Taxiway Markings – Aviation Thrust

Edit3: The whole of europe uses EASA regulations so that would be a lot of countries improved by one set of textures.

ICAO as a base and then FAA and EASA for regional would cover a big chunk of the world!

[CharlieFox00]

If you want to get super deep into the dimensions of individual numbers and letters, check out the advisory circular in my original post!

Thanks for the vote!

[stefanocosta]

Hey!

Something that really bothers me in Microsoft Flight Simulator is that EVERY SINGLE AIRPORT has the aiming point markings too near of the thereshold, more than in real life, more than satelite images show.

I will attach 3 examples in this topic using real images x MSFS images for you to compare. But I suggest you to try comparing by yourself in some airport that you like for you too see with your eyes. This happens in every single scenery, don’t matter the producer.

1st example: SBGR TropicalSim

Google Maps:

MSFS:

VERY near…

2nd example: SBGL Asobo

Google Maps:

MSFS:

Again, very much near than it should.

3rd example: LPPT - MK Studios / ORBX

Google Maps

MSFS

Why almost every single scenery of the flight sim suffers of the same thing? Is it only up to the producers? All of them are making the same mistake at the same time? Even Asobo? I don’t think so…

Very boring having to be very low on every approach to touch on aiming point. Unrealistc.

Hope you fix it. Thanks for this space
Regards and happy new year

[OMICO4146]

Google, Google, Google…

I expect here, in this sim Google isn’t source of data, correct? On other side, you need report this to Airports 3-rd party devs to correct this or I see it not correct here? No def sim Airports from your report except n.2, only 3-rd party devs…

[CommonBloom31]

It looks like for LPPT they took a very old photo, something like 10 years ago and just changed the 03 marking to 02

[stefanocosta]

Your comment just dont make any sense. Real life is real life, doesn’t matter if it’s google or bing. What changes is the saturation of the world and some data depending on the date. The airports markings arent variable if you go to google or bing. go check on bing if you see the aiming point in a different location. Beside that in the 3 pictures always the second marking is missing. Dont treat it like a normal thing. If you are an old simmer you will remember that this happens since fs9/fsx.

[stefanocosta]

Like I said, go check by yourself. Just type on google Lisbon airport and go to maps. See the airport of your city and check. The aiming point will be always early

[OMICO4146]

heh

I don’t understand to your system. You know that Bing is probably used here but attach Google heh What you want then compare? Are you sure what data Asobo have available exactly? Really don’t understand to your 3-rd party Airports attached here also. as I said, this is 3-rd party devs things.

[stefanocosta]

My question is: whats wrong with the simulator that leads every single producer to make sceneries and all of them have the same mistake? Almost all of them produce to Xplane as well and the runway is perfect. What happens with msfs?

I ask that because I produced one scenery and I had problems with the runway markings as well.

Go check on bing if the aiming point of SBGR, SBGL and LPPT is located somewhere else making the marking of MSFS correct. Even the ones missing. If its correct, I apologize and delete the post.

[OMICO4146]

@stefanocosta

Go check on bing if the aiming point of SBGR, SBGL and LPPT is located somewhere else making the marking of MSFS correct

Very sry,

not my intention, why yes? If i can help you understand your situation, pls don’t compare this to XPlane. If you have some problem with design of Airport then you need this tell us also in init post that we can understand your situation better. maybe after 20 posts here we can finally get to exact problem, or?

[OMICO4146]

@stefanocosta

If you are an old simmer you will remember that this happens since fs9/fsx

Yes,

I can confirm and did changes by myself with AFD or other Airport scenery designer. Again pls and pls understand, if you want help from users or ask for bug, pls attach relevant source/actual data to compare. Google isn’t source although I agree that in sim data need to be actual as close as possible.

[CharlieFox00]

Hi Stefano, good catch! I believe what you’re seeing is the difference between ICAO and US markings. The sim SDK seems to be geared toward the latter, as far as aim points are concerned.

To further elaborate:

The 2016 ICAO standard for aim point markings

Note that 5.2.5.3 sets a distance standard, however the end of the paragraph states “except that, on a runway equipped with a visual approach slope indicator, the beginning of the marking shall be coincident with the visual approach slope origin.”

That last part implies that the aim point can be independent of the other markings. In the examples you provided, the aim point markings are coincident with the PAPI units, and are decisively independent of a fixed, defined distance. Interestingly, the Sao Paolo (SBGR) 09R markings seem to be a little non-standard in that they are not exactly coincident with the PAPI. Prior to 2008, they were at the 320 meter point, so the ICAO standard may have changed to the independent alignment around then. Interestingly, they are coincident with the PAPI on runway 09L

Whereas in the US, Advisory Circular 150/5340-1M paragraph 2.6 states the following:

Thus, in the US, the standard aim point, except in rare occasions, is 1,020’ from the threshold, irrespective of the PAPI, and in this, becomes part of the standard distances between the touchdown zone markings (replacing the second set of three stripes at the 1,000’ station). Interestingly, the former nomenclature for aimpoint markings was “fixed distance markings.” I still err in calling them that because that was the terminology when I got my certificates.

So the question becomes - can the sim SDK support the coincidental alignment of aimpoint markings with the PAPI for non-US airports?

[CharlieFox00]

Without having the actual airport planning or certification documents (good luck getting those in many cases), I think it’s fair to use aerial images to establish objective reality at a given point in time. Where it gets a little out of sorts is when the imagery is too old.

That said, in the US, the airport facility directories will denote when markings or lighting is non standard (“NSTD”), meaning it doesn’t conform to the advisory circulars or regulations, however, it will not always say why it’s non-standard, thus reference to the aerials.

[stefanocosta]

Hope they get this fixed, @CharlieFox00. Really ain’t a big deal to fix it.

[CharlieFox00]

A person wouldn’t think so. There already are a few switches in the SDK that deal with ICAO vs FAA. It seems like it would be fairly simple to implement a switch that ties the aimpoint to the VASI, independent of the touchdown zone markings.

[f4k3badeshka4]

Really hope this catches more traction, would be such a big immersion booster to the sim and hopefully its something they add in MSFS 2024.

[Xx11zeus11xx]

It won’t. This and the lighting issues are due to the dated engine they use

[Speed1994]

MSFS2024 will feature a new game engine, so it is entirely possible that they will be fixed

[Xx11zeus11xx]

A new engine would be amazing