Standard COVADIS remplacé : Plan local d’urbanisme v1.2

Il y a 21 commentaires

1. 

   Stéphanie DELFAU a dit

   Bonjour,
   Une remarque dans la structure des tables MAPINFO, nous retrouvons un premier champ "ID_MAP" non décrit dans le standard validé par la COVADIS. Ce champ en principe proposé dans les couches validées par l’ex CNV est-il toujours d’actualité ? Par ailleurs j’ai relevé des différences entre la partie B et la partie C (par exemple dans la table MAPINFO de DOC_URBA il y a un champ ID_DOC_URBA_PRECEDENT qui n’est pas décrit page 16 alors qu’il l’est page 36) ?
   Merci.

2. 

   Jean-Loup Delaveau a dit

   Le champ ID_MAP ne fait pas partie du standard COVADIS dans la mesure où il s’agit d’un identifiant technique spécifique aux GéoBASEs qui est en effet un héritage du projet GéoMAP.
   Le secrétariat COVADIS avait fait le choix de le faire figurer dans chaque table Mapinfo standardisée pour ne pas perturber le fonctionnement des GéoBASE.
   Cependant, après vérification, aucune règle commune au MAAP et MEEDDM n’est définie au sujet de l’identification des objets. Cet ID_MAP est par conséquent obsolète, le champ peut être supprimé des tables concernées.
   Concernant les identifiants, le secrétariat COVADIS observe une règle simple : réserver le recours à des identifiants aux cas qui le justifient (identifiant préexistant, application nationale, implémentation d’une association sémantique)

   Ps : le différence entre parties B et C que vous mentionnez est normale : elle est due à l’implémentation de l’association <remplace> qui est expliquée dans le paragraphe C.1.1

3. 

   Glaser Alain a dit

   Bonjour,

   Très bien la mise à disposition des tables gabarit (que nous allons reprojeter en wgs84, système géodésique en usage en Guadeloupe/Martinique)

   Concernant le cdc, dommage que la version traitement de texte ne soit pas au format ooo

4. 

   Jean-Loup Delaveau (Secrétariat de la COVADIS) a dit

   Une erreur s’est glisée p.36 du standard PLU initialement diffusé : le champ DATVALID ne doit pas figurer dans la table N_DOCUMENT_URBA_ddd !
   Il a été supprimé des documents et de la table modèle concernée qui viennent d’être republiés.

5. 

   Frédéric Lasseron a dit

   Bonjour

   1) pour la table ZONE_URBA l’attribut libelle est celui reporté sur le plan (généralement court comme 2AU).

   y a t-il un attribut pour stocker sa signification ou son libellé long (ex : Zone pouvant à urbaniser à moyen et long terme à vocation d’habitat=2AU) définit dans le règlement ?

   2) y a t-il possibilité de codifier le terme d’une zone (court, moyen, long terme, indéterminé) dans un attribut ?

   3) ne faudrait il pas mettre ces éléments en relation avec une table pour l’ensemble du Plu ?

   cordialement

6. 

   Jean-Loup Delaveau (secrétariat de la COVADIS) a dit

   1) Comment peut-on stocker le libbelé court d’une zone d’urbanisme ?
   Le champ LIBELLE de la table N_ZONE_URBA_ddd a été codé sur 254 caractères de manière à laisser la possibilité de juxtaposer dans ce champ le nom court ou le nom long de la zone (en utilisant un caractère séparateur).
   Le besoin de gérer un champ spécficique pour le libellé court a été examiné mais l’instruction a conclus qu’il n’était pas indispensable de dissocier ces deux champs dans le standard COVADIS. De manière générale, un standard COVADIS définit le noyau minimal d’information utile à tous les métiers, qui n’interdit pas l’ajout local de champs spécifiques (à la seule condition que le champs ajouté n’induise ni confusion, ni contradiction).
   Pour des raisons de commodité qui vous sont propres, vous pouvez créer un attribut spécifique pour y écrire le libellé court de chaque zone.

   2) Est-il possible de codifier le terme d’une zone ?
   Cette notion de temporalité n’est traitée dans le standard que pour les zones à urbaniser AU. Les deux modalités AUc (à urbaniser alternatif) et AUs (à urbaniser bloqué) distinguent respectivement la constructibilité de court-moyen terme de celle de long terme.

   3) Ne faudrait-il pas commencer par saisir tous les libellés longs des zones du règlement dans une table-paramètre avant de procéder à la saisie des zones (une jointure des deux tables rend plus aisé le remplissage du libellé de chaque zone) ?
   Les standards de la COVADIS ne se préoccupent pas des modalités de saisie des données (même si ils peuvent contenir quelques conseils ou règles). Chaque producteur peut tout à fait optimiser son processus de saisie en fonction des caractéristiques de ses sources de données.

7. 

   Solange Charpentier a dit

   1 - Table N_PROCEDURE_URBA_ZSUP : pour l’attribut TYPE_PROCEDURE, il manque la révision simplifiée dans la liste des valeurs possibles

   2 - Attribut ID_DOC_URBA dans les tables N_DOCUMENT_URBA, N_ZONE_URBA et N_PROCEDURE_URBA_ZSUP. Il est prévu que cet identifiant soit construit par concaténation du code INSEE ou numéro SIREN avec la dernière date d’approbation (§B.1.2). Cette concaténation n’est pas suffisante pour respecter le caractère unique de l’identifiant, deux procédures différentes pouvant être approuvées le même jour. C’est le cas de plus en plus fréquent pour les modifications, modifications simplifiées et révisions simplifiées. Ce problème se retrouve également pour le nommage des répertoires (§C.1.2).
   Nous avons donc construit l’identifiant et le nom des répertoires de la même façon suivante : INSEE_nature du document_date d’approbation_type de procédure. Exemple :
   50294_PLU_20031014_R (révision approuvée 14/10/2003) ;
   50294_PLU_20070201_RS1 (1ère révision simplifiée approuvée 01/02/2007) ;
   50294_PLU_20090703_MS1RS2 (1ère modification simplifiée et 2ème révision simplifiée approuvées le 03/07/2009).

   3 - Versement des fichiers dans la géobase
   L’arborescence de la géobase prévoit un versement des fichiers, par commune, dans le répertoire INSEE_PLU_AAAAMMJJ. Outre le problème dans le nom du répertoire (soulevé dans le 2ème point), est-il possible de verser directement et uniquement les couches départementales (lesquelles correspondent d’ailleurs au nom des fichiers prévu dans ce répertoire? ex N_ZONE_URBA_050. Nous réalisons déjà ces couches départementales pour la mise en ligne plus aisée des données sous Cartélie. Le versement par commune est très lourd. De plus, si on souhaite verser les fichiers par commune, comment fait-on pour changer le nom du répertoire INSEE_PLU_AAAAMMJJ ?

8. 

   Jean-Loup Delaveau (Secretariat de la COVADIS) a dit

   1 - Cette première question concerne le standard Zonages des politiques de l’habitat, de la ville et de la planification urbaine et rurale qui définit les procédures d’urbanisme. La révision simplifiée (spécifique aux POS et PLU) ne s’applique plus depuis le 1er janvier 2010. C’est pour cette raison que cette valeur ne figure pas parmi les types de procédure décrits.

   2- Cette question a été traitée par le GT PLU du CNIG qui a décidé de retenir une approche objet : le document d’urbanisme doit être vu comme un document dématérialisé composé d’objets géographiques numériques. De ce point de vue, l’administrateur des données doit modifier tous les objets du document qui sont impactés le même jour par plusieurs procédures. Le résultat est alors d’obtenir une seule version numérique du document d’urbanisme.
   Nb : la table N_PROCEDURE_URBA_ZSUP permet justement de conserver la trace de ces procédures.

   3- La gestion des données à la commune est lourd mais c’est un mal nécessaire si on veut conserver toutes les versions successives d’un document d’urbanisme (car les contentieux en ADS obligent à le faire). C’est mal pratique à utiliser et une seule table départementale va en effet beaucoup mieux (notamment pour travailler dans Cartélie).
   Ne conserver qu’une table départementale pose problème quand un PLU est modifié : il n’est pas question de stocker deux PLU successifs d’une même commune dans la table départementale ce qui produirait un sandwich géographique indigeste et inutilisable. Il n’est pas non plus question d’écraser des données PLU qui ont été opposables : les données de PLU obsolètes doivent être archivées.
   Le discours maintient que les besoins nécessitent autant des données à la commune (conservation, suivi de données opposables à la commune) que des données au département (commodité d’utilisation, cartographie, publication, consultation). Ces dernières doivent faire l’objet d’un prochain standard de données sur les zones généralisées des documents d’urbanisme.
   Enfin le nom INSEE_PLU_AAAAMMJJ ne peut pas être changé dans le GéoREPERTOIRE en effet. Mais il s’agit d’un répertoire spécimen « factice » qui sert à indiquer les modalités de classement d’un PLU dans la GéoBASE. L’arborescence de votre GeoBASE locale peut être complétée par autant de sous-répertoires que nécessaire.

9. 

   laurent a dit

   Bonjour,

   Merci de passer aussi en version 1.1 du Standard COVADIS les "tables Mapinfo prêtes à l’emploi".
   Est ce que l’application GEOADS est aussi modifiée en conséquence ?

10. 

    DELAVEAU Jean-Loup a dit

    Les tables Mapinfo prêtes à l’emploi - ou gabarits - viennent d’être mises à jour en même temps que la publication du standard PLU version 1.2.
    La structure logique des tables n’a pas changé depuis la version 1.
    Deux évolutions sont à signaler :
    – le contenu de la table DOCUMENT_URBA_TYPE a gagné un enregistrement correspondant à la modalité "carte communale"
    – le nom des tables communales contient depuis la version 1.2 le code INSEE complet de la commune concernée (suite à une requête du PAN ADS)

11. 

    Gaelle a dit

    GeoADS permet d’intégrer pour l’instant les PLU au format COVADIS v1.1.
    Le passage à la version 1.2 fait partie des améliorations demandées dans la prochaine version.
    GeoADS évoluera pour prendre en compte les formats COVADIS en cours des POS/PLU, Cartes Communales et Servitudes d’utilité publiques.

12. 

    Sabine a dit

    Bonjour,

    Ne pourrait-on pas revoir la taille du champ NOMFIC des <> tables du
    standard COVADIS POS-PLU ? le fixer à 150 voire 254 (max)

    En utilisant le serveur FTP-SIG utile à Cartelie …, le lien par défaut
    "http://piece-jointe-carto.developpement-durable.gouv.fr/DEPT037A/" dans
    notre cas, utilise déjà 66 caractères , ce qui ne laisse pas de place
    suffisante pour les répertoires de classement et les fichiers PDF des
    règlements, prescriptions, annexes (correctement nommés) utiles à
    Cartelie, à GeoADS

    Si oui, il faudrait revoir aussi l’implementation pour GeoADS (rendre
    possible l’accès à ces documents centralisés sur le serveur FTP-SIG sous
    GeoADS. et éviter ainsi les doublons de téléversements ou manque de
    possibilité de téléversements. rendre l’accès possible sous GéoADS à
    l’ensemble des données renseignées dans les tables (actuellement les
    info-bulles donnent accès à une partie minime des informations utiles)

13. 

    O. CARDOT a dit

    Bonjour,
    1 - un peu de vulgarisation des documents aurait été la bienvenue. Quelques exemples, afin de savoir ce qui se cache derrière les codifications issues des modéles conceptuels de données.
    2 - dans le document COVADIS du 30 juin 2011 - version 1.2 : serait-il possible d’homogénéiser le texte ? La valeur code INSEE d’une commune, utilisée pour nommer les fichiers ou servir d’attribut, est tantôt <INSEE> tantôt ccccc. Et parfois dans la même page qui plus est (35/61) …
    3 - la philosophie de cette démarche de dématérialisation des documents d’urbanisme étant d’avoir un "mirroir" du document papier (validé, officiel et seul opposable aux tiers), ne risque t’on pas une perte d’informations et un risque de confusion dans le cas de la couche N_ZONE_URBA, champs TYPEZONE ?
    Les valeurs possibles ne reprennent pas l’ensemble des cas rencontrés. Une dérogation quasi systèmatique à la liste de valeurs proposée semble s’imposer.
    Merci pour vos infos et renseignements éventuels.
    Cordialement,

14. 

    O. CARDOT a dit

    Désolé, apparemment le HTML n’a pas aimé les < > ? Dans le texte" est tantôt < INSEE> tantôt ccccc "

15. 

    Arnauld Gallais (CETE Ouest, PAN ADS) a dit

    Dans l’esprit du CCTP du CNIG et donc du standard COVADIS qui en découle, les champs NOM (limités à 80 caractères) sont considérés comme suffisants pour stocker les noms de fichiers documentaires, mais leur nom seulement, sans leur chemin d’accès…

    Ces champs NOM ne sont donc actuellement pas prévus pour accueillir des URL ou des chemins absolus vers un fichier car le standard COVADIS suppose un stockage normalisé des données dans l’arborescence Géobase (cf § B.1.6 "Stockage des données" et § C.1.2 "Livraison informatique" dans COVADIS_standard_PLU_v1-2)

    En suivant les spécifications CNIG et COVADIS les emplacements normalisés sont :

    Le fichier : [INSEE]_rapport_[date_approbation].pdf est dans :
    //[Serveur Géobase]/AMENAGEMENT_URBANISME/N_ZONAGES_PLANIFICATION/[INSEE]_PLU_[date_approbation]/Pieces_ecrites/1.Rapport_presentation

    Le fichier : [INSEE]_padd_[date_approbation].pdf est dans :
    //[Serveur Géobase]/AMENAGEMENT_URBANISME/N_ZONAGES_PLANIFICATION/[INSEE]_PLU_[date_approbation]/Pieces_ecrites/2.PADD

    Le fichier [INSEE]_reglement_[date_approbation].pdf est dans :
    //[Serveur Géobase]/AMENAGEMENT_URBANISME/N_ZONAGES_PLANIFICATION/[INSEE]_PLU_[date_approbation]/Pieces_ecrites/3.Reglements

    Les fichiers : [INSEE]_orientations_[date_approbation].pdf et autres annexes sont dans :
    //[Serveur Géobase]/AMENAGEMENT_URBANISME/N_ZONAGES_PLANIFICATION/[INSEE]_PLU_[date_approbation]/Pieces_ecrites/4.Annexes

16. 

    DELAVEAU Jean-Loup a dit

    1- Le catalogue d’objets en B.3 décrit en détails et de manière littérale tous les éléments représentés sur le modèle conceptuel de données. L’idée de donner des exemples peut certainement être utile mais également parfois restreindre le discours ou induire en erreur le lecteur… De toute façon il nous est difficile d’en faire plus aujourd’hui si on veut garder des documents "maintenables" dans le temps.

    2- Très juste, ce point sera homogénéisé lors de la mise à jour du standard envisagée en 2012.

    3- Nous admettons que le standard est incomplet sur ce point. Non pas qu’il faille allonger la liste de valeurs possibles du champs TYPEZONE. Le standard propose deux champs relatifs au code de la zone : le champs LIBELLE doit contenir le code figurant réellement sur le plan opposable (aucune modification n’est à apporter) tandis que le champs TYPEZONE ne peut contenir uniquement une des valeurs de la liste simplifiée du standard (cette liste est validée par le groupe PLU du CNIG). Aucune dérogation n’est donc nécessaire.
    Mais quelques explications complémentaires sont à apporter sur ce point. Une fiche-méthode sera annexée au standard PLU sur la façon de remplir TYPEZONE en fonction du code ’opposable’ de la zone que se trouve dans le champs LIBELLE.

17. 

    O. CARDOT (DDT 52) a dit

    Pourquoi avoir distingué les géométries des tables par les extensions LIN, SURF, PCT (N_PRESCRIPTION SURF, N_PRESCRIPTION_LIN …)
    alors que la DDAF utilisait L, S, P dans son système GéoBASE pour définir la primitive graphique des tables - comme ce qui est fait dans le standard SUP ? Les noms des fichiers s’en trouvent alors allongés ce qui n’est pas pratique dans le contrôle des couches de MapInfo.

18. 

    Jean-Loup DELAVEAU (secretariat de la COVADIS) a dit

    Le secrétariat COVADIS a, il est vrai, repris la convention de nommage du GéoREPERTOIRE car elle était bien assimilée des géomaticiens issus de la maison agriculture et avait le mérite d’exister au moment où les travaux démarrait.
    Cependant, certains cas de figure nous font prendre quelques libertés par rapport à cette convention. Et le standard PLU en fait partie. Nous avons choisi de reprendre les mêmes noms de tables que ce que propose le CNIG mais en leur ajoutant N_ en préfixe et _ddd en suffixe nécessaire à la GéoBASE.
    Il faut comprendre que PCT, SURF et LIN ne remplacent pas P, S et L malgré les apparences certes trompeuses car :
    la partie du nom signifiant de la table "INFO_SURF" traduit simplement le nom de la classe d’objets Info_SURF du modèle conceptuel PLU. Un strict respect des règles de nommage du GéoRépertoire aurait produit le nom de table N_INFO_SURF_ccccc_S_ddd.TAB. L’ajout du _S crée une répétition que l’on a considérée superflue.
    C’est pourquoi cette table s’appelle N_INFO_SURF_ccccc_ddd : si on enlève le suffixe et le préfixe, on retrouve le nom de table préconisé dans les recommandations nationales du CNIG. C’est ce qui a déterminé notre choix qui comme tout choix est discutable. Ce qui prime est :
    1- que les échanges avec les collectivités soient facilités
    2- que tous les services utilisent le même nom pour désigner la même table.

19. 

    O CARDOT a dit

    "Enfin le nom INSEE_PLU_AAAAMMJJ … autant de sous-répertoires que nécessaire."
    Cela aurait profitable à tout le monde et un gain de temps de mettre l’ensemble des sous-répertoires devant être crées sous ce répertoire.

20. 

    Glaser a dit

    Bonjour,

    Le champ TYPEZONE de la table N_ZONE_URBA_ccccc_ddd est codifié sur 3 caractères. Dans le cas d’un pos, des secteurs à numériser peuvent avoir un attribut de 5 caractères (exemple IINAc.)

    Avons nous liberté de rajouter un attribut (par exemple SECTEUR sur 5 caractères)?

    Ne risque t’il pas d’y avoir une contre indication par rapport à GEOADS ? (je ne sais pas s’il y a un rapport quelconque entre le standard covadis et la structure des données pour géoads)

    Alain Glaser

21. 

    Jean-Loup Delaveau (secretariat COVADIS) a dit

    L’ajout de cet attribut SECTEUR n’est pas nécessaire dans votre cas de figure car le champ LIBELLE de cette table doit servir à stocker cette information (rappel de la définition du champ LIBELLE : "Libellé de la zone tel que le définit le règlement"). Le champ libellé doit contenir le code qui figure sur le document opposable. De surcroit, l’ajout de cet attribut SECTEUR n’est pas souhaitable car il pourrait laisser à penser aux secteurs d’une carte communale.
    Mieux vaut donc utiliser le champ LIBELLE (254 caractères).

    Le champ TYPEZONE est énuméré : les valeurs possibles sont imposées par le standard PLU.
    Et le remplissage de ce champ dans le cas des POS est l’objet de fréquentes questions. Le GT CNIG PLU a réalisé une table de correspondance entre les types de zone POS et les valeurs standardisées du TYPEZONE en page 24 du document : http://www.geomatique-aln.fr/IMG/pdf/Introduction_V2011_1_cle0b7643.pdf

    Il n’est donc pas besoin de faire d’adaptations du standard PLU pour les POS !

    Enfin, le point d’appui national ADS se base sur le standard PLU pour développer les interfaces d’import des données dans GéoADS. Tout nouveau champ ajouté localement à une table du standard ne sera vraisemblablement pas importé.