Currently the values are stored with 5 significant digits, using
TextUtil.doubleToString. There's no real reason for storing more
The data in the FlightDataBranches could be changed to floats and I
considered this. However everything else in OR works with double
precision, so this interface should too. And I estimated that the
data doesn't take that much memory that the difference between float
and double is relevant - and if it was discovered to be relevant it
can be changed.
Importing data has always been in consideration, but never
implemented. There's some rudimentary support, mainly that a
Simulation can have type Simulation.Status.EXTERNAL, indicating
imported data. But no further implementation exists.
If you're interested in the import functionality it should ideally be
based on the new plugin system (still a bit under development). You
should be able to write plugins for different sources of data, for
example a CSV file or an altimeter. (I've already got routines for
downloading data from two altimeter models.) There's probably some
potential common stuff, like matching the data to the OR data types or
computing some parameters from other (e.g. velocity from altitude).
On Mon, Jan 7, 2013 at 10:33 AM, Richard Graham <richard@...> wrote:
> I have just finished the work I was doing re-organizing on the container
> format and getting the flight data into the container.
> This is in my github branch openrocket-rdg. I was working off master
> before todays merge, so I still need to update it once I figure out how
> to merge it properly. Hopefully this should be a good start to the
> container / external resource management which has been discussed here
> in the various threads.
> As for the file format, I at first tried saving the double data
> directly, surprisingly this actually resulted in much larger files
> because of the significant rounding which is done when the data is
> written as a string. Saving as floats gives slightly bigger files and
> more precision, but in the end I just left it as ASCII. It does raise a
> question though ... if it is acceptable to save the data with
> significantly less precision than a float, why not use floats in the
> data branches?
> One other thing -- I remember at some stage someone mentioning there was
> some code around for importing data from various accelerometer (?)
> formats, does anyone know anything about that? I was thinking of
> implementing data importing soon, although for a start probably just csv
> support should be sufficient.
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. SALE $99.99 this month only -- learn more at:
> Openrocket-devel mailing list
Sampo Niskanen <=> http://www.iki.fi/sampo.niskanen/