ReLucBlog - SIG, MOZILLA & NTIC

OpenLayers 2.7 a été publier le 29 septembre 2008, au début des FOSS4G 2008, mais l'annonce officielle publiée par l'OSGEO vient de paraître (soummission de l'anonce par Frank Wamerdam le 7 octobre 2008).

Le laboratoire de Mozilla vient de publier une extension pour Firefox 3, Geode, permettant de tester la géolocalisation par le navigateur. J'ai déjà parler de cette méthode qui permet de géolocalsier un utilisateur d'application Web. Vous n'aurez donc pas à attendre la prochaine version de Firefox, la 3.1, ou la sortie de Fennec pour tester cette nouvelle fonctionnalité.

La norme du W3C sur l'API de géolocalisation est encore un brouillon. Cette extension doit permettre d'améliorer la norme mais aussi les possibilités de l'intégration de cette API dans Firefox 3.1 et Fennec.

Dans mon précédent billet j'avais mentionner la possibilité de choisir le fournisseur de position (GPS, Service Web ou autre). Dans Geode, un seul fournisseur de position a été intégré, SkyHook Wireless. Ce service Web permet de se positionner en fonction des bornes Wifi environnentes.

Pour en savoir plus :

• en anglais, l'annonce officiel
• en français, la présentation de Geode par clochix

Ils en parlent :

• The AnyGeo Blog
• VerySpatial

Il y a un an, lors des FOSS4G 2007, CampToCamp annonçait et présentait sa nouvelle solution cartographique MapFish (CartoWeb 4). Elle fut alors publier en version 0.1.
Il y a 6 mois, une nouvelle version de MapFish était annoncé, son numéro de publication était alors le 0.2.
Lundi, lors des FOSS4G 2008, CampToCamp annonce la première Release Candidate de MapFish 1.0, sur GeoRezo et Baliz-Media.
Mais où sont passées les versions intermédiaires ?

La réponse est assez simple : il n'y en a pas eu, ou alors en interne chez CampToCamp que personne n'a vu. Ceci montre bien qu'un numéro de version ne veut rien. Chaque éditeur de logiciel, que ce soit une entreprise ou une communauté, est libre de numéroter ces produits comme il le souhaite.

Dans le cas de MapFish, ce défaut de numérotation montre bien que le projet à trouver son marché. Il était donc nécessaire d'un point de vue commerciale de publier une version stable, ou pour être plus précis une version portant un numéro qui fait penser à une version stable. J'avais d'ailleurs déjà discuter de ce problème de numérotation avec des personnes de chez Mozilla et il est plus facile de promouvoir un logiciel avec un numéro entier, car un numéro entier fait penser à un travail abouti et finalisé.

Mais Ceci montre aussi que CampToCamp en créant MapFish ne savait pas ce qu'il allait vraiment être, ou n'avait pas planifier les étapes de développement. Ceci ne veut pas dire que MapFish 1.0 ne sera pas un projet abouti.

Autre exemple de numérotation, la communauté OpenLayers a décidé de se fixer des objectifs daté et non des objectifs de fonctionnalités. Le résultat est qu'une nouvelle version est publié à date fixe et que les utilisateurs profite régulièrement des évolutions apporté par la communauté.

Quelle sera la politique de la communauté MapFish et de CampToCamp ?

La prochaine version d'OpenLayers est en vue, la Release Candidate 2 a été publié. Pour l'occasion un diagramme UML est disponible. Donc si vous vous demandiez à quoi ressemblait l'architecture d'OpenLayers, je vous conseille d'y jeter un coup d'oeil.

Actuellement pour permettre à un utilisateur de se géolocaliser, il faut demander l'adresse de celui-ci. Avec Firefox 3.1 ou la nouvelle version de Google Gears, il sera possible d'obtenir la géolocalisation simplemet en demandant au navigateur!

La prochaine version de Firefox, disponible avant la fin de l'année, implémente les premières versions de l'API de Géolocalisation. Cette nouvelle norme du W3C est encore en cours d'élaboration. L'objectif de cette norme est de permettre aux applications Web de demander la position sur Terre de l'utilisateur, sans que celui-ci ai forcément besoin de saisir une adresse ou sa position.

Techniquement ceci se traduit par :

• l'ajout de méthodes au DOM accésible en JavaScript ;
• l'ajout d'une interface d'abstraction des fournisseurs de position.

Cette structure résout 2 problèmes :

• Comment puis-je fournir en temps réelle ma position à une application Web ?
• Comment fournir sa position quand on a pas de GPS ?

Donc le développeur d'application Web pourra simplement interroger le navigateur sur la position de l'utilisateur mais aussi s'abonner pour connaître toutes les modifications de position. Pour bien voir l'intérêt d'une telle API, prennons le cas de Google Maps. Sur l'IPhone 3G, il est possible de se positionner sur fond Google Maps. Mais vous n'utiliser pas Safari ni le Google Maps que vous consultez sur navigateur Web. Donc Google a dût développer une application qui ai accès au système GPS de l'IPhone et aux données de Google Maps. Avec l'API de Géolocalisation, plus besoin de développer une nouvelle application. Ils suffit d'ajouter quelques lignes de JavaScriptcool pour que l'application puisse savoir où se trouve l'utilisateur.

Il reste tout de même à ajouter au navigateur la possibilité de répondre à cette demande de position! Dans ce qui a été imaginé, le navigateur pourra utiliser différentes sources de position : GPS, bornes wifi, bornes téléphoniques, etc... Chez Mozilla, l'ajout de ces fournisseurs de position pourra se faire via des extensions. Pour Google Gears, il sera possible de proposer un service de geolocalisation.

Donc cette API a été intégré au futur Firefox, mais aussi au futur navigateur mobile de Mozilla : Fennec. Il est évident qu'une telle API doivent être intégré à Fennec, mais elle est tout aussi intéressante dans Firefox. Tout d'abord par ce que les objets mobiles ne sont pas que les smartphones ou téléphones portables, il y a aussi les netbooks et les tablets PC. Ensuite on peut imaginer des applications Web contextuelles tout aussi intéressantes pour un utilisateur sur poste fixe, par exemple pour consulter les évènements prêts de chez soi ou les bonnes affaires des magasins du quartiers.

Cette nouvelle API offre de nouvelles perspectives de développement d'application de Web Mapping mais aussi de Web SIG.

Pour en savoir plus :

• Geolocation in Firefox and Beyond d'Aza Raskin
• Geolocation today de Doug Turner
• Geolocation support added to Firefox 3.1
• Gears Geolocation API

GeoFabrik vous permet de consulter l'évolution des données cartographiques libres (OpenStreeMap) de certaines région, comme par exemple Paris :

Ces animations sont disponibles sous forme de GIF ou via une interface menu d'un slider.

Via OpenGeoData.

La première Release Candidate de la version 2.7 d'OpenLayers devrait être annoncé aujourd'hui.

Au moment où j'écris ces lignes, 96% des tickets de la version 2.7 ont été clos. Il reste encore 7 tickets.
4 devrait être inclus dans cette Release candidate :

• l'ajout d'un protocole WFS, Review ;
• l'ajout d'un protocole SQL.Gears pour pouvoir utiliser Google Gears et donc OpenLayers en mode déconnecté, Review ;
• l'ajout d'un contrôle de mesure, Commit ;
• l'amélioration du gestionnaire de dessin (sketch handler), Commit.

Les 3 derniers nécessite encore du travaille :

• l'ajout des formats ATOM et GML Simple Feature ;
• l'intégration du travail sur le comportement des couches vectoriels, afin de passer du mode online au mode offline de façon transparente ;
• l'ajout d'un parseur GML versionné afin de supporter GML2 et GML3.

Dans ce qui est déjà intégré à cette Release Candidate, il y a 2 choses intéressantes que vous pouvez déjà tester :

• un affichage en profondeur des objets géographiques en fonction de leur position sur l'axe des x et y, exemple ;
• le support des well-known graphics pour les géométries de type point, exemple.

Enfin un dernier point qui m'intéresse particulièrement, c'est la correction d'un bug des couches Google.

Mozilla labs vient de lancer une nouvelle expérience : Ubiquity. Tout comme Prism, Ubiquity propose une nouvelle façon de consommer le Web. Cette fois, l'objectif est d'essayer de connecter le Web à la Langue. Cette connection se traduit par un système de ligne de commande. L'exemple choisi par Aza Raskin pour montrer l'intérêt d'un tel système utilise la cartographie. C'est le suivant :
Vous êtes sur votre Web mail en train de rédiger une invitation à un ami et vous souhaitez ajouter une carte positionnant le restaurant. Pour ce faire, vous devez ouvrir un nouvel onglet dans votre navigateur, entrer l'adresse d'une solution de cartographie Web (par exemple : maps.google.fr), entrer l'addresse du restaurant dans le champs de recherche, obtenir l'URL correspondant au résultat visualiser et insérer cette URL dans votre mail. Vous avez réalisé de nombreuses étapes sans même arriver à intégrer une carte à votre mail. Vous n'avez fait que trouver une URL que pourra utiliser votre ami pour visualiser l'emplacement du restaurant. Avec Ubiquity, il vous suffit d'Ubiq map l'adresse du restaurant pour obtenir et insérer l'image de l'emplacement du restaurant.

J'ai été pas mal impressionné par les capacités qu'offrent Ubiquity, et comme le dit Tristan Nitot : c'est potentiellement révolutionnaire mais ça n'est qu'une expérience de laboratoire. Vous pouvez malgré tout tester cette extension et participer à l'évolution d'Ubiquity.

Liens :

• Annonce officiel Mozilla labs
• Description par Aza Raskin
• Présentation de Tristan Nitot

Mozilla viens d'intégrer au tronc et donc de publier TraceMonkey, une évolution du moteur de JavaScript (SpiderMonkey) de Firefox. TraceMonkey sera disponible à tous avec Firefox 3.1 qui devrait être publier à la fin de l'année. TraceMonkey utilise la technique appellé trace trees pour permettre la compilation juste à temps (Just In Time) du JavaScript. Cette méthode permet d'améliorer la performance du langage JavaScript et donc du Web, la preuve par l'exemple.

L'objectif initial était d'améliorer l'interprétation du JavaScript pour le mobile et donc de proposer une expérience du Web Mobile proche du Web. Pour ce faire il était nécessaire d'améliorer la façon dont le JavaScript est interprété par le navigateur. Il était nécessaire d'interprété celui-ci juste à temps et de diminuer l'emprise mémoire de celle-ci. La technique trace trees était déjà utilisé par Adobe dans son interpréteur d'ActionSript (FLEX), cousin du JavaScript, et fourni à la communauté Mozilla via Tamarin Tracing.

TraceMonkey est une excellente nouvelle pour le Web car il est disponible pour les architectures de processeurs x86, x86-64 et ARM, donc pour tous les ordinateurs de bureaux (desktops) et les mobiles (smartphones et téléphones mobiles). De plus l'amélioration des performances offertes par TraceMonkey permet de réaliser en JavaScript des applications qui nécessitait jusqu'alors l'utilisation d'un plugin.

Mais TraceMonkey est surtout une excellente nouvelle pour le GeoWeb, puisqu'il augmente les capacités du JavaScript. Il augmente les possibilités d'analyse et de traitement des données vectorielles au sein du client. Là où le Flash était nécessaire, le JavaScript pourra le remplacer. Il sera aussi possible d'accéder à de vrai application de Web-Mapping à partir d'un mobile.

Ce qui peut sembler limitant c'est que cette évolution n'est valable que pour le navigateur Firefox et que donc pour pouvoir en profiter il faudra installer Firefox 3.1. Or Mozilla n'est pas le seul à travailler sur l'amélioration des performances de son interpréteur JavaScript. Apple travaille aussi à l'amélioration de l'interpréteur de Webkit. De plus Mozilla a prévu de publier ScreamingMonkey qui permettra d'utiliser SpiderMonkey et donc TraceMonkey dans Internet Explorer. En ce qui concerne le mobile, les utilisateurs d'IPhone n'en profiteront pas directement en raison de l'interdiction par Apple d'installer un interpréteur sur l'IPhone, par contre les heureux possesseurs de Nokia N95 en profiteront rapidement avec Fennec. Enfin Il existe la possibilité d'utiliser Prism pour publier des applications Web ou alors de réaliser son propre visualisateur d'application de WebSIG avec XULRunner. Cette dernière solution permet même de mixer données Web (Google Maps, WMS, GeoJSON) et données locales (ESRI Shape File, base de données PostGIS).

Enfin, il faut savoir que Mozilla vise à faire de JavaScript un langage capable de concurencer les langages nativement compilés. On devrait donc pouvoir rapidement réaliser des applications SIG tout en JavaScript.

Si vous voulez en savoir plus sur TraceMonkey :

• Brendan Eich, TraceMonkey: JavaScript Lightspeed
• Robert Accetura, Getting Faster With TraceMonkey
• Shaver, the birth of a faster monkey
• SpiderMonkey + Tracing = TraceMonkey
• Andreas Gal, Tracing the Web
• John Resig, TraceMonkey

Depuis peu, Earthscape est diponible sur l'Apple Store pour 10$.

Petite vidéo de démonstration faite par Frank Taylor de Google Earth Blog.

Earthscape possède :

• un modèle de terrain 3D de la terre ;
• des photos satellites hautes résolutions ou aériennes pour certaines régions (principalement les USA), mais moins précisent que dans Google Earth ;
• une couche Wikipedia qui géoréférence des articles de la célèbre encyclopédie numérique.

Démo officiel.

Via Google Earth Blog.

Via James Fee GIS blog.

Ce nouveau standard est un langage GML pour la description et l'échange de modèles 3D de batîments et de villes. Cette norme doit permettre de rapprocher BIM et SIG. Luc Vaillancourt (Baliz-Media) avait évoqué le raprochement entre BIM et SIG dans son retour sur GeoWeb 2008.

Maintenant que cityGML est une norme de l'OGC, il faut que celle-ci soit implémentée par les éditeurs de globe virtuelle, que la communauté produise des données alors que le KML, qui est aussi une norme de l'OGC, permet depuis un moment de décrire et échanger des modèles 3D !

Non, je ne suis pas un afficionados de Google et ne dédie surtout pas ce blog à Google Maps, mais Google vient de rendre disponible en version béta la possibilité de trouver son parcours à pied!

Par exemple : aller de la gare Montpellier Saint roch à la place des Martyrs de la Résistance à Montpellier en voiture ou à pied

Je sais aussi que du côté d'OpenStreetMap ça avance bien comme par exemple OpenRouteService (seulement disponible en Allemagne pour le moment) qui devrait pouvoir intégrer le calcul de trajet à pied ;-)

Via Mapperz

Mitchell Tyler vient d'annoncer que l'IGN est le dernier sponsor en date de l'association OSGEO.

Petite traduction :

Le premier point qui intéresse l'IGN dans les projets Open Source est d'améliorer des outils tels que Proj4 et GDAL/OGR, projet soutenu par l'OSGEO, afin de pouvoir reprojeté des données géographiques de l'ancien système géodésique français (NTF) vers le nouveau (RGF93). Il faut espérer que l'amélioration de ces outils contribuera à rendre la transition plus facile pour le public.

Deuxièmement, ils ont également eu recours à OpenLayers appuyés par l'OSGeo comme base de la nouvelle API du Geoportail. Compte tenu de l'utilisation généralisée d'OpenLayers, les programmeurs devraient trouver facile l'utilisation de l'API du Geoportail.

L'IGN attend avec impatience d'être impliqué dans le soutien de l'OSGeo par le financement mais aussi en continuant de contribuer au code des projets susmentionnés.

Billet initial.

Dans mon précédent billet j'ai eu la malencontreuse idée d'associer OpenStreetMap et Google Maps. Je ne pensais pas que ça provoquerait autant de réactions. J'ai donc décidé de prendre le temps de présenter un peu plus longuement ma perception de Google Maps Maker et de la collaboration cartographique.

Tout d'abord Rodolphe, je ne fais aucun amalgame entre OSM et GMaps. le billet, Google Maps devient collaboratif, souhaitait juste mettre en avant le fait que Google proposait aux néo-géographes et non-géographes de participer encore plus à son service de cartographie en ligne. Open Street Map a un tout autre objectif, comme le rapelle Wally, fournir des données cartographiques libres du monde.

Une fois cela connu, libre à chacun de participer à la carte de son choix.

Google a construit Google Maps à partir de données que des entreprises construisent et vendent. TomTom vend des appareils équipés des données achetées aux mêmes fournisseurs. Ces données ont un cycle de vie, les fournisseurs s'engagent à les mettres à jour régulièrement. Mais cette durée de vie est assez faible vis-à-vis du rythme d'évolution de notre environnement, et la collaboration offre une alternative interressante.

La collaboration permet à Google et TomTom de participer à la carte qu'ils utilisent. De plus ils peuvent ainsi proposer des données potentiellement plus précises que celles de leur fournisseur. Mais sans jamais remettre en cause l'importance de ses fournisseurs, TeleAtlas a bien été racheté par TomTom. Dans le cas d'OpenStreetMap, la collaboration est à la base du projet puisque c'est le meilleur moyen pour générer des données libres.

Dans le cas de Google, je pense que la collaboration a 2 objectifs :

• le premier attirer encore plus de contributeur, pour étoffer la quantité et la qualité des données géographiques analysées par ses serveurs et ainsi améliorer les réponses de son moteur de recherche GeoWeb;
• le second convaincre les commerçants, artisants et autres professions référençables géographiquements d'investir dans le géographique (publicité et autre).

Dans le cas de TomTom, c'est plus évident :

• tenir compte le plus vite possible des modifications ayant un impact sur les parcours proposés
• proposer des circuits ou autres services liées aux positionnement géographiques.

Ce qui est évident, c'est que le modèle d'éditeur de données est en train d'évoluer. La collaboration va faire partie du mode de création de carte, et je pense que même l'IGN y réfléchi. OpenStreetMap est avec UPCT le précurseur du GeoWiki. OpenStreetMap est a mon sens le GeoWiki le plus poussé et le plus complet possible mais il lui reste un cap à franchir en terme de visibilité et de notoriété. J'espère tout de même qu'un jour OSM sera la référence en terme de source de données.

Google vient de lancer un nouveau service Google Maps permettant aux utilisateurs d'ajouter ou mettre à jour les informations fournit par Google Maps : Google Map Maker.

Le monde entier n'est pas éditable mais Google Maps devient ainsi une carte Collaborative au même titre qu'OpenStreetMap ou MapShare de TomTom, d'ailleurs Google Map maker n'est rien d'autre que le GeoWiki de Google!

Que manque-t-il encore à Google Maps pour être une carte numérique de premier ordre ?

Via Mapperz