Base de données Occupation du Sol à l'échelle COMmunale (OSCOM) en 2016 dans l'Indre-et-Loire
Licence : License Not Specified
Mots-clés : donnees-ouvertes,foncier-sol-occupation-du-sol,oscom,sols

La base de données OSCOM est produite à partir de diverses couches de données dites à grande échelle (BD-TOPO®, BD-FORET®, MAJIC, etc.), OSCOM peut donc être considérée comme une base de données d’occupation du sol à grande échelle, à la différence de CORINE LAND COVER par exemple.
Si l’échelle de travail de CORINE LAND COVER relève ainsi du 1/100 000, l’échelle de travail du produit OSCOM relève quant à elle du 1/10 000.
Cette échelle permet d’envisager des utilisations de la base de données à l’échelle inter-communale, mais aussi communale voire infra-communale.
Cette échelle est bien adaptée aux besoins locaux de suivi et de gestion de l’environnement ou d’aménagement de l’espace.
En particulier, elle permet d’envisager un suivi précis de la consommation d’espace à l’échelle communale.
I - L’Unité Minimale de Collecte
Les couches utilisées pour produire la base de données sont des couches de données vectorielles qui possèdent des échelles de validité différentes selon les sources. Il n’est donc rigoureusement pas possible de déterminer une Unité Minimale de Collecte (UMC) homogène pour l’ensemble de la base de données relative à l’occupation du sol.
Malgré cette hétérogénéité, la précision des différentes sources de données est soit directement issue du Référentiel à Grande Échelle (RGE) de l’IGN (BD-TOPO®) soit de niveau d’échelle compatible avec celui-ci. C’est notamment le cas du Registre Parcellaire Graphique (RPG) de l'ASP et de la base MAJIC de la DGFiP dont la précision de la donnée est fournie à la parcelle cadastrale.
Dans le cadre d’OSCOM, il n’a pas été envisagé de généraliser la topographie afin de créer une UMC artificelle, car cela aurait abouti à dégrader la qualité des sources de données utilisées pour constituer la base de données.

II - La temporalité et la notion de millésime
Comme pour l’Unité Minimale de Collecte, les couches utilisées pour produire la base de données ont des temporalités qui peuvent être différentes, ce qui pose des problèmes pour déterminer un millésime homogène pour la base de données occupation du sol. Même si ce biais constitue une des limites assumées de la méthode, il convient d’en relativiser la portée compte-tenu des éléments suivants. En effet, parmi les bases de données mobilisées, le RPG et MAJIC sont des bases de données millésimées qui ne posent donc pas de problèmes à ce titre.
Dans le cadre de la version OSCOM réalisée en 2016, l’ensemble des couches de données utilisées possèdent un millésime oscillant entre 2012 et 2014, ce qui permet de retenir à titre indicatif un millésime final de 2013 pour la présente base de données.
Bien que l’actualité des données de la BD-TOPO® diffèrent désormais selon les classes d’objets, – ce qui pose justement des problèmes pour déterminer un millésime – les classes d’objets les plus importantes pour la constitution de la base de données, notamment la classe « BATI », suivent le cycle de mise à jour des planches cadastrales par la DGI. Pour les autres éléments, l’IGN garantit un décalage maximum d’un an sur les informations fournies. L’actualité des données en fonction des différentes livraisons peut donc être considérée comme relativement fiable. Pour la BD-FORET®, elle est disponible dans sa version 2 au niveau de la région Auvergne-Rhônes-Alpes que relativement récemment. Les écarts observés restent donc acceptables compte-tenu de plus du caractère peu évolutif de la donnée.
En conclusion, la grande majorité des objets géographiques utilisés pour construire la base de données répondent à une actualité de mise à jour compatible avec la notion de millésime. Il convient néanmoins de porter une vigilance particulière sur certaines classes de la BD-TOPO® (zones d’activités, commerciales notamment...) dont le cycle de mises à jour (même s’il est inférieur à un an) peut ponctuellement présenter des écarts plus importants avec le millésime retenu.