neogeo

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.

Depuis ce matin sur les étals du geoweb frétille un nouveau specimen dénommé MapFish. Avec pour emblème une magnifique croquette de poisson pané (!) c’est sous ce nom que CartoWeb4, présenté en septembre au FOSS4G, se présente désormais, Cartoweb restant le nom de la branche 3, toujours maintenue depuis la sortie de la version 3.4 fin septembre.

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.

Mapstraction intègre désormais un 9ème provider cartographique qui n’est autre qu’… OpenLayers ! Bizarre quand on sait qu’OpenLayers n’est pas un producteur de données mais un client multi-sources, comme Mapstraction justement. Reprenons…

Mapstraction est une classe javascript d’abstraction (d’où le nom, les plus perspicaces l’auront remarqué) des principales API cartos, permettant à partir d’un code unique de manipuler les contenus Google, Yahoo, Microsoft, Map24 etc. Par exemple, pour cadrer la vue sur un endroit particulier, Mapstraction utilise la fonction setCenterAndZoom quelque soit l’API utilisée. C’est la librairie d’abstraction qui traduit en commandes spécifiques à l’API pour vous. Pratique, même si ça réduit forcément l’utilisation de la librairie au dénominateur commun des APIs prises en charge.

OpenLayers, bien connu des lecteurs de ce blog, est une API javascript de cartographie disposant de nombreux types de connexions vers des sources de données (GoogleMaps, YahooMaps, mais aussi des flux GeoRSS, GML, GeoJSON). OpenLayers n’utilise pas les fonctionnalités des API externes, mais au contraire dispose de ses propres contrôles et commandes, ainsi que de couches personnalisées (VectorLayer par exemple).

Mapstraction avait déjà intégré OpenStreetMap, qui n’a pas d’API propre, et devait donc être chargée via l’API Google…

Au final, l’intégration d’OL (qui n’est pas un fournisseur de données) dans Mapstraction se résume à l’utilisation des controles OL dans l’interface Mapstraction, tout en permettant de ne plus passer par l’API Google pour visualiser les données OSM qui sont la couche par défaut chargée avec OL.

Donc, une API qui se sert des contrôles d’une autre API pour manipuler les données d’une troisième, ça donne quand-même un peu le vertige.

via HighEarthOrbit