Un modèle de données est issu d’une modélisation. Modéliser, c’est doter une information d’une structure solide qui permettra, d’une manière efficace, d’optimiser l’échange des données entre les applications pour obtenir l’information souhaitée.
Il s’agit donc d’identifier les objets du monde réel comme des entités possédant deux types d’attributs:
les attributs descriptifs (alphanumériques), qui donnent une description de l’objet;
les attributs graphiques, qui décrivent la géométrie de l’objet.
Dans les spécifications nationales le modèle de données est traduit sous forme de graphe sur deux pages.
La première page du modèle montre la répartition des informations en « grands blocs » (rectangles roses et gris). Chacun de ces « blocs » correspond a une grande catégorie d'information (Objet). En géomatique une information est catégorisée soit parce qu’elle a une géométrie spécifique (Surface, Ligne, Point, Texte), soit parce qu'elle est identifiée comme représentant une information importante (Prescriptions, Informations).
Ces « blocs » sont traduites dans les spécifications nationales en classes d'objet.
Dans chaque « bloc » il y a des informations spécifiques (lignes rouges). Ces informations correspondent aux attributs des classes. Certain attribut sont libres ou fortement contraint par des format de saisie. D'autre sont directement définis par des listes pré établies. On retrouve ces listes dans la deuxième partie du modèle de donnes.
Le modèle de données des PLU a été pensé pour prendre en compte toute l’information nécessaire à son édition au format papier à partir des informations numériques. Pour cela, et pour faciliter son utilisation, ce modèle de données est la structure minimale à donner au document d’urbanisme.
Par conséquent Il est:
possible d’ajouter des informations supplémentaires au modèle de données proposé;
IMPOSSIBLE d’en enlever.
L’annexe I des prescriptions nationales de dématérialisation des documents d’urbanisme propose des exemples d’ajout d’informations pour répondre à des besoins locaux.
Le standard distingue entre la partie conceptuelle qui est unique et les implémentations informatiques ouvrant à plusieurs possibilités : CNIG, COVADIS, Arcopole, etc.
La maîtrise d'ouvrage, doit donc bien indiquer l'implémentation attendue.
Les prescriptions nationales préconisent pour la classe DOCUMENT_URBA (annexe H) d’indiquer le nom du fichier du plan scanné du document d’urbanisme dans l’attribut NOMPLAN. Si plusieurs plans sont nécessaires alors il est conseillé de faire un fichier unique dans lequel on retrouvera l’ensemble des documents.
Date d'approbation
La date d'approbation est la “date correspondant à la dernière évolution du document d'urbanisme qu'il s'agisse d'une modification, d'une révision, d'une révision simplifiée, d’une mise à jour ou d’une mise en compatibilité, même si elle ne concerne que la partie écrite du règlement (par exemple, une modification du règlement concernant la pente des toitures). Elle signifie que le document numérisé intègre les informations du document approuvé à l'origine ainsi que les évolutions successives jusqu'à cette date.”
La notion de date d'approbation du PLU numérisé telle qu'elle est définie dans les prescriptions du CNIG correspond à la date de la délibération qui approuve ou acte l'adoption de toute procédure constitutive d'un document d'urbanisme, que ce soit son élaboration, une révision, une modification, une révision simplifiée, une modification simplifiée, etc.
Le document numérisé accueille ainsi la représentation de la succession des procédures constitutives du document d'urbanisme en vigueur.
Il est associé dans sa globalité à une seule date, la DATAPPRO, qui correspond à la date d'approbation de la dernière procédure, quelque soit son importance, prise en compte par la numérisation.
Son objectif n'est pas de “dater” chacune des pièces constitutives du document d'urbanisme tel qu'il peut se présenter en format papier, mais de “dater” la correspondance entre la numérisation et les procédures qui se sont succédées pour un même document d'urbanisme.
Concrètement, il ne faut pas continuer à désigner par sa date de révision ou modification un document ayant fait l'objet d'une simple mise à jour (par exemple : incorporation de servitudes) par arrêté municipal, car pour le PLU numérisé une simple mise à jour est bien considérée comme une évolution du document d'urbanisme.
La date d'approbation DATAPPRO est la même date pour tous les fichiers du jeu de données correspondant au document d'urbanisme numérique.
Date de validation
Les prescriptions de dématérialisation ne gèrent pas l'historique des documents. Néanmoins, certains utilisateurs ont fait part du besoin de conserver la date d'apparition ou de dernière modification des zonages d'urbanisme. La date de validation, attribut de la classe ZONE_URBA correspond à celle du dernier changement apporté à la zone ou à son règlement.
Elle est donc antérieure ou égale à la date d'approbation du document d'urbanisme auquel appartient la zone.
Concrètement, si une zone d'urbanisme porte une date de validité au 6 mai 2007 au sein d'un PLU approuvé le 25 février 2012, cela signifie qu'elle n'a pas été impactée par les évolutions du document depuis le 6 mai 2007.
Le modèle de données proposé par les prescriptions nationales prévoit de prendre en compte les PLU Intercommunaux. Pour cela il faut utiliser les classes prévues en annexe H.
Dans la classe DOCUMENT_URBA , l’identifiant du PLU intercommunal sera composé par la concaténation du code SIREN de intercommunalité et de la date d’approbation du document.
Dans la classe DOCUMENT_URBA_COM, l’identifiant cité précédemment permet de faire le lien avec les numéros INSEE des communes couvertes par le document intercommunal de planification. Enfin une référence au Code Officiel Géographique (COG) permet de garder l’année de référence du périmètre administratif des territoires concernés.
Le COG se trouve sur le site Internet de l’INSEE.
Cet attribut supplémentaire n’a pas été retenu. En effet il est possible de trouver des zones U ou AU ayant plusieurs COS.
Il est intéressant de noter que l’implémentation du COS par zone peut répondre à des logiques d’études et d’analyse prospectives du territoire. Si le choix est fait localement de renseigner le COS pour une zone il convient de s’assurer au travers du règlement que cette zone a un seul et unique COS.
Dans le modélisation prescrite il n’est pas prévue de faire apparaître des informations relatives aux prescriptions.
Toutefois si vous avez des besoins locaux de connaître ces informations vous pouvez vous référer à l’annexe I des prescriptions nationales. Vous y trouverez différentes façons de procéder pour implémenter les renseignements qui vous concernent.
La seule contre indication existante sur la superposition de géométrie concerne les zonages. En effet ces derniers sont calés sur la géométrie des parcelles. Il faut donc que chaque parcelle d’un territoire donné appartienne à un type de zonage. Pour le reste des polygones il est tout à fait envisageable d’avoir une superposition d’information.
Il est spécifié dans le catalogue d’objets que le champs LIBELLE doit recevoir le nom court de la zone. Le nom complet de la zone apparaitra dans le champ LIBELONG prévu dans le version 2012-1 des prescriptions nationales pour la dématérialisation des documents d’urbanisme.
un conseil municipal (ou une autorité compétente) peut approuver le même jour plusieurs modifications sur le document d’urbanisme de son territoire. Les prescriptions nationales de dématérialisation permettent de gérer une image numérique quotidienne du document opposable. Par conséquent les mises à jour ne seront pas traité procédure par procédure mais jour par jour. Ainsi l’ensemble du document prendra une DATAPPRO égale à la date du jour des approbations. Et seuls les éléments modifiés par ces procédures prendront une DATEVALID égale à la date du jour des approbations.
Non. Il n’y a pas de recommandations particulières pour la sémiologie à utiliser pour les cartes communales. Il est important de ne pas utiliser la même sémiologie que pour les POS et PLU, les natures des zonages n’étant pas les mêmes.
Seul dans le cas d’une carte généralisée des zonages à l’échelle d’un département (ou plus) une sémiologie similaire pourra être utilisée.
Par soucis de cohérence entre les différent documents d’urbanisme non la même structure d’identifiant que pour les POS et les PLU. Ainsi dans le cas d’un PLU, l’identifiant commence soit par le numéro SIREN codé sur 9 caractères s’il est intercommunale, soit par 0000+n°INSEE s’il est strictement communale. La règle est donc la même pour l’identifiant de la Carte Communale
Si vous souhaitez faire apparaître des orientations d’aménagement sur certains zonages il est conseillé de procéder de la façon suivante. Dans le répertoire prévu pour stocker les différentes pièces écrites (chapitre 2.3 de l’Annexe B) créez un sous répertoire « orientation d’aménagement » où vous viendrez stocker les différents documents. Puis dans la classe « PRESCRIPTION_SURF » saisissez l’emprise et vous renvoyez vers le PDF du document.
Les prescriptions nationales précisent que la mise à jour est une des procédures administratives prise en compte. Dans ce cas, il n'y a pas de délibération d'approbation mais un arrêté de mise à jour pris en application de l'article R123-22 du Code de l'urbanisme ; c'est donc la date de cet arrêté qui figure dans le champ DATAPPRO. Par conséquent, les instructeurs sauront s'ils ont la bonne version du document d'urbanisme, même en cas de mise à jour.
Les Prescriptions sont des règles édictées par le PLU lui même, par opposition aux périmètres d'information (ou Informations) qui trouvent leur origine dans une source extérieure au PLU.
L’occurence 11 concerne les limitations particulières d'implantation des constructions (bande constructible, marge de recul, zone non aedificandi, alignement, emprise des constructions, …).
L’occurrence 15 concerne les règles d'implantation des constructions par rapport aux voies, emprises publiques et limites séparatives.
Il faut retenir que la règle qui s’applique pour choisir à quelle occurrence appartient une prescription est que l’on fait apparaître dans l’occurrence 11 tout ce qui ne va pas dans la 15. En effet l’occurrence 15 fait uniquement référence aux règles qui s’appliquent au titre des articles R123-9 6° et 7° et R123-11.
Pour rappel :
L’occurrence 02 des prescriptions concerne les secteurs avec limitation de la constructibilité ou de l’occupation pour des raisons de nuisances ou de risques (R123-11 b).
L’occurrence 14 des informations concerne les périmètres de voisinage d’infrastructure de transport terrestre (R123-13 13)
L’occurrence 2 est clairement encadrée par le R 123 11 b et apparaissent dans cette occurrence uniquement les dispositions qui relèvent de la collectivité. L’occurrence 14 des informations permet d’intégrer des dispositions extérieures à la collectivité prises par arrêté préfectoral.
Ces attributs ont été créés afin de répondre aux pratiques locales. En effet le code de l’urbanisme ne prévoit pas que les cartes communales puissent avoir des prescriptions. Ce que la version 2011-1 du cahier des charges des Cartes Communales avait traduit en supprimant la classe prescription. Cependant des remarques sont remontées au groupe de travail concernant la dématérialisation des « limitations particulières d’implantation des constructions » qui sont des prescriptions dans les PLU et qui apparaissent dans certaine cartes communales. Il s’agit d’intégrer ces objets dans les cartes communales en conservant les références communes avec la nomenclature d’objet des PLU sans leur donner le même statu réglementaire des PLU. Pour éviter de créer trois nouvelles classes (prescription) non justifiées dans la version 2012-1 le groupe a décidé de créer des nouveaux attributs dans les classes INFORMATION afin de rester conforme au sens du code de l’urbanisme.
Ainsi TYPEI sert à définir le type des éléments géométriques de nature informative.
Le TYPEP sert à définir des éléments qui seraient autres mais qui font référence à la liste des Prescriptions dans les POS/PLU.
Le contenue d’une carte communale définit par le code de l’urbanisme ne prévoit pas de faire apparaître des prescriptions sur les documents graphiques. La version 2012-1 des prescriptions nationales pour la dématérialisation des cartes communales permet de prendre en compte ce cas. Deux attributs ont été modifiés ou crées afin de mieux ventiler l’information contenue dans une carte communale.
L’attribut TYPEP sert à rattacher les informations faisant référence à la liste des occurrences de prescription du Cdc PLU et POS, notamment les périmètres de la Loi Barnier.
Les prescriptions nationales recommandent de travailler avec un fichier de règlement qui soit entier, au format pdf et indexé afin de faciliter son utilisation. L’indexation d’un document pdf peut se faire avec plusieurs logiciels (Adode Acrobat, Foxit distiller, Open Office..). Dans tous les cas l’opération consiste à créer un signet à la position choisie (début de règlement pour une zone précise ou début de page par exemple). Le fichier pdf ainsi créé contient les index permettant une utilisation plus rapide du document.
Une question a été posée concernant le type de zone simplifié proposé pour les zones à urbaniser (AU dans les PLU, NA dans les POS). Il est prévu deux types de zone :
Il est demandé si on ne pourrait pas plutôt les appeller 1AU et 2AU.
La position du groupe de travail est de ne pas changer l'organisation actuelle et ce principalement pour deux raisons :