neogeo

Depuis ce matin sur les étals du geoweb frétille un nouveau specimen dénommé MapFish. Avec pour emblème une magnifique croquette de poisson pané (!) c’est sous ce nom que CartoWeb4, présenté en septembre au FOSS4G, se présente désormais, Cartoweb restant le nom de la branche 3, toujours maintenue depuis la sortie de la version 3.4 fin septembre.

Egalement sponsorisé par CampToCamp, il est vrai que MapFish n’a pas grand’chose à voir technologiquement avec Cartoweb, même si la finalité reste la mise en oeuvre rapide d’applications cartographiques. De fait, MapFish se veut être le chaînon manquant entre la qualité d’un client carto comme OpenLayers et la puissance de traitement qui fait une vraie application de cartographie en ligne. Ceci se fait en deux temps :

- d’une part un client web qui s’appuie sur OpenLayers tout en y juxtaposant des widgets graphiques issus du fascinant framework javascript extjs. On peut ainsi avoir une légende un peu plus raffinée que la simple liste des couches d’OpenLayers, même si le composant à encore des progrès à réaliser (distinction des types de géométries dans les cartouches par exemple). Parmi les widgets on trouve encore un controle de zooms prédéfinis, ou un outil de recherche. Plus complexe, un composant geostatistique permet de réaliser des discrétisations à la volée à partir d’un flux GeoJSON. Ou encore de réaliser des calculs d’itinéraires en se basant sur les fonctions PgRouting de PostGIS développée conjointement par CampToCamp et Orkney. Voilà pour la partie cliente.

- d’autre part, une architecture serveur basée sur le framework python Pylons qui implémente des modules nécessaires au bon fonctionnement des widgets clients, ainsi que le reste de l’application web si nécessaire.

La version présentée aujourd’hui, et annoncée sur la liste openlayers-dev, est une alpha-release. Certes cela se voit, et le récent remplacement du framework js Dojo par Extjs a laissé quelques traces. Mais comment ne pas saluer une initiative qui :

- rappelle qu’une application cartographique sur le web ce n’est pas qu’un tuilage rapide, c’est aussi des données, l’accès à leurs attributs et à la modification de leur représentation.
- s’appuie sur des bibliothèques existantes qui ont fait leurs preuves dans leur domaine (OL, extJs, Pylons), sans chercher à réinventer la roue. C’est du KISS très DRY !
- s’ingénie à fédérer les énergies, non pas en proposant un environnement complet et fermé, mais plutôt une démarche, une dynamique et une boîte à outils.

Voici donc un petit poisson qui a toutes ses chances de devenir grand.

Mapstraction intègre désormais un 9ème provider cartographique qui n’est autre qu’… OpenLayers ! Bizarre quand on sait qu’OpenLayers n’est pas un producteur de données mais un client multi-sources, comme Mapstraction justement. Reprenons…

Mapstraction est une classe javascript d’abstraction (d’où le nom, les plus perspicaces l’auront remarqué) des principales API cartos, permettant à partir d’un code unique de manipuler les contenus Google, Yahoo, Microsoft, Map24 etc. Par exemple, pour cadrer la vue sur un endroit particulier, Mapstraction utilise la fonction setCenterAndZoom quelque soit l’API utilisée. C’est la librairie d’abstraction qui traduit en commandes spécifiques à l’API pour vous. Pratique, même si ça réduit forcément l’utilisation de la librairie au dénominateur commun des APIs prises en charge.

OpenLayers, bien connu des lecteurs de ce blog, est une API javascript de cartographie disposant de nombreux types de connexions vers des sources de données (GoogleMaps, YahooMaps, mais aussi des flux GeoRSS, GML, GeoJSON). OpenLayers n’utilise pas les fonctionnalités des API externes, mais au contraire dispose de ses propres contrôles et commandes, ainsi que de couches personnalisées (VectorLayer par exemple).

Mapstraction avait déjà intégré OpenStreetMap, qui n’a pas d’API propre, et devait donc être chargée via l’API Google…

Au final, l’intégration d’OL (qui n’est pas un fournisseur de données) dans Mapstraction se résume à l’utilisation des controles OL dans l’interface Mapstraction, tout en permettant de ne plus passer par l’API Google pour visualiser les données OSM qui sont la couche par défaut chargée avec OL.

Donc, une API qui se sert des contrôles d’une autre API pour manipuler les données d’une troisième, ça donne quand-même un peu le vertige.

via HighEarthOrbit

Grâce à un joli mash-up d’une foultitude de sources différentes (MODIS, EO1 mais aussi OSM et Filckr) une application OpenLayers permet de suivre le front des incendies en Californie et de constater l’ampleur des destructions. Un résultat séduisant, qui démontre l’intérêt de la syndication de données géographiques mais dans lequel une bonne légende ne serait cependant pas superflue.

C’est avec un certain retard sur le planning initial que l’équipe de QGis vient d’annoncer la sortie de la nouvelle version 0.9.0., nom de code Ganymède, avec, entre autres, au menu :

- L’intégration de python qui permet d’écrire des plugins dans ce langage mais aussi d’utiliser les modules Qgis dans un programme Python
- L’ajout de nouveaux outils Grass
- Une amélioration des possibilités de rendu des cartes, avec notamment la possibilité de faire des classifications par quantile, plus utile que les seules amplitudes jusqu’alors disponibles. Pour les autres méthode (Standard, Moyennes emboîtées, Lognormale, Géométrique, toutes bien pratiques pour classifier des données statistiques), on attendra encore un peu…
- Une refonte des librairies principales, qui améliore sensiblement les performances, notamment dans la manipulation de lourdes couches de données.

Côté installation, de nombreux paquetages sont déjà prêts (Ubuntu, Debian, OpenSuse, Mac OS X et Windows), disponibles ici.

J’ai réalisé l’installation à partir des sources, sans pouvoir intégrer le support Python du fait d’une erreur à la compilation. Le cmake, qui remplace le configure, recherche les installations de python, postgresql, grass et autres. Si le compte-rendu du cmake indique qu’il n’a pas trouvé un composant que vous savez être installé sur le système, un petit tour du côté des fichiers du répertoire cmake peut vous aider : FindGEOS, FindGRASS, FindPostgres, FindProj peuvent être édités manuellement de manière à aider le cmake à retrouver les librairies nécessaires. Au final, l’install est très propre, de même que le uninstall. Par contre, le module Grass n’a pas été installé, malgré la prise en compte des librairies grass-dev pour le make.

Après quelques tests, la véritable plus-value de cette édition se situe du côté des performances, nettement améliorées dans la manipulation de gros fichiers, pour peu qu’on bâtisse un index spatial de la couche en question. Le module de géoréférencement gagne aussi en ergonomie.

Bravo à toute l’équipe de Qgis pour cette nouvelle version.

Ce n’est pas vraiment un sujet “geo”, mais comment résister à transmettre cette info amusante glanée sur le site de l’Expansion : quand on lui demande de traduire “Sarkozy” du français vers l’anglais, l‘outil linguistique de Google vous répond : “Blair”, tandis que “Sarkozy Nicolas” devient “Nicolas Bush”, et “Cecilia Sarkozy” donne “Cecilia Bush” alors qu’à l’inverse “Sarkozy cecilia” vous renvoie “Cecilia Blair”. Google a peut-être la réponse aux questions qui agitent la presse française depuis quelques semaines.

P.S. : Google a semble-t-il corrigé légèrement son outil de traduction pendant la rédaction de cet article (ils devaient craindre la diffusion de cette info sur un canal aussi populaire). “Sarkozy” est ok, mais sans la majuscule c’est toujours aussi rigolo !