Entre le 22 et le 25 avril, à l’occasion de la « Semaine Internationale des Applications Spatiales« , ou Toulouse Space Show pour les intimes, une application réalisée par Neogeo pour le compte du Grand Toulouse va être présentée au public sur le stand du Grand Toulouse. Cette application est une maquette opérationnelle de ce qui deviendra la plate-forme Toulouse Open de mutualisation et de partage de données.

Vue de l’interface

Pour la réaliser, dans un délai très serré, j’ai mis en oeuvre ce que j’estime être le meilleur des technologies OpenSource : un back-office en python, s’appuyant sur le framework Django couplé à une (petite) base de données PostgreSQL, un serveur WMS/WFS avec MapServer, une pincée de GDAL/OGR pour la manipulation des données, un serveur de cache avec TileCache, et bien sûr côté client la dernière version d’OpenLayers et quelques composants MooTools pour les menus. L’intérêt principal de cette architecture est le faible couplage des éléments entre eux. En utilisant des standard d’échange (WMS, XML, JSON…) chaque élément peut être remplacé facilement par un équivalent pour peu qu’il propose les mêmes entrées et sorties. Les données cartographiques sont directement exploitées dans leur format originel, en MapInfo .TAB ou en ECW, afin de faciliter les tâches de mise à jour, qui se font ainsi par simple remplacement des fichiers.

Au niveau fonctionnel, l’application propose visualisation, téléchargement, reprojection, changement de format sur une cinquantaine de couches de données différentes, dont une orthophotographie à 12.5 cm, le parcellaire cadastral, un Modèle Numérique d’Elévation (avec export 3D vers GoogleEarth !) le tout filtré selon le profil de l’utilisateur et les territoires qui lui sont ouverts. Quelqu’un peut ainsi avoir le droit de « voir » une couche sur l’ensemble de l’agglomération, mais ne pouvoir en télécharger qu’une partie. Les utilisateurs peuvent aussi intégrer des ressources WMS externes, ou uploader leurs propres données vers la plateforme. Après validation par l’administrateur, celles-ci deviennent alors visibles par tous.

Le principal défi a été de proposer quelque chose de parfaitement opérationnel en un délai très bref (moins de 30 jours). Pour le relever, le recours à Django s’est révélé être un choix particulièrement judicieux tant la rapidité de développement dans cet environnement et la stabilité du résultat sont impressionnantes. J’en ai par contre peu utilisé les templates, afin de privilégier l’évolutivité et l’autonomie du client. Ainsi la plupart des échanges se font en JSON, notamment l’initialisation de la liste des couches à intégrer dans OpenLayer.
Autre gros avantages de l’utilisation de Django, c’est la constitution quasi-automatique d’un module d’administration très complet. A partir de quelques formulaires, l’administrateur peut ajouter des couches, tout en spécifiant leurs conditions d’accès (droits utilisateurs en visualisation/export), d’affichage (AGG ou PNG, tuilage ou pas, niveau de transparence par défaut…) ou encore le contenu des métadonnées (qui se basent sur template ISO-19139 minimaliste).

Le but à moyen terme, après avoir décontextualisé certains aspects liés aux demandes spécifiques du Grand Toulouse, est aussi de placer cette solution en OpenSource, afin de pouvoir en faire profiter le plus grand nombre. A suivre donc. Si vous passez par Toulouse cette semaine, venez faire un tour du côté du centre des congrès Pierre Baudis, ou n’hésitez pas à me contacter directement pour toute information complémentaire.

neogeo fait son show…
Étiqueté avec :                    

4 pesnées sur “neogeo fait son show…

  • 22 avril 2008 à 8:52
    Permalien

    Bravo, cela semble très intéressant et prometteur.

    As-tu utilisé tilecache pour l’ortho ? si oui, tu stockes en quel format les images ?

    Répondre
  • 22 avril 2008 à 9:09
    Permalien

    Oui. Les images sont stockées en JPEG. Au dernier niveau de zoom (1/250e environ) il y a plus de 1400000 images, et une légère baisse de performance sur les temps d’accès aux tuiles, due à la profondeur de l’arborescence. Le serveur n’est pas particulièrement optimisé pour servir des fichiers. Je pense qu’une configuration en stripping avec des disques rapides et un ReiserFS pourrait améliorer la chose. De même que je veux tester LightHttpd avec Tilecache et python en FastCGI pour voir ce que ça donne.

    Répondre
  • 15 décembre 2008 à 12:44
    Permalien

    Salut Guillaume! Premièrement, je veux te féliciter pour ton magnifique blog et continue comme ça! Parlons de choses sérieuse 😛 dis moi est ce que tu as essayé cette configuration: « LightHttpd avec Tilecache et python en FastCGI »? Si oui, qu’est ce que tu en penses et est ce que tu as noté une diférence aux niveaux des performances? (peux tu faire un petit article comment installer tilecache et fcgi pour linux?) Car, j’ai vu sur un de tes articles qui redireccionait à ce link: http://presentations.opengeo.org/2008_FOSS4G/WebMapServerPerformance-FOSS4G2008.pdf (résultat des performances entre geoserver et mapserver) qui dit que mapserver doit être configuré avec fastcgi pour obtenir des meilleurs résultats (3 fois!)… J’attendrais une réponse de ta part… Merci!

    Répondre
  • 15 décembre 2008 à 12:49
    Permalien

    Oui, j’ai fait ce genre de tests. En gros, le plus rapide avec tilecache reste Apache + mod_python, d’autant plus qu’il supporte mieux la montée en charge. Par contre, pour les meilleures performances, on peut outrepasser tilecache et brancher directement Lightttpd sur le répertoire des tuiles, et utiliser un layer de type Tilecache dans OpenLayers, ou faire un mécanisme de calcul des adresses des images sur un autre client, ce qui n’est pas vraiment compliqué. Contacte-moi directement pour plus de détails ! Et merci pour ces encouragements !

    Répondre

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *