Le coin de l'open-source géospatial

Sortie de la version 1.4.0 de PostGIS

L’équipe de développement de PostGIS vient d’annoncer la sortie d’une nouvelle version (la 1.4.0) après une « période de médidation et de recherche intérieure » (je cite l’annonce). La version est téléchargeable ici : http://postgis.refractions.net/download/postgis-1.4.0.tar.gz
Cette nouvelle version de PostGIS inclus une augmentation importante de la performance, une documentation améliorée, un nouveau format en sortie (GeoJSON) et un système interne amélioré de teste. PostGIS 1.4 gère la version récente de PostgreSQL 8.4.

Compatibilité minimale :

• PostgreSQL 8.2 et supérieure sur toutes les plateformes ;
• GEOS 3.0 et supérieure seulement ;
• PROJ4 4.5 et supérieure seulement.

Nouvelles fonctionnalités :

• ST_Union() utilise l’union rapide en cascade lorsqu’il est compilé avec GEOS 3.1+ (Paul Ramsey) ;
• ST_ContainsProperly() nécessite GEOS 3.1+ ;
• ST_Intersects(), ST_Contains(), ST_Within() utilise les géométries préparées en cache super rapide en fonction de GEOS 3.1+ (Paul Ramsey) ;
• amélioration importante de la documentation et du manuel de référence (Regina Obe & Kevin Neufeld) ;
• exemples de figures et de diagrammes dans le manuel de référence (Kevin Neufeld) ;
• ST_IsValidReason() renvoi des explications explicites sur l’échec de la validité (Paul Ramsey) ;
• ST_GeoHash() renvoi une signature geohash.org pour les géométries (Paul Ramsey) ;
• Interface multi-plateforme pour le chargement de Shape (Paul Ramsey) ;
• ST_LineCrossingDirection() renvoie des directions de passage (Paul Ramsey) ;
• ST_LocateBetweenElevations() renvoie des sous-chaînes basé sur Z-ordonnées (Paul Ramsey) ;
• le parser de géométrie renvoi des messages d’erreur explicites sur l’endroit des erreurs de syntaxe (Mark Cave-Ayland) ;
• ST_AsGeoJSON() renvoie un format JSON ;
• Populate_Geometry_Columns() — ajoute automatiquement les enregistrements dans les tables geometry_columns pour les TABLES et les VIEWS (Kevin Neufeld) ;
• ST_MinimumBoundingCircle() — renvoie le plus petit polygone circulaire qui peut entourer une géométrie (Bruce Rindahl).

Amusez vous bien !

Souscrire aux commentaires de cet article

Des logiciels libres aux données libres (partie 3 sur 3)

Les données libres

Les licences, ces modèles économiques, ces outils et cette organisation présentés dans les sections précédentes sont adaptés et ont été conçu pour des projets logiciels. La problématique pour les projets de données sont un peu différente. Cette section a pour but de tenter de proposer une définition pour chacun d’eux.

Licences

Il existe plusieurs licences de données libres :

• la probable future licence de OSM ;
• la Public Geodata Licence ;
• mais d’autres existent.

Les licences libres doivent permettre :

• la liberté d’utiliser les données — pour tous les usages ;
• la liberté de voir les données brutes — ce qui suppose l’accès aux données brutes ;
• la liberté de redistribuer des copies, mapshup, cartes, etc. (travaux dérivés) — ce qui comprend la liberté de vendre des copies et travaux dérivées ;
• la liberté d’améliorer les données et de publier ses améliorations — ce qui suppose, là encore, l’accès aux données brutes.

Les travaux dérivés constituent une modification telle que l’accès aux données brutes n’est plus possible. Il en résulte selon les droits décrits plus haut, que le diffuseur doit fournir un accès aux données libres utilisées. Mais cela est un peu plus complexe qu’il n’y parait …

OpenStreetMap utilise jusqu’à présent la licence « Creative Common CC-BY-SA ». Cela signifie que vous avez le droit de copier et de diffuser le document en gardant l’auteur et les conditions originels. Cette licence pose un certain nombre de problème :

• elle n’a pas été conçu pour des données !
• elle n’est pas clair sur les possibilités de réutilisation des données (mapshup, cartographie, etc.).

La nouvelle licence proposée par la Fondation OpenStreetMap (en réalité composée de deux licences : Open Data Licence combiné à l’ODL Factual Info Licence) est une licence adaptée aux bases de données et aux données. Ce projet de licence a été initiée en 2007 par Jordan Hatcher et Dr. Charlotte Waelde de l’Université d’Édimbourg et a proposé ces deux types licences complémentaires offrant une grande flexibilité d’utilisation. Elle est maintenant hébergée et gérée par l’Open Knowledge Foundation qui propose également d’autres projets.

La problématique des licences des données libres est donc non seulement différente de celle des logiciels libres mais beaucoup plus complexe. Comment définir un travail dérivé ? Des traitements spatiaux complexes sur les données devront elles être diffusés sous une licence libre ou bien pourrait on considérer ce travail de la même manière qu’écrire un document avec un logiciel de bureautique tel qu’OpenOffice ? Ces licences se doivent de préciser clairement ce qui est un traitement dérivé, les droits et devoirs qui s’y appliquent. D’autre part, est il souhaitable de faire la différence entre la structure de la table et son contenu ? Mais comment définir le « contenu » d’une base de données ?

D’autres parts, de nombreuses protections existent concernant les bases de données et les données : directive européenne, droit d’auteur, contrat, etc. L’auteur de la licence Opendatacommons explique : que

ce maquis de droits protégeant les bases de données et les données peuvent constituer un obstacle important pour l’utilisation et la réutilisation des données. Cela est vrai tant pour la communauté scientifique, qui souhaitent élargir sa connaissance grâce à l’utilisation des autres données et pour la communauté de la recherche et d’Internet avec pour ambition le Web sémantique.

[source : Jordan Hatcher, http://www.osbr.ca/ojs/index.php/osbr/article/view/516/475]

Mais comme nous venons de le voir, un travail est mis en place tant du côté d’OpenStreetMap que du côté de l’OSGeo ou d’autres groupes de travail. Ceci peut être préjudiciable car une licence ne sera adoptée que si elle correspond aux besoins du plus grand nombre tout en étant la plus lisible possible. Auxquels cas nous verrons le jour à une multitude de licences de données libres, chacune avec ses imperfections.

Les modèles économiques

Les modèles économiques des projets libres sont basés sur les services. Autant en matière de logiciels, ceux-ci ont pu être testé et ont pas mal évolué, en matière de données libres, tout reste à faire. Certaines sociétés ont tenté il y a quelques années de créer de la valeur ajoutée sur les données libres malheureusement la société n’a pas pu continuer à les proposer. Si on se réfère aux modèles économiques des logiciels libres, ceux-ci sont basées :

• sur les services ;
• sur la valeur ajoutée ;
• sur la double licence ;
• sur la mutualisation.

Peut-on se baser sur ces modèles pour élaborer ceux des données libres ? Quels services de données peut proposer une société ?

Une société peut proposer dans le cadre d’un modèle économique basé sur les services :

• des webservices WMS, WCS, WFS, SLD dont les données sont mis à jour fréquemment ;
• stockage de données en base de données PostGIS ou MyGIS ;

ou d’un modèle économique basé sur la valeur ajoutée :

• un travail de mise à jour et de validation des données ;
• des changements de projections et de formats.

Si son modèle économique est basé sur la double licence, elle peut proposer la mise à jour et la validation des données avec possibilité d’utiliser les données sous une licence commercial sans obligation de fournir les données brutes.

Enfin si son modèle économique est basée sur la mutualisation, elle peut proposer des améliorations qui seront financé par une communauté. Le projet OpenStreetMap peut être considéré comme étant basé sur un tel modèle économique dans le mesure où la fondation reçoit des dons et des financements en nature (matériel ou temps disponible des bénévoles) ou en argent (campagne de don). Aujourd’hui aucune société ne peut démarrer un projet de création de données libres concurrent à OSM à partir de zéro. Elle devra se focaliser sur d’autres type de données ou bien avoir déjà des données disponibles (libération de données).

Quelques sociétés ont commencé à proposer des webservices sur des données libres comme la société allemande WhereGroup. Deux solutions sont proposées : une gratuite, mise à jour deux fois par an, et une autre payante, mise à jour tous les jours. D’autres webservices peuvent être mise en place, comme les services WFS et WCS, mais également des services SLD de définition de style pour les couches proposées en WMS, des GeoDRM (accès à la données en fonction d’une identification).

Les communautés et leurs outils

Il existe peu d’outils, à ma connaissance, adaptés à la gestion des données (historique notamment). OpenStreetMap gère l’historique au moyen d’une table maître (master table) qui contient tout l’historique des éditions et d’une table « actuelle » (current table), en plus des tables d’administration et utilisateurs. OpenStreetMap est le projet de référence en matière de communauté de données libre bien qu’elle soit focalisée sur les données routières principalement, seul une société éditrice ayant déjà des données pourrait arriver à rivaliser avec elle (mais on a déjà vue des projets leader perde tout leadership suite à des mauvaises décisions comme par le changement de licence).

OpenSteetMap propose ainsi toute une suite de logicielle (Merkaator, potlach, etc.), une API, une bases de données avec des snapshots ou nightly build réguliers, des listes de diffusions, un wiki, etc. Nous retrouvons tout ce qui compose un projet de logiciel libre.

À noter deux applications web intéressantes. J’ai parlé de l’application web TRAC plus tôt. Application qui permet de gérer des tickets qui constituent des rapports de bugs relatif aux logiciels. L’équivalent existe pour les données, cela s’appelle OpenStreetBug ou RIPart (Remontée d’Informations Partagées) ou bien des tests « unitaires » pour vérifier la qualité des données. L’application RIPart n’est pas libre et se base sur l’API du Geoportail. Elle a pour objectif de faire remonter les informations qui sont incorrectes vers le fournisseur de données (l’IGN).

Vous trouverez quelques informations supplémentaires sur la base de données d’OpenStreetMap dans ces liens :

• Explication du schéma de la base de données d’OpenStreetMap ;
• Schéma de la base de données d’OSM ;
• Pile applicative d’OSM.

Quelles données publiques doivent être libres et comment ?

Le Power of Information Taskforce Report a réalisé 7 recommandation sur les données libres :

• les données géographiques basique telles que les limites électorales et administratives, La localisation des établissements publiques, etc doivent être disponible pour libre (ré)utilisation ;
• il doit y avoir un accès aisé et libre aux données adresses ;
• les organisations bénévoles et communautaires poursuivant des objectifs de politique publique doivent bénéficier de dispositions standard simples pour assurer l’accès aux données géospatiales à tous les niveaux d’utilisation ;
• les licences doivent être simplifiée et harmonisées [..] et ne devrait pas dépendre de la destination ou du modèle économique de l’utilisateur ;
• l’API d’OpenSpace (l’équivalent anglais de notre géoportail), similaire mais plus contraignant que la version de Google Maps, doit devenir le point principal de diffusion pour les services de l’Ordnance Survey (l’IGN anglais) ;
• la création et la disponibilité des adresses et des codes postaux pour l’Angleterre libre pour (ré)utilisation.

Conclusion

La donnée et l’information sont le moteur de l’économie de la connaissance. Les recommandations du rapport sur la libéralisation des informations non personnelles du gouvernement pourrait fournir un stimulus de l’information si elle est appliquée.

[Source : http://poit.cabinetoffice.gov.uk/poit/2009/02/introduction-to-the-taskforce-final ]

Une réflexion doit avoir lieu sur les données libres publiques et la possibilité d’innovation qu’elles permettent. En Angleterre, la task force a permis d’initier une telle réflexion avec les utilisateurs. Citons les une dernière fois :

Il y a maintenant un besoin urgent de réformer l’Ordnance Survey. Actionnaires exécutifs et ministère du Trésor sont actuellement en train de mettre en place un examen du modèle économique. Elles devraient saisir l’occasion de la refonte de l’Ordnance Survey en agence cartographique du 21e siècle. Les progrès technologiques ont modifié les fondements traditionnels du modèle d’entreprise de l’Ordnance Survey et il existe un risque réel qu’il se retrouve lui-même anachronique, il est dépassé par des alternatives ouvertes telles que OpenStreetMap, soutenue par des technologies bon marché comme appui à la création de carte.

Des études ont montrées la pertinence des modèles économiques pour l’édition de logiciels libres, en France comme à l’étranger de nombres sociétés ont basées leur fonctionnement sur de tel modèle. D’ailleurs la France tient une place importante dans le monde de l’open source. Concernant les données libres, on voit ici et là, quelques initiatives mais très peu de véritable modèle économique sont mis en place, et un organisme public a toute sa pertinence pour mettre en place un tel modèle. Quelle sera la place de la France en terme de données libres ? Quel organisme public ou privé libérera le premier ses données et basera son fonctionnement sur un modèle économique innovant et original ?

Enfin comme la task force pour l’Angleterre, nous (communauté de la géomatique en France) devons être source de propositions et agir pour informer nos représentants politiques de la pertinence de ce modèle comme service publique. Agir non pas sur l’IGN mais directement sur les politiques et sur la tutelle de l’IGN qui définisent les missions et objectifs de l’IGN.

Bibliographie

1. La cathédrale et le bazar de Eric Raymond, http://seddisoft.kelio.org/cathedrale-bazar.htm ;
2. Veni, Vidi, Libri : l’association Veni, Vidi, Libri a pour objectif de promouvoir les licences libres ainsi que de faciliter le passage de créations sous licence libre, http://www.venividilibri.org ;
3. OSGeo – Public Geospatial Data Committee : comité Données Geospatial publiques de l’OSGeo, http://www.osgeo.org/geodata ;
4. Portail de diffusion de données libres au Canada, http://www.geobase.ca/geobase/fr/index.html ;
5. http://www.punkish.org/Licensing-Geographic-Data ;
   
6. http://interactive.dius.gov.uk/innovationnation/ ;
   
7. http://poit.cabinetoffice.gov.uk/poit/ ;
   
8. Comité Données Geospatiales Publiques, http://wiki.osgeo.org/wiki/Public_Geospatial_Data_Committee ;
   
9. http://www.opendefinition.org/ ;
   
10. Open Source Business Resource, http://www.osbr.ca/ojs/index.php/osbr/index.

Souscrire aux commentaires de cet article

Des logiciels libres aux données libres (partie 2 sur 3)

Modes de fonctionnement

Parmi la multitude de projet libre les plus connus sont sans aucun doute les projets de logiciels libres. Cette section présente le fonctionnement des projets en tant que projet de logiciels libres. Ce qui me semble définir un projet de logiciel libre est l’existence d’une communauté de développeurs dont des règles écrites ou tacites régissent les comportements et les relations en toute transparence. Les utilisateurs ont la possibilité d’échanger ou de suivre les échanges avec ou entre les développeurs.

Le mode de fonctionnement des projets libres est directement lié aux modèles économiques choisis ainsi qu’aux libertés fondamentales (voir plus haut). Les mots-clés sont les termes communautaire, transparence et indépendance.

Une communauté

Un projet libre a pour vocation de réunir des contributeurs d’horizon divers autour du projet. La licence autorisant les utilisateurs à modifier et diffuser leurs modifications, il est de l’intérêt du projet d’accepter les modifications des utilisateurs et de l’intérêt des développeurs extérieurs à retourner leur développements les plus génériques. Et ce pour différentes raisons :

• le projet évolue ainsi plus facilement et plus rapidement (correction de bugs, nouvelles fonctionnalités, etc.) ;
• les développeurs extérieurs n’auront pas à ré-adapter leurs modifications à chaque nouvelle version (adaptation de leur code aux évolutions du coeur du projet, évolution et adaptation des fonctionnalités qu’ils ont développés par la communauté).

Un travail gagnant-gagnant en somme.

Pour que les contributions puissent être acceptées il faut que le projet se soit réunit autour d’une communauté d’utilisateurs et de développeurs prêt à contribuer. Mais il faut également des règles définies pour que tout utilisateurs et développeurs puissent connaître le processus d’acceptation des contributions au projet et connaître les besoins.

Des outils

Pour une bonne communication entre les développeurs et les utilisateurs, des outils sont mis en place. On trouve généralement :

• des listes de diffusion ;
• un serveur de dépôt de code source, svn ou subversion est généralement utilisé ;
• une interface de gestion de bug et de demande de nouvelle fonctionnalité, appelé bugtracker ;
• un canal irc ;
• un site Internet (avec le minimum vital parfois) ;
• un wiki (mais pas toujours).

Le serveur de dépôt de code, les listes de diffusion et le bugtracker sont le minimum que propose un projet. Ces outils ont chacun une fonction précise dans le processus de développement.

Listes de diffusion et canal IRC

Il existe généralement plusieurs listes, mais toutes celles qui sont présentées ici n’existent pas toujours :

• dev (toujours) ;
• users (toujours) ;
• commit (souvent) ;
• release (souvent);
• listes locales (fr, de, etc.).

La liste dev permet de discuter entre les développeurs : quelles sont les nouvelles fonctionnalités qui vont être ajoutées, discussion sur leur conception, sur les bug et leur résolution, définition du planning des prochaines versions, etc. C’est aussi l’endroit pour poser vos questions si vous désirez ajouter une nouvelle fonctionnalité.

La liste user vous permet de poser vos questions lié à des problématiques d’utilisation du logiciel. Les développeurs y répondent directement et rapidement assez souvent.

La liste commit vous permet de suivre de près (de très près même) les développements qui sont « commité » (d’où le nom de la liste) dans le serveur de dépôt de code source.

La liste release vous permet de vous tenir au courant des sorties des nouvelles versions.

Les listes locales vous permettent de poser votre question dans votre langue. Très peu de ce type de liste existe. Il en existe pour GRASS (grass-fr par exemple).

Un serveur de dépôt de code source

Un serveur de dépôt de code source est un serveur qui permet à plusieurs développeurs de travailler ensemble sur le développement d’un logiciel sans que leurs modifications du code source soient écrasées par celles des autres développeurs. Ce serveur gère également un historique des modifications :

• qu’est ce qui a été modifié ?
• qui a modifié ?
• quand le fichier a t-il été modifié ?

Voici quelques exemples :

• le svn de MapServer ;
• voir les sources de MapServer ;
• un diff entre deux versions du fichier HISTORY.TXT dans lequel une ligne a été rajoutée, cliquez ici.

Bugtracker

Un système de rapport de bug permet au projet de gérer les problèmes et les demandes de fonctionnalités. Il permet d’affecter ceux-ci à une version spécifique et permet de connaître la roadmap des futures versions. Voici celles pour QGIS. Vous trouverez sur cette page la liste des bugs actifs, classés par type de bug.

Site et wiki

Bien sur, un projet a toujours son site, parfois une page, parfois plus, il présente le projet, rassemble la documentation, liste les liens pour télécharger les versions (source et binaires). Parfois un wiki est proposé. De plus en plus souvent les projets utilisent une application appelée Trac qui rassemble un wiki, un bugtracker, une navigation du svn, la roadmap et la timeline ((page qui liste les envois de code sur le serveur de dépôt effectués par les développeurs)).

Des règles écrites ou tacites

Dans le cas un peu spécial où le projet est hébergé par l’OSGeo, le projet se doit d’avoir un minimum de règle écrite pour définir le fonctionnement du comité en charge du projet. Ce n’est pas souvent aussi formalisé au sein d’un projet Open Source. L’OSGeo impose un certain nombre de règle lors de la phase d’incubation : révision du code concernant le copyright, ajout d’en en-tête dans tous les fichiers pour indiquer la licence et bien sur des règles écrites concernant le fonctionnement du projet. Voici par exemple celui du projet OpenLayers.

Vous trouverez chaque Comité de pilotage du projet pour les projets de l’OSGeo sur cette page.

Souscrire aux commentaires de cet article