Habillages linéaires du PLU (doc. du 26.04.2011) de la commune d'Oizon
Organisation : Direction Départementale des Territoires du Cher
Fréquence de mise à jour : unknown
Mots-clés : passerelle-inspire,structure,usage-des-sols
Formats disponibles : zip,shp

Les éléments d'habillage sont des écritures en rapport avec une disposition réglementaire (largeur de voie, cote, nom des communes voisines.) ou des éléments géométriques surfaciques, linéaires ou ponctuels indicatifs, habillant les documents graphiques du PLU ou du POS. Ils sont nécessaires pour l'édition sous forme papier des documents graphiques opposables. Ce peut être, par exemple, une emprise d'un plan de détail, un cadre, un cartouche, un trait de rappel pour une écriture, un trait pour dessiner une cotation, une étiquette d'identification d'un équipement

__Origine__

Sources des géométries :
Les géométries de la table des adresses et de la table des opérations diffuses sont issues de la base Adresse de la Ville de Paris (actualité 2016). Il s’agit du point-adresse associé dans cette base à l’adresse renseignée dans le champ adr_loc (qui correspond au champ l_adr de la base Adresse).
Les géométries de la table des secteurs ont été produites par l’UDEA 75. Elles peuvent être issues, selon le cas, de la donnée Zone d’aménagement concerté de Paris (actualité mai 2017) ou du Tableau de bord du foncier public mobilisable pour le logement (actualité avr. 2017).

Traitements automatiques sur les dénominations :
La géolocalisation des enregistrements s’est fondée en premier lieu sur les informations renseignées dans la dénomination des opérations. Trois séries de traitements automatiques sur denom_op ont permis d’identifier un secteur ou une adresse valide pour une large part des 1 838 enregistrements : 1 175 géolocalisations à l’adresse lors du premier traitement automatique, 311 géolocalisations à l’adresse lors du second traitement automatique, 83 géolocalisations automatiques au secteur.
Remarque sur les adresses multiples
Il est fréquent que les dénominations SISAL ne mentionnent pas une unique adresse, mais associent un intervalle de numéros à un libellé de voie (‘3-5 RUE DE LILLE’, par exemple). Elles peuvent également, plus rarement, se référer à plusieurs voies. Hormis pour les opérations diffuses, évoquées ci-après, qui concernent plusieurs adresses très éloignées les unes des autres (parfois dans des arrondissements différents), il a été admis de réaliser la géolocalisation sur une seule adresse, choisie arbitrairement parmi celles qui sont citées.

Premier traitement sur les adresses :
Le premier traitement automatique à l’adresse s’est appuyé sur le constat que les opérations avaient le plus souvent une dénomination de la forme [Numéro de délibération][Organisme][Localisation][Informations diverses sur les logements], certains de ces éléments pouvant toutefois être omis. Il a suivi la méthode suivante :
(1) extraction de l’identifiant de la délibération et du nom de l’organisme – dans le cas où ces informations apparaissent dans la dénomination ;
(2) simplification de la chaîne de caractères résultante : mise en majuscules, remplacement des lettres complexes (suppression des accents, des cédilles…) par leurs équivalents simples, normalisation des types de voie et des indices de répétition, suppression des abréviations courantes (‘ST’ pour ‘SAINT’, ‘GAL’ pour ‘GENERAL’…), suppression de tous les caractères spéciaux (apostrophes, tirets, virgules, points…) qui ne sont pas utilisés pour séparer deux numéros de voie ;
(2b) suppression des espaces ;
(3) simplification équivalente du champ l_adr de la base Adresse ;
(4) recensement de toutes les adresse de la base Adresse, dont la forme réduite (issue de l’étape 3) est exactement incluse dans la dénomination simplifiée (issue de l’étape 2b) ;
(5) attribution à l’enregistrement de la plus longue de ces adresses.
Par exemple, pour la dénomination fictive ‘2016DLH 001 3-7, 11, boulevard de l’école de médecine 3 PLAI AA 13e’ :
étape 1 : ‘2016DLH 001’ est reconnu comme présentant une forme d’identifiant de délibération. Il est retiré de la chaîne de caractères, qui devient ‘ 3-7, 11, boulevard de l’école de médecine 3 PLAI AA 13e’ ;
étape 2 : transformation en ‘ 3-7, 11 BD DE LECOLE DE MEDECINE 3 PLAI AA 13E’ ;
étape 2b : transformation en ‘3-7,11BDDELECOLEDEMEDECINE3PLAIAA13E’ ;
étapes 3-4 : la comparaison avec la base Adresse renvoie les adresses (fictives) ‘1BDDELECOLEDEMEDECINE’, ‘11BDDELECOLEDEMEDECINE’, ‘1BDDELECOLE’, ‘11BDDELECOLE’ ;
étape 5 : sélection de ‘11BDDELECOLEDEMEDECINE’, qui est la plus longue de ces adresses.
Il peut être noté que, lorsque la dénomination se réfère à plusieurs numéros de voie, cette méthode a pour conséquence immédiate de ne rechercher des correspondances que sur le dernier de la liste.
Par ailleurs, elle présente l’inconvénient notable de pouvoir retourner des résultats erronés si l’adresse recherchée n’existe pas dans la base Adresse. Ainsi, dans l’exemple précédent, si la dénomination SISAL avait contenu une coquille telle que ‘médicine’ au lieu de ‘médecine’, alors les seules correspondances pour ‘3-7,11BDDELECOLEDEMEDICINE3PLAIAA13E’ auraient été ‘1BDDELECOLE’ et ‘11BDDELECOLE’. ‘11BDDELECOLE’ aurait été retenu à tort.
Cette question a pu être en partie résolu par l’extraction du dernier numéro de voie (avec son indice de répétition éventuel) de la dénomination et la vérification de son inclusion dans l’adresse obtenue. Ceci a notamment permis d’éviter la situation où ‘1BDDELECOLEDEMEDECINE’ aurait été retenu au lieu de ‘11BDDELECOLEDEMEDECINE’ parce que la base Adresse n’aurait pas recensé de n°11 pour cette voie. Ce test détecte efficacement les erreurs sur les numéros de voie, mais il n’autorise toutefois pas le repérage de celles qui affectent les libellés.
Pour cette raison – et parce que le second traitement automatique mené par la suite est également susceptible de présenter des failles, toutes les adresses déduites des dénominations ont fait l’objet d’un contrôle manuel a posteriori.
Les enregistrements géolocalisés lors de cette étape ont un obs_loc égal à 1.

Second traitement sur les adresses :
Le second traitement automatique a été appliqué aux enregistrements qui n’avaient pas trouvé de correspondance dans la base Adresse lors du premier traitement. À partir de la chaîne de caractères résultant de la normalisation de la dénomination (étapes 1 et 2 du premier traitement), il a suivi la méthode suivante :
(3) identification d’un numéro de rue (le dernier mentionné par la dénomination si celle-ci en cite plusieurs), avec son indice de répétition éventuel ;
(4) extraction de la chaîne de caractère du premier « mot » de cinq lettres ou plus qu’elle contient (s’il y a lieu). Ce mot se définit comme une sous-chaîne précédée et suivie d’un espace, qui ne compte que des caractères de type lettre ;
(5) recensement de toutes les adresses de la base Adresse dont le numéro de rue (avec compléments) correspond à celui qui a été identifié et dont la forme réduite (cf étape 3 du premier traitement) contient le mot extrait de la dénomination ;
(6) si l’étape 5 ne renvoie qu’une adresse, alors celle-ci est conservée. Sinon, le traitement ne retourne pas de résultat.
Le principe de ce traitement est de permettre la mise en correspondance d’adresses à partir de deux informations caractéristiques : le numéro de voie et un terme suffisamment long pour qu’il puisse être espéré qu’il soit spécifique au nom de la rue concernée. Lorsque le mot sélectionné n’était pas suffisamment discriminant et que plusieurs correspondances sont possibles, elle ne renvoie pas de résultat.
Les enregistrements géolocalisés lors de cette étape ont un obs_loc égal à 2.
NB : pour quelques enregistrements de l’année 2015 qui n’avaient pas encore été localisés à l’issue de ce second traitement, la normalisation d’adresses réalisée en 2016 par l’UDEA 75 sur les opérations agréées en 2015 a été mobilisée. Ces enregistrements ont également reçu un obs_loc égal à 2. Ils se caractérisent par le fait que leurs adresses tendent à retenir le premier numéro de voie de la dénomination et non le dernier. Le contrôle manuel systématique a porté aussi bien sur ces enregistrements que sur ceux qui avaient été géolocalisés par les deux traitements automatiques.

Traitement sur les secteurs :
Le repérage des enregistrements à associer à des secteurs et leur mise en correspondance avec les secteurs qu’ils concernent a consisté en une série de tests d’inclusion dans les dénominations de mots clés caractéristiques des noms de secteurs. N’ont été traités que les enregistrements contenant les chaînes de caractères ‘[espace]ZAC[espace]‘, ‘[espace]LOT[espace]’ ou ‘[espace]PRG[espace]’ (pour Paris Rive Gauche), considérés comme les plus susceptibles de se référer à des secteurs plutôt qu’à des adresses. Le traitement automatique a été conforté par un contrôle manuel systématique.
Les enregistrements géolocalisés lors de cette étape ont un obs_loc égal à 5.

Identification manuelle des adresses :
Les enregistrements qui n’avaient pas pu être géolocalisés à l’issue des trois traitements automatiques ont été repris manuellement.
Pour une large partie d’entre eux, la correspondance n’avait pu être faite parce que la forme de l’adresse dans la dénomination était trop différente de la forme normalisée de la base Adresse (à cause d’une coquille, par exemple), mais il n’y avait pour autant pas de doute possible sur l’adresse à retenir. Pour ces enregistrements, les adresses ont été reprises manuellement pour correspondre à la forme de la base Adresse. Leur obs_loc prend la valeur 3.
Dans certains cas, les informations contenues dans la dénomination, ne permettaient pas d’identifier avec certitude une adresse. Parfois parce que la localisation n’était pas mentionnée, parfois parce qu’elle l’était sous une forme ambiguë, susceptible de correspondre à plusieurs adresses différentes, parfois parce que l’adresse citée n’existait pas dans le référentiel Adresse. Dans cette situation, les informations de localisation indiquées dans les délibérations ou les projets de délibération (souvent plus précis que les délibérations elles-mêmes, car ils contiennent également l’exposé des motifs), publiés par la Ville de Paris sur sa plateforme a06.apps.paris.fr, ont été utilisées.
Si une confirmation était nécessaire, ou en l’absence de délibération, le répertoire du parc locatif social (RPLS) au 1er janvier 2015, l’inventaire SRU au 1er janvier 2016 (UDHL 75), les fichiers fonciers au 1er janvier 2015 (DGALN, d’après DGFiP/MAJIC3) et toute information utile disponible sur internet ont été mobilisés.
Pour ces enregistrements, obs_loc est égal à 4.
D’une manière générale, la localisation de ces enregistrements peut être considérée comme très fiable, car elle n’est pas tributaire de la qualité de la saisie de l’adresse dans la dénomination SISAL et se base sur la consultation, voire la confrontation, de sources précises et qui présentent un bon niveau de fiabilité.
Pour deux enregistrements, toutefois, l’adresse retenue a été choisie de manière (relativement) arbitraire : id 654 (2016 DLH 416 SIEMP 99, rue Decaen PLAI AA) et id 1207 (5ter rue Dosne  Fondation Dosne PLS N). Dans les deux cas, il s’agit d’une adresse de la même voie que celle qui est mentionnée par la dénomination, mais avec un numéro voisin. Ces choix n’ont pas pu être étayés par des informations issues d’autres sources.

Opérations non géolocalisées :
La table L_SISAL_2011_2016_075_ADRESSE compte une opération sans géométrie (id 1543, ‘Résidences le Logement des Fonctionnaires PLS N’), pour laquelle les informations disponibles n’étaient pas suffisantes pour déduire une localisation. obs_loc prend la valeur 8 pour cet enregistrement.


__Organisations partenaires__

DDT Cher

__Liens annexes__

 * [Vue XML des métadonnées](http://ogc.geo-ide.developpement-durable.gouv.fr/csw/all-dataset?REQUEST=GetRecordById&SERVICE=CSW&VERSION=2.0.2&RESULTTYPE=results&elementSetName=full&TYPENAMES=gmd:MD_Metadata&OUTPUTSCHEMA=http://www.isotc211.org/2005/gmd&ID=fr-120066022-jdd-a0d6d800-4f83-43aa-ad0e-7cc1ef63a3cc)

➞ [Consulter cette fiche sur geo.data.gouv.fr](https://geo.data.gouv.fr/fr/datasets/ad5f307ae6d8cab81c639fe8fbcb7fd23c437928)