Re: GTE DUATS and weather graphics/etc.

[Nathan Neulinger <nneul@umr.edu>]

I would suggest that any standardized library to interface with duats
should be written in C - the reason for this is that then it can be used
from ANY of the languages (perl,tcl,python,c,c++), simply by writing a
small wrapper library by hand or using SWIG. 

This makes a LOT more sense than coding something specific to one
scripting language which will then HAVE to be reimplemented if someone
wants to use something else.

For example, I could very easily see portions of this tied in with GMAP
or GRASS, which are a couple of GIS systems.

-- Nathan

"John C. Peterson" wrote:
> 
> On Sat, Jan 29, 2000 at 05:46:52PM -0800, Eugene Leitl wrote:
> > Kenyon D. Cox writes:
> >
> >  > You bet.
> >  >
> >  > As a confirmed non-programmer I've recently tried to decide which
> >  > script language to use for such a project, and how fancy I wanted to
> >
> > Here's the script language to end all script languages:
> > http://python.org
> >
> > It really is very good, and you can choose 3 shiny O'Reilly books to
> > learn it from. You'll be up and flying within a weekend.
> >
> 
>    I'll add my vote for Python as the preferred scripting language.
> I really like the idea of having bindings to the Gtk and Gnome libs,
> (using PyGtk and PyGnome). With the glade interface builder, you can
> rapidly prototype and build very nice GUI applications. The Gnome canvas
> widget is also an excellent resource to have. It's perfectly suited to the
> display of map data where you might want to quickly toggle the visibility
> of things like airspace boundaries, etc. There's a nice page on just the
> canvas widget at;  http://www.gnome.org/devel/canvas/
> 
>    Although I've been making small fixes to fplan, I've been holding off
> on adding any significant new features because I've wanted to clarify
> in my own mind what the best general approach might be. I'm starting to
> settle on the idea of a top level GUI interface to major flight planning
> "modules" that is written in Python, PyGtk, PyGnome. The "modules"
> could be defined in an obvious way so that people could work on them
> independently without too much trouble. Some of the obvious ones are;
> 
>   o Weight and Balance
> 
>   o Gathering of weather observations, forecasts
> 
>   o Aircraft performance predictions (like take off distances estimated from
>       density altitude computations derived from weather observations, etc.)
> 
>   o Route selection (including constraints like fuel availability, and
>      possibly some type of route optimization).
> 
>   o Computation of headings, distances, etc (The stuff that fplan already
>       does... The interface to the Python GUI would be accomplished by
>       adding a simple output format to fplan based on "tags" that could
>       easily be interpreted by the Python GUI for subsequent use and
>       display).
> 
>   o Filing of flight plans
> 
> Any others I have forgot???
> 
> Regards, John
> 
> --
>  ___|___  | John C. Peterson, KD6EKQ | Try Linux for Intel x86, the open
>   -(*)-   | mailto:jaypee@netcom.com | source operating system of the future!
>   o/ \o   | San Diego, CA   U.S.A    | See http://www.linux.org/ for info
> -
> Archives of linux-aviation: http://mail.nl.linux.org/lists/linux-aviation/
> To unsubscribe: send the command "unsubscribe linux-aviation" in the body
> of a mail message to <Majordomo@mail.nl.linux.org>.

-- 


------------------------------------------------------------
Nathan Neulinger                       EMail:  nneul@umr.edu
University of Missouri - Rolla         Phone: (573) 341-4841
CIS - Systems Programming                Fax: (573) 341-4216
-
Archives of linux-aviation: http://mail.nl.linux.org/lists/linux-aviation/
To unsubscribe: send the command "unsubscribe linux-aviation" in the body
of a mail message to <Majordomo@mail.nl.linux.org>.