Messages

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

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

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" :-)...

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é...

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.

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ý

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...

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...

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...