On Aug 15, Dirk Dittmann wrote: Hello
> - Dialbook get Nummer : > the search should not return the first frequency, the nearest in Range is > more > suitable. True, it currently returns the first in alphabetical order. As Clement answered, adding ranges, even simple one, should narrow the choice of returned. > - Thinking about center controller: > the dialbook could summarize all frequencies of the control area and dials > one > number on the server. So we have one desk for the center. Especially for > OpenRadar it will be an interesting feature. What is 'center controler'? Do you mean Air Control Center i.e. En Route long distance or other FIR frequencies? > - As main problem i see in the ranges of the frequencies: > the apt.dat provides no info about ranges. > And there are a lot of intersections between frequencies. apt.dat provides a "type" for each frequency (the 5x code on the line of each freq). I thought about defining a range for each type (say 20 nm for TWR freq = type 54, 10 nm for GND freq = type 53), but if it is acceptable for ground frequencies (which rarely go over a few nm) it is not for towers or approaches which can have very different ranges (at least in real life). For the overlap in the frequencies, yes there are a lot currently. It should be better with the range depending on altitude (I have a patch against fgcom to add that to the standalone fgcom as Clement already did it for the embeeded fgcom), but may not be enough. So on the long term adding ranges to frequencies based on their type is probably needed too. > Approaching EDDP from east is no fun for the controller. The pilot dials to > all other airports in the near until it intercepts the ils. Must be very nice if there are some ground frequencies he reaches when approaching :) > IMO we should maintain a own dialbook. May bee based on apt.dat (or more > realistic infos ???) + manual correction of used(atced) airports. And for > this > airports we need a working solution to increase the fun for atc & pilot. You can find the VFR frequencies at the ICAO website. Integrating that to apt.dat would be a big work, but I would help if apt.dat was maintained and distributed in a more collaborative manner (a git repo for example). fgcom's (the standalone one) data comes from apt.dat, so the source is apt.dat. > This is the point where realism meets fg reality, we have hopefully one atc > at > the airport and he needs a 100nm range frequency at the tower. It is the case, except when the tower frequency overlaps with another station nearby because of one having a too long range. We can fix that :) > All frequencies could have the real range and each airport gets a special > frequency "all in one" (100nm). So we can play real and real. As said, this means addind the "ranges" to each freq. Either with a brutal rule (such as "any GND freq, never talks over 10 nm range") or using range numbers from a source (apt.dat). BTW, flightgear uses a very old apt.dat currently, this also does not help (Clement, this might even reintroduce some wrong data which is fixed in fgcom's positions.txt :)) -- bug ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
