25 odpovědí na toto téma

[JirkaF]

Ahoj, objevil jsem takový poměrně hodně šikovný udělátor na PDA. Asi ho už znáte http://www.nicque.com/PQz/GCz.htm. A teď se pokouším do něj exportovat data z GeoGeta. Používám typ exportu Pocket Query GPX. Nějak se to nedaří.

Jak jsem koukal, tak origo GPX z GC.COM obsahuje tohle

<wpt lat="48.662033" lon="15.950317">
    <time>2006-12-27T00:00:00</time>
    <name>GC100QN</name>
    <desc>Crosses along ancient ways - Wegkreuze #1 by SFBF, Multi-cache (1.5/1)</desc>
    <url>http://www.geocaching.com/seek/cache_details.aspx?guid=b432d4b3-5607-428c-bc47-374409ca8bea</url>
    <urlname>Crosses along ancient ways - Wegkreuze #1</urlname>
    <sym>Geocache</sym>
...

ale GeoGet tam přidává jakési další věci

<wpt lat="48.662033" lon="15.950317">
  <time>2006-12-27T00:00:00.000</time>
  <name>GC100QN</name>
  <desc><![CDATA[Crosses along ancient ways - Wegkreuze #1 by SFBF (1.5/1)]]></desc>
  <url><![CDATA[http://www.geocaching.com/seek/cache_details.aspx?guid=b432d4b3-5607-428c-bc47-374409ca8bea]]></url>
  <urlname><![CDATA[Crosses along ancient ways - Wegkreuze #1 by SFBF]]></urlname>
  <sym>Geocache</sym>
  <type>Geocache|Multi-cache</type>

...

Problém je v tom <![CDATA[ . Koukal jsem do toho makra, ale nějak se mě to nedaří odstranit. Nevíte někdo co s tím ? Případně jaký jiný export použít ? Origo GPX z GC.COM to bere bez problémů.

[HaLuMa]

Pokud GCz nebere ty CDATA elementy, pak je chyba jednoznacne na jeho strane. Kazdy validni XML parser to musi umet precist. takze bych doporucil kontaktovat autora GCz s prosbou o opravu.

[Parkis]

Dneska jsem resil totez s autorem GCz a prakticky okamzite to opravil. Bude to v nektere blizke verzi, pripadne lze najit opraveny exe ve foru na xda-developers: http://forum.xda-dev...&postcount=1739

Zustava ovsem problem v tom ze GCz ocekava aditional waypoints v oddelenem souboru stejne jako v originalnim PQ. Uz jsem zkousel tuto problematiku dopoledne nakousnout v tomhle vlakne :http://www.geocachin...160#post_150160

[HaLuMa]

Na namixovanem souboru neni take nic spatneho. Kdyz si clovek stahne GPX z listingu, tak tam take ma kesku i waypointy v jednom souboru.

[Parkis]

ja nerikam ze je to neco spatneho ale proste v PQ je to jinak a tak se to snazim nejak uzpusobit

[JirkaF]

Dík všem za info. Jen poznámečka. A není škoda, že jinak tak výbornej program, jakým GeoGet bezesporu je, nedokáže vyrobit skutečně 100% GC.COM PQ GPX soubory ?

[HaLuMa]

Ale dokaze. Jen to dosud nikdo nepotreboval, takze to nikdo ani nenapsal. V makrech, jakychkoliv, muzes pracovat se soubory, tedy je i vytvaret. V principu jde o to, ze waypoint by se neposilal na vystup exportniho makra, ale do nejakeho tveho docasneho souboru. A v ExportEfter, kdy je ti sdeleno i jmeno exportovaneho souboru, jej prejmenujes na finalni jmeno.

[Parkis]

HaLuMa napsal/a:
Ale dokaze. Jen to dosud nikdo nepotreboval, takze to nikdo ani nenapsal.

V makrech, jakychkoliv, muzes pracovat se soubory, tedy je i vytvaret. V principu jde o to, ze waypoint by se neposilal na vystup exportniho makra, ale do nejakeho tveho docasneho souboru. A v ExportEfter, kdy je ti sdeleno i jmeno exportovaneho souboru, jej prejmenujes na finalni jmeno.

To je presne to co jsem potreboval vedet, diky
Odpoledne se na to mrknu

[JirkaF]

A-há. Tož to se omlouvám. Když já k těmhle těm programovacím věcem mám takový nic moc vztah. Parkisu, jestli se ti to podaří, měl bych velikou prosbu, jestli by jsi se o to se mnou nepodělil.

[HaLuMa]

Na zapisovani do toho druheho souboru je nejlepsi vyuzit sluzeb objektu TFileStream. Ale chce to trosku vedet objektove programovani. Jednodussi cesta je to syslit do globalni stringiove promenne a pak to vyklipit do souiboru pres funkci StringToFile. Akorat toto je pomalejsi a exportovana data se drzi v pameti.

[hplus]

A definitivne posledni otazkou pak zustava, jestli se tohle vsechno vyplati - oproti tomu zaplatit si bud pausal na data a pouzivat GCz online (pripadne stahnout data doma pres kabel/wifi) a nebo PM a stahnout si "opravdovy" PQcko. (Ale ja vim, do technickyho vlakna takovy otazky nepatrej.)

[brazajar]

hplus napsal/a:
A definitivne posledni otazkou pak zustava, jestli se tohle vsechno vyplati - oproti tomu zaplatit si bud pausal na data a pouzivat GCz online (pripadne stahnout data doma pres kabel/wifi) a nebo PM a stahnout si "opravdovy" PQcko.

(Ale ja vim, do technickyho vlakna takovy otazky nepatrej.)

(Ale ja vim, do technickyho vlakna takovy otazky nepatrej.)
Mne by se to hodilo treba na to, ze bych do GCz naladoval v gpx vylusteny mysterky...

[Parkis]

hplus napsal/a:
A definitivne posledni otazkou pak zustava, jestli se tohle vsechno vyplati - oproti tomu zaplatit si bud pausal na data a pouzivat GCz online (pripadne stahnout data doma pres kabel/wifi) a nebo PM a stahnout si "opravdovy" PQcko.

(Ale ja vim, do technickyho vlakna takovy otazky nepatrej.)

Pausal na data mam, ale offline je nutnost do zahranici. V tuzemsku zase chci mit v exportu i spoctene finalky mysterek, coz mi PM nevyresi.

[medwyn_cz]

To je jednoduche: reknete gechovi, ze jeho program neumi zatim nacitat po jednom stahovane GPX z GC.com. Jakmile prida podporu k tomuhle, bude fungovat i PQ z geogetu. Jinak teda doprogramovat ten export do GC.com praveho formatu je zalezitost tak na patnact minut. Ale ve slusnych programech musi fungovat stavajici format. Proc nefunguje v GSAKu je mi zahadou...

[JirkaF]

Dneska jsem si s tím GCz delší dobu hrál a asi mě nějak uniká jeho logika. Když mám 10 GPX vygenerovaných z GC.COM tak při použití GPX Import mě udělá 10 keš listů. Jenže já chci jeden list. Nevíte jak na to ? A další věc, když jsem si pomocí GeoGetu a pak i GSAKu z těch 10 GPX udělal jeden velikej s cca 530 kešema, tak mě vždycky po importu napsal, že jich načetl jen 500. Počty waypointů byly úplně mimo. Tak nevím jestli to importuje blbě, nebo počítá blbě a nebo je tam nějaký limit 500. No napsal jsem mu to na GCz fórum. Uvidíme kde je problém.

[Parkis]

Tak jsem neco splacal. dle prvnich testu to celkem funguje. Bohuzel to asi Gech neopravil vsude, takze v souboru s waypointy stale nefunguje konstrukce s CDATA. Prozatim jsem to vyresil jejim odstranenim a prevedenim vsech specialnich znaku na HTML elementy. Akorat mam dojem ze to misty zmrsi diakritiku (napr. š).
Pokud ma nekdo chut to dotahnout do konce (a treba prepsat s pouzitim tridy TFileStream jak psal HaLuMa), budu jen rad Ja se k tomu dostanu zas nejdriv pristi tyden.

viz priloha, staci umistit do datoveho adresare

EDIT: priloha se nechce vlozit, tak tady: http://gc.parkis.net...xpq-gcz.gge.zip

[HaLuMa]

Opakuji, CDATA je napsrosto standardni XML prvek, a kazda paliakce si s tim musi poradit. je to jistejsi a mnohem rychlejsi nez zakodovavat elementy. Navic, pokud si pamatuji dobre, dneska tu bylo receno, ze GCz bylo opraveno, aby CDATA zvladalo. Takze mi prijde zbytecne se s timto mordovat, ne?

[Parkis]

HaLuMa napsal/a:
Opakuji, CDATA je napsrosto standardni XML prvek, a kazda paliakce si s tim musi poradit. je to jistejsi a mnohem rychlejsi nez zakodovavat elementy. Navic, pokud si pamatuji dobre, dneska tu bylo receno, ze GCz bylo opraveno, aby CDATA zvladalo. Takze mi prijde zbytecne se s timto mordovat, ne?

Vsak se s tebou nikdo nehada Holt to asi neopravil vsude, budu ho jeste uhanet. Zas takovy mordovani s tim hromadnym replacem z cdata na HtmlEntityEncode nebylo Ale holt zitra odjizdim a potreboval jsem to mit vyexportovany, toz asi tak.

[HaLuMa]

Proc enodujes HTML entity, kdyz staci kodovat jen XML entity? tedy XmlEntityEncode?

[Parkis]

HaLuMa napsal/a:
Proc enodujes HTML entity, kdyz staci kodovat jen XML entity? tedy XmlEntityEncode?

Protoze tomu prd rozumim a moje programovani funguje na principu pokusu a omylu