Přejít na obsah






Fotka
* * * * * 25 hlasy

GGZ mýtů zbavené

Příspěvek od HaLuMa , 16 leden 2014 · 8 327 Zobrazení

garmin
V roce 2013 přišel Garmin s novým přístrojem Oregon 6x0. Geocachery hned zaujala novinka, že oproti starým modelům, kde se limit počtu keší pohyboval od 1000 do 5000 (podle konkrétního modelu), se zde limit zvedl až na čtyři milióny. To celé prý díky novému formátu GGZ, kterým nahrazují dosavadní GPX.

A smršť dohadů na celosvětových diskuzních fórech na sebe nenechala dlouho čekat. Nicméně, člověk se dozvěděl jen odhady, dohady, nikoliv však fakta.

Oregon600


V tiskové zprávě Garminu stálo, že GGZ vám vygeneruje GSAK, nebo jiný váš oblíbený program či web. Jakožto autor jednoho takového oblíbeného programu jsem zkusil kontaktovat přímo Garmin, jestli bych nemohl získat specifikaci GGZ, abych jej také mohl zapracovat do své aplikace. Odpověď jsem dostal ve stylu, že mi ji nedají, protože je to stejně jejich proprietární formát určený jen pro opencaching.com, takže mi do toho vlastně nic není. (A to, i když jejich Opencaching v mé aplikaci také podporuji.) Garmine, styď se!

Pomohl jsem si sám, a ze získaných vzorků od laskavých uživatelů jsem brzy podstatu GGZ formátu odhalil, a mohl jsem tak vyrobit veřejně dostupný konvertor mezi GPX a GGZ.(viz. http://geoget.ararat...doku.php/ggzgen)Tedy něco, co bych čekal, že bude nabízet sám Garmin na svém webu. Garmine, styď se podruhé!

Nicméně až teď, když mám Oregon 600 v ruce, jsem se mohl tomu záhadnému GGZ podívat pořádně na zoubek. K čemu je tedy GGZ ve skutečnosti dobrý?

Než si to vysvětlíme, je třeba pochopit, jak to uvnitř Garmin GPS funguje. Každá čára na mapě, každé její zalomení, každá hranice plochy, i každá mapová značka, to je hodně moc bodů! Klidně v řádu miliónů. Problém, který musí GPS řešit, zní: „Jak hodně rychle v těch obrovských souborech najdu právě ty body, které právě teď potřebuji vykreslit uživateli na displej?“ Řešení je v těch souborech s mapami (ale platí to třeba i pro GPI soubor s uživatelskými POI body). Jejich vnitřní struktura je vymyšlena tak, aby v nich GPS mohla rychle najít právě to, co potřebuje. Je to vlastně taková specializovaná databáze uzpůsobená právě tomuto jedinému účelu. A dokáže to dělat dobře, vemte si, že to fungovalo i na mnohem starších modelech, které měly doslova zlomek výkonu dnešních přístrojů! (Ale bohužel, starý formát znamená také leckdy zdánlivě absurdní omezení.)

Jenže vy tam dáváte keše v GPX souboru. To je textový formát uzpůsobený snadné výměně dat mezi programy a zařízeními. Není úsporný na velikost, a už vůbec nemá žádné optimalizace na to, aby se v něm dalo rychle vyhledávat podle souřadnic! Co s tím GPS může udělat? Potřebuje vzít alespoň ta data, která potřebuje na vykreslení mapové značky, a uložit si je tak, aby s tím mohla GPS rychle pracovat. Tedy základní info o keši. Listing, logy, i další věci nejsou zajímavé, pro ty se dá jednorázově sáhnout do GPX až ve chvíli, kdy si uživatel přeje zobrazit listing. Tam nás nějaké zdržení netrápí. Ale ty mapové značky, ty musíme mít rychle.

Musí tedy vzniknout jakýsi index. Souřadnice a základní informace o keši. A to celé uložené tak, aby s tím GPS mohla pracovat. Ale kam si tento index má GPSka dát? Možnosti jsou dvě. Buď na úložiště (tedy tam, kde jsou mapy, GPX, a další soubory), nebo do operační paměti. (Což je kus paměti, kde běží samotný program GPS, po vypnutí se smaže.)

Tento index se vytvoří při zapnutí GPS. V průběhu nabíhání se přečtou vámi nahrané GPX soubory. Z Geocache si vyrobí index, a waypointy se dají do obyčejných trasových bodů. I z těch se asi někde udělá podobný index. Nevím jistě, kam se u starších GPS tyhle provozní indexy ukládaly, ale dost možná, že právě do té operační paměti. Pak by to totiž vysvětlovalo ony dosti nízké limity na celkové počty keší a waypointů.

Je jasné, že aby Oregon 6x0 zvládl 4 milióny keší, musí to dělat jinak než doposud! Taková věc by se do operační paměti nevešla ani náhodou. Index tedy hledejme na úložišti. A opravdu tam je! Nalézá se v souboru \Garmin\SQL\UserData.sqlite3.

Přichází první překvapení. Garmin začal používat obecnou databázi místo svých proprietárních formátů. A to konkrétně SQLite3 s rozšířením RTREE. Oboje je mi důvěrně známé, neboť databáze Geogetu používá shodnou technologii. Je to fajn, protože existuje dost nástrojů, pomocí kterých se dá dovnitř podívat.

Uvnitř této databáze opravdu najdeme souřadnice keše, její základní informace, ale také odkaz na soubor, ze kterého byly informace načteny. A navíc je tam i pozice keše v tom zdrojovém souboru, aby si mohla GPS sáhnout pro úplný záznam pro účely zobrazení listingu.

Tento databázový index je schopen pojmout velké množství záznamů. Nicméně ty 4 milióny, to je klasický marketingový krasožvást. Tolik byste tam nenarvali, i kdyby tolik keší existovalo a vy je měli čirou náhodou stáhnuté. Oregon totiž nemá výkon na to, aby takto velké množství keší dokázal načíst v řádu alespoň desítek minut. Kolik se tam tedy doopravdy vejde? No, rozhodně více, než asi budete potřebovat. Ale pokud jste si všimli, toto se týká jen samotných keší. Ne však jejich waypointů! Pro waypointy keší se totiž nezměnilo nic, snad jen to, že limit je 4000. Garmine, to myslíš vážně?

Aby to celé fungovalo, musí se nám na úložiště vejít jednak původní GPX soubor, ale také navíc ten vygenerovaný databázový index. Dobře, GPX soubor lze dát i na paměťovou kartu. Při průměrné velikosti tuzemského listingu 11kB by se nám na 32GB kartu vešlo něco kolem tří miliónů keší. To není zlé. Kolik ale zabere ten index v interní paměti?

Empiricky jsem zjistil, že indexová databáze bobtná zhruba 200 bytů na keš. Pokud je pravda, že limit je čtyři milióny keší, a opravdu se tento limit hlídá, pak by se ta indexová databáze neměla rozrůst na více jak 800MB.

Jakmile GPX soubory smažete, při dalším nabíhání GPS promaže z indexu již nepoužívané záznamy. Proto nejen po přidání souborů, ale i po jejich smazání náběh GPSky trochu déle trvá. Jenže ta indexová databáze se ve skutečnosti nezmenší! Zůstane stejně velká, akorát si jen poznačí, které části databázového souboru může opět použít. Takže o místo, které index jednou zabral, jste přišli, i když všechna GPX smažete. Leda že by firmware GPSky čas od času provedl tzv. Vacuum, což u mne ještě nenastalo. Garmine, doufám, že jsi na to nezapomněl! Ještě štěstí, že to asi nebude mít negativní vliv na životnost flash paměti, protože jestli použili stejný chip jako v eTrex30, tak ten má Wear Leveling, tudíž neustálé přehrávání nebude mydlit stále tytéž paměťové buňky.

Pozorný čtenář si už chvíli pokládá otázku: „Vždyť on tu pořád mluví o GPX, ale ne o GGZ!“ Ano, je to tak, zatím jsme totiž GGZ vůbec na nic nepotřebovali! A ano, abyste do Oregon 6x0 dostali mnoho keší, stačí naprosto obyčejné GPX.

Tak proč GGZ formát? K čemu je vůbec dobrý?
  • GGZ soubor je komprimovaný. Je to ve skutečnosti jen přejmenovaný ZIP soubor. Zabírá tak v paměti méně místa. Což ale při velikosti dnešních SD karet není žádné terno.
  • Menší soubor se také rychleji nahraje do navigace. Jen je nutné brát v úvahu, že ten nový Oregon má i rychlejší USB, takže reálná úspora je malá, a je nutné připočíst čas na výrobu GGZ.
  • Do GGZ souboru se dá uložit hned několik různých GPX souborů. Ano, GGZ obsahuje uvnitř sebe obyčejné GPX. Zjednoduší to manipulaci, pokud třeba máte větší množství malých GPX.
  • Do GGZ se dávají jen keše, nikoliv waypointy!
  • GGZ obsahuje navíc předgenerovaný index. Je v něm přesně to, co si GPS ukládá do té své indexovací databáze.
Díky tomu všemu je načítání keší z GGZ souboru rychlejší. GPS při nabíhání nemusí přečíst celé veliké GPX soubory, aby si z nich vytáhl jen zlomek informací. Místo toho si z GGZ rozbalí právě a jen ten relativně malý indexový soubor, a jeho obsah nasype do své databáze. A rozdíl v rychlosti není zanedbatelný. Co jsem zkoušel, bylo načítání GGZ zhruba 2x až 3x rychlejší než GPX. Nicméně i tak, kdyby se mělo načítat oněch deklarovaných 4000000 keší, byla by to zábava na několik hodin.

Mimochodem mne napadlo, proč vyhledávání keší prohledává jen v okolí cca 200km? Odhaduji, že GPSka vezme polohu, a k ní jednoduše přičte a odečte jeden stupeň v každém směru. Tím dostaneme ‚obdélník‘ o hrubých rozměrech (nepočítal jsem to, tak mne nechytejne za slovo) 220x140km. A tímto obdélníkem si pomocí RTREE v té SQLite databázi vyfiltruje ty keše, které jsou uvnitř toho obdélníku. A s těmi teprve dále pracuje. Docela tahle teorie sedí, nemyslíte?

Takže když to shrnu:
  • Na větší množství keší GGZ nepotřebujete, stačí GPX.
  • GGZ je ale rychlejší a zabere méně místa.
  • Problémem zůstávají waypointy.
Nyní víte o GGZ snad úplně vše. Pokud se dozvíte něco nového, nebojte se o to s námi podělit!

 Doplněno 17.1.2014

Pokud v GPS zrovna nemáte žádné GPX a GGZ soubory s kešemi, můžete tu indexovací databázi smazat. GPS si ji při náběhu znovu vyrobí, ale opět malou.

Také mám pro vás konkrétní test. Vzal jsem keše v celé ČR, což bylo zrovna 36418 kusů. A provedl test s GPX:
  • Velikost souboru 398MB
  • Upload do GPS na kartu: 5:29 (přes GPS na dodávanou kartu)
  • Načítání bodů při náběhu: 5:10
  • Úklid po smazání: 1:18
A jak to dopadne s GGZ?
  • Velikost souboru 101MB
  • Vytváření GGZ: 3:23 (To záleží hodně na výkonu počítače!)
  • Upload do GPS na kartu: 1:24 (přes GPS na dodávanou kartu)
  • Načítání bodů při náběhu: 1:24
  • Úklid po smazání: 1:18

 Pokud se Vám tento blog líbil, přidělte mu hvězdičky nad nadpisem. Děkuji!

  • 31



Je rozdíl v rychlosti zapínání gps a práci s kešemi v navigaci, pokud je v GPS uložen například jeden GGZ soubor se 4mi státy, nebo je lepší nahrát každý stát zvlášť? Máte to někdo vyzkoušené?

    • 0

Nyní právě zkouším rychlost načítání a konzultuji s českou podporou Garmin a z toho co jsem zjistil, tak je to následovně:

 

1) Nezáleží na rozdělení dat do více souborů (to už v podstatě HaLuMa psal), protože při načtení GGZ nebo GPX se vytvoří JEDEN indexovací soubor ve kterém se vyhledává. Při vstupu do menu geocaching se nejdříve vyhledají všechna ID keší, které jsou v okruhu 160 km a odpovídají nastavenému filtru. Ve výpisu se pak podle ID načítají i další infromace.

 

2) Problém s rychlostí, na který se pravděpodobně ptáš, pramení z toho, že přístroj prochází VŠECHNY keše v okruhu 160 km a je mu jedno, jestli jich tam je 7000 (to by byla odezva cca okolo 5 vteřin) a nebo 60 000 (to je pak odezva cca okolo 100 vteřin) - obojí jsou časy při testu s GGZ ve kterém je 137000 keší.

 

3) Problém s rychlostí NENASTÁVÁ na mapě a i několik tisíc keší se zobrazí do 5 vteřin (zde se to špatně odhaduje, protože ještě záleží na rychlosti načtení mapy). Načtení několika až několika set keší je velmi rychlé a pohodlné.

 

4) Přístroj sice vyfiltruje i několik desítek tisíc keší okolo dané polohy, ale ani na několika testovacích souborech s nastavenou různou polohou se mi ještě nepodařilo přescrolovat až dolů a přístroj se vždy zasekl.

 

 

Z bodu 2 vyplývá, že by stačilo omezit počet keší v seznamu napevno například na 1000 (nebo klidně i 5000) a nebo i uživatelsky ve filtru (to by ale asi nikomu na nic nebylo, protože se neukazuje počet vyfiltrovaných keší a ani to nelze nijak jinak využít, protože se přístroj sekne).

 

To, že není problém filtrovat rychle dokazuje bod 3), protože na mapě funguje vyhledávání v databázi rychle...

 

Tato úprava by nenarušila ani další funkce v menu Geocaching, podle názvu se vyhledává opět znovu a omezení se na to vztahovat nemusí...

 

Pokud se někde mýlím, prosím opravte mě někdo.

 

Tomáš

    • 0

Problém (eTrex20)

- mám cache.ggz soubor v adresáři \Garmin\GGZ na SD kartě, ale po zapnutí se nic neděje a cache nejsou na mapě. Co s tím?

Dík*

    • 0

eTrex20 GGZ nepodporuje.

    • 0

Ale narazil jsem na Garminu, že eTrex series to podporuje nebo jen novější? Nebo update firmware?

    • 0

Mozna nejake novejsi modely (20x nebo 25 Touch), ale stary eTrex 20/30 to opravdu neumi.

    • 0

Díky za info*

    • 0

Říjen 2019

P Ú S Č P S N
 123456
78910111213
1415 16 17181920
21222324252627
28293031   

Poslední komentáře

Reklama

Naše nabídka