[Xastir] Question/suggestion

[Ken Koster]

I've added the developers list to this as well since the topic is more
appropriate there.  Those of you responding on the developers list
should probably edit out the user list address.

Ken,  N7IPB

On Wednesday 14 August 2002 06:06, Gerry Wheeler KG4NBB wrote:

> Most of the time, my "ideas" have already been thought of by someone
> else. Keeping in mind that I might just be repeating what went before...

Hey, if we didn't all come up with some of the same ideas, we'd probably
never find anything to agree upon.

> It has occurred to me that there should be a way to break apart the
> functional blocks of Xastir, and perhaps some other programs, and build
> them anew so they work together. What I'm thinking of is:

It has been discussed, but no work done.  At least no public work.

>
> 1) A mapping program that knows how to display a map, icons, bitmaps,
> lines, polygons, filled areas, etc., that acts as a drawing agent for
> other programs. It receives its orders (perhaps via a socket?) from one
> or more separate programs that want to map something.

Or more likely it gives orders like 'give me "this" map from "that" database' 
and is given triggers like "Hey, the aprs tnc receive program just received 
a new map position for n7ipb-2" that it then acts on.

>
> 2) An APRS program that receives the data stream from RF (via TNC) and
> tells the mapping program what to draw.

An APRS program that receives the data and stores it in an SQL database then 
sends a trigger to sockets registered by other programs.  The trigger would 
indicate such things as 'I just received a position for kg4nbb-2" or "I have
a message for kg4nbb" or "a WX alert has just been stored".

>
> 3) An APRS program that receives the data stream from aprsd (via
> network) and tells the mapping program what to draw.

See the above,  it's no different than the RF case.

> 4) One or more weather programs that retrieve weather data from various
> places and tell the mapping program what to draw. (They could get
> textual data from NWS and/or NOAA, radar images (including grabbing a
> local image from a local TV station web page), etc.)

Could work the same as above, the programs get the data, store them in the DB
and then send a trigger to any program that needs it.  That program then is
free to ignore, or act upon the information.
 
> 5) A GPS interface that receives info from a local GPS device and tells
> the mapping program what to draw. (It would be nice if it could also

Two parts,  one can be as simple as the existing GPSD program.

> query the mapping program for objects within a certain box and display
> them as waypoints on the GPS receiver.)

This could be a seperate piece that understands a specific GPS and pulls the
data from the database and sends it to the GPS in the proper format.

...

> Getting back to the point made above, there could be more than one
> version of the mapping program. One for display on a computer screen,
> one to build an image for web display, one to build a WAP page, possibly
> even one that just filters the data in some way and passes it on to
> another version for drawing.

Yup, it makes all that stuff much much easier to do.  It's all been discussed
before.

>
> I would think a lot of the drawing code within Xastir could be used for
> the map drawing agent. And the APRS receiving code could likely provide
> the basis for programs 2 and 3 listed above (and maybe 5 as well).

Making an attempt at splitting the code apart has been on my todo for some
time now.  My problem is finding enough time away from other distractions to
sit down and understand the code well enough to know where to split.  I'm 
going to be at the International Kite Festival in Longbeach, WA next week and
I'm going to make one more attempt at it when my only distractions are flying
kites, and the usual beach distractions walking by. :-)  If you guys are lucky
it will rain all week and I'll get a lot done.

>
> The real key here is probably the protocol for the messages to and from
> the map drawing program. Unlike APRS, which is limited in size due to RF
> constraints, this would be a network-only protocol. It should be easy to
> generate, easy to parse, not limited or fixed in length. Keeping in mind
> the diverse types of display (screen, web, WAP), it should be kept at a
> fairly high level, letting the drawing program make interpretations on
> how to do the work. If multiple geographic datums are allowed, they
> should be specified in each message.

You've got it backwards, the drawing program should be asking for the data
it needs, not being told what to do.  That way the problem of display goes
away since presumably the display program will only ask for what it can
use.   It asks for maps, and objects to display.  It accepts triggers that 
it then is free to either use or ignore.

Data reception programs (gpsd, aprs tnc rx, aprs net rx, etc.)  should
probably just receive the data, add a header that identifies time,interface,
etc. and then should pass it on to the next level via a socket.  This header 
and packet form need to be described.

The next level would be a decode program that decodes the aprs data, formats
it and generates the SQL commands that store it in the database.  It also
would be responsible for generating triggers and sending them to other
programs via a socket connection.  The database structure needs to be
designed and the trigger formats defined.

Above that everything is optional, (and really only one reception program is 
needed).  Display programs would need to know where the database is, and
what host/socket to connect to for triggers.  Maps could come from either
local directories as we do now, or from a database or network connection.
Message handling programs would need the database and trigger connections
but could be completely independent of the display programs.

>
> One unanswered question (in my mind, anyway) is time. There needs to be
> some way to synchronize timing. Things like automatic expiry times for
> objects would be nice. It would also be nice to play back a loop of
> radar images, for example. Should all the other objects loop too? Each
> frame of the display should be time-consistent, right? But if the
> history of the APRS objects, for example, is stored within the APRS
> program, how would the mapping program tell it what time is being
> displayed? No anwer to that, yet.

All this can be left up to the display program.  When it retrieves an object 
from the DB it gets a timestamp for when that entry was created.  It can 
use that to expire objects.  

The same technique applies to maps and radar images.  Retrieve them, store 
them in the DB with a timestamp,  send a trigger.  The map program can 
display the map, or cycle thru the last xx maps or whatever it wants to do.


We can start by splitting Xastir up but still using our existing code for
object storage, display etc.  That helps define what data is needed by 
the various programs and lets us refine what would be needed in the 
way of triggers and database storage.  Then we can go from there.

And even tho I've concentrated on reception above, transmitting would be 
handled in a similar manner.

>
> Anyway, just my $0.02. Thanks for reading.

And my $0.02 as well.

Ken,  N7IPB