Hier haben wir uns die pragmatische Erhebung der verunschärften Ortsangabe einer Imkerei erschlossen.
Damit schließt sich der Kreis zu @mois’ ursprünglichem Beitrag.
Danke mal wieder!
Momentan ist die Annahme und die Verarbeitung von Orten weder in der Telemetrie noch in der Datenbank vorgesehen. Wir freuen uns, wenn wir hier mit Dir vielleicht gemeinsam den Anfang machen könnten.
Ich verschiebe den Gesprächsverlauf gleich mal woanders hin.
Dort dann bzw. einstweilen gerne hier weiter:
- Kannst Du Deinen übermittelten JSON payload noch ein wenig mehr aufbohren? Dann könnten wir das gleich dort übermitteln.
- Ah, Du machst ja das mit der PHP Weiterleitung (siehe Probleme beim Neustart der Bienenwaage im Mai). Gut, dann fügen wir kurzerhand einfach dort einen weiteren Parameter namens “geohash” hinzu. Bekommst Du das selbst hin?
nur zum verständnis: den trage ich dann fix ein und übermittle ihn jedesmal (alle 2 minuten oder so) mit?
ja, das würde ich hinkriegen.
Ja, genau. Weil: Warum nicht. Wir werden bestimmt auch andere Mechanismen zur Übermittlung des Meßortes entwickeln (einmalig, nicht jedesmal, etc.).
Aber in Deinem Fall wäre das die plausibelste Lösung.
… und ist gleichzeitig die generischste, wenn man an bewegliche Datenlogger denkt. Klar dass sich Dein Stock nicht bewegt, daher ist das Hartkodieren des einmalig ermittelten geohash Wertes direkt in die Telemetrie völlig in Ordnung.
hast du einen link/hinweis für mich, in welchem format ich das einbauen soll in mein skript?
An jener Stelle
einfach in den Telemetriedatensatz einsetzen à la
"geohash" => "u336q"
Have fun!
ok, ab sofort müsste der geohash mitkommen.
vielen dank mal wieder!
Ist das im Sinn von Bandbreite, später ggf. LoRa und auch Datenhaltung nicht suboptimal (oder auch völliger Quatsch), wenn wir an Ende tausende Datensätze mit den gleichen Daten haben, weil sie sich nie oder ggf. 2x im Jahr ändern??
Hi Clemens,
vielen Dank. Deine Argumente sind verständlich, aber keine Panik ;]. Ich versuche, gut auf Deine Punkte einzugehen.
Bandbreite
Bei dünnen Luftkabeln sollten wir redundante Informationen nicht jedesmal übermitteln, um sparsam mit den knappen Ressoucen umzugehen. Den Geohash bei anderen Übertragungsbedingungen anders zu übermitteln, ist kein Problem.
Datenbankschema
Ein normalisiertes Datenbankschema ist natürlich immer hilfreich, um Redundanzen zu vermeiden. Bei der Luftdatenpumpe haben wir das genau so umgesetzt, weil wir hocheffizienten Zugriff auf die Verschränkung von Zeitseriendaten mit Metadaten haben wollten.
Wie man die Sache auch dreht, es bleibt aber das eine Datum, mit dem man selbst im voll normalisierten Datenmodell die andere Relation referenziert, die die Geolocation-Entitäten enthält. Das kann eine eineindeutige Datenbank-ID (Integer) sein, muss es aber nicht: Der geohash (String) selbst tut es genauso hervorragend.
Das ist aus architektonischer Hinsicht sogar absolut wünschenswert, weil sich so die Datenhaltung wunderbar ins komplette Ökosystem einfügt: Das Grafana Worldmap Panel kann ebenfalls so arbeiten, dass es sich für die Darstellung von Punkten auf der Karte aus dem geohash-Feld der Zeitseriendatenbank bedient.
Ergo: Das ist also nicht ungewöhnlich, dass man die Geoposition denormalisiert in der Zeitseriendatenbank mit- und fortschreibt.
Unter Denormalisierung versteht man die bewusste Rücknahme einer Normalisierung zum Zweck der Verbesserung des Laufzeitverhaltens einer Datenbankanwendung.
Effizienz
Viele Speichereffizienzargumente fallen heutzutage meist in die Kategorie “premature optimization is the root of all evil”, wenn man es nicht gerade mit Datenmengen zu tun hat, für deren Bewältigung uns das Silicon Valley einige schöne Gerätschaften geschenkt hat –
– totally different story! Im Vergleich zu solchen Datenmengen sind wir mit der Bienenstocktelemetrie weit(!) darunter.
– http://wiki.c2.com/?PrematureOptimization
Ich hoffe das passt für Dich.
Viele Grüße,
Andreas.
¹ Hier fallen erstmal auch nicht-ganz-so-effiziente Dinge wie String als ID-Datentyp (geohash) nicht ins Gewicht. Erst ab einer Netzwerkgröße wie bei luftdaten.info müsste man sich ernsthaftere Gedanken machen. Das ist in weiter Ferne! ;]