Date range with weather and telemetry lookup

I'm on a 2-week sick leave (my gallbladder was removed last week), and have some spare time for enhancements and bug fixes. Rest of the time I'm entertaining Armi the cat, who joined us on Friday.

This morning I added arbitrary date range lookups to the weather and telemetry pages. It allows you to look up a detailed graph between any two dates or times. It also has a little calendar widget for your convenience.

I've also done some XHTML validity fixes for better browser compatibility, switched to a smaller position marker on the static maps, and added some navigation links in the bottom of most pages. I also fixed the bug of date selection menu not appearing when clicking on 'start tracking' on the live map.

Also, the /info/ page of a weather station now shows a brief 'latest weather' report instead of the number of weather reports in database. It's probably much more interesting, and it's much quicker to load, too, since it's almost always cached in memory and doesn't require a potentially large disk read.

Google Maps loading problem fixed

Google released Google Maps API version 2.151 today, which somehow broke map loading for many users (including myself). I received a number of complaints that the map doesn't load. The Firefox error console gave the error "window.jstiming is undefined".

I've now manually downgraded to Google Maps API version 2.150 which seems to work better.

Sorry for the trouble, and thank you for your patience!

Some database cleanups

Since the popularity of the site is increasing I need to do some optimizations to keep the site running smoothly.

As announced before, I ran some database restructuring batch jobs during the weekend. The last one was actually started on Monday morning and the execution was completed early Tuesday morning. I hope the slowdowns were not too noticeable, I tried to make them run slowly enough to not interfere with normal use.

I'm currently looking at ways to clean up some unused data from the aprs.fi database. There's quite a lot of automatically or erroneously generated targets stored in the database, most of which are not really looked at by anyone. They just inflate my tables and make the prefix browsing view very cluttered. The performance impact caused by the extra targets isn't really noticeable, but it's just not very nice to have them there.

If you're keeping an eye on the statistics, you might have noticed that today I deleted about 60000 targets. Those were all APRS objects, which had only a single point stored (non-moving), which were last announced over a week ago, and which were announced for less than 12 hours. Almost all of them were automatically generated earthquake and severe weather warning objects, which don't really need to be here any more.

There's also an awful lot of regular APRS targets which have a corrupted source callsign. Most usually one or two characters have been lost from the beginning of the callsign. For example: 1VAJ (J41VAJ), 3GXT-2 (W3GXT-2) and 3TVX-9 (VE3TVX-9). You can find these by looking at the prefix browsing view, picking a strange prefix starting with a number, and looking up the correct original call in the "nearby stations" list of the info page. I wonder how the callsigns get mangled like this, and how could I remove these from the database without accidentally removing some valid data.

Slowdowns caused by maintenance work

I'm doing some changes in the database structures during this Friday evening and Saturday morning, so there might be some slowdowns in the aprs.fi service. In particular, updated data might take a few minutes to be inserted in the database. No data should be lost, though, it'll just be delayed. Thank you for your patience!

APRS in русский язык

Thanks to UZ2HZ, RA1AMW, UA3IRS and UR7IMM, aprs.fi is now available in the Russian language! The site has now been translated to 20 languages. Although there's not so much APRS activity in Russia yet, Russian is the primary language of about 164 million people living in quite a few countries. Even here in Helsinki, it's the third most common language.

There are spots of APRS coverage in (at least) St. Petersburg, Moscow and Novgorod.

Single-target APRS packet paths

The APRS packet path plotting now works while tracking a single target. As a natural side-effect, all of the stations used as digipeaters and igates by the tracked target will also be shown on the map.

On Saturday I also made some significant changes in the backend code, which should make it scale out a bit better. I added some more in-memory caching which should speed things up so that the addition of things like APRS packet paths will not cause a significant performance hit.

"First heard" algorithm fix, and APRS-IS server failover

I've just fixed the "first heard by" algorithm to mark the igate as the first receiving station, when an intact WIDE1-1,WIDE2-1 path is seen. It was incorrectly guessing that the packet might have been digipeated because there is a WIDE2-1 in there, but the untouched WIDE1-1 clearly says that the packet has not been digipeated yet.

I've also added support for failing over to secondary APRS-IS servers automatically, so now I don't have to do anything manually if my own APRS-IS server fails (or is taken down for maintenance). This should prevent today's outage from happening again.