Je uz dostatocne zname, ze garmin zobrazi len prvych cca 8000 znakov z listingu.
MoZiGo, ale asi aj ine programy to riesia rozdelenim listingu a vytvorenim "fantomoveho wpt bodu".
Inou moznostou v mozigo je export listingu ako obrazok…
Pre uplnost doplnim o moznost exportu ako GPXPOI …
Podarilo sa mi najst uplne iny sposob ako uvedeny problem relativne jednoducho vyriesit…
Chcem poprosit o otestovanie na viacerych listingoch a trebars aj na roznych garminoch - ja mam G550 a skusal som to na par listingoch a vypada to slubne…
Povodny export gpx a garmin colorado ostal v mozigo nedotknuty a na tento novy je na obrazovke exportov do gpx samostatne tlacitko…
Zatial to je nastavene na pevne cisla - 8000 znakov, jednoducho sa listing rozdeli do tolkych casti aby posledna mala menej ako tych 8000znakov.
Pls dajte vediet ako sa Vam export podaril/nepodaril…dakujem.
Mám k dipozici Magellan eXplorist GC a zkoušel jsem chování listingů, ketré nekorektně zobrazí Garmin v něm. Kupodivu s nima v mnoha případech problém neměl, ale přesto některé listingy nedělající problémy Garminu zase špatně zobrazil Magellan (překrývání částí listingů).
Je to myslím také ovlivněno i úpravou původního PQ gpx souboru v různých programech.
Mohl bych klidně něco ověřit, ale jsem pouze BM, takže jedině pokud mi někdo zašle listing na ověření.
Dik za ponuku, ale toto riesenie je site na garmin. S PQ nema nic spolocne.
Ale ked sme uz pri tom, tak moja skusenost s garminom je taka, ze je lepsie kvoli citatelnosti html tagy vyhodit uplne a ponechat len tie zakladne …
vycisti to listing od zbytecnyho html (ktery moje oregano stejne nezobrazi) a zaroven opravi cestinu zkonvertovanou do html entit (kterou oregon taky v nekterych pripadech nepobere)
Hmmm - ted jeste pro blby jako jsem ja, jak tim ten gpx soubor prohnat. A muze to byt cele PQ, nebo jen jeden listing. Jestli jsem mimo misu tak sorry.
jak jsem psal - s mozigem to nema nic spolecnyho, je to totiz jen kousek PHP, kterej pouzivam na http://gc.zlej.net
takze pro "normalni" lidi asi k nicemu
Ja jsem nevydrzel.
Vidim, ze davas kousky listingu jako falesne logy. To neni spatny napad. Dokonce jsem se o nem bavil uz v cervenci 2009 s HuntBehindem, ale tenkrat jsme ho zavrhli bez testovani. Kvuli hledani multin. Pokud clovek naviguje na waypoint (tedy ne na kes ani na "next stage") a chce si cist listing, tak muze bez zruseni navigace. Logy si ale bez zruseni navigace myslim neprecte a musi dat navigovat znovu na kesku, tam si precist logy a dat navigovat zpet na stage…
Ted si ale nejsem jist, zda se pri zobrazeni listingu kesky (na kterou se zrovna NEnaviguje) nahodou na konci listingu ty logy nezobrazi. A nemuzu to overit
Ono se to tezko popisuje, ale snad vis, o cem mluvim.
Co se tyka GC kodu vadnych kesi, tak je jich asi spousta.
Myslim, ze mi to urcite rezalo "Udoli mlynu" GC101D9 a i nejake dalsi. Mozna by stacilo si udelat select do db na kese, jejichz long description ma vice nez 8192 znaku
Dalsi vec co me napadla - co takhle rozdelit dlouhe listingy po cca 8000 znacich nejprve do short description a pak do long description a sledovat, jak se s tim garmin popere? To by mohlo taky vyznamne pomoct. Nicmene se zas bojim, ze narazime na jine podobne pitome limity i pro short description.
Reseni je asi spousta, ale protoze si exportuju kese stejne i jako POI, neresil jsem to. Pokud nahodou narazim v terenu na uriznuty listing, tak si ho proste prectu v POI.
Shortdesciption nejde pouzit..to som skusil uz davno.
Ale k logom sa to chova zaujimavo, pre kazdy log je mozne vyuzit tych cca 8000 znakov /nie je to 2^13/ ale menej…
Dokonca sa takto daju pribalit aj povodne logy , nezbadal som ziadnu komplikaciu.
Mne sa toto riesenie pozdava omnoho viac ako doterajsie delenie…
Pls odskusajte to na G300 resp. na Dakote ale podla mna to pojde pouzit vsade…
Prilozil som "Udoli mlynu" GC101D9 na otestovanie…
Podla mna short desciption je horsi napad kvoli tomu ze kopec kesiek pouziva short desc a potom no neriesi situaciu ozaj dlhych listingov, ktore maju viac ako cca 16kB
Pri pouziti logov take nehrozi…
No a, ze pouziva?
Co takhle strategie:
a) sloucit si do jedne promenne short + long z GPX/jineho zdroje
b) rozdelit to na celky po tech cca 8000 znacich (ja na vzorku par kesi zkousel, ze se 8192 znaku na UTF-8 vstupu zobrazi vzdy. nekdy i vic, ale zatim ani jednou min)
c) zacit jimi postupne plnit short, long. A pokud se nevejde, tak log za logem.
Ja s tim nevidim problem. Tedy pokud to funguje.
K logum bych pristupoval jako k posledni instanci, protoze je neskutecne otravne, kdyz clovek chce precist rychle posledni log (pres menu geocaching-logy), ale predtim by musel odscrollovat zbytek listingu.
stálo by za to udělat si statistiku kolik těch listingů je delších než 16kB
možná že to nebude až tak moc a tak by na logy došlo opravdu jen v pár případech
To at si kazdy uz naimplementuje do svych softwaru po svem
zLOSTe, nechces jeste ozkoumat i nejaka dalsi omezeni garmina? Max pocet logu, max delka jednoho logu, max delka jmena kese … vicemene max delka jakehokoliv tagu v GPX?
