Archive pour le mot-clef ‘Python’

Sortie officielle de QGis 0.9.0

Vendredi 26 octobre 2007

Qgis 0.9.0. Ganymède

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.

Qu’est-ce qu’on parle au FOSS4G ?

Dimanche 30 septembre 2007

Après une semaine fort excitante passée à suivre les conférences et ateliers du FOSS4G2007, je profite du temps épouvantable qui m’oblige à rester cloîtré dans la salle commune du Whalers on the Point Guesthouse de Tofino et m’empêche de sortir ma planche de surf pour livrer quelques réflexions sur ce que j’ai pu apprendre ces derniers jours.

Premièrement, concernant les langages de développement, Python fait réellement l’événement puisque c’est le langage utilisé dans les applications les plus pointues et récentes présentées au FOSS. Citons TileCache, FeatureServer, Cartoweb 4, Shapely, GeoDjango, tous ces projets ont privilégié le python en raison de sa stabilité et de son extraordinaire versatilité (au sens anglo-saxon du terme). Java est toujours là, structurant des projets déjà reconnus (uDIG) ou en devenir (un ETL OpenSource présenté par Talend et CampToCamp). Par contre le PHP ne fait plus partie des langages en vue. Encore utilisé largement, s’il apparaît notamment dans des retours d’expérience il n’est plus le fer de lance du développement en WebMapping, dont l’architecture s’oriente vers des bibliothèques puissantes écrites en C, intégrées dans des wrappers python. Cela a été rendu possible par l’intégration de Ctypes dans python 2.5 qui permet l’appel direct de bibliothèques C sans passer par une fastidieuse interface SWIG.
Du côté des geeks, Charlie Savage met désormais en oeuvre du GeoRuby pour faire tourner son MapBuzz, et à créé une liste dédiée au webmapping dans RubyOnRails, que rien ne semble arrêter !

Tout ceci produit des applications plus puissantes, plus stables et plus robustes, notamment dans la gestion de la mémoire et de la montée en charge. Des bibliothèques aussi cruciales que Geos, Gdal, Ogr, Proj peuvent ainsi être utilisées au coeur même d’une application web dont les scripts python constituent une double interface entre les requêtes utilisateurs d’un côté et la manipulation des données à un bas niveau de l’autre. Ceci devrait faire émerger des frameworks cartographiques avec de véritables fonctions d’administration des données, qui sont encore des aspects trop négligés par le monde OpenSource.

GeoDjango devrait montrer la voie puisque ses concepteurs ont montré un vif intérêt à l’idée d’intégrer des notions de règles de topologies à la gestion des tables.

Utilisation de AtomPub

Vendredi 7 septembre 2007

En complément du précédent article, j’ai trouvé deux applications cartographiques utilisant le format AtomPub dans un contexte géographique (avec des balises georss décrivant les géométries) :

Le déjà célèbre MapBuzz, dans lequel les objets créés par les utilisateurs et affichés en mode vectoriel sont issus d’un flux AtomPub. Il a l’avantage d’illustrer mon précédent propos sur l’architecture REST : les trois modes d’affichages différents des objets saisis par les utilisateurs (géométries sur les cartes, info-bulle au survol, fichier complète au clic) sont trois représentations différentes (chacune avec plus ou moins d’attributs) d’une même ressource.

Et un prototype fait par Metacarta intégrant la prise en charge de AtomPub dans OpenLayers et s’appuyant sur FeatureServer, sorte de serveur WFS en Python à la différence que les formats de sortie sont variés (JSON, GeoRSS, KML, GML, HTML ou OSM, le format OpenStreetMap). C’est à l’heure actuelle ce que j’ai pu trouver de plus avancé sur la question.

Heureuse initiative

Vendredi 27 juillet 2007

Chris Schmidt et Howard Butler viennent de mettre en ligne un petit site web qui référence les projections EPSG et des projections personnelles, chargées par les utilisateurs du site. Rien de bien excitant ? Et bien si, car ils mettent aussi à disposition des webservices de publication des définitions des projections, aux formats GML, Proj4, EsriWKT, OGC WKT, USGS et JSON. Grâce à une architecture RESTFull, les définitions (ou les ressources, pour utiliser la terminologie REST) sont accessibles par un simple appel d’URL :

http://spatialreference.org/ref/epsg/27572/Proj4 renvoie ainsi un flux texte correspondant au Lambert II structuré selon la norme Proj4.

L’intérêt ? Pouvoir à terme intégrer ces URL en lieu et place des définitions elles-mêmes dans l’utilisation de GDAL ou de MapServer par exemple. Donc un moyen simple d’accéder à des définitions maintenues à jour, sans avoir à mettre les mains dans les fichiers EPSG de la librairie proj, ainsi que de créer ou d’utiliser des projections non définies par l’EPSG.

Autre intérêt du site : bâti autour du framework Django, donc écrit en Python, avec une architecture REST, il montre ce que ces technologies peuvent apporter en termes de simplicité et de flexibilité dans la mise en oeuvre de webservices cartographiques.