On 10/10/02 at 1:59 PM David Megginson wrote: >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?
I personally much prefer the second (embedded example). There's also taxiway data needed as well - the thing could get *very* big by the time its finished. Cheers - Dave _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
