Standard - Datenbankschema für Wetterdatenaufzeichnung

[TheWeather]

Ich verfolge die Bestrebungen nach einem "Einheitsformat" zum Datenaustausch jetzt schon seit Anbeginn an. Was mich mir noch nicht erschließt, ist der Sinn dieses Unterfangens.

Man kann jedes Format (mit etwas Programierung) von dem einen in das andere überführen. Da spielt es keine Rolle, ob binär, hexadezimal, in Dezimalwerten oder als Text geseichert wird. Was macht es also für einen Unterschied, ein international gültiges Format für "Umweltaufzeichnungen" neu zu überdenken, wenn die letztendlich wichtige Auswertung diese Daten nicht lesen kann?

Das weit verbreitete MS-Excel wird die Daten nicht lesen können, ein OpenOffice (immerhin von freien Programmierern unterstützt), wird es ebenso nicht von heute auf morgen bewerkstelligen, die neu erdachte Struktur zu lesen und für tabellarische/grafische Auswertungen verwenden zu können.

Ich muss also nochmal nach dem Sinn fragen, der sich mir noch nicht wirklich erschließt.

Wenn ein Hersteller irgendeinen Wert sicher auf 1/1000stel auflösen kann, taugt die beschlossene Darstellung in 1/100stel auch nichts mehr, weil dann Information verloren gingen. Der müsste sich dann eine andere Alternative suchen (wahrscheinlich wieder .csv), um seine Daten zu archivieren oder zu dokumentieren.

Etwas Aufklärung über die "eigentliche" Absicht wäre aus meiner Sicht sicherlich angesagt.

Gruß Hans

[24Online]

Hallo Fredy, genauso hatte ich das auch gesehen:

1.Wertebezeichner mir klarer Beschreibung

Vor allem völlig losgelöst einer Quellhard- oder -software.

Die Frage ist in welcher Form wir eine Zusammenarbeit im Sinne von Collaborationplattform hinbekommen, da wir ja offensichtlich örtlich und zeitlich differierend agieren.

Ich würde diese Wertebezeichner, sobald wir eine guten ersten Stand haben, dann auch in XML-abbilden.
Zunächst wurde ich aber empfehlen das wir eine gute Dokumentation erstellen. Könnte wir dies vielleicht hier im Wiki machen, wen fragen wir da?

Code Auswählen Erweitern

<?xml version="1.0" encoding="utf-8" ?>
    <data>
        <doc_description>
            <doc_type>X-Meteodat</doc_type>
            <doc_version>V0.0.1</doc_version>
            <doc_url>...</doc_url>   
        </doc_description>
        <station_description>
            <id>IBERLINB43</id>
            <name>Berlin, Schulzendorf </name>
            <description>Berlin, Schulzendorf</description>
            <url>http://wetter.mxberlin.de</url>
            <email>xxxxx@mxberlin.de</email>
            <city>Berlin</city>
            <zip></zip>
    <state>BERLIN</state>
            <country>Germany</country>
            <country-code>DE</country-code>
            <latitude>52.610935</latitude>
            <longitude>13.243770</longitude>
            <elevation_ft>121</elevation_ft>
            <elevation_m>36.88</elevation_m>
            <station_HW>HP1000</station_HW>
            <station_SW>V1.1.0</station_SW>
            <operator>
                <nickname>xxx</nickname>
                <realname>Vorname Nachname</realname>
                <p_email>xxxx@xxxx.xx</p_email>
            </operator>    
        </station_description>
        <observation>
            <date_f1>04.02.2014</date_f1>
            <date_f2>2014-02-04</date_f2>
            <time_f1>20:15:02</time_f1>
            <time_f2>HH:MM</time_f2>
            <zone>GMT</zone>
            <observation_time_rfc822>Tue, 04 Feb 2014 20:15:02 GMT</observation_time_rfc822>
        </observation>
        <datafields>
            <temperatures>
                <temperature_string_2m>35.1 F (1.7 C)</temperature_string_2m>
<temp_f_2m>35.1</temp_f_2m>
<temp_c_2m>1.7</temp_c_2m>
                <temp_air_2m_c></temp_air_2m_c>
                <temp_air_2m_f></temp_air_2m_f>
                <temp_air_5cm_c></temp_air_5cm_c>
                <temp_air_5cm_f></temp_air_5cm_f>
                <temp_ground_5cm_c></temp_ground_5cm_c>
                <temp_ground_5cm_f></temp_ground_5cm_f>
                <temp_ground_1m_c></temp_ground_1m_c>
                <temp_ground_1m_f></temp_ground_1m_f>
                <calculate_temps>
                    <windchill_string></windchill_string>
                    <windchill_f></windchill_f>
                    <windchill_c></windchill_c>
                    <dewpoint_string>25.5 F (-3.6 C)</dewpoint_string>
                    <dewpoint_f>25.5</dewpoint_f>
                    <dewpoint_c>-3.6</dewpoint_c>
                </calculate_temps>
            </temperatures>
            <air>
                <rel_hum>68</rel_hum>
                <pressure_string>29.93" (1013.4 mb)</pressure_string>
<pressure_mb>1013.4</pressure_mb>
<pressure_in>29.93</pressure_in>
            </air>
            <wind>
                <wind_string>...</wind_string>
<wind_dir_de>WNW</wind_dir_de>
                <wind_dir_en>WNW</wind_dir_en>
               
<wind_degrees>297</wind_degrees>
               
<wind_mph>0.0</wind_mph>
                <wind_kmh>0.0</wind_kmh>
                <wind_ms>0</wind_ms>
                <wind_kn>0</wind_kn>
                <wind_bft>0</wind_bft>
                <wind_bft_string>...</wind_bft_string>
               
<wind_gust_mph>0.0</wind_gust_mph>
                <wind_gust_kmh>0.0</wind_gust_kmh>
                <wind_gust_ms>0</wind_gust_ms>
                <wind_gust_kn>0</wind_gust_kn>
                <wind_gust_bft>0</wind_gust_bft>
                <wind_gust_bft_string>...</wind_gust_bft_string> 
            </wind>
            <rain>
                <precip_1hr_string>0.00 in (0.0 mm)</precip_1hr_string>
<precip_1hr_in>0.00</precip_1hr_in>
<precip_1hr_metric>0.0</precip_1hr_metric>
                <precip_3hr_string>0.00 in (0.0 mm)</precip_3hr_string>
<precip_3hr_in>0.00</precip_3hr_in>
<precip_3hr_metric>0.0</precip_3hr_metric>
                <precip_6hr_string>0.00 in (0.0 mm)</precip_6hr_string>
<precip_6hr_in>0.00</precip_6hr_in>
<precip_6hr_metric>0.0</precip_6hr_metric>
                <precip_9hr_string>0.00 in (0.0 mm)</precip_9hr_string>
<precip_9hr_in>0.00</precip_9hr_in>
<precip_9hr_metric>0.0</precip_9hr_metric>
                <precip_12hr_string>0.00 in (0.0 mm)</precip_12hr_string>
<precip_12hr_in>0.00</precip_12hr_in>
<precip_12hr_metric>0.0</precip_12hr_metric>               
<precip_today_string>0.00 in (0.0 cm)</precip_today_string>
<precip_today_in>0.00</precip_today_in>
<precip_today_metric>0.0 cm</precip_today_metric>
            </rain>
            <sun>
                <solar_radiation>0</solar_radiation>
<UV>0.0</UV>
            </sun>
            <ligntnings>
                <lightnings_interval> </lightnings_interval>
                <lightnings_1h> </lightnings_1h>  
                <lightnings_3h> </lightnings_3h>
                <lightnings_6h> </lightnings_6h>
                <lightnings_12h> </lightnings_12h>
                <lightnings_24h> </lightnings_24h>
            </ligntnings>
           
            <radiation> </radiation>
           
            <customs> </customs>
        </datafields>
    </data>


Beiträge zusammengeführt, weil der Autor sich selbst geantwortet hat statt seinen letzten Beitrag zu ändern: 05.02.2014, 20:49:17
Hi TheWeather,

ich versuche mal meine ursprünglichen Gedanken aufzeigen.

Ich bin dabei die Messdaten meiner Wetterstation für die Anzeige im Internet aufzubereiten. Dabei bin ich auf die Anforderung gestoßen, dass ich Daten aus dem XML-Format über ein PHP-Skript in eine mysql-Datenbank speichern wollte. Da ich zeitlich so wenig Daten "verlieren" wollte wie es nur geht, habe ich auf die schnelle eine eigene Datenbankstruktur (heiße-Nadel-Design) erstellt. Später würde ich darauf basierend auch langzeitige  rückwirkende Charts erstellen. Nun habe ich die erste Aufgabe (Anzeige der Wetterdaten) erfüllt und möchte die nicht sichtbaren Skripte des Imports, der zeitlichen und funktionalen Steuerung optimieren.

Dabei habe ich im Internet nach einer mysql-Datenbankstruktur gesucht, die vielleicht als Standard die Benennung der einzelnen "Spalten" der Datenbank auflistet und den Datentyp (bspw. INTEGER oder DEZIMAL) beschreibt. Ich wurde nicht fündig und habe deshalb hier gefragt ob es so etwas gibt.

Sinn und Zweck war zum einen mir genau diese Arbeit zu sparen, wenn es Vorgaben mit einer "gewissen Gültigkeit" geben würde und zum anderen evtl. mal mit irgendjemanden Daten austauschen zu können ohne genau diese Bezeichnungen anpassen zu müssen. Also ohne ein Skript schreiben zu müssen, was bspw. die Daten der Spalte "temp_c" mit der Spalte "temp_c_2m_air"  abzugleichen, sofern es dann um die Ergebnisse einer vergleichbaren Messmethode sind.

Also kurz um, war das ursprüngliche Ziel völlig losgelöst von Soft- und Hardware ein Datenmodell für diese Zwecke zu finden. Also das was Fredy unter "Wertebezeichner mir klarer Beschreibung" meint.

Das man in einen nachfolgenden Schritt dann darauf basierend auch mysql-inserts, csv-Dateistrukturen, XML-Dateien oder sonst was adaptieren könnte ist dann jeden selbst überlassen bzw. der Community.

[wneudeck]

Hallo,
ich habe ja schon weiter oben gesagt, mich hier nicht besonders einzubringen, aber nun doch folgendes:

wenn es Vorgaben mit einer "gewissen Gültigkeit" geben würde

Und genau die gibt es eben nicht und das werdet ihr hier auch nicht zustandebringen.
Wir dürfen unser Forum hier auch nicht überschätzen und glauben, wir ( in dem Fall 2 engagierte Forumsmitglieder) könnten hier sozusagen eine Norm auf die Füße stellen, die dann die Allgemeinheit rettet.
Es ist für mich einfach nur interessant, dem ganzen Gedankengang und den Bemühungen zu folgen, aber ich wage zu behaupten, es wird hier kein Ziel erreicht werden.
Ich war und bin z.B. fasziniert von dem Tutorial, das Fredy in Bezug auf Datenbanken hier schon eingebracht hat (drum habe ich es ja auch oben angepinnt), aber was hier jetzt abgeht, ist mehr eine akademische Diskussion.
Wobei ich nichts dagegen habe, wenn sie weitergeführt wird.

[Fredy]

Hallo

Bei GitHub hätten wir ein wiki und Versionskontrolle über alle Dateien etc.

Grüsse Fredy

[TheWeather]

Hallo zusammen,

ich betrachte es jetzt, mal vorsichtig ausgedrückt, so ähnlich wie Werner es gerade formuliert hat. Ich lege allerdings noch meine Füße hoch, denke vielleicht ebenfalls ein wenig mit, beäuge aber mal das Geschehen aus sicherer Distanz.

Wenn ich einen Satz wie diesen hier lesen muss

... Die Frage ist in welcher Form wir eine Zusammenarbeit im Sinne von Collaborationplattform hinbekommen, da wir ja offensichtlich örtlich und zeitlich differierend agieren ...

, habe ich nicht unbedingt den Eindruck, dass es hier um einen gemeinsamen Gedankenaustausch gehen soll, dem noch irgendjemand im Forum mit Interesse folgen können soll.

Nun könnte ich selbst einfach behaupten, "es tangiere mich zwar aus Interesse, wenn zwar nicht mental, dann aber wenigstens peripher und mein Gesichtskreis soll sich durch weitere Diskussionen nicht unbedingt auf einen persönlichen Standpunkt mit dem Radius NULL ausdehnen". Das klingt genau so gequirlt und kratzt ein wenig an der Ernsthafigkeit des geschilderten Vorhabens.

Auch bei den eingeworfenen Links hätte man manchmal eher ins Klo greifen sollen, statt denen auch nur einen Bezug zur momentanden Diskussion abringen zu können - ich habe versucht diesen zu folgen, hätte stattdessen aber auch IEEE754-Formate für die Darstellung von Zahlenformaten zitieren können, die in dem Moment auch niemandem genutzt hätten.

Meine Bitte wäre, wenn es denn öffentlich ausgetragen wird, auch die Forenmitglieder soweit mit einzubeziehen, dass es Spaß macht, euren Überlegungen zu folgen - das sehe ich leider momentan noch nicht.

Ebenso irritiert mich, dass man Zeilen wie : <precip_1hr_string>0.00 in (0.0 mm)</precip_1hr_string>, welche als "Neuentwicklung" angepriesen werden, bereits im exakt gleichen Wortlaut bei Weather Underground (oder wie auch immer das heißt) im Netz findet, wenn man mal kurz google bemüht - "von Guttenberg" lässt anscheinend aus der Ferne grüßen.

Ich warte halt mal ab, bis die Sache soweit "durch" ist ... 

Gruß Hans

[24Online]

Hallo TheWeather,

entschuldige bitte meine Ausdrucksform (bezüglich der Collaborationsplattform), obwohl ich deiner Kritik nicht ganz folgen kann.

Du hast nach den ursprünglichen Gedanken gefragt und ich habe versucht es allgemein zu erläutern. Nach wie vor bin ich nicht der Meinung das wir einen "Standard" oder gar eine "Norm" erzielen können, das ist nicht das Ziel. Aber wir, und damit meine ich die Interessierten, können doch sicher versuchen eine Datenfeldbezeichnung abzustimmen nach der die Interessierten ihre Datenbanken strukturieren können.


So nun zu deinem nächsten inhaltlichen Beitrag:

"...<precip_1hr_string>0.00 in (0.0 mm)</precip_1hr_string>, welche als "Neuentwicklung" angepriesen werden..."

1.) Niemand hat das als Neuentwicklung angepriesen, wo denn?
2.) Warum sollten wir nicht auf existierendes zurückgreifen? Es geht doch hier nicht darum das RAD neu zu erfinden, oder einen neuen Begriff für "Niederschlag" zu finden...

Da du den String ja gegooglet hast, gehe ich davon aus, das es dich inhaltlich doch etwas interessiert oder du nur nach etwas zum Kritisieren suchst.

Entschuldige meine Direktheit...aber ich habe den Eindruck, das Du konstruktiv nichts dazu beitragen möchtest, sondern lediglich den Grundgedanken und unsere Lösungsfindung wiederholt in Frage stellen möchtest.

Und noch einmal: Keine Norm, kein Standard (Auch ich weiß das wir dazu zu unbedeutend und wahrscheinlich auch zu unwissend sind), sondern eine Abstimmung von Wertebezeichner bezüglich Name, ggfs. Gruppierung und Format zwischen Interessierten.

[Fredy]

Hallo Wetterfreunde

Betrachtet man sich diese Beispiel-Information, aus Sicht eines "Entwicklers" oder einer Anwendung:

<precip_1hr_string>0.00 in (0.0 mm)</precip_1hr_string>

Ist ohne weitere Informationen nicht klar, ob es sich nun um effektive gemessene, hochgerechnete, Sum. Min. Max. oder gar Werte einer Vorhersage handelt. Diese Information wird ja erst im Kontext von Zusatzinformationen nutzbar. Welche und in welcher Form diese Zusatz Informationen nun gespeichert oder übermittelt werden, könnte doch Grundlage einer Diskussion und Suche nach einem evtl. bereits existierendem Standard sein. (im Besonderen hier im Entwicklerbereich. Das muss ja nicht jeden interessieren)

Zum "Format":
Tabellarische Daten lassen sich in zb. csv wunderbar abbilden. Das stellt ja niemand in Frage.
Sobald aber weitere Zusatzinformationen, welche nicht in das Tabellenlayout passen, aufgenommen werden sollen, wird das doch mit .csv ein gebastel.
Möchte ich Beispielsweise die Stationshöhe, Standort etc. mitspeichern, müsste ich das in einer 2.ten Datei speichern, um das Tabellenlayout nicht auseinanderreissen.
Möchte ich dann noch zusätzliche Sensor Informationen mitspeichern, müsste ich eine weitere .csv erstellen.
Man kann aber Informationen, welche nicht in "dasselbe" Tabellenlayout passen, auch in einer einzigen Datei speichern. Hier kämen dann Formate wie xml und json etc. ins Spiel, welche mehrere "Tabellen-Ebenen" erlauben.

Falls dann auch mehrere Entwickler auf das gleiche Format zurückgreifen würden, könnten Informationen zwischen den Anwendungen viel einfacher (automatisiert) ausgetauscht werden.
Das wäre, in erster Linie, sicher eher für einen Entwickler Interessant.  Würde aber längerfristig evtl. indirekt auch Vorteile für Anwender bringen. (Könnten Sie doch zwischen Anwendungen wechseln, ohne sich Gedanken über z.b. Trennzeichen zu machen.) Für den Anwender sollte aber immer  auch die Möglichkeit bestehen, einen "Tabellen Export/Import"  der "Rohdaten" in Tabellenformate wie .csv oder .xls durchzuführen.

Ob in diesem Format, definiert sein soll, wie z.b. ein Wetterwert-Feld bezeichnet, und ob zusätzlich sogar ein "Feldtyp" und Kommastellen festgelegt werden sollte, soll doch u.a. Zweck dieser Diskussion sein.

Dass im Moment noch keine Anwendung existiert, die den nicht existierenden ,,Standard" unterstützt, sollte klar sein.

Grüsse Fredy

Nachtrag: Immerhin würden ja hier gemäss derzeitigem Stand der Abstimmung, 8 von 10 Entwickler, einen Standard "im Bedarfsfall nutzen und bei Ihrer Programmierung berücksichtigen".

[24Online]

Um etwas Transparenz zu schaffen, was das eigentliche Anliegen war, möchte ich nachfolgend eine kurze Beschreibung des Vorhabens und ein zu diskutierenden Ablauf aufführen:

Projektbezeichnung (Vorschlag):  OpenWeatherStationData (OWSD)

Ziel des Projekts: Bereitstellung einer Datenstruktur zur Bezeichnung und Formatierung von Messdaten aus privaten Wetterstationen (PWS) zur Erweiterung der Möglichkeiten eines effizienten Datenaustauschs und als Basis zur Erstellung von weiterverarbeitenden Skripten.

Vorgehen:
Schritt 1:   Abstimmung und Definition des notwendigen inhaltlichen Detailierungsgrad der Beschreibung eines Datenbezeichners
Ziel ist es die ausgewählten Datenbezeichner auch inhaltlich zu definieren. So werden neben der Datenfeldbezeichnung auch Beschreibungen wie bspw. die Einheit des Messwerts (bspw. Grad Celsius C°, das Datenformat (bspw. Dezimalwert, 2 Stellen nach dem Komma), ggf. der mögliche Wertbereich (bspw. von -30,00 bis 99,00), das Messverfahren und ggf. Quellen zum Messverfahren mögliche Detaillierungen.

Beispiel:

Messwertbeschreibung:
Der Messwert ist die gemessene meteorologische Lufttemperatur.

Vorschlag Bezeichner:    
temp_air_2m_c  (Bezeichner  f. Grad Celcius)
temp_air_2m_k (Bezeichner  f. Einheit Kelvin)
temp_air_2m_f (Bezeichner f. Einheit Fahrenheit)

Gruppe:
Temperaturen
Subgruppe I:
Luft
Subgruppe II:
   
Format(e):
[°C] = Dezimal, 2 Nachkommastellen
[K] = Dezimal, 2 Nachkommastellen
[F] = Dezimal, 2 Nachkommastellen

Einheit(en)   :
Grad Celsius [°C]
Kelvin [K]
Fahrenheit [F]
Wertebereich:
[°C] = von -XX,XX bis XX,XX
[K] = von -XXX,XX bis XXX,XX
[F] = von -XX,XX bis XXX,XX

Messverfahren:
Die Lufttemperatur wird in der Regel  in 2 Meter Höhe über Boden gemessen und ist  weder von direkter Sonnenstrahlung noch von Bodenwärme oder anderer Wärmeleitung beeinflusst.

Quellen:
http://de.wikipedia.org/wiki/Lufttemperatur
http://www.dwd.de (Wetterlexikon Lufttemperatur)

Schritt 2:   Sammlung der zu beschreibenden Datenbezeichner
In diesem Arbeitsschritt werden die Vorschläge aufgenommen, welche Messdaten in das OWSD-Format aufzunehmen sind.  In Abhängigkeit des Umfangs und der Anzahl der Mitwirkenden sollte hier ggf. priorisiert werden.

Schritt 3:   Strukturierung der zu beschreibenden Datenbezeichner in messtypbezogenen Gruppen
Um eine Strukturierung (Gruppierung) zu ermöglichen sind die Gemeinsamkeiten der Messdaten zu ermitteln. Erkannte Gemeinsamkeiten werden diskutiert und abgestimmt. Gruppierung können bspw. stationsbezogene Daten, Operator-bezogene Daten, Temperaturwerte vielleicht unterteilt in ,,gemessen" und ,,errechnet"  oder ähnliches sein. 

Schritt 4:   Abstimmung und Definition der Datenbezeichner
Dieser Arbeitsschritt dient der Abstimmung der Datenbezeichnungen

Schritt 5:   Ausarbeiten  der Beschreibungen (bspw.)
5.1   Feldbezeichner und Varianten
5.2   Inhaltliche Feldbeschreibung
5.3   Gruppenzugehörigkeit
5.4   Quellen zu Messverfahren und ...
5.5   Einheit(en)
5.6   Datenformate
Schritt 6:   Abstimmung Definition der Anwendung, Formatnutzung
6.1   Bezeichnung des Formats (Vorschlag: OWSD-Format)
6.2    Nutzung und Teilnutzung beschreiben
6.3   Versionierung/Veröffentlichung
7.   Begleitende Dokumentation


...und Entschuldigung danach: Plan, Do, Check & Act nach Herrn Deming...

[TheWeather]

Hallo 24 online und Fredy,

ein Interesse an euren Überlegungen ist vorhanden, allerdings nur aus der Sicht eines Beobachters. Zur aktiven Mitarbeit bin ich nocht nicht genügend motiviert und werde wohl auch weiterhin nur mitlesen oder auch mal (wie zuvor geschehen) die Form der Darstellung "kritisieren".

Da du den String ja gegooglet hast, gehe ich davon aus, das es dich inhaltlich doch etwas interessiert oder du nur nach etwas zum Kritisieren suchst.

Kritik sei aber dennoch erlaubt (klingt neutraler als "kritisieren").

... Immerhin würden ja hier gemäss derzeitigem Stand der Abstimmung, 8 von 10 Entwickler, einen Standard im Bedarfsfall nutzen und bei Ihrer Programmierung berücksichtigen".

Ihr dürft davon ausgehen, dass ich eine der 8 Stimmen repräsentiere. Allerdings ist es auch so, dass man sich als Entwickler gezwungenermaßen mit den unterschiedlichsten angebotenen Formaten auseinander setzen muss. MS-Access als filebasierte Datenbank (*.mdb) lässt ja auch innerhalb einer Datei zahlreiche Tabellen (Strukturen) zu, daneben sogar Berichte und Abfragescripte. Es wäre allerdings (meines Ermessens nach) für die meisten Aufgaben (z.B. das Anlegen einer einfachen Datensatztabelle mit zeitlich aufeinander folgenden Einträgen für einige Umweltdaten) völlig überdimensioniert.

Ebenso macht es einen deutlichen Unterschied, ob eine Datensammlung (ich vermeide jetzt mal den Begriff "Datenbank") a) online verwendet wird (also im laufenden Betrieb mit Records gefüllt wird) oder ob es sich eher um b) einen Report (eine abgeschlossene und zur Weitergabe aufbereitete Datensammlung) handelt. Zu b) hielte ich eure Überlegungen für sehr gut geeignet, zu a) weniger - kann man aber vieleicht später mal diskutieren.   

Entschuldige meine Direktheit...aber ich habe den Eindruck, das Du konstruktiv nichts dazu beitragen möchtest, sondern lediglich den Grundgedanken und unsere Lösungsfindung wiederholt in Frage stellen möchtest.

Was ich momentan etwas vermisse, ist eine grobe Vorstellung eures Projektes von Anfang an. Erst durch eure weiteren Erläuterungen wird jetzt mittlerweile eher verständlich (so geht's zumindest mir), in welche Richtung es gehen soll. Es war (und ist) bei den ersten Beiträgen schon schwierig, euren Gedankengängen zu folgen.

Insofern darf ich mich vielleicht ausnahmsweise selbst zitieren:

Meine Bitte wäre ... , auch die Forenmitglieder soweit mit einzubeziehen, dass es Spaß macht, euren Überlegungen zu folgen - das sehe ich leider momentan noch nicht.

Wenn es in diese Richtung weiter ginge und man euren Gedanken zukünftig folgen dürfte, wäre doch jedem gedient - oder?

Gruß Hans

Nachtrag: Sorry, sehe gerade, unsere Beiträge haben sich überschnitten. Die vorangehende  Darstellung sieht doch schon mal gut aus.

[Fredy]

@24online

Sehr schöne Aufstellung.

Wäre noch die Frage der "Collaborationsplattform"


Grüsse Fredy