Taille des parcelles

[rfrelat]

• la corrélation de la surface cultivée des parcelles par années est plus faible que ce que j'imaginais. La taille des parcelles ne devrait pas beaucoup évoluer d'une année sur l'autre sur une période de 10 ans, et les années proches devraient être plus corrélée entre-elles, non ? Est-ce que les résultats de la Figure 5 vous semblent normaux ou est-il possible qu'il y ait des erreurs lors de l'agrégation des sous-parcelles ?
• Est-ce que la distribution des surfaces (entre 0.5 et 30ha, avec une médiane de 3ha) et le périmètre (entre 300 et 2000m, médiane de 850m) sont plausibles et en accord avec vos attentes?
• Que pensez-vous de la forme des parcelles (Figure 7)? La reconstruction des parcelles depuis les sous-parcelles n'est pas un processus facile ... - Que faire des parcelles qui sont visuellement erronées, par example BIOHME_43_2020 (plusieurs champs séparés par une route)?

[rfrelat]

S (08/10/2025):
Comme ça difficile à dire. Il faut que je vérifie de mon côté si l’agrégation en parcelles agricoles (sous-parcelles contiguës d’une même culture dans une même exploitation à partir de la filiation des parcelles pour obtenir le fichier des séquences de cultures) est correcte car les métriques de taille de parcelles et périmètre sont calculés à partir de là. Peux-tu me rendre accessible l’espace nextcloud FunBioDiv où si j’ai bien compris c’est là que tu stockes les données traités dans R par la suite. Pour le cas de parcelles RPG visuellement erronées (cas de la parcelle BIOHME_43_2020), attention à vérifier l’année de prise de vue de la photo aérienne ou images sat utilisée dans la fig 7 qui peut être différence du millésime RPG analysé. Si après vérif ces 2 sources sont synchrones, c’est su et admis que les données RPG ont une certaine qualité liée à leur source de production : déclaration par les agriculteurs lors de leur déclaration PAC. A décider ensemble si un contrôle post-traitement est fait et corrigé « plus ou moins à la main » pour FunBioDiv

[rfrelat]

R (10/10/2025):
Pour la taille des parcelles, je te joins deux fichiers en gpkg: les sous parcelles originales non agrégées (rpg_all_fields_35.gpkg) et les parcelles agrégées (rpg_aggregated_field_35.gpkg) selon la méthode que j'expliquais dans le document (dont un calcul du 'convex hull' pour simplifier les polygones qui ne se touchent pas). Je pense que l'information de la taille des parcelles est très importante, mais pour le moment j'ai de gros doutes sur ma méthode artisanale... Ça peut avoir un impact assez important sur les métriques de distribution de taille des parcelles. Je vais comparer avec les données RPG brutes pour vérifier si l'agrégation est correct.

[rfrelat]

S (14/10/2025):
j’ai regardé en détail les parcelles des 2 gpkg du POC sur le département 35 et j’ai l’impression qu’il y a une erreur sur le champ surface de la parcelle agrégée qu’il faut mettre à jour. Dans le rpg_aggregated_field_35.gpkg, j’ai rajouté une couche « pg_aggregated_field_35_SurfRecalc » avec un champ nouveau « SurfAgg » où j’ai recalculé la surface du polygone en hectare et celle-ci est différente est plus grande que la valeur du champ « seq_surf » qui ne correspond à la surface que d’une des n parcelles agrégées. Je t’envoie le rpg_aggregated_field_35.gpkg par lien FTP.

[rfrelat]

R (16/10/2025):
Pour le moment, je ne sais pas encore quelle est la meilleure source de données pour les calculer. Je n'ai pas eu le temps de comparer les données brutes RPG avec les données 'RPG séquences de cultures'. Et comment intégrer les données 'RPG complété'? Ce n'est pas si trivial, à creuser.

[rfrelat]

Discussion (Ax, S, R, 17/10/2025) :
Si on n'a pas besoin de l'information du périmètre, on doit pouvoir utiliser seulement l'étape d'agrégation sans recourir à l'enveloppe convexe, ça peut éviter des erreurs (e.g. site BIOHME_30_2020). Sinon, il faut tester les données RPG originales, même si elles sont beaucoup plus volumineuses.
Quid du RPG complété qui est aussi dans le format séquence de culture (les données 2022 contiennent l'occupation du sol de 2016 à 2022, donc potentiellement des sous-parcelles).
Encore quelques tests à faire…