| |
ZL3AI > APRDIG 05.03.04 13:08l 254 Lines 9656 Bytes #999 (0) @ WW
BID : 2949-ZL3AI
Read: GUEST
Subj: TAPR Digest, Mar 03, 3/7
Path: DB0FHN<DB0FOR<DB0SIF<DB0EA<DB0RES<ON0AR<ON0AR<F6KMO<EA5DVS<EA5RQ<
VK7AX<ZL2BAU<ZL2BAU<ZL3VML
Sent: 040305/1020Z @:ZL3VML.#80.NZL.OC #:20396 [Chch-NZ] FBB7.00i $:2949-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: APRS in Mexico
From: "Donald Jacob" <djacob1@socal.rr.com>
Date: Wed, 3 Mar 2004 09:40:14 -0800
X-Message-Number: 23
Is there any APRS activity in Mexico, Baja and the West Coast of the
mainland. If so, what frequency is it on
Thanks
Don WB5EKU
DM04sg
IRLP Node 3830
----------------------------------------------------------------------
Subject: Re: NWS Radar trouble
From: Jeff King <jeff@aerodata.net>
Date: Wed, 3 Mar 2004 12:53:27 -0500
X-Message-Number: 24
On Wed, 3 Mar 2004 09:31:41 -0600, James Jefferson wrote:
>>Maybe, just maybe, there is a secret conspiracy to get rid of
>>Freebie type of services,
....
>>Do we unnecessarily bombard these sites just because we can?
....
>YES!
....
>From a systems standpoint if I wanted to reduce the amount of maps
>requested I would do the following:
>1) turn off auto refreshing and makes that a button or checkbox to
>enable. or
>1) only automatically refresh pages that have something moving on them.
>2) request only one map and one scale and let the user zoom if
>they want more.
In other words, you'd not really change the system much, other then letting
the user decide if they want to be a bandwidth hog, as opposed to that being
the default?
Makes sense to me.
----------------------------------------------------------------------
Subject: Re: NWS Radar trouble
From: Steve Dimse <k4hg@tapr.org>
Date: Wed, 3 Mar 2004 12:54:06 -0500
X-Message-Number: 25
On 3/3/04 at 9:31 AM James Jefferson <jj@aprsworld.net> sent:
>>Maybe, just maybe, there is a secret conspiracy to get rid of Freebie
>>type of services, such as APRS's users. 8 million hits a month to FINDU,
>>let alone the millions of non aprs hits at these Radar and Map sites
>>receive since the onslaught of Cable modems and always connected operation.
>
>Since 29 Feb I've gotten 240,214 hits from findu. So basically three days.
>Multiply that by 10 and it is a little over 2.4 million hits a month.
That's about right. findu had a slow month in February with the short
month, server move (two days of logs were lost), and mapping troubles, only
5.9 million hits, January was 7.2 million.
>>From a systems standpoint if I wanted to reduce the ammount of maps requested
>by findu I would do the following:
>1) turn off auto refreshing and makes that a button or checkbox to enable.
>or
Refresh was added very early on during findU's development at user's
request, my perception is my users want this.
>1) only automatically refresh pages that have something moving on them.
The problem here is one of forward prediction. Just because something
hasn't moved doesn't mean it won't move. People don't open a location page
and leave it up if it is a house, people select a page because they expect
it to move.
Granted, it would be nice to have a system that only updated when the object
moved, as soon as it moved. The web infrastructure does not allow that now.
I also think you may be over-estimating the impact of refresh. My web log
analysis program defines a visit as all hits occuring from the same IP with
no gaps greater than 5 minutes. For example, if I loaded my main page
(which doesn;t auto-refresh, and hit reload 6 minutess later, that would be
two visits, but hitting refresh after 4 minutes is considered the same
visit (and starts the 5 minute timer over). Since the auto-refresh is three
minutes, those all count as single visits.
In Feb, there were 279,887 visits producing 5,779,710 hits, or 20.65
hits/visit. Taking into account pages like near, that load a bunch of icons
and can generate 30 hits all by themselves, and wxpage.cgi, that generates
6 hits per page (main page, 4 graphs, and the radar plot), the average user
is not leaving a page auto-refreshing for long.
Without auto-refresh, people would probably be hitting refresh more often
than every three minutes, map usage might even go up.
>2) request only one map and one scale and let the user zoom if they want more.
At one point early in findU's development I tried doing this, it lasted
less than a day, the feedback was universally negative.
Some people have noticed the new map.cgi on the APRS Map Manager, which can
handle dos, pocket, geo, and toporama maps automatically. The idea here is
to provide a single map interface for those that want it, most likely I'll
activate this through clicking a static map image, at that point anyone
that want this sort of thing will be able to have it, but my expectation is
most of my users will stick with the current system.
Steve K4HG
----------------------------------------------------------------------
Subject: Re: NWS Radar trouble
From: "Tyler Allison" <tyler@allisonhouse.com>
Date: Wed, 3 Mar 2004 12:54:27 -0500 (EST)
X-Message-Number: 26
>On 3/3/04 at 11:34 AM Tyler Allison <tyler@allisonhouse.com> sent:
>
>>>This won't necessarily give you a single radar site, but a good mosaic
>>>of the ones in a region.
>>
>>Since Gerry is willing to do the mosaics (the hard part) I can provide
>>individual radar sites to the APRS community if there is an interest.
>>
>>I actually have them available on the internet already with a sorta
>>hidden
>>URL. Im just not sure I want to run the risk of a $1000+ bandwidth bill
>>if
>>some APRS user hits refresh on his GUI every 5 seconds.
>>
>I have no bandwidth bill, and I could host them on my server if one of you
>feeds
>them to me.
Gerry can hook you up with a live NEXRAD feed, I assume ;), that will give
you the ability to build the individual radar locations as they hit your
server. You wont need to go out to the NWS to grab them. It does involve
installing some seriously wack'd software but once it is setup it works.
If that doesn't work out for any number of reasons I can provide the
graphics via an rsync or something.
-Tyler
----------------------------------------------------------------------
Subject: Re: NWS Radar trouble
From: Jeff King <jeff@aerodata.net>
Date: Wed, 3 Mar 2004 13:53:10 -0500
X-Message-Number: 27
>>>From a systems standpoint if I wanted to reduce the amount of
>>>maps requested
>>I would do the following: 1) turn off auto refreshing and
>>makes that a button or checkbox to enable. or
>Refresh was added very early on during development at user's
>request, my perception is my users want this.
That is what "checkbox" means. The user "checks" the box if they want
refresh. The idea, by default, is to give the user a minimal set of features,
and only give them the richer bandwidth hog features if the user so desires.
So your not taking anything away for the user, your just making it a pull
operation instead of a push operation, so to speak.
The basic premise here is good manners.... if someone is giving you something
for free, you only use what you need, and don't fill a grocery bag at the all
you can eat buffet. You pick only what you can eat at that particular
sitting.
In any case, making it a user checkbox/switch will reduce the bandwidth load,
and those that still need it, can enable it. No brainer.
----------------------------------------------------------------------
Subject: Re: NWS Radar trouble
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Wed, 03 Mar 2004 14:09:10 -0500
X-Message-Number: 28
>>>James Jefferson said: ...to reduce the amount of maps
>requested by findu he would:
>
>1) turn off auto refresh and make it a button or checkbox [OR]
>1) only automatically refresh pages that have something moving on
them.
Or do like APRSdos does. Leave the map alone. And just refresh the
Symbols (icons) that are new or have moved. This is why APRS has a COLOR
specified for OLD symbols. It OVERWRITES the old position with the deep
blue color and then adds the NEW position to the map in the normal new
color.
Thus, the OLD symbols (in deeep blue) are like a track history and only the
LATEST position is shown in normal color. At any time the observer wants
to clean up the map and get rid of all the old tracks, then he requests a
new map.
This way, I never have to refresh maps except on specific request, and for
free I get very obvious track histories..
The routine is trivial. For every new posit, compare it to the old. If
changed, then plot (overlay) the OLD with the special "old" color and then
plot (and save) the new posit.
Just for what it's worth..
Bob
----------------------------------------------------------------------
Subject: Re: NWS Radar trouble
From: "James Jefferson" <jj@aprsworld.net>
Date: Wed, 3 Mar 2004 13:20:00 -0600 (CST)
X-Message-Number: 29
>Or do like APRSdos does. Leave the map alone. And just
This really isn't possible on the internet. Overlaying images on top of
other images is quite difficult to impossible on the client side. The
main problem is that "pushing" isn't possible on the web.
----------------------------------------------------------------------
Subject: Re: NWS Radar trouble
From: "Scott Miller" <scott@opentrac.org>
Date: Wed, 3 Mar 2004 11:24:35 -0800
X-Message-Number: 30
>Or do like APRSdos does. Leave the map alone. And just
>refresh the Symbols (icons) that are new or have moved. This
>is why APRS has a COLOR specified for OLD symbols.
>It OVERWRITES the old position with the deep blue color
>and then adds the NEW position to the map in the normal
>new color.
I think the point is that a web browser can't do that. It retrieves a map
and has no way to know when something's changed unless it connects again and
checks. Not without adding some client-side scripting, at least.
Scott
N1VG
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
