[CZ] - Načítání TAR map

[romantic29]

Ahoj,
zkouším podporu .tar pro trekbuddyho v aktuální verzi locus PRO a narazil jsem na následující:
1) když tam nahraji dílčí tary, problém je, že na nejnižším zoomu (14 pro celý čr) .tar atlasu mám více jednotlivých map (tuším, že 5 nebo 6), když je tam nahraju všechny locus si s tím neporadí a ukazuje pak, že je k dispozici více vrstev (10, 12, 14-18), místo správného (10, 12, 14). Při zoomování se mi pak na většině map ukazuje jen bílo. Bohužel nevím, jak jinak si tyhle mapy přegenerovat do sqlite, protože ty podkady už nejsou dostupné v MOBACu :-(.
2) I když tam nahraji od vrstvy 14 jen jednu mapu a pohybuji se v místech, kde určitě ta mapa je k dispozici, locus při zoomování často padá a je v podstatě nepoužitelný (odeslal jsem pár hlášení)...
3) Přechod mezi jednotlivými dlaždicemi není plynulý, ale trošku trhaný, v trekbuddy i na starém mobilu u stejného atlasu plynulý je...

Prosím o pomoc, jak tohle mám vyřešit, nevím si s tím rady. Svoje atlasy bych rád používal a bohužel už si je nemůžu znovu vytvořit (podklady pro cykloturistické mapy ČR a Slovenska už nefungují, preferoval bych sqlite, ale, nevím, jak to tam převézt - program, který je zde na fóru, nefunguje, generuje soubory s konstantní (a dost malou) velikostí bez ohledu na to, co mu podstrčím. Velikost dlaždice mám odladěnou pro trekbuddyho s ohledem na úsporu místa 1024x1024. Díky moc za rady...

[romantic29]

Díky za nasdílenou mapu... Má to ale jeden háček - můj trekbuddy atlas, cyklo ČR, zoom 10, 12, 14, dlaždice 1024x1024, kvalita jpeg 70, má necelých 300MB, stejný atlas v sqlite má 2GB - to je strašně moc. Další atlasy v sqlite jsou dokonce ve více souborech a je jich opravdu hodně a zabírají opravdu moc místa, navíc to že budu muset vždy otevírat náhledovku a vybírat tu správnou mapu to jsou dva kroky dozadu... Chtěl bych se proto zeptat: je sqlite tak prostorově neefektivní? Už jsem přišel na to, jak předělat .tar atlas, aby v jedné úrovni zoomu byla opravdu jen jedna mapa, ovšem nyní mě trápí fakt, že locus na .tar mapě pořád padá (a to celkem často) :-(. Proto jsem se chtěl zeptat, jestli se to bude nějak opravovat, případně jetsli nemůžu být nějak nápomocen...

[Menion]

Nezdá se mi že by SQLite databáze měla mít větší objem při stejných datech. Háček tam bude někde jinde, pravděpodobně zoom 15 který bude v SQLite (nebo i více) a který v taru není

každopádně, problém že mapa padá bude celkem jistě kvůli velikosti dlaždic. 1024x1024 je opravde velmi neefektivní velikost na mobilní zařízení. Ideální je 256x256, přinejhorším 512x512. Prozraď mi, tobě mapa s tak velkými dlaždice na androidím TrekBuddy programu běhá bez problému?

[romantic29]

Nezdá se mi že by SQLite databáze měla mít větší objem při stejných datech. Háček tam bude někde jinde, pravděpodobně zoom 15 který bude v SQLite (nebo i více) a který v taru není

v tom určitě problém není - mapy jsou to úplně stejné, navíc do sqlite se mapa ani nevygenerovala celá - ale podle bližšího zkoumání to vypadá, že na sqlite mapy se neaplikuje nastavená konverze jpegu (jsou mnohem hladší) a nevím jak to donutit ten jpeg využít, skoro bych řekl, že to tam ukládá v .png

každopádně, problém že mapa padá bude celkem jistě kvůli velikosti dlaždic. 1024x1024 je opravde velmi neefektivní velikost na mobilní zařízení.

Používám větší dlaždice, protože jsou prostorově mnohem efektivnější - samozřejmě jedna dlaždice 1024x1024 zabere mnohem méně místa než když je rozdělná do 4 souborů 512x512. Jen pro zajímavost atlas s dlaždicema 512x512 zabere cca o 25% víc místa -> úspora plyne z postupných kroků jpeg komprese, kde především RLE komprese je efektivnější.

Ideální je 256x256, přinejhorším 512x512. Prozraď mi, tobě mapa s tak velkými dlaždice na androidím TrekBuddy programu běhá bez problému?

No chodí to absolutně bez problémů a naprosto plynule, žádný náznak záseku. Vlastně dlaždice 1024x1024 jsem 3 roky používal i na mém 4 roky starém telefonu SE G502 pod javovským trekbuddy, i když úplně plynulé to nebylo, používat to šlo... Ovšem abych byl objektivní, trekbuddy nepodporuje digitální přibližování a oddalování na fixním zoomu mapy, především pak díky oddalování se tedy asi může stát, že Locus má načteno více dlaždic najednou a tady už si asi dokáži představit, že to může padat kvůli jejich velikosti... Každopádně otestuji teda pořádně .tar mapy na 512x512 a dám co nejdříve vědět...

[Menion]

moc těm všem kompresím nerozumím takže to beru jako platný fakt a díky za poučné informace

problém s velkými dlaždicemi je ten, že podstatná část z nich může být mimo obraz a nikdy nevyužitá. Tzn i když je potřeba jen úzký proužek, musí se načíst obří obrázek.

TrekBuddy má navíc asi celkem výhodu v tom, že jako aplikace je značně jednodušší než Locus a tedy sama o sobě ubírá z paměti méně místa a více tedy zbývá na mapu. Opravdu zkus ty 512x512. Kdyby i ty zlobily tak s tím zkusím zase po čase něco provést. Nějaké optimalizace v tomhle směru rozhodně neuškodí ...

[romantic29]

Otestována stejná mapa 512x512 dlaždice. Padá podstatě méně a vlastně pády jsem vygeneroval pouze v případě, že jsem na určité vrstvě hodně digitálně odzoomoval a pak přejížděl - vše tedy nasvědčuje tomu, že to padá opravdu kvůli paměti. Posouvání je stále malinko trhané. Asi si pořídím 32GB kartu na sqlite mapy. Stále ale vidím velikou nevýhodu v tom, že se sqlite mapy nevejdou do jednoho souboru a pak člověk musí přepínat jednotlivé vrstvy. Rozdíl ve velikosti je opravdu asi tím, že sqlite nepoužívá jpeg, ale png. Mám ke své domněnce dva důvody: 1) při zazoomování je mapa kvalitní a není na ní pozorovatelný klasický kompresní šum jpegu 2) u jednotvárných map, kde se opakuje jen několik barev (např. klasické google mapy), kde se dá očekávat png bezztrátová komprese efektivní, je rozdíl velikostí atlasů v jednotlivých formátech malý, zatímco u rozmanitějších map (např. cyklomapy s reliéfem) je rozdíl ve velikosti několikanásobný

[lacop2]

... Stále ale vidím velikou nevýhodu v tom, že se sqlite mapy nevejdou do jednoho souboru a pak člověk musí přepínat jednotlivé vrstvy. ...

Ale to v prípade Locusu vôbec nie je nevýhoda, skôr naopak. Locus to má výborne ošetrené. Budem citovať sám seba z iného fóra z návodu na výrobu turistických máp pre Locus pomocou programu MOBAC:

" !!! TIP: Pokiaľ by sme si chceli vyrobiť mapu celého Slovenska (odporúčam vo všetkých zoomoch, t. j. 7 až 15), je potrebné územie Slovenska rozdeliť napr. na takých 6 mierne prekrývajúcich sa máp (každá v zoomoch 7 až 15). Výsledné súbory môžeme nazvať "Slovensko1.sqlitedb" až "Slovensko6.sqlitedb". V telefóne na SD karte potom v priečinku "Locus/maps/" vytvoríme nový priečinok s názvom napr. "Slovensko s lesnymi cestami" a až do toho priečinku umiestnime všetkých 6 mapových súborov "Slovensko1.sqlitedb" až "Slovensko6.sqlitedb". Mapu v programe Locus potom nájdeme pod názvom "Slovensko s lesnymi cestami". Takto môžeme mať v Locuse pod jedným názvom viacero na seba naväzujúcich máp rovnakého typu."

[romantic29]

Ale to v prípade Locusu vôbec nie je nevýhoda, skôr naopak. Locus to má výborne ošetrené.

O tom jsem neměl ani ponětí a funguje to výborně, díky za upozornění :-) a smekám před autorem, Locus mě stále příjemně překvapuje. Takže nevýhoda už je jen to místo, ale 32GB microSD je již objednaná :-), takže to brzy ani taková nevýhoda nebude.

[Menion]

fajn no nic to ale nemění na faktu že Locus má problémy s pamětí které se stejně tak můžou projevovat i u SQLite map, takže o důvod více s tím něco udělat ...

ta trhanost je myslím způsobena tím, že mapové dlaždice pro Offline mapy načítám v hlavním vlákně narozdíl od online map kde se donačítají průběžně. Už jsem nad tím uvažoval že bych přidal možnost aby si na pomalejších telefonech lidé mohli zapnout nějakou "Zpožděné naítání" což by zvýšilo plynulost mapy za cenu občasného bílého místa než by se mapa donačetla. No ještě to nějak promyslím .. každopádně ať slouží

[romantic29]

Jaké má to spojování map možnosti / omezení?

Tak mě napadá např., jestli to napojí i sqlite mapy, které mají trošku jiná měřítka (např. jedna 7-14, druhá 7-15) - myslím tím, jestli vrstvy 7-14 budou napojené...

[Menion]

budou .. omezení není žádné. systém je prostý. vezme se jedna mapa a použije se pro zobrazení. když někde nebude dlaždička, začnou se prohledávat další mapy aby doplnily mezeru. Problém může být v případě hodně menších map, takže nad takových pět kousků v jednom adresáři nedoporučuju ... ale sám jsem to ani pořádně nezkoušel takže i tak by nemusel být problém ...

[romantic29]

Tak mě napadá, locus provádí s mapama nějaký preprocessing či indexaci? Přidal jsem 6GB nových map a už nějakých 10 minut se locus "inicializuje" :-)...

[Menion]

6GB? no snad se mu to nakonec povedlo jo něco se tam děje ...

[romantic29]

6GB? no snad se mu to nakonec povedlo jo něco se tam děje ...

Samozřejmě již vše skvěle funguje :-).

[segi]

Zdravím,
nahodil som si do Locus mapy čo som používal v Trekbuddy. Jedna skupina ide v pohode, druhá skupina máp sa tvári ako zle skalibrovaná a tretiu mi pri načítavaní aplikácie vyradí ako chybnú.
Všetky mapy boli spravene v Oziexploreri kde fungujú správne. Ani v Trekbuddy nebol problém.

Tu je link na "zle skalibrovanú":
//http://l4j3un.1fichier.com/en/
a tu na chybnú:
//http://fprxro.1fichier.com/en/

Vie mi niekto s tým poradiť?