Difference between revisions of "Component databases"
Soupwizard (talk | contribs) |
Soupwizard (talk | contribs) |
||
| Line 29: | Line 29: | ||
Over time, the rocketry community could build an open library of components and ideas to use in constructing rockets, and indeed entire rocket designs. | Over time, the rocketry community could build an open library of components and ideas to use in constructing rockets, and indeed entire rocket designs. | ||
| − | For rocket motors, we could obtain curated motor data from thrustcurve.org via their internet API. Would we want to use their data directly (each OpenRocket user's instance reads from thrustcurve.org), or would we pull data and store in the OpenRocket library? (or give the option to do either?). Having the OpenRocket program communicate directly with thrustcurve.org (or for that matter, any data source (estes, etc)) would put additional, possibly unwanted, load on their servers. | + | For rocket motors, we could obtain curated motor data from thrustcurve.org via their internet API. Would we want to use their data directly (each OpenRocket user's instance reads from thrustcurve.org), or would we pull data and store in the OpenRocket library? (or give the option to do either?). Having the OpenRocket program communicate directly with thrustcurve.org (or for that matter, any data source (estes, etc)) would put additional, possibly unwanted, load on their servers. Also, for OpenRocket users who do not have internet access (or sporadic access), having OpenRocket retrieve all it's component data from the library in ORC format allows those disconnected users to manually update their component files by putting a updated snapshot of the library (via usb stick, or infrequent download) on their machine. |
Potential messiness: someone will have to maintain the library. Maybe divide the library between official OpenRocket supported components (data from manufacturers, approved submitters and/or rocketry clubs, etc), and a general open-upload section. | Potential messiness: someone will have to maintain the library. Maybe divide the library between official OpenRocket supported components (data from manufacturers, approved submitters and/or rocketry clubs, etc), and a general open-upload section. | ||
| Line 35: | Line 35: | ||
=== Changes to OpenRocket Program === | === Changes to OpenRocket Program === | ||
| − | + | Changes needed to the OpenRocket application to make use of the above new fuctionality: | |
| − | + | ||
| − | + | * OpenRocket must support reading and writing of ORC XML files. | |
| − | + | * Store all component data outside the program code (ie, in ORC XML files). | |
| + | * Allow updating of component files from the OpenRocket component library (or from a snapshot set of updated ORC files, for users who do not have internet access). | ||
| + | * Don't allow user to modify or overwrite of standard parts files, instead allow user to copy, modify, and store customized parts. | ||
| + | * When user chooses to add a part to a design, allow user to pick one from the component library, or to create a new part using the existing parts specification UI. | ||
== Software Design == | == Software Design == | ||
Revision as of 10:46, 28 August 2011
Introduction
This page is for planning the implementation of component databases in OpenRocket and splitting the implementation into smaller tasks.
Currently in OpenRocket, details about rocket components must be entered by hand every time a rocket is designed. For example, when a body tube is added both the inner diameter, outer diameter, and material need to be specified. However, many of the rocket components generally used are standard commercial items whose design specifications are already know. It would be useful to allow OpenRocket users to, for example, select a body tube by manufacturer and type, and only have to specify the variable dimensions: ie, select an Estes BT-60 tube (which will set the tube dimensions and material), then specify a length of 50 cm.
Functionality To Be Built
The functionality needed to support the above use case can be broken down into the following:
OpenRocket Component (ORC) Format
An open and extensible standard for specifying all relevant details about rocket components. The obvious choice is an XML format. OpenRocket will need to be able to read and write this format.
The format could also allow non-structural components such as rocket motors, wadding or nomex sheets for recovery device protection, etc - any item that is attached to a rocket.
Import and Export Tools for the OpenRocket Component Format
Component data will somehow have to converted into ORC XML files, either by the manufacturers themselves or hobby volunteers. It is unreasonable to expect that manufacturer's staff or hobbyists will have the expertise and time to hand-code component XML files. It is more likely that intermediate spreadsheet files will be created with component data. Therefore, we will need a utility to convert both ways between the ORC XML format and standard comma-separated (CSV) value spreadsheet files.
The import/export utility could be built into the OpenRocket software itself, or could be a separate program.
Online Library of OpenRocket Components
A useful feature for OpenRocket users would be an online library of OpenRocket component files, a canonical location for the latest version of component files. This would allow the OpenRocket software to obtain the latest component files via the internet.
In addition to commercial rocket components, the library could store non-commercial components, such as combinations of components that form a larger useful piece. For example, an ejection baffle can be created from 3 smaller components: a tube coupler and 2 thin bulkheads with holes drilled in the in various patterns.
Over time, the rocketry community could build an open library of components and ideas to use in constructing rockets, and indeed entire rocket designs.
For rocket motors, we could obtain curated motor data from thrustcurve.org via their internet API. Would we want to use their data directly (each OpenRocket user's instance reads from thrustcurve.org), or would we pull data and store in the OpenRocket library? (or give the option to do either?). Having the OpenRocket program communicate directly with thrustcurve.org (or for that matter, any data source (estes, etc)) would put additional, possibly unwanted, load on their servers. Also, for OpenRocket users who do not have internet access (or sporadic access), having OpenRocket retrieve all it's component data from the library in ORC format allows those disconnected users to manually update their component files by putting a updated snapshot of the library (via usb stick, or infrequent download) on their machine.
Potential messiness: someone will have to maintain the library. Maybe divide the library between official OpenRocket supported components (data from manufacturers, approved submitters and/or rocketry clubs, etc), and a general open-upload section.
Changes to OpenRocket Program
Changes needed to the OpenRocket application to make use of the above new fuctionality:
- OpenRocket must support reading and writing of ORC XML files.
- Store all component data outside the program code (ie, in ORC XML files).
- Allow updating of component files from the OpenRocket component library (or from a snapshot set of updated ORC files, for users who do not have internet access).
- Don't allow user to modify or overwrite of standard parts files, instead allow user to copy, modify, and store customized parts.
- When user chooses to add a part to a design, allow user to pick one from the component library, or to create a new part using the existing parts specification UI.
Software Design
Tasks
- Design XML format for storing component databases: Component database XML format
- Write schema for the format
- Implement framework for using standard components
- RocketComponentPreset class?
- loadPreset(PresetComponent) method in RocketComponent?
- Remember what is used as a preset component
- When changing critical variables preset component is cleared (e.g. diameter of body tube), but not when changing others (e.g. length of body tube)
- Implement database for storing standard components
- Maintain user-selectable presets list (user can choose which components are in an easy-to-access presets list)
- Implement methods for reading XML format
- Implement methods for reading CSV format
- Implement GUI for component selection
- Preset dropdown
- Button for opening selection dialog
- Dialog allows selecting which components are displayed in the preset list
- Implement GUI for creating components(?)
- Useful for manufacturers
- How to store the preset info in ORK file? Should the entire preset info be included, or just a digest that is used in case the preset is already loaded and available?