Database design goals...
- From: "John C. Peterson" <jcp eskimo com>
- To: fplan-list gnome org
- Subject: Database design goals...
- Date: Fri, 9 Nov 2001 00:28:20 -0800
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]