neogeo

On l’apprend sur la liste de diffusion de l’OSGeo, via un communiqué de son président Tyler Mitchell, l’IGN devient un sponsor associé de l’OSGeo. Même si c’est le niveau le plus bas, à 3000 $, il convient de saluer cette initiative qui apparaît comme une réelle reconnaissance envers la communauté OpenSource dans laquelle l’IGN a su puiser et participer : proj, gdal/ogr dans un premier temps, OpenLayers pour l’API du Géoportail plus récemment.

C’est précisément l’API du Géoportail qui a incité l’IGN a franchir ce pas. Pour la future version, prévue sous peu, il a été décidé qu’elle deviendrait un type de couche d’OpenLayers, à la manière de ce qui existe pour GoogleMaps. Cette décision renforce le niveau d’intégration de l’API dans OpenLayers, et ce faisant le niveau d’implication de l’IGN dans le projet global (résolution de bugs, patches, nouvelles fonctionnalités…). Mais il était difficile à l’IGN de se soumettre aux Conditions de licence de Metacarta, qui, même si elles sont protectrices pour le projet lui-même, en reviennent à soumettre une institution publique française au droit de regard d’une entité privée américaine, damned ! Le passage par l’OSGeo, fondation à but non lucratif, permettrait de contourner cet obstacle, même si Metacarta reste le détenteur final du copyright.

Toujours est-il que les buts des développeurs de l’IGN est clairement de contribuer régulièrement à la solution OpenLayers, afin d’en faire le standard européen pour les Géoportails. A la différence de l’Ordnance Survey britannique, et à ce que la bêta avait pu faire croire, l’IGN se place donc résolument dans le camp de la généricité et de la mise en commun de ses efforts, ce qui mérite un grand respect et de chaleureux remerciements. Que l’été va sembler long, à attendre la nouvelle version de l’API Geoportail…

Poseidon Linux est une distribution basée sur Ubuntu spécialement packagée pour les sciences et le SIG. Faite par des Brésiliens océanographes, on y retrouve entre autres Grass, QGis, MapServer et p.mapper.

Je suis donc heureux de valoriser ce travail en proposant un mirroir à la distribution.

Site officiel en anglais (le lien ci-dessus étant réservé aux lusophones…)

Le groupe de recherche GeoSOA, mené par l’éminent Thierry Badard, nous signale la sortie de GeoKettle, que tout estivant ayant traversé le Lot pourra facilement traduire par GeoBouilloire, qui n’est pas destinée à éliminer les impuretés de vos données cartos, mais à réaliser du data-mining en 3 mn chrono !

C’est, pour reprendre les termes du communiqué, une version “spatialisée” de Pentaho Data Integration, outil ETL (Extract, Transform, Load) dédié à l’agrégation de sources de données différentes dans des entrepôts de données. GeoKettle intègre ainsi l’ensemble de la suite décisionnelle Pentaho, afin de donner une dimension géographique tant à la présentation du résultat des analyses (ça c’est facile) qu’à leur exploration elle-même. Pour faire court, la dimension géographique devient une des composantes analytiques, permettant par exemple de consolider les indicateurs en fonction d’entités administratives, ou d’énoncer des contraintes d’ordre spatial (distance par exemple) à leur composition.

Il semblerait donc qu’après le rapprochement entre CampToCamp et Talend, autre éditeur d’ETL OpenSource, le GéoDécisionnel ait le vent en poupe et constitue le nouveau territoire de la géomatique.

Via un message sur plusieurs listes et son blog personnel, Christopher Schmidt vient d’annoncer la publication de la version finale de la spécification GeoJSON, la version 1.0 donc.

Le GeoJSON est un format cartographique un peu particulier puisqu’il n’est pas destiné au stockage mais plutôt au transfert des données cartographiques entre un serveur et un client web exécutant du javascript. Car dans GeoJSON il y a JSON (JavaScript Object Notation) ! Hors de ce contexte donc, point de GeoJSON. L’un des principaux intérêts de ce format est de structurer naturellement son contenu en objets javascript un fois interprété par celui-ci. Par exemple :

{”type”: “FeatureCollection”, “features”: [{"type": "Feature","geometry": {"type" : "Point","coordinates" : [527904.26, 1844683.7]},”properties”: {”nom”:”PLACE ESQUIROL”,”adresse”:”15 PL ETIENNE ESQUIROL”,”numero”:”0102″,”bornes”:”18″}}]}

génère un objet fait de features, features dont les éléments ont une propriété nom, à laquelle on accède par features[i].properties["nom"], mais aussi une propriété geometry caractérisée par un type et un tableau de coordonnées.

Surtout, les protagonistes à l’oeuvre dans ces specifications ont tenu à l’enrichir suffisamment pour couvrir de très larges contextes d’utilisation. On retrouve donc des objets tels que les multi-lignes, multi-polygones, bounding boxes, ou même des systèmes de référence spatiaux qui peuvent être faits de liens http vers une définition externe (sur http://www.spatialreference.org par exemple).

Enfin, ce format a connu un succès rapide, dès avant sa formalisation complète. OGR l’intègre depuis quelques mois, OpenLayers et FeatureServer également, ça va de soi, mais on le retrouve aussi dans des logiciels propriétaires tels que FME de Safe Software. En tout, plus de vingt logiciels l’utilisent déjà sous une forme ou une autre.

Rien ne synthétise sans doute mieux les récentes évolutions de la néocartographie qui s’affranchit des frontières classiques du SIG que ce format, destiné à faire le lien entre la données carto “classique” et des contextes d’utilisation web de plus en plus diversifiés.