neogeo

Ca bouge chez ESRI, qui réinvente FeatureServer... Une interface REST en cours de développement mais déjà opérationnelle (l’exemple est fait avec OpenLayers, pas ArcIMS…) dans le cadre du projet ArcDevelopper illustre bien l’intérêt porté aux Architectures Orientée Ressources par les plus gros acteurs du marché SIG. Ca retourne même du GeoJSON (essayez ce lien : http://65.101.234.201/rest/rest.svc/TestService/Flyways/10?g=true) , preuve que ce format est en train de s’imposer tranquillement comme le standard pratique d’échange de données vectorielles sur le web, tandis que l’architecture REST procure souplesse et lisibilité. On aura l’occasion d’en reparler bientôt.

P.S. : même Microsoft s’intéresse à REST, le framework .NET 3.5 intègre une classe .NET d’URI templating, pour interpréter directement les URLs Restful selon des modèles prédéfinis…

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.

Mateusz Loskot vient de publier un nouveau driver pour OGR, la célèbre bibliothèque d’abstraction/conversion de formats SIG, qui va donc désormais pouvoir accéder en lecture seule à des flux GeoJSON. On en a déjà parlé, le GeoJSON est la version Geo (malin non ?) de la notation JSON (Javascript Simple Object Notation) qui permet d’échanger facilement des objets structurés entre un serveur et un client. Un tableau associatif PHP se converti ainsi directement en un objet javascript.

La particularité du driver de Mateusz est de pouvoir accéder directement à un flux http renvoyant du GeoJSON, car ce “format” n’est pas à proprement parler un format de stockage comme le Shapefile ou le GML, mais bien un format d’échange. Avoir un fichier .gjson serait par là même une aberration ! Le driver ouvre donc une connexion vers un service web délivrant du GeoJSON, et permet alors toutes les opérations habituelles des modules OGR : info sur le fichier et conversion :
ogr2ogr -f “ESRI Shapefile” cities.shp http://featureserver/cities/.geojson OGRGeoJSON transforme en shapefile le flux GeoJson des villes issu du serveur de données.

L’intérêt de cette implémentation est tout naturellement son utilisation dans un contexte mobile, où la limitation de bande passante empêche l’exploitation de “gros” formats tels que le WFS-GML, un petit client pouvant ainsi récupérer les données vectorielles dynamiquement pour une exploitation locale.

Notez bien que ce driver n’est pas encore disponible dans la version officielle de GDAL-OGR, mais uniquement à partir du svn osgeo . Le portage dans la version officielle devrait être faite sous peu.

C’est le blog d’OpenLayers qui le dit, la nouvelle version disponible depuis ce jour en Release Candidate 1 propose de nombreuses améliorations à l’excellent client javascript de cartographie :

• Amélioration de la prise en charge des formats vectoriels via du GeoJSON
• Amélioration des fonctionnalités d’édition des objets, et notamment des petites ancres au milieu des segments qui permettent facilement d’ajouter des sommets sans manipulation complexe de la forme existante (voir la démo)
• Meilleure prise en charge des données hétérogènes
• Fonction de création de polygones réguliers à partir de quelques paramètres (centre, rayon, nombre de faces)
• Possibilité de faire pivoter les objets vectoriels. Ca donne un peu le tournis, mais à n’en pas douter ça peut avoir quelques applications intéressantes.

Un grand bravo donc à tous les développeurs de cette nouvelle version, et notamment aux équipes de CampToCamp et Metacarta qui n’ont semble-t-il pas ménagé leurs efforts. Il est vrai que le prochain CartoWeb 4, qui sera présenté à l’occasion du FOSS4G, utilisera OpenLayers en lui adjoignant des modules serveurs complémentaires.