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

Reply via email to