[Xastir] Question/suggestion

[Gerry Wheeler KG4NBB]

On Tue, 2002-08-13 at 17:20, Curt Mills, WE7U wrote:
> On Tue, 13 Aug 2002, Jack Twilley wrote:
> 
> > It would be very reasonable to write a Java plugin to interface with the
> > as-yet-unwritten future Xastir's backend.
> >
> > Another very useful frontend would be for WAP devices -- making my
> > cell phone look like my TH-D7A's display would be Very Keen.
> 
> The difference between fantasy and reality in this case is someone's
> drive to write a few hundred or few thousand lines of code.

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...

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:

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.

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

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

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.)

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
query the mapping program for objects within a certain box and display
them as waypoints on the GPS receiver.)

6) A weather station program to display local weather. Maybe an
interface to a Boltek lightning detector could be written.

You get the point. A user could turn on or off whichever features were
desired by running or not running the appropriate program. New data
sources could be created when needed. The drawing program and the other
programs need not be on the same computer. A data stream splitter could
be used to send the collected data to more than one map drawing program.
Display frames could be captured and sent to a remote display. (Curt,
while you're out on SAR you could use a wireless WAN to receive position
updates and display them on your PDA.)

The mapping program might need to support multiple drawing layers, so
weather radar images, for example, don't cover up APRS stations and
tracks. The layer assignments should be configurable at run time, not
hard-coded in the programs. (It's not clear whether this is a mapping
configuration, or done in the program supplying the data. Perhaps the
supply program refers to the layer by some logical name, and the mapping
program configuration places that layer with respect to the others.)

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.

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).

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.

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.

Anyway, just my $0.02. Thanks for reading.
-- 
Gerry Wheeler KG4NBB
kg4nbb at arrl.net
N26.28318  W081.75755