Base de données de pièces - plaa/Modular GitHub Wiki
Cette page concerne la planification de l’implémentation d'un projet de base de données de pièces dans OpenRocket et ainsi permettre de découper l’implémentation en petites taches.
Pour le moment dans OpenRocket, les détails des pièces fusées doivent être rentrés à la main chaque fois qu'une fusée est conçue. Par exemple, lorsqu'un tube est ajouté le diamètre interne, le diamètre externe et les matériaux ont besoins d'être spécifiés. Cependant de nombreuses pièces fusées généralement utilisées sont des composants standard dont les spécifications sont déjà connue. Il pourrai être utile de permettre aux utilisateurs d'OpenRocket de sélectionner par exemple un tube en fonction du fabriquant et du type, et d'avoir seulement à spécifier les dimensions variable: c'est à dire, sélectionner un tube Estes BT-60 (qui définira les dimensions du tube et son matériau), et ensuite spécifier une taille de 50 cm.
La fonctionnalité nécessaire pour répondre à ce besoin peut être morcelée de la façon suivante:
Un standard ouvert et extensible pour spécifier tous les détails concernant les pièces fusées. Le choix qui tombe sous le sens est un format XML. OpenRocket devra être capable de lire et écrire ce format.
Le format pourrai également permettre l'utilisation de pièces ne faisant pas parti de la structure comme les moteurs fusées, wadding ou des feuilles de nomex pour la protection du dispositif de récupération, etc - n'importe quel pièce qui est rattaché à la fusée.
La spécification initiale des champs XML et la structure peuvent être généré en regardant the ORK rocket design format for what it stores for parts data.
Est ce que la base de données de pièces devrait être liée à OpenRocket (ORC)? Idéalement le format pourrai également être adopté par d'autres logiciels ... Plaa 19:24, 8 Octobre 2011 (UTC)
Les données de pièces devront etre d'une façon ou d'une autre converties en fichiers ORC XML, soit par les fabriquants eux meme ou des volontaires pationnés. 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.
L'utilitaire import/export pourrai être construit dans le logiciel OpenRocket lui même, ou pourrai être un programme indépendant.
Modifications nécessaire à l'application OpenRocket pour pouvoir utiliser la fonctionnalité pièces:
- OpenRocket doit être capable de lire et écrire des fichiers XML ORC.
- Stocker toutes les pièces en dehors du code du programme (c'est à dire, dans les fichiers ORC XML ).
- Ne pas permettre à l'utilisateur de modifier ou d'écrire par dessus des pièces standard mise à disposition par OpenRocket, à la place permettre à l'utilisateur de copier, modifier et stocker de nouvelles pièces personnalisées.
- Lorsque l'utilisateur choisi d'ajouter une pièce au projet, permettre à l'utilisateur d'en choisir une dans la bibliothèque de pièces, ou de créer une nouvelle pièce en utilisant les spécifications existantes de l'interface utilisateur (UI).
Une fonctionnalité utile pour les utilisateurs d'OpenRocket serai une bibliothèque en ligne de fichiers pièces pour OpenRocket, un lieu dédié pour trouver les dernières versions des fichiers de pièces. Cela permettrai au logiciel OpenRocket d'obtenir les derniers fichiers de pièces depuis 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.
En plus des pièces de fusées commerciales, la bibliothèque pourrai stocker des pièces non-commerciales, comme par exemple une combinaison de pièces qui forment une plus grosse pièce utilisée souvent. 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.
Difficulté/bazar Potentiel: quelqu'un devra être en charge de la bibliothèque. 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.
- Permettre la mise à jour des fichiers de pièces depuis la bibliothèque de pièces d'OpenRocket:
- 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).
- Permettre la création et le téléchargement de pièces personnalisée
- Concevoir un format XML pour stocker des bases de données de pièces: Format XML de base de données de pièces
- Write schema for the format
- Implement framework for using standard components
- Class RocketComponentPreset ?
- 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 (ex. longueur du tube du corps)
- Implementer une base de données pour stocker des pièces standard
- Maintain user-selectable presets list (user can choose which components are in an easy-to-access presets list)
- Implementer des methodes pour lire le format XML
- Implementer des methodes pour lire le format CSV
- Implémenter une interface utilisateur graphique pour choisir la pièce
- Pre-remplir la liste déroulante
- Un bouton pour ouvrir la fenetre de dialogue de selection
- Dialog allows selecting which components are displayed in the preset list
- Implémenter une interface utilisateur graphique pour créer des pièces(?)
- Pratique pour les fabricants
- 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?