Přejít na obsah






Fotka
* * * * * 25 hlasy

GGZ mýtů zbavené

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



Fotka
petulinka1
led 18 2014 15:39

Teda, Halumo, mel by ses stydet! Delas tu nekaly praktiky a jeste se tim verejne chlubis, jako by se nechumelilo (ne, ze by venku bylo dvacet metru snehu :D) :D

 

Ja ti za to snad dam jedno obrovsky varovani, mozna i ten BAN by sis zaslouzil, tohle se tu prece nesmi! :D

    • 0

Jestli se to smí nebo ne je jedno, HaLuMa riskuje mnohem víc. Geohacker tu je Tiskar94, kterému tímto fušuje do řemesla, takže by se teď mohl bát nějaké velmi nepříjemné pomsty. A když navíc bude zabanovaný, tak o tom ani nebude moct dát vědět  ;)

    • 1

Mám v Oregonu také celou čr. Nabíhání GPS mně tolik nevadí (na začátku lovu zapnu, večer když se vracím domů zase vypnu), ale co mně štve je, že když zvolím "hledání pokladu", začne se mi načítat, točit zelené kolečko a na seznam keší v okolí čekám cca půl minuty. Jde s tímhle něco udělat? Kromě toho, že do oregona nahraji menší počet keší. Používám výhradně ggz.

    • 0

Pomalost vyhledavani je stejna jak u GGZ, tak i u GPX, nebot se hleda na shodne indexove databazi.

 

je to dano i tim, ze ti GPSka chce naservirovat nalezene kesky od nejblizsich po nevzdalenejsi. jenze ktere jsou ty nejblizsi? V tom ti ta databaze nepomuze, musis vzit pekne bod po bodu a spocitat vzdalenost od tve aktualni pozice. A az u vseho spocitas vzdalenost, pak to teprve muzes seradit a hodit na displej. proto to tak dlouho trva.

 

Optimalizovat se to da jen vhodnym vyberem kandidatu podle toho RTREE. Ale jestli berou nejake vetsi uzemi (nedej boze tech 200km kolem!), pak to chvili trva...

    • 0

 

Optimalizovat se to da jen vhodnym vyberem kandidatu podle toho RTREE. Ale jestli berou nejake vetsi uzemi (nedej boze tech 200km kolem!), pak to chvili trva...

 

A nějaká cesta, jak zúžit ten vyhledávací okruh asi neexistuje, co?

    • 0

Efekjtivni by bylo - stat se programatorem u Garminu a ten firmware trochu prepsat. Protoze:

  • I hledani podle nazvu hleda jen v tom okruhu cca 200km. Proc, proboha? Proc neprohleda cely ten index?
  • Hledani v okoli zase pro zmenu pravdepodobne prohledava zbytecne moc velke okoli. Casto cloveka v tu chvili zajima kes v okoli radu kilometru. Az kdyz by se toho moc nenaslo, nebo by uzivatel chtel vice, mohlo by se prohledavat vetsi okoli.
    • 0

No, ono by i Groundspeaku prospělo angažovat lidi, co dělali c:geo nebo jiný podobný program nebo třeba HaLuMu, hned by to rozhraní mohlo vypadat lépe a radostněji ...

    • 0

HaLuMa si dovolil napsat lépe hodnocený blog, než Honzák, tak je z něj taky veřejný nepřítel, jako z RW :-)

    • 0
Mám Montanu a nedaří se mi zprovoznit GGZ pro geocaching. Vytvoření souboru pomocí ggzgen.exe <source_gpx> <destination_ggz> je jasné .. soubor .ggz vyzkoušen jinde a je OK.  Zkoušel jsem nahrát do složky GPX, vytvořit složku GGZ a do ní, nahrát i bez přípony, vymazat vše z GPX, a nic, nenačte se. Kde dělám chybu?
    • 0

Montana GGZ neumi. GGZ byla novinka az u Oregon 6x0.

    • 0

Tak jsem vytvořil první GGZ soubor. Hodila by se informace o tom, že vygenerovaný GGZ soubor patří do adresáře \garmin\ggz v navigaci, v adresáři \garmin\gpx to nechodilo.

    • 0

Jaký export do GPX formátu je z Geogetu nejlepší pro tvorbu GGZ databáze? Takto lze nahrát i Multiny, nebo jenom tradiční keše?

    • 0

GGZ řeší jen samotné keše a jejich listingy. Přidané waypointy se stále řeší jako normální trasové body, což není šikovné, neboť jejich počet je v GPS omezen.

    • 0

Jak mám tedy vyexportovat multinu, abych ji mohl nahrát jako GGZ? Použít tedy z Geogetu Original PocketQuery GPX? část převést do GGZ a waypointy nahrát jako GPX?

    • 0

Jednu multinu opravdu nema smysl prevadet do GGZ. To ma smysl jen u vetsiho/velkeho poctu kesi.

 

V tom pripade pouzij export do originalniho GPX (body museji byt oznaceny kodem kese). Ten vytvari jeden soubor s kesemi a druhy s WP. Prevadis jen ten s kesemi. Pokud bys mel v jedinem souboru kese i WP, myslim, ze to nevadi, protoze ten konvertor WP ignoruje.

    • 0

Jo, to je jedna z moznych cest, asi ta nejpohodlnejsi.

    • 0

Díky, vyzkoušeno a funguje

    • 0

Mám v Oregonu také celou čr. Nabíhání GPS mně tolik nevadí (na začátku lovu zapnu, večer když se vracím domů zase vypnu), ale co mně štve je, že když zvolím "hledání pokladu", začne se mi načítat, točit zelené kolečko a na seznam keší v okolí čekám cca půl minuty. Jde s tímhle něco udělat? Kromě toho, že do oregona nahraji menší počet keší. Používám výhradně ggz.

Ahoj Mikeante, mohu se zeptat, jak se dají stáhnout všechny kešky v ČR? V Pocket Querry mi jde najednou vytvořit jen 1000 keší. Díky moc :)

    • 0

Musis vsechny kese v CR rozdelit podle data jejich vzniku do vice PQ. Na den muzes mit 10 PQ, takze za 4 dny mas stazenou celou republiku.

    • 0

Ahoj Mikeante, mohu se zeptat, jak se dají stáhnout všechny kešky v ČR? V Pocket Querry mi jde najednou vytvořit jen 1000 keší. Díky moc :)

 
Gord mně předběhl. Ano, odpověď je "postupně"

    • 0

Prosinec 2019

P Ú S Č P S N
      1
2345 6 78
9101112131415
16171819202122
23242526272829
3031     

Poslední komentáře

Reklama