[Flightgear-devel] re: [Flightgear-cvslogs] CVS: data/Navaids default.ils.gz,1.8,1.9
Curtis L. Olson writes: > Modified Files: > default.ils.gz > Log Message: > Align all the approaches I could automatically match up to runways. Where we have exact data on the lat/lon of the localizer and GS, we should use it, and fix our airport data if there's a discrepancy; where we're just guessing, of course, we should do the auto-correction. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] re: [Flightgear-cvslogs] CVS: data/Navaids default.ils.gz,1.8,1.9
David Megginson writes: > Curtis L. Olson writes: > > > Modified Files: > >default.ils.gz > > Log Message: > > Align all the approaches I could automatically match up to runways. > > Where we have exact data on the lat/lon of the localizer and GS, we > should use it, and fix our airport data if there's a discrepancy; > where we're just guessing, of course, we should do the > auto-correction. The problem is that I have two data sets both providing "exact" locations for the localizer and both disagreeing significantly on the position and orientation. :-( Our runway data is really out of date and most of which is of unknown quality/origin. We *really* need to get our airport database updated from recent DAFIFT/FAA data first. Then we will have a better idea if our localizer positions are reasonable and we can come up with a better solution auto-aligning (or not) the localizers (or the runways.) Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] re: [Flightgear-cvslogs] CVS: data/Navaids default.ils.gz,1.8,1.9
Curtis L. Olson writes: > The problem is that I have two data sets both providing "exact" > locations for the localizer and both disagreeing significantly on the > position and orientation. :-( We have to decide on the authority of each data point individually. Anything that we get from the DAFIF or FAA data should stand as-is, for example. For Robin Peel's data, we should fix things only when there is a known problem. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] re: [Flightgear-cvslogs] CVS: data/Navaids default.ils.gz,1.8,1.9
David Megginson writes: > We have to decide on the authority of each data point individually. > Anything that we get from the DAFIF or FAA data should stand as-is, > for example. For Robin Peel's data, we should fix things only when > there is a known problem. The problem is that in my spot checking, DAFIF and FAA data always disagree, sometimes/often significantly. Usually neither set of localizer info brings you in over the threshold correctly. Robin auto corrects all the approaches for X-Plane so those by default should be considered "munged" ... but they are munged for X-Planes coordinate system. I don't know if either DAFIF or FAA could be considered "authoritative". We'd need to go stand on top of a few actual localizers with a differential gps to verify if one or the other is more accurate. I suspect that for both, the information is often not recorded to the tolerances we need in FlightGear to get the approach to line up perfectly. It's probably fine for chart making or the other anticipated uses. I'm guessing that when an ILS is installed, someone goes out and stands at the center of a runway with something equivalent to a VOR gauge (or maybe they park a real aircraft out there) and they have the person at the localizer end adjust the heading until the VOR needle centers. That's just a guess. What get's recorded and put into the DAFIFT/FAA data could be *much* cruder or error prone. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] re: [Flightgear-cvslogs] CVS: data/Navaids default.ils.gz,1.8,1.9
Curtis L. Olson writes: > I don't know if either DAFIF or FAA could be considered > "authoritative". I'd consider FAA authoritative for U.S. airports, and DAFIF for other countries, again, until proven otherwise. > I'm guessing that when an ILS is installed, someone goes out and > stands at the center of a runway with something equivalent to a VOR > gauge (or maybe they park a real aircraft out there) and they have the > person at the localizer end adjust the heading until the VOR needle > centers. That wouldn't work -- you need to test it at the appropriate altitude, because of the possibility of interference (the same reason that you have to start the engine before you can test your nav radios on the ground). I watched Transport Canada testing the ILS 07 at CYOW a few days ago -- they NOTAM'ed out the ILS, then sent out their Dash-8 to fly the approach over and over and over again, collecting data. The pilot was quite a cowboy, breaking off the approach literally less than half a wingspan above the runway and rolling straight into a 30-degree bank (I was tempted to go out afterwards and look for paint marks on the pavement). The biggest concern is the approach path, not the runway itself -- the purpose of an IAP is to allow an aircraft to transition from IFR enroute altitudes to a point where the pilot can land it visually, and the approach path has to be guaranteed free of obstructions for a certain distance in every direction. The actual landing, on the other hand, is the one part of the procedure that *is* visual. In a normal Cat I ILS approach, that last possible point to transition to visual will be 200 ft AGL and less than a quarter mile back. For a LOC-only approach, it will more likely be 500 ft AGL and a mile or two back. > What get's recorded and put into the DAFIFT/FAA data could be > *much* cruder or error prone. There are standards for registering navaids with the FAA -- I saw them recently online, but I don't remember where. The lat/lon/elev fields demanded a fairly high degree of accuracy. It's also worth noting that the FAA data is (indirectly, through suppliers like Jepp) the basis for the GPS databases that GA and the airlines use. It might be interesting to look at some examples where the FAA and DAFIF data disagrees -- what are some of the most serious ones? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
