Votez pour des mashups plus libres ...

Richard Fairhurst, contributeur OpenStreetMap, propose au vote public cette injonction à Google :

"Sort the legalities about tracing from your aerial imagery!
Millions of people are creating mashups on Google Maps. The export format is easy (KML), but we still can't use it elsewhere due to copyright worries."

Pour plus d'informations, regardez ici et là.

Je vous invite à voter sur la page dédiée.
Petite ironie : il faut un compte Google pour voter ;-)

Unexpected use of Geographic Information

As seen at the State of the Map conference:



"The project was started because most maps you think of as free actually have legal or technical restrictions on their use, holding back people from using them in creative, productive or unexpected ways." from http://wiki.openstreetmap.org/wiki/Press

Now, I get it ;-)

Pourquoi AND a offert ses données à OSM ?

Attention, ce que vous allez lire pourra vous offenser. Le trait est volontairement exagéré. Ames sensibles, changez de fil ;-)

La réponse est en fait très simple : parce qu'elles ne valent plus rien !
Ou alors, parce qu'il reste peu de temps avant que leur coût tende vers zéro. Plus précisément, parce qu'il ne sera bientôt plus possible d'en tirer une quelconque rentabilité, tout en restant dans le même paradigme de distribution unidirectionnelle de la donnée fermée.

Plusieurs raisons à cela.

La première est que OSM avance très vite, et sous peu, les données libres auront atteint le même niveau de qualité et de complétude (cf l'étude de Muki Haklay qui compare la qualité des données OSM avec un dataset commercial --Meridian2--, dont l'hypothèse conclusive est sans appel, au transparent 38) ...

La deuxième est que ce jeu de données leur coûte trop cher à maintenir (et donc leur couterait beaucoup plus cher à améliorer significativement - ce qui serait souhaitable pour certaines applications), alors que la communauté OSM fait ça très bien, bénévolement, et qu'elle en tire un plaisir non dissimulé.

La dernière est probablement parce que vendre de la donnée brute "de base" ne suffira plus (ce que semble confirmer cette interview). C'est la pertinence de la donnée qui va permettre de générer du revenu: délivrée au bon moment, d'actualité, mise en contexte et commentée. On rejoint le contexte des bien connus LBS.

La conclusion est la suivante : la véritable valeur d'un jeu de données est liée au nombre d'utilisateurs qui s'en servent, et qui donc sont en mesure de le corriger et de l'améliorer (car les utilisateurs de la donnée géographique sont aussi des contributeurs, dans le paradigme émergent).

Tout ceci suppose bien évidemment que la licence sur les données soit ouverte.
Il est en effet inimaginable de maintenir les remontées de bug des utilisateurs sur le long terme autour d'un jeu de données fermé, alors qu'une offre parallèle de données géographiques de qualité monte en puissance.

Les producteurs de données commerciales tels que Navteq et TeleAtlas ont du souci à se faire. Au fur et à mesure que OSM avance, leurs jeux de données perdent de leur valeur.
Ce ne sont pas les pseudo communautés mises en place autour de systèmes tels que MapShare qui vont permettre de compenser celà. Comme expliqué plus haut, ces datasets retiennent encore pour eux leur homogénéité, ainsi que la connaissance de leurs limites.

Un business modèle alternatif ? le service.
A l'image de l'écosystème bâti autour du logiciel libre, dans lequel les projets financent les ajouts fonctionnels à des briques de base libres, il est possible d'imaginer vendre du service autour de l'enrichissement (en POI, en données pertinentes pour un champ d'activité particulier, etc, mais peut être aussi en précision ?) d'un jeu de données ouvert sur une zone donnée.

L'apparition de tout ceci n'est plus qu'une question d'années.

Attention, je n'ai pas parle pas ici des données créées et maintenues par les agences cartographiques nationales (NMA), telles que l'IGN et l'Ordnance Survey. J'examinerai ce cas dans un prochain billet.

Open Database License 1.0

Hier a été publiée en version 1.0 la tant attendue licence "ODbL" (Open Database License) qui combine "Share Alike" (redistribution sous les mêmes termes du contrat) et "Attribution" (il faut créditer la source si vous redistribuez) sur la base et ses données.

Cette licence offre une meilleure protection des données que la Creative Commons BY-SA, dont elle garde l'esprit.
Je cite le blog de Open Data Commons : "The Open Database License (ODbL) is an open license for data and databases which includes explicit attribution and share-alike requirements. This license, the first of its kind, is a major step forward for open data. There are currently very few licenses available suited to data and databases and none which provide for share-alike (existing share-alike licenses such as the GPL, GFDL and CC By-SA are all unsuitable for data)."

Pour information, le projet OpenStreetMap considère désormais effectuer un "switch" vers cette licence, si tant est qu'une majorité des membres de la Fondation, puis des contributeurs l'approuvent.

Pour toute nouvelle publication de données géographiques libres (vecteur, rasteur) avec une orientation "Share Alike" et "Attribution", il est recommandé de considérer cette licence plutôt que toute autre.
A mon sens, cette nouvelle licence comble un vide juridique important, et il faut accueillir son arrivée comme une très bonne chose pour les données libres !

Note: si vous souhaitez placer vos données dans le domaine public, utilisez plutot la licence CC0 ou la PDDL (qui sont très proches et interopérables, car il s'agit d'implémentations du "protocole d'accès libre aux données" de Science Commons).

De la qualité des données collectées automatiquement

... et de la supériorité d'une approche qui privilégie le "terrain". C'est de celà qu'il va être question dans ce billet.

Peut être connaissez vous la Dent d'Arclusaz (prononcer "Arcluse") ?
Ceux qui empruntent l'A43 en direction d'Albertville ont dû entrapercevoir ce beau synclinal perché sur leur gauche, dans le massif des Bauges.

Quelle ne fut pas ma surprise quand j'ai appris qu'elle avait été inondée ! Si si, un beau massif calcaire, avec un lac au milieu ! C'est du moins ce que Google nous laisse penser ... regardez par exemple sur cette page.



La photo satellite de cette même zone nous rassure: l'inondation est passée ;-)



Plaisanterie à part, on peut tout de même s'étonner qu'aucun contrôle visuel n'ait été réalisé avant mise en production de telles données. La zone identifiée en tant que "lac" est en fait un peuplement de résineux, un peu plus sombre que les arbres alentours, qui a selon toute probabilité leurré les algorithmes de télédétection.

Bref, vous l'aurez compris, rien ne vaut le relevé et/ou la vérification sur le terrain, que promeuvent les "bottom-up GIS" tels que OpenStreetMap.

Limites administratives

Voici un petit tutoriel permettant d'exporter en shapefile les données de type "limites administratives" depuis OpenStreetMap.

Il y a/avait une petite astuce, que Sylvain Letuffe (alias "sly" sur osm-talk-fr) m'a fait découvrir. Merci à lui. C'est essentiellement pour celà que je poste ce billet : l'astuce vaut d'être plus largement connue.

Ce tutoriel suppose quelques connaissances de la ligne de commande sous linux debian. Rien de bien méchant anyway.

Nous voici partis.

On commence par récupérer les données OSM sur la France. On ne va pas passer par l'API, pour deux raisons :

1. la première est que ce ne sera pas permis en raison de la taille trop importante de la bounding box,
2. la deuxième (qui est en fait la cause originale) est que ça chargerait trop les serveurs OSM,
3. j'en dévoile une troisième au vol (qui est plutôt une conséquence de 2 puis de 1) : CloudMade offre déjà des extraits par pays, qui se téléchargent très bien (merci aws ;-)
   

Zou !

$ cd /tmp
$ wget http://downloads.cloudmade.com/europe/france/france.osm.bz2

On va ensuite importer ces données (au format XML) dans une base de donnée géographique.
OSM fournit un outil très pratique pour ce faire : OSM2PgSQL

Il y a quelques dépendances, que vous pourrez installer facilement via :

$ sudo apt-get install build-essential libxml2-dev libgeos-dev libpq-dev libbz2-dev proj

Voici ensuite une manière d'installer osm2pgsql :

$ svn co http://svn.openstreetmap.org/applications/utils/export/osm2pgsql/
$ cd osm2pgsql

Et là, on arrive au point ou il est nécessaire de mettre en oeuvre l'astuce sus-citée.
Par défaut, et à ce jour, OSM2PgSQL ne considère pas les objets de type boundary comme des géométries polygonales. Pour y remédier, éditer le fichier output-pgsql.c : il vous faudra remplacer make_polygon=0 par make_polygon=1 en ligne 818, de la rev. 14211
Edit: OSM2PgSQL a été patché depuis, et cette modification n'est plus nécessaire.

Puis, l'installation classique reprend son cours :

$ make
$ sudo make install

Nous arrivons au point au nous avons besoin du SGBD PostgreSQL ainsi que sa cartouche spatiale PostGIS...

$ sudo apt-get install postgresql-8.3 postgresql-8.3-postgis

Puis nous créons une base de donnée pour accueillir les tables résultant de l'export des données OSM :

$ sudo su postgres
$ createdb -E UTF8 osm
$ createlang plpgsql osm
$ psql -d osm -f /usr/share/postgresql-8.3-postgis/lwpostgis.sql
$ psql -d osm -f /usr/share/postgresql-8.3-postgis/spatial_ref_sys.sql

Ceci fait, nous lançons l'importation, avec :

$ osm2pgsql -d osm -H localhost -P 5432 /tmp/france.osm.bz2

Vous pouvez aller vous prendre un café ;-)

Enfin, vous voici prêt à lancer l'export en shape:

$ pgsql2shp  -f /tmp/arrondissements.shp -g way -k osm "select * from planet_osm_polygon where admin_level=10"
$ pgsql2shp -f /tmp/communes.shp -g way -k osm "select * from planet_osm_polygon where admin_level=8"
$ pgsql2shp -f /tmp/departements.shp -g way -k osm "select * from planet_osm_polygon where admin_level=6"
$ pgsql2shp  -f /tmp/regions.shp -g way -k osm "select * from planet_osm_polygon where admin_level=4"

HTH comme on dit.

Et voici le résultat :


Il nous reste du travail ;-)

En chiffres, voici l'état actuel de la métropole :

• 13% des communes
  
• 81 départements (sur 96)
  
• 14 régions (sur 22)