PCIBase permet d’intégrer vers le modèle FONCIER 2022, les données d’urbanisme au format CNIG de type :

►     DU (Document d’Urbanisme) :

-   PLU/PLUi : Plan Local d’Urbanisme (communal ou Intercommunal),

-   CC : Carte Communale,

-   PSMV : Plan de Sauvegarde et de Mise en Valeur.

►     SUP (Servitude d’Utilité Publique).

PCIBase importe uniquement les données d’urbanisme respectant les standards CNIG de dématérialisation des documents d’urbanisme.

PCIBase supporte, les STANDARD CNIG suivants :

-   PLU et PLUi : v2024, v2022, v2017d, v2017, v2014 (v2017b et v2017c sont reconnus en tant que v2017) ;

-   PSMV : v2022, v2019b, v2019, v2014 ;

-   CC : v2024, v2022, v2017d, v2017, v2014 ;

-   SUP : v2016b rev.2024-08 et antérieur, v2016, v2013.

La description des standards est disponible sur le site du CNIG, dans la page concernant la dématérialisation des documents d’urbanisme :

http://cnig.gouv.fr/ressources-dematerialisation-documents-d-urbanisme-a2732.html

L’intégration de données d’urbanisme se fait pour le modèle FONCIER 2022 (URBA 2018) pour arcOpole PRO Foncier :

►     arcOpole PRO Cadastre 3.5 et supérieur ;

►     arcOpole PRO Foncier v1.2 et supérieur (widgets Cadastre) ;

►     arcOpole PRO FONCIER CADASTRE Desktop 2018.

PCIBase intègre un seul échange de données d’urbanisme à la fois (DU ou SUP).

L’outil reconnait automatiquement le type et la version des données d’urbanisme à intégrer et en vérifie la validité avant intégration. Cette vérification est la même que celle effectuée par l’outil « Vérification des données d'urbanisme CNIG », outil qui peut être utilisé indépendamment de l’outil d’intégration.

Pour plus d’informations, cf. Chapitre 5.1.4 Vérification de données d’urbanisme CNIG.

Chaque intégration nécessite un dossier de travail différent. Ce dossier de travail doit être vide avant une intégration.

L’intégration de données d’urbanisme génère dans le dossier de travail une géodatabase fichier contenant le résultat de l’intégration.

Après intégration, le dossier de travail pourra être chargé dans votre géodatabase foncière finale par l’outil « Chargement d’une intégration de données d’urbanisme (DU ou SUP) ».

!          ATTENTION : Pour une « Intégration document urbanisme », vous ne pouvez traiter qu’un échange de document d’urbanisme à la fois.           
Si vous avez 5 PLU et 10 SUP à intégrer, vous devrez faire 15 intégrations distinctes, vous aurez donc 15 dossiers de travail d’intégration et 15 chargements à faire dans la géodatabase finale.

Pour des données de type SUP, un code emprise est obligatoire. Il permet d'identifier la SUP selon la zone géographique couverte par la SUP.

Un code emprise doit être composé de 1 à 6 caractères, uniquement de lettres (A..Z, a..z) et chiffres.

Exemple :

►     FR ►     R53 (code INSEE de la région Bretagne) ►     41 (département Loir-et-Cher) ►     41269 (code INSEE de la commune de Vendôme)

 

Outil : Urbanisme/Intégration/Intégration des données d’urbanisme CNIG

Ligne de commande : INTEGRATION_URBA

Paramètres : - dossier de travail de l'intégration (ce dossier doit être vide) - dossier 'donnees_geographiques' des données d'urbanisme CNIG - référence spatiale des données : (au choix) (optionnel)         # : la référence spatiale sera déterminée à partir des données (si c'est possible)         WKID (exemple : 2154 pour RGF_1993_Lambert_93)         Nom d'une référence spatiale reconnu par ArcGIS (exemple : RGF_1993_Lambert_93)         Chemin d'accès à un fichier PRJ (exemple : D:\DATA\maprojection.prj) - Code emprise de la SUP (uniquement pour les SUP). Optionnel s'il peut être déterminé automatiquement à partir du nom du dossier des données d'urbanisme CNIG Exemple : PCIBase INTEGRATION_URBA c:\integration\sortie\urba\82077_CC_20111012 c:\integration\Sources\URBA\82077_CC_20111012\donnees_geographiques 2154

Dossier de travail :

Dossier de travail dans lequel sera faite l’intégration. Ce dossier doit être vide.

Dossier « donnees_geographiques » des données CNIG :

Sous dossier « donnees_geographiques » du dossier de l’échange CNIG des données à intégrer. Ce dossier doit contenir (entre autres) des fichiers shape (*.shp). Pour les DU (PLU/PLUi, CC, PSMV), son dossier parent doit contenir des tables dBase (*DOC_URBA*.dbf et *DOC_URBA_COM*.dbf).

Référence spatiale :

La référence spatiale des données CNIG est reconnue automatiquement. !          ATTENTION, il s'agit de la référence spatiale des données CNIG à intégrer, qui n’est pas forcément la référence spatiale des données de la géodatabase finale. Si la référence spatiale a pu être déterminée automatiquement, il n'y a normalement pas de raison de la modifier. Si ce n'est pas le cas, il faut l’indiquer : ►     En mode outil, il faut sélectionner la référence spatiale ; ►     En mode ligne de commande : ►     Pour laisser l’outil déterminer la référence spatiale, indiquer # comme référence spatiale. ►     Pour indiquer une référence spatiale, fournir au choix : -   Un WKID (exemple : 2154 pour RGF_1993_Lambert_93), -   Le nom d'une référence spatiale reconnu par ArcGIS (exemple : RGF_1993_Lambert_93), -   Le chemin d'accès à un fichier *.PRJ (exemple : D:\DATA\maprojection.prj).

Type de données d’urbanisme :

►     En mode outil, ce paramètre est déterminé automatiquement et toujours désactivé. Il est juste présent pour information. ►     En mode ligne de commande, ce paramètre n’existe pas. Pour plus d’informations, cf. Chapitre 6.4 .1 Récupération du type de la version du dossier d’un échange CNIG.

Version des données d’urbanisme :

►     En mode outil, ce paramètre est déterminé automatiquement et toujours désactivé. Il est juste présent pour information. ►     En mode ligne de commande, ce paramètre n’existe pas.

Code emprise de la SUP :

Si les données à intégrer sont des SUP, le code emprise doit être indiqué et permet d’identifier la SUP selon la zone géographique qu’elle couvre. Ce code emprise doit être composé de 1 à 6 caractères, parmi A..Z, a..z, 0..9. ►     En mode outil, ce paramètre est déterminé automatiquement à partir du nom du dossier des données CNIG. Si ce n’est pas possible, il doit être renseigné. Même si le code emprise a pu être déterminé automatiquement, il est possible de modifier ce code emprise. ►     En mode ligne de commande, ce paramètre doit être indiqué. ►     Comment est déterminé le code emprise ? Pour des SUP version 2016, le code emprise est déterminé à partir du nom du dossier d’échange de la SUP, qui est composé comme suit : -   <idGest>_<catégorie>_<maillage>_<date>. -   Le code emprise sera <maillage>. Par exemple : Pour un échange SUP nommé « 130022114_I4_82_20220328 », le code emprise sera 82.

Les données sont vérifiées puis intégrées.

Après le traitement, le dossier de travail contiendra une géodatabase fichier (.gdb).

Des fichiers de log sont aussi créés dans le dossier de travail, contenant les messages générés pendant le traitement.

Le nom de ces fichiers de log est indiqué en début et fin de traitement et correspond à la date de lancement du traitement.

Le dossier de travail peut ensuite être utilisé par l'outil « Chargement d'une intégration de données d'urbanisme (DU ou SUP) ».

Avant le traitement, dans le cas d’une intégration de données standard CNIG PLU, PLUI ou PSMV de version supérieure ou égale à v2022, une vérification est faite sur la taille du champ ATTCOMP de la classe d’entités plu_zone.

En effet, l’intégration des « nouveaux » champs FORMDOMI, DESTOUI, DESCDT et DESTNON de la table ZONE_URBA sont intégrés en tant qu’attributs complémentaires dans le champ ATTCOMP.

Pour chaque champ trois attributs complémentaires sont ajoutées :

►     <NOM_DU_CHAMP> : Contient le(s) libellé(s) et le(s) code(s) de la valeur d’origine

►     <NOM_DU_CHAMP>_L : Contient le(s) libellé(s) de la valeur d’origine

►     <NOM_DU_CHAMP>_C : Contient le(s) code(s) de la valeur d’origine

Exemple pour DESTOUI="34-37", l’intégration dans ATTCOMP est :

{   "DESTOUI_L" : ["activités de services où s'effectue l'accueil d'une clientèle", "autres hébergements touristiques"],   "DESTOUI_C" : ["34", "37"],   "DESTOUI" : ["activités de services où s'effectue l'accueil d'une clientèle (34)", "autres hébergements touristiques (37)"], }

Le champ ATTCOMP fait une taille par défaut de 1000, dans le modèle de données URBA 2018. Si les données à intégrées dépassent cette limite, une erreur s’affiche à l’utilisateur pour lui indiquer d’augmenter la taille du champ ATTCOMP du modèle de données URBA :

!          IMPORTANT : Il est nécessaire d'augmenter la taille du champ ATTCOMP du modèle de données ainsi que celui de la base de données finale !

Dans ce cas, il est nécessaire d’augmenter la taille du champ ATTCOMP de la classe d’entités PLU_ZONE dans la GDB Fichiers du modèle de données : .\pcibase\modeles\urba_2154.gdb.

Pour augmenter la taille d’un champ, vous pouvez utiliser un géotraitement d’ArcGIS Pro ou l’outil de Modification de la taille d’un champ d’une table (cf. $5.4).

!          Attention, il est fortement recommandé de faire une sauvegarde de la géodatabase modèle urba.gdb avant toute modification.

!          ATTENTION, s’il a été nécessaire d’augmenter la taille du champ ATTCOMP dans le modèle de données URBA 2018, il sera donc nécessaire d’augmenter la taille du champ ATTCOMP de la classe d’entités PLU_ZONE de la base données « destination » avant le chargement des données intégrées. Un avertissement apparaîtra avant le chargement si une différence de taille sur le champ ATTCOMP est observé :

!          Après avoir intégré et charger le PLU, PLUI ou PSMV en erreur, remettre la gdb de sauvegarde pour avoir le modèle de données d’origine. Cela permet de ne pas alourdir inutilement les données d’intégration à venir.