Mikrom vystavil na svem webu novou verzi exportniho makra pro BeelineGPS (cest jeho praci, makro je docela fajn) kompatibilni s GG2. http://www.mikrom.cz/index.php?docs&file=78
Potykam se ale s urcitymi problemy pri naslednem importu do Beeline (nektere paznaky v listingu, & v nazvu kese atp.)
Existuje v makro jazyku nejaky efektivni zpusob, jak kese zbavit takovych bordelu pri exportu (nehledam zmenu listingu v db geogetu, to neni definitivni reseni (aktualizace atp)).
Problemove: [cache]GCW46N[/cache], [cache]GC179QB[/cache] - jde o ty paznaky v listingu.
Samozrejme jde provest urcita rucni editace. Ja ale casto pripravim doma gpx soubor a importuji do beeline treba az v terenu. Je strasne nemile pak zjistit, ze od treti kesky nejde soubor nacist protoze je tam vyprznene schema. V PDA nasledne soubor nejde rozumne editovat a kacerske odpoledne je v pytli
Nevim jestli Beeline bojuje s urcitou skupinou znaku ci s nejakym jednotlivym, zatim mi ho jiste zabijel tento:
Na jeden znak by asi pomohl i replace ve stringu, to je fakt.
Mikromovi se nektere problemy pomohlo vyresit pomoci zabaleni do UtfToAscii(), ale na ctverecek to nepomaha.
Napada nekoho pekne, efektivni reseni jak vyresit sproste exporty na veky veku?
PS: Ctverecek jsem poslal jako obrazek protoze byl schopen rozhodit i RSS na webu GG, viz zde
To jsou klasicke paznaky na konci short-description. U Groundspeaku maji nekde pri zpracovani na wbove stranky naalokovano na retezec vice bytu nez potrebuji a tak se na konec pridava nejaky nahodny obsah pameti. (Pri kazdem zobrazeni stranky tim padem jinak…) A dodnes to nebyli schopni opravit.
Geoget pri importu provadi ucesani alespon do takove miry, ze se v datech nevyskytuji invalidni sekvence znaku. To co proleze, jsou pak uz korektni UTF-8 znaky a s temi se tezko neco dela, nebot se strojove neodlisi od znaku, ktere se v textu mohou vyskytovat zcela legalne.
Tebe konkretne trapi ctverecek, ktery je ve skutecnosti znak s kodem ctyri. To je dokonce i korektni ASCII znak, proto prolezl i tim UtfToAscii. Problem je v tom, ze pokazde ten znak muze byt jiny. Zitra narazis na jiny znak, atd.
Jistym resenim by bylo ty importy do Geogetu jeste trosku vic ocesavat tak, aby se v textu nevyskytovaly ani tyto nepatricne ridici znaky. Takze tam maximalne zbydou paznaky, ktere sice nedavaji smysl, ale nemely by uz nic zborit.
Ano, jiste by slo tyto ridici znaky orezavat prim v makru (mas tam funkce na nahrazovani v retezci, na prochazeni retezce znak po znaku, atd.) ale pro tento ucel mi to prijde zbytecne pomale. Lepsi bude to orezat uz pri importu.
Jinak je tu jeste funkce AnsiToGPS, ktera pusti ven jen omezenou mnozinu znaku, ktera je primo podporovana GPS-kami. (Pred tim je potreba si prevest UTF na ANSI… priklad je v tom Garminim exportu.) To by na ty paznaky stacit, ale to je dobre tak maximalne na nazev kesky, listing to uz oreze asi moc…
Jenze dalsi penize se mi do geocachingu ted vkladat nechce. Musi me hrat vedomi, ze tak pomaham i nasledujicim generacim a diky mym pripominkam budujes lepsi a lepsi program.
Ale konec OT
Resim jeste jednu vec: jak v makru zkopirovat slozku nekam jinam? pripadne treba prejmenovat slozku (plnou souboru).
Zkousel jsem par moznosti, ale vetsinou to nejde prelozit a nebo to po prelozeni nefunguje.
Jsou tam zatim jen funkce pro pracis jednotlivymi soubory, pripadne vytvoreni adresare, ci hromadne mazani (podle masky), ale pro prejmenovani ci smazani adresare tam nic neni. Asi tam mohu neco pridelat.
Nepouzivam BeeLine, ale stacil mi letmy pohled na posledni zmeny: "upraveny informace waypointu, nyní nadm. výška, hodnocení, hint.."
Tak se to ucite lisi? Nebo tvoje PQ od Groundspeaku obsahuje treba nadmorskou vysku, nebo hodnoceni kvality? Obsahuje tvoje PQ od Groundpseaku treba tebou vypocitane finalni souradnice mysterek?
do listingu prida na zacatek poznamku co mate v geogetu
a ke vsem kesim a waypointum pridava <ele></ele>, takze kese a waypointy obsahuji nadmorskou vysku
XML Parse Error: Not well-formed (invalid token) at line 29
Soubor přikládám
a abych doplnil..export se "jakože" provede, ale nahlásí to jen jeden exportovaný bod (v příloze je gpx s jednou keší, ale testováno i s více)
když sem se do gpx souboru díval přes texťák, tak na řádku 29 je zrovna ta poznámka z GeoGetu
v20090616, definitivne dokoncena sekce s poznamkou, generuje se jen kdyz poznamka existuje, pokud je v poznamce odradkovani, tak se projevi, a kod je se zavrenejma ocima validni (tabulka v odstavci)
Konečně sem se dostal k tomu, abych odskoušel poslední verzi exportního makra a ejhle, Houstone máme problém…
Při generování Field notes je nežádoucí aby keška byla pojmenována jménem jak je tomu díky tomudle makru. Potřebuje to podle GC kódu Ještě že jsem odlovil jen dvě kabky. Jinak by mě braly mdloby
To je nalinkovane RSS ze zdejsich diskuzi.
