Speichern von Lösungen für Mystery- und Multi-Caches

Nachdem wir irgendwann mal die ersten Rätselcaches gelöst hatten kam die Frage auf: „Sollen wir die Lösungen eigentlich irgendwo aufheben?“

Na ja, einmal geloggt braucht man die Lösung für sich selber eigentlich nicht mehr... aber vielleicht hat mal irgendwann ein befreundeter Cacher eine Frage zu dem Cache? Oder, was bei uns öfters vorkommt, wir Lösen ein paar Mysteries in Aachen und Umgebung, fahren da aber erst in ein paar Wochen (zum Loggen) hin.

Also wurde die eingangs gestellt Frage mit „Ja, wir heben die Lösungen auf!“ beantwortet. Nächste Frage: „Und wie?“ In Papierform = Zettelwirtschaft sicher nicht. Also Computer-affine Menschen lag da das Speichern in digitaler Form natürlich am nächsten.

Zwischeneinwurf:  Im Gegensatz zu den meisten anderen unserer Blogeinträge wird es nachher ziemlich technisch... Also keine Sorge, wenn man eventuell irgendwann nicht mehr folgen kann - könnte sein, je nach eigenem Wissen und Interessenlage zu dem Thema :-)

Gut, also per Computer. Dann kommt die nächste Frage: „Und wie auf dem Computer?“ Hm... Die Daten sollten auf PC, Tablet und Smartphone gleichermaßen einsehbar und gut durchsuchbar sein, wenn man mal gezielt nach bestimmten Kriterien filtern will. Und natürlich soll es flexibel sein, was die Datenstruktur angeht.

Textverarbeitung? Nicht unbedingt ideal in Bezug Cross-Plattform Nutzung und auch suboptimal, was die Durchsuchbarkeit und besonders Filterbarkeit angeht.
Tabellenkalkulation? Beim Suchen und Filtern sicherlich brauchbar, aber in Bezug auf die problemlose Nutzung auf verschiedenen Plattformen eventuell problematisch. Auch auch die Flexibilität führt eventuell zu ziemlich großen (=breiten oder langen) Tabellen.
Relationale Datenbank? Sicherlich top, was Suche und Filterbarkeit angeht, aber zu viel „Overhead“, zumindest bei großen Datenbanken mit Server-Client Architektur. Und generell das Problem, dass man zum Befüllen üblicherweise noch eine Benutzeroberfläche braucht (wer will schon viele Daten via Kommandozeile eingeben?). Und die Cross-Plattformnutzung ist - außer mit der Datenbank SQLite - auch problematisch.

Also fiel die Wahl am Ende auf JSON (=Java Script Object Notation), ein text- basiertes „lightweight data-interchange format“. Weitere Vorteile von JSON sind, dass die Daten gleichermaßen gut für Menschen als auch Maschinen (=Computer) lesbar sind. Und: JSON verstehen so gut wie alle Programmiersprachen, so dass man die Daten einfach einlesen und verarbeiten (wie z.B. zwecks Suche und Filterung) kann.
CouchDB, die Datenbank welche wir zur Speicherung der Daten der von uns gelegten Caches nutzen, setzt übrigens auch auf JSON als Datenformat, aber das nur am Rande.
Im Internet werden auch viele Daten zwischen Server und Client als JSON Daten ausgetauscht. Das läuft aber in der Regel im Hintergrund und transparent für den Nutzer.

Wie sehen denn jetzt solche JSON Daten aus? Erst Mal ist das eine ganz normale Textdatei, wie man sie mit jedem Editor erstellen kann. Somit lassen sich JSON Dateien auch ziemlich problemlos darstellen, und zwar auf allen Plattformen. Moderne Browser können z.B. auch JSON Daten lesen und direkt lesbar formatiert im Browserfenster darstellen.

Technisch gesehen besteht JSON aus Objekten in Form von Schlüssel-Werte Paaren. Außerdem kennt JSON noch Arrays, was man umgangssprachlich als Liste bezeichnen würde. Auf Arrays gehen wir hier aber nicht weiter ein (zumal wir auch keine Arrays für das Speichern der Mystery-Lösungen brauchen).
Die Objekte - und auch Arrays - dürfen weiterhin verschachtelt werden. Mehrere Objekte und Arrays hintereinander werden mit einem Komma separiert.

In unserem Fall speichern wir jede Lösung in einem einfach verschachteltem Objekt: der Schlüssel ist die GC-Nummer des Caches (oder - wenn opencaching.de ist - natürlich die OC-Nummer), der Wert ist wiederum ein Objekt, welches verschiedene Schlüssel-Werte Paare wie Cachename, Antworten, Ort, geloggt? enthält.

Klingt kompliziert? Ist es aber nicht. Ein Beispiel dazu:

{
"GC123AB":
    {
        "name":"Beispielcache",
        "typ":"Unknown Cache",
        "antworten":"A=1 - B=7 - C=3",
        "final":"N 50°24.123 E 007.55.456",
        "log":false
        "ort":Kleinbeispielhausen"
    }
}

Wenn man es sieht ist es eigentlich recht anschaulich. Die geschweiften Klammern { } umschließen ein Objekt. Schlüsselnamen und Werte werden in Anführungsstriche gesetzt, sofern es nicht nur eine Zahl oder ein Wahrheitswert (true oder false) ist.

Ein größerer Ausschnitt aus unsere Datei mit den Lösungen sieht so aus:

Die Datei speichern wir übrigens in einem Cloudspeicher, der sich automatisch auf alle für uns relevanten Geräte synchronisiert, so dass die Daten immer auch lokal verfügbar sind.

Soweit so gut. Speichern ist das eine, aber irgendwann sucht man sicherlich auch Daten. Je nachdem was wir Suchen gibt es zwei Strategien:

• Wenn nach einem bestimmten Cache / Cachernummer gesucht wird machen wir das mit der Suchfunktion innerhalb des Editors (bzw. wenn die JSON Datei im Browser geladen ist, mit der Suchfunktion des Browsers).
• Wenn die Suche komplexer ist wie z.B. „zeige alle nicht-geloggten Mysteries für den Ort Aachen“, dann liest ein kleines Python-Skript die JSON-Datei ein, schreibt die Daten in eine temporäre SQLite oder auch CouchDB Datenbank, in der dann die Suche an sich ausgeführt wird.

Letzteres geht wie eingangs bereits erwähnt auch mit den meisten anderen Programmiersprachen, da diese so gut wie alle JSON Daten Lesen können.

Mit diesem Vorgehen fahren wir bis jetzt sehr gut. Und alle von uns gestellten Kriterien werden erfüllt. Wobei wir natürlich nicht behaupten, dass dies der ultimative Königsweg ist. Wer andere Ansprüche hat bzw. den Schwerpunkt vielleicht auf anderen Kriterien legt, für den gibt es sicherlich auch bessere, alternative Wege.

Ach ja: Lösungen, Antworten und Koordinaten von geloggten Multis speichern wir i.d.R. auch ab, wie auch im obigen Beispiel zu sehen ist.

Und falls jetzt jemand (vielleicht zurecht) einwirft: „Und was ist mit GSAK?“ Geht soweit wir wissen auch, aber unsere Rechner laufen nicht unter Windows noch haben wir eine Windows-Lizenz, um Win in einer virtuellen Maschine zu betreiben. Abgesehen davon würde GSAK nicht das von uns gestellte Kriterium der Multi-Rechner Verfügbarkeit der Daten erfüllen... :-)