Database design goals...



Hi Everyone,

  My rewrite of the design notes is coming around, but I'm not
done yet... I think the number of issues that really need more 
work is pretty small, maybe 5-6 at most.  I thought it might be
helpful to sumbit a part of what I have just to get some input
from you all. The database stuff seems to be hot, so what I have
on that follows below. I spent a fair amount of time identifying
the core goals, and would request we limit the thread to that
sort of flavor, and discuss implementation specific issues after
there is basic agreement on the goals.  Let me know what you think
about the format as well...

Regards, JOhn

================================================================================

Aeronautical Information Database Module

 DESCRIPTION: This module provides support for the management of
 aeronautical data. There are two distinct formats of aeronautical
 data that are dealt with; current data from official sources (such
 as the DAFIF data from NIMA or the NASD data from the FAA/AIS).
 The other form of data is a validated and reformatted subset
 of the official data (perhaps for a given region of the world:
 USA, USA SW, Canada, Europe, Australia, etc.). The records are
 composed of character delimiter fields (similar to the airport,
 navaid records in the current fplan release).

 DESIGN GOALS: The functions that read or perform searches of the
 reformatted (or fplan format) files should be efficient in both
 speed and storage resource requirement terms. The data files
 should be easy to install and update on the end user system and
 of a reasonable size (a reasonable download on a system with a
 dial-up connection to the internet).  An application suitable
 for installation and use by the end user must be available that
 supports the construction of a separate personal database that
 is always be searched by fplan BEFORE the system-wide database.

 The applications and functions that maintain and convert the
 official data should be designed to be easily modified without
 undue hassles to the programmer (provide the ability to respond
 quickly to inevitable changes in the official formats. Priority
 should be placed on implementing support for data sources that
 deliver official data in a timely manner (not expired!) for all
 parts of the world (not just US only). Efficiency in working with
 large datasets is also a primary consideration. The end users
 of fplan can use these components at their option, but they are
 not *required* to.

 IMPLEMENTATION NOTES: The current fplan release has functions
 that provide searching by indentifier only, the ability to
 search on other keys should be implemented. Option 1): A home
 brewed system, combine the existing airport, navaid, airways
 files into a single file (order doesn't matter). Generate
 sorted indexes (with disk addresses that point into the file)
 that can then be searched with a binary search (as currently
 used for the identifier search). Option 2); Build upon a "lite"
 dB package such as Berkeley DB (or something else which can
 be statically compiled into executables).

 The applications for maintaining the large official datasets are
 probably best implemented using an industrial strength database
 solution such as PostgreSQL, mySQL, DB2, and _____ ??? Support
 for multiple packages has been suggested. Conversions would be
 done using scripts in interpreted languages because they have
 minimal development time and still provide good effficiency;
 Perl, Tcl, Python to mention a few. Existing code from avdbtools
 and _____ ??? should also help provide a good start.  What other
 data types should be considered for support; vector imagery
 data like the AVDAFIF, MIDAFIF data sets, raster image data
 such as scanned aeronatical charts, _____ ???

 TASKS: Continue development of fplan records for new data
 types that are now available;

  - airways (done by Ed Falk)
  - active parachute jump zones
  - airspace boundaries (esp. MOAs, restricted, prohibited airspace)
  - other DAFIF items from the list I have forgotten...

================================================================================

-- 
 ___|___ | John C. Peterson, KD6EKQ | Try Linux for Intel x86, because
  -(*)-  | mailto:jcp eskimo com    | a PC is a terrible thing to waste!
  o/ \o  | San Diego, CA  U.S.A     | See http://www.linux.org/ for info



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]