Skip to content

Feat(back): Plantability computation in raster instead of geom#193

Merged
ludovicdmt merged 19 commits intodevfrom
faster_clip
Apr 22, 2025
Merged

Feat(back): Plantability computation in raster instead of geom#193
ludovicdmt merged 19 commits intodevfrom
faster_clip

Conversation

@ludovicdmt
Copy link
Member

@ludovicdmt ludovicdmt commented Apr 15, 2025

  • Convert Data into raster maps with a resolution of 1x1 meter
  • Perform a weighted sum of the raster maps using factor weights
  • Downsample the result to a 5x5 meter resolution to generate the plantability map
  • Convert the raster data back to geometry format for database storage
  • Add tests
  • Add documentation

@ludovicdmt ludovicdmt linked an issue Apr 15, 2025 that may be closed by this pull request
@ludovicdmt
Copy link
Member Author

image
Le raster visualisé sur QGIS avec OSM en fond

@ludovicdmt
Copy link
Member Author

ludovicdmt commented Apr 16, 2025

Ca va beaucoup plus vite de calculer comme ça (~2h vs 2j) MAIS:

  • Ca alourdit d'avoir autre chose que des carrés : un pixel c'est carré et dessiner des formes plus complexes demanderait une résolution du raster trrèèèèès grande
  • On perd l'info qui était quels pourcentages de facteurs sur chaque tuile qui n'est plus que sous forme de raster

Copy link
Contributor

@Marc-AntoineA Marc-AntoineA left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Je ne comprends pas l'intention générale de cette MR.

Je crois comprendre que tu as là une expérimentation pour optimiser le temps de génération des tuiles. Et pour le moment, il y a donc aucune modification du code déjà en place en particulier aucune suppression de code qui serait remplacé par les raster. 

Tu écris que "ça alourdit d'avoir autre chose que des carrés : un pixel c'est carré et dessiner des formes plus complexes demanderait une résolution du raster trrèèèèès grande".
👉 Est-ce que ça signifie donc que les tuiles hexagonales ne sont pas envisageables avec cette option ?

"On perd l'info qui était quels pourcentages de facteurs sur chaque tuile qui n'est plus que sous forme de raster"
👉 Est-ce seulement un problème de non-rétrocompatibilité avec la version actuelle ?

**data,
"geometry": GEOSGeometry(data["geometry"].wkt),
"metadata": data_config["name"],
"factor": data["factor"],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

C’est pas déjà inclus dans **data ?

@ludovicdmt
Copy link
Member Author

En utilisant le process en raster on fait :

  1. Convertir les données de Data pour tous les facteurs en raster haute résolution (1x1m)
  2. Convolution des rasters, individuellement, avec un noyau carré 5x5. Les pixels des rasters de résultat contiennent le pourcentage de chaque facteur sur des tuiles carrés 5x5m.
  3. Somme pondérée des rasters d'OCS, avec les poids relatifs aux facteurs, pour produire un raster de plantabilité
  4. On crée des geoms qui sont des carrés 5x5m qui vont être insérées dans une DB PostGIS. On utilise les valeurs des pixels dans le raster de plantabilité pour remplir le champ correspondant à la plantabilité et à la plantabilité seuillée.

En base nous n'avons que des géoms qui correspondent au score de plantabilité. Nous n'avons pas de géoms qui correspondent à l'occupation des sols par chaque facteur.

@ludovicdmt
Copy link
Member Author

#200 pour les tuiles hexagonales
#201 pour l'occupation des sols par facteur sur chaque tuile

@ludovicdmt ludovicdmt merged commit 3b6825e into dev Apr 22, 2025
10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

ETQ data je veux tester l'intersection de facteurs en raster

2 participants