[Xastir] Question/suggestion

[Gerry Creager N5JXS]

Sorry for the delays.  I'm on the go a good bit and don't get to spend 
much time with either e-mail or ham radio these days!

A couple of things come to mind. And, Gerry, these are not criticisms. 
The more folks we can incorporate in the process of defining what we 
need and suggestions on implementation strategies, the better the result.

First a couple of points of philosophy.
1.  Xastir is evolving rapidly toward a formal GIS package that has 
specialty application associated with APRS
2.  A GIS program is little more, in the long run, than a good database 
for spatial data and pictures.

If we think along those lines, segregating the core operating elements 
of xastir and restructuring them into a more modular... or another 
monolithic... app is going to enable us to make some sweeping changes.

Gerry Wheeler KG4NBB wrote:
> 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...

But hearing them expressed again, or by someone different, or in a 
different manner, helps in the clarification process most of the time.

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

Yes, but do we want (n) smaller programs effecting a distributed 
processing approach, or a monolith with modules that can be enabled or 
disabled without adversely affecting the others?  After all, some 
elements, such as the database, will always have to be running.  Do we 
want to incorporate jdbc into the monolith or use PostGIS instead, as a 
separate backend?


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

0)  A database to allow rapid searching of mapfiles, enabling faster map 
draws.  The database may reference existing shapefiles, or may 
incorporate within its schema the map data completely.


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

OOH!  I like it!  Someone's going to seed a bunch of wireless AP's on 
Curt's mountains? :-)  Not really making fun, but being involved in a 
grand plan to distribute, and then try to secure, a bunch of AP's in the 
boonies, on tall towers, is not a thrilling thought!

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

James, where are you?  We have an expert on web mapping.  In fact, I'd 
wished I coulda enticed him to leave the frozen north and come study in 
the balmy State of Texas!

The mapping element is a candidate for stand-alone.  It is not, however, 
dependent on another element "telling" it when to draw.  Instead, it 
needs to know to go looking for updates periodically, and not 
infrequently, and redraw the changes.  If that involves a view change, 
it's pretty massive.  If we've moved icons around on the "mobiles" 
layer, then, that's pretty easy.

And,I'd like to promote the idea of layers that are autonomous.  I've 
got static mapping layers, eg, transportation, hydrology, contours, 
airports, airways, etc., that don't change.  They could each occupy 
their own layer, and only get redrawn when the view (pan/zoom/centroid) 
changes, while a layer for weather, another for mobiles, another for 
digi's, another for fixed stations, is updated frequently, and redrawn 
if necessary.  We can probably identify some layers as fixed, and some 
as dynamic, but if all we're looking for is delta, and then redraw if 
there IS a delta, then the effectively static layers and some of the 
less dynamic volatile layers, are infrequently updated.


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

Not without incorporating some major changes to improve map selection 
and speed inherent thereto.  That needs to happen sooner rather than 
later, too.  As we start downloading ESRI's Tigerfiles for local disk 
access, the 5 minute wait on updates for Texas on a redraw is becoming 
an obvious bottleneck.

I believe we need to incorporate PostGIS (now, rather than later) as a 
default database system, and use it for map indexing.  It'd incorporate 
map extents, and map filename, and an SQL query could readily pull up 
the files needed for a map draw/redraw.

I recommend PostGres/PostGIS because it's already spatially enabled, and 
we'd not have to incorporate, say, MySQL now and Oracle19x later...


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

<soapbox> Regardless of your datasources, I think we need to all be 
concentrating on the concept of normalizing geodetic datum reference to 
an objective system.  Help stamp out NAD27/NGVD29 datums in our 
lifetime.  Support NAD83/NAVD88 objective datums.

And don't think the transformation, because we have 100 lines of C code 
to perform a 7-parameter transformation, is going to make a 
subjective-datum coordinate into an objectie-datum coordinate.  The 
error budget and uncertainty should be posted whenever someone blindly 
transforms from NAD27 to NAD83.
</soapbox>


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

Ooh!  Aah!  An APRS-Spec issue.  In fact, objects like radar, if we were 
to generate  a server from an appropriate source, such as IDD/LDM 
(www.ucar.edu) would allow time-tagged data for such a purpose.  Getting 
it off a TV station website is cute, it may be art, but 
<pedantic-academic> isn't technically a good 
approach</pedantic-academic>.  YMMV

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

And a good read it was.

Thanks!

73, gerry n5jxs