Standard - Datenbankschema für Wetterdatenaufzeichnung

[24Online]

Hallo Fredy,

also in der letztendlichen "Darstellung des OWSD-Formats" würde ich das auch entsprechend konsolidiert als "Datensatz" also zusammenhängend darstellen wollen. An dem Entwurf dafür im Wiki arbeite ich gedanklich noch. Bisher ist ja eher eine Erklärungs- und Arbeitsplattform zu sehen.

Das "ID_Nr" finde ich gut. Deine dargestellte "6" könnte man doch auch als Gruppenzurodnung verwenden, also bspw. die führende numerische Stelle mit "1" für Temperaturen, "2" für Niederschlag etc. die folgenden fortlaufend.

Zweisprachige (DE und EN) Darstellung finde ich auch gut. Jedoch sollten wir dann zwei "Datensätze" s.o. erstellen. Die Übersicht leidet sonst sehr.

....und mit den Nachkommastellen bin ich auch nicht verheiratet ...kommt ja auch ein bisschen auf die zur Verfügung stehenden Messgeräte an. Jedoch denke ich ist dies bspw. für die Einstellungen einer mysql-Datenbank hinsichtlich des auszuwählenden Typ (dezimal 10.1 oder int 2) nicht ganz unwichtig oder liege ich da falsch.

Die Grundlage für die Berechnungen wäre natürlich gut, aber ich weiß nicht, ob wir dann nicht versuchen die "eierlegende Wollmilchsau" zu basteln. Die vielen Informationen dazu im Netz sind ja teilweise sehr komplex dargestellt und eine Darstellung für Hobby-PWS-Betreiber (die nicht unbedingt Mathe-Leistungskurs besucht haben  ) wäre sicher toll. Hmm, ich weiß nicht, wann wollen wir den damit fertig werden  .

Ich werde deine Vorschläge mal ins Wiki einarbeiten wenn Du mir nicht zuvor kommst. Ich muss noch parallel an meinen Charts basteln, da sie bei dicht aneinander liegenden Werten die dynamischen Skalen (manchmal) falsch darstellen. In diesem Zusammenhang habe ich mich mal mit den von dir verwendeten amcharts beschäftigt. Diese Charts sind deutlich besser dokumentiert als die die ich bislang verwende.

Irgendwie müsste man über die typischen 24 Stunden eines Tages noch die Nacht nutzen können...

Nachtrag1: Achso, kannst du für die Aufgabe 2 auf der Diskussionsseite noch Werte für...

Gruppe (Vorschlag) "Luftbelastung/air_pollution"
...
...
Gruppe (Vorschlag) "Grundwasser/groundwater"
Grundwasserspiegel
...

beisteuern?

Nachtrag2: Wir könnten die ID um eine Sprachinformation erweitern bspw. ID: 6001_DE, 6001_EN ? Und dann die jeweiligen "Datensätze" beschreiben?

[TheWeather]

Hallo zusammen,

ich denke, es läuft ganz gut, wenn hier diskutiert wird und ihr federführend die Doku im Wiki nachzieht.

Bezüglich IDs (also z.B. die 6001) würde ich mit der Vergabe bis ganz zum Schluss warten, wenn der Bedarf an Nummernkreisen einigermaßen geklärt ist. Die Gruppeneigenschaften DE/EN würde ich zunächst auch nur in DE formulieren, Solange das Projekt am Wachsen ist und viele Dinge sicherlich noch überarbeitet werden müssen, ist es meist angenehmer, wenn man nur das notwendigste ändern muss und nicht gleich auch die Übersetzung(en) nachziehen muss.

Bei der Definition der  Sensor-Mnemonics (alo z.B. "temp_air_2m_c"), die ich soweit für gelungen halte, muss igendwie berücksichtigt werden, dass es nicht nur EINEN Sensor für eine spezielle Aufgabe geben kann, sondern auch mehrere, die zwar gleichartig sind, aber für verschiedene Aufgaben eingesetzt werden (Beispiel: Außenfühler für Temperatur/Feuchte, welche z.B. indiziert als "temp _out[1]...[N]_c bezeichnet wären oder als "humi_out[1]...[N]_%"), welche nicht speziell eingesetzt werden, sondern je nach Anwendungsfall im Keller, im Schuppen, im Gartenhaus, ... oder sonstwo untergebracht sein könnten. Denen einen eigenen Namen zu verpassen, würde wohl den Rahmen alles Vorhersehbaren sprengen. Per Deklaration könnte man festlegen, dass ein "temp_out_c" identisch zu "temp_out[0]_c" wäre, falls mehrere Indizees aufträten.

Die Grenzen sind nahezu von der Physik vorgegeben, hier würde ich keinerlei Beschränkungen vorgeben. Bei Temperatur (und Umweltdaten) gibt's wenigstens -273,15 °C, maximal schätzungsweise 373,15 K (100 °C), auch Angaben in °F würden also in diesen Rahmen passen. Bei Feuchte gibt's erst mal nur 0,0 bis 100,0%, bei vielen Angaben wie Luftdruck, UV-Index, Schadstoff-Konzentrationen und vielem mehr, sind ebenfalls physikalisch vorgegebene Grenzen gleichzeitig die Grenzen des Wertebereichs. Bei der beschreibung lassen sich natürlich Grenzen angeben ...

Bei der Auflösung eines Messwertes (also z.B. die Anzahl der zulässigen Nachkommastellen) besteht eher das Problem, keine künstlichen Beschränkungen im Datenformat zu implementieren. Wenn unserer gängigen Meinung nach 1/100 °C, also 2 NK-Stellen bereits ausreichen, sollte dennoch offen sein, auch z.B. noch Vielfache von 1/1000 °C abzubilden, ebenso bei Feuchte, bei der momentan selten Werte besser als 1/10 % r.F. erreicht werden, andererseits bei Präzisionsmessungen durchaus auch Vielfache von 1/100 % r.F. noch interessant sein könnten. 

Wenn man an verschiedene Darstellungseinheiten denkt (z.B. nur °C und °F), benötigen beide von vorneherein 3 NK, damit man sie verlässlich nach Umrechnunge auf wenigstens 2 NK abbilden kann. Gleiches gilt z.B. auch für Windgeschwindigkeitsmessungen in m/sec, km/h, mph, Knoten oder Bft. Da braucht's Luft im Aufzeichnungsformat, damit man problemlos ohne gravierenden Auflösungsverlust konvertieren kann.

Bei einem binären Format wie Float oder Double, welches mit 4 oder 8 Byte auskommt, spielt diese Überlegung fast keine Rolle. Wenn man allerdings dezimal (als ASCII-Code) speichert, müssen auch die Dezimalstellen von vorneherein festgelegt werden. Das geplante Aufzeichnungsformat spielt also auch eine erhebliche Rolle, was definiert werden muss und was nicht.

Es ist generell eine gute Idee, das Aufzeichnungsformat (in einer Datei) vom später wählbaren Darstellungsformat ab zu koppeln (Beispiel Excel).

Es wird sicher noch jede Menge Arbeit - hier nur meine ersten bescheidenen Überlegungen dazu.

Gruß Hans

[Fredy]

Hallo

ID:
Habe auch an eine ID, welche Gruppen Zugehörigkeit beinhaltet gedacht. (Und wie TheWeather sinnvoll anmerkte, sollten wir diese erst festlegen, wenn der Umfang einigermaßen ersichtlich wird)

Mehrsprachigkeit:
Zuerst alles in deutsch finde ich gut. Wie wir andere Sprachen dann am besten Abbilden, können wir ja auch später festlegen. (Die Idee mit "ID: 6001_DE" finde ich schon mal gut.)

Nachkommastellen/Zahlenformate:
Sehe ich wie theWeather. Würde hier, soweit es geht, keine Einschränkungen definieren. (Evtl. würde INTEGER/DECIMAL/TEXT oder sogar nur ZAHL/TEXT als Typenbeschreibung ausreichen.)

Im Sinne eines "Austauschformats", sollte es dann aber möglich sein, den tatsächlichen Inhalt eines Wertefeldes zu beschreiben. z.B. zwei Felder mit "Benutzerspezifischem" Inhalt:

ValueDataType = "decimal"
ValueDataFormat = "xxx.xxxx" oder "3,4"

Ein "Import/Export Script" könnte dann entsprechend darauf reagieren.


Feld für Berechnungsgrundlage:
Ich würde das ähnlich wie Quellenangaben abbilden. Also nicht die eigentlichen Formeln darin abspeichern. Aber dafür könnte ja auch die bisherige "Quelle" ausreichen.


"Benutzerspezifische" Sensoren:
Für unvorhersehbares, nicht vergleichbares, wie z.B. Temperaturen von Innenräumen, Gartenhäuser, Gartenteichen etc. würde ich einen eigenen (Namens)Bereich vorschlagen.

z.B. custom_temp_002 oder custom_0001 und entsprechend freie Beschreibungsfelder

Interessant ist die Frage in Bezug auf wirklich gleichartige Messungen. Also z.B. mehrere Aussen Temperatur Sensoren auf 2m Höhe. (z.b Referenz oder Backup Sensor).
"temp_air_2m_c[N]" ?
"temp_air_2m_[N]_c" ?


Grundwasser / Luftbelastung werde ich mal ins Wiki aufnehmen

Grüsse Fredy

[24Online]

Hallo Fredy, hallo theWeather,

schönen Dank zunächst für die vielen konstruktiven Beiträge . ich glaube wir sind auf einem guten und dadurch inzwischen etwas längeren Weg als gedacht. Deshalb habe ich die Aufgabe 1 zunächst mal als erledigt definiert und die Aufgabe 8 gestartet. Da es ohnehin eine regelmäßige Evaluierung geben soll, tut das ja keinen Abbruch wir müssen aber nur mal beginnen mit dem ersten Wurf.

Ich habe Eure Anmerkungen/Vorschläge mal direkt ins Wiki http://wiki.wetterstationen.info/index.php?title=Open_Weather_Station_Data eingearbeitet. Zudem hab ich auf der Hauptseite die Aufgaben entfernt und in die Diskussionsseite http://wiki.wetterstationen.info/index.php?title=Diskussion:Open_Weather_Station_Data eingefügt und erste Erläuterungen zu den inhaltlichen Beschreibungen hinzugefügt. Am Ende der Hauptseite würde ich nunmehr in Kürze eine Vorschlag zur Darstellung hinzufügen. Kreative Vorschläge gerne hier oder direkt im Wiki. Viele Grüße 24Online.

[TheWeather]

Hallo 24Online,

Du weißt ja aus Anbeginn der ersten Beiträge, dass ich eher skeptisch eingestellt bin.

Dennoch gefällt mir das analytische Vorgehen und die ersten Erfolge, welche daraus abgeleitet werden können.

Da es noch kein offizelles OWSD-Datenformat gibt, stellt sich zunächst auch die Frage, in welcher bereits bestehenden Datenbankstruktur es am besten unter zu bringen wäre. Ich denke, es wäre in Deiner Absicht, es in einer bisher weit verbreiteten Datenbank-Struktur (bislang scheint mir nur .mdb aus Office-Access dazu geeignet), unterzubringen. Nun ist .mdb nicht unbedingt dazu geeignet, leicht auswertbar zu sein, was ich aber ebenfalls als Prämisse zum Vorhaben verstanden habe.

MySQL oder SQL ist auch keine unmittelbare Lösung, da der notwendige Overhead unvermeidbar zu Akzeptanzproblemen führen wird, da die Lösung nicht filebasierend sondern nur serverbasierend  nutzbar wäre, was weiteren unnützen Overhead provozieren würde.

Ich kenne ehrlich gesagt kein Dateisystem, in welchem OWSD unmittelbar realisierbar wäre.

Ich könnte bei der Entwicklung eines solchen neuen Dateisystems behilflich sein, was vielleicht sogar andere Entwickler mit weiteren Vorschlägen auf den Plan ruft. Mir persönlich schwebt ein Datenbanksystem vergleichbar .dbf vor, welches natürlich neu entwickelt werden müsste und eventuell bei Dateien die Endung .owsd bekommt.

Da sowas (.owsd) mit üblichen Boardwerkzeugen keiner lesen kann, brauchts zumindest eine Konvertierung in .csv hin und zurück, die entsprechenden Tools müssten wahrscheinlich beigesteuert werden, um genügend Akzeptanz zu erhalten.

Ich erkläre mich zumindets bereit, an einer völlig neuen Datenbanklösung mitzuwirken, welche das owsd-Format filebasierend abbildet - inkl. .csv hin und zurück. Wie das dann umgesetzt würde, steht noch in den Sternen, aber machbar ist alles! Wunder brauchen etwas länger ...

Mein erster Vorschlag dazu: ein Header mit allen Nomenklaturen, danach die reinen Daten, allerdings nicht mehr ASCII-lesbar (z.B. via Notepad) sondern im Binärformat - das kann jeder Software-Entwickler leicht auflösen, wenn's einigermaßen gut dokumentiert ist. Den .csv-Import und Export hätten natürlich alle Anwender zur Verfügung, welche owsd lesen und wieder schreiben müssten.

Auch nur wieder ein Denkansatz ...

Gruß Hans

[24Online]

Hallo Hans,

zunächst mal Danke für die Blumen  , ich denke auch das wir schon gute Fortschritte gemacht haben und die Art und Weise der Diskussion hier wirklich zielführend ist.

Ich hatte ja in meinem ersten Thread eigentlich nur gefragt, ob es ein derartiges Format gibt und hatte eigentlich nicht die Absicht an einer Erstellung mitzuwirken. Aber wie die Jungfrau zum Kinde, sehe ich mich nun mit in der Pflicht, die nebenbei noch ausgesprochen viel Spaß macht.

Umso mehr freut es mich natürlich, wenn Du schon kreaktive Ideen hast wie die Akzeptanz und die Verwendbarkeit hergestellt werden kann (Danke dafür...). Denn da (hoffe und denke ich) gibt es hunderte Ansätze die man verfolgen kann.
Zu dem Gebiet "Abbildung in Datenbank oder Flatfile" kann ich derzeit nicht sonderlich viel beitragen , da ich zunächst meine zur Verfügung stehende (wirklich freie) Zeit auf die Ausarbeitung des Formats beziehen werde und zudem dies erst in der Aufgabe 9 sehen würde, die obwohl die Nummerierung keine Rolle spielen soll, doch zeitlich noch etwas weiter weg ist. Hast Du Dinge, die im Vorfeld diskutieren möchtest ist es trotzdem ja gut dies schon zu tun. Dann haben diese Ideen wenigstens Zeit, auch in der Community, zu reifen und durch zusätzliche Aktivisten auch noch besser zu werden.

Ich hatte eigentlich gehofft, das die doch relativ weit "unten angesiedelten Formatvorgaben" eine Chance in möglichst vielen Datenbanksystemen oder Flafiles haben.
Ich persönlich werde dieses Format dann nach der initialen Fertigstellung der Datenbezeichner in meiner mySQL-DB anwenden. Über den Overhead habe ich mir dazu bislang wenig Gedanken macht. mySQL läuft bei mir auf dem NAS mit und belegt eigene Speicher- und Rechenressourcen.
MS-Access finde ich persönlich zu unhandlich...und ist deshalb für mich keine Alternative. Zudem gesellt sich der starke Hersteller-, Betriebssystem- und Lizenzkostenbezug.
Eine extra für diesen Zweck programmierte Lösung sollte aus meiner Sicht betriebssystemunabhängig sein. Die dafür benötigten Kenntnisse in Programmiersprachen, was weiß ich C, C++ oder Java habe ich leider nicht. Deshalb muss ich in der Regel auf Lösungen zurückgreifen, die auf HTML, PHP und JavaScript basieren. Zur Ansteuerung dieser Skripte muss man dann noch ein wenig Shell-Skripting können. Also kurz gesagt aus der Eigenentwicklung bin ich raus und würde nur unterstützen wo ich kann.
Hah, ein XML-File nach OWSD-Format würde ich noch hinbekommen 

Also bei der Diskussion dazu, Hans wäre ich auf jeden Fall dabei. Programmieren kann ich so etwas nicht ansatzweise. Aber ich hoffe es finden sich noch Interessierte, die tatkräftig mitwirken.

Viele Grüße an alle Leser

Achim

[TheWeather]

Hallo Achim,

im Vergleich zu Apps sind ja beliebige Datenformate auf allen PCs lesbar. So ist es zumindest mit Dateien als .txt oder .pdf, welche jeweils sowohl von Win als auch von Mac unterstützt werden.

Ich bin der Überzeugung, dass das Festlegen von Strukturen einer geeigneten Datenbank auch bereits in die Planung einfließen sollte, um einen unnötigen Planungs-Overhead zu vermeiden.

Wenn es also bereits ein Format wie binär "Float" (4 Byte) oder "Double" (8 Byte) gibt, in welchem jeder beliebige Wert abgebildet werden kann, gleich ob es eine Ganzzahl oder ein Gleitkommawert ist, würde ich die binäre Umsetzung bevorzugen. Wer die Datei irgendwann auslesen sollte, weiß schon, wie er mit diesen Formaten umgehen muss. Platzssparender als binär geht einfach nicht.

Handicap ist natürlich, dass man die Datei noch nicht mal mehr annähernd noch in Notepad lesen könnte, weil da nur noch Hyroglyphen drin stehen - macht aber generell erst mal nichts, weil man selbst bei verbreiteten Formaten wie .doc, .xls, .mdb nichts anderes als Hyroglyphen erhält, wenn man sie mit einem "normalen" Editor öffnen muss.

Einen "owsd"-Reader oder -Writer zimmere ich in wenigen Minuten (fürs erste) zusammen, bis er dann wirklich taugt, werden schon ein paar Stunden drauf gehen - ist aber erst mal unerheblich. Für eine tabellarische Darstellung der Inhalte wären zunächst keine Grenzen gesetzt.

Man muss die Umsetzung von Vorstellungen immer ein wenig mit den bereits vorhandenen Möglichkeiten abgleichen. In diesem Fall (owsd) gibt's natürlich noch nichts Vergleichbares.

Es ist aber absolut unkompliziert, ein dafür geeignetes Datenbank-Format zu konstruieren, wenn erst mal die restlichen Definitionen dafür festgelegt werden konnten.

Auch wenn das Kapitel erst in Abschnitt 9 zum Tragen käme, macht es bereits jetzt Sinn, sich um Alternativen zu einem gängigen Datenformat vorzuknöpfen - kann einem zumindest jede Menge Arbeit ersparen ...

Gruß Hans

[24Online]

Hallo Hans,

ich bin voll und ganz deiner Meinung...Wir müssen nur aufpassen, dass wir uns die Akzeptanz und die Verwendbarkeit nicht durch eine zu komplexe Art der Nutzung oder zu enge Vorgaben "verbauen". Deshalb auch der Versuch bspw. nur Zeichen im Datenbezeichner zuzulassen die weitgehend überall (Zeichensätze und Sprachen) vorhanden sind.

Schreie also bitte laut, sobald wir eine Defintion innerhalb des Formats verschriften, welche genau diese Möglichkeiten des von dir Beschriebenen verhindert.

Gut das wir nicht mehr in Stein meisseln....
Gruß Achim

[Fredy]

Hallo

Ich denke ebenfalls, dass wir das Format in möglichst vielen Dateiformaten unterbringen können sollten. Nehmen wir als einfachstes mögliches Dateiformat csv, müssen alle Informationen in (mehreren) Tabellen gespeichert werden können.

Daraus ergibt sich die Frage wie viele Tabellen wir mindestens benötigen:

1. Dokument & Stations Informationen
2. (Vordefinierte) Spalteninformationen der Wetterdaten
3. Wetterdaten


Ich würde gerne noch einen Bereich für Benutzerspezifische Spalteninformationen schaffen, mit Werten wie:
Sensor Typ:
Sensor Hersteller:
Sensor Modell:
Sensor Präzision:
Sensor Abweichung:

(Evtl in einer 4. Tabelle)

Dabei sollte berücksichtigt werden, dass sich die "Benutzerdefinierten Spalteninformationen" innerhalb der Aufzeichnung ändern können.
(z.B. Könnte ein Sensor durch anderes Modell ersetzt werden). Somit müsste dieser Bereich mehrfach vorkommen dürfen. (Referenziert in einer Spalte der Wetterdaten Tabelle 3)

Als weiters Vorgehen würde ich empfehlen, die bereits definierten "Bezeichner" im Wiki, auf  einzelne Tabellen zu verteilen. Dabei versuchen, so wenige Tabellen wie möglich zu verwenden.
Ich vermute so sehen wir recht schnell, wie viele Tabellen oder "Informations Ebenen" wir benötigen, um möglichst viele Anwendungsfälle abzudecken.

Aus diesen Tabellen lassen sich dann auch die (Haupt)Gruppen/Sektionen einer zb. xml Datei ableiten, sowie evtl. die Tabellen Basis einer beliebigen Datenbank.

Sektion 01 : Dokument und Stationsinformationen
Sektion 02 : (Vordefinierte) Spalteninformationen der Wetterdaten
Sektion 03 : (Benutzerdefinierte) Spalteninformationen der Wetterdaten
Sektion 04 : Wetterdaten

Dabei sollte eine nach owsd gültige Datei, nicht alle Sektionen enthalten müssen.

Grüsse Fredy

[24Online]

Hi Fredy,

können wir die "Benutzerspezifische Spalteninformationen" in der Beschreibung des Datenbezeichner integrieren?

Im wiki hatte ich für vergleichbares schon Beispiele aufgeführt:

031101_DE_Desc = "Text_DE"

könnte doch dann auch so etwas wie:

031101_DE_Sensor_[N]_Typ = "Sensor typ" oder
031101_DE_Sensor_[N]_Hersteller = "Sensor Hersteller" sein.

Der Sensor wäre dann einer Gruppe und einem Wert zuzuordnen. Ein Modellwechsel des Sensors könnte dann durch die Nummerierung [N] zu kennzeichnen sein. So hätten wir eine gewisse Darstellungsvereinheitlichung, da wir in den Werte selbst ja auch schon mit dieser "Nummerierung" arbeiten um identische Werte unterschiedlicher (parallel betriebener) Sensoren abzubilden.

Die Sektionenaufteilung findet ich gut, diese kann ja dann auch ein wenig die Formatierung der letztendlichen Darstellung des OWSD-Formats in Wiki beeinflussen.

Wenn ich es richtig verstehe, dann wird hier nachfolgende hierarchische Struktur gebildet:

Sektion => Gruppe => Subgruppe I => Subgruppe II => Datenbezeichner

Ich brauch jetzt mal nen Kaffee...

Bis später
Achim