On Thu, 1 Mar 2012, Libor Augustin wrote:

The last mentioned, the Lighting Detection&Reporting system is the main issue as i have the
informations from Honza.
Every new lighting strike reported by the system is expressed by the new object, the object name is
composed of current date and time, ie. STR260946 (name prefix,day,hour,minute). Because of that naming,
there is thousands of individual, short lived objects that are stored in database now. Correct me here
if iam wrong.

That's right.

1. we keep the current naming and include the special tag at the end of the object comment. This tag
will tells your system to not store such objects to prevent the overloading or save just for a few
hours to display it. The tag will be something which we decide together, something you prefer to be and
something you can then remove from the actual comment to not display it in the station informations
(same as PHG or DAO).

I get quite a lot of requests for special features needed by individual users or small groups of users worldwide. Unfortunately I do not have enough time to do everything, so I try to concentrate implementing things which benefit large groups of users (on global scale!) so that the time is well spent and benefits as many users as possible. So, I won't do some special tag hack only for you guys - it would need to be a real APRS standard extension which everyone can implement and utilize for other general use cases. It would need to be discussed on the APRSSIG with other implementors.

2. another idea is to removing any APRS object which transmitted just and only ONE beacon in a life
after defined duration. Lets say 24 hours or several days (week?). In this case, ANY object or station
in a world, will not be stored if some of the following examples comes true:
- station accidentaly transmitted beacon (weird saying but could happen)
- short lived objects like the lighting strikes
- there is a beacon, which is not real station and this could happen, when some TNCs are faulty or
accidentaly decode the packet in a wrong way. The example is here: http://aprs.fi/?call=a%2FCZ3-3. Ii
is a non existing station, the real station at this QTH is http://aprs.fi/?call=a%2FOK0BCA-1&_s=mb.
CZ3-3 is state routing path (SSn-N).
- there might be even more examples ...
The second idea is more complex solution, not requiring user's attention and everything happens
automaticaly.

Good idea! aprs.fi already does exactly this (has been doing for a couple years), but it isn't effective enough - a lot of crap comes in more than once, including the lightning strikes. Many APRS packet corruptions are systematic - your example has had 12 different positions stored in the database over time (see http://aprs.fi/info/a/CZ3-3). For the strikes: "STR260946 (name prefix,day,hour,minute)" - a proper thunderstorm will have multiple strikes per minute at different locations, making the object jump around. And there are thunderstorms around the world all the time, making such naming scheme fall over quickly.

aprs.fi, or the APRS-IS in general, does not have a design which would really support worldwide lightning strike information distribution. With some hacks like (1) you might be able to do it for your country, but if a few others would try to do it at the same time, it would break. I would not like to see one object generator doing something that others shouldn't take an example of.

3.

I would recommend you to push lightning information to a network designed to transmit it (I think www.blitzortung.org is a popular distributed lightning receiver network), and keep it there. With some nice KML overlay magic we can then render the information on top of the aprs.fi map without actually polluting the APRS-IS or aprs.fi's database. Here's how you can tell aprs.fi to load a kml file, residing on another web server, on top of the map:

http://aprs.fi/?lat=38.8720&lng=-77.0570&z=15&kml=http%3A%2F%2Fhe.fi%2Fmisc%2Fpentagon.kml

If the lightning data is presented in KML somewhere, I could support a feature to have things like that conveniently listed in the "Overlays" drop-down menu in the top right corner of the real-time map. The 'Weather' item there from NOAA isn't good, some better items would be welcome.