ILS Not Aligned with centre of runway

Bug Reporting Hub ATC, Traffic & NAVAIDs
, , , , ,
22

I have the same Issue on many different Airports.

1 Like
23

As we’ve seen, sometimes it’s a scenery issue, sometimes it’s a navdata issue, and sometimes it’s the way it is meant to be in real life. So saying it’s an issue on many airports isn’t going to help - need data. What airports?

24

The last that i remember are
Frankfurt - EDDF
DĂŒsseldorf - EDDL
New York - JFK
Denver - DEN
Abu Dhabi - AUH
Tokio Haneda - HND
London Heathrow - LHR

1 Like
25

In case of the rwy aligned Localizers the following variables determine the rwy alignment:

  1. Localizer coordinate

  2. Magnetic course

  3. Magvar

To get a properly aligned Localizers the following conditions must be met:

  1. Coordinate needs to be aligned with MSFS centerline

  2. The combination of Course and Magvar must match the MSFS rwy true bearing

Unfortunately there will be always small misalignments in the MSFS world unless Localizers are recalculated to the MSFS Sceneries. At least for the default sceneries that could be done automatically.

For Glideslopes a similar issue exists when postion or elevations don‘t match the scenery.

Extreme cases can be corrected by building an own Navdata.bgl with the affected Localizer according to the tutorial: https://docs.flightsimulator.com/msfs2024/html/7_Samples_Tutorials/Samples/Sceneries/SimpleNavData.htm

It would be nice if there would be an easier way than the current editor / xml files to make those corrections quicker.

Here is an Example that would correct the wrong Glideslope at EDDS due to the flat RWY:

<?xml version='1.0' encoding='ASCII'?>
<FSData version="9.0">
  <Airport lat="48.6898777261376" lon="9.22196388244629" alt="1255F" ident="EDDS" onlyAddIfReplace="TRUE">
   <Ils
                lat="48.684952304"
                lon="9.196054016"
                alt="373.075M"
                heading="250.0"
                frequency="109.900"
                range="27.0N"
                magvar="-3.987"
                ident="ISTW"
                width="5.19999980926514"
                name="ILS/DME 25"
                backCourse="FALSE">
                <GlideSlope
                    lat="48.692385287"
                    lon="9.240224948"
                    alt="1259F"
                    pitch="3"
                    range="27.0N"/>
                <Dme
                    lat="48.692385287"
                    lon="9.240224948"
                    alt="1259F"
                    range="27.0N"/>
            </Ils>
</Airport>
   </FSData>
26

This is where we can get into issues. If we change the navdata for EDDS to make it work within the sim, it’ll mess everything up on the altitudes for the approach. The runway in the sim needs to be corrected, full stop, not the navdata.

1 Like
27

The problem with written text is it does not show the tone of the conversation.

In no way am I criticising the developers for this error. I was just saying it to bring it to their attention.

With Melbourne (YMML), Sydney (34L and 34R) I get this problem where the vertical ILS locks the aircraft to an approach between the runway and the taxiway to the east. The horizontal glide scope appears to be correct.

Is there any suggestions they can offer to help fix? It appears the error is a bit widespread amongst member of the community.

Cheers,

Oz.

28

I do not have this issue with navdata from Navigraph installed. With stock navdata I do have this issue.

29

Unfortunately state source published values for Localizer and Glideslopes will never be 100% compatible with the MSFS world (Position, Elevation) as they are not made for flight simulator use in the first place.

Even Navigraph does some Localizer alignment calculations due to the above mentioned reasons. That is why YMML is different on their side.

Its easier to adapt the Localizer and Glideslope to the MSFS Scenery than the RWY to the Navdata. Changing a RWY Profile is much more complex than adjusting the Navdata.

30

Right, but it has knock-on consequences. EDDS is a prime example. Your MDAs, DAs, and minimum segment altitudes on the approaches to runway 27 would be egregiously off if you just changed the altitudes. Have to pick the better of two bad situations and that instance is so bad (70+ feet!), it’s hard to say what’s worse.

31

Thanks for the replies.

Maki152, do you pay for navigraph or is there a free version available?

32

Navigraph has the same issues, just at different airports (and some of the same airports also).

The core issue is that national AIP data for ILSs is not designed for simulator use. ILS locations are not surveyed regularly or with any particular accuracy, because in real life they very much don’t need to be; you’re picking up the radio station wherever it actually is and the navdata location is completely irrelevant to the actual broadcast radio guidance. And we have observed that as aerodrome authority operating budgets get crunched across the world, these values tend to get updated at wider and wider intervals.

We’re looking into ways we can “massage” the surveyed antenna location data but it’s a very difficult problem to solve, as the ARINC data standard also doesn’t include any intended offset. The published approach charts will, but those are not something that are machine readable en masse. Just locking ILSs to the ARINC published runway positions and angles is also problematic, as you have to make guesses about intended offset, and ARINC runway data can be off by some fractions of degrees for similar reasons, as well as generally not exactly matching the simulator scenery runway positions, which have been aligned to actual satellite imagery.

Unfortunately there’s no magic bullet or wand here anyone can wave, but it is an active discussion topic and we are looking for ways to improve this situation.

4 Likes
33

Pay for it. Navdata only can be bought for ~$40 a year.

1 Like
34

Ok. Thanks. I will investigate.

35

Thanks for the detailed reply.

36

Following field from ARINC 424 continuation record could be used:

Localizer/Azimuth Position Reference (@,+,-) Definition/Description: The “Localizer/Azimuth Position Reference” field indicates whether the antenna is situated beyond the stop end of the runway, ahead of or beyond the approach end of the runway. The “Back Azimuth Position Reference” field indicates whether the antenna is situated ahead of the approach end of the runway, ahead of or beyond the stop end of the runway. Source/Content: For Localizer and Azimuth positions the field is blank (@) when the antenna is situated beyond the stop end of the runway, it contains a plus (+) sign when the antenna is situated ahead of the approach end of the runway or a minus (-) sign when it is located off to one side of the runway. For Back Azimuth positions the field is blank (@) when the antenna is situated ahead of the approach end of the runway, it contains a plus (+) sign when the antenna is situated beyond the stop end of the runway or a minus (-) sign when it is located off to one side of the runway.

Alternatively following calculation could be done the get the position reference of the Localizer vs. the MSFS RWY:

Determine the extended MSFS centerline and then compare the Localizer position in relation to the MSFS stop end. If within a certain tolerance of the RWY width, it could be aligned.

For cases where an automation is not possible, a simple editor accessible via the normal user interface could be provided to allow users to do Localizer, GP, DME corrections on the fly respective to the installed sceneries.

37

Unfortunately, if you read the field description, it cannot. It doesn’t give you an absolute world position (which we already have in another field anyway), it just says, generally, if the antenna is at the front, the back, or the side of the runway. None of those correlate definitively to if the approach is intended to be an offset approach.

This has the same problem. There are offset approaches in which the antenna is in the normal location at the stop end of the runway, just that the bearing is offset from the runway centerline. These offsets can be as low as 1-2 degrees, so it is difficult to come up with an appropriate “snapping” heuristic.

You can do this today in the scenery editor, and make as many corrections as one likes.

1 Like
38

Don`t focus too much on the magnetic bearing value. They just reflect “Published values” and can be different from the RWY magnetic. Looking at the magnetic values, differences of 1-2° are normal as RWY bearing (Airport magvar) and Localizer Course (Localizer magvar) might be based on different magnetic variation values.

The trick is that if the resulting Localizer true and the RWY true based on the ARINC file values are the same or very close to each other e.g. wthin a degree or less and the Localizer position is beyond the RWY, the Localizer can be considered aligned with the RWY centerline. There should be no 1 - 2 degrees difference when comparing the true values in case the Localizer is supposed to be aligned with the RWY.

If you have some specific examples, could you please show them to me in order to verify that they are coded correctly on Lido side.

It would be helpful if the scenery editor would be able to directly show the relevant information needed for Localizer construction based on the used scenery. The debug info helps already as a baseline to start with but should be available in a copy paste form instead of having to type it down manually. Sometimes it seems that the debug is not exactly matching the drawn RWY and there are still minor corrections necessary to get the alignment right.

RWY center coordinate should be provided with full available resolution
RWY true should be available with full resolution

With that a transparent RWY as overlay could be created in a faster way to plot the extended centerline of the respective scenery and determine the Localizer position for alignment.