[aprssig] Open Source Parser

Thu Jun 21 17:29:22 EDT 2007

My Comments on Parsers... To whom it may concern:

There have been some implementations of APRS that have not met
the original intent of APRS in several areas, and it maybe
because of the way the SPEC was written.  But the INTENT of APRS
in these areas are as follows:

1) APRS OBJECTS:

APRS OBJECTS are not supposed to be treated any differently than
any other APRS station packet.  The only thing that makes an
OBJECT an "OBJECT" is that it does not have a TNC and so it
cannot send its own position report. 

Therfore, we came up with the OBJECT format so that another
station can send an OBJECT as a way of sending the position
report from some other station or object that cannot sent it
himself.   What this means, is that an OBJECT can contain ANY
OTHER POSSIBLE APRS POSITION information.

The way an object should be parsed is:
1) Parse out the OBJECT_NAME
2) Take all of the packet after the * and...
3) Recurse that packet data as if it was an "@" format position
4) Giving it the callsign of OBJECT_NAME
5) But notice that OBJECT_NAME can be mixed case and can even
have punctuation in it.
6) Keep a flag bit that it was originally an object and also
keep the callsign of the station posting it.
7) Any future OBJECT or STATION POSITION of the same name will
overwrite and replace it

2) THIRD PARTY FORMAT

The second bigggest mistake of most clients is to assume that
3rd party packets only come from Igates and therefore that "3rd
party" can be used as an internet looping filter.

THIS IS NOT THE INTENT OF APRS 3rd PARTY FORMAT.

The Igate loop filter should look for the "TCPIP" in the path of
a 3rd party packet before filtering out that packet from future
Igating.

There are many other applications of 3rd party packets, and it
is unfortunate that too many clients use the short-cut of
ignoring all on-air 3rd party packets when in fact, the only
ones that should be filtered from the Igate stream are the ones
with TCPIP in the path.

3) APRS ADDENDUM 1.1

Finally be sure to implement all of the updates included in the
APRS 1.1 addendum
http://www.ew.usna.edu/~bruninga/aprs/aprs11.html  and please
consider implementing all of the proposals in the APRS 1.2
addendum proposals.

Good Luck.

We need NEW parsers, and New clients that implement ALL of APRS,
not just the simplistic vehicle tracking and plotting.  APRS is
much more, but too many clients took the short cut to maps and
vehicle plotting and have left too much out of their
implementations.  We need to get APRS back on track.  If you are
implementing new software, contact me for additional comments of
errors I see in many applications.

Bob, WB4APR

> -----Original Message-----
> From: aprssig-bounces at lists.tapr.org 
> [mailto:aprssig-bounces at lists.tapr.org] On Behalf Of James 
> Jefferson Jarvis
> Sent: Thursday, June 21, 2007 2:18 PM
> To: TAPR APRS Mailing List
> Subject: Re: [aprssig] Open Source Parser
> 
> It's definitely there. I wrote most of it. I posted it. And
the 
> db.aprsworld.net and db2.aprsworld.net use the code from 
> there. It is in 
> the CVS tree. You'll have to follow the CVS instructions or 
> download a 
> nightly tarball. There is no "release" version.
> 
> The parser in the CVS will read from network or stdin.
> 
> Thanks,
> 
> -Jim KB0THN
> 
> Tom Hayward wrote:
> 
> > I don't think the actual APRS World parser is on
Sourceforge. I
> > downloaded what's there and it parses data from a database,
not text
> > APRS packets.
> >
> > However, I did a search for APRS and found lots of things 
> that could 
> > be helpful:
> >
http://sourceforge.net/search/?type_of_search=soft&words=aprs
> > The C++ library looks particularly enticing.
> >
> > Tom KD7LXL
> >
> > On 6/21/07, James Jefferson Jarvis <jj at aprsworld.net> wrote:
> >
> >> aprsworld.net's parser is available on sourceforge.net.
Search for
> >> aprsworld. It's written in C. It's designed to shoot the 
> parsed data to
> >> a MySQL database, PostGIS database, or flat files. It 
> would be pretty
> >> trivial to write another backend.
> >>
> >> But nobody has a "validated" parser. APRS is too complex, 
> too loosely
> >> defined, and too poorly engineered to have anything better 
> than a good
> >> approximation.
> >>
> >> I always use Ian's perl aprsdec.pl program as my gold 
> reference. Ian
> >> edited the APRS spec years ago.
> >>
> >> -Jim KB0THN
> >>
> >> M J wrote:
> >>
> >> >Hello!
> >> >Can anyone point me to an open source, 
> already-in-existence parser 
> >> that has been validated against the APRS protocol?  I am
thinking 
> >> about writing a software product to simply display APRS 
> >> Internet-stream data (but not inject any data into the
stream) and 
> >> would prefer to not try to digest the entire protocol 
> document if I 
> >> don't have to.  Thanks!  -MJ
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> 
> >_____________________________________________________________
> _______________________ 
> >>
> >> >Be a PS3 game guru.
> >> >Get your game face on with the latest PS3 news and
previews at 
> >> Yahoo! Games.
> >> >http://videogames.yahoo.com/platform?platform=120121
> >> >
> >> >_______________________________________________
> >> >aprssig mailing list
> >> >aprssig at lists.tapr.org
> >> >https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
> >> >
> >> >
> >>
> >>
> >> _______________________________________________
> >> aprssig mailing list
> >> aprssig at lists.tapr.org
> >> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
> >>
> >
> > _______________________________________________
> > aprssig mailing list
> > aprssig at lists.tapr.org
> > https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
> 
> 
> 
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
> 