3
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.
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ý?
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:
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:
Pokud se Vám tento blog líbil, přidělte mu hvězdičky nad nadpisem. Děkuji!
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.
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.
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.
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
- 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!
Aspon nekdo mi na ten blog pise 
GeoGet
URWIGO
CWG
Ještěrka zdarma
Významné stromy
publish
Je to ve skutečnosti jen přejmenovaný ZIP soubor
A to není ani zazipovaný s heslem ? Člověk by řekl, že doba pokročila, ale asi ne. Stejnou fintu jsem použil před nějakými 20lety, když jsem programoval proprietární HELP knihovnu. Ani jsem neindexoval, vyhledávalo se sekvenčně a stačilo to. Ale tenkrát to bylo třeba kvůli malým diskům.