Why can't we stick it into the scenery directories, but one directory up from the tiles, so we have one file per 10degx10deg of planet. That should ensure that FGFS doesn't need to load all that many files, and just having the one file in the base package will allow initial use.
> I've been pulling information out of the DAFIF in different shapes and > trying to decide how we should model our own airport database. For > the external representation, we want something flexible enough that we > can add new types of data easily -- fixed-length records with > fixed-width fields just don't cut it. Any XML or INI files with > airport data will be huge, of course, but they don't have to be part > of the core base package -- we can include only precompiled binary > files of some sort, and make the source XML available as a separate > download. > > Getting on to the data model, there are some obvious relationships. > For example, there is a one-to-many relationship between airports and > runways, and another between airports and comm frequencies. We could > model things purely relationally like this: > > <airport id="CYOW"> > ... > </airport> > > <runway> > <ident>04/22</ident> > <airport-ref>CYOW</airport-ref> > ... > </runway> > > <runway> > <ident>07/25</ident> > <airport-ref>CYOW</airport-ref> > ... > </runway> > > <runway> > <ident>14/32</ident> > <airport-ref>CYOW</airport-ref> > ... > </runway> > > <comm> > <type>tower</type> > <freq-mhz>118.8</freq-mhz> > <airport-ref>CYOW</airport-ref> > ... > </comm> > > But that kind of thing is a major pain to process. Personally, I > prefer to model relationships by embedding when the relationship is > one-to-many rather than many-to-many (i.e. no runway belongs to more > than one airport): > > <airport id="CYOW"> > <name>MacDonald-Cartier International</name> > <short-name>Ottawa</short-name> > <lat>..</lat> > <lon>..</lon> > <elev>..</elev> > ... > <runways> > <runway> > <ident>04/22</ident> > <airport-ref>CYOW</airport-ref> > ... > </runway> > <runway> > <ident>07/25</ident> > <airport-ref>CYOW</airport-ref> > ... > </runway> > <runway> > <ident>14/32</ident> > <airport-ref>CYOW</airport-ref> > ... > </runway> > </runways> > <comms> > <comm> > <type>tower</type> > <freq-mhz>118.8</freq-mhz> > <airport-ref>CYOW</airport-ref> > ... > </comm> > </comms> > </airport> > > We can continue to add to a format like this to help with AI ATC and > planes. For example, we can specify the location of the control > tower, state when the lights are turned on and off (if not ARCAL) and > what hours the tower is open, specify preferred runways for different > types of aircraft (i.e. CYOW generally has 04 or 22 for light aircraft > operating together with 07, 14, 25, or 32) and for noise-abatement, > control-zone limits (when ATC hands you off), etc. etc. > > Comments? > > > 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 > > _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
