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 ?

Dans le cadre de la réalisation de mon premier composants XPCOM en C++, j'ai dû résoudre le problème suivant : Comment récupérer un buffer pour le manipuler en JavaScript et l'afficher via la définition d'un nouveau protocol ?

Voici mes découvertes :

nsIBinaryOutputStream

L'objet JavaScript suivant permet d'écriture dans un output stream :

Components.classes"@mozilla.org/binaryoutputstream;1"
  .createInstance(Components.interfaces.nsIBinaryOutputStream);

Un tel objet permet de récupérer le buffer générer au sein de mon composant C++ via la méthode writeByteArray qui prend en paramètre le buffer (char *) et la taille de celui-ci. J'ai donc créer une méthode saveToStream qui prend en paramètre un objet implémentant l'interface nsIBinaryOutputStream.
Par exemple pour écrire dans un fichier :

// création d'un fichier local
var aFile = Components.classes"@mozilla.org/file/local;1".createInstance(Components.interfaces.nsILocalFile);
aFile.initWithPath( "/tmp/buffer");
// création du OutputStream associé au fichier
var stream = Components.classes"@mozilla.org/network/file-output-stream;1".createInstance(Components.interfaces.nsIFileOutputStream);
stream.init(aFile, 0x04 | 0x08 | 0x20, 0600, 0);
// création du binary output stream
var bos = Components.classes"@mozilla.org/binaryoutputstream;1".createInstance(Components.interfaces.nsIBinaryOutputStream);
// cette étape va permettre d'écrire dans l'output stream du fichier
bos.setOutputStream(stream);
// écriture du buffer dans l'output stream du fichier
myComponent.saveToStream(bos);
// il n'y a plus qu'à fermer les flux pour finaliser l'écriture du buffer dans le fichier
bos.close();
stream.close();

Grâce au Binary Output Stream je suis capable d'écrire le buffer générer dans mon composant XPCOM dans un fichier.

nsIChannel et nsIPipe

Dans Mozilla, il est possible de définir son propre protocol. La principale étape est de définir la méthode newChannel qui prend en paramètre un objet implémentant l'interface nsIURI et doit retourner un objet implémentant l'interface nsIChannel. Dans mon cas c'est dans cette méthode que j'utilise mon composant et donc que je récupère un objet implémentant l'interface nsIOutputStream. Or un nsIChannel est basé sur un objet implémentant une interface nsIInputStream. Il fallait trouver le moyen d'obtenir le input stream associé à l'output stream.

L'objet JavaScript suivant permet de lié input stream et output stream :

Components.classes"@mozilla.org/pipe;1".createInstance(Components.interfaces.nsIPipe);

Enfin il fallait faire de l'input stream obtenu un objet implémentant l'interface nsIChannel, c'est ce que permet l'objet suivant :

Components.classes"@mozilla.org/network/input-stream-channel;1".createInstance(Components.interfaces.nsIInputStreamChannel);

La méthode newChannel s'implémente ainsi :

myProtocolHandler.prototype.newChannel = function(aURI) {
     // création du pipe
     var pipe = Components.classes"@mozilla.org/pipe;1".createInstance(Components.interfaces.nsIPipe);
     pipe.init(true,true, 0, 0, null);
     // création du binary output stream
     var bos = Components.classes"@mozilla.org/binaryoutputstream;1".createInstance(Components.interfaces.nsIBinaryOutputStream);
     // cette étape va permettre d'écrire dans l'output stream du pipe
     bos.setOutputSTream(pipe.outputStream);
     // écriture du buffer dans l'output stream du pipe
     myComponent.saveToStream(bos);
     // fermeture des output stream
     bos.close();
     pipe.outputStream.close();
     // il reste plus qu'à créer le channel
     var channel = Components.classes"@mozilla.org/network/input-stream-channel;1".createInstance(Components.interfaces.nsIInputStreamChannel);
     channel.setURI(aURI);
     channel.contentStream = pipe.inputStream;
     channel.QueryInterface(Components.interfaces.nsIChannel);
     return channel;
}

C'est bien mais c'est synchone...

nsIPipe et nsIThreadManager

La dernière étape consiste à faire en sorte que la création du buffer et l'écriture soit asynchrone. Ce qu'il faut savoir c'est que le pipe permet d'écrire dans un thread et de lire le résultat dans un autre, de plus tant que rien n'est écrit dans l'output stream du pipe rein n'est lu, enfin lorsque l'output stream est clos le channel et donc la requête qui a été créer à partir de l'input stream du pipe est considéré comme fini.

Il faut d'abord définir un thread d'exécution :

var workingThread = function(pipe, myComponent) {
   this.pipe = pipe;
   this.component = myComponent;
};

workingThread.prototype = {
  run: function() {
    try {
      var bos = Cc"@mozilla.org/binaryoutputstream;1".createInstance(Ci.nsIBinaryOutputStream);
      bos.setOutputStream(this.pipe.outputStream);
      this.component.saveToStream(bos);
      bos.close();
      this.pipe.outputStream.close();
    } catch(err) {
      Components.utils.reportError(err);
    }
  },
  
  QueryInterface: function(iid) {
    if (iid.equals(Ci.nsIRunnable) ||
        iid.equals(Ci.nsISupports)) {
            return this;
    }
    throw Components.results.NS_ERROR_NO_INTERFACE;
  }
};

Ensuite il suffit de déclarer un objet global permettant l'exécution en fond de tâche :

background = Components.classes"@mozilla.org/thread-manager;1".getService().newThread(0);

Il ne reste plus qu'à réécrire la méthode newChannel du protocol handler :

myProtocolHandler.prototype.newChannel = function(aURI) {
     // création du pipe
     var pipe = Components.classes"@mozilla.org/pipe;1".createInstance(Components.interfaces.nsIPipe);
     pipe.init(true,true, 0, 0, null);
     // appel en fond de tâche de la création du buffer et de l'écriture
     background.dispatch(new workingThread(pipe, myComponent), background.DISPATCH_NORMAL);
     // il reste plus qu'à créer le channel
     var channel = Components.classes"@mozilla.org/network/input-stream-channel;1".createInstance(Components.interfaces.nsIInputStreamChannel);
     channel.setURI(aURI);
     channel.contentStream = pipe.inputStream;
     channel.QueryInterface(Components.interfaces.nsIChannel);
     return channel;
}

En espérant que ça puisses vous servir ;-)

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.

Après l'intégration des tranformations CSS3, Robert O'Callahan annonce la possibilité d'utiliser les effets SVG sur du contenu HTML. Le Web Ouvert va vraiment devenir sympa ;-)

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.