Bano osm grenoble_2015-03-05

1 269 vues

Publié le

Adresses, OSM et BANO

Présentation devant le groupe local OpenStreetMap Grenoble

Publié dans : Données & analyses
1 commentaire
1 j’aime
Statistiques
Remarques
Aucun téléchargement
Vues
Nombre de vues
1 269
Sur SlideShare
0
Issues des intégrations
0
Intégrations
7
Actions
Partages
0
Téléchargements
10
Commentaires
1
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Bano osm grenoble_2015-03-05

  1. 1. Adresses, OSM et BANO
  2. 2. Groupe local OpenStreetMap Grenoble 05 Mars 2015 Pierre Knobel
  3. 3. Adresse ● Information textuelle permettant de définir sans ambiguïté un lieu / un bâtiment / une parcelle / le destinataire d'un courrier (boîte aux lettres) ● Le plus souvent : – Nom de rue – Numéro de maison dans la rue – Commune (code postal + nom) ● Parfois uniquement commune + lieu dit + nom d'une famille
  4. 4. Schémas de numérotation ● Séquentiel (gérer les maisons intercalées : Bis, Ter, Quater… ou A, B, C…), le plus souvent pair/impair de part et d'autre de la rue ● Métrique ● Par blocs d'immeubles (Japon) ● Par ordre de construction ● Pas de numéros de maison (villages peu peuplés, communes constituées d'une collection de hameaux comme Revel) ● Anarchique ● All of the above (plusieurs schémas dans une seule commune)
  5. 5. Adresses dans OSM http://wiki.openstreetmap.org/wiki/Addresses
  6. 6. Ce qui fait consensus ● addr:housenumber ● addr:street ● addr:city ● addr:postcode ● … etc
  7. 7. Ce qui divise (1) ● Spécification de toutes les infos sur chaque point adresses vs. relations – Relations : ● Informations non dupliquées, plus facile de corriger le nom de la rue (sur un unique objet) ● Pas complètement supporté dans tous les éditeurs OSM ● Un peu plus difficile à comprendre pour un débutant – Points : ● Facile à saisir pour un débutant ● Schéma géré par tous les éditeurs OSM grand public (ID, Potlatch 2) ● Infos redondantes, erreurs dans noms de rues à corriger sur de multiples points ● Relation Street vs. AssociatedStreet
  8. 8. Ce qui divise (2) ● Position du point adresse : – Polygone ou centre d'un bâtiment – Entrée(s) du bâtiment – Position de la plaque adresse – Centre d'une parcelle – Entrée(s) d'une parcelle (routage GPS) – Boîte aux lettres (facteur) ● Peut-être qu'il faudra plusieurs points par adresse, ou une surface contenant tous les éléments
  9. 9. Adresses OSM en France ● Import semi-automatique du cadastre, en très grande majorité – Plugin JOSM cadastre-fr permet de mettre le cadastre vectoriel en fond de plan et de saisir les adresses en quelques clics : création automatique d'une relation AssociatedStreet en cliquant sur une rue, puis ajout de points addr:housenumber incrément automatique du numéro à chaque clic – Plus récent, http://cadastre.openstreetmap.fr/ permet de générer des fichiers .osm d'adresses à importer et fusionner avec les données du serveur OSM dans JOSM. Permet de choisir la position de l'adresse (sur façade de bâtiment ou non) et le schéma (AssociatedStreet ou non). ● De plus en plus d'OpenData (grandes villes) ● Chacun fait comme il préfère, pas de consensus
  10. 10. Pourquoi BANO ● Il faut une base de données adresses libre et ouverte. – Bénéfices direct : ● Économies sur les frais de maintenance de bases publiques ou privées en silo (DGFiP, IGN, SDIS, communes, 3 x La Poste, ...etc) ● Implication des citoyens et communes pour corriger et maintenir la base ● Une base commune de meilleure qualité – Bénéfices indirects : ● Impôts sur les bénéfices des entreprises qui exploitent la base ● Emploi ● Services innovants ● Plutôt que se précipiter dans l'import en masse du cadastre et des données ouvertes avant d'avoir défini ce qu'est une adresse, on peut d'abord faire une base externe composite ● Sources : – OSM (idéalement relevé sur le terrain) – OpenData (communes) – Cadastre (DGFiP)
  11. 11. BANO aujourd'hui ● http://munin.openstreetmap.fr/bano-month.html
  12. 12. BANO aujourd'hui
  13. 13. Problème des doublons ● Multiples sources → doublons ● Lorsque les infos correspondent, les doublons sont éliminés automatiquement – Priorité données OSM, puis OpenData, puis cadastre ● Mais parfois, ça ne peut être fait automatiquement : orthographe des noms de rues différentes entre les sources
  14. 14. Résolution manuelle des doublons ● Nom de rue mal orthographié ou absent dans OSM → corriger OSM ● Nom de rue mal orthographié dans le cadastre → rajouter clé unique de la voie ref:FR:FANTOIR dans OSM pour faire le lien
  15. 15. Rendu BANO – visualiser les problèmes
  16. 16. Zones à compléter dans OSM ● Les grandes régions en rouge sur le rendu BANO sont des zones avec un cadastre vectoriel mais pas toutes les rues ou noms de rues dans OSM. Souvent les petites rues, les chemins, les travers et les impasses manquent. ● Exemples autour de Grenoble : – Saint-Martin-d'Uriage – Vinay – Terres froides / Nord-Isère – ...Etc
  17. 17. FANTOIR ● Le FANTOIR, ou Fichier ANnuaire TOpographique Initialisé Réduit, anciennement fichier RIVOLI (Répertoire Informatisé des VOies et LIeux-dits), est un fichier français listant, par commune, les voies, les lieux-dits et les ensembles immobiliers. ● Fichier et descriptif : https://www.data.gouv.fr/fr/datasets/fichier-fantoir-des-voies-et-lieux-dits/
  18. 18. Problèmes de FANTOIR ● Contient de nombreuses erreurs : http://wiki.openstreetmap.org/wiki/Contribuer_%C3%A0_la_BANO#Typologie_des_anomalies_FANTOIR – À signaler dans : ● Fautes de frappe dans OSM en tapant le code dans la clé ref:FR:FANTOIR : http://cadastre.openstreetmap.fr/fantoir/fantoir_errone.html ● Mise à jour lente, code FANTOIR indisponible un certain temps après la création d'une nouvelle rue http://cadastre.openstreetmap.fr/fantoir/#insee=38185
  19. 19. BANO .csv Pour chaque adresse: ● id (unique) : code_insee + codefantoir + numero ● numero : numéro dans la voie avec suffixe (ex: 1, 1BIS, 1D) ● voie : nom de voie ● code_post : code postal sur 5 caractères ● nom_comm : nom de la commune ● source : OSM = donnée directement issue d'OpenStreetMap, OD = donnée provenant de source opendata locale, O+O = donnée de source opendata enrichie par OpenStreetMap, CAD = donnée directement issue du cadastre, C+O = donnée du cadastre enrichie par OSM (nom de voie par exemple) ● lat : latitude en degrés décimaux WGS84 ● lon : longitude en degrés décimaux WGS84 http://bano.openstreetmap.fr/data/
  20. 20. BANO .csv
  21. 21. Future BAN ● Projet encore un peu flou, déclaration d'intention récente (un pas de géant malgré tout) ● Collaboration OSM, IGN, La Poste, DGFiP avec participation possible des communes, SDIS, gendarmeries ● Base en double licence : – Licence libre pour utilisation avec repartage – Licence fermée pour utilisateurs payants, sécurité juridique promise par l'IGN et La Poste ● Les données BAN pourront être réutilisées dans OSM, mais pas l'inverse (Odbl incompatible avec la licence fermée)
  22. 22. Outils divers ● Comparer géocodages OSM vs. BANO vs. Google – http://www.ideeslibres.org/GeoCheck/ – http://www.ideeslibres.org/Bano/comp/geocodeComp/ ● Rendu BANO : – Pour JOSM : tms[20]:http://{switch:a,b,c}.layers.openstreetmap.fr/bano/{zoom}/{x}/{y}.png – Navigateur : http://tile.openstreetmap.fr/~cquest/leaflet/bano.html ● http://adresse.data.gouv.fr/ Futur site officiel de BAN – http://adresse.data.gouv.fr/tools ● Canal #bano sur irc.oftc.net ● https://github.com/osm-fr/bano/issues/new

×