neogeo

L’intérêt de tuiler un jeu de données raster, c’est-à-dire de préparer des imagettes multi-échelles qui seront exploitées nativement dans une application de webmapping n’est plus à démontrer. Dans le cadre du Google Summer of Code 2008, Klokan Petr Pridal vient d’ajouter un nouveau module de ce type aux outils GDAL : gdal2tiles.

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

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…

Joli recueil d’astuces diverses pour la manipulation de données vecteur et raster sur le blog GFOSS.

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.

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.