@Oliver:

Sehr schön weit voausgesehen!
Dafür würde sogar ich (komprimiertes) XML für gerechtfertigt halten

Grüße
Malte

Zitat:

---

Dafür würde sogar ich (komprimiertes) XML für gerechtfertigt halten

---

Als komprimiertes meinst du jetzt eine vom Menschen lesbare Datei zippen, oder einfach die datei lesbar machen, aber den Haupteil, die Daten, dann doch als Binärwert darzustellen?
Ich habe mir gerade mal bei Wiki den Eintrag zu XML durchgelesen. Macht durchaus Sinn für mich sowas nicht auch hier einzuführen. Das bedeutet, wir einigen uns irgendwann mal auf den Inhalt, und der wird dann eben XML konform dargstellt.

Ich finde den Ansatz von Oliver auch ganz toll, würde den aber gerne wirklich nur auf Motordaten beschränken. Die Idee links zu anderen Dateien herzustellen oder gar Bilder von dem Motor ist schon sehr viel. Evtl. kann man das ja als Option vorsehen. Also einen Datenblock der dann ein Bild enthalten kann.

So wie ich die Idee von Oliver und Malte verstanden habe, wird die Datei in Blöcke unterteilt. Jeder Block entspricht einem Datensatz. Der muss nicht unbedingt voll sein, sollte aber eben aufgeführt werden.
Ich würde dann gerne zu den Werten die Oliver genannt hat noch typische Werte eines Hybriden hinzu nehmen. Das wäre Brennkammerdruck (wie gehabt) und Tankdruck sowie ein paar typische Angaben wie z.B. Venthole.

Damit wir jetzt aber einen großen Punkt aus der Welt schaffen, werde ich eine kleine Umfrage hier starten um zu sehen wer jetzt für Maschinencode oder Klartext ist.

Gruß

Neil

Ich meinte menschenlesbares XML komprimieren.

Grüße
Malte

Hi,

ich weiß, meine Vorschlag geht nicht gerade in die Richtung einfachste Implementierung, aber die letzten Posts haben mich an ein bestehendes Format erinnert, das OpenDocument Format. Das baut wiederum auf XML auf, aber darum geht es nicht, das kann man auf eine beliebige andere Art und Weise auch lösen. Seht das Wort XML jetzt mal eher als Platzhalter (ich denke aber trotzdem dass es keine schlechte Wahl wäre).
In Anlehnung an ODF könnte das Format mal so aussehen:
Basisdatei ist eine gezippte XML Datei. Sie enthält alle Metadaten und die Messwerte in strukturierter Darstellung. Falls man jetzt will packt man zusätzlich zur XML Datei weitere Dateien in den ZIP-Container. Das können sein: Binärdaten (sinnvoll für Rohdaten und/oder sehr hochaufgelöste Daten), Bilder, Altimeterdateien, WRASP kompatible Dateien, etc...
Das Format wird dabei so ausgelegt, das man "beliebig" viele Messungen unterbringen kann um z.B. die Daten einer Familie (BC, AT, etc) in einem File unterzubringen oder um zeitliche Entwicklungen zu illustrieren oder einfach nur Varianten miteinander zu vergleichen.
Werden die oben angesprochenen zusätzlichen Dateien in das Format miteingepackt tut man sich leichter die Integrität des Datensatzes zu gewährleisten weil man das Risiko eliminiert das z.B. die referenzierten Dateien nicht mitkopiert werden.
Ganz nebenbei hat man immer noch mit Standardmitteln (Editor, Hexeditor, Bildbearbeitung) Zugriff auf die Einzeldaten, man braucht die Datei ja nur mit einem Entpacker öffnen.

Wenn man noch einen klitzekleinen Schritt weitergeht kann man gleich sagen das Format muss gar keine Schubkurven enthalten (und nennt es OpenRocketFormat ) . Manch einem reicht es ja wenn das Format die Druckpunktberechnung, die Altimeterdatei und ein Startfoto enthält.

Wichtig ist imho nur dass das Format (egal ob jetzt Prüfstandbezogen oder ein allgemeines Raketenformat) flexibel und erweiterbar ist, so dass sich z.B. ein einfaches Programm von zusätzlichen Bildern nicht irritieren lässt. Wenn man alle Wünsche auf einmal erfüllen will bekommt man ein Monsterformat für eine eierlegende Wollmilchsau und scheitert schon an der Spezifikation.

Gruß
Reinhard

Hi,

es scheint sich ja schon ein ergebnis in der Umfrage abzuzeichnen. Das ist schön, kommen wir ja dem Ergbnis näher.
Mir kam gestern Abend noch ein Punkt in den Kopf. Wir haben bei den Prüfstanddaten oder Umgebungsparameter immer statische Werte angenommen. Wenn jetzt aber einer mal auf die Idee kommt, seinen Motor während des Fluges zu vermessen, so ergibt das wieder weitere Variable Werte.
Ich will jetzt die Datei nicht mit noch mehr Datentabellen voll müllen, aber man sollte das evtl. berücksichtigen. Dabei kam mir dann eine Idee womit man dann auch Peters bedenken entgegenkommt. Wir gestalten das Format der Datei variabel im Bezug auf den Zeitstempel. Will sagen, das wir vor der Tabelle sagen, ob die Messwerte einen Zeitstempel haben oder nicht. Somit kann man dann jeden Messwert in der Tabelle mit oder ohne Zeitstempel speichern oder einfach als konstante stehen lassen. Das könnte dann so aussehen:


<temp>
timecode = 0 ; 0 = Constant, 1 = FixScanRate, 2 = TimeMark
ScanRate = 0 ; Hz
Unit = Degree Celsius
15,3
<End temp>

<thrust>
timecode = 1 ; 0 = Constant, 1 = FixScanRate, 2 = TimeMark
Scanrate = 10000 ; Hz
Unit = Newton
0
0
0
0
10
100
.
.
.
0
<End thrust>

<chamber preasure>
timecode = 2 ; 0 = Constant, 1 = FixScanRate, 2 = TimeMark
Scanrate = 0 ; Hz
Unit = nmm2
0 10
1 20
2 100
.
.
.
99 10
<End chamber preasure>



Was haltet ihr von der Idee?
Ich habe jetzt in der Datei Werte genommen die man lesen kann als Mensch. Man könnte aber auch einen Marker setzen der einem mit teilt ob die Werte so oder binär vorliegen?
Wobei so eine Datei nicht mehr von Excel gelesen werden kann. Aber ich denke da kann man sich auch eine Exportfunktion schreiben. Ist zwar gegen meine erste Idee und Einstellung, aber so ein Format gefällt mir immer besser.

Gruß

Neil

Geändert von Neil am 12. Oktober 2006 um 09:18

1. Du hast jetzt innerhalb einer Messung einen festen Zeitraum, du kannst Zeitbereiche als noch einfach überspringen.
2. Ich würde die Zahlenwerte binär speichern, was deutlich Platz spart. Ist zwar dann nur noch mit einem HexEditor lesbar, aber dafür _deutlich_ kleiner

mfG

Markus

Die Umfrage finde ich leider nicht ganz passend, denn ich würde zwei Optionen
favorisieren: Datei nicht Menschen-lesbar mit und ohne Zeitstempel - je nach
Verfügbarkeit der Daten aus dem Prüfstand.

Wenn der Prüfstand selbst Zeitstempel erzeugt, dann sollen die auch mit auf PC
abgespeichert werden bzw. wenn eine Kurve manuell erstellt oder verändert
wurde, macht es auch Sinn, wenn jeder Kurvenpunkt einen Zeitstempel hat. (Die
Kurvenpunkte müssen ja nicht gleiche Zeitabstände haben.)

Liefert der Prüfstand dagegen keinen Zeitstempel, gewährleistet aber eine feste
Abtast-Rate, dann macht es keinen Sinn, einen Datensatz auf dem PC künstlich
mit einem Zeitstempel aufzublähen. Da reicht es dann, die Abtastrate zu speichern.

Leider ist auch ein kleiner Fehler bei der Umfrage unterlaufen, das ist
missverständlich: Es gibt zweimal den Punkt "Für den Menschen nicht lesbar ohne
Zeitstempel."

Da ich selbst keine eigene Erfahrung mit Hybriden habe, wollte ich Dich (Neil) fragen,
was Du mit "Venthole" gemeint hast und was da abzuspeichern wäre. Ich würde mich
auch sehr für noch mehr Informationen über technische Daten von Hybriden,
Flüssigantrieben und Wasserraketen interessieren und die Bedürfnisse der
Betroffenen bei einem zu definierenden Format berücksichtigen.

Der Hinweis auf die "eierlegende Wollmilchsau" von Reinhard ist durchaus berechtigt,
wenn es um ein Programm geht, das alle Bedürfnisse befriedigen sollte. So ein Ziel
würde ich lieber nicht verfolgen. Ich denke wir sind besser bedient, wenn wir
mehrere kleine Programme haben, die verschiedene Bedürfnisse abdecken. Alle
Programme zusammen könnten so eine Art "Raketen-Office" bilden. Das verbindende
zwischen diesen Programmen wären die Datei-Formate, die durch eine von uns zu
definierende Formatierung leichter austauschbar wären.

Als Datei-Typen würden mir einfallen:
- Motor-Dateien (Prüfstand, Simulation, Eigenschaften, Kommentare,... s.o.)
- Flug-Dateien (Simulationsergebnisse, SALT-Messungen, Umgebungsparameter,...)
- Raketen-Dateien (Konstruktionsdaten, Druckpunkt/Schwerpunkt, Trägheitsmomente,...)

Ich weiss nur noch nicht so recht, wie man Wasserraketen hier unterbringen
könnte, da ihr Schub auch von der Beschleunigung und damit von den Flugdaten
abhängt (sind zwar nur ein paar Prozent, aber die möchte ich nicht unter den
Tisch kehren). Das würde eine Überlagerung von Motor- und Flugdaten bedeuten.
Vielleicht brauchen Wasserraketen doch eine Extra-Behandlung.

Gruß,
Oliver

Zitat:

---

Was haltet ihr von der Idee?

---

Vier Dinge sind nicht gut:

1. Warum nicht XML Tags verwenden? Du kreierst neue Tags, die keine bestehende Software versteht. So unleserlich ist </temp> nun auch wieder nicht, dass man stattdessen <End temp> schreiben müsste.
2. Wenn man nun so etwas macht, was nur auf den ersten Blick so aussieht wie XML, aber keines ist, dann muss man alles neu schreiben, d.h. man macht sich nur einen Haufen Arbeit.
3. Wenn man nun annimmt, dass beabsichtigt war, ein XML File zu bauen, mit wenig strukturiertem Inhalt der einzelnen Tags, dann muss man berücksichtigen, dass XML bei XSL-Transformationen einen relativ liberalen Umgang mit Whitespace pflegt. D.h. Zeilenumbrüche bleiben nicht unbedingt erhalten. Man sollte also entweder durch CDATA oder durch zusätzliche Tags sicherstellen, dass keine Zweideutigkeiten entstehen können.
4. Da der Inhalt der Tags aus XML Sicht völlig unstrukturiert ist, kann man mit XML-Bibliotheken nichts mit diesem Fileformat anfangen. Dazu müssten die einzelnen Bestandteile mit XPath adressierbar sein. Man muss sich also fragen, warum man überhaupt XML einsetzt, so bringt XML nur gerade das Framing: man kann die einzelnen Bestandteile des Files auseinanderhalten. Das könnte man aber auch, in dem man zum Beispiel auch mit simpleren Methoden, wie zum Beispiel definierten Headern, die durch ein reserviertes Zeichen eingeleitet werden, genausogut und wohl eher noch lesbarer erreichen.

Warum nicht einfach ein richtiges XML Format verwenden, wie es Reinhard vorgeschlagen hat (modulo kleine Korrekturen, welche schon diskutiert worden sind), und für die Präsentation ein XSL-Stylesheet zu diesem Format definieren? Damit liesse sich eine besser lesbare Darstellung (Layout, Schriftarten, Schriftgrade, Farben) als jedes reine Textformat erreichen, ohne dass auch nur eine einzige Zeile Code geschrieben werden müsste. Bei Verwendung eines FOP Prozessors kann man daraus statt Webpages auch PDF generieren, ohne eine Zeile Code. Nach Transformation mit weiteren XSL Stylesheets liesse sich dieses Format dank SVG dazu verwenden, Schubkurven oder andere Parameter graphisch darzustellen, und zwar als Vektorgraphik, d.h. ohne Einschränkung der Auflösung, diese könnten in grosser Genauigkeit ausgedruckt werden. Ebenfalls ohne eine einzige Zeile Code. Da XSLT Turing vollständig ist, wäre es sogar grundsätzlich möglich, zum Beispiel die Berechnung des Gesamtimpulses oder die Konvertierung von Masseinheiten in einem Stylesheet zu machen. Die Stylesheets hierfür wären vermutlich etwas komplexer.

Warum Code schreiben für etwas, was gar keinen Code (ausser XSL Stylesheets) braucht? Warum Programme bauen, wenn die nötigen Programme (Browser) auf allen Plattformen bereits existieren? Wenn diese Programme zu wenig Komfort bieten, kann man immer noch eine Oberfläche darumherum entwickeln, die diese Kernfunktionen noch etwas schöner integrieren. Warum altertümliche Methoden verwenden, wenn nur leicht modernere Methoden eine derartige Erleichterung bringen können?

Hi,

ich fange mal mit den Antworten an:

@MarkusJ:

1. Was meinst du damit genau? Wenn du verschiedene Aufzeichnungsgeräte verwendest, kann es sein, das du einmal eine feste Abtastrate hast und einmal eine variable. Als macht es Sinn die Möglichkeit zu offenbaren für einen Versuch verschiedene Methoden der Datenspeicherung anzubieten.

2. Ich mich selber mal

Zitat:

---

Ich habe jetzt in der Datei Werte genommen die man lesen kann als Mensch. Man könnte aber auch einen Marker setzen der einem mit teilt ob die Werte so oder binär vorliegen?

---

@osmadie:

Ich meine die Umfrage so aufgebaut zu haben, das du mehrere Punkte angeben kannst als Wunschformat. Es kommt beide Kombinationen vor in der Frageliste.

Alles über Hybride per PM und nicht hier im Thread.

Zitat:

---

Leider ist auch ein kleiner Fehler bei der Umfrage unterlaufen, das ist
missverständlich: Es gibt zweimal den Punkt "Für den Menschen nicht lesbar ohne
Zeitstempel."

---

Erledigt, das passiert wenn man stur kopiert ohne nachzudenken

@Andreas Mueller:

Ich hatte nicht vor was neues neben XML zu erfinden. Ich habe versucht was heraus zu finden über XML. Das was ich gefunden habe hat mich positiv gestimmt. Ich wollte nur das was ich im Text erklärt habe nochmal als Pseudocode darstellen damit es deutlicher wird. Das unabhänig irgendwelcher Formate.
Ich denke du hast verstanden was ich meine, in der Datei soweit die Information zu den Daten angeben, das diese beliebig sein können aber immer interpretierbar. Ich glaube das ist ja auch der Sinn hinter XMl. Wenn du mir also sagst, das meine Idee von oben mit XML funktioniert dann bin ich zufrieden.
Die Idee einfach ein fertiges Modul zu haben in der Software welches in etwa so funktioniert:

Datei --> BlackBox --> schöner Graphen

Gefällt mir, da sich dann jeder spart code zu schreiben um eine Datei zu lesen.
Wenn du mir Quellen nenne kannst zu XML wo erklärt wird wie das funktioniert und nicht wer es warum erfunden hat, wäre ich dankbar.

Gruß

Neil

Zitat:

---

Original geschrieben von Neil
Die Idee einfach ein fertiges Modul zu haben in der Software welches in etwa so funktioniert:

Datei --> BlackBox --> schöner Graphen

---

XML und XSLT können eben noch etwas mehr. Ganz rechts kann noch ganz anderes stehen, zum Beispiel "Motordokumentation in PDF", "WRASP File", Rocksim-File, Eng-File.

Und auf der linken Seite könnte eben auch noch etwas mehr stehen als nur "Datei". Zum Beispiel "URL". D.h. man klickt auf einen URL, der ein solches Datenfile referenziert. Ein Webserver liefert die Datei, wobei diese auch aus einer Datenbank on the fly hergestellt werden kann (damit würde man noch etwas mehr Flexibilität darin bekommen, was man mit den Daten anstellen möchte, nur so sind zum Beispiel die Qualtitätsprüfungsaspekte realisierbar, die Du in einem früheren Post angesprochen hast ). Die BlackBox, besser bekannt unter dem Namen "Browser" macht daraus dann eine der verschiedenen Darstellungen.

Alternativ könnte die "BlackBox" auch ein Bestandteil des Webservers sein, so dass der Benutzer gleich das formattierte Endprodukt bekommt. Es ist ja durchaus schon ein Weile üblich, Datenobjekte als XML darzustellen und die Präsentationsaspekte durch Transformation einzubringen. Vor ein paar Jahren habe ich zum Beispiel ein System gebaut, welches Produktdatenblätter für technische Produkte in XML beschreibt (Daten kommen aus einer Datenbank) und je nach Benutzerwunsch on the fly mit XSLT in HTML, JPG, PNG oder PDF umwandelt.

Daher auch mein ursprünglicher Vorschlag, thrustcurve.org (die Software, nicht die Website) nicht aus den Augen zu verlieren. Jenes System kann eigentlich alles, ausser ein wirklich flexibles Format, wie es Reinhard vorgeschlagen hat. Es hat eine Datenbank, es hat eine Suchfunktion, es fehlt nur noch die Transformationen der Daten von und in ein universelles Format. Ausserdem hat thrustcurve.org viele Daten, die uns auch interessieren, und ohne die, wage ich zu behaupten, "thrustcurve.de" bestenfalls eine Insellösung wäre. Und die dort eingesetzte Technologie ermöglicht auch, dass man das alles auch lokal auf dem eigenen Rechner (nicht nur PC) haben kann. Thrustcurve.de jederzeit, auch ohne Internet-Verbindung.