Narrative:

Flying into guatemala city - mggt; we experienced a navigation coding problem with the ILS 02 zulu approach in the FMS. This problem has been described to some extent in [company communications]. We had been vectored off of the airway by ATC due to outbound climbing traffic. After traffic passed; we were re-cleared via present position direct to the aur VOR for the ILS 02 zulu approach. We reselected aur in the FMS and went present position direct. We slowed to 160 KIAS with landing gear and flaps extended to 15 prior to crossing aur; the IAF. Upon observing the outbound track for the teardrop approach; we noticed that the path extended well beyond the 7 mile arc we had previously built in the fix page. There should have been a turn point at aur 5.0 RF on the outbound leg; but this had dropped out. Cross-checking aur DME and the arc on the fix page; we verified that the tear drop portion of the approach now had erroneously displayed our proposed flight path well beyond the 7 mile limit on the navigation displays. Approaching 6 DME; I disengaged the autopilot and turned back to intercept the ILS runway 02 approach course. We reselected the runway as the active waypoint to keep the fly-to points and missed approach procedure ahead of the jet. We armed the approach mode for the ILS once inbound for back up course and glide path guidance and landed in daylight VMC conditions uneventfully on runway 02.this is the first time I've actually experienced this error on the nd in several trips to guatemala city.I recommend alerting crews of the possible data base coding problem to help ensure all crews are aware of the potential hazard of an over-extended outbound flight path displaying on the nd of the approach procedure beyond the allowable limits.

Google
 

Original NASA ASRS Text

Title: B737-800 Captain reported an FMS issue when trying to load the ILS 02 Zulu approach to MGGT.

Narrative: Flying into Guatemala City - MGGT; we experienced a navigation coding problem with the ILS 02 Zulu approach in the FMS. This problem has been described to some extent in [company communications]. We had been vectored off of the airway by ATC due to outbound climbing traffic. After traffic passed; we were re-cleared via present position direct to the AUR VOR for the ILS 02 Zulu approach. We reselected AUR in the FMS and went present position direct. We slowed to 160 KIAS with landing gear and flaps extended to 15 prior to crossing AUR; the IAF. Upon observing the outbound track for the teardrop approach; we noticed that the path extended well beyond the 7 mile arc we had previously built in the fix page. There should have been a turn point at AUR 5.0 RF on the outbound leg; but this had dropped out. Cross-checking AUR DME and the arc on the fix page; we verified that the tear drop portion of the approach now had erroneously displayed our proposed flight path well beyond the 7 mile limit on the Navigation Displays. Approaching 6 DME; I disengaged the autopilot and turned back to intercept the ILS runway 02 approach course. We reselected the runway as the active waypoint to keep the fly-to points and missed approach procedure ahead of the jet. We armed the approach mode for the ILS once inbound for back up course and glide path guidance and landed in daylight VMC conditions uneventfully on runway 02.This is the first time I've actually experienced this error on the ND in several trips to Guatemala City.I recommend alerting crews of the possible data base coding problem to help ensure all crews are aware of the potential hazard of an over-extended outbound flight path displaying on the ND of the approach procedure beyond the allowable limits.

Data retrieved from NASA's ASRS site and automatically converted to unabbreviated mixed upper/lowercase text. This report is for informational purposes with no guarantee of accuracy. See NASA's ASRS site for official report.