Wetterstationsforum.info - Archiv

Hi Fredy,

das wäre doch ein Anfang, es wäre doch bereits ein Fortschritt, wenn alle (viele) bspw. unter "tempa_c" die Außentemperatur in Grad Celsius ablegen würden oder unter "rel_huma" die relative Luftfeuchtigkeit der Außensensoren...

Das DB Schema kann ja jeder für sich gestalten, wenn zumindest die Feldnamen und evtl. die dahinterliegenden Formate auf das Import/Export "Format" passen.

Über deine Anmerkung zu den sich wiederholenden Informationen denke ich noch nach, weil ich (derzeit) denke das sich eine Weiterverwendung dann schon wieder etwas komplexer darstellt.

Aber grundsätzlich wäre eine Formatdefinition wie sie für verschiedene andere Verfahren existieren schon Klasse. So etwas wie XMeld als OSCI (Online Services Computer Interface). Sicherlich sind wir zu kleine um einen IT-Standard zu definieren, aber das Vorgehensmodell passt doch.   "XMeteodat"

Sicherlich hat der DWD doch ein Format, ob man das mal abfragt? Aktualisierung: Anfrage abgeschickt. Ich halte Euch auf dem Laufenden ob ich eine Antwort bekomme.

Hallo 24Online

Bin gespannt auf die Antwort.

In der Zwischenzeit hab ich mir so meine Gedanken gemacht. Mir gefällt die Idee eines Standard Formats. Sei es zur Archivierung oder zum Austausch zwischen Anwendungen und Anwender.

Ich habe, um meine Gedanken zu ordnen, mal ein Beispiel erstellt. (auf GitHub)

https://github.com/fredyfire/openWeatherStationData

Hier nur mal nur so als Idee, ein Beispiel wie so etwas aussehen könnte:
https://github.com/fredyfire/openWeatherStationData/blob/master/example1.js
(als Test mal in JSON abgebildet)

Nachtrag: Wobei ich hier etwas vom Thread-titel abdrifte. Falls das Thema auf Resonanz stösst, evtl. in einem neuen Thread weitermachen.

Nachtrag 2:
Hier ein Beispiel möglicher Feldbezeichnungen:
https://github.com/fredyfire/openWeatherStationData/blob/master/valueDescriptions.txt


Bitte erweitern, ändern, oder komplett verwerfen

Grüsse Fredy

Nachtrag 3:
Projekt umbenannt in "openWeatherStationData".

Hallo 24Online,

die Überlegungen dazu finde ich sehr elegant und die Aufteilung (in der decriptions.txt) hat schon was für sich. Leider ist es aber auch so, dass Du kaum alle (wenn nicht einen einzigen) Hersteller dazu begeistern könntest, auf ein neues Ausgabeformat (ich nehme an, weiterhin .csv) umsteigen zu wollen.

Das Format .csv beinhaltet nach wie vor eine Reihe von Einschränkungen, weil international keinerlei Regelung darüber besteht, WIE Zahlenformate dargestellt werden oder welches Listentrennzeichen verwendet werden soll.

So arbeiten die .csv-Formate in DE, obwohl wir in Deustchland leben, meist mit "." als Dezimaltrenner bei Zahlen und mit "," als Listentrenner. Der Abschluss einer Datenzeile mit CrLf ist klar geregelt, aber dazwischen darf jeder machen, wie er denkt.

Da sicherlich über 2/3 der Weltbevölkerung einen Dezimalpunkt "." verwenden, ist das in weiten Kreisen verbreitete "Dezimalkomma", wie z.B. bei uns, ein gewisser Fehlerfaktor, weil es häufig auch als Listentrennzeichen verwendet wird.

Man müsste hier, ähnlich wie bei dBase, ein Abkommen treffen, dass als Dezimaltrenner bei Zahlen stets "."  verwendet wird. Stattdessen könnte auch "," erlaubt sein, dann müsste der Listentrenner aber eindeutig als Semikolon ";" definiert sein oder auch durch "TAB" oder ein anderes Steuerzeichen ersetzt worden sein können. ".csv" macht da keine Vorschriften!

Die Idee selbst ist nicht übel - die Hersteller haben aber bereits ihre eigenen Standards definiert.

Deswegen finde ich das Vorgehen von WsWin, sich auf alle möglichen .csv-Formate einzustellen, wenn man deren Datenformat mal verstanden hat, sehr anwenderfreundlich.

Man nimmt das, was man bekommt und wandelt es in die eigenen Anforderungen um - ist doch schon ein wenig elegant! Da wird man wohl auch über weitere Jahrzehnte nicht drumherum kommen.

Ein abgewandeltes Standardformat (orientiert an möglicherweise sogar gut durchdachten Strukturen) wird es so schnell nicht geben. Das Format "dBase" war mal über Jahrzehnte so ein gewisser Standard, bei dem jetzt leider neue Herausforderungen nicht mehr gewartet werden. Ein dBase mit "echtem" Zeitstempel würde das Problem als einfachste Alternative bereits lösen, da dort Feldinformationen bereits in der Datenbank verankert sind, gleich wie man Felder benennt oder welches Zahlenformat verwendet wird. Bei .csv weiß man nie, was wo steht, wenn es nicht im Header definiert ist. Dass eine .csv beliebig viele Header-Zeilen haben kann, ist aber auch bekannt - die allgemeingültige Auswertung diesbezüglich also schwierig.

Ein "dBase" mit erweiterten Felddefinitionen könnte das komplette Problem bereits lösen, wenn man statt der ASCII-Darstellung von Zahlenwerten auch DateTime, Float, Double oder Integer (8/16/32/64 Bit) zulassen wollte. Aber an dBase macht ja keiner mehr was ...

Also - das Ziel in allen Ehren - ich bin und bleibe mehr als skeptisch ...

Gruß Hans

@Fredy: WOW, genau so habe ich mir das vorgestellt. So wären wir schon zwei Nachfolgend noch vier Ergänzungen zum Format "OpenMeteoData". Zwar in XML-Format aber das kannst du ja ändern.

<solar_radiation>0</solar_radiation>
<UV>0.0</UV>

<wind_dir>NW</wind_dir>
<wind_degrees>314</wind_degrees>

@TheWeather: So hoch wollte ich doch gar nicht hinaus, dass Hersteller ihr Format von CSV in andere Formate ändern. Ich denke einen "userdefinierter Standard" reicht doch völlig. Da CSV-Dateien ja leicht zu mappen sind, könnte man dies ja auch tun wenn man Daten tauschen möchte. Zumal es sicher nicht schwer ist, für bestimmte Ursprungsformate entsprechende Automatismen zu bauen.

Ich würde mir bei Zeiten mal das passende XML-File " OpenMeteoData-XML" vornehmen.

  bei aller Begeisterung,

ein Konzept taugt nur, wenn es sich auf breiter Front umsetzen lässt. Das sehe ich momentan leider noch nicht.

Nur weil man sich Feldnamen und Definitionen einer zugehörigen Datenbankstruktur ausdenkt, ist damit noch niemandem gedient. Wäre es in irgendeiner Weise kompatibel zu Excel, Access, .csv, .dbf oder anderen Datenbank-Formaten oder gar serverbasierend zu MySQL? Da müsste doch dann als nächster Schritt sofort ein Tool her, welches alle Formate in das neu erdachte konvertiert oder zurück. Damit wäre man wieder dort, wo WsWin bereits jetzt ist, nämlich einigermaßen bekannte Formate in ein "eigenes" zur Bearbeitung umzuwandeln.

Es gibt hunderte von komprimierten Bildformaten (z.B. .tif, .pcx, .bmp, .jpg, .tiff, .jpeg, .png, ...), ein Standard scheint noch lange nicht gefunden ... Wer "alles" lesen kann, ist hier klar im Vorteil. Wer nach Bearbeitung nur als .jpg, .jpeg, .png oder .bmp speichert, orientiert sich an Standards und damit kann man an allen Ecken und Enden unbesorgt weiter arbeiten.

Ein Programm, welches jedes Format lesen kann, hat doch sicherlich mehr Anhänger, als ein neues Format, an welches man ohne Spezial-Tools gar nicht erst ran kommt ...

Aber euer Engagement in allen Ehren - ich lasse mich gerne überraschen ...

Gruß Hans

Hi TheWeather,

ich würde das zunächst nicht so hoch hängen, da wir ohne Konzept, über eine Datenstruktur / Feldbezeichnungen reden, das den Austausch von Messdaten dienen soll/könnte.

Ich denke (und vielleicht auch nur ich), das man in einen Umfeld, wo sehr sehr viele kluge Köpfe agieren, sich das Leben ein wenig einfacher machen könnte und die ohnehin eingesetzte Energie bspw. für die Programmierung einer Webseite oder dem Daten Import/Export dann halt auch nachhaltig nutzen kann. Ich bin Realist und glaube nicht daran mit so ein paar Gedanken die Welt verändern zu können, aber jeder der auch nur ein Skript zum Errechnen der WindChill-Temperatur geschrieben hat, kann sich doch fragen warum dieses nicht auch von anderen genutzt wird.

Ich übergebe die Daten meines (bisherigen) XML-Files übrigens an ein Skript zum Einfügen in eine mysql-Datenbank und werde es sofern es dazu kommt einen benutzerdefinierten Standard zu entwickeln und abzustimmen (mehr als 2) auch anpassen und bereitstellen. Dokumentation inkl.

Wie gesagt, die Idee (ist m.E.) ist kleiner angesiedelt als es sich vielleicht anhört. Aber auch ein weiter Weg beginnt mit dem ersten Schritt...

Zitat von: TheWeather am 04.02.2014, 19:51:09
Damit wäre man wieder dort, wo WsWin bereits jetzt ist, nämlich einigermaßen bekannte Formate in ein "eigenes" zur Bearbeitung umzuwandeln.

Servus,
leider ist es genau so.
Was man machen könnte wäre ein Tool, welches auf einfach bedienbare Weise ein beliebiges CSV- Format in ein WSWIN- lesbares "Universal"- CSV- Format wandelt, welches man dann nicht nur in WSWIN verwenden könnte, sondern auch standardisiert in eine DB importieren könnte.
Dass man Werner Krenn evt. überzeugen könnte, bei WSWIN eine "Standard- WS" dafür einzubauen, könnte ich mir evt. vorstellen. Bei den Herstellern würde das Kopfschütteln hervorrufen.
Als "Standard" könnte man aber auch gleich Davis hernehmen, da hier vermutlich alle Eventualitäten abgedeckt sind (Zusatzsensoren, etc.)

Hi,

Zitat von: 24Online am 04.02.2014, 20:09:20
... Aber auch ein weiter Weg beginnt mit dem ersten Schritt...

Ja, nö, iss klar!

Als Spielerei hab' ich mir auch schon so manche Gedanken um alles Mögliche gemacht. Meines Erachtens "Alles geht - nichts muss".

Ich habe ja schon angedeutet, dass ich der Entwicklung mit Spannung entgegen sehe, meine Skepsis aber auch nicht verheimlicht. Nun warten wir einfach mal ab ...

Gruß Hans

Hallo,

ich verwende für die Speicherung der Wetterdaten eine mysql-Datenbank. In der gibt es 6 Tabellen, welche sich in zwei 'Gruppen' aufteilen.

Zwei Tabellen ('curr' und 'minmax') speichern die Daten direkt von der Wetterstation. 'curr' enthält die Daten im Einminutenintervall, wie sie von der Station kommen. 'minmax' speichert die Extremwerte von einem Tag, welche ebefalls von der Wetterstation kommen - ist eine Vantage Pro, wo man die Minmax-Werte seperat auslesen kann.

Die restlichen 4 Tabellen werden regelmäßig per Script aktualisiert und speichern die Daten wie sie für die Webseite gebraucht werden.
'day' speichert die Tagesdaten, 'month' die Monatsdaten, 'year' die Jahresdaten und 'alltime'  die Werte seit Aufzeichnungsbeginn.
Alle 4 Tabellen in dieser 'Gruppe' haben einen fast identischen Aufbau. Für jeden Meßwert gibt es drei Felder: Minimum, Maximum und Mittelwert entspr. der Zeitspanne. Wo es keinen Sinn macht, lasse ich den Min/Max-Wert weg, zB kein Minimum bei der Windstärke.
Nur das Datum ist bei den einzelnen Tabellen unterschiedlich, vorallem, um Speicherplatz zu sparen. Bei 'day' ist es der Datentyp 'Date', bei 'month' Integer berechnet aus Jahr+10000*Monat, bei 'year' und 'alltime' ein Integer. Bei 'alltime' ist das Datum aber Banane, da die Tabelle immer nur einen Datensatz enthält, ich mir aber eine Sonderbehandlung sparen möchte.

Zu Sicherungszwecken werden die Daten auch in Textdateien geschrieben (feste Satzlänge).

Hallo 24online,

<xml> halte ich für eine sehr guten, modernen Ansatz, um Daten von A nach B zu transferieren - allerdings komplett überladen für die eigentliche Aufgabenstellung. <xml> leitet sich in groben Zügen aus <html> ab und mag sinnvoll sein, wenn man <xml> relativ einfach in <html> einbinden möchte.

Zur Übergabe von Daten ist es aber dennoch nicht sonderlich gut geeignet, da der Übernahme in eine Datenbank ein <xml>-Parser vorgeschaltet sein müsste, der die ganze Syntax erstmal analysiert, bevor ein Datensatz dort landet, wo er letztendlich hin soll.

Es geht letztendlich immer um die Übernahme von Daten, die "irgendwo" her stammen und "irgendwo" hin sollen, z.B. nach Datum indiziert in eine Datenbank. Es ist ein nettes Merkmal, wenn man Daten bis zur eigentlichen Transformation in eine neues Format oder eine Datenbank solange verfolgen kann, bis sie dort mit Windows-Bordmitteln so einfach nicht mehr nachvollziehbar sind. Insofern ist auch <xml> geeignet, als man bis zum Schluss verfolgen könnte, welche Daten transportiert wurden.

Noch einfacher ist allerdings das aus früheren Zeiten bekannte .ini-Format, bei dem jeder Eintrag in einem ASCII-Editor ebenfalls lesbar bleibt, der Aufbau aber wesentlich zielstrebiger ist.

Da hat man z.B.:

[Temp_Int]
Temp_Int = 10.5
Humi_Int = 56

[Temp_Ch1]
Temp_Ch1 = 9.2
Humi_Ch1 = 37
...



Das ist platzsparender, steht aber einer Auswertung in <xml> in keinem Punkt nach. Ganz im Gegenteil - es ist wesentlich schneller und wesentlich einfacher strukturiert und in einem einfachen Editor (wie z.B. Notepad) nach wie vor lesbar.

Die Daten in einer solchen .ini, .dat, .pre oder wie auch immer man sie nennen möchte, lassen sich mit einem einfachen Parser in jedes beliebige (lokale) Datenbank-Format einlesen - ob .dbf, .csv, .mdb spielt dabei nur eine untergeordnete Rolle, MySQL entzieht sich meiner Kenntns, da noch nie verwendet.

Ob man die Daten dann (je nach [Header]) binär, als Int, Int32, Int64, als Dezimalwert, als Float oder Double oder sonst irgendwie in der Datenbank ablegt, spielt keine Rolle mehr, solange man sie mit dem umgekehrten Algorithmus auch wieder 1:1 zurück holen (lesen) kann.

Das Hauptaugenmerk gilt sicher der angestrebten Datenbank-Struktur, welche auf der einen Seite stets erweiterbar sein sollte, auf der anderen Seite aber auch mit minimaler Struktur (z.B. nur einem einzigen Temperatur-Wert) funktionieren sollte.

Auch wenn das früher "verkehrt" rüber gekommen sein sollte, ist es nicht meine Absicht, einen möglichen Erfolg anzuzweifeln. Es geht lediglich darum, dass zu einer eigenen Datenbank-Struktur auch eine ordentliche Übergabe dorthin und ebenfalls zurück gehört, die natürlich bei einem "neuen" Format zunächst kein anderer unterstützt. Es wäre eine nette Idee, damit ein eigenes Monopol aufzubauen, allerdings würde das kein leichter Weg ...

Ich möchte lediglich meine Zweifel anmelden - eine Idee ausreden wäre nicht in meinem Sinne.

Gruß Hans