J'ai commencé à bosser sur un projet similaire, mais en version "web" il y a quelques jours, avant qu'un ami ne me parle d'OpenJardin...
Je ne sais pas dans quelle mesure nos actions pourraient être mutualisables vu la différence de cible (je vise une utilisation "sur mobile", à terme, pour certaines actions), mais quelque part je trouve ça dommage de faire les choses deux fois...
Le projet en est à son début de vie, il change et évolue de jours en jours; je n'ai donc publié aucune source pour le moment. Une espèce de démo sans persistance de données est dispo là: https://vuejs.experimentslabs.com/garden_party/
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Je viens juste de voir le message.
J'ai vu l'article sur https://linuxfr.org/news/gestion-de-jardin-garden-party,
C'est une excellente idée de passer sur une version web. j'ai vu le site de démo c'est déjà bien avancé notamment la partie graphique avec OpenStreetMaps. Je ne sais pas dans quelle mesure il est possible de mutualiser car ce sont deux domaines distinctes, sinon au niveau des bases de données qui sont en sql.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Des premiers retours que je peux avoir les attributs que nous avons sur Garden Party sont incomplets. Je pens qu'à terme ils se rapprocheront de ceux des plantes proposées par OpenJardin. Une idée serait peut-être de mutualiser ces données (sur Garden Party, une API est disponible pour les utilisateurs avec un compte, pour le moment) un système d'import dans OpenJardin pourrait être intéssant ?
Avoir un format de données commun pour passer de l'un à l'autre ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Après une année un peu chargée et pas mal de réflexion autours de la gestion de données de GardenParty, j'ensuis arrivé à la conclusion suivante: gérer les données communes c'est fastidieux.
Donc j'en suis arrivé à faire un dépôt séparé pour les "données de confiance", sur lesquelles les instances de GardenParty peuvent se synchroniser. Ces données sont des fichiers YAML, donc facilement modifiables/parsable.
Si vous souhaitez qu'on bosse sur un système d'export au format OpenJardin, on pourrait imaginer la chose suivante:
- Ajouter des champs nécessaires à OpenJardin (et qui pourraient aussi servir à GardenParty ou d'autres projets)
- Dans OpenJardin, avoir la fonctionnalité pour importer ces fichiers directement (ou écrire écrire un petit script pour exporter une base SQLite dédiée à OpenJardin, dans le dépôt de données)
Dans tous les cas je serais ravi de pouvoir aider sur un script générant la base SQLite, mais ne souhaite pas intégrer les fichiers exportés dans le dépôt (un artefact de CI pourrait faire le job, celà dit)
Hello !
J'ai commencé à bosser sur un projet similaire, mais en version "web" il y a quelques jours, avant qu'un ami ne me parle d'OpenJardin...
Je ne sais pas dans quelle mesure nos actions pourraient être mutualisables vu la différence de cible (je vise une utilisation "sur mobile", à terme, pour certaines actions), mais quelque part je trouve ça dommage de faire les choses deux fois...
Le projet en est à son début de vie, il change et évolue de jours en jours; je n'ai donc publié aucune source pour le moment. Une espèce de démo sans persistance de données est dispo là: https://vuejs.experimentslabs.com/garden_party/
Je viens juste de voir le message.
J'ai vu l'article sur https://linuxfr.org/news/gestion-de-jardin-garden-party,
C'est une excellente idée de passer sur une version web. j'ai vu le site de démo c'est déjà bien avancé notamment la partie graphique avec OpenStreetMaps. Je ne sais pas dans quelle mesure il est possible de mutualiser car ce sont deux domaines distinctes, sinon au niveau des bases de données qui sont en sql.
Des premiers retours que je peux avoir les attributs que nous avons sur Garden Party sont incomplets. Je pens qu'à terme ils se rapprocheront de ceux des plantes proposées par OpenJardin. Une idée serait peut-être de mutualiser ces données (sur Garden Party, une API est disponible pour les utilisateurs avec un compte, pour le moment) un système d'import dans OpenJardin pourrait être intéssant ?
Avoir un format de données commun pour passer de l'un à l'autre ?
Bonjour,
actuellement on utilise une base SQLITE, on trouve dans le fichier ci-joint les requêtes d'initialisation de la base, avec les données minimales des plantes, espèces, familles etc: en français / https://sourceforge.net/p/openjardin/code/ci/master/tree/sql/restore.sql et en anglais https://sourceforge.net/p/openjardin/code/ci/master/tree/sql/restore_en.sql
Je pense que les deux projets sont complémentaires car actuellement openjardin est un client lourd sans accès à sa base de données à distance.
Last edit: open04 2021-01-06
Bonjour Christian !
Après une année un peu chargée et pas mal de réflexion autours de la gestion de données de GardenParty, j'ensuis arrivé à la conclusion suivante: gérer les données communes c'est fastidieux.
Donc j'en suis arrivé à faire un dépôt séparé pour les "données de confiance", sur lesquelles les instances de GardenParty peuvent se synchroniser. Ces données sont des fichiers YAML, donc facilement modifiables/parsable.
Si vous souhaitez qu'on bosse sur un système d'export au format OpenJardin, on pourrait imaginer la chose suivante:
- Ajouter des champs nécessaires à OpenJardin (et qui pourraient aussi servir à GardenParty ou d'autres projets)
- Dans OpenJardin, avoir la fonctionnalité pour importer ces fichiers directement (ou écrire écrire un petit script pour exporter une base SQLite dédiée à OpenJardin, dans le dépôt de données)
Dans tous les cas je serais ravi de pouvoir aider sur un script générant la base SQLite, mais ne souhaite pas intégrer les fichiers exportés dans le dépôt (un artefact de CI pourrait faire le job, celà dit)
Le dépôt de données: https://gitlab.com/experimentslabs/garden-party/data
Au plaisir d'avancer ensemble !