Přejít na obsah






Fotka
* * * * * 25 hlasy

GGZ mýtů zbavené

Příspěvek od HaLuMa , 16 leden 2014 · 8 244 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 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.

    • 0

Pěkné!

    • 0
Ne, zadne heslo, jen obycejny zip.
    • 0
Fotka
petulinka1
led 17 2014 7:20

Tak vis co - proc by se Garmin namahal neco jednou udelat poradne? Jejich politika vyroby/vyvoje je uplne stejna jako u GS - neco udelame, kdyz to netihneme, tak to nevadi, proste to zametem pod koberec, publikujem to jako bomba vec. Lidem to udela radost, ale to je tak vsechno, co pro ne muzem udelat. Jak se s tim funguje a co to vlastne je, jim rikat nemusime, jeste by prisli na to, ze jsme se na to vybodli...

    • 0
Fotka
petulinka1
led 17 2014 7:20

Jinak dik za fajn clanek :) Aspon nekdo mi na ten blog pise :D

    • 0
Fotka
pozorjed
led 17 2014 7:54

pěkné, to je za několik palců nahoru, jak článek, tak konverzní nástroj, díky

    • 0

Hezký článek. Kdysi jsem někde četl, že GGZ má raději, když ty jednotlivé GPX co má uvnitř nemají víc jak 5 MB (snad kvůli rycglosti rozbalování v GPS či co).

 

A ohledně zipování - ony i formáty docx a xlsx jsou jen obyčejné zip soubory, takže proč něco takového "chránit" heslem a ztěžovat tak lidem práci?

 

Zajímalo by mě ale, jaký je tedy reálný limit na počet keší v GPX souborech v Oregonu 6x0?

    • 1

Rekl bych, ze nejvice limitujici je cas, ktery hodlas venovat nabihani GPSky. Trpelivost ti dojde driv nez narazis na realny limit.

    • 0

Je vidět, že je opravdu dobře, že tu GPSku vyhrál HaLuMa :-)

    • 6

U Oregonu 450 se mi stalo, že se mi nezobrazovaly všechny keše a to jsem nepřekročil limit 5000 kusů (a nezobrazovalo se to docela náhodně). Proto by mě zajímalo, jestli u Oregonu 600/650 můžu načíst GPX třeba s 10000 kešemi a všechno se zobrazí.

Je to ale spíše teoretický dotaz, Waypointy i teď exportuji jako POI, takže v případě přechodu na O6x0 bych jen musel výsledné GPX převést do GGZ

    • 0

Jen co vyzkousim, ze umim tu indexovou databazi fyzicky smrsknout, tak pak klidne otestuji nejakou poradnou naloz.

    • 0

Mam v Oregonu 600 57000 kesi v GGZ. Prvni nacteni a nasledne pouziti filtru je uplne vpohode. Zobrazovani na mape taky. Waypointy taky davam do POI.

    • 0
Tak toto je bomba článek. HaLuMo, díky za investigativní práci v oblasti GPX a GGZ. Se zájmem jsem si početl.
    • 0

No to vite, kdyz se profesionalni novinari zmuzou maximalne tak na opisovani PR clanku, tak tu investigativnost musi vzit do svych rukou amateri.

    • 1

Tak jsem právě vyzkoušel, že ten nezmenšitelný databázový soubor stačí prachprostě smazat. Při startu si GPS vyrobí nový, prázdný a malý.

    • 1

Pripsal jsem male doplnení blogu, kde najdete i konkretni test s kesemi z cele republiky.

    • 1

Řekl bych, že zdroják ggz není opensource, takže bych se moc veřejně nechlubil nabouráním se do něj (i když je jeho zabezpečení na úrovni zabezpečení gc.com). Jinak zajímavý článek.

    • -7
Honzáku, huš! GGZ = GPX + ZIP. ZIP - otevřený formát, GPX - otevřený formát, SqLite - otevřený formát. Co řešíš?
    • 0

GGZ je zazipované GPX, ke kterému je přidaný XML soubor se seznamem keší (SQL databázi si vytváří až sama GPS). Zipuje se to snad jen kvůli úspoře místa a nebo aby to byl jakoby jeden soubor.

 

"Nabourat" se do něj je tedy stejné jako rozbalit zazipované TXT a přečíst si, co je v něm napsané

    • 0

Aha, takze ja neco hacknul pouzitim dvou otevrenych prumyslovych standardu ZIP a XML? Dobry! :-)

    • 2

Srpen 2019

P Ú S Č P S N
   1234
567891011
12131415161718
19202122 23 2425
262728293031 

Poslední komentáře

Reklama