[aprssig] Vicinity plotting

[Lynn W. Deffenbaugh (Mr)]

On 11/22/2011 3:16 PM, Andrew P. wrote:
> 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.

At least 0,0 is an easily recognizable point!  Although for a while, 
someone in OpenStreetMaps had the "North Pole" located at 0,0!

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

Bob doesn't agree with the way I do it, but I render it 1/2 across the 
ambiguous position, draw a tight purple circle around the symbol to 
indicate that something is strange here, and (if enabled by the user) 
draw a large circle at the ambiguity distance.  And if you watch a 
mobile ambiguous station (I have a view filter to show ONLY ambiguous 
stations, they're fun to watch) overlayed on a street map, you can 
pretty much pinpoint where they are.  No security there.  And, IMHO, 
ambiguity isn't security for a repeater position either because once you 
get within the ambiguous distance, you can probably spot the tower 
(unless it's been stealthed).

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

I developed an algorithm to shuffle the callsign labels around a stack 
when I realized that every station is the world is potentially on a 
single stack if you zoom out far enough.  So, I don't bother sorting 
other than alpha order by callsign which is the order of my internal 
station list for binary search reasons.  I just loop the list and draw 
the stations, so the higher alpha-sort callsign ends up on "top", but 
IMHO, that's as good as any other.  Just zoom over to KJ4ERJ-1 and 
you'll have a bigger stack (10) to test with!  (a b/KJ4ERJ* filter will 
get you most of them).

And at "normal" (non tight) zoom levels, Dayton will give you a really 
big stack!

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

PS. Since you're targeting java with your client, can we expect it to 
run on a BlackBerry?

>
> 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
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>