Joli travail ! On va mettre en commun nos efforts pour éviter une communication brouillonne et des doublons.
BANO étant un projet à la fois technique mais aussi avec une dimension politique assez forte. La prochaine étape pour BANO est surtout s'avancer sur le guichet unique pour améliorer son contenu et là il ne faut pas se louper pour avoir une adoption la plus facile possible par les acteurs de terrain. Le 10 juin 2014 23:23, Frédéric Rodrigo <fred.rodr...@gmail.com> a écrit : > Bonjour, > > Il y a deux semaine j'ai commencé un nouveau projet de constitution d'une > base d'adresse depuis le cadastre, l'OpenData et OSM. Oui l'objectif est > bien de construire une bano, mais c'est pas le même projet que l'"autre" > bano. > > Pourquoi une autre bano ? Par ce que j'en avais envie. Parce que je > voulais expérimenter une autre façon de faire. Parce que je voulais > pourvoir comprendre comment ça marche. > > Le code source et l'explication du processus d'extraction des différentes > sources de données, de rapprochement et de constitution de la banof sont > disponible sur github : > > https://github.com/frodrigo/banof > > """ > Les donnes sont extraites du cadastre vectoriel en ligne avec l'outil > export-cadastre. Elles sont mises en correspondance avec le FANTOIR. > > Les données adresses sont extraites d'OpenStreetMap, puis retraitées et > consolidées pour être toutes sous la même forme. > > L'ensemble de ces sources des données sont ensuite mise en correspondance > suivant différents critères et priorités (FANTOIR, noms de voies, noms > approximatifs...). Il en est ensuite de même pour les numéros de rues. > > Après la mise en correspondance les données sont exportées, cela comprend > de façon unique les données retrouvées dans plusieurs jeux de données, mais > aussi celles sans correspondances. > """ > > Le processus produit deux types d'exports, un brut avec les données > alignées de toutes les sources et une "normal" qui est une "simple" base > adresse. > > Un peut d'information sur le temps de construction et de mise à jour : > > 12 jours : temps d'extraction depuis les fichiers pdf (hors > téléchargement, les fichiers étaient déjà dans le cache de la bano). > > 2 h 42 : temps de chargement en base du cadastre, de mise en > correspondance avec le FNATOIR et de post traitement. > Le code FANTOIR est retrouvé pour 97,6 % des voies du cadastre. > Le cadastre contient 1 076 145 voies et 15 037 464 numéros. > > Pour effectuer la mise à jour toutes les phases suivante doivent être > rejoué (même s'il est imaginable d'en remplacer une partie par > l'utilisation de diff pour l'accélérer) > > 2 h 30 : temps d'extraction des données d'adresses et de voirie d'un > extract OSM de la France avec osmosis, puis chargement en base de données > et conversion dans un modèle avec une table pour les voies et une table > pour les numéros. > OSM contient 47 225 voies avec adresses et 687 184 numéros. > > > 3 h 39 : temps de mise en correspondance des voies et numéro. > 89% des voies d'OSM avec adresses sont retrouvées dans le cadastre, > 80% des voies du cadastre sans adresse dans OSM sont retrouvées > 42 082 + 828 009 voies sont mise en correspondance. > (A noter que mes tests ne comporte que la métropole pour OSM, et tous les > territoires Français pour le cadastre) > > 3 min : temps de l'export. > 1 107 498 voies et 15 144 142 numéros. > > Les premières données complètes sont disponible là : > http://osm110.openstreetmap.fr/~fred/ > > Frédéric. > > _______________________________________________ > dev-fr mailing list > dev-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/dev-fr > -- Christian Quest - OpenStreetMap France
_______________________________________________ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
