Ajout nouveaux facteurs et MAJ données anciens#179
Conversation
back/plantability/management/commands/c01_compute_plantability_indice.py
Outdated
Show resolved
Hide resolved
| const score = computed(() => { | ||
| if (props.index < -3) return 0 | ||
| if (props.index < -2) return 2 | ||
| if (props.index < -0.5) return 4 | ||
| if (props.index < 0.75) return 6 | ||
| if (props.index < 1.5) return 8 | ||
| return 10 | ||
| }) | ||
|
|
There was a problem hiding this comment.
J'ai gardé ici un score entre 0 et 10 au clic par pédagogie (thresholds les mêmes que ceux de couleur)
C'est sans doute à raffiner avec des tests utilisateurs pour le nombre de classe / découpage.
There was a problem hiding this comment.
Non, tu ne devrais pas définir deux fois la même chose dans le front & le back, si besoin de cette échelle, tu peux ajouter une requête api pour l'obtenir ? O
Une solution serait que ce que tu stockes en base soit réellement ces valeurs là dans normalized indice
Comme les score sont associés à des labels, peut-être peut-on simplement ne pas afficher le score mais seulemnet le label ?
There was a problem hiding this comment.
Pour l'instant favorable à afficher le score car c'est ce qu'a défini Geoffrey dans ses maquettes mais on peut en discuter avec lui.
J'ai bougé le calcul du normalized indice pour que ce soit directement la valeur seuillée vu qu'on ne sert nul part de la valeur brute, ce qui résous le doublon.
| if (score.value === 0) return "Plantation impossible" | ||
| if (score.value === 2) return "Plantation très contrainte" | ||
| if (score.value === 4) return "Plantation contrainte" | ||
| if (score.value === 6) return "Plantation neutre" | ||
| if (score.value === 8) return "Plantation favorisée" | ||
| return "Plantation très favorisée" |
There was a problem hiding this comment.
Ces nommages proviennent du calque V1 et avaient été choisis avec des acteurs de terrain
There was a problem hiding this comment.
D'une manière générale, s'il y a besoin de commenter une PR avec des commentaires, c'est que ces derniers auraient mérité leur place dans le code.
Dans le code, grâce à Quentin notamment, on aurait utilisé un enum ici.
Marc-AntoineA
left a comment
There was a problem hiding this comment.
Remarques générales :
- sur la partie données, toujours une frustration de ma part de cette absence de tests mais ok. Mettre à jour la doc ?
- sur le refacto, quand tu déplaces puis modifie des fonctions, tu peux le faire en deux fois avec un nom de commit ultra explicite. Comme ça, en ciblant les bons commits, je peux voir quelles modifs ont été faites ;
- Je pense tu peux déjà ajouter une entrée dans le changelog avec des explications et capture d’écrans zoomées (avant/après) en prenant en compte tes nouvelles sources de données.
Ça fait plaiz en tout cas de voir ces améliorations !!
| None | ||
|
|
||
| Reference: | ||
| https://makina-corpus.com/django/generer-des-tuiles-vectorielles-sur-mesure-avec-django |
There was a problem hiding this comment.
J'ai l'impression que tu as grandement simplifié le code, sans ajouter de nouvelle dépendance.
Est-ce que tu as aussi constaté eu des gains de temps de calcul ?
(c'est cool niveau comm de dire qu'on a eu des améliorations de perfs !)
There was a problem hiding this comment.
Non pas de gain, ni de différence. Juste maintenant c'est mapbox_vector_tile qui fait les opérations au lieu que ce soit nous à la main.
| { | ||
| "name": "SLT", | ||
| "file": "sltmateriel.geojson", | ||
| "file": "voirie.gpkg", |
There was a problem hiding this comment.
Est-ce le bon nom de fichier ? Dans ce cas, pourquoi avoir également ajouté (en commentaire) un autre fichier voirie.cpkg?
There was a problem hiding this comment.
Oui c'est le bon nom. gpkg c'est un fichier qui contient plusieurs layers (quand geojson) n'en a qu'une.
Valérian des SIG à la voirie m'a fait un export en gpkg de toutes les données les concernant, quand la dernière fois ils avaient fait des exports séparés en geojson.
Il a juste oublié un champ indispensable pour les données SLT donc je garde l'ancien fichier en attendant qu'il me refasse l'export et que je puisse switcher sur la version commentée (j'ai pas envie de ré-écrire la même chose dans 1 semaine donc je stocke là temporairement en commentaire).
| "factors": ["Rsx aériens ERDF"], | ||
| "output_type": "LINESTRING", | ||
| }, | ||
| { |
There was a problem hiding this comment.
Fichier data.md à mettre à jour non ?
| "name": "Réseaux aériens Enedis", | ||
| "file": "rsx_aerien_enedis.geojson", | ||
| "actions": [{"buffer_size": 1, "union": True}], | ||
| "actions": [{"buffer_size": 1, "union": False}], |
There was a problem hiding this comment.
Pourquoi ce passage de True à False. Est-ce qu'il y avait un bug avant ?
There was a problem hiding this comment.
Non avant j'explosais les géométries en suivant une grille régulière pour simplifier les traitements suivants en me permettant de travailler avec juste des bouts de géom.
Je me suis rendu compte qu'en gardant juste l'explosion inhérente aux données (donc pas d'union), ça va tout aussi vite pour les traitements suivants mais ça simplifie l'import des données.
There was a problem hiding this comment.
Pour du tel refacto, proposition de créer un dossier utils avec différents fichiers plutôt que des fichiers préfixés par utils.
| }, | ||
| ) | ||
|
|
||
| def test_transform_to_tile_relative(self): |
There was a problem hiding this comment.
Supprimé car plus la méthode associée c'est ça ?
There was a problem hiding this comment.
Oui les transformations correspondantes sont maintenant directement traitée par mapbox_vector_tile donc on se contente de tester le résultat final qui est les tuiles MVT et plus les étapes intermédiaires.
There was a problem hiding this comment.
On pourait s'attendre à ce que le nombre de tests augmente et ne diminue pas :) Du coup, est-ce que tu aurais 2 tests unitaires pertinents à ajouter ? ^^
Dans ma compréhesion, toutes les fonctions dans utils*.py sont élémentaires et peuvent donc être testées.
There was a problem hiding this comment.
J'ai rajouté 2 tests pour l'import de données du coup (utils/data_processing.py)
back/plantability/management/commands/c01_compute_plantability_indice.py
Outdated
Show resolved
Hide resolved
| cy.contains("45.76") | ||
| cy.contains("4.85") | ||
| cy.contains("Plantabilité élevée") | ||
| cy.contains("Plantation favorisée") |
There was a problem hiding this comment.
Si tu utilises un enum, tu pourras directement l'utiliser ici.
|
Il manquera juste les updates dans le changelog quand j'aurais re-généré la base..! |
Marc-AntoineA
left a comment
There was a problem hiding this comment.
Okay, des détails en review.
| return 10 | ||
|
|
||
|
|
||
| def compute_robust_normalized_indice() -> None: |
There was a problem hiding this comment.
Il y a eu des modifs ici depuis ma dernière review, c’est lié aux bugs dans la génération de ce WE ?
There was a problem hiding this comment.
Oui et que ça mettait une vie de le faire en base directe
docs/changelog.md
Outdated
| ## 🔖 0.3.0 (2025-XX-XX) - XXX | ||
| ## 🔖 0.3.0 (2025-09-04) - Mise à jour de données et ajout calque vulnérabilité à la chaleur | ||
|
|
||
| ### 🐛 fix: Données d'occupation des sols |
There was a problem hiding this comment.
C’est plutôt une amélioration de la partie données que réellement la correction de bugs. Maintenant, tu prends en compte les ponts.
(je trouve que c’est un peu dégradant pour ton travail de dire que c’est de la correction de bug ^^)
docs/changelog.md
Outdated
| Les routes d'API étaient définies à la main, maintenant nous utilisant une API REST à l'aide de DjangoRestFramework | ||
|
|
||
| → Ticket [#98](https://github.com/TelesCoop/iarbre/issues/98) | ||
| → Commit [4bfc05d](https://github.com/TelesCoop/iarbre/commit/4bfc05d0ebea7523501d9f2a49eac4284ac7bae2) |
There was a problem hiding this comment.
Qu’est-ce que tu trouves de plus pour un commit par rapport à un lien vers une issue ou une MR ?
L’avantage d’une MR ou d’une issue, c’est que ça a un numéro simple et tous les commentaires, les raisons détaillées du "pourquoi".
There was a problem hiding this comment.
Ok ça me va aussi, j'ai juste changé par uniformité avaec le reste où l'on listait les commits mais je peux supporter une différence haha
| # Journal de changements | ||
|
|
||
| ## 🔖 0.3.0 (2025-XX-XX) - XXX | ||
| ## 🔖 0.3.0 (2025-09-04) - Mise à jour de données et ajout calque vulnérabilité à la chaleur |
There was a problem hiding this comment.
tu as mis l'intégralité des devs réalisés depuis la v0.2.0 ?
There was a problem hiding this comment.
Oui j'ai repris les merge sur dev depuis
| @@ -18,7 +19,7 @@ describe("MapScorePopup", () => { | |||
There was a problem hiding this comment.
Le score ne pourra plus être 0.81 ? Cette valeur avait justement pour objectif de vérifier que l’arrondi était bien réalisé.
There was a problem hiding this comment.
Non du coup, je fais du seuillage dans le back pour direct renvoyer le score dans [0,2,4,6,8,10]

Pour la fibre fusionne l'ancien et les nouveaux fichiers qui se complètent.
Dans le fichier transmis par la voirie, il manque un champ dans les données SLT. En attente de leur réponse.