{{ ctx.nhits | number }} record

{{ ctx.nhits | number }} record

Active filters

No active filters

Filters

SUDOCUH-2018-EPCI -972 - Etat d'avancement des EPCI en Martinique

Ce jeu de données décrit, par EPCI (établissements publics de coopération intercommunale *) hors syndicats mixtes et PETR (pôle d'équilibre territorial et rural) le type d'EP ainsi que le nom de l'EP. La remontée des compositions communales des EP se faisant a travers l’enquête SuDocUH, outil de suivi en temps réel des procédures de planification en matière d’urbanisme et d’habitat au 31/12/2018. Les données élémentaires de l'année N sont produites par les directions départementales des territoires en janvier N+1 et arrêtées au 31 décembre N (ici 2018). Le jeu de données millésimé est produit habituellement en mars après un processus de vérification notamment de leur complétude, de leur cohérence par rapport au COG de l'année. Des inexactitudes très ponctuelles restent toutefois possibles. * Les établissements publics de coopération intercommunale (EPCI) sont des regroupements de communes ayant pour objet l'élaboration de « projets communs de développement au sein de périmètres de solidarité ». Ils sont soumis à des règles communes, homogènes et comparables à celles de collectivités locales. Les communautés urbaines, communautés d'agglomération, communautés de communes, syndicats d'agglomération nouvelle, syndicats de communes et les syndicats mixtes sont des EPCI. __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. 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 diffuses : Les opérations diffuses (obs_loc = 7) correspondent à cinq enregistrements qui ne pouvaient être localisés ni à une adresse ni à un secteur spécifique, car ils concernaient en fait plusieurs adresses clairement distinctes, sur plusieurs arrondissements différents. Les adresses concernées, ainsi que (généralement) le nombre de logements agréés sur chacune, ont été déterminés grâce aux projets de délibérations. La table annexe L_SISAL_2011_2016_075_ OPDIFFUS, qui propose une ventilation à l’adresse des opérations, a pu être créée sur cette base. Dans une délibération, cependant, le détail de la répartition de 21 logements PLUS en acquisition-conventionnement sur cinq adresses dans les XVe et XVIIe arrondissements n’était pas explicité, et cette information n’a pas pu être obtenue via les sources complémentaires susmentionnées. Il a été arbitrairement admis de répartir uniformément les 11 logements T1 et les 10 logements T3 sur les trois adresses mentionnées pour chacun de ces types (dont une en commun). Ces enregistrements de la table des opérations diffuses ont un obs_n_lls qui vaut 2 et non 1. 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__ DGALN (Direction Générale de l'Aménagement, du Logement et de la Nature) __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-7a00b9e5-38d4-404f-8158-45c8bad2a31f) ➞ [Consulter cette fiche sur geo.data.gouv.fr](https://geo.data.gouv.fr/fr/datasets/6ca6b2a9446273939770a4c6befdf90c259b75d0)

Dataset schema

JSON Schema

The following JSON object is a standardized description of your dataset's schema. More about JSON schema.