Bon dimanche.

Stéphane.

J’ai donc un GPS pour mon D90 : il s’agit de l’unité GP-1, qui se place à la place du flash ou sur le coté. Pour info, dans le Nikon P.6000, un compact, le GPS est en standard.

Mes grands-parents, s’ils étaient en vie, diraient : « Mais que fait Stéphane, dans le jardin, avec un appareil photographique pointant vers le ciel ? » Au début, la première capture des satellites est un peu longue : plus de 5 s., c’est déjà embêtant si vous devez déclencher tout de suite… passons. En laissant l’appareil en veille, ça va mieux. Ensuite cela semble assez précis (même dans le jardin), l’altitude aussi (testé avec un bon vieil altimètre).

Clic-clac, les coordonnées et l’altitude sont bien capturées et incluses dans les méta-données EXIF de l’image. Avec Exiftool (et tous les outils qui tourne autour), par exemple, il est facile de voir et d’exporter ces valeurs de positionnement (extrait) dans ExiftoolGUI…

De les sortir sous la forme d’un tableau HTML (voir plus bas)…

…Et bien entendu, il est très facile d’exploiter cela avec un outil cartographique en local, tel que l’excellent GeoSetter dont une version en français est disponible :

ou bien via l’outil carte de Flickr (là, rien à faire de particulier, les photos sont positionnées par défaut lors du chargement).

Tout cela peut aussi ce faire via son Firefox avec IExif, Dans la monde Google avec Picasa et Google Earth, etc.

Si le format EXIF vous pose un problème, il est possible de stocker ces données dans du MIX. C’est évidement plus complexe pour l’exploitation, du moins pour le grand public.

Extraire ce type de méta-données avec du Perl est très facile : le programme perl exiftool de Phil Harvey est très bien pour cela : une petit ligne du type « Exiftool -exif:GPSAltitude -h  img > mes_exifs.html » et l’on récupère l’altitude d’une série d’images dans un tableau HTML.

Avec du PHP c’est possible aussi : il faut charger les extensions php_mbstring et exif (dans cet ordre) dans le php.ini ; ensuite il est possible d’utiliser la fonction exif_read_data.

Bref, bientôt TOUS les appareils géo-tagueront en automatique et l’on ne comprendra pas pourquoi les photos anciennes ne le sont pas (les documentalistes vont avoir du travail) : ainsi les interfaces d’intérogations vont évoluer : un fond de carte, des outils de sélection (ronds, carrés, etc.), des plots de couleurs, des requêtes externes, des réponses aux questions qui s’afficheront sous la forme d’un chapelet de marqueurs. Au CN2SV, nous avons commencé à le faire des cartes et des atlas anciens, j’imagine ce que nous allons faire dans quelques années !

Mais j’y pense… le temps d’écrire ce billet et tout cela doit déjà exister, j’en suis sûr (et en open-source ?). En attendant la suite, j’espère que les artistes vont trouver des applications moins « utiles » que celles décrites ici. Je m’en retourne à mon mash-up de noël.

Joyeuses fêtes,

Stéphane.

Je profite d’un week-end loin de Paris et d’un long voyage en train pour décrire (mais avec beaucoup de retard) un petit mashup que j’ai réalisé pour le site @.ampère et l’histoire de l’électricité. L’idée de départ était de développer des chronologies avec l’outil Timeline mis au point par le MIT et que pas mal de développeurs connaissent et utilisent. Timeline permet de créer des frises chronologiques à l’image de celles encore présentes dans les livres scolaires d’histoire (nous avons tous rêvés devant ces frises en couleurs présentant l’histoire de l’Homme par exemple). C’est outil utilise des éléments en javascript et du XML : c’est donc un système basé sur AJAX. Dans le site @.ampère nous voulions faire une frise avec des éléments historiques différents le tout devant être synchronisé :

• une sous-frise sur les grands personnages de l’histoire de l’électricité
• une sous-frise sur les grandes découvertes de ce même domaine

Dans Timeline, les évènements (events) sont stockés dans un fichier XML très simple. Dans le but d’inclure Timeline dans le système d’information (SI) du site, nous avons utilisé deux tables MySQL pour mettre les données brutes (date, contenu de l’évènement, etc.). Un script PHP utilisant DOM réalise alors une présentation XML de ces données : en sortie, nous avons deux fichiers XML, un pour chaque sous-frise, qui sont normés suivant le schéma des fichier nécessaire au fonctionnement de Timeline. Nos deux tables MySQL sont indépendantes du système AJAX de Timeline : c’est PHP/DOM qui formate les données en XML suivant la grammaire Timeline. Nous avons d’ailleurs un autre programme PHP qui présente ces même données sous la forme d’une page web classique. Le schéma suivant en résume le modèle :

Les deux fichiers XML sont stockés dans un répertoire du serveur et chargé dans l’application AJAX qui gère Timeline. Le XML resemble à ceci :



<?xml version="1.0" encoding="iso-8859-1"?><data>

<event start="Jan 00 1544 00:00:00 GMT" end="Jan 00 1603 00:00:00 GMT" 

image="AMP_1015.jpg" isDuration="true" title="William GILBERT">(1544-1603)</event><event start="Jan 00 1666 00:00:00 GMT" end="Jan 00 1736 00:00:00 GMT" 

isDuration="true" title="Stephen GRAY">(1666-1736)</event> ...

</data>

Pour le tout fonctionne, il nous a fallu ajouter un petit programme php de vérification de la forme des dates/heures histoire de ne pas avoir de bug dans l’une des deux sous-frises. Pour terminer nous avons ajouté, dans le fichier javascript de la frise (main.js) qui pilote l’affichage écran, les instructions suivantes :

bandInfos[1].eventPainter.setLayout(bandInfos[1].eventPainter.getLayout());

tl = Timeline.create(document.getElementById("my-timeline"), bandInfos, Timeline.HORIZONTAL);

Timeline.loadXML("kronos1.xml", function(xml, url) { eventSourceA.loadXML(xml, url); });

Timeline.loadXML("kronos2.xml", function(xml, url) { eventSourceB.loadXML(xml, url); });

Nous avons une « bandInfos » dans laquelle nous « chargeons » les deux fichier XML : kronos1.xml et kronos2.xml. Ce chargement est réalisé au sein des deux eventSource (A et B). Ce fichier, main.js, qui est un fichier javascript pur est chargé dans une page HTML (ou PHP dans notre cas) par l’utilisation d’une simple balise <script> dans l’entête. La frise « double » est ensuite affiché dans le code HTML via un « id » de balise <div> :

<div id="my-timeline" style="height:800px; width:100%;"></div>

Le tour est joué, nous avons une belle frise chronologique présentant de façon synoptique ces deux types d’évènements. Voici le résultat :

Bonne fin de week-end,

Stéphane.

PS : Merci à Marie-Hélène Wronecki pour le travail sur la base de données MySQL.

Un petit script php très simple pour convertir une date du type AAAA-MM-JJ HH:MM:SS en date normée suivant RFC 822 utilisée dans les flux RSS ou dans le monde OAI-PMH :

$datedepart = '2007-09-10 00:00:00'; // on entre la date (qui peut venir d'un champ de type datetime de SGBDR : MySQL, PostgreSQL, etc.)

list($date, $hours) = split(' ', $datedepart);
list($year,$month,$day) = split('-',$date);
list($hour,$min,$sec) = split(':',$hours);

$date = date(r,mktime($hour, $min, $sec, $month, $day, $year));
print "$date";

Stéphane.

Le KML (Keyhole Markup Language) est une grammaire XML permettant d’afficher et de gérer des données dans Google Maps et Earth. Il offre la possibilité de poser des points, tracer des lignes, des polygones. Dans Google Earth, s’y ajoute les angles de vue, les objets 3D simples ou texturés. Mais l’une des fonctionnalités les plus intéressante pour la recherche reste l’enrichissement en données externes. KML peut diffuser des données XHTML riches (textes, images, videos), des images plaquées sur la photo satellitaire, etc…

Il existe une version compressé du KML, le KMZ. Pour ceux qui ont utilisé comme moi du VRML (Virtual Reality Modeling Language), nous avions aussi une version « Gzipé » du langage : le .wrz (à la place du .wrl). le KMZ encapsule aussi les images qui peuvent être liées au fichier KML. Il est possible de fabriquer du KMZ avec un simple compresseur : WinZip, Gzip, etc.

Sur le plan syntaxique, le KML se présente comme du XML :

<?xml version= »1.0″ encoding= »UTF-8″?>
<kml xmlns= »http://earth.google.com/kml/2.2″>
<Placemark>
<name>Siège du CNRS</name>
<description>Paris, le siège du CNRS.</description>
<LookAt>
<longitude>2.264605600614077</longitude>
<latitude>48.84727288728012</latitude>
<altitude>0</altitude>
<range>171.6689944655567</range>
<tilt>-6.848248640637841e-011</tilt>
<heading>0.0004740658326556625</heading>
</LookAt>
<Point>
<coordinates>2.264605600614077,48.84727288728013,0</coordinates>
</Point>
</Placemark>
</kml>

Ce petit fichier KML permet de placer dans Google Earth ou Maps, un point localisé sur le siège du CNRS, l’élément <LookAt/> correspondant au point de vue de la caméra qui « regarde » ce point. <Placemark/> encapsule le <Point/> géocodé présentant la latitude et la longitude. Dans le monde Earth / Maps de Google, les coordonnées géographiques sont en degrés décimaux (comptés positivement vers le Nord pour la latitude, et vers l’Est pour la longitude). Ici, le géocodage est très précis (2.264605600614077), mais si vous utilisez l’API de Maps, la précision est de l’ordre du mètre. Autre limite, dans Google Maps, seuls certains éléments peuvent être utilisés : les points, les lignes, les polygones, les styles, les icônes et les liens et l’application de couches multiple (placage d’images), mise en œuvre de dossiers et types de vues. Pour le moment (version 2.2 du KML) la 3D n’est pas utilisée (nous sommes dans Maps, donc le royaume de la 2D).

Ce petit exemple, permet de ce lancer dans la construction de fichiers KML et ainsi enrichir en information de toutes sortes de cartes dans le vaste « bac à sable » que peut être Google Maps ou Earth. De nombreux scientifiques, les géographes principalement, utilisent déjà ce format. J’ai découvert aussi ce site qui présente Google Earth et le KML pour les enseignants du secondaire. Le KML n’est pas le seul format XML dans le domaine des « géo-formats/2D/3D » : il y a le WMS, WFS et GML venant du monde de la géographie, les formats pour « services web » : AtomPub, GeoRSS et le KML/Z (avec d’autres limites cependant).

Dans le cadre du CN2SV, nous avons publié l’inventaire d’un fonds de cartes topographiques anciennes (XIXe-XXe siècle) de la cartothèque du centre de documentation REGARDS-CNRS. Nous avons décidé de coupler ce fonds de cartes, après numérisation, avec une base de données bibliographique/documentaire classique. Pour cela, nous avons utilisé une base de données intermédiaire qui, à partir des données lat./long. des quatres angles d’une carte, a pour mission de stocker des données pour produire à la fois du KML (pour l’instant sous la forme de petit fichier, donc nous sommes en mode asynchrone) qui peut être utilisé dans Google Earth pour visualiser l’emprise de la carte, ces villes importantes, etc. Mais aussi du XML compatible avec l’API de Google Maps (qui est légèrement différent du KML natif, du moins dans sa version 2.2 ).

Dans un second temps, j’ai développé une petit programme PHP qui exploite ces fichiers XML (pour l’API…) dans un contexte l’application riche. Du KML simple, nous passons dans un micro format XML propre (mais nous pourrions faire cela avec du KML directement, c’est juste une histoire d’optimisation du fichier pour l’API de Google Maps), ainsi pour chacune des cartes nous avons ceci :

<?xml version= »1.0″ encoding= »UTF-8″?>
<mygeod xmlns= »http://www.cn2sv.cnrs.fr/xml/mygeoc/0.1″>

<markers>
<marker lat= »-20.53105″ lng= »47.24332″ label= »Ville d’Ambositra » html= »Informations sur la ville d’Ambositra <br>avec la base de données REGARDS-ADES-CNRS » infolink= »query.php?value=Ambositra »/>
<marker lat= »-20.62105″ lng= »47.20332″ label= »Carte de Madagascar » html= »Informations sur la ville d’Ivato <br>avec la base de données REGARDS-ADES-CNRS » infolink= »query.php?value=Ivato+Madagascar »/>
<marker lat= »-19.871795326377995″ lng= »47.03521728515625″ label= »Carte de Madagascar » html= »Informations sur la ville d’Antsirabe <br>avec la base de données REGARDS-ADES-CNRS » infolink= »query.php?value=Antsirabe »/>
<marker lat= »-20.27137605095937″ lng= »44.31661605834961″ label= »Carte de Madagascar » html= »Une carte est disponible » infolink= »?id=R_MADA11_04_00014″/>
<line colour= »#ff0000″ width= »5″>
<point lat= »-19.40″ lng= »45.32″/>
<point lat= »-19.40″ lng= »48.11″/>
<point lat= »-21.20″ lng= »48.11″/>
<point lat= »-21.20″ lng= »45.32″/>
<point lat= »-19.40″ lng= »45.32″/>
</line>
<center lat= »-20.33″ lng= »46.90″ zoom= »8″/>
</markers>

</mygeod>

Ce fichier XML permet de délimiter la couverture de carte et de pointer des lieux (les « markers » de Google Maps). Les attributs sont très simples :

• label : titre de la vignette/popup
• html : contenu de la vignette/popup
• lat : latitude
• lng : longitude
• zoom (pour <center/>) : facteur du zoom d’entrée dans la carte
• infolink : lien vers le connecteur de/des bases de données à interroger (mais on pourrait imaginer une chose avec du xlink et xpointer si l’on veut rester dans le monde XML)

Il suffit d’utiliser de l’API de Google Map pour monter l’application. Mais cela sera pour le prochain billet…

Stéphane.

PS : Le format KML est relativement simple, mais un ouvrage de référence en français manque (à moins qu’il soit sous presse).

Stéphane.
PS : un tutoriel plutôt bien fait existe sur le site : developpez.com

location.href='formAK.php/user?action=add& description='+encodeURIComponent(document.getSelection())+';

Seulement voilà, il y a IE et document.getSelection(); renvoit une belle erreur javascript. Mais il y a une petite solution très simple qui permet de rendre cette action compatible quelque soit votre navigateur préféré (sous MacOS X, cela fonctionne aussi). Plutôt que de détecter le navigateur (son nom via : navigator.appName), il plus intéressant de détecter la méthode (ou l’objet) dont le fonctionement avec les navigateurs n’est pas possible (ou mal gérée). Ainsi, avec un système conditionnel classique et une nouvelle variable « methodeselection » :


if (document.getSelection) methodeselection = document.getSelection();
else if (document.selection) methodeselection = document.selection.createRange().text;
else return;

Préparé pour une page web, nous pouvons écrire :

function envoyer_une_selection_quelquepart() {
if (document.getSelection) sel = document.getSelection();
else if (document.selection) sel = document.selection.createRange().text;
else return;
location.href='http://www.monsite.fr/?action=ajouteramonforumulaire&
description='+encodeURIComponent(sel)+';
}

Bonne fin de semaine,
Stéphane.

Je profite des vacances pour avancer la mise en place d’ICEberg 4 ! Les tests avancent plutôt bien : il est sûr que préparer la nouvelle version de mon gestionnaire de corpus numériques au bord d’une piscine c’est assez génial : un plouf entre deux class php. Mes deux compagnons de programmation de cette nouvelle version : Romain et Frédéric ont maintenant terminé leur travail, j’ai pris la suite pour assembler les blocs, débuguer, relire, reprendre, améliorer le tout. ICEberg 4 s’appuyera sur MySQL et PHP 4 ou PHP 5 (nous avons prévu les deux versions au cas ou…la version « tout XML » : ICEbergXML reste toujours disponible…). La partie « berg » est nettement plus opérationnelle : les chercheurs maitrisant l’informatisation de leurs propres corpus vont être contents ! la partie ICE reste dans la même idée que celle de la version 3 : nous n’avons changé que de petites choses sur le plan de l’interface. Cependant, le code a été totalement ré-écrit par Frédéric avec des class en PHP 5.

L’autre jour, un chercheur me demandait pourquoi j’avais fait un outil « propre » alors qu’il en existe plein sur le web tel que PLEADE, ARCANE, etc. Je lui est dit qu’il arrive un moment ou il faut développer un outil dédié pour répondre à une demande forte qui apparaît. Il existe Photoshop, pourtant des programmeurs ont développé GIMP ! ICEberg répond à un besoin : la mise en ligne et la gestion de paquets de documents numériques (d’archives, issus de documents actuels, des photos, bref tout type de documents numérisés) en utilisant un gestionnaire de base de données « libre » ou du XML, rien de plus. J’ajoutais qu’il n’y a pas de moteur recherche puissant dans ICEberg, j’en prépare un avec l’aide du CNRS mais il ne sera pas dans ICEberg, mais il fonctionnera au-dessus ; balayant ainsi l’ensemble des corpus numériques, même chose pour le module OAI d’ICEberg.
Ainsi, ICEberg tend toujours vers le plus simple : des modules y sont ajoutés, mais toujours de façon annexe, sans toucher au noyau. Mais de temps en temps, nous réécrivons une nouvelle version de la partie « dure » d’ICEberg : nous y sommes.

Je m’en retour à mon code :-). Bonne soirée, Stéphane.