Messages

Díky. Zkoušel jsem ten import z Gmailu. Jedná se o klasickou Gmail aplikaci od Googlu, akorát používám záměrně trochu starší verzi (4.7.1), ale to asi nebude mít vliv. V příloze emailu je klasické GPX (většinou z Locusu, z mapy.cz nebo z cykloserveru). Ale bohužel mi to nefunguje. Tedy Locus se spustí, ale nestane dále nic. Nezobrazí se okénko o potřebě uložení a importu. Ani se rovnou neotevře importní dialog (což bych čekal). Ani se trasa rovnou nenaimportuje. Prostě se jen spustí/zobrazí Locus.

Oprávnění pro čtení emailů rozhodně potřeba není. Spousta aplikaci, které používám a pomocí kterých otevírám přílohy z Gmailu, nic takového nemají. Třeba MuPDF pro čtení PDF má jen WRITE_EXTERNAL_STORAGE a INTERNET. A normálně si tím otevřu PDF poslané v příloze emailu otevřeného v aplikaci Gmail.

Celkem bych čekal, že proto ani ze strany aplikace nebude třeba nějaká zvláštní podpora. Vlastně mi to tak funguje u všech aplikací, které jsem zkoušel, kromě Locusu.

Jinak díky za ostatní úpravy.

Ahoj, díky. Chápu, že požadavků máš tolik, že to nemůžeš stihnout. Sám asi nejlépe dokážeš posoudit poměr pracnosti k užitečnosti navrhované změny. Něco je hodně pracné, něco je třeba úprava na dvě minuty. Budu vděčný za každý vyřešený bod.

Ještě jsem zapomněl na jednu věc, která mi hodně vadí. Tedy přesněji hlavně lidem v okolí, kterým jsem Locus doporučil. Když pošlu trasu (gpx) emailem, tak po otevření přílohy z Gmailu Locus prohlásí, že trasu nenaimportuje. Že ji musím uložit a otevřít přes dialog Import. Já to umím, i když je to pochopitelně zdlouhavější. Ale ostatní s tím mají velké problémy, protože neví, ve které složce mají soubor hledat apod. Je to na ně příliš složité a těžko se jim to vysvětluje.

Vzhledem k tomu, že ostatní přílohy lze z Gmailu běžně otevřít (tedy když pošlu např. PDF, tak se mi soubor otevře třeba v Adobe Readeru apod.), tak technický důvod asi nebude. PDF (DOC, XLS a spousta dalších) je z pohledu Androidu stejné jako GPX - prostě nějaký datový soubor, kterému "rozumí" určitě aplikace, které si tento typ souboru zaregistrovaly. A evidetně se ta aplikace k obsahu toho souboru bez problémů dostane. Tak by Locus na tom měl být stejně, ne?

Generování by měla provádět funkce NAVIGOVAT DO. To může probíhat online nebo offline (pomocí aplikace BROUTER). To, že to pak mimo jiné podle té trasy naviguje, je věc jiná. To můžeš stornovat. Editovat trasa lze, ale jen přesouváním bodů - nikoli změnou průjezdních míst. Tedy alespoň o takové možnosti nevím. Třeba ti někdo poradí lépe.

Rozhodl jsem se sepsat nějaké věci, které mi na Locusu vadí (i když je celkově super). Jsou to víceméně takové různé drobnosti, které ale ve výsledku buď dělají práci potěšením nebo utrpením.

1) Rolování v seznamu tras (možná jen v případě, že jsou tam ikonky tras - mini mapy) je trochu trhané a není zde možnost rychlého rolování (chytnutí za posuvník). Pokud máš tras málo, tak to asi nikomu moc nevadí. Ale já už jich mám v některých složkách hodně a je to otravné, i když přežít se to samozřejmě dá.

2) Ikonky mapiček mi osobně přijdou dost k ničemu (idea pěkná, ale v praxi se mi potvrdilo, že na tom nic není vidět). Trochu je tam vidět tvar trasy (ale reálně mi to pomáhá jen výjimečně) a na té podkladové mapičce nevidím vůbec nic. Zabírá to dost místa a ostatní údaje jsou zbytečně malým písmem. Asi to i zpomaluje zobrazování seznamu (nenačítá se to asynchronně?). Vyhovovalo by mi, kdy to šlo vypínat/přepínat do nějakého jiného layoutu položky seznamu, který využije efektivně místo místo mapičky.

3) Na druhou stranu mě tam chybí informace o času startu a konci trasy.

4) Celkem hodně mi vadí, že název trasy se nezalamuje, ale ořezává. Přitom stejně výška položky seznamu je variabilní kvůli popisu, takže k tomu nevidím důvod. Název typicky má nějakou rozumnou délku (jeden až dva řádky) a chci jej zobrazit celý (narozdíl od popisu, který může být hodně dlouhý a zobrazit v seznamu tras jen začátek dává smysl).

5) Při klikání na ikonku oka pro zobrazení trasy Locus zobrazí nápis "Pracuji" a přestane na chvíli reagovat. Pokud těch tras chci zobrazit třeba 10, tak je to otravné. Nemůže to dělat na pozadí, aniž by to blokovalo GUI?

6) Ikonka oka je v pravé části položky, ale nezasahuje úplně doprava. Takže pokud tapnu příliš vpravo, tak netapnu na ikonku, ale na plochu položky a trasa se otevře v detailu. Bylo by dobré, kdyby tapnutí v pravé části seznamu se bralo jako tapnutí na oko.

7) Rozklinutí detailu trasy je hodně pomalé. Nevím, proč tomu tak je. Možná to způsobuje generování mapky, nevím. Pokud ano, mělo by být asynchronní. Při hledání trasy a proklikávání více tras je to opruz.

O to větší opruz je třeba pojmenovávání tras nebo jiné operace s trasami. Je třeba zbytečně rozklikávat detail trasy. Pohodlnější by bylo zobrazení menu možných operací s trasou po přidržení prstu na položce trasy v seznamu tras.Toto gesto je zde nevyužité a přitom v Androidu zcela přirozené.

9) U grafu trasy mi chybí jeden zcela přirozený graf a to závislosti uražené vzdálenosti na čase.

10) Při slučování tras (provádím často - měním akumulátor, který nevydrží celý den záznamu trasy) dostane složená trasa aktuální datum a čas (doby slučování) a nikoli datum a čas prvního slučovaného úseku. Takže se zobrazuje v seznamech úplně špatně a ani jsem nenašel možnost tento datum a čas ručně opravit.

11) V bublině, která se zobrazí po kliknutí na trasu na mapě, se zobrazí oříznutý název trasy (opět bych uvítal alespoň i dvouřádkové zobrazení). Pak je tam číslo trackpointu (to nevím, zda je k něčemu tak důležité, aby se zobrazovalo hned v té bublině). Je tam ujetá vzdálenost, zbývající vzdálenost, nastoupané km a jejich opak, nadmořská výška. Ale zcela tam chybí čas od počátku trasy, absolutní čas, čas do konce trasy,

12) Když ručně taguju trasu pro navigaci - tedy doplňuji navigační body, tak je otravné nutnost dvou tapů pro přidání navigačního bodu. Když to dělám třeba 100x po sobě (což je celkem běžné, když taguju nějakou trasu, kterou chci jet na kole), tak je to otrava. Chtělo by to mód přidávání navigačních bodů, kde by se zobrazila ikonka přidávání nav. bodu na jeden tap.

13) Nejsem si jist, zda to nějak nejde, ale při záznamu trasy se stává, že potřebuji nějaké informace o právě nahrávané trase. Třeba změřit nějakou vzdálenost nebo čas mezi dvěma body zaznamená trasy. Typický příklad - jedu z domu na sraz a dále s dalšími lidmi někam na výlet. Trasu zaznamenávám z domu. Někdo chce v průběhu výletu vědět, kolik už jsme od srazu ujeli km. Přitom tapnou na trasu, která se zaznamenává, a zobrazit třeba informace o délce od počátku trasy k bodu, kam jsem tapnul, se mi nedaří. Stopnout záznam je nepraktické. Na místě srazu záznam přerušit a udělat z toho dvě trasy by asi šlo, ale člověk na to typicky zapomene a nechce řešit. Třeba to nějak jde a nevím, jak.

Neber to prosím jako kritiku, ale konstruktivní postřehy a zpětnou vazbu z praktické dlouhodobé zkušenosti, kdy Locus používám pro pěší a cyklo výlety - plánování, navigaci, záznam tras apod.

Díky, skoro dokonalé

Díky, ale má podstatnou vadu na kráse - je to strašně pracné. Tedy vyvolat to na mnoho tapů, pokaždé napsat znovu URL, potvrdit importovací dialog... Prostě pro nějaké "live" sledování něčeho je to prakticky nepoužitelné.

Pokud by to bylo na kliknutí, tak by bylo potřeba to mít možnost umístit do pravé lištičky s ikonkami/tlačítky a provést bez další interakce s přednastavenými parametry (zejména URL). Do lištičky sice import dát jde, ale stejně je to pro každý refresh strašně pracné.

Zdravím. Locus umí Live Tracking, tedy odesílat pravidelně polohu někam na server. To je super a díky za to.

Takto získaná data není problém zobrazovat třeba na webu. Ale otázka je, jak takto získaná data zase prezentovat v Locusu. Tedy rád bych měl k dispozici opačnou funkci, kdy by si Locus z internetu (klasický HTTP dotaz z nastavitelné URL) tahal ve zvolených intervalech např. nějaké GPX a zobrazoval na mapě. Nebo třeba po rozsvícení displeje, na stisk tlačítka apod., aby to trochu šetřilo baterii. Prostě když se chci podívat na takto zaznamenaná data (jiných osob), která jsou uložená na serveru, aby to bylo snadno možné.

Prostě takový jednoduchý a zároveň univerzální systém pro sledování polohy. Univerzálnost by spočívala v tom, že dané GPX (nebo tak něco) by generoval server a mohl by to dělat z libovolných zdrojů, libovolným způsobem, ... Implementačně by to myslím nemuselo být složité. Co si o tom myslíš?

Nebo to lze nějak udělat již nyní?

http://az4n6.blogspot.com.es/2013/11/python-parser-to-recover-deleted-sqlite.html?m=1

Ahoj, automatická záloha mimo zařízení by se mi také velmi hodila. Uvítal bych možnost šifrování (pokud by šlo zálohovat jen na veřejné úložiště typu DropBox a nikoli třeba na privátní server), možnost zálohování jen při napájení ze sítě, inkrementální zálohování (po pár letech používání programu je těch dat celkem dost).

@Menion: "jen rozsah je nastaven na celý svět, tak je třeba najet na himaláje aby to bylo pořádně vidět" ... no právě, mě šlo o to, abych si udělal představu o terénu při plánování trasy v relativně rovinatých oblastech jako např. na screenshotu (výšky se pohybují v intervalu několika málo stovek metrů). A pro každou takovou výškovou zónu by bylo potřeba mít samostatnou mapu. Pokud ze SRTM dat generuješ překryvnou vrstvu se stíny, tak generovat z toho trochu něco jiného by mělo být poměrně snadné. Tedy máš tam zřejmě nějakou funkci, která generuje z výšky daného bodu a výšky bodu kousek vedle nějakou barvu. A celé toho je jen o změně této funkce, resp. její parametrizace dle nastavení. Po stránce výkonu by to bylo myslím také téměř stejné. Ale samozřejmě chápu, že pokud o tu funkci nebude mít zájem více lidí, tak to nemá smysl, abys to dělal. Mě už to tolik netrápí, protože si těch pár map pro výškové rozsahu, které mi vyhovují, předgeneruji.

A nebo ... možná bych mohl udělat Androidí aplikaci, která by se chovala jako webserver a generovala dlaždice na přání, přičemž do Locusu by se přidala jako online mapa. Akorát to bude znamenat ten webserver startovat a zase ukončovat apod. Nešlo by vytvořit API, přes které by šla napojit aplikace, která by generovala data do Locusu (dlaždice, POI body, trasy), tedy Locus by poslal request (např. pomocí Intents) zaregistrované aplikaci s informacemi o požadované dlaždici a aplikace by mu vrátila bitmapu a případně nějakou množinu POI či úseků tras, které se mají zobrazit? Tím by Locus šel pěkně rozšiřovat o mnoho různých zajímavých pluginů...

Jedná se o výškovou mapu vygenerovanou ze SRTM dat pro oblast nížin. Je to spíše ukázka, protože ideální by bylo, kdyby tohle uměl generovat Locus on-the-fly a s volitelným nastavením mapování rozsahu výšek na barvy. Pokud se namapuje škála přes velký rozsah výšek (třeba 0 m až 8000 m nad mořem), tak pak v oblasti malých výškových rozdílů je barva prakticky jednolitá a není tam nic vidět.

Jinak je to zobrazené jako překryvá mapa (overlay) nad klasickou mapou, průhlednost podle potřeby, mód prolnutí DARKEN.

Využití např. pro plánování trasy tak, aby se vyhnula velkým výškovým rozdílům. Z klasické mapy (i se stínováním) si lze jen těžko udělat představu o výškách. Takže zbývá vždy jen najet na určité místo a podívat se na výšku ... ale představa o terénu z toho moc dobrá není.

Ke stažení:
http://uloz.to/xEQMiFt7/height-overlay-cz-sqlitedb

Ukázka:


Pro srovnání SRTM stínování, které Locus umí:

Paměť by problém nebyl, ale výkon a spotřeba ano. Vem si, že normálně se na obrazovku vejde třeba 3x5=15 dlaždic, které je třeba načíst z disku, dekomprimovat typicky PNG a vykreslit. Pokud ale zmenšíš mapu na 25 %, tedy každá strana dlaždice bude mít 25 % původní velikosti, k vykreslení obsahu obrazovky potřebuješ najednou (3*4)x(5*4)=240 dlaždic. A navíc je třeba každou dlaždici zmenšit. Pokud by se šlo ještě o jeden krok dále, bylo by třeba zpracovat (3*8)x(5*=960 dlaždic. Dlaždice se možné zpracovávat postupně (resp. třeba vždy pouze 4 najednou) a ukládat stačí výsledek, takže paměť by nebyl problém. Ale znamenalo by to velké množství IO operací (čtení z paměťové karty) a času CPU (a potažmo také energie z baterie). Tedy v reálu by to stejně nebylo moc použitelné.

Lepší je tedy toto provést na (oproti telefonu) výkonnějším počítači a hlavně pouze jednou a takto zpracovaná data uložit na paměťovou kartu. Tedy pro každý zoom (1x, 2x, 4x, 8x, ...) budou již připravené dlaždice standardní velikosti a vždy se jich bude zobrazovat na obrazovce např. těch 15. Navíc u prostého zmenšování je problém s tím, že když příliš zmenšíš různé objekty jako texty, čáry, ikony apod., tak jsou pak příliš malé a stejně nejsou vůbec vidět. Takže reálně se pro menší měřítka vytváří jiná mapa, která obsahuje méně informací, ale v dostatečné velikosti. Např. už tam nejdou jednotlivé ulice, ale jen schematicky celá města a jejich názvy.

U *.TAR map by mělo být možné použít i jinou projekci, ale osobně jsem to zatím nezkoušel. Někde tam musí být nějaká metadata, ze kterých Locus pozná tu projekci. Logicky pak nelze čekat, že půjde přes mapu umístit např. překryvná vrstva v jiné projekci (to by musel Locus deformovat bitmapy a to neumí a i kdyby to uměl, tak by to bylo strašně pomalé a nejspíše i ošklivé).

Obnovený link:
http://uloz.to/x2wNdHiQ/tar2sqlite-rar
(stejné heslo)

Díky, povedlo se