Rozhodli jsme se s Honzou opet o kontaktovani Hessu a pokusit se nejak vyresit zobrazovani objektu na aprs.fi
Zde je jeho odpoved:
Code: Select all
Hi,
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.
- Hessu
Z cehoz plyne, ze neni naklonen nejake "individualni" praci a implementaci systemu na vyrazeni nekterych stanic, nebo objektu pomoci nejakeho specialniho oznaceni v textu.
Tudiz od nej zrejme zadne reseni cekat nemuzeme a musime si pomoct nejak sami.
Proto vyvstava otazka co s tim.
Nabizi se jedno reseni, ktere lze pojmout dvemi zpusoby.
- Vysilat blesky i nadale pod znackou OK1COM-10 a vyuzit tak stavajiciho filtru na strane aprs.fi. Tim umoznime i nadale jejich vysilani na RF, avsak nebudou zobrazovany na aprs.fi. A dale presunuti istatnich objektu (METAR, CHMI, TA, SPA ...) na jinou znacku, respektive jine SSID. Toto reseni bude vyzadovat upravu nastaveni igate tak, aby vysilaly objekty z jine znacky (SSID).
- Ponechat vysilani objektu pod OK1COM-10 a presunout blesky na jinou znacku (SSID). V tomto pripade budeme muset Hessu pozadat o nastaveni filtru na novou znacku kde budou nove jen blesky a odstraneni filtru pro OK1COM-10 tak, aby se ostatni objekty (METAR, CHMI, TA, SPA ...) zacaly zobrazovat. Toto reseni bude opet vyzadovat upravu nastaveni igate tak, aby vysilaly blesky z nove znacky (SSID).
Myslim ze Honza se ktomu jeste nejak vyjadri a upresni me.