7
20 fév 2012

News.png C'est une revue de presse bien chargée que nous vous proposons cette semaine. Nous y aborderons comme à l'accoutumée, les sorties de la semaine, mais aussi la possibilité de créer vos applications OpenLayers avec OL Architect, de voter pour les fonctionnalités de LeafLet que vous souhaitez voir implémentées, le nouveau projet de geocodage collaboratif de steve coast, quelques réflexions sur l'Open Data ou encore le nouveau projet de réalité augmentée de Google. Bonne lecture !


Sorties de la semaine

Qgis en version 1.7.4 & LizMap plugins
Pas de grandes nouveautés pour cette nouvelle version de Qgis mais surtout des corrections de bug comme l'indique la note de release.
Par contre, saluons la sortie de deux nouveaux plugins qui devraient grandement vous faciliter votre travail de géomaticien Open Source. Les plugins "Lizmap" et "Lizmap Web Client", tout deux développés par la société 3liz, permettent de publier vos projets Qgis sur le Web. Lizmap s'occupe de la liason entre Qgis Server et Lizmap Web Client. Lizmap Web Client est dédié, comme son nom l'indique, à la partie client et s'appuie sur un ensemble de librairies comme OpenLayers, jQuery. Nous n'avons pas encore pu faire de tests au moment de l'écriture de l'article, mais nous essayerons de vous faire un retour prochainement. Pour plus d'infos sur l'installation ou le paramétrage, n'hésitez pas à consulter la doc associée du plugin Lizmap et de LizMap Client. Enfin, pour un aperçu du résultat final, le mieux est de consulter la démo.


Grass en version 6.4.2
Grass est l'un des logiciels SIG OpenSource les plus anciens mais aussi l'un des plus puissants. A titre d'exemple, au-delà du logiciel lui-même il est utilisé en tant que boite à outils dans QGIS ou comme base de services WPS dans PyWPS. Depuis peu, une nouvelle version (6.4.2) est disponible. En terme de nouvelles fonctionnalités signalons l'ajout ou la correction de 770 mises à jour du code, une interface graphique encore améliorée et surtout le support total du langage python.


PgRouting avec SQLite
Vous utilisez Spatialite et vous aimeriez bien disposer, comme c'est le cas sur Postgis (via PgRouting), de la possibilité de calculer des itinéraires ? Alors, ce post est fait pour vous. En effet, Jorge Osorio a tout récemment mis en ligne sur GitHub la librairie NiuRouting. Celle-ci n'implémente que l'algorithme de Dijkstra pour le moment. Ca serait sympa d'essayer ça avec des données OpenStreetMap ! Des volontaires ?


Côté client

Paramétrer Openlayers via une interface web
Il y a quelques années, nous avions annoncé un outil nommé OL Architect. Celui-ci renait de ses cendres. Allez sur cette nouvelle démo pour apprécier. Son principal intérêt n'est pas tant dans le fait que le code soit généré mais par le fait de faire la correspondance visuelle entre paramètres et code. Cela paraît être idéal pour comprendre ce qu'on fait quand on débute. Nous en profitons pour vous faire partager cette vision avec une présentation avec démo html 5 bluffante (mais non cartographique) qui reprend bien cette idée de correspondance code et visuel Revenant à OL Architect, il faut aussi noter que ce projet est porté par Erik Hazzard, l'auteur de "OpenLayers Beginner Guide" et que le code de l'application est maintenant disponible sur un dépôt Github.


Générer une carte stylisée
Dans la continuité de notre recherche d'informations sur OL Architect, nous avons poursuivi notre tour du dépôt Github de Erik Hazzard. Nous avons trouvé un générateur de cartes mais où la représentation cette fois-ci n'est pas du tout classique bien qu'automatisée. Elle reprend l'idée de créer une carte de continents par idées et par importance associée à cette idée en s'inspirant du site xkcd.
Le résultat est observable en moins de 2 min chrono sous Linux. Faites un git clone https://github.com/enoex/Data_Map_Generator.git puis cd Data_Map_Generator, ensuite faites python -m SimpleHTTPServer 8888 et lancez votre navigateur à l'adresse localhost:8888/
Vous observerez le résultat ci-dessous (Sous chrome OK mais pas sous notre version de Firefox)


Data map generator

Leaflet, votez pour vos fonctionnalités
Leaflet, se propose d'inclure sa communauté d'utilisateur au sein de son processus de développement. Pour cela, il vous suffit de vous rendre sur la page Leaflet User Voice et de suggérer ou voter pour les fonctionnalités que vous désirez. Je trouve l'initiative particulièrement intéressante. Néanmoins, ce qui me fait sourire c'est que la plupart des demandes existent déjà dans OpenLayers. De ce fait, est-il pertinent d'avoir deux projets clones ? Surtout que la popularité de leaflet est basée sur sa simplicité et son faible poids. On verra bien ce que nous réserve l'avenir de ces deux API (ce n'est d'ailleurs pas la première fois que la question se pose)


OpenData et OSM

Un géocodeur collaboratif
Après OpenStreetMap, le nouveau projet de Steve Coast se nomme OpenGeocoder. Le principe est comme le nom du projet l'indique, de proposer un service de géocodage complètement libre. Pour cela, si vous effectuez une requête (ex : Nice, France) est que cette information n'est pas dans la base, vous êtes alors invité à définir l'emprise spatiale de la zone désirée. Le fonctionnement est simple et intuitif. Côté programmation, sachez qu'un dump de la base de géocodage est disponible ainsi qu'une API. Celle-ci s'utilise très simplement via une url (ex : http://www.opengeocoder.net/api/0.1/search?query=Redmond,%20Washington) qui nous retourne alors le résultat ci-dessous :


{"id":16,"querystring":"redmond, washington",
"bbox":[-122.12612490061538,47.682770031074355,-122.10370325427419,47.692444621976811]}

J'aurais par contre un petit bémol à soulever. En effet, lors de nos tests, nous avons effectué plusieurs requêtes similaires (ex : le port, ile de la Réunion; le port, la Réunion; le port, Réunion). Pour le service, il s'agissait de trois requêtes différentes et il me proposait donc à chaque fois de définir l'emprise géographique. Il y aurait peut-être une petite amélioration à faire de ce côté. Il faut maintenant espérer qu'OpenGeocoder est le même succès qu'OpenStreetMap. Tiens en parlant d'OSM, c'est étrange de ne pas pouvoir choisir cette couche de données sur l'interface d'OpenGeocoder non ? L'explication donnée par Steve Coast est que les résultats d'OpenGeocoder tombent dans le Domaine Public ce qui est incompatible avec la licence d'OSM. J'avoue ne pas avoir tout compris...


Google, "Evil or Not" sur l'OpenData?
A l'heure où Google entraîne par la passage à une API payante pour Google Maps quelques mécontentements, nous vous proposons de voir quelques points de vue sur les liens entre Google, OSM et l'opendata. Nous commençons avec ce texte qui reprend la polémique sur l'utilisation de Google Map Maker par la Banque Mondiale avec un appel à contributions du public mais les droits des données reversés à Google (inhérent à Map Maker, pas nouveau en soi). Cette polémique est liée à l'association d'idées "Banque Mondiale = pour le bien public" ce qui paraît assez incohérent par rapport aux faits que les citoyens qui mapperont ne pourront rien refaire des données. Nous continuons par un point de vue plus balancé qui montrerait plutôt une complémentarité Google et OSM nommé Google is not the Enemy. Il est toujours intéressant de voir le positionnement de Google par rapport, les temps étant de plus en plus à la coopétition. C'est pourquoi pour nous, cette polémique risque de devenir récurrente à l'avenir.


OpenData, quelques réflexions philosophiques sur son lien (ou non-lien selon les avis) avec le citoyen
Nous relayons un article intitulé Le citoyen a-t-il une place dans l’open data ?" qui pose une question fondamentale : à l'heure où on avance le lien entre citoyenneté, opendata et transparence (pour les curieux, voir le concept d"'empowerment" en anglais), où en est-on réellement en France? Nous vous proposons aussi de voir cette vidéo dont certaines idées sont intéressantes même si on reste plus loin du point de vue pragmatique et opérationnel de l'article juste avant.


Arts, sciences humaines et cartographie

De belles cartes, tout simplement
Si vous aimez les belles cartes, cette collection sur Tumblr intitulé Cartophile ne pourra que vous retenir. Si vous n'êtes pas contemplatif mais plutôt actif, un excellent article sur comment faire des cartes lisibles et agréables à l'oeil. Enfin, pour finir dans cette partie, nous vous invitons à apprécier ces cartes satyriques très figuratives des rapports entre pays datant du début du 20ème siècle.


"Digital humanities"
Nous avons préféré reprendre ce terme car il est plus riche et propre au langage anglais (pour en savoir plus, allez sur cet article). Il s'agit de l'application aux sciences humaines des sciences informatiques de manière simplifiée. Ainsi nous vous invitons à faire un tour de cette compilation d'applications possibles en utilisant les SIG. Plus de 80 cas à apprécier :)


Tendances

Vers la réalité augmentée avec Google
Google malgré beaucoup de critiques continue à innover dans le géospatial. On a commencé à voir surgir sur nos téléphones mobiles depuis déjà quelques années des applications de réalité augmentée. Google semble prendre aussi ce chemin: la compagnie bien que ne souhaitant pas encore communiquer à ce sujet serait en train de développer des lunettes qui permettraient de profiter de la réalité augmentée. Vous verriez ainsi le monde en vous prenant pour Terminator. Plus d'informations sur ce billet de blog du New York Times.


Autres

R à toutes les sauces
Si vous êtes assidu de nos revues de presse, vous savez que nous accordons un intérêt à l'analyse de données. Nous vous proposons de voir l'intérêt que R prend non seulement pour cela mais aussi pour la visualisation. Ainsi, nous vous invitons à consulter l'article "Coming of Age: R and Spatial Data Visualisation". Si vous souhaitez utiliser R, une interface graphique nommée SpatialDeducer est maintenant disponible pour les aspects cartographiques comme annoncé sur ce billet
Si vous avez déjà un peu utilisé R , ce billet vous donnera un peu de code pour faire quelques essais un peu avancés. Enfin, si vous êtes un complet débutant, nous vous invitons à lire R pour les sociologues qui contient plusieurs chapitres sur la partie SIG de R. Il donnera les bases sur R si vous n'êtes pas tombé dans les statistiques quand vous étiez petits.


Rentrez dans les rouages du SIG
Soyons clair, cet article s'adresse plutôt aux gens qui par goût ou par obligation s'intéressent à la complexité technique derrière les SIG. Ainsi, nous vous proposons de consulter le livre "Map Projections: A Working Manual" publié par l'USGS (United States Geological and Survey) en 1987. Bien qu'ancien, son contenu est toujours d'actualité. Il vous permettra d'approfondir un peu les questions que vous vous posez parfois sur les projections.
Nous continuons en vous proposant de vous rendre sur le site R-tree Portal qui vous permettra d'apprendre plus sur l'indexation des données géométriques qui permet d'avoir des requêtes spatiales rapides. Ce site se destine plutôt à des personnes ayant des compétences informatiques pour travailler dans le bas niveau des SIG. Pour ceux qui ne voient pas à quoi correspondent un rtree, nous les invitons à (re)lire cette page du cookbook spatialite


A propos de l'auteur: 
GeoTribu

Toute l'actualité de la géomatique Open Source ! Mais aussi des tutoriels, des billets de blog, des tests et surtout une bonne humeur géographique !

Commentaires

Certes, c'est toujours bien de revenir sur le fondamentaux, mais une fois par an à la même date, ça cache quelque chose...

http://geotribu.net/node/348

++
Jérôme

Je vois que nous avons un très fidèle lecteur :)
A un an d'intervalle il fallait le remarquer !
Néanmoins, un rappel de cet ouvrage incontournable n'est jamais une mauvaise chose.

Arnaud

Il est aussi vrai qu'on traite tellement d'informations dans une année qui oublie parfois de vérifier qu'on a pas déjà fait cette annonce :)
Après, il faut répéter pour que ça rentre comme dirait certains de nos anciens enseignants.

Thomas

Bonjour,

Une petit commentaire à propos de Leaflet et de la question de son intérêt vis à vis d'OpenLayers. L'intérêt de commencer un nouveau projet alors qu'il existe déjà un projet équivalent est souvent multiple : par jeu, par volonté de partir sur des bases propres plus modernes (le cas de Leaflet a priori), par l'utilisation d'un langage différent ou d'un objectif un peu différent (GeoServer vs MapServer).

Généralement ces projets apportent une nouvelle dynamique car en multipliant les projets on multiplie les points de vue, les manières de codé tel ou tel fonctionnalité. C'est rarement une mauvaise chose (mais ça peut). Dans le cas de Leaflet je pense que c'est un bonne chose mais contrairement à ce que tout le monde peut être amené à penser, Leaflet et OpenLayers sont deux projets encore très différents et tout deux très dynamique.

Au niveau des fonctionnalités OpenLayers a encore beaucoup d'avance mais on peut se demander si Leaflet va gérer les mêmes sources de données ? Y a t'elle intérêt ? Pas forcément. Notamment parce qu'OpenLayers se doit d'avoir une gestion compatible des anciennes fonctionnalités (le type de couche Markers pour donner un exemple) il y a donc des sources de données qui ne sont/ne doivent plus être utilisé.

Au niveau du poids : OpenLayers offre une très grande souplesse d'utilisation par la construction de build personnalisé. À fonctionnalité égale le poids de la lib d'OpenLayers est équivalente à celle de Leaflet.

Bref, Leaflet se doit de poursuivre son chemin car il permet une saine concurrence entre les deux projets.

Je suis tout à fait d'accord avec votre analyse. Leaflet et OpenLayers doivent être vues par les utilisateurs comme complémentaires. Après tout, un peu de compétition amicale entre ces deux librairies ne peut être que bénéfique !

Arnaud

Hi, it's Vladimir, Leaflet maintainer - thanks for mentioning it. :) Just wanted to comment on the UserVoice initiative and OpenLayers comparison...

What makes really great products stand out is not the sheer amount of features but rather the quality of each feature, the design and attention to every little detail. I doubt Leaflet will ever get noticeably bigger than 25kb of compressed JS (I may even cut out some already present features into plugins) - instead, as 95% of functionality I planned for Leaflet is already there and it doesn't need much more that that, I'm focusing on perfecting the basic and most important things - improving speed, usability, responsiveness, simplicity, ease of use, stability and browser compatibility.

The main reason for creating the UserVoice is to give users who already chose Leaflet some perspective on features they occasionally need, letting them know if a feature is ever going to be implemented (and most suggestions won't be), if not, why, and if yes, then if it's going to be a part of the core or a separate plugin, to give me a better understanding about how users use the library so I could improve it (without necessarily adding something new but often reworking and improving what's already there), and to give third-party developers a good perspective on what plugins to develop.

Hi Vladimir,

Thank you for your intervention on this blog.
My objectives to compare OpenLayers and Leaflet was not to say that one is better than an another. But I would like to highlight the fact that OpenLayers already exists with a huge quantity of functionnalities. If another library (as leaflet) want to have the same succes, it must explore something else that we already have.
I must agree that the lealfet code is very good with a great API. It's really a pleasure to create an application with leaflet.
Now for the user's voices, I've got just two words : "thank you". It's a really great initiative. Usually we must go on a mailing list and it's not easy for people who doesn't know the Open Source world.

Thank you again to share your work with the community.

Sincerely,

Arnaud