You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
vincent 0e1e4ba497 Suivi des hashtags sur osmcha 2 weeks ago
assets Ajoute quelques liens vers d'autres cartes 2 weeks ago
bin Add initial set of files 5 months ago
config Groupe les outils 2 weeks ago
doc ajoute le tuto projet 3 months ago
migrations essaie de trouver les changesets 4 months ago
public Add initial set of files 5 months ago
src Change l'ordre de tri des projets 2 weeks ago
templates Suivi des hashtags sur osmcha 2 weeks ago
translations ajoute le tri des tâches sur la page projet 4 months ago
.env ajoute quelques bricoles 4 months ago
.gitignore ajoute la dépendance à php-cs-fixer 3 months ago
.php-cs-fixer.dist.php ajoute la dépendance à php-cs-fixer 3 months ago
COPYING ajoute la license 3 months ago
README.md commente un peu plus le projet 3 months ago
compose.override.yaml gère les projets 5 months ago
compose.yaml gère les projets 5 months ago
composer.json ajoute la dépendance à php-cs-fixer 3 months ago
composer.lock composer update 2 weeks ago
importmap.php wip 4 months ago
symfony.lock ajoute la dépendance à php-cs-fixer 3 months ago

README.md

Gestionnaire de tâches simple

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.

Idée de départ

L'idée serait de faire une application Symfony pour gérer simplement des tâches de cartographie.

  • authentification OAuth2 sur OSM pour ne pas avoir à créer de compte
  • télécommande JOSM
  • priotité avec matrice de Eisenhover importance/urgence
  • carte maplibre ou leaflet synchronisée avec la liste des tâches
  • possibilité de modifier les tâches en masse (actions groupées)
  • stockage des données dans sqlite
  • presets dans le projet pour envoyer à JOSM (genre hashtags du message de commit, etc)

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.

Mise en place technique

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 »)