-
Willkommen im Geoclub - dem größten deutschsprachigen Geocaching-Forum. Registriere dich kostenlos, um alle Inhalte zu sehen und neue Beiträge zu erstellen.
Export zw. DB, gefundenen Caches nicht einfach löschen?
- Ersteller Timo TA93
- Erstellt am
Nein, falsch verstanden. Innerhalb von ACB sollen gefundene Caches wahlweise gelöscht oder in eine andere (in ACB existierende) DB (vorzugsweise namens Funde) verschoben werden. Damit hat man seine Wegepunkte, Notizen, Variabblen etc für den Fall der Fälle, daß man danach gefragt wird oder man sie nochmal benötigt.
Das Problem hatte ich kürzlich auch:
In einem Gebiet will/soll ich einen Event-Cache legen, da gibts aber auch noch einen Multi in diesem Gebiet. Hat man keine Notizen mehr kann man ja nur den Multi nochmal machen um die Stationen zu finden um zu wissen wo kann ich eine Station dazwischen packen...
Aber lies doch bitte noch mal die ersten Beiträge dieses Threads
Das Problem hatte ich kürzlich auch:
In einem Gebiet will/soll ich einen Event-Cache legen, da gibts aber auch noch einen Multi in diesem Gebiet. Hat man keine Notizen mehr kann man ja nur den Multi nochmal machen um die Stationen zu finden um zu wissen wo kann ich eine Station dazwischen packen...
Aber lies doch bitte noch mal die ersten Beiträge dieses Threads
Noch ein mal... es sollte eine rein ACB interne Funktion sein!
Beispiel:
In ACB hat man eine DB die "Homezone" heist, mit der geht man cachen...
Man findet Caches, markiert sie als gefunden und nach dem Upload der Fieldnotes hat man schließlich die Wahl, ob sie über "Lösche Caches" -> "Lösche Gefundene" einfach gelöscht werden oder sie über "Lösche Caches" -> "Archiviere Caches" in eine andere DB namens "Funde" verschiebt und somit alle persönlichen Einträge der betreffenden Caches später noch zur Verfügung hat.
Beispiel:
In ACB hat man eine DB die "Homezone" heist, mit der geht man cachen...
Man findet Caches, markiert sie als gefunden und nach dem Upload der Fieldnotes hat man schließlich die Wahl, ob sie über "Lösche Caches" -> "Lösche Gefundene" einfach gelöscht werden oder sie über "Lösche Caches" -> "Archiviere Caches" in eine andere DB namens "Funde" verschiebt und somit alle persönlichen Einträge der betreffenden Caches später noch zur Verfügung hat.
Koblenzer
Geomaster
Der Hintergrund ist zumindest bei mir, dass ich vorhandene Datenbanken der unterschiedlichen Gebiete öfters neu erzeuge (GSAK-Export) und daher alle vorher vorhandenen selbsterstellten Infos weg sind. Außerdem möchte ich mir nicht in mehreren DBs meine Funde zusammensuchen, wenns denn mal gebraucht wird. Daher die Idee einer Archiv/Fund-DB. Idealer Weise noch mit Overlay über die gerade geladene DB ;-)
cacheboxer
Geomaster
Ist zwar nicht dass, was sich Timo gewünscht hat - sollte IMHO aber Priorität haben, da sich auch Anwender von GSAK und anderer Tools darüber freuen würden, man damit sein Garmin befüllen könnte und auch Timos Anwendungsfall mit einem zumutbaren Zwischenschritt abbildbar wäre.Homer-S schrieb:
cacheboxer schrieb:
Der Export von GPX aus ACB-DB`s ist doch eine völlig andere Baustelle
Welches Garmin läßt sich bitte mit Daten aus ACB heraus füttern? Das geht mangels Blauzahnschnittstelle möglicherweise erst ab Garmin Oregon6x0, die haben als einzige Garmins Blauzahn4.0 ... und sooo weit ist halt ACB noch nicht.
Natürlich wäre das auch wünschenswert
In diesem Thread sollte alles außer ACB mal außer Acht gelassen werden. WCB nutzt nicht jeder, GSAK hat man wie WCB unterwegs auch nicht dabei und Cachewolf ist "nur" ein Pedant zu GSAK auch wenns auf Handy läuft (dort heißt das dann GDAK)
cacheboxer schrieb:
Zum Thema Garmin schrieb ich bereits ... Aber:
Mein Anwendungfall wäre mit deiner Idee noch nicht gelöst. Wie auch? GSAK und ACB "reden" nur über GPX miteinander, aber eben nur in einer Richtung (GSAK-Export).
Bei jedem Import/Export zwischen verschiedenen Programmen besteht immer die Gefahr von Datenverlust aufgrund inkompatibler Datenstrukturen.
SDF ist nicht DB3 und db3 ist nicht gleich DB3, versuch mal einer eine DB von ACB in GSAK zu öffnen oder umgekehrt. Beide verwenden *.db3
cacheboxer
Geomaster
Sag ich doch: Es wird ein GPX-Export aus ACB gebraucht, um die andere Richtung abbilden zu können.Timo TA93 schrieb:
Dein Anwendungsfall (schau mal auf's Topic) hatte übrigens nichts mit GSAK zu tun. Es ging da um eine ACB-DB mit gefundenen Dosen.
Verstehe nicht, was diese Info sagen soll und wie Du jetzt auf SDF und db3 kommst. Natürlich ist db3 nicht gleich db3 und xml nicht gleich xml. Natürlich wäre es aber möglich, mit GSAK direkt in das ACB-db3-Format zu exportieren oder in GSAK aus ACB-db3-Daten zu importieren. Es müsste sich nur jemand die Mühe machen, ein entsprechendes GSAK-Makro zu bauen.Bei jedem Import/Export zwischen verschiedenen Programmen besteht immer die Gefahr von Datenverlust aufgrund inkompatibler Datenstrukturen. SDF ist nicht DB3 und db3 ist nicht gleich DB3, versuch mal einer eine DB von ACB in GSAK zu öffnen oder umgekehrt. Beide verwenden *.db3
Den meisten Nutzen für die meisten ACB-Anwender würde aber ein GPX-Export in ACB bringen. GPX ist die Lingua Franca der Dosensucher - was auch immer an Datenaustausch gewünscht ist, lässt sich damit realisieren.
Auch Dein Anwendungsfall ließe sich damit über einen zumutbaren Zwischenschritt machen: Du exportierst Deine Funde ich eine GPX und importierst sie dann in Deine Funde-DB.
Ich werbe hier doch für einen GPX-Export. Damit könnte man ein Garmin füttern. Aktuelle Smartphones und Tablets können als USB-Host fungiere und erkennen das Garmin als Massenspeicher.
@ cacheboxer,
wovon reden wir hier eigentlich
Von einem Verschieben eines Caches innerhalb von ACB von einer DB in eine andere oder von einem reinen GPX-Export (wie in CB auf WM6.5)
Das sind zwei völlig getrennte und unabhängige Baustellen!!
Ich glaub ich brauch einen Sponsor, um mir eine Ausbildung zum Android-Programmierer finanzieren zu lassen Wenn ich das allein hinbekäme, würde Longri nen Patch erhalten und das Ding wär drin ...
Zwischenwege sind draußen im Feld (gerade wenn man mal längere Zeit unterwegs ist) nicht wirklich akzeptabel. Wer schleppt schon immer sein Schlepptop mit sich rum (irgendwo muß der Name Schlepptop ja auch herkommen
). ACB könnte es, wenn nicht immer nur diskutiert und alles zerredet würde.
http://forum.geoclub.de/viewtopic.php?f=114&t=70045
Da steht doch alles zu deinem Wunsch
wovon reden wir hier eigentlich
Von einem Verschieben eines Caches innerhalb von ACB von einer DB in eine andere oder von einem reinen GPX-Export (wie in CB auf WM6.5)
Das sind zwei völlig getrennte und unabhängige Baustellen!!
Ich glaub ich brauch einen Sponsor, um mir eine Ausbildung zum Android-Programmierer finanzieren zu lassen
Wenn ich das allein hinbekäme, würde Longri nen Patch erhalten und das Ding wär drin ...Zwischenwege sind draußen im Feld (gerade wenn man mal längere Zeit unterwegs ist) nicht wirklich akzeptabel. Wer schleppt schon immer sein Schlepptop mit sich rum (irgendwo muß der Name Schlepptop ja auch herkommen
). ACB könnte es, wenn nicht immer nur diskutiert und alles zerredet würde.http://forum.geoclub.de/viewtopic.php?f=114&t=70045
Da steht doch alles zu deinem Wunsch
GeoSilverio
Geowizard
Ich verstehe das Hin und Her nicht.
Gewünscht wird:
1. Exportmöglichkeit von Caches aus der ACB-DB (und vielleicht auch WCB), als GPX
2. Möglichkeit, Caches in ACB mit all ihren Attributen, Werten, manuellen Eingaben, Solver-Daten (wahrscheinlich auch Images und Spoiler) etc. im laufenden Programm in eine Zweit-DB zu transferieren.
Ich würds in den Tracker schreiben und hoffen.
Punkt 1 stelle ich mir mit Fleißarbeit recht gut Umsetzbar vor, Punkt 2 könnte an der Basis schon scheitern, wenn beispielsweise in sqLite nicht zwei Datenbanken parallel ansprechbar sind. Da kenne ich mich aber nicht gut genug aus.
Gewünscht wird:
1. Exportmöglichkeit von Caches aus der ACB-DB (und vielleicht auch WCB), als GPX
2. Möglichkeit, Caches in ACB mit all ihren Attributen, Werten, manuellen Eingaben, Solver-Daten (wahrscheinlich auch Images und Spoiler) etc. im laufenden Programm in eine Zweit-DB zu transferieren.
Ich würds in den Tracker schreiben und hoffen.
Punkt 1 stelle ich mir mit Fleißarbeit recht gut Umsetzbar vor, Punkt 2 könnte an der Basis schon scheitern, wenn beispielsweise in sqLite nicht zwei Datenbanken parallel ansprechbar sind. Da kenne ich mich aber nicht gut genug aus.
Zu Punkt 2 kann ich dich beruhigen. ACB nutzt im Normalbetrieb bereits 3 DB's gleichzeitig (Caches, Fieldnotes und Settings). Eine 4. wäre da sicherlich auch noch möglich, nochdazu wo diese ja nicht ständig geöffnet bleiben müsste.GeoSilverio schrieb:
Generell würde ich den Punkt 2 als weniger Aufwand betrachten als Punkt 1.
Beim GPX-Export hätte ich am meisten "Angst" vor Inkompatibilitäten mit allen möglichen Import-Programmen. Auch wenn GPX sowas wie ein Standard sein soll gibt es da anscheinend viel Interpretationsspielraum.
GeoSilverio
Geowizard
Ja, das stimmt wohl.Ging-Buh schrieb:
Man könnte höchstens, so sich denn jemand findet, der das implementiert, erst einmal nur und ausschließlich das Format von Groundspeak (GPX 1.1) nehmen. Nicht, dass das das "richtige" Format wäre aber wer damit nicht umgehen kann hat ja ohnehin ein gröberes Problem und kann auch alle anderen PQ von Groundspeak nicht importieren.