Blog de cquest

BANO ? BANCO !

cquest — Mon, 19 May 2014 10:11:43 +0000

Qu'est-ce que BANO ?

Il s'agit donc de constituer une base d'adresses composite à partir des meilleures sources disponibles (et libres).

L'objectif est de proposer une couverture la plus étendue possible, la plus homogène possible.

Bien sûr à son démarrage BANO ne sera pas exhaustive, ni parfaite (quelles données sont parfaites ?) et fonctionnera dans l'esprit "release early, release often" cher au monde de l'open-source.

Il s'agit donc d'un projet ouvert et collaboratif ou toutes les bonnes volontés sont les bienvenues pour apporter des données, des outils, du code, des ressources matérielles, de la matière grise !

Comment est-elle constituée ? A partir de quelles sources ?

Tout d'abord ce sont les données OpenStreetMap collectées sur le terrain par des centaines, des milliers de contributeurs qui sont utilisées. Ce choix peut paraitre étonnant, mais c'est potentiellement la source la plus à jour et la plus réactive aux changements comme nous allons le voir un peu plus loin. Elle est donc prioritaire sauf exception et son volume est d'environ 2 millions d'adresses à mai 2014.

Ensuite vient une deuxième source, trop rare (petit appel du pied), mais souvent de qualité: ce sont les données en opendata. Leur volume estimé est d'environ 1 million d'adresses (mai 2014).

A ces données déjà disponibles en opendata, nous ajouterons les données versées dans BANO par les organismes producteurs de données voulant les partager mais qui ne les ont pas encore mises en opendata. C'est par exemple le cas de nombreux SDIS (petit appel du pied au passage).

Pour compléter, ce sont les adresses collectées à partir du cadastre vectoriel qui seront utilisées. Celui-ci couvre 80% des communes et 87% de la population.

Quels rapprochements entre les sources ?

Le rapprochement des différentes sources est fait régulièrement afin de produire la base composite.

Il est trop tôt pour dire à quelle fréquence elle sera produite, potentiellement quotidiennement si les ressources matérielles le permettent (2ème petit appel du pied).

Un contrôle de qualité pourra être fait pendant cette phase de rapprochement pour identifier les adresses avec une trop grande différence ou un manque de rapprochement. Ceci n'est pas encore le cas dans les premiers fichiers produits.

Quels enrichissements ?

Ce rapprochement permet par exemple sur les sources opendata ou cadastre d'étendre les adresse dans leur forme complète, accentuée, sans abbréviations et comprenant majuscules et minuscules. Ceci correspond aux préconisations du CNIG dans son rapport final sur l'adresse.

C'est la règle utilisée en France dans OpenStreetMap, mais malheureusement non généralisée en opendata. Le cadastre quant à lui est à l'opposé (toponymes abbrégés, en majuscule non accentués).

"AV DU MAL LECLERC" deviendra donc dans la mesure du possible "Avenue du Maréchal Leclerc"... finit le style MINITEL 80s. Pour cela il suffit de correctement nommer la voirie dans OSM, les scripts de rapprochement de BANO faisant le reste entre les sources d'adresses, le fichier FANTOIR de la DGFiP (en opendata) et OSM.

Comment améliorer et corriger les adresses de BANO ?

Les données géographiques sont en perpétuelles changement car le terrain qu'elles tentent de décrire aussi exactement possible est en perpétuel changement. Telle nouvelle rue est percée, rallongée, change de nom.

Le CNIG estimait (en 2002) à 200.000 le nombre de nouvelles adresses créées annuellement. Il reste encore de nombreuses communes rurales où l'adressage intégral n'est pas réalisé mais progresse.

Initialement, pour corriger et améliorer ces données, il suffira donc de le faire dans OpenStreetMap, qui sera pris en priorité sur les autres sources. Les outils sont déjà disponibles et ils s'appuient sur une infrastructure existante, stable, maintenue. C'est donc une plateforme immédiatement disponible pour les acteurs qui veulent collaborer (services de l'État, collectivités, entreprises, etc ). Toute amélioration profitera donc et à la BANO et à OSM, d'une pierre deux coups.

Dans un deuxième temps, un outil plus centré sur l'adresse devrait pouvoir être aussi mis en place pour simplifier ce processus de signalement, correction et amélioration sans passer par les outils d'édition classiques d'OpenStreetMap (eéditeur en ligne iD et éditeur lourd JOSM).

Quelle licence pour les données BANO ?

La BANO s'appuyant en partie sur des données sous licence ODbL (par exemple OSM et certains jeux en opendata), elle sera naturellement publiée sous licence ODbL.

Cette licence impliquera donc de citer la source et de partager toute amélioration ou enrichissement de celle-ci. Cette clause de partage à l'identique garantit que les données de BANO et leurs améliorations seront toujours d'accès libre.

Ceci ne devrait poser aucun problème aux services publics, qui n'ont aucun intérêt à ne pas partager les améliorations, bien au contraire, ça leur évitera de faire le travail en double, triple, voire plus !

La licence ODbL n'empêche pas les usages commerciaux, BANO est donc aussi ouverte pour le monde de l'entreprise, dans le respect de l'attribution et du partage à l'identique bien sûr.

Quelles échéances ?

Dans mon précédent billet un des chapitre s'intitulait "A comme Action".

BANO a démarré il y a déjà quelques mois pour la partie codage des scripts de collecte, de rapprochement, de cumul et d'export. Le premières collectes ont démarré pendant le pont du 8 mai dernier.

BANO a accumulé à ce jour (19 mai 2014) plus de 12,5 millions d'adresses à partir des 3 sources initiales (OSM + opendata + cadastre).

A la fin de la collecte initiale (prévue d'ici une à deux semaines), la BANO devrait cumuler environ 25 millions d'adresses à partir des différentes sources, la moitié du chemin a donc été parcouru en une dizaine de jours.

Le statut (en temps réel) du contenu de BANO est disponible sur: http://openstreetmap.fr/outils/bano/status

Un rendu cartographique permet de visualiser la couverture de BANO: http://tile.openstreetmap.fr/~cquest/leaflet/bano.html

Voir sur une carte plus grande

Des données déjà disponibles

Les premiers fichiers expérimentaux sont déjà disponibles pour une soixantaine de départements sur: http://bano.openstreetmap.fr/data/

Votre retour concernant ces premiers fichiers est attendu et souhaité en gardant bien à l'esprit qu'il s'agit d'un premier export expérimental dans une logique "release early, release often".

Vous pouvez faire vos remontées via:

github sur https://github.com/osm-fr/bano/issues
email: bano@openstreetmap.fr

BANO et l'intégration d'adresses dans OpenStreetMap
Un point important pour les contributeurs OpenStreetMap: BANO n'est pas destinée à être une source pour OpenStreetMap, car BANO s'appuie sur les données OSM pour créer une base composite à partir de différentes sources.
Ce sont les sources d'origine qu'il faut utiliser pour intégrer des données adresse dans OSM, c'est à dire http://addr.openstreetmap.fr pour les sources en opendata et http://cadastre.openstreetmap.fr pour les extractions à partir du cadastre.

On résume...

BANO est un projet ouvert, libre, collaboratif pour consistuer une Base d'Adresses Nationale Ouverte la plus complète et à jour possible.
BANO est une réalité, les premiers fichiers (expérimentaux) sont déjà disponibles pour une soixantaine de départements.
BANO a besoin pour avancer (appels du pied):

de données complémentaires (SDIS, collectivités locales, autres acteurs de terrain)
d'améliorations des données déjà collectées
de ressources matérielles, humaines
de vos remontées sur le projet, sur les premiers fichiers expérimentaux

Tags:

BANO

adresses

Base Adresse Nationale: à côté de la plaque ?

cquest — Mon, 12 May 2014 11:00:23 +0000

Moins d'un an après la rédaction de ce billet de blog,
la BAN est là et sous licence libre !

A comme Adresse ou A comme Arlésienne ?

Dans un billet récent, je pestais contre le Groupe La Poste et sa posture opendata-esque qui relevait de l'imposture.

Cette vieille maison, toujours incapable de diffuser librement en 2014 ne serait-ce qu'un fichier de référence des codes postaux créé en 1972.

Cette maison est aussi associée à une autre vénérable maison pour constituer la Base Adresse Nationale sur un modèle décrit, documenté, initié par le CNIG il y a plus de 12 ans. Vu le retard pris, ce projet de "BAN" a été relancé par l'Afigéo il y a 2 ans, sans grand succès malheureusement.

Bref, depuis si longtemps on parle de constituer une Base de donnée des Adresses, une base de données collaborative où tout les acteurs impliqués (et ils sont nombreux) pourront participer à la mise à jour, la correction et l'enrichissement de ces données... mais on a surtout fait des réunions et des rapports (pour constater le retard et voir "comment on fait") ou des annonces (pour faire patienter ?).

Pour l'instant, les deux protagonistes nationaux (Poste et IGN) n'ont su se mettre d'accord que pour se partager le gâteau. Car, si ces données existent, ça n'est pas pour être librement partagées et utilisées, mais au contraire pour être vendues alors qu'elles sont essentielles à de nombreux pans de l'activité économique mais aussi parfois (et même souvent) vitales.

Les services d'urgence ont par exemple besoin de localiser précisément et rapidement les personnes qui appellent les secours. Aussi, depuis des années, ceux-ci se sont recréé leurs propres données adresse, et les mettent à jour eux-mêmes car il n'est pas question d'attendre un an ou deux pour avoir des mises à jour, car oui, les adresses ça vit et ça meurt, comme les gens.

Ce travail supplémentaire mobilise dans de nombreux SDIS plusieurs pompiers qui régulièrement font ce travail de relevé et de mise à jour... en lieu et place des services dont c'est en principe le métier (l'IGN). Du coup, les pompiers "partagent" ce travail, mais uniquement avec l'IGN (englué par les Conditions d'Utilisation)... qui ne repartage pas sauf exception.

Mais les SAMU en ont besoin aussi, n'importe quelle ambulance peut en avoir besoin tout comme les services du gaz ou de l'électricité aussi, mais aujourd'hui, au XXIe siècle, troisième millénaire, tout le monde ou presque fonctionne "en silo". Chacun refait à peu près la même chose que son voisin, sans son voisin plutôt que de tous faire ensemble.

Ubuesque ! Pire même... au sein de la même entreprise, par exemple... le Groupe La Poste. On y trouve au moins 3 bases adresses, constituées par des "silos" différents (le courrier, les colis, la pub), mises à jour en parallèle avec tous les coûts annexes que cela induit.

La Poste vend sa base d'adresses, j'imagine que ça doit lui rapporter un peu, mais a-t-elle déjà fait le compte de ce que lui coûte le fait que l'on n'a pas accès à un vrai service (sans passer par une macro Word 2007 !) pour vérifier des adresses librement, automatiquement et surtout en masse avant l'envoi de courriers et colis ?

300 millions de lettre et colis reviennent chaque année à leur expéditeur (dixit le rapport du CNIG)... pour un coût souvent double au retour qu'à l'aller. Au tarif lettre le moins cher ça nous fait 300 millions d'euros par an. J'espère que la vente des adresses rapporte au moins ça sinon merci de relire la phrase précédente et d'en tirer vous-mêmes les conclusions évidentes.

Pendant ce temps (rappelez-vous: 12 ans)... au Danemark... une base d'adresses nationale a été constituée, son processus de création sur 7 ans a coûté 20 fois moins que les économies directes engendrées sur la même période, c'est-à-dire 63 millions d'euros. L'économie nette annuelle est depuis de l'ordre de 10 millions d'euros. En extrapolant sur la France vous pouvez multiplier ces chiffres par 5 10 (10 fois plus d'adresses en France). Cette base est libre et gratuite. Elle est maintenue à jour collaborativement et de plus en plus riche en informations "métier".

De l'autre côté de l'Atlantique, les États-Unis ont pris comme engagement que l'ensemble des données adresses disponibles serait librement accessible d'ici un an (mi 2015). Un catalogue collaboratif a même été constitué pour identifier l'ensemble de ces données.

En Espagne toutes les données du cadastre (donc les adresses) sont en opendata depuis plusieurs années.

A... comme Action !

Le collaboratif et la donnée géographique... c'est tout le cœur d'un projet comme OpenStreetMap et voici un peu plus d'un an, suite à une discussion avec l'Afigéo, nous avons compris l'aspect prioritaire et essentiel de cette donnée, mais aussi que les choses n'avançaient pas sur ce sujet et qu'il n'y avait aucune raison que cela change après 12 ans d'avancées plus que timides. Une sorte de défi à relever pour aller un peu plus loin que nos cartes !

Pour un projet comme OSM, les adresses sont un élément indispensable si l'on veut par exemple calculer un itinéraire... car il faut bien trouver les points de départ et d'arrivée. Le géocodage (passage d'une adresse à une position géographique, voire l'inverse) est en effet le lien de nombreuses données non géographiques vers le monde réel, bien géographique.

Depuis, nous avons frappé aux portes pour collecter cette donnée essentielle. Quelques portes se sont ouvertes, des données ont été mises en opendata par différentes grandes agglomérations (au total moins de 1 million d'adresses), mais trop rares pour être suffisantes. Une demi-douzaine de départements ont mis à disposition les plans cadastraux informatiques dont ils avaient financé la vectorisation. Grand merci à eux, mais malheureusement insuffisant là aussi pour penser à l'échelle nationale.

Nous avons donc creusé le sujet de notre côté, à notre façon, en nous appuyant sur une source autorisée depuis 2009 pour le projet OpenStreetMap à savoir: le cadastre. Cet accès autorisé au cadastre nous a permis par exemple après 5 ans de travail de fourmis de reconstituer avec précision les limites administratives des 36681 communes* (métropole et DOM), faisant d'OSM la seule source libre à ce niveau de détail... et à jour !

Quelques semaines ont donc été passées par une petite équipe bénévole à transformer notre outil qui jusque-là n'extrayait que les formes des bâtiments, pour lui faire extraire ce qui nous intéressait c'est-à-dire les adresses.

B... comme BANO

Ce projet, nous l'avons nommé BANO, pour Base d'Adresses Nationale Ouverte.

La première pierre a été symboliquement posée durant la conférence annuelle d'OpenStreetMap France, début avril à Paris. Ce sujet a occupé une partie importante de notre journée destinée en priorité aux collectivités et entreprises (voir les vidéos en ligne), puis un atelier de travail s'est organisé lors de cette même conférence. L'intérêt et les retours très positifs nous ont poussé à mettre les bouchées doubles.

Qu'est-ce que BANO ? Comment est-elle constituée ? A partir de quelles sources ? Comment collaborer ?

Ceci fera l'objet d'un second billet...

* oui, depuis mon billet sur le nombre de communes, la fusion de Bihorel et Bois-Guillaume a été annulée au 1er Janvier 2014... le GEOFLA 2014 sera peut être disponible en novembre si il suit la tendance des années passées.

Tags:

BANO

adresses

opendata: La Poste, posture ou imposture ?

cquest — Sun, 09 Feb 2014 09:56:04 +0000

Depuis la publication de ce billet, La Poste a finalement diffusé en opendata le fichier officiel des codes postaux sur data.gouv.fr le 14 novembre 2014 et a signé le même jour un accord avec l'IGN, OSM France ainsi que le SGMAP/Etalab pour la constitution de la Base d'Adresses Nationale qui sera disponible sous licence libre.

Samedi dernier s'est tenu le troisième acte de "la démarche DataPoste" où "Le Groupe La Poste se positionne comme un acteur incontournable de l’Open Data."

Ce n'est pas moi qui le dis, mais le groupe La Poste sur son site: http://legroupe.laposte.fr/en/Innovation/L-Open-Data-accelerateur-d-innovation-pour-Le-Groupe-La-Poste

« L’Open Data c’est avant tout un état d’esprit, une posture et des valeurs. Pour Le Groupe La Poste, incarner ces valeurs, c’est faire preuve d’ouverture et d’un esprit innovant. L’Open Data peut également être une opportunité pour créer de nouveaux services accessibles par Internet ou via une application mais c’est aussi la possibilité d’améliorer nos bases via le crowdsourcing, comme par exemple la base des boîtes aux lettres dont la qualité pourrait être encore supérieure si le public apportait des corrections aux erreurs qu’il constate. »

Un état d'esprit, une posture et des valeurs...

L'état d'esprit de l'opendata est le libre partage de données à mi-chemin entre une demande de transparence et un gisement d'innovations. Des données donc, en volume, en qualité et avec une licence libre qui permet de les utiliser le plus librement possible sans présager des usages qui en seront faits. Oui, l'ouverture est une valeur centrale, qu'on retrouve dans la racine "open".

Le terme de "posture" m'a un peu surpris, ce n'est pas un mot qu'on entend souvent accolé aux concepts d'opendata. Il est bien adapté si on le prend dans le sens de comportement et conduite mais beaucoup moins dans le sens d'une attitude ou d'une pose qu'on prendrait de façon un peu artificielle.

Je constate que le "crowdfixing" est aussi au programme avec un exemple fort à propos.

opendata = open + data

Désolé de devoir rappeler les évidences, mais le terme opendata s'appuie sur deux mots centraux. On parle bien d'ouverture, de liberté (open), et de données (data).

Quelles sont dans le cas présent les données ouvertes par La Poste à ce jour ?

Par données ouvertes, je parle bien sûr de données disponibles sous licence libre et sur data.gouv.fr, seuls 2 jeux de données sont disponibles depuis avril 2012 (bientôt 2 ans) :

la liste des "points de contact" et leurs horaires d'ouverture
la liste des espaces de retraits So Colissimo

Hum... comment dire... c'est maigre pour un "acteur incontournable de l'opendata", non ?

Personne n'a encore pensé aux codes postaux ? C'est une donnée de base actuellement non accessible en opendata (sauf data-bricolages pas très légaux: http://georezo.net/forum/viewtopic.php?id=90124).

Je n'ose même pas aborder le sujet des adresses... serpent de mer avec le projet de Base d'Adresse Nationale qui n'avance pas depuis plus de 12 ans (cf: https://drive.google.com/file/d/0B0urI9Y66dXNc014X1d6RE03azJNaEM0eEUwWW1MTGRCRjFJ/edit?usp=sharing)

dataposte... une lueur d'espoir ?

Voyant le Groupe La Poste enfin s'intéresser à l'opendata avec sa démarche "dataposte", on peut s'attendre à un petit peu plus de data et surtout des données utiles au plus grand nombre. La remise des prix du 4e concours dataconnexions organisé par la mission Etalab avait même eu lieu au siège du Groupe La Poste.

Le discours est enthousiasmant: "Avec DataPoste, [le Groupe La Poste] s’engage dans une démarche d’ouverture et d’exploitation des données postales à grande échelle."

Engagement, ouverture, grande échelle... on va voir ce qu'on va voir et tout le monde retient son souffle jusqu'au 8 février, date du concours "datajam", où de nouvelles données seront mises à disposition.

open ? pas vraiment

Donc rendez-vous au datajam... et là quelques données supplémentaires sont mises à disposition des participants ne sont pas si croustillantes. Ah oui, petit détail d'importance: ces données ne sont utilisables que dans le cadre de ce concours, pas en dehors, donc pas après.

Après 2 tweets sans réponse, je lis le règlement du concours (11 pages, rien que ça autant dire que comme sûrement tout le monde je ne l'avais pas lu) et, oui, c'est marqué noir sur blanc:

"Toutes autres données de La Poste, portées à la connaissance et mises à disposition des Participants pendant la durée du Datajam sont la propriété exclusive de La Poste et/ou de ses filiales. Ces données ne pourront être utilisées que dans le strict respect du Règlement, uniquement pendant la durée du Datajam, et afin de réaliser l’objectif du Datajam. Aucune utilisation ni exploitation, commerciale ou non, de ces données ne pourra être faite après le Datajam sans l’accord préalable de La Poste, ce que le Participant reconnaît expressément. Si nécessaire, une licence d’utilisation des données devra être signée par les Participants au jour du Datajam. Dans ce cas, la participation au Datajam ne sera effective que si le Participant accepte les termes de la licence."

Grosse déception: en gros, nous allons passer une journée à coder un prototype qui ne pourra pas voler de ses propres ailes librement si nous le souhaitons.

Remarquez, on a vu pire comme concours, là au moins notre travail nous appartient à peu près, pas comme dans un hackathon récent où tous les droits étaient cédés à l'organisateur du concours... une forme de travail gratuit.

On s'éloigne un peu de l'état d'esprit, non ? La posture ressemble à une pose...

Quand la com prend le dessus...

Pour une fois, je n'étais pas mentor et j'ai participé à ce concours histoire d'avoir une autre point de vue sur ces évènements auxquels j'ai souvent pris part. C'était donc ma première participation de ce type à ce que je croyais être un hackathon, c'est-à-dire un sprint où en un temps très court on teste une idée en créant un prototype qui s'appuie sur des jeux de données ciblés.

Notre petite équipe avait pris le parti de répondre à 2 des 5 défis:

défi #1 : points de contact postaux et territoires
défi #5: collecte de nouvelles données et croisements

Il s'agissait de mettre en valeur un jeu en opendata (celui des bureaux de poste) et un jeu qu'on qualifiera de "beta", c'est-à-dire celui des boites aux lettres.

Le croisement avec d'autres données a été fait sur les emplacements de parking réservés aux personnes handicapées (source Préfecture de Police et OpenStreetMap), et la collecte de nouvelles données devait servir à améliorer le jeu de données des boites aux lettres reconnu comme n'étant pas au top et à compléter la liste des parkings réservés.

Le datajam durait une seule journée, c'est très court. Habituellement les hackathon s'étalent un peu plus, sur 48h minimum ce qui permet grâce à une ou deux nuits blanches supplémentaires de produire quelque chose de fonctionnel et de ne pas rester dans le conceptuel.

Or, la communication a rapidement pris le pas sur le reste. Il nous faut produire une vidéo ! Ah bon ? Il nous faut un scénario de présentation, et pourquoi pas une marque, un logo, des goodies à distribuer ?

Doit-on vraiment présenter un prototype qui s'appuie sur des données ouvertes ou plutôt une vidéo ou de magnifiques slides d'un concept ou d'une idée ?

And the winner is...

Que penser des 3 lauréats ?

Pour certains, aucun jeu de données n'a été utilisé. C'est pourtant la base du concours, c'est même une obligation faite par le règlement un petit peu oublié.

Les données semblent passer complètement au second plan dans tout ce ramdam. Au final, aucunes nouvelles données n'ont été mises en opendata, rien de nouveau donc depuis avril 2012 ce n'est donc peut être pas pour rien qu'elles passent en arrière plan dans ce palmarès.

Le winner c'est surtout la communication du Groupe La Poste et ce n'est pas le monde de l'opendata, qui attend toujours des données structurelles essentielles tels les codes postaux ou les adresses (j'en ai déjà parlé ?) pour n'en citer que deux qui à défaut d'être librement disponibles nous sont sans arrêt demandés dans OpenStreetMap.

Post-pitch

Pour devenir "un acteur incontournable de l’Open Data", il faut ouvrir ses données et le faire sans arrière pensée.

C'est un acte qui ne doit pas se faire avec une attente de retour directe, en visant tel usage ou tel autre pour favoriser telle ou telle innovation car c'est le meilleur moyen de brider l'ouverture et les innovations.

Un acteur incontournable de l'opendata aurait déjà depuis longtemps mis à disposition des essentielles pour de très nombreux acteurs.

Sur les codes postaux, peut-on me dire pourquoi ces données ne sont toujours pas publiques et libres ?

Pour les adresses, en ne partageant pas ces informations, La Poste n'aide pas à la création d'une référence publique. Ceci lui coûte chaque année énormément d'argent... une part sûrement non négligeable des "NPAI".

Cela fait aussi que ses boites aux lettres de rues sont relativement mal positionnées dans les fichiers entre aperçus samedi, tout comme les bureaux de postes publiés en 2012 étaient pour certains très mal positionnés à partir d'un géocodage très approximatif.

Il y a tellement à gagner et si peu à perdre... et pas qu'en image !

Le Groupe La Poste se positionne comme un acteur incontournable de l’Open Data ? Chiche, c'est quand vous voulez !

FANTOIR et culture générale...

cquest — Mon, 13 Jan 2014 11:09:40 +0000

En testant un nouveau script-outil faisant le croisement entre les données OSM et le fichier FANTOIR de la DGFiP, j'ai exploré les rues du 1er arrondissement de Paris à la recherche de rues manquantes.

La rue Richepance n'existe pas dans OSM, je suis donc parti à la recherche de celle-ci...

C'est Le Parisien et Libération qui m'ont donné l'explication. Cette rue parisienne a changé de nom fin 2001.

En effet, Richepance est le nom d'un général, Antoine Richepanse (ou Richepance) qui s'est malheureusement illustré par 10000 morts pendant la répression en Guadeloupe en 1802. Un fait peu glorieux qui lui a fait perdre sa rue 199 ans plus tard.

Cette rue parisienne porte désormais le nom de Chevalier-de-Saint-Georges, nom du fils d'une esclave.

D'après wikipédia, le « quai Richepanse » de Metz qui lui rendait hommage a quant à lui été renommé « quai Paul Wiltzer »

Sources:

Tags:

FANTOIR

DGFiP

outils

Limites administratives simplifiées

cquest — Wed, 18 Dec 2013 11:22:55 +0000

Depuis que l'ensemble des limites administratives des communes françaises ont été tracées dans OpenStreetMap, un besoin d'une version simplifiée de ces limites s'est fait sentir.

En effet, le tracé fait par les contributeurs OpenStreetMap approche la précision du cadastre or pour de nombreux usages, ces tracés s'avèrent trop lourds à manipuler.

Il n'y a pas moins de 9 millions et demi de points dans ces 36680 polygones, ce qui représente un jeu de données de plus de 250Mo de data bien difficile à manipuler pour des besoins cartographiques à petite ou moyenne échelle.

Mais comment simplifier plus de 36000 polygones tout en gardant une cohérente topologique entre eux ?

postGIS possède bien une commande ST_SimplifyPreserveTopology, mais c'est la topologie de chaque polygone qui est conservée sans cohérence entre 2 polygones ayant une frontière commune.

Du coup cela donne un résultat de ce type:

Ou voit que les polygones ne sont pas jointifs, ce qui bien sûr n'est pas le but recherché, l'objectif étant celui-ci:

Il existe des outils en ligne comme mapshaper, mais je doute qu'il puisse traiter autant de données d'un coup (j'avoue ne pas avoir testé).

Je voulais aussi produire un autre jeu de données, celui non pas des polygones des communes, mais des linéaires des frontières, afin à terme de les dessiner plus proprement dans le rendu "FR" car actuellement ces limites sont tracées polygone par polygone et donc tracées 2 fois dans la majorité des cas, ce qui empêche d'avoir un pointillé cohérent, voire d'autres tracés plus utiles qu'un simple pointillé.

L'objectif aussi est de faire tout ça avec postGIS... pour pouvoir l'intégrer à la base osm2pgsql utilisée par le rendu FR.

Donc l'idée est de :

recréer les linéaires des frontières
simplifier ces linéaires en vérifiant qu'il n'y a pas d'intersection dûe à la simplification
moins simplifier ceux qui se croisent
recréer les polygones

Après avoir démarré initialement en pur postgis, j'ai voulu utiliser les extensions topologiques de postgis qui permettent de gérer ce genre de choses, mais les temps de traitement semblent bien trop long et inadaptés à un tel volume de géométries à simplifier. Retour donc à du pur postgis...

Je vous passe (pour l'instant) les détails, mais ça y est, le résultat est atteint après un long week-end passé sur le sujet à fouiller la doc de postGIS, celle de postgres et aussi à corriger des limites de communes qui n'étaient pas correctes (chevauchements sur des intersections, îles mises dans 2 communes différentes, etc).

Le résultat ce sont 3 fichiers shapefile contenant les polygones simplifiés des communes françaises avec 3 niveaux de simplification différents (10, 100 et 250) qui correspondent grosso-modo à une simplification à 5m, 50m et 100m (voir ici).

Du coup, on passe d'un shapefile de 250Mo à 85, 22 et 12Mo.

Sur la todo list:

extraction des limites linéaires
utilisation de ces limites linéaires dans le rendu FR
scripter le processus pour produire ces fichiers remis à jour quotidiennement
le généraliser pour d'autres découpages...

Ces fichiers simplifiés sont référencés sur data.gouv.fr: http://www.data.gouv.fr/fr/dataset/decoupage-administratif-communal-fran...

Tags:

postgis

Première rencontre technique avec l'IGN

cquest — Sat, 07 Dec 2013 09:44:18 +0000

Ce matin Gaël, Vincent, Marc et moi étions à l'IGN pour une première rencontre technique.

C'est suite à la rencontre avec la direction de l'IGN de ces dernières semaines que nous avons lancé cette série de réunions technique pour mieux nous connaitre, mieux connaître nos façons de faire, nos outils, nos problèmes respectifs.

Donc ce coup-ci c'était l'IGN qui nous montrait quelques outils et nous recevait dans ses locaux.

Nous avons commencé par un outil d'appariement qui permet de retrouver les objets similaires dans deux bases. Cet appariement se fait sur le plan géométrique et a été développé à l'origine pour compléter les données sémantiques d'une base riche géométriquement mais pauvre sémantiquement avec les données sémantique de l'autre base plus riche mais plus pauvre sur le plan géométrique (ça va vous suivez ?).

Pour nous ça donnerai par exemple :

- la BD Carthage : avec des noms, des ref:sandre potentiels, de la navigabilité mais une géométrie moins détaillées que...

- les données OSM avec des cours d'eau tracés mais sans tout cette sémantique (nos tags) qu'on pourrait ajouter

Pour cela un sur-découpage du filaire est fait pour faire correspondre des éléments qui ne sont pas tronçonnés de la même façon car autant apparier du ponctuel est relativement simple autant pour du filaire ou du surfacique ça se complique très vite !

L'exemple montré était assez intéressant, une zone sur Haïti avec des données OSM et d'autres données et comment réconcilier tout ce petit monde.

Ca tourne dans GéoConcept, donc même si l'IGN peut éventuellement mettre ça en opensource, c'est dépendant d'un logiciel propriétaire.

Les principes sont proches d'une thèse que j'avais lu sur le sujet: http://recherche.ign.fr/labos/cogit/pdf/THESES/DEVOGELE/These_Devogele_1997.pdf

L'appariement peut aussi être fait sur des éléments surfaciques et a été utilisé pour intégrer le bâti du cadastre dans la BDUni (la base "mère" de l'IGN).

Le plus difficile à apparier, ce sont des données avec des géométries prévues pour des échelles très différentes ou lorsque la topologie est différente car l'outil semble aussi s'appuyer sur un graphe pour les données filaires.

Deuxième outil dont on a juste parlé, c'est un générateur de "diff". On lui donne 2 bases et il sort ce qui est en plus ou différent, ce qui a disparu, mais aussi les fusions/tronçonnages ou les fausses modifs (suppression/ajout du même élément). Ca se base sur des ID d'objet et aussi une comparaison géométrique mais très serrée (par comme pour l'appariement). Outil intéressant qui devrait être mis en opensource (CECIL-C) sans trop de difficulté. C'est écrit en C et tourne sous Windows, Linux et OSX.

Troisième outil, c'est le futur outil de remontée d'erreurs basé sur une interface web qui permet d'accèder directement aux données de la BDUni (de la veille) un peu comme avec iD. L'avantage c'est qu'on modifie directement les attributs des objets et qu'on accède aux objets présents en base mais aussi on peut rendre visible ceux supprimés ainsi que les colorer selon leur date de dernière mise à jour.

Prochaine réunion technique en janvier, ce coup là c'est l'IGN qui viendra nous voir à La Fonderie, sûrement avec quelques "collecteurs" qui tournent sur le terrain. On a en effet parlé de GoPro, d'outils de saisie, de suivi des modifs de données, mais aussi d'outil de contrôle à priori (façon "validator" de JOSM) que l'IGN a dans ses outils, mais il ne semble pas y avoir d'équivalent à osmose.

A ce sujet, j'ai lancé l'idée de définir des règles de cohérences sous forme de scripts génériques non liés à un outil ou des formats de données pour par exemple décrire des choses comme: un bureau de poste est soit ponctuel, soit d'une surface comprise entre 10 et 500m2.

C'est une idée qui m'était venue pendant l'exposé d'une autre thèse lors de la journée OSM au CRAIG: http://recherche.ign.fr/labos/cogit/pdf/THESES/BRANDO/M%C3%A9moire_de_Th%C3%A8se-Carmen_Brando_Escobar_2013.pdf

Tags:

IGN

Les enjeux d'un référentiel "communes"

cquest — Sat, 07 Dec 2013 09:00:30 +0000

Lors du premier opendatacamp organisé par la mission Etalab fin novembre 2013, j'ai proposé un atelier sur un référentiel des communes.

Ceci coïncidait avec l'achèvement proche du tracé des limites de communes françaises dans OpenStreetMap et c'était l'occasion de se poser quelques questions sur les usages potentiels de ce genre de référentiel, des ré-utilisateurs, de leurs attente et aussi des problèmes liés à un tel référentiel.

Notre atelier a rapidement tourné en un quizz avec une question basique: combien y a-t-il de communes en France ?

Je ne pensais pas qu'on passerai autant de temps à répondre à cette question d'apparence simple et ce tweet a eu pas moins de 37 retweets ce qui doit être mon record !

Comme vous le voyez, des nombres assez variés sont sortis de nos explorations de données, en fonction de la source et du jeu de données. Seules 2 sources semblaient d'accord l'INSEE et le Ministère de l'Intérieur avec 36681 communes.

L'INSEE publie le COG (Code Officiel Géographique) sur sont site web. Fin novembre c'était le COG au 1er janvier 2013 qui était disponible. C'est comme son nom l'indique la source Officielle. L'autre jeu de données qui coïncidait était celui du Ministère de l'Intérieur disponible sur data.gouv.fr et qui indique l'appartenance à un EPCI (communauté de communes, d'agglos, etc) là aussi au 1/1/2013.

Pour le chiffre du cadastre, ceci provient d'un script maison qui va chercher chaque nuit sur le site du cadastre la disponibilité au format vectoriel ou image du cadastre des communes. Ce n'est donc pas à proprement parlé un jeu de données. Pour les chiffres de la DILA, ce sont les emplacements de mairies... donc un jeu de données soit incomplet soit il y a plus d'une centaine de communes sans mairie. Pour Territoria, je n'ai pas le descriptif exact.

Pour l'IGN, deux jeux de données spécifiques aux communes sont disponibles, le GEOFLA qui contient l'emprise géographique approximative et le RGC (Registre Général des Communes) qui est un fichier texte listant les communes et des informations les concernant, un jeu assez proche du COG. Là les données datent de 2012 ce qui explique en partie l'écart.

Certains écarts trouvent leur explication dans le contenu du jeu de données. Y a-t-il bien les DOM ? Les arrondissements municipaux (Paris, Lyon, Marseille) ont ils été mélangés aux communes ? En gros compte-on la même chose ?

D'autres écarts sur des sources à considérer comme des références (COG, GEOFLA, RGC) proviennent des mises à jour et du millésime des données. Il est par exemple étonnant que fin novembre 2013 GEOFLA et RGC n'aient pas été remis à jour depuis 2012.

Une donnée mouvante

En effet, les communes évoluent, fusionnent, se séparent, mais aussi changent de nom, voient leur territoire changer, bref c'est un jeu de données en perpétuelle évolution. Ces évolutions pourraient par mesure de simplification de leur suivie être appliquées par exemple le premier janvier de chaque année, mais non ce serait bien trop simple (ou alors personne n'y a pensé).

Donc le chiffre de 36681 du COG qui semblait le plus exact était en fait lui aussi inexact à la date de l'opendatacamp car depuis le 1er janvier 2013, au moins une commune a fusionné avec sa voisine le 28 février 2013.

Pour se tenir au courant il faut faire la lecture du JORF (Journal Officiel) qui publie ces changements. Le texte est disponible sur le site légifrance, mais sans les plans et cartes associés pour ce qui est des changements de territoires entre deux communes. Ceci bien sûr ne facilite pas la tâche pour des données cartographiques.

Par mesure de simplification, je suggère vraiment que toutes ces modifications soit officielles au 1er janvier de chaque année et jamais en milieu d'année. Ceci permettrait à minima d'avoir un jeu de données annuel stable et donc bien plus facile à suivre.

Un besoin de millésimes

Il est aussi important que les différents millésimes de ce jeu de données soient facilement disponibles, ce qui n'est pas le cas aujourd'hui. l'INSEE publie bien l'historique des modifications du COG depuis 1943, mais reconstituer le COG de 2005 n'est pas quelque chose de facile.

Pareil pour l'IGN et le GEOFLA, avoir les limites de communes au 1er janvier de chaque année et conserver la publication des millésimes précédents est très utile car ce jeu de données sert souvent à faire des datavisualisations par exemple de statistiques parfois de l'année en cours, mais souvent établies sur des données issues des années passées. Comment représenter sans erreur la population par commune en 2010 alors qu'on n'a plus à notre disposition les découpages des communes de 2010 ?

C'est ce que nous allons tenter de faire à partir des données OpenStreetMap dans les semaines à venir vu que ça y est, depuis l'opendatacamp nous avons fini de tracer les limites des communes françaises (hors Mayotte).

Le découpage communal est en effet un socle sur lequel de multiples découpages s'appuient (EPCI, électoraux, ressort judiciaire, différents syndicats de communes, carte scolaire rectorats et académies, etc). C'est donc une donnée essentielle, fortement réutilisée et etrèmement utile ! Son libre partage est donc essentiel.

Ah oui... dernier point... sauf erreur de ma part à la lecture du JO 2013, il y aurait à l'heure où je poste ce billet 36680 communes françaises.

Mise à jour du 1-10-2014: il y a actuellement 36683 communes en comptant St-Pierre et Miquelon et la "dé-fusion" de Bihorel et Bois-Guillaume intervenue le 1/1/2014...

Mise à jour du 1-1-2015: 24 communes de moins en ce premier janvier, issues de fusions... on est donc à 36659 (sauf erreur)

Tags:

découpage administratif

Quality control on french OSM administrative boundaries

cquest — Thu, 21 Nov 2013 10:41:25 +0000

Tracing France administrative boundaries is a tedious work that took several yers as France has 36000+ municipalities which is around 40% of all Europe municipalities !

In 2011, then in 2013, IGN (french geographic national authority) published 2 datasets in opendata, GEOFLA and Route500, but these data are simplified with a much lower level of details compared to OSM goals.

So, the only authorized and good enough source for that job is the french cadastre.

As we're getting close to 100% completeness of french administrative boundaries, it is time to study their quality. Without freely available reference data, an exhaustive study is not possible, but let's try with what we have.

GEOFLA and Route500 contain simplified administrative boundaries, but it seems that the crossing nodes have been more or less maintained very close to their original location.

So I've tried to do some comparison on these crossing nodes between OSM and Route500 (less simplified that GEOFLA).

(if PostGIS SQL queries are not your favorite reading, you can skip to the end of this post)

Import Route500 in PostGIS...

export SHAPE_ENCODING="ISO-8859-1"

ogr2ogr -t_srs EPSG:900913 -f PostgreSQL PG:dbname=osm LIMITE_ADMINISTRATIVE.SHP -overwrite -nlt GEOMETRY -lco SCHEMA=public

ogr2ogr -t_srs EPSG:900913 -f PostgreSQL PG:dbname=osm NOEUD_COMMUNE.SHP -overwrite -nlt GEOMETRY -lco SCHEMA=public

ogr2ogr -t_srs EPSG:900913 -f PostgreSQL PG:dbname=osm COMMUNE.SHP -overwrite -nlt GEOMETRY -lco SCHEMA=public

Geometries a reprojected in mercator as for the OSM data we will use an osm2pgsql schema usually used to generate tiles.

We then to some cleaning and add some usefull indexes...

ALTER TABLE NOEUD_COMMUNE RENAME TO r500_communes_noeuds;

ALTER TABLE r500_communes_noeuds drop ogc_fid;

ALTER TABLE LIMITE_ADMINISTRATIVE RENAME TO r500_limite_admin;

ALTER TABLE r500_limite_admin drop ogc_fid;

ALTER TABLE LIMITE_ADMINISTRATIVE RENAME TO r500_communes;

ALTER TABLE r500_communes drop ogc_fid;

CREATE TABLE r500_noeuds (pt geometry, nb integer, insee text);

CREATE INDEX on r500_noeuds using gist(pt);

CREATE INDEX on r500_noeuds (insee);

Then we extract the crossing nodes...

INSERT INTO r500_noeuds select ST_Line_Interpolate_Point(l.wkb_geometry,0) as pt, null, null from r500_limite_admin l;

INSERT INTO r500_noeuds select ST_Line_Interpolate_Point(l.wkb_geometry,1) as pt, null, null from r500_limite_admin l;

and determine which municipalities are sharing them...

INSERT INTO r500_noeuds select pt, count(distinct(insee_comm)), string_agg(distinct(insee_comm),' ' order by insee_comm) as insee from r500_noeuds join r500_communes c on (st_touches(pt,wkb_geometry)) join r500_communes_noeuds n on (n.id_rte500=c.id_rte500) group by pt;

and a final cleanup:

DELETE FROM r500_noeuds where nb is null;

The resulting table contains 72598 nodes (Route500 2012) with:

crossing node
number of municipalities sharing that node: 1 for islands, enclaves and exclaves, 2 for municipalities on the seaside or at international border, 3 or more in most cases
INSEE unique codes identifying the municipalities sharing the node (in ascending order)

OSM crossing nodes

Same structure for the table:

CREATE TABLE osm_noeuds (pt geometry, nb integer, insee text);

CREATE INDEX on osm_noeuds using gist(pt);

CREATE INDEX on osm_noeuds (insee);

To speedup processing, a temporary table only containing municipalities polygons is created:

CREATE TEMP TABLE osm_communes as (select "ref:INSEE" as insee, way FROM planet_osm_polygon WHERE boundary is not null and boundary='administrative' and admin_level='8' and "ref:INSEE" is not null);

CREATE INDEX on osm_communes using gist(way);

Then crossing nodes are extracted (with this poorly optimized query)...

INSERT INTO osm_noeuds select pt, null, null from (select st_line_interpolate_point((st_dump(st_linemerge(st_intersection(c.way,l.way)))).geom,0) as pt from osm_communes l join osm_communes c on (st_touches(c.way,l.way) and c.insee > l.insee)) as lim group by pt;

INSERT INTO osm_noeuds select pt, null, null from (select st_line_interpolate_point((st_dump(st_linemerge(st_intersection(c.way,l.way)))).geom,1) as pt from osm_communes l join osm_communes c on (st_touches(c.way,l.way) and c.insee > l.insee)) as lim group by pt;

Remove the doubles...

INSERT INTO osm_noeuds select pt, 0,null from osm_noeuds group by pt;
DELETE FROM osm_noeuds where nb is null;

and determine which municipalities are sharing them:

INSERT INTO osm_noeuds select pt, count(*), string_agg(c.insee,' ' order by c.insee) as insee from osm_noeuds join osm_communes c on (st_touches(pt,way)) group by pt;

DELETE FROM osm_noeuds where nb=0;

Tables r500_noeuds and osm_noeuds are similar, we can start comparing their content... and get the 100 largest differences :

SELECT min(st_distance(st_transform(r.pt,2154),st_transform(o.pt,2154))) as d , r.insee from r500_noeuds r join osm_noeuds o on (r.insee=o.insee) group by r.insee order by d desc limit 100;

Résults

A CSV file containing the above query result is updated every night at: http://osm13.openstreetmap.fr/~cquest/openfla/ecarts-osm-route500.csv

It contains :

the distance between OSM and Route500 crossing nodes, which median value is 22m (half of differences are below 22m)
INSEE codes of the municipalities (space separated)

These raw data are available for further analysis, and also to check/fix OSM data where needed.

Here is a data visualisation of these differences, provided thru a new overlay on tile.openstreetmap.fr

More reading (in french) about this overlay is available on OSM wiki : http://wiki.openstreetmap.org/wiki/FR:Servers/tile.openstreetmap.fr#Couc...

Tags:

qualité

Français

Contrôle qualité des limites administratives françaises dans OSM

cquest — Wed, 20 Nov 2013 20:08:24 +0000

Le tracé des limites administratives communales françaises est un travail de fourmis que les contributeurs OSM ont démarré il y a déjà plusieurs années.

La seule source de qualité pour laquelle nous avons une autorisation d'utilisation est le cadastre.

En 2011 puis en 2013, l'IGN a bien libéré le GEOFLA™®© puis le Route500™®©, mais ces données sont simplifiées et d'une qualité très inférieure à l'objectif que se sont fixé les fourmis mappeuses.

Les 100% étant bientôt atteints, se pose la question de la qualité de ces données et leur vérification. En l'absence d'accès aux données "de référence", il n'est pas possible de faire une étude exhaustive, mais a minima une étude sur des points vérifiables.

Le GEOFLA et le Route500 contiennent donc des limites simplifiées, mais cette simplification semble n'avoir était faite que sur les polylignes et pas (ou peu) sur les nœuds d'intersection où les frontières de plusieurs communes se rejoignent.

J'ai donc creusé cette idée "pour voir" et voici comment j'ai procédé pour comparer ces nœuds dans OSM et Route500.

(si les requêtes SQL ne sont pas votre lecture favorite, vous pouvez zapper à la fin de ce billet)

Tout d'abord l'import du Route500 dans une base PostGIS...

export SHAPE_ENCODING="ISO-8859-1"

ogr2ogr -t_srs EPSG:900913 -f PostgreSQL PG:dbname=osm LIMITE_ADMINISTRATIVE.SHP -overwrite -nlt GEOMETRY -lco SCHEMA=public

ogr2ogr -t_srs EPSG:900913 -f PostgreSQL PG:dbname=osm NOEUD_COMMUNE.SHP -overwrite -nlt GEOMETRY -lco SCHEMA=public

ogr2ogr -t_srs EPSG:900913 -f PostgreSQL PG:dbname=osm COMMUNE.SHP -overwrite -nlt GEOMETRY -lco SCHEMA=public

Les géométries sont reprojetées en mercator car c'est une base osm2pgsql destinée à la production de tuiles qui va être utilisée côté OSM.

Dans psql on procède à un peu de nettoyage et à la création de quelques index qui seront bien utiles...

ALTER TABLE NOEUD_COMMUNE RENAME TO r500_communes_noeuds;

ALTER TABLE r500_communes_noeuds drop ogc_fid;

ALTER TABLE LIMITE_ADMINISTRATIVE RENAME TO r500_limite_admin;

ALTER TABLE r500_limite_admin drop ogc_fid;

ALTER TABLE LIMITE_ADMINISTRATIVE RENAME TO r500_communes;

ALTER TABLE r500_communes drop ogc_fid;

CREATE TABLE r500_noeuds (pt geometry, nb integer, insee text);

CREATE INDEX on r500_noeuds using gist(pt);

CREATE INDEX on r500_noeuds (insee);

Ensuite il faut extraire ces nœuds d'intersection...

INSERT INTO r500_noeuds select ST_Line_Interpolate_Point(l.wkb_geometry,0) as pt, null, null from r500_limite_admin l;

INSERT INTO r500_noeuds select ST_Line_Interpolate_Point(l.wkb_geometry,1) as pt, null, null from r500_limite_admin l;

puis déterminer les communes se rencontrant sur ces nœuds...

et faire un petit nettoyage final:

DELETE FROM r500_noeuds where nb is null;

La table ainsi générée contient 72598 nœuds (Route500 2013) avec:

le noeud d'intersection
le nombre de communes touchant cette intersection: 1 pour les iles, enclaves et exclaves, 2 pour les communes du littoral et frontalières, 3 ou plus pour les autres (il y en a seulement 4 qui sont à l'intersection de5 communes, et 1 à l'intersection de 6 communes)
les codes INSEE des communes correspondantes (triés par ordre croissant)

Création de la table des nœuds d'intersection OSM

La table possède la même structure (noeud, nombre de communes, codes insee).

CREATE TABLE osm_noeuds (pt geometry, nb integer, insee text);

CREATE INDEX on osm_noeuds using gist(pt);

CREATE INDEX on osm_noeuds (insee);

Pour accélérer les traitements on va créer une table temporaire ne contenant que les polygones des limites administratives:

CREATE INDEX on osm_communes using gist(way);

Pour la suite, je n'ai rien trouvé de très optimisé (pour l'instant) et donc...

Puis on dédoublonne...

INSERT INTO osm_noeuds select pt, 0,null from osm_noeuds group by pt;
DELETE FROM osm_noeuds where nb is null;

Ne reste plus qu'à reprendre chaque nœud pour trouver les communes qui s'y rejoignent:

INSERT INTO osm_noeuds select pt, count(*), string_agg(c.insee,' ' order by c.insee) as insee from osm_noeuds join osm_communes c on (st_touches(pt,way)) group by pt;

DELETE FROM osm_noeuds where nb=0;

La structure des tables r500_noeuds et osm_noeuds sont donc identiques et on peut commencer les comparaisons... et sortir par exemple la liste des 100 plus gros écarts :

SELECT r.insee, min(st_distance(st_transform(r.pt,2154),st_transform(o.pt,2154))) as d from r500_noeuds r join osm_noeuds o on (r.insee=o.insee) group by r.insee order by d desc limit 100;

Résultat

Un fichier CSV contenant le résultat de cette dernière requête est disponible et mis à jour chaque nuit sur: http://osm13.openstreetmap.fr/~cquest/openfla/ecarts-osm-route500.csv

Il contient donc:

l'écart dont la valeur médiane est de 22m (50% des écarts sont inférieurs à 22m)
les codes INSEE des communes à l'intersection (séparés par un espace).

Il ne reste plus qu'à analyser plus en détail ces écarts et à vérifier les plus importants... un travail de fourmis, mais ça c'est notre spécialité !!

Voici une visualisation colorée de ces écarts produite par une nouvelle couche disponible sur tile.openstreetmap.fr

A propos de cette couche carto, lire : http://wiki.openstreetmap.org/wiki/FR:Servers/tile.openstreetmap.fr#Couc...

Tags:

qualité

English

Données ODbL affichées sur fond Google... comme un léger problème ?

cquest — Mon, 28 Oct 2013 13:08:47 +0000

Les histoires de licences ne sont pas les plus drôles, mais celle-là vaut le coup d'être racontée.

Lors de nombreux hackathon, j'en profite pour présenter OpenStreetMap aux développeurs présents, leur montrer que ce n'est pas qu'une carte mais bien une base de données et leur vanter les mérite du libre !

Lors du dernier hackathon où j'étais présent (#dataculture), une question m'est venue à l'esprit: connaissant les conditions d'utilisation des services de Google, a-t-on le droit d'utiliser les API Google pour visualiser des données ODbL ?

En général, peu de monde se pose ce genre de questions et ces fameuses conditions d'utilisation ne sont quasiment jamais lues, donc voici le passage intéressant dans "Vos contenus et nos Services" :

En soumettant des contenus à nos Services, par importation ou par tout autre moyen, vous accordez à Google (et à toute personne travaillant avec Google) une licence, dans le monde entier, d’utilisation, d’hébergement, de stockage, de reproduction, de modification, de création d’œuvres dérivées (des traductions, des adaptations ou d’autres modifications destinées à améliorer le fonctionnement de vos contenus par le biais de nos Services), de communication, de publication, de représentation publique, d’affichage ou de distribution public desdits contenus.

En clair, si on utilise Google Maps (ou autre) pour visualiser des données ODbL (issues de l'opendata, issues d'OSM, etc) on les soumet donc aux "Services" et donc on accorde implicitement à Google un droit que l'on ne possède pas.

En effet, l'ODbL est une licence en "partage à l'identique" (share-alike en anglais) dont le but est d'alimenter le cercle vertueux du partage. On ne peut donc pas mélanger des données ODbL avec des données non libres au sein d'une même base de données. Or en accordant des droits d'utilisation très larges à Google on oublie un peu vite ce principe de la licence ODbL ainsi que le second qui oblige à citer l'origine des données.

Qu'est-ce que Google fera au juste des données qu'on soumet à ses services ? On n'en a aucune idée précise tellement les termes sont flous.

Ni le partage à l'identique ni l'attribution ne seront respectés et donc en soumettant des données ODbL à un service non libre qui s'autorise à réutiliser ces données comme bon leur semble on ne respecte pas la licence ODbL d'origine.

Encore aurait-il fallu lire ces conditions d'utilisation pour le savoir... lecture que je vous recommande car vous découvrirez sûrement d'autres surprises très intéressantes !

Je vous remets le lien, comme ça plus d'excuse : http://www.google.fr/intl/fr/policies/terms/regional.html

Commentaires bienvenus !

Tags:

ODbL

licence

Google