Standard - Datenbankschema für Wetterdatenaufzeichnung

[Fredy]

Hallo Wetterfreunde

@24Online
Vielen Dank Ich werde die neuen Felder noch hinzufügen. (Wie sind die Einheiten für <solar_radiation> und <UV>?)


@theWeather
Ich würde klar xml und json als Basis bevorzugen. Bei xml ist der "overhead" halt ein wenig grösser, und bei csv am kleinsten
.ini sollte diesbezüglich etwa gleich auf mit json sein.(Aber ist ini wirklich für eine solche Aufgabe besser geeignet?)

@leknilk0815
Wie sieht denn eine "davis" Datei aus? Kannst du ein Beispiel verfügbar machen?

grüsse Fredy

[24Online]

Morgen Fredy,
nur kurz vorm Job, Solar radiaton in Watt/ m2 und der UV-Index ist einheitslos und steht's ne ganze Zahl 0-16 (Infos gibt es beim Amt für Strahlenschutz). Gruß 24Online

PS.: die Einheiten der Radiation kenne ich nicht...so etwas hat meine Ws nicht. Aber ich kann gerne mal googlen später...

[leknilk0815]

Wie sieht denn eine "davis" Datei aus? Kannst du ein Beispiel verfügbar machen?

Servus,
da ich keine Davis habe, müsste sich da ein Davisianer äussern... - vielleicht kann ja Werner mal eine Beispieldatei liefern?

[webworker]

Vielleicht hilft dabei die Orientierung an den WMO-Standards, die ebenfalls in die UN-Datenbanken fliessen und dazu von einigen nationalen Wetterdiensten genutzt werden.

http://data.un.org/Explorer.aspx?d=CLINO

Der Ansatz von Fredy scheint schon ziemlich tief zu gehen - nicht schlecht. JSON zum Austausch dürfte machbar sein.

Was wird als Davis-Datei benötigt?!

Rohdaten? Wird im SDK gut beschrieben ->
http://www.davisnet.com/support/weather/download/VantageSerialProtocolDocs_v261.pdf

Wenn es etwas aufbereitetes sein soll kann ich mich gerne noch dran setzen da ich aktuell zum Austausch zwischen PC und Web-DB  XML, CSV und JSON je nach Verwendungszweck erzeuge.

[leknilk0815]

Was wird als Davis-Datei benötigt?!

Servus,
falls wir nicht völlig aneinander vorbeireden eigentlich nur eine CSV- Datei, wie sie WSWIN benützen würde, wenn man die Davis mit Dateiüberwachung laufen lassen würde.
Darin sind die Positionen und Felder definiert

[wneudeck]

Hallo,
nur ein kurzer Einwurf von mir, da ich das Thema hier nicht mehr komplett präsent habe:
"Wie sieht eine Davis Datei aus?"
Ich sage jetzt mal burschikos: sie "sieht" überhaupt nicht aus, denn Davis speichert seine Daten in den wlk-Dateien im Binärformat, das man leztlich mit einem normalen Editor gar nicht ansehen kann (ansehen schon, aber es nützt nichts). Und auch ein Hex-Editor hilft dem Normalverbraucher nicht weiter.
Und um nun auf WSWIN zu kommen: speziell bei der Davis überwacht WSWIN genau diese wlk-Datei, es ist also hier (anders als bei vielen anderen Stationen) keine csv-Datei im Spiel.

[Fredy]

Hallo

@webworker
Danke für den interessanten un.org Link. Ich schau mir das mal genauer an .
Das Davis SDK pdf beschreibt ab Seite 22 viele Felder. Interessant wäre auch eine Exportdatei mit allen Feldbezeichnungen.

Ich denke wir brauchen nur eine möglichst grosse Liste von Werten, um eine einheitliche Bezeichnung von möglichen Felder zu finden.

Betreffend bereits existierenden Standards bin ich noch auf OGP gestossen.(SensorML)
http://www.opengeospatial.org/domain/swe#standards


Habe noch einige Felder hinzugefügt und "temp_ground" in temp_soil "geändert":
( https://github.com/fredyfire/openWeatherStationData/blob/master/valueDescriptions.txt )

Code Auswählen Erweitern

### Wind ###

winddir_degree : Winddirection in degrees 0.1-359.9 ?
winddir_string : Winddirection in string (NNE)

### Radiations ###

radiation_solar : Solar radiation in W/m2
uv_index : UV-Index 1-X

### Precipitation (Rain&Snow) ###

raining_now ? : true of false ?
precipitation_type ? : rain, snow ...?
snow_height ? : snow height agl ?

leaf_wetness ? : true false ?
soil_moisture ? : in cbar ?

### ? Air Pollution ? ###

air_03 : O3 in µg/m³
air_NO2 : NO2 in µg/m³
air_SO2 : SO2 in µg/m³
air_CO : CO in mg/m³
air_CO2 : % ?
air_PM10 : fine suspended particulates less than 10 microns in diameterµg/m³
air_CPC : Condensation Particle Counter in 1/cm³
air_ECPM25 : elemental carbon EC PM2.5 in µg/m³
air_NMVOC : ppm



### ? Groundwater ? ###

groundwater_level_m : ? below ground level in m ?



--
grüsse Fredy

[webworker]

Entscheident für nen Standard dürften ja nicht irgendwelche Dateien sein, sondern das was letztlich minimal dabei zum Vorschein kommen soll - sprich das was im Standard an Metadaten definiert wurde.


- Wert inklusive Vorzeichen, Dezimalzeichen, Anzahl der Dezimalstellen, Anzahl Zeichen minimal / maximal sowie Vorgabe bei fehlenden Daten
- Einheit
- Zeitpunkt der Erfassung + Format + Zeitzone
- Level (Eindeutige Levels zur Kennzeichnung bspw. Luftdruck Station-Level bzw. Sea-Level)
- Eindeutige Identifizierung / Zuordnung zur meldenden Station / Sensor

Dazu dann zwingend ergänzend eine Beschreibung der Station / des Sensors

- Position ( Lat / Lon)
- Höhe
- Name
- evtl. Genauigkeit je nach Zweck
- Eindeutige Kennung ( dürfte bei privaten Stationen schwierig werden) für Datenaustausch


Und das liegt ja mitunter an den Wetterstationen mit Ihren erfassten Parametern  bzw. an der Software die die Daten übermittelt. Oder liege ich da aktuell völlig daneben? Und da ist uninteressant wie die Software die Daten ausliest sondern eher wie diese aufbereitet und weitergegeben werden.

Um da WsWin als Beispiel wieder zu nehmen kann damit so ziemlich vieles an Formaten weitergegeben werden. Bin bisher an keine Einschränkung gekommen.

@Fredy

Nochmal von der WMO, die ja schon Standards nutzt bzw. vergeben hat - das passt ziemlich gut:

"Handbook on CLIMAT and CLIMAT TEMP Reporting"

http://www.wmo.int/pages/prog/www/OSY/Publications/TD1188/HandbookCLIMAT-CLIMATTEMP_en.pdf





Beiträge zusammengeführt, weil der Autor sich selbst geantwortet hat statt seinen letzten Beitrag zu ändern: 05.02.2014, 13:39:39

Hallo

@webworker
Danke für den interessanten un.org Link. Ich schau mir das mal genauer an .
Das Davis SDK pdf beschreibt ab Seite 22 viele Felder. Interessant wäre auch eine Exportdatei mit allen Feldbezeichnungen.

Ich denke wir brauchen nur eine möglichst grosse Liste von Werten, um eine einheitliche Bezeichnung von möglichen Felder zu finden.

--
grüsse Fredy

Die Davis erzeugt nicht zwingend eine Exportdatei - man kann direkt über den Logger auf das EEPROM zugreifen und die Werte auslesen.

Von WsWin habe ich mal eine Exportdatei angehangen, da ist die Bezeichnung dann abhängig von den unter Eigenschaften definierten Kurznamen.



[gelöscht durch Administrator]

[Fredy]

Hallo webworker

Und da ist uninteressant wie die Software die Daten ausliest sondern eher wie diese aufbereitet und weitergegeben werden.

Ich sehe das auch so.

Ich denke wir sollten evtl. 2 Dinge trennen um Missverständnisse zu minimieren.

1. Definition von "Wertebezeichern". So kann auf eine "Liste" mit Definitionen (und Beschreibungen) zurückgegriffen werden. Man sollte dann immer wissen was man in einem Feld mit entsprechender Bezeichnung zu erwarten hat. (unabhängig des Dateiformats)

z.B. "temp_air_2m_c" für Lufttemperatur in 2m agl in °C (z.B. im Format -99.99)

2. Dokumentstruktur
Hier sollte man eine Möglichkeit finden, die Werte (und allfällige metadaten) nach einem "Muster" zu ordnen. Eine kompatible Anwendung wüsste dann immer, wo die entsprechende Information "zu finden" ist.

z.B. die Daten immer in der Sektion <data>, unabhängig davon ob weitere (nicht zwingende) Metadaten enthalten sind.



Betreffend CLIMAT Standard:

Das sieht auch Interessant aus. Hier ein Beispiel einfach beschrieben (s7):
http://www.wmo.int/pages/prog/gcos/Publications/GCOS-127_EN.pdf


Grüsse Fredy


Nachtrag: Hier eine Übersicht bereits existierenden, und evtl. in Frage kommenden Standards:

BUFR (WMO):
http://en.wikipedia.org/wiki/BUFR
GRIB (WMO):
http://en.wikipedia.org/wiki/GRIB

- m.m. eignen sich beide nicht für unsere Zwecke. Zudem Binärdaten.


CLIMAT (WMO):
http://en.wikipedia.org/wiki/CLIMAT

- Beschränkung auf Monatsdaten und eher für Klimadaten optimiert.


METAR (WMO):
http://en.wikipedia.org/wiki/METAR

- zu beschränkt, anderes Einsatzgebiet

SYNOP (WMO):
http://en.wikipedia.org/wiki/SYNOP

- evtl. ? vermute aber zu grosse Einschränkungen


sensorML & SOS (OGC)
http://de.wikipedia.org/wiki/Observations%26Measurements

- könnte m.m. passen, scheint aber zu weitreichend und sehr komplex zu sein.

Irgendwie passt bis jetzt alles nicht so richtig

[webworker]

SensorML ist heavy 

Was ganz einfaches, aber relativ verbreitet

http://openweathermap.org/wiki/API/data_upload

wobei man da nicht unbedingt von einem Standard sprechen kann...