c:geo / Opencaching

[Blindmulch]

Mahlzeit !

Besteht eigentlich die Möglichkeit, c:geo mit Daten ( .gpx ) von Opencaching zu füttern ? Oder gibt es auch hier einen " Connector " ? Habe schon danach gegoggelt, aber nichts wirklich profundes gefunden.

Ludger

 

[SammysHP]

Speziell für OC ist c:geo nicht entwickelt, man kann die GPX-Dateien aber bestimmt konvertieren (was natürlich nicht so komfortabel ist).

 

[MaxED9]

Wohin sollte denn die standardkonforme OC-GPX konvertiert werden?

Als ich carnero darauf mal ansprach, war seine Auskunft, dass c:geo GC-Wegpunkte in der GPX erwartet und daher OC-GPX-Dateien zwar ohne Fehlermeldungen eingelesen, aber die Informationen übersprungen werden.
Damals sagte er aber auch, dass er irgendwann vor hatte auch das zu implementieren, vermutlich ist das jetzt hinfällig.

Aber es gibt ja auch noch andere Programme, die das können.

 

[GeoSilverio]

Wobei das ja nicht sooo schwer zu implementieren sein sollte.
Der Aufbau der GPX ist ja fast identisch nur die XML-Tags sind eben manchmal anders benannt.
Du kannst die OC-GPX evlt. in GSAK einlesen und dann von dort wieder exportieren, evtl. gehts dann schon.

Ansonsten GeOrg, da gibts im Market zusätzlich auch einen speziellen Opencaching-Connector, der die OC-Caches direkt laden kann.

 

[MaxED9]

Ansonsten GeOrg, da gibts im Market zusätzlich auch einen speziellen Opencaching-Connector, der die OC-Caches direkt laden kann.

Immer wird gleich GeOrg empfohlen .
Ich gehe aber mal davon aus, dass Blindmulch c:geo verwendet, weil es kostenlos ist.

Eine ebenfalls kostenlose Alternative wäre ja auch Columbus und das ist auch mein favorisiertes Programm.
Es ist auch bei großem Datenbestand noch fix, man kann in der Kartenansicht schnell zwischen unterschiedlichen Karten wechseln (Google/OSM usw,), Onlinesuche nach Caches bei GC und div. OC-Knoten und es kann natürlich auch deren GPX-Dateien einlesen.

 

[GeoSilverio]

Naja, jeder empfiehlt hals das, was er kennt.
Columbus kenne ich nicht, deswegen kann ich es nicht "empfehlen". Das hat ja nichts damit zu tun, dass es nicht gut wäre.
GeOrg kenn ich, hat mein Sohn und ist auch ganz zufrieden.
Ich selbst nutze Cachebox, das ist für Android aber noch nicht erhältlich, kann somit ja auch nicht als Empfehlung gelten, auch wenn der Import von OC-GPX dort funktioniert.

 

[ElCid68]

Dann werfe ich auch noch was rein. Mit Locus (auch mit der freien Version) kann man wunderbar OC-GPX Daten importieren und danach auch vernünftig lesen.

 

[SammysHP]

Ich habe ja so ein paar Ideen für c:geo. 90% davon kann man in die Rubrik "Code aufräumen" packen, unter anderem Separation des Spiderns in ein extra Package und minimalem, generischen Interface. Das würde bedeuten, dass man ähnlich wie mit dem Connector unter GeOrg operieren kann. Genauso könnte man auch den GPX-Import auslagern, sodass er einfach zu erweitern ist und somit auch andere Plattformen unterstützt. Generisch muss allerdings auch die Cache-Daten-Speicherung sein, momentan ist das ziemlich eklig implementiert und ist kaum erweiterbar.

Letztendlich würde alles auf ein riesiges Copy&Paste-Massaker und Neuschreiben des Codes hinauslaufen, mal schauen, wer sich dafür freiwillig meldet.

 

[jennergruhle]

Ich hätte ja schon Bock mitzumachen, aber konnte c:geo noch nicht zum "Alles-Durchkompilieren" in Eclipse bringen. Will ich in den nächsten Tagen noch nachholen. Wie und wo speichert c:geo überhaupt Cachelistings und Bilder? Habe noch nichts dazu finden können. Mein Traum wäre ja noch ein Synchro Cachewolf -> c:geo. GPX-Export aus CW und Import in c:geo geht schon recht gut, aber man muss immer mühselig aktualisieren, um auch wieder alle Bilder drin zu haben.

 

[SammysHP]

Binärdaten liegen in /sdcard/.cgeo, Einstellungen und Cache-Daten liegen in der Android-DB (was ich allerdings wegen der Geschwindigkeit gerne ändern und optimieren würde).

 

[ra_sch]

Letztendlich würde alles auf ein riesiges Copy&Paste-Massaker und Neuschreiben des Codes hinauslaufen, mal schauen, wer sich dafür freiwillig meldet.

Ich würde mich durchaus daran beteiligen, das ganze zu refakturieren. Bisher hatte ich hauptsächlich im map-code und ein bisschen in den settings zu tun. Da gibt es durchaus 'historisch gewachsenes' das man wieder vereinheitlichen und straffen kann.
Bin aber der Auffassung dass sowas am besten gelingt, wenn man zu mehreren eine neue Stuktur herausarbeitet.

gruß
ra_sch

 

[SammysHP]

Bin aber der Auffassung dass sowas am besten gelingt, wenn man zu mehreren eine neue Stuktur herausarbeitet.

Ich arbeite da mit ein paar Freunden an einem umfangreichen Framework. Bisher haben wir 200-300 Seiten Dokumentation und keine einzige Zeile Code, aber seit einigen Monaten fehlt uns allen die Motivation. Aber ja, es bringt unheimlich viel, wenn man alles vorweg plant.

Wäre schön, wenn du dich mit daran beteiligen möchtest. Ich werde mir jetzt in der vorlesungsfreien Zeit mal etwas den Code anschauen und dann können wir ja ein paar Ideen sammeln (wo, auf welcher Plattform? Ich hatte schon so einige Kolaborationsplattformen für den eigenen Server getestet, aber bin zu keinem Fazit gekommen. Vielleicht ein Wiki sowie einen Jabber-Conference-Server/Channel, ggf. auch Mumble oder Ähnliches).

 

[ra_sch]

Bin aber der Auffassung dass sowas am besten gelingt, wenn man zu mehreren eine neue Stuktur herausarbeitet.

Ich arbeite da mit ein paar Freunden an einem umfangreichen Framework. Bisher haben wir 200-300 Seiten Dokumentation und keine einzige Zeile Code, aber seit einigen Monaten fehlt uns allen die Motivation. Aber ja, es bringt unheimlich viel, wenn man alles vorweg plant.

Wäre schön, wenn du dich mit daran beteiligen möchtest. Ich werde mir jetzt in der vorlesungsfreien Zeit mal etwas den Code anschauen und dann können wir ja ein paar Ideen sammeln (wo, auf welcher Plattform? Ich hatte schon so einige Kolaborationsplattformen für den eigenen Server getestet, aber bin zu keinem Fazit gekommen. Vielleicht ein Wiki sowie einen Jabber-Conference-Server/Channel, ggf. auch Mumble oder Ähnliches).

Ganz so hoch wollte ich das sicher nicht hängen, mehr so dass man eben sich kurz abspricht, welche Bereiche man ausgliedern und refakturieren will und kurz skizziert, welche Funktionen dort hin gehören und welcher Name ausreichend abgrenzend und beschreibend ist. Overengineering muß wirklich nicht sein.
Wiki klingt gut, ansonsten habe ich nur Erfahrung mit ICQ, eventuell kann man ja auch einen IRC-channel aufmachen.