OpenStreetMap France - IGN

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

Gratuites ou libres ? Les données ne sont pas données (Libération)

webmaster — Wed, 27 Feb 2013 10:47:06 +0000

Une certaine confusion règne autour de la notion de «données libres». Dans une récente tribune, en réponse à une demande d’ouverture des données de bien commun (Libération du 25 janvier), l’Institut géographique national (IGN) avance la mise à disposition gratuite d’une partie du patrimoine géographique (Libération du 7 février).

Stage lié à OSM au COGIT-IGN

webmaster — Fri, 11 Jan 2013 08:53:55 +0000

Le COGIT étudie les problématiques liées à l'utilisation des données topographiques vectorielles comme l'intégration de données, le changement de niveau de détail, la cartographie ou la structuration des données pour faciliter des analyses dans des domaines d'application spécifiques (urbanisme, biodiversité, etc.).

Il propose sur son site un stage de recherche de 4 à 5 mois pour 2013.

OpenStreetMap à l'honneur dans IGNmagazine !

webmaster — Tue, 04 Dec 2012 20:11:31 +0000

Data Tuesday Cartographie le 18 septembre à Saint-Mandé (94)

webmaster — Mon, 27 Aug 2012 20:11:51 +0000

Hébergé par l'IGN, le premier Data Tuesday de la rentrée sera consacré au thème : Cartographie et Géolocalisation

Au programme, plusieurs sociétés et organisations interviendront parmi lesquelles :

L'IGN
OpenStreetMap
la Ratp
3Liz

Rendez-vous le mardi 18 septembre à 18h30 à l'Institut Géographique National, 4 avenue Pasteur à Saint-Mandé, Métro Saint-Mandé ou Bérault (Ligne 1)

Incriptions sur: http://fr.amiando.com/DataTuesdayCartographie.html