Difference between revisions of "Component databases"
Soupwizard (talk | contribs) |
Soupwizard (talk | contribs) |
||
| Line 11: | Line 11: | ||
=== OpenRocket Component (ORC) Format === | === 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. | + | 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. | ||
| + | |||
| + | === 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. | ||
| + | |||
| + | This idea could even be extended to cover entire rockets, as they are assemblages of smaller components. | ||
| + | |||
| + | Over time, the rocketry community could build an open library of components and ideas to use in constructing rockets, and indeed entire rocket designs. | ||
=== Import and Export Tools for the OpenRocket Component Format === | === Import and Export Tools for the OpenRocket Component Format === | ||
| Line 17: | Line 29: | ||
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. | 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 utility could be built into the OpenRocket software itself, or could be a separate program. | + | The import/export utility could be built into the OpenRocket software itself, or could be a separate program. |
| + | |||
| + | === User-Created Components (Collaborative c === | ||
| + | In addition to commercial | ||
== Software Design == | == Software Design == | ||
Revision as of 11:12, 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.
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.
This idea could even be extended to cover entire rockets, as they are assemblages of smaller components.
Over time, the rocketry community could build an open library of components and ideas to use in constructing rockets, and indeed entire rocket designs.
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.
User-Created Components (Collaborative c
In addition to commercial
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?