[aprssig] Default find.cgi scale

[Steve Dimse]

On 11/15/04 at 9:09 AM Scott Miller <scott at opentrac.org> sent:

>One thing worth considering might be running Squid as a reverse proxy.  (See
>http://www.ngogeeks.com/node/view/272).  Though as far as the FindU -
>aprsworld link goes, it'd probably make more sense to set up a squid server
>on the FindU end, to transparently cache maps and save server load and
>bandwidth on aprsworld and any other map sources.
>
Jim caches the maps on his end, so this would mostly just save the bandwidth
between our two servers, which is not an issue of concern. 

If you read my findU project ideas, number 5 was map caching...however to be
really effective this needs to be done in a way different than squid. Imagine a
state-wide map, say 10 pixels to the mile. I call the map once to draw a
station, which then moves a mile down the road and the map needs to be redrawn.
There is no reason the first map cannot be reused, the station might be 10
pixels off center, but who cares? As long as the geo file is saved with the map
image, the icon will be drawn in the correct place. The squid proxy would
require the server produce a new map, which is needlessly wasteful. My plan is
to be able to specify a "slop factor", how much off center a map can be and
still be acceptible...because there are times, for example drawing an animated
GIF, where the requested point must be in the center.

I have always cached the NWS radar images for three minutes in order to limit
the load on NWS web servers, and the new TerraServer code also uses caching (in
the 36 hours since I announced the service, only 3624 of the tiles have been
requested from TerraServer, taking up only 34 MB of space on findU. At this rate
it ought to be a month or more until I need to start flushing the buffer. The
terra.cgi has been hit 3132 times (each time needing 9 tiles) so the cache
system is decreasing the load on TerraServer by a factor of about 8. This should
improve over time as the cache on findU gets larger.

Steve K4HG