Si vous cherchez une brique logicielle côté client pour communiquer avec un serveur CSW et si vous aimez Python, vous pouvez essayer OWSLib (cf. ici).

Qu’est-ce que GeoDjango ?

C’est une extension de Django (ça existe même en français) destinée à gérer les données géographique. OK, mais on n’avance pas là. Qu’est-ce que Django ? Un framework web en Python sous licence OpenSource BSD qui permet de structurer un site web au travers d’une structure Modele – Vue – Template très rapidement. Les modèles sont les tables de votre BD, mais en mode objet; les vues sont les actions et les manipulations diverses que vous voulez effectuer, et les templates sont des modèles de mise en page HTML destinés à présenter les résultats des vues. De plus, Django génère automatiquement un module d’administration des Modèles (des tables donc), qui permet facilement de CRUDer (lire, retrouver, mettre à jour, supprimer) le contenu de votre SI. Un peu comme PhpMyAdmin, mais en mieux !

A ceci, GeoDjango ajoute donc la dimension spatiale, tout comme PostGIS ajoute la dimension spatiale à PostgreSQL. Cela peut fonctionner avec PostgreSQL, MySQL ou Oracle, mais pour ces deux derniers toutes les fonctions ne sont pas encore intégrées (voir la table de compatibilité). Vous obtenez alors des tables spatiales référencées en tant que modèles, et manipuler les objets géométriques (intersection, union, extent, aire…). Ceci grâce au portage dans le code de GeoDjango des librairies bien connues GDAL et GEOS.

Depuis août 2008, GeoDjango fait partie intégrante de Django, tout en gardant sa propre doc et son wiki.

KiCéKiLaFé ?

Justin Bronn, qui va bientôt passer ses examens pour devenir District Attorney (procureur…). A l’occasion de la mise en place de son application Houston Crime Maps, il a choisi Django et y a progressivement intégré la dimension spatiale dont il avait besoin.

Et on peut voir ça où ?

Une petite application de démonstration est accessible ici. Elle a été construite par Dane Springmeyer, Josh Livni et  Christopher Schmidt. Vous pouvez utiliser le login/passwd geo/geo pour vous connecter au module d’administration. Surprise, les données géographiques sont éditables grâce à l’intégration d’OpenLayers dans la page et de votre objet en mode vectoriel !

Sinon la présentation faite par Justin Bronn au Forum Texas GIS en octobre 2008 donne aussi quelques liens.

Ok, c’est beau, mais il y a de la doc ?

Oui, aussi. D’abord un tutoriel : http://geodjango.org/docs/tutorial.html#geographic-data

Un kit d’installation : http://geodjango.org/docs/install.html

Les spécificités des modèles GeoDjango (qui surclassent les modèles standard Django)

La DB-API, qui intègre les opérateurs spatiaux.

et plein d’autres trucs (sur GDAL, GEOS…)

et enfin, un groupe de discussion !

et sinon, tu en penses quoi ?

Je ne suis pas forcément très objectif, mais je suis un inconditionnel de Django en général et de GeoDjango en particulier. Ce que j’apprécie le plus est de pouvoir stocker les données géographiques sous PostGIS et de les manipuler ensuite pour les envoyer vers le client en GeoJSON par exemple après les avoir reprojetées ou simplifiées. Le GeoAdmin, et la capacité d’édition de la donnée qu’il apporte, même si elle est imparfaite, est aussi très agréable.

La prise en main n’est pas très difficile. Les tutoriels de Django et GeoDjango sont très accessibles, et la vitesse à laquelle on arrive à des résultats concrets donne vite envie d’aller plus loin.

Son intérêt principal est de pouvoir exploiter directement une image existante (ECW, TIFF, MrSid, JPEG, JPEG2000 et PNG) sans passer par le relai d’un serveur WMS par exemple comme TileCache. Une arborescence est alors créée répondant aux principes du TMS (Tile Mapping Service). Publiée dans un répertoire web, elle est alors directement exploitable par les client TMS tels qu’OpenLayers.

Mais ce n’est pas tout. Klokan a également inclus des options spécifiques à la création de tuiles pour GoogleMaps (en projection sphérique Mercator donc) ou GoogleEarth (en WGS 84). Qui plus est, l’application génère automatiquement, pour peu qu’on lui demande, des fichiers html pour une mise en ligne immédiate. Simple mais efficace, même dans GoogleEarth qui exploite les SuperOverlays déjà disponible avec TileCache !

Mais ce n’est pas tout ! Klokan a également pensé à ceux d’entre nous qui ne sont jamais arrivés à faire une simple conversion ogr2ogr de Shapefile en MapInfo… Il prépare MapTiler, une interface  graphique pilotant gdal2tiles pour générer ses tuiles en faisant clic clic clic ! Si c’est pas gentil ça !

Pour les autres, voici les quelques options glanées dans la documentation :

gdal2tiles.py [-title "Title"] [-publishurl http://yourserver/dir/]
              [-nogooglemaps] [-noopenlayers] [-nokml]
              [-googlemapskey KEY] [-forcekml] [-v]
               input_file [output_dir]
-title : le titre pour les metadata xml, les pages web et le KML
-publishurl : URL de publication du répertoire contenant les tuiles
-nogooglemaps : pas de génération de page GoogleMaps
-noopenlayers : pas de génération de page OpenLayers
-nokml : pas de génération de KML
-googlemapskey : votre clé GM pour l'utilisation de la page html GoogleMaps
-forcekml : forcer la génération du KML
-v : mode verbeux.
input_file : fichier à traiter
output_dir : répertoire de création des tuiles

Il faut bien noter que gdal2tiles.py est un module Python, et que GDAL doit donc avoir été compilé avec l’option –enable-python.

Source : gdal-dev mailing list

1. L’installation

Simplissime ! Récupérez une archive des sources sur le site de tilecache (http://www.tilecache.org/), et décompressez-la dans un répertoire publié sur le web (/tilecache dans ce qui suit).

Autorisez l’exécution des cgi pour ce répertoire :

<Directory /usr/local/apache2/htdocs/tilecache>
AddHandler cgi-script .cgi
Options +ExecCGI
</Directory>

Editez le fichier tilecache.cfg et spécifiez un répertoire de stockage des dalles, par exemple :

base=/usr/local/apache2/htdocs/tileFolder

(NB : ce répertoire doit exister et être accessible en écriture à l’utilisateur apache).

Vous pouvez déjà tester en chargeant la page http://nom_du_serveur/tilecache/. Vous devriez voir apparaître une interface OpenLayers avec une carte du monde. Vérifiez le contenu de votre répertoire de stockage, vous devriez y voir un sous-répertoire « basic », nom de la couche WMS chargée par défaut, contenant des sous-répertoires numérotés.

Arrivé là, vous êtes déjà en train de mettre en cache les couches WMS que vous exploitez. Le reste n’est donc plus qu’une question d’optimisation.

1. La configuration des ressources WMS.

Vous avez sans doute d’autres données à exploiter que les données proposées par défaut. Pour cela, il faut rajouter ces entrées dans le fichier tilecache.cfg, en commençant par le nom de la ressource (layername) entre crochets. A noter que le nom que vous donnez à la ressource est complètement libre, mais que c’est lui que vous devrez utiliser lors des appels à TileCache, depuis OpenLayers par exemple. Voici un exemple complet de configuration d’une ressource :

[geosignal]
type=WMS
url=http://www.geosignal.org/cgi-bin/wmsmap
bbox=-50000,1200000,1400000,2700000
extent_type=loose
extension=png
layers=RASTER4000K,RASTER1000K,RASTER500K,RASTER250K,\
RASTER100K,RASTER50K,RASTER25K,RASTER5K
resolutions=2116.666666667,1058.333333333,529.166666667,\
264.583333333,132.291666667,66.145833333,26.458333333,\
13.229166668,6.614583334,2.645833334,1.322916667
levels=11
srs=EPSG:27572

La pluplart des paramètres sont facilement compréhensibles. Après la bbox cependant, on trouve un extent_type=loose. Il sert à autoriser la création de dalles en dehors de la bbox. Pratique pour éviter les dalles roses dans OpenLayers, quand l’étendue de la carte est plus grande que celle de votre ressource. L’omettre pour forcer les requêtes à se situer dans la bbox. Quant aux résolutions, c’est une manière d’exprimer les échelles. On peut les calculer assez facilement (hmmm…) : les dalles par défaut font 256×256 px. Si les images issues du serveur WMS sont en 96 dpi, chaque dalle fera donc (256/96) = 2,666666667 pouces, soit 2,666666667 x 2.54 = 6,773333333 cm. Au 100000e, cela représente donc 6773,333333 mètres, ce qui ramène à (6773,333333/256) = 26,458333333 m/pixel. La résolution pour le 100000e est donc de 26,45833333, et on peut alors facilement calculer les autres par simple péréquation.

Une autre option peut s’avérer utile, c’est metaTile=true. Elle permet d’envoyer des requêtes sur de larges extents, qui sont ensuite redécoupées en 256 x 256. C’est pratique à plus d’un titre. D’une part c’est souvent plus rapide de faire une requête que 25 (la metaTile fait 5 x 5 dalles de base par défaut), même si l’image est plus grosse. D’autre part ça diminue le problème du chevauchement des labels entre dalles contigües, puisque cet effet de bord n’apparaît plus désormais qu’en frontières des grandes tuiles, donc 5 fois moins souvent (20 faces externes au lieu de 100). Elle nécessite cependant l’installation (si ce n’est pas déjà le cas) de la librairie Image de Python (http://www.pythonware.com/products/pil/) qui fait le travail de découpe. Malheureusement, elle ne gère pas les PNG entrelacés, et cette option ne pourra donc pas fonctionner si la ressource WMS diffuse ses images dans ce format. Pour MapServer, il faut ajouter un FORMATOPTION « INTERLACE=OFF » dans la définition de l’outputformat PNG.

1. Optimisation 1, utiliser mod_python.

TileCache est un programme en python, configuré par défaut pour être exécuté en mode cgi, c’est-à-dire qu’Apache charge à chaque requête l’exécutable python qui traite le fichier tilecache.cgi. C’est un peu lent. Il vaut mieux charger python dans Apache avec mod_python (à activer dans la liste des modules du httpd.conf, ou à compiler et installer directement) car le fichier est alors directement interprété par l’extension python d’Apache, résidente en mémoire.

Donc ajoutez à votre fichier httpd.conf :

LoadModule python_module modules/mod_python.so

Pas de tilecache.py dans votre répertoire tilecache ? Il suffit en fait de renommer le fichier tilecache.cgi en .py . Il faut par contre aussi adapter votre httpd.conf. La configuration du répertoire tilecache devient :

<Directory /usr/local/apache2/htdocs/tilecache>
AddHandler python-program .py
PythonHandler TileCache.Service
PythonOption TileCacheConfig /usr/local/apache2/htdocs/tilecache/tilecache.cfg
</Directory>

Petite précaution : maintenant que python et tilecache.py sont résidents en mémoire, il vous faudra redémarrer Apache à chaque modification du fichier de configuration de TileCache, qui est devenu une sorte de prolongement d’Apache… Il vaut donc mieux avoir bien configuré toutes ses ressources avant cette étape.

Comparez à présent le fonctionnement de votre TileCache, les performances devraient être sensiblement supérieures.

1. Optimisation 2, pré-remplir le cache.

L’intérêt de cette étape dépend du nombre d’échelles de vos données WMS, ainsi que de leur utilisation. Inutile de pré-générer la France au 5000e si peu d’utilisateurs s’en servent. Mais il est souvent agréable d’avoir les 2-3 premiers niveaux pré-générés. Pour ce faire, utilisez le petit programme tilecache_seed.py ainsi :

python tilecache_seed.py ‘url_du_serveur_WMS’ nom_de_la_ressource niveau_de_depart niveau_de_fin

ce qui donne pour notre ressource définie plus haut :

python tilecache_seed.py ‘http://www.geosignal.org/cgi-bin/wmsmap’ geosignal 0 2

Cela générera toutes les dalles pour les niveaux 0,1 et 2 de la ressource « geosignal », soit les trois premières résolutions décrites dans le fichier tilecache.cfg. Il faut bien veiller à utliser le même nom de ressource que dans le tilecache.cfg.

Une fois la pré-génération réalisée, l’affichage sur ces premiers niveaux devrait être beaucoup plus fluide.

1. Optimisation 3, forcer le cache client.

Vous remarquerez toutefois qu’en revenant sur un niveau de zoom déjà consulté, les images sont le plus souvent rechargées depuis le serveur. Dommage puisqu’elles sont déjà dans le cache client. Mais celui-ci (le navigateur) ne sait pas qu’elles sont encore valides. Il faut donc l’aider à le savoir. Pour ce faire, il faut utiliser le module Apache mod_expires. Il n’est pas chargé par défaut, mais peut l’être facilement en dé-commentant ou ajoutant un LoadModule mod_expires dans le httpd.conf si vous avez un version packagée. Par contre, si vous avez compilé Apache vous-même, il faudra le recompiler avec les options –enable-headers –enable-expires. Oui, j’aurais pu le dire avant… Mais Apache est votre ami, lors d’une réinstallation, le make install n’écrase que les exécutables et préserve le fichier de configuration, les modules et le contenu de cgi-bin. Donc tout va bien.

Une fois l’installation réalisée, il faut régler la durée de mise en cache dans la configuration Apache du répertoire tilecache. Rééditez donc à nouveau le httpd.conf et ajoutez dans la section Directory concernant tilecache :

ExpiresActive on
ExpiresDefault « access plus 6 months »

La durée de mise en cache peut se régler finement. Voir la documentation du module Expires pour cela. Tout dépend de la durée de vie des données sources. Si elles sont soumises à une mise à jour quotidienne, on pourra se contenter d’un ExpiresDefault « access plus 6 hours » . A noter que ceci n’a aucune incidence sur le contenu du cache serveur. Donc si les données sont mises à jour quotidiennement, il faut également purger le cache serveur tous les jours !

A l’issue de cette dernière étape, comment dire, après quelques allers-retours entre niveaux de zooms différents, l’affichage devient quasi-instantané !

1. Optimisation 4, simuler plusieurs serveurs.

La plupart des navigateurs n’effectuent pas plus de deux requêtes simultanées sur un même serveur, mais peuvent par contre en effectuer beaucoup plus vers plusieurs serveurs. En déclarant auprès de votre hébergeur de nouveaux noms de domaines (data1.myserveur.com, data2.myserveur.com, data3.myserveur.com…) pointant tous vers la même IP, les navigateurs pourront alors charger les dalles beaucoup plus vite, pour peu que l’application web que vous utilisez prenne en charge ce genre de requête. Avec OpenLayers il suffit de déclarer non plus une URL, mais un tableau d’URL :

wms_sigma = new OpenLayers.Layer.WMS( "TIGER",
["http://sigma4.openplans.org/tilecache-1.3/tilecache.py?",
"http://sigma3.openplans.org/tilecache-1.3/tilecache.py?",
"http://sigma2.openplans.org/tilecache-1.3/tilecache.py?",
"http://sigma1.openplans.org/tilecache-1.3/tilecache.py?"],
{layers: 'sigma' }, {numZoomLevels: 17});

Si avec tout ça vous allez encore moins vite que GoogleMaps, il ne vous reste plus qu’à acheter un serveur avec 36 Go de RAM et charger votre cache directement dedans. Car TileCache en est également capable !

Version PDF.

Refinery (with ctypes): 4972288.61 usec/pass

Ogre (Cython/Pyrex) : 682301.81 usec/pass

ogr.py (old-school bindings) : 9183181.72 usec/pass

Le coup du old-school bindings en a énervé quelques-uns, qui ont fait remarquer qu’il avait utilisé une vieille version d’OGR. Trop facile ! Mais avec la nouvelle, même si celle-ci est 15 fois plus rapide que la précédente (bravo Howard), Cython garde le dessus :

Refinery (with ctypes)
4994133.40 usec/pass

Ogre (Cython/Pyrex)
593522.91 usec/pass

ogr.py (next generation bindings)
594103.50 usec/pass

De cette implémentation efficace avec Cython, Sean a fait un premier prototype, WordMill. Quelques exemples permettent de se rendre compte de la souplesse du programme. La définition d’un workspace (répertoire de données) suffit à permettre l’accès à toutes les sources de données supportées par OGR qui s’y trouvent, et de parcourir ainsi les fichiers et leur contenu de manière transparente quant à leur format, sans appel à un driver particulier et à travers des structures simples. On peut ainsi accéder aux données, les interroger, les filtrer très efficacement. De la belle ouvrage, doublée d’une installation simplissime. Chapeau Sean !

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.

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.

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.

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.

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.