To neni špatný nápad.
Větší číslo je lepší proto, aby objekty neskakaly po mapě z jednoho místa na druhé (spojené čarou). Pri delším časovém rozlišení to udělá stejně, ale aby to nedělalo pri běžném hodinovem timeoutu. Muselo by se to spočítat.
Pridavam dalsi moznost.
APRS "standart" umoznuje objekty mazat, staci zmenit hvezdicku pred casovou znackou za podtrzitko, viz:
;123test *051850z5004.50N1425.30E<testovaci objekt
;123test _051850z5004.50N1425.30E<testovaci objekt
pokud by aprs.fi zacalo tuto funkci podporovat, mohly by se objekty po nejake dobe mazat ....
Já jsem nemyslel že bychom řešili Poláky, ale spíš utvořit název objektu tak, aby (když se to bude jinde líbit) mohli pokračovat stejným systémem. t.z.n. [Prefix]_"STR"_[pořadové číslo]. Myslím, že by bylo vhodné provést následující kroky:
1. Hluboce se zamyslet na tím "kolik" čísel by bylo potřeba
2. napsat Hessimu návrh:
a) Variantu s omezeným počtem recyklovaných objektů (a co by tomu řekl, kdyby jich bylo maximálně "x")
b) navrhnout implementaci "gumování" objektů jak je to v bibli viz. Liborův text (a zdůraznit, že by tato funkce a její propagace mohla značně ulehčit jeho databázím i od jiných uživatelů)
Pojdme to tedy nejak dotahnout do konce. Po vcerejsi korespondenci mame na vyber dve moznosti:
1. Ponechat v podstate vse jak je, s tim rozdilem, ze blesky se budou posilat pod jinou CALL-SSID, kterou Hessu zablokuje tak jako ted OK1COM-10. A ostatni objekty (TA, METAR, CHMI WX, apod.) budou i nadale vysilany pod znackou OK1COM-10, kterou Hessu odblokuje.
2. Omezit mnozstvi objektu reprezentujici blesky na konkretni cislo na kterem se s Hessu shodnem. Tzn besky by se jmenovaly napr. STR_001 az STR_300, popr. OK_STR001 az OK_STR300. Zaroven by Hessu omezil ukladani objektu se symbolem blesku na nezbytnou dobu tak, aby aby se zobrazily na mape, tj. napriklad na 1 hodinu. U teto varianty by se samozrejme vse i nadale vysilalo pod znackou OK1COM-10, kterou by Hessu odblokoval.
Obe reseni maji za cil opet zviditelnit objekty vysilane serverem OK1COM-10 na mape aprs.fi, kdy u prvni varianty bychom prisli o moznost sledovat blesky.
Takze co vy na to?
Predne verejne dekuji Liborovi, ze se ujmul vyjednavani s Hessu.
ad1) Jednoduche reseni, ktere bude pro Hessu urcite prijatelnejsi, protoze jak jsem to pochopil, tak se mu moc nelibi blesky na aprs.fi (nejen to, ze mu plni databazi, ale ze tam vubec jsou). Chapu to, na to jsou jine mapy. Pro nas jsou dulezite blesky na RF a zobrazovani vseho ostatniho na aprs.fi.
Nevyhoda je nutnost dvou SSID a prenastaveni vsech gejtu co propousti COM-10 do RF. Druha SSID by byla OK1OAB-10.
ad2) Tato varianta by byla asi zajimavejsi, protoze by blesky zustaly na mape aprs.fi, ale znamena to zasadni upravy jak na strane serveru aprs.fi tak COM-10. Cislovani bych asi zvolil trochu jinak. Celkova povolena suma by mela byt delitelna 60 (pocet minut v hodine). Cislovalo by se pak pak napriklad A01, A25, A59, B10, ... tedy A-prvni hodina bourky, 01,25,59 - minuta v hodine, B-druha hodina bourky. tedy 300 objektu - 5 hodin [A-E][00-59]. Cislovani hodin by se tocilo neustale dokola tj. po Ecku je znovu Acko a nasledujici bourka zacina, tam kde predchozi skoncila. Nebo dokonce pri 360 objektech tj 6hodin by hodiny mohly na pevno tj A=00,06,12,18. Uvedomuji si, ze takoveto cislovani se bude tocit mnohem rychleji (ne vsechny minuty budou mit "svuj" blesk) nez proste 1-360, ale i presto povazuji za prednejsi mit na prvni pohled jasny cas uderu blesku.
Samozrejme nejidealnejsi by bylo cislovani HHMM (tedy pouha zmena z STR_DDHHMM na STR_HHMM - ostatne to jdu udelat hned), ale to muze byt teoreticky az 1440 objektu, realne behem bourkove sezony mene nez polovina. Ale to uz asi nebude pro Hessu zkousnutelne. Na druhou stranu mene nez 240 tj. 4 hodiny je asi zase neprijatelne pro nas z duvodu velmi rychleho opakovani. Je velka sance, ze se cykus otoci i behem jedne bourky.
Velka vyhoda je zachovani jedne SSID.
Prikladnim se k variante 2, ale varianta 1 je pro me take schudna.
60%-var2 / 40%-var1
