eq forums : Standard COVADIS remplacé : Plan local d'urbanisme v1.2

Adaptation du standard à un POS : Renseignement du TYPEZONE dans le cas d'un POS

2011-12-01T12:04:07Z

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é.

Adaptation du standard à un POS

2011-11-30T16:36:06Z

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

Attributs TYPE_PROCEDURE, ID_DOC_URBA et versement fichiers dans Géobase : Sous répertoires

2011-10-17T09:49:00Z

"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.

Une question qui taraude certains ADL et utilisateurs : PCT, SURF, LIN versus P, S, L

2011-10-17T07:22:16Z

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.

Une question qui taraude certains ADL et utilisateurs

2011-10-17T07:09:56Z

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.

document V1.2 COVADIS : N_ZONE_URBA : du bon usage du champs LIBELLE versus TYPEZONE

2011-10-13T15:22:17Z

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.

Structure des tables COVADIS PLU : Référencement des fichiers attachés au PLU dans les tables COVADIS

2011-09-30T14:39:13Z

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

document V1.2 COVADIS : HTML ?

2011-09-28T15:03:31Z

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

document V1.2 COVADIS

2011-09-28T14:42:50Z

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 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,

Structure des tables COVADIS PLU

2011-09-05T11:37:26Z

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)

Tables Mapinfo prêtes à l'emploi : GEOADS et les formats COVADIS

2011-08-30T12:33:16Z

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.

Tables Mapinfo prêtes à l'emploi : Gabarits des tables mis à jour en v1.2

2011-06-30T13:35:04Z

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)

Tables Mapinfo prêtes à l'emploi

2011-06-23T06:31:44Z

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 ?

Attributs TYPE_PROCEDURE, ID_DOC_URBA et versement fichiers dans Géobase : Précisions apportées par la version corrective 1.1 du standard PLU-POS

2011-06-07T09:54:14Z

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.

Attributs TYPE_PROCEDURE, ID_DOC_URBA et versement fichiers dans Géobase

2011-01-27T14:19:49Z

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 ?

Complément d'informations : Libellé, terme et saisie d'une zone PLU

2010-11-19T12:25:34Z

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.

Complément d'informations

2010-11-08T14:42:08Z

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

demande de précisions : Il y avait bien un champ en trop

2010-10-18T14:32:16Z

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.

Cahier des charges format éditable

2010-10-14T11:51:30Z

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

demande de précisions : Le champ ID_MAP est-il toujours pertinent ?

2010-09-28T13:10:23Z

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 qui est expliquée dans le paragraphe C.1.1