Class-based links and support for targets having the same name
aprs.fi has for a long time had serious problems when multiple tracking targets share the same name. There are an awful lot of AIS vessels having the same name, and those always had to be looked up by their MMSI. APRS stations (and objects and item names) could also overlap with the AIS vessels. I've now implemented proper searching functions to look up these stations and select the interesting ones from a list. To make it possible to link to these stations I've had to add a target class identifier in the links.
- a stands for APRS
- i stands for AIS
- http://aprs.fi/Aurora will search for all stations having the name Aurora, and show a list. Since the real-time map can show multiple targets at the same time, you can check many checkboxes and get a view tracking those stations.
- http://aprs.fi/a/Aurora jumps directly to the APRS station.
- http://aprs.fi/i/306784000 is a link to an AIS ship having the name Aurora.
If the station's name is unique, old links with no class identifier will continue to work as before: http://aprs.fi/OH7RDA
SSL for sensitive pages
The sign-up, password recovery, login and account pages are now protected by SSL/TLS (2048-bit RSA + up to 256-bit AES). This keeps your password safe from eavesdropping when you're using this site over an untrusted network. I believe the password safety to be on a good level now, since they're also stored in the database using an industry standard safe method (PBKDF2).
I used a free SSL certificate provider, and some more marginal or old browsers might complain about the certificate not being trusted. Sorry about that, please disregard the warning or use a browser which trusts StartSSL's certs.
Packet transmit rate advisor
This has been suggested by several users. The info page now calculates a median interval between packets transmitted. If the median falls below 25 seconds, the following advice is shown:
This station is transmitting packets at a high rate, which can cause congestion in the APRS network.
If the median falls below 13 seconds, the following advice is shown:
This station is transmitting packets at a very high rate, which causes serious congestion in the APRS network. This could be considered an abuse of the network resources.
Up to last 50 packets from a station are considered, but the backwards-going lookup stops at the first 1-hour gap between packets, the intention being to look at the last or current trip of a vehicle. The median is only calculated if there are at least 8 packets in the last trip. Because a median is used, this shouldn't trigger too easily from bursts generated by Smart Beaconing.
There are some ideas how to make this more meaningful. I've been thinking of an algorithm to calculate some sort of fuzzy "network loading" value by multiplying the packet rate by the amount of digipeater hops requested in the packets and using the result to trigger the nagging. This would allow a higher rate to be used with no digipeater path, but trigger more quickly when a 3-hop path is used. It would also handle proportional pathing by looking at the path of each packet separately.
I'm sure some people will be annoyed a bit by this and some rock-throwing might occur. Please be gentle and pick some smaller rocks first. The algorithm is new and it'll be revised. The intention is good – to provide advice in sensible tracker configuration.
Amount of persons on a ship shown when available
The most recent SVN versions of gnuais can receive and upload this information.
Some smaller fixes
- Cursor focus is moved to callsign input field when the real-time map is loaded
- Fixed lat/lng in XML export
- Better string translation moderation tool
- Google maps API is no longer loaded in translation tool
