[Xastir-dev] xastir as pvd

[Owen DeLong]

>> > A couple of questions come to mind... This sounds like a perfect
>> > fit with the internet APRS formats,
>
> But we're back to the symbology thing.  Those little icons in
> the APRS table just don't seem accurate enough for headings,
> even if rotated.
>
Perhaps.... Perhaps we can actually fix that another way...

> much easier.  There would be no connection setup or keep-alive
> tcp baggage,
> xastir would just listen to a UDP port and display anything
> received on it.
>
OK... I think RADIO->APRSD<-XASTIR is probably the way to go, then,
as suggested by someone in an earlier message.  APRSD can do the UDP->
TCP transition for you and gives you some other features along the way.
It's already written, and you could just connect XASTIR to localhost:APRSD
and have APRSD work via UDP with your radio locally or wherever.  As the
other guy pointed out, it even allows for multiple radios.

>> > I think you can do it with minimal additional code in XASTIR.
>
> I hope so!
>
Yep... I think we're there.

>> > I think if you can do TCP and pretend to be an internet APRS feed, you
>> > then only need to add functionality we already want in XASTIR, but
>> > haven't had time to implement:
>> >
>> >       Symbol Rotation
>> >       Alternate Symbol Library
>> >       Over-the-air Symbol definition
>
> Have I just volunteered for those???
>
Depends on how bad you want them.  If you do them, then you get to know
when they end up in the package.  If you don't, then, it gets there when
it gets there.  Lots of us have said these things would be nice to have,
but, nobody has thought it was more important than other things they were
working on yet.

>> Do you need high accuracy, or is DD MM.MM format enough?
>
> High accuracy.  I would want to show the difference in having
> WAAS and not having it.
>
NP, then, but, you'll have to plan on implementing compressed format APRS
packets instead of NMEA+headers.

>> The alternate symbol library is the biggie.  This would benefit
>> everybody if we did it correctly.  If it's done quickly, without
>> much thought, it might not benefit anybody.
>
> Well, given that, I suppose we should do it correctly(!).
>
Agreed.

>> Do you absolutely need additional symbols at this point, or are the
>> small/large aircraft and the helo symbols that we currently have
>> adequate, if they can be rotated in finer increments?
>
> I would really desire finer symbols, if that fit into the xastir
> framework nicely.  Having a dynamic symbol may allow for items
> such
> as projected heading/speed barb in front of the symbol.
>
Actually, if we live with the existing symbols and add to the desired
feature list:

	Ability to plot course/speed barbs on moving objects

(could probably steal this from the existing WX wind barb code for the
most part, and, I'm assuming that the direction of a stationairy aircraft
isn't particularly important)

Then, I think that might suffice.

However, you're the judge of what you need.

Owen