vincent 8cc2eea7cf | 2 months ago | |
---|---|---|
assets | 2 months ago | |
bin | 4 months ago | |
config | 2 months ago | |
migrations | 3 months ago | |
public | 4 months ago | |
src | 2 months ago | |
templates | 2 months ago | |
translations | 4 months ago | |
.env | 3 months ago | |
.gitignore | 2 months ago | |
.php-cs-fixer.dist.php | 2 months ago | |
COPYING | 2 months ago | |
README.md | 2 months ago | |
compose.override.yaml | 4 months ago | |
compose.yaml | 4 months ago | |
composer.json | 2 months ago | |
composer.lock | 2 months ago | |
importmap.php | 4 months ago | |
symfony.lock | 2 months ago |
Voici un outil pour faciliter le travail collaboratif autour d’un projet. Le projet regroupe des tâches que les contributeurs OSM peuvent s’approprier et traiter dans JOSM.
L'idée serait de faire une application Symfony pour gérer simplement des tâches de cartographie.
On créé un projet (titre, description), on peut manipuler les tâches d'un projet (ajouter par import geojson, supprimer, diviser en n×n ou en surface (on en déduit n)) et pour chacune d'elle on trouve un statut historicisé (à faire, en cours, fait) pour chaque action (mapper, vérifier). On peut imagine que certains status lockent la tâche qui se délocke au bout d'un certain temps.
Peut-être préférer un workflow : à mapper → mappage en cours → mappage terminé à vérifier → vérification en cours → vérifié Où les étapes en cours sont lockantes et reviennent au statut précédent au bout d'une journée
Un système de commentaires arborescent sur les tâches serait pas du luxe (lien avec le statut via la date).
On peut faire des statistiques par projet sur les statuts des tâches. Et rappeller les commentaires par ordre antéchronologique globalement sur le projet.
En tous cas l'idéal serait de pouvoir faire tout ça via une api et de fournir un client web en js moderne. Un client en ligne de commande serait pas du luxe non plus.
Il s’agit d’un petit projet Symfony (7.1.3) donc essentiellement en PHP (développé avec la version 8.2.23) avec un peu de Javascript (utilisation du framework Stimulus suggéré par Symfony) et de CSS (utilisation du framework Bootstrap). Les données sont stockées dans une base SQLite localement.
Les dépendances PHP sont gérées assez classiquement par Composer. On peut donc
les récuperer avec un simple composer install
dans la racine de
l’application.
On peut le faire tourner en local pour tester/développer grâce à l’outil en
ligne de commande symfony
et notamment en
démarrant un serveur local : symfony serve -d
.
L’application peut être servie par un serveur web (nginx, Apache, etc) comme
une application Symfony classique (la racine du serveur web étant dans
/public
) pour peu qu’il interprète le PHP. Il n’y a pas de référence à des
noms de domaines donc pas de soucis pour les adresses web absolues.
La configuration de l’application se fait dans un fichier .env.local
(s’inspirer du .env
fourni) dans lequel il faut essentiellement renseigner
les variables :
APP_TIMEZONE
a priori Europe/Paris
OSM_CLIENT_ID
et OSM_CLIENT_SECRET
à générer dans les options de son
compte OSM (onglet « application OAuth2 » avec comme URI de redirections
l’adresse web de son instance suffixée du chemin /osm/callback
et comme
autorisation, uniquement « Lire les préférences de l’utilisateur »)