Afficher les informations sur les feux de forêts
publié le , mis à jourDécrivez votre problème, votre suggestion
Google Maps affiche les feux de forêts sur la carte, ce qui est intéressant pour projeter une sortie en forêt. Ils utilisent vraisemblablement l'API de https://feuxdeforet.fr ( https://feuxdeforet.fr/espaces/data/ ) qui est utilisable librement. Ci-joint la capture d'écran du feu en forêt de Fontainebleau
Système d'exploitation
No response
Navigateur
No response
latetedansleguidon
Je n'ai pas trouvé la doc de l'API de feuxdeforet.fr, qui renvoie uniquement vers le formulaire de contact... Mais open event database semble inclure leurs données. Peut-être est-ce l'occasion de travailler l'intégration OEDB dans cartes.app ?
@latetedansleguidon wrote in https://codeberg.org/cartes/web/issues/2517#issuecomment-19192499:
Je n'ai pas trouvé la doc de l'API de feuxdeforet.fr, qui renvoie uniquement vers le formulaire de contact... Mais open event database semble inclure leurs données. Peut-être est-ce l'occasion de travailler l'intégration OEDB dans cartes.app ?
laem
Ah c'est génial si OEDB l'inclus déjà ! En effet, c'est carrément l'occaze de tester l'intégration !
Je n'ai pas trouvé la doc de l'API de feuxdeforet.fr, qui renvoie uniquement vers le formulaire de contact... Mais open event database semble inclure leurs données. Peut-être est-ce l'occasion de travailler l'intégration OEDB dans cartes.app ?
Mince le site est tombé.
J'arrive pas trop à savoir s'il faut qu'on utilise l'API Effis qui a l'avantage d'être européenne quand même, par rapport à Feux de forêt qui ouf est une association.
Si ça peut aider, j'ai trouvé ce projet qui vectorise le WMS de l'EFFIS. https://github.com/LuisSevillano/effis_current_situation/tree/main
Autre source de données : Eutmetsat https://mamot.fr/@adarr_volte/116977450217054191 https://mamot.fr/@adarr_volte/116977656855917218
Intéressant aussi, mais spécifique à la France https://fr-alert.gouv.fr/les-alertes
Désolé je n'ai aucune idée du workflow pour cartes.app, mes compétences se limitent pour l'instant à des scripts pour mon usage perso... Donc pour l'instant j'ai mis ça sur mon github 😬 https://github.com/LaTeteDansLeGuidon/fire_areas Voilà où j'en suis :
- script autonome, paramétrable avec un fichier yaml (période à couvrir, zone géographique, intervalle de mesure etc)
- mise en cache des données extraites des images satellites. Plus de spamming du serveur Eumetsat, on sauvegarde les polygones extraits en spécifiant les paramètres. Si la prochaine exécution a les mêmes paramètres, elle ne téléchargera des nouvelles données que pour les images pas encore analysées.
- fusion spatiale et temporelle des polygones : pour cartes.app on veut simplement une "zone de danger" par feu, pas un million de polygones indiquant chaque front du feu avec des infos temporelle
- dilatation et lissage du périmètre
- amélioration esthétique : arrondir les angles causés par la résolution de la mesure
- export des données en pmtiles plutôt que shapefile
Exemple sur Bordeaux, foyers sur 1 semaine et 24h
etienneJr
J'ai réfléchi au sujet environ 1/2 seconde et je n'ai pas compris pourquoi @laem tu dis qu'il faudrait un pmtiles. Un geojson comme quand on affiche les résultats d'une requête photon, ça devrait marcher nickel, non ?
Le geojson forcément à l'échelle de l'Europe imposera un lourd téléchargement de données même quand on est en train de regarder Paimpol au zoom 20.
C'est le but des tuiles (pmtiles ou mbtiles), de ne charger que les données présentes à ce niveau de zoom.
Un geojson ça pourrait marcher pour créer une carte "les feux en cours" : on charge tout, c'est pas grave. Mais là mon idée est d'intégrer les feux directement comme une couche de tuiles.
Éventuellement on pourrait intégrer un pmtiles pour les signalements de feu sous forme de points, comme fait Google Maps, puis la zone geojson concernée au clic, mais je me dis qu'on peut faire d'une pierre deux coups avec un geojson et on pourra raffiner si jamais ça devient trop lourd visuellement d'afficher la zone brulée / brulant directement.
Bon comme d'hab quand j'essaie un projet python, ça marche pas haha.
Using cached packaging-26.2-py3-none-any.whl.metadata (3.5 kB) INFO: pip is looking at multiple versions of opencv-contrib-python to determine which version is compatible with other requirements. This could take a while. ERROR: Cannot install -r requirements.txt (line 2), -r requirements.txt (line 4) and numpy==1.26.4 because these package versions have conflicting dependencies. The conflict is caused by: The user requested numpy==1.26.4 geopandas 1.1.1 depends on numpy>=1.24 opencv-contrib-python 4.12.0.88 depends on numpy<2.3.0 and >=2; python_version >= "3.9" To fix this you could try to: 1. loosen the range of package versions you've specified 2. remove package versions to allow pip to attempt to solve the dependency conflictOK j'ai ! Y a un script d'install, merci !
@latetedansleguidon tu avais vu ces shapefiles ?
https://firms.modaps.eosdis.nasa.gov/active_fire/#firms-shapefile
J'ai l'impression que ça fait à peu près la même chose, non ? Déjà calculés en SHP.
OK j'ai mis en ligne une première version basée sur ces SHP, on pourra continuer la discussion ici.
- à faire côté serveur, intégrer ce que j'ai fait ce soir dans le Ansible
Côté visualisation de données, je pense que les points c'est pas incroyable car ça donne l'impression que ce sont des feux actifs. Des zones (de gris : brûlé, c'est tout carbonisé à rouge sombre : brûlé mais toujours potentiellement chaud et dangereux ; jusqu'à jaune : en train de crâmer actuellement) c'est mieux je pense. Peut-être des points pour les zones qui crâment maintenant.
@latetedansleguidon je réponds à ton commentaire suivant :
J'avais exclu cette source dans mes recherches, car les satellites en orbite basse ont certes une bonne résolution spatiale, mais une fréquence d'actualisation variable
À contrario, les données Eumetsat sont quasi instantanées grâce aux satellites géostationnaires (mais pas publiées dans des formats directement exploitables ici)
Tu as un lien qui permet de visualiser la différence ? Eumetsat n'est pas sur cette carte qui aggrège plusieurs sources ?
Au fait, la MAJ des feux est automatique et consultable ici
https://cartes.app/maj
@laem wrote in https://codeberg.org/cartes/web/issues/2517#issuecomment-20257726:
Tu as un lien qui permet de visualiser la différence ? Eumetsat n'est pas sur cette carte qui aggrège plusieurs sources ?
Je n'ai pas trouvé les deux sur une même carte, tu peux trouver les images Eumetsat ici (infos sur ces données Fire Temperature RGB - MTG - 0 degree)
@laem wrote in https://codeberg.org/cartes/web/issues/2517#issuecomment-20226373:
@latetedansleguidon tu avais vu ces shapefiles ?
https://firms.modaps.eosdis.nasa.gov/active_fire/#firms-shapefile
J'ai l'impression que ça fait à peu près la même chose, non ? Déjà calculés en SHP.
J'ai initialement exclu cette source de mes recherches, car les satellites en orbite basse ont certes une bonne résolution spatiale, mais une fréquence d'actualisation faible/variable. (peut-être pas si grave que ça pour nous, j'ai lu quelques part que les données MODIS de la NASA sont actualisées 6 fois par jour, à voir si c'est la fréquence de prise de vue, ou de génération des rendus) A contrario, les données d'Eumetsat proviennent de satellites en orbite géostationnaire, avec une période d'actualisation de 10 minutes mais une résolution plus faible, de l'ordre du km.
Pour moi, le choix de la source peut dépendre de l'orientation que veut prendre cartes.app : suivi précis et/ou en temps réel du feu, simple zone de danger ?
Beau boulot @laem pour cette intégration éclair. À mon sens il faut qu'on se pose la question de l'orientation à prendre.
- des points, pour visualiser précisément où ça brûle (dans la continuité de l'actuel)
- des points + des zones, qui correspondraient à l'aire du feu au cours des x derniers jours (avec un buffer spatial pour avoir une unique zone par feu, par exemple en Gironde on aurait une immense zone de 40000 ha.)
- uniquement des zones (on peut faire comme Google une zone pour l'incendie, mais aussi envisager d'ajouter des zones où le feu est détecté plus récemment, un peu dans l'idée de ce que j'ai partagé plus haut)
A propos de la production de zones, j'ai déjà quelque chose qui marche pour regrouper les points (jointure spatiale et temporelle). Il pourrait s'agir de "zones de danger", où le feu est ou a été au cours des x derniers jours. Attention, les mégafeux imposent de réfléchir sur des durées plus grandes que la semaine. Je propose d'analyser les données sur le mois écoulé, puis n'afficher que celles dans des zones où des foyers ont été détectés au cours de la semaine par exemple.
Le schéma de "zones de danger" pourra être le même pour les alertes météo ou catastrophes naturelles par exemple. La zone correspondante feu pourra être liée à des consignes de sécurité, un lien vers le site de la pref etc. On peut envisager un bandeau sur les POI situés dans ces zones, une alerte en cas d'itinéraire par cette zone (avec l'option d'éviter cette zone, BRouter propose cette fonction maintenant). Il faut penser à mettre une option
désactiver pour 24hpar exemple, si je suis riverain d'une catastrophe je suis au courant merci.LySioS
Bravo pour l'avancée, mais 🙃
Je ne suis pas fan de l’affichage actuel. On ne comprend pas du tout a quoi cela correspond.
Dans le cas de la Gironde, ça va tout le monde est au courant, mais si je vais zoomer sur un autre territoire sans passer par la Gironde, on ne peut pas comprendre.
Peut-être :
afficher un emoji flamme au coeur du cluster en faire une couche (dés) activable Afficher une info ulle au clic?
Excellente carte partagée par @severo https://amcaw.github.io/svelte-fires/
afficher un emoji flamme au coeur du cluster afficher un emoji flamme au coeur du cluster
Oui bien sûr, et un lien vers un portail officiel pour avoir des informations, j'ai juste pas eu le temps de le faire.
en faire une couche (dés) activable
Pas trop d'accord. C'est une nouvelle donne géographique, il faut vivre avec. C'est une information autrement plus importante que la plupart des couches de notre style.