neogeo

L’API du GéoPortail est disponible depuis la semaine dernière dans sa version Bêta. Généralement, une version Bêta sert à tester un produit pour déterminer sa capacité à répondre aux besoins des développeurs et des utilisateurs. Sauf que les conditions générales d’utilisation introduisent les restrictions suivantes :

• la taille de la fenêtre cartographique ne doit pas dépasser 400 x 400 pixels (autant dire du webmapping du siècle dernier). C’est tellement petit que même dans les pages d’exemple ils n’ont pas osé respecter cette clause, la carte y est en 900 x 500. Même la mini-carte est en 500 x 400 !
• le nombre de pages vues ne doit pas dépasser 100 / jour ou le nombre de tuiles chargées ne doit pas dépasser 10000/j. Rien qu’avec les fautes de frappe et les petites optimisations liées à la conception d’une page carto, il va me falloir 1 semaine pour faire quelquechose de potable.

Ensuite, l’API est en fait une surcharge d’OpenLayers. Comme ses collègues britanniques de l’Ordnance Survey, l’IGN a donc choisi cette API OpenSource (licence BSD) à la communauté dynamique pour créer un produit complètement propriétaire. La documentation pointe d’ailleurs directement vers les pages d’OpenLayers pour les composants “standard”. Sauf que sans mention de la version d’OL utilisée, on risque rapidement de se retrouver avec une documentation déconnectée de la version utilisée (une “fork” comme on dit dans le Lot).

Plus rigolo encore sont les “Obligations des Bêta-Testeurs”. On a déjà vu qu’ils avaient juste le droit de montrer une fenêtre de 400 x 400 à quelques membres de leur famille, mais pour pouvoir bénéficier de ce privilège, il faut quand-même respecter quelques règles de bonne conduite (c’est moi qui souligne le plus beau passage) : “A aucun moment vous ne devez effectuer (ou sciemment laisser faire) une utilisation illégale, trompeuse ou mensongère de l’API bêta ou de données du Géoportail, y compris, mais sans exhaustivité, le dénigrement de l’IGN ou du Géoportail ou d’autres pratiques qui peuvent être préjudiciables à l’IGN ou au Géoportail.” Donc pas de banderole genre “Riquiqui, limité, fermé - Bienvenue à l’API Géoportail !” au prochain géo-événement ok ?

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.

Petite mise à jour de la carte de localisation des stations de Vélôs de Toulouse aujourd’hui, avec quelques améliorations :

• utilisation de tilecache pour les rasters
• récupération des données de disponibilité des vélos en temps réel depuis le webservice de l’application de la ville

Et après ? au programme une version dédiée téléphone mobile. Parce que c’est bien de connaître la disponibilité depuis chez soi sur internet, mais c’est mieux de pouvoir la consulter quand on cherche un vélo dans la rue ! Les beta-testeurs sont les bienvenus.

Au chapître des nouveautés webmapping, PortailSIG nous fait découvrir aujourd’hui deux superbes applications :

• Le PLU du Grand Lyon, sous OpenLayers, fluide et esthétique
• Le nouveau portail INSEE des statistiques locales, avec une partie cartographique en Flash(Géoclip). Excellent outil de géostatistiques, d’une grande rigueur et d’une grande richesse fonctionnelle et surtout impressionnante liste de données consultables ET téléchargeables. Dommage que le plugin Flash ne puisse afficher une France communale en entier, car ce niveau d’analyse garde toute sa pertinence à petite échelle.

L’Ordnance Survey, agence géographique nationale britannique, dévoilera début 2008 OSOpenSpace, une application de cartographie couvrant l’Angleterre, l’Ecosse et le Pays de Galles et disposant d’une API ouverte permettant de créer ses propres applications à partir des données de l’agence :

• Les contours des îles britanniques
• la MiniScale ® :
• le Raster couleur au 250000e :
• le Raster couleur au 50000e :
• L’OSStreetView ® au 10000e :

Les conditions d’utilisation sont cependant assez restrictives. Seul un usage non-commercial est autorisé (’There can be NO FORM of financial gain’, ce qui interdit par exemple le placement de publicités sur la page), le nombre de dalles quotidiennes est limité à 30000 et le nombre de recherches d’adresses à 1000 par jour. 30000 dalles par jour, ce n’est pas beaucoup. Sur une carte simple de 3 x 3 dalles, cela ne fait que 3333 cartes que l’on peut proposer, soit 10 cartes (incluant les zooms etc) à 333 utilisateurs différents. Ca reste sufifisant pour un site tel que celui-ci (sic), mais très handicapant pour quiconque visant une large audience. Le FAQ indique benoîtement qu’on peut les contacter en cas de dépassement des quotas ! Sans doute pour évoquer la répartition du business !

Le plus amusant est qu’on apprend aujourd’hui via la liste de diffusion d’OpenLayers que cet OpenSpace est bâti sur la célèbre API OpenSource de cartographie. Dans un mail de remerciements à l’équipe de développeurs d’OpenLayers, l’OrdnanceSurvey indique qu’ils ont pris le code OpenLayers tel quel, puis y ont ajouté quelques nouvelles fonctionnalités (meilleur support des marqueurs par exemple, ou support amélioré des projections britanniques).

Donc voilà des gens qui utilisent une API complètement OpenSource, en brident l’utilisation pour ne pas qu’on utilise trop leurs données, l’améliorent mais gardent le code pour eux. Joli coup ! L’IGN a désormais au moins un exemple de ce qu’il ne faut pas faire !

C’est bien connu, à Toulouse nous ne sommes jamais en retard d’une mode parisienne. Le Vélô, version locale du Vélib’ a donc fait son apparition mi-novembre dans les rues de la Ville Rose, le ô étant là pour rappeler l’inoubliable Ô Toulouse du regretté Claude Nougaro.

Pour permettre aux toulousains de repérer facilement la station la plus proche de chez eux, j’ai réalisé une petite application avec OpenLayers. Les fonds de plan sont issus du service WMS de Geosignal. Les emplacements des stations de Vélô sont issus de la mairie de Toulouse. Pour les exploiter sur le serveur de ce site, dépourvu de serveur cartographique, je les ai transformées au format GeoJSON (au passage, merci à Pierre Giraud pour ses lumières), dans un fichier texte donc, qu’OpenLayers exploite directement depuis une requête XMLHttpRequest. Il y a aussi un fichier KML pour visualiser tout ça dans vous savez quoi.