Component databases

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 known. 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.

OpenRocket Component (.orc) XML File Format

XML format for storing component databases: Component database XML format

Functionality To Be Built

The functionality needed to support the above use case can be broken down into the following:

Phase 1

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.

The initial specification of the XML fields and structure can be generated by looking at the ORK rocket design format for what it stores for parts data.

Should the component db extension be tied to OpenRocket (ORC)? Ideally the format would be adopted by other software as well... Plaa 19:24, 8 October 2011 (UTC)

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 Jasa seo, Jasa seo jakarta, Wedding organizer.

The import/export utility could be built into the OpenRocket software itself, or could be a separate program.

Modifications to OpenRocket Client

Changes needed to the OpenRocket application to make use of the component functionality:

• OpenRocket must support reading and writing of ORC XML files.
• Store all component data outside the program code (ie, in ORC XML files).
• Don't allow user to modify or overwrite standard OpenRocket supported part, instead allow user to copy, modify, and store new 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.

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, and provide both a web UI for people to view the library, and a web api to allow software to update or retrieve component info.

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.

Modifications to OpenRocket Client

• Allow updating of component files from the OpenRocket component library:
  • From an online connection to the library web api
  • From a snapshot set of updated ORC files, for users who do not have internet access (for example, out at a launch site).
• Allow creation and uploading of custom components

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?