[aprssig] Vicinity plotting

Tue Nov 22 15:16:27 EST 2011

Thanks for the advice re: all these issues I'm just discovering now. I think I'll make vicinity plotting optionally enableable but off by default, and stop reporting anything as distance-to-station for Coast-of-Africa points.

Also thanks for reminding me to do a load test with a wide-open stream from APRS-IS. I've only had a narrow pipe (50km radius filter) in my testing so far. 

Just out of curiosity, what missing fraction do you use for increased-ambiguity positions? Zero digits? Half-way across the span? Random digits like the spec says?

I'm trying to support stacked sites; the user can click on them and see all of the co-located stations and objects. I've seen stacks as high as 5 at one precise location (3 bands of D-star repeater, WX, and digi) in my immediate area. Still trying to decide whether I should sort particular types of stations to the top of the stack, or just leave it arbitrary.

Andrew Pavlin KA2DDO

Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: "Lynn W. Deffenbaugh (Mr)" <ldeffenb at homeside.to>
Date: Tue, 22 Nov 2011 19:27:50 
To: <aprssig at tapr.org>
Subject: Re: [aprssig] Vicinity plotting

APRSISCE/32 doesn't do vicinity plotting at all currently.  There is 
never, IMHO, a clearly located first digi.  I don't care if you see a 
packet that says "src>to,DIGI1,WIDE1*" that doesn't mean that DIGI1 was 
the first to see the packet.  There are devices out there (albeit few) 
that are beaconing a WIDE1-2 for their first path component and 
digipeaters that do callsign substitution instead of insertion.  Pair 
the two up, and you still have no idea where the station is nor what it 
might be close to.

And how do you handle a packet that you see that simply says 
"src>to,WIDE1*"?  It was obviously (possibly) digipeated by something, 
but what and where?

And then you have the packet "src>to,DIGI1,WIDE2*" which may or may not 
have been heard first by DIGI1, may have been a WIDE2-1 originally, or 
maybe a WIDE2-2, and where do you draw src if you haven't heard where 
DIGI1 even is?

Nope, after looking at how many chances there were to get it wrong, I 
decided to simply not place stations by inference.

And yes, I learned the hard way also that monitoring the local RF was 
wonderfully CLEAN as compared to what you see via APRS-IS.  And then I 
realized that everything that I saw via APRS-IS was actually local RF to 
someone that might be running my client, so I concluded that my client 
had to do reliable, reproducible, and explainable (above all) things 
regardless of what it was fed, so I opted for the 0,0 solution.  And it 
had to survive 24x7 operation against an APRS-IS full feed or I needed 
to fix it until it could survive the onslaught of concatenated, 
corrupted, delayed, and generally ugly packets.

Just wait until you get someone insisting that your new-kid-on-the-block 
APRS client "isn't showing my station in the right place" when in fact, 
they mean that his station appears in a different place on your client 
than on aprs.fi or jfindu.com or OpenAPRS and when you dig even deeper 
you find out that they've configured their Kenwood radio to beacon with 
10nm (yes, 10 MILE) ambiguity.  So, they're not transmitting their 
actual location and then they complain that different viewers put them 
in different places, all within 10 miles of where they actually are.

Yep, it's a thankless job, but I'm glad we've got brave souls out there 
to give hours and hours of work to let the rest of us complain about 
what's wrong with the results.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

On 11/22/2011 2:05 PM, Andrew P. wrote:
> Hmmm..... So, does APRS-IS/CE not do vicinity plotting at all, or only do it when there is a clearly located first digi? I'm currently implementing the second choice, and trying to decide what to do about the spurious error messages from the non-located digis. I do suspect part of my problem is the APRS-IS feed is bringing me relayed stations where the digis don't have WIDEn aliases in their position beacons, but the stations they relay do use WIDEn aliases. I don't have this issue nearly as much with an RF-only feed from a TNC and radio.
>
> Good thing there isn't a land mass at (0,0); they'd be swamped with traffic. ;-)
>
> Andrew Pavlin KA2DDO
> ------Original Message------
> From: Lynn W. Deffenbaugh (Mr)
> To: aprssig at tapr.org
> Sent: Nov 22, 2011 12:15 PM
> Subject: Re: [aprssig] Vicinity plotting
>
>
> Having struggled with the same thing myself, I finally decided that any
> station from which I have not received a position report will be located
> at 0,0 until I get a position report.  I examined many many paths before
> coming to the conclusion that there is NO good solution that will
> RELIABLY tell you where you should RANDOMLY position said station.  And
> cluttering the map with ambiguity circles or any other indication that
> the station really is NOT where you're drawing it was worse than just
> keeping the station off the map until a position was received.
>
> I would also recommend against any sort of automatic query of a station
> from which you think you need additional information.  Think of the
> traffic that would be generated when you successfully replace UI-View
> and 10,000 instances of your client (yes, it works via APRS-IS too, I
> assume) "decide" they need to know exactly where that event tracker
> actually IS and fire out the requests.  Not a pretty picture in my
> mind's eye.
>
> If you haven't heard where a station is, then my opinion is that the
> station might as well be invisible, but at least I draw them at 0,0 off
> the coast of Africa.
>
> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
>
> PS.  All that said, I am considering some better approaches having
> watched the real-time plots of packet paths in APRSISCE/32.  I may (or
> may not) implement some sort of user-option for "guessing" a position
> for a non-beaconing station...
>
> On 11/22/2011 11:30 AM, Andrew P. wrote:
>> Greetings, all.
>>
>> I've been trying to implement vicinity plotting of stations that don't send position reports, and I'm having a tough time of it. Many of them were originated over TCPIP, so they never had an initial digipeater to use for vicinity plotting. Others digipeated over a path without tracing, so their path only reports the WIDEn aliases. Yet others had an initial digipeater, but I never got a position report from the digi itself to use for vicinity plotting.
>>
>> So how should I handle these? Right now, they are being plotted off the coast of Africa at lat/lon 0,0. Should I be querying the invisible digis as to their position? That would at least help with some, but that would cause more spurious radio traffic.
>>
>> Thanks in advance.
>>
>> Andrew Pavlin KA2DDO
>> Sent from my Verizon Wireless BlackBerry
>>
>>
>> _______________________________________________
>> aprssig mailing list
>> aprssig at tapr.org
>> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>
>
> Sent from my Verizon Wireless BlackBerry
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>

_______________________________________________
aprssig mailing list
aprssig at tapr.org
https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig