Standard - Datenbankschema für Wetterdatenaufzeichnung

[24Online]

Hallo Forum.

existiert eigentlich ein als Standard zu bezeichnendes Datenbankschema für das Ablegen von Wetterdaten in einer Datenbank. Insbesondere interessieren mich natürlich die Bezeichnung der Datenfelder und die Art Datentyp. Also bspw. die aktuell gemessene Temperatur in Grad Celsius speichert man in dem Datenfeld "temp_c" das als "Integer X.X" oder "decimal X.X " angelegt ist.

Vielleicht kann ja auch jemand der so etwas hat ein entsprechend leeren mysql-Export anbieten.

Gruß 24Online

[leknilk0815]

Servus,
soweit mir bekannt ist, gibt's da kein Schema, da es auch kaum Wetterstationen gibt, die eine DB verwenden. Einziges mir bekanntes Programm mit Datenbank ist von ELV das unsägliche Datenmonster "Weatherprofessional", das die Daten in einer PostGres- DB ablegt.
Darüber braucht man sich keine Gedanken zu machen, weil WP und PG dann die "Alleinherrschaft" über den PC beanspruchen, daher benutzt das praktisch niemand mehr.
Als Standard würde ich bei Wetterstationen CSV bezeichnen. Damit kann man fast mit allen Stationen arbeiten. Aber auch hier gibt's kein einheitliches Format, WSWIN z.B. beherrscht zwar viele Formate, aber auch nicht alle.
Um mit Datenbanken zu arbeiten, müsste man sich also zuerst mal mit dem Import von CSV nach DB befassen.

[Fredy]

Hallo

Ich verwende in mysql, datetime für datum/zeit und decimal für die Werte. Integer würde aber weniger Speicherplatz benötigten. Man müsste dann die Werte mit zb. 10 multiplizieren, da Integer ja nur Ganzzahlen zulässt.

(Siehe auch mein Tutorial Wetterdaten und Datenbanken: http://wetterbinningen.blogspot.ch/p/tutorials.html )

Grüsse Fredy

Nachtrag: Zahlenwerte in MySQL
http://dev.mysql.com/doc/refman/5.1/de/storage-requirements.html

Nachtrag 2: Datum/Zeit in Mysql
Man könnte auch timestamp verwenden. Braucht weniger Speicher, ist aber beschränkt auf 1970-2037.
Siehe:
http://dev.mysql.com/doc/refman/5.1/de/datetime.html

[wneudeck]

Hallo Online24,
zunächst: es gibt hier keinen Standard
Ich übertrage die wswin-Daten (nicht alle, nur die, die ich brauche) in eine mysql-Datenbank, die so aufgebaut ist wie im screenshot gezeigt. Das einzige Problem ist die Struktur des Datums, da ich es so verwende, wie im Feld 'Datum" gezeigt, WSWIN mir aber das Datum in einem anderen Format liefert. Aber das kann man ja alles anpassen. Zum Import verwende ich übrigens die von WSWIN automatisch erzeugte Datei ws_newdata.csv

[gelöscht durch Administrator]

[Fredy]

Ich habe Datum und Zeit nicht getrennt. So kann man die datum/zeit Spalte auch als "unique" oder gleich als Primärschlüssel verwenden. So werden doppelte Einträge effektiv verhindert. Auch allfällige Joins sowie Sortierungen lassen sich darüber etwas einfacher realisieren. Einen Zusätzlichen Primärschlüssel braucht man dann nicht.(weniger Speicherplatz)

Grüsse Fredy

[wneudeck]

Hallo Fredy,
das ist richtig, aber es hat 2 Gründe ( bei mir): In meiner ws_newdata.csv (Datenlieferant) werden Datum und Zeit getrennt angeboten und ich hätte, als ich die Datenbank damals entwarf, auch noch kiene Möglichkeit gefunden (Kenntnisse), dies entsprechend umzuformen.
Aber wenn jemand neu anfängt, ist es sicher so besser, wie Du vorschlägst

[Werner]

@Toni,

Als Standard würde ich bei Wetterstationen CSV bezeichnen. Damit kann man fast mit allen Stationen arbeiten. Aber auch hier gibt's kein einheitliches Format, WSWIN z.B. beherrscht zwar viele Formate, aber auch nicht alle.

Welches CSV-Format kann Wswin nicht ?

Werner

[leknilk0815]

Welches CSV-Format kann Wswin nicht ?

Servus Werner,
...da hab ich mich vielleicht missverständlich ausgedrückt.
CSV heißt ja nur, daß die einzelnen Daten durch Komma oder Semikolon getrennt sind.
Die Anordnung der Daten ist je nach Wetterstation unterschiedlich, wie z.B. zwischen Davis und TFA.
In WSWIN sind halt "nur" einige gängige Stationen eingebunden, somit kann WSWIN auch nicht alle "Formate" (Stationen) bedienen. Der Begriff "Format" ist hier natürlich nicht unbedingt korrekt.
Eine Konvertierung ist jedoch prinzipiell kein großes Problem, mit einer kleinen DOS- Batch ist das schnell erledigt, oder eben mit einer angepassten Importfunktion einer Datenbank. Ob nun die Aussentemperatur von ID 1 oder von ID 33 kommt, ist egal, solange sie in der Datenbank dann unter z.B. "Aussentemp" richtig eingeordnet wird.

[24Online]

Hallo Forum,
zunächst erstmal vielen dank für die vielen Antworten, so macht der konstruktive Austausch Spaß.

Aus meiner Sicht ist es wirklich Schade, das es hier keinen Standard gibt, denn so zeichnet jeder für sich  selbst auf und wenn man mal eine Auswertung erstellen möchte, und erhält eine Reihe von Aufzeichnungen anderer so ist zunächst ein aufwändiges Mapping erforderlich.

Als ich im Dezember (als Geschenk meiner Frau, sie wusste nicht was sie damit anrichtet) eine Wetterstation bekommen habe, wollte ich natürlich nicht all zu viel Zeit ins Land gehen lassen und habe schnell das notwendige programmiert. Ich habe ein HP1000 die die Messdaten ja zunächst zu Wunderground schiebt. Die Möglichkeit lokale Server als Exportziel einzugeben funktioniert nicht oder ist schlecht dokumentiert. Versuche dies hinzubekommen habe ich auch Grund der mir selbst gestellten Aufgabenpriorisierung nach hinten gestellt. Also greife ich meine eigenen Daten die ich zuvor zu Wunderground geschickt habe über die XML-API per PHP wieder ab. Diese XML-Datei verwende ich dann für die Anzeige auf meiner Wetterseite. Gleichzeitig werden diese Daten aber auch in zwei mysql-Datenbanken geschrieben. Eine liegt bei meinem Webseiten-Hoster die andere lokale auf einem NAS das auch einen Webserver mit mysql-DB bereitstellt. Entwicklung zu Hause (lokal), Veröffentlichung beim Hoster. Die Datenbank beim Hoster wird ab und an von Altdaten befreit. Die lokale Datenbank speichert alle Daten langfristig. (Speicherkapazität kostet ja nichts mehr.) Im Dezember habe ich also ein mysql-Datenbank-Schema erstellt (eindimensional) um möglichst wenig Daten zu verlieren . Diese Daten verwende ich derzeit nur zu Erstellung der Tagesverlaufsgrafiken. Bevor ich also PHP-Skripte bastle die irgendwann vielleicht mehr und öfter auf diese Datenbank zugreifen, wollte ich gerne auf diesen abgefragten (leider nicht existierenden) Standard umdesignen. Das wären zum heutigen Zeitpunkt nur wenige PHP-Skriptanpassungen (Inserts und selects). Da mein Schema mit der heißen Nadel gestrickt ist, würde ich vor einem Umbau nicht zurückschrecken.

Vielleicht sollte man ein "wetterstationen.info - Datenbankschema" entwickeln, dass zunächst eine Reihe von Standardfeldbezeichnungen festlegt, aber die Ergänzungen offen lässt.

Also ich speichere bspw. auch identische Informationen wie bspw. die Position und Höhe etc. in jedem Datensatz mit ab, um die Verwertbarkeit für Andere zu ermöglichen ohne Rahmeninformationen zu dem Datenexport mitgeben zu müssen. Ich habe derzeit keine Anfragen oder wirklichen Vorstellungen was da kommen könnte, aber die Basis dafür wäre gegeben und nicht durch ein proprietäres Schema verbaut oder nur durch ein aufwändiges Mapping realisierbar.

Viele Grüße
24Online
 

[Fredy]

Hallo

Ich würde ein standard Import/Export "Format" begrüssen. Jeweils für csv, xml und json. So könnte man relativ einfach Daten austauschen, ohne immer neue mappings erstellen zu müssen.
Ein db-design sollte aber m.M. immer an die spezifischen Anforderungen angepasst bleiben.

Grüsse Fredy

Nachtrag: Daten wie Stationshöhe, Ort, Hersteller, Toleranzen etc. würde ich separat speichern. Macht nicht wirklich sinn, das in jedem Datensatz abzulegen. In der Datenbank sollte sowas in eigener Tabelle gespeichert und dann verknüpft werden. (Join)