France/data.gouv.fr/Occupation du sol

Présentation des données

Depuis 2006, pour des raisons de facilité de contrôle, les demandes d'aides PAC des agriculteurs sont accompagnées d'une déclaration graphique des surfaces agricoles qu'ils exploitent, surfaces dessinées par l'agriculteur (ou un conseiller agricole) sur un fond d'orthophotographies IGN (BD ORTHO). Ces surfaces déclarées suivent la notion d'îlot de culture, qui correspond à un groupe de parcelles contiguës, cultivées par le même agriculteur. Un îlot ne correspond donc pas forcement à une seule culture (cf tableau sur la répartition du nombre de de culture par îlot).

Le registre parcellaire graphique (RPG pour les intimes) est un fichier SIG qui résulte de la compilation de ces demandes de subventions PAC des agriculteurs français. Il est compilé par l'Agence de Service et de Paiement (ASP), organisme français responsable de la vérification des déclarations et du paiement aux agriculteurs. La compilation réalisée par l'ASP existe en plusieurs versions, différant seulement par les données attributaires distribuées avec la couche graphique . A partir de la version 2, le RPG est distribué avec une table de donnée, qui contient les cultures de chaque parcelle, avec l'identifiant de l'îlot dans laquelle cette parcelle se situe. Note: Les informations géographiques des parcelles ne sont jamais disponibles, quelques soient les versions du RPG.

Une version modifiée du RPG de l'année 2010 est disponible sous licence LO/OL sur le site [2]. Il correspond a la version 1 distribuée par l'ASP, complétée par un identifiant du groupe de culture principal sur chaque îlot. Cette culture principale est la culture de la parcelle de plus grande superficie pour chaque îlot. Cette version correspond à l'affichage du RPG sous Géoportail. Le fichier est disponible au format Shapefile, en projection Lambert 93. Une table de donnée des groupes de cultures, avec l'identifiant et la dénomination de chaque groupe de culture est jointe à ce fichier.

Exemple : Répartition du nombre d'îlots par leur nombre de groupe de culture différents en Loire-Atlantique (RPG2010)

Cultures par îlot	Nbre d'îlot	Proportion
0	25	0,03%
1	53131	67,11%
2	17827	22,52%
3	5800	7,33%
4	1774	2,24%
5	475	0,60%
6	112	0,14%
7	19	0,02%
8	7	0,01%

Utilisation dans OpenStreetMap

Les importations de données à base de script et les modifications automatisées ne devraient être effectuées que par des personnes ayant acquis une bonne expérience et une bonne compréhension de la manière dont la communauté OpenStreetMap crée ses cartes. Et ce seulement après avoir pris soin de planifier, et d’avoir consulté la communauté locale.
Consultez nos directives d’importations et notre code de conduite des modifications automatisées pour plus d’information. Les importations ou modifications automatisées qui ne suivent pas ces directrices pourraient être annulées !

La précision beaucoup plus grande du RPG par rapport à Corine Land Cover (CLC) permettrait d'envisager une amélioration très intéressante de la représentation de l'occupation du sol dans les zones agricoles, principalement en ce qui concerne la distinction toujours difficile entre landuse=farmland et landuse=meadow. L'intégration de cette donnée reste cependant à réaliser à la main, après suppression des polygones de landuse CLC de catégories agricoles (landuse= farmland, meadow, orchard...). De plus, les polygones du RPG peuvent être simplifiés, fusionnés par type et nettoyés avant leur intégration.

Les zones vides du RPG sont aussi intéressantes : la très bonne précision du RPG permet aussi d'envisager son utilisation pour tracer et recaler les chemins et les routes, qui apparaissent en "négatif" sur celui-ci. Les zones résidentielles, commerciales, industrielles, naturelles ne peuvent chevaucher les polygones du RPG. Enfin, l'emprise des cours de ferme (landuse=farmyard) apparait nettement.

Le Plugin OpenData permet de charger directement le RPG d'un département entier. Pour chaque polygone, le plugin ajoute automatiquement le tag landuse correspondant au groupe de culture du RPG. Le nombre d'objet chargé par le plugin (plus de 90 000 polygones pour certains départements) rend cependant JOSM très lent et presque inutilisable une fois le fichier chargé.

Je ne retrouve pas la table de correspondance du plugin OpenData, je propose donc d'utiliser la table suivante, qui établit une correspondance entre le type d'information contenue dans le RPG et les classes d'occupation du sol utilisées dans OpenStreetMap --M.gueret 21:18, 19 December 2012 (UTC)

Il me semble une bonne idée d'ajouter le tag source suivant : source=Registre Parcellaire Graphique 2012 - Agence de services et de paiement (ASP) à tous les polygones --Marc (talk) 06:33, 3 May 2016 (UTC)

Les groupes de culture

Code des groupes de culture	Détail des groupes de culture	correspondance proposée avec nomenclature OpenStreetMap
0	Pas d'information sur la culture	landuse=farmland à défaut d'autres informations (orthophotos, repérage terrain)
1	Blé tendre	landuse=farmland crop=wheat
2,3,4,5,6,7,8,9,10,14,15	Cultures principalement annuelles : Céréales (Blé, maïs, orge, autres céréales), Oléagineux (Colza, Tournesol, autres oléagineux), protéagineux, plantes à fibres (lin, chanvre) et semences	landuse=farmland
11,12,13	Terres en jachère	landuse=farmland
16	Fourrages (betteraves, choux, luzernes, etc...)	landuse=farmland
17	Estives et landes, parcours...	landuse=meadow, natural=scrub ou natural=heath en montagne ou en zones semi-naturelles, landuse=meadow pour les parcours, à confirmer avec orthophotos
18	Prairies permanentes	landuse=meadow
19	Prairies temporaires. Les prairies temporaires rentrent souvent dans les rotations culturales, on ne peut donc pas les considérer comme pérennes	landuse=farmland
20	Vergers	landuse=orchard (compléter éventuellement avec trees=* correspondant, après vérification sur le terrain)
21	Vignes	landuse=vineyard
22	Fruits à coque	landuse=orchard (compléter éventuellement avec trees=* correspondant, après vérification sur le terrain)
23	Oliviers	landuse=orchard + trees=olive_tree
24	Autres cultures industrielles	landuse=farmland
25	Légumes & Fleurs	landuse=farmland
26	Canne à sucre	landuse=farmland
27	Arboriculture	landuse=forest (compléter éventuellement avec wood=* (déprécié) correspondant, après vérification sur le terrain)
28	Divers	landuse=farmland à défaut d'autres informations (orthophotos, repérage terrain)

Utilisation du fichier SIG disponible

Principe

Je propose d'utiliser le RPG selon le principe suivant :

• Travailler commune par commune, découper le shapefile avec les limites de la commune
• Requalifier chaque polygone selon le tableau de correspondance avec les clés/valeurs
• Simplifier les polygones (en préservant la topologie... ?)
• Exporter au format .osm, nettoyer encore les géométries l'aide de JOSM et d'un fond Bing
• Supprimer les polygones CLC2006 "agricoles" de la zone, faire un changeset spécifique "suppression des polygones CLC2006 agricoles"
• intégrer les nouveaux polygones, ajuster/recoller les polygones CLC restants
• uploader, avec pour commentaire de changeset la clé/valeur : source=ASP - Registre Parcellaire Graphique 2010

Un peu de technique (en cours de mise au point... patience ! --M.gueret 20:58, 3 January 2013 (UTC))

(Réalisé sous PostGIS 2.0/PostgreSQL 9.1, sous Debian Squeeze, à l'aide de OGR, QGIS... avec le RPG des Deux-Sèvres)

• On télécharge le RPG de son département sur le site OpenData, c'est un fichier zippé, que l'on extrait dans un répertoire
• Le shapefile que l'on télécharge est en projection Lambert 93 (en métropole). On a besoin de faire des calculs de distance pour simplifier le RPG, on conservera donc ce système de projection (les calculs de distance sont plus facile a réaliser dans une projection plane). La conversion vers le système de projection géographique (WGS84) utilisé dans la base de données OSM sera réalisée ensuite.

• On crée une base Postgis avec extension hstore (l'utilisateur linux a les droits de création de bd) :

$ createdb rpg_db
$ psql -d rpg_db
rpg_db=# CREATE EXTENSION postgis;
rpg_db=# CREATE EXTENSION hstore;
rpg_db=# \q
* On importe le shapefile du RPG de notre département dans la base :
$ cd ~/RPG_2010_079
$ shp2pgsql -s 2154 RPG_2010_079.shp |psql -d rpg_db

• on vérifie que le RPG ne contient pas de géométries invalides avec cette requête :

SELECT gid FROM rpg_2010_079 WHERE st_IsValid(geom) IS FALSE

S'il y a des erreurs, on "répare" le RPG avec les deux requêtes suivantes :

UPDATE rpg_2010_079 set geom = ST_MakeValid(geom) WHERE ST_IsValid(geom)=FALSE AND ST_GeometryType(ST_MakeValid(geom))='ST_MultiPolygon'

UPDATE rpg_2010_079 SET geom = ST_CollectionExtract(ST_MakeValid(geom),3) WHERE ST_IsValid(geom)=FALSE

• On y importe aussi les limites des communes du département dans lequel on travaille, disponibles ici. On converti ces données en Lambert 93 pour travailler dans un système de projection uniforme. Au passage, on supprime les accents dans les noms de table sous postgresql, c'est toujours gênant.

$ cd ~/79-Deux-Sèvres.shp
$ ogr2ogr -s_srs EPSG:4326 -t_srs EPSG:2154 79-Deux_Sevres_L93.shp 79-Deux-Sèvres.shp
$ shp2pgsql -s 2154 79-Deux_Sevres_L93.shp public.communes_079 |psql -d rpg_db

• On importe dans la base le tableau qui va nous permettre de faire correspondre le code de groupe de culture avec les tags OSM indiqués dans le tableau ci-dessus.

 Ajouter le fichier .sql
$ psql -f tableau_rpg_landuse.sql -d rpg_db

• On cherche l'identifiant du polygone de sa commune :

$ psql -d rpg_db
rpg_db=# SELECT gid, name FROM communes_079 WHERE name LIKE '%Moutiers%';

Par exemple, pour la commune de Moutiers-sous-Argenton, c'est l'identifiant 63 (gid =63)

• On récupère les données sous la forme d'un shapefile

$ ogr2ogr -f "ESRI Shapefile" essai.shp PG:"dbname=rpg_db" -sql="'a faire'"

Autres informations

Anecdote : le passage du système de projection Lambert II étendu au Lambert 93 en 2010 a induit de légères diminutions de surfaces et donc du montant des subventions pour certains agriculteurs.