neogeo

Malgré des rengaines récurrentes tendant à confondre logiciel libre et logiciel gratuit (ou Free Software et freeware, l’anglais étant encore plus ambigu que le français en la circonstance), un exemple récent illustre qui si la question du coût logiciel ne peut être évacuée, elle n’est pas centrale dans la problématique OpenSource.

L’association (”educationnal charity” en anglais, à but non lucratif donc) Oxford Archeology vient d’être notifiée par ESRI qu’elle ne pouvait plus se prévaloir des remises “éducation” pour ses licences ArcGIS car les associations étaient désormais exclues de ce périmètre. L’association, qui utilise 60 postes de travail sous ArcGIS, verra ses licences actuelles désactivées à la fin du mois (!), à moins de s’acquitter des tarifs “standard” d’ici là. Comme Oxford Archeology n’a pas les moyens de poursuivre avec ESRI, elle réfléchit à un basculement vers des solutions OpenSource. Question de coût donc ? Pas que. Car des logiciels propriétaires plus abordables pourraient être envisagés. Mais question de liberté surtout. Car tout autre logiciel propriétaire, s’il pourrait alléger les coûts, ne changerait pas la situation de base : la totale dépendance de l’utilisateur vis-à-vis de la politique commerciale (tarifs, conditions d’utilisation) et industrielle (mises à jour, correctifs, support…) de son éditeur, donc la subordination de son activité, et partant de là de son coût de revient et de sa productivité, à un tiers.

L’OpenSource a une approche inverse : mettre à la disposition de tous des outils informatiques et des ressources permettant à chacun d’être indépendant, autonome et libre dans leur utilisation :

“Free software is software that gives you the user the freedom to share, study and modify it. We call this free software because the user is free.” (Free Software Foundation)

Cela a parfois un coût aussi, direct ou induit, mais c’est celui de la liberté.

PS : ESRI a trouvé bon de faire remarquer à Jo Cook, auteur de l’article sus-mentionné dans son blog personnel, que les négociations en cours pourraient se trouver compromises par les propos tenus dans son blog. Liberté je vous dis !

via Technical Ramblings

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…

Suite au commentaire de l’article précédent par Thomas Bonfort , principal maître d’oeuvre de l’intégration d’AGG dans MapServer, j’ai refait les tests avec la version trunk de MapServer, future version 5.1…

Ce qui nous donne (accrochez-vous…):

• Sur le Finistère, communes BDCarto(c), AGG :
  real 0m0.271s
  user 0m0.200s
  sys 0m0.080s
• Sur la France entière, communes BDCarto(c), AGG :
  real 0m1.962s
  user 0m1.880s
  sys 0m0.090s

Les performances ont donc été multipliées par 12 (!!!), et sont désormais nettement supérieures à celles de Mapnik pour les gros jeux de données (mais très comparables sur les petits volumes).

Thomas indique également la prochaine possibilité de tracer des traits plus fins dans le rendu AGG, comme c’est déjà le cas pour Mapnik.

Toutes nos félicitations à l’équipe de développement de MapServer et particulièrement à Thomas Bonfort donc, pour cette significative amélioration des performances.

La récente adoption du format AGG par MapServer (depuis la version 5) l’a doté d’une qualité de rendu qui lui a longtemps fait défaut.

Côté rendu, MapServer a ainsi rejoint une solution plus récente, encore mal documentée, mais prometteuse : Mapnik. Bibliothèque C++ avec une API en python, celle-ci a fait de la qualité graphique une de ses priorités. Elle intègre donc également la bibliothèque AGG (AntiGrainGraphics) permettant de lisser les PNG.

Autant le dire tout de suite, les images produites sont strictement identiques, au pixel près ! Cependant, côté performances, Mapnik est un peu plus intéressant, comme en témoigne ce petit test réalisé sur une machine tout ce qu’il y a de standard pour générer l’image des communes de la pointe du Finistère ci-dessus :

• MapServer :
  real 0m0.382s
  user 0m0.310s
  sys 0m0.070s
• Mapnik :
  real 0m0.244s
  user 0m0.200s
  sys 0m0.050s

Mapnik s’acquitte donc de la tâche en 1/3 de temps en moins, pour un résultat, rappelons-le, strictement identique. On retrouve un écart d’autant plus significatif que le jeu de données est important. Sur la France entière, communes BDCarto(c) :

• Mapserver :
  real 0m25.415s
  user 0m25.330s
  sys 0m0.080s
• Mapnik :
  real 0m13.673s
  user 0m13.630s
  sys 0m0.040s

C’est preque un facteur 2 qui sépare les deux applications. Alors, MapServer K.O. debout ? Pas si sûr, car le rendu AGG étant souvent utilisé dans un contexte de tuilage et de cache disque (voir par exemple OpenStreetMap) le temps de génération a certes une importance mais pas de manière aussi critique que sur du rendu “live”. L’AGG est un peu trop lent pour être utilisé dans un tel contexte, et il faut souvent se contenter dans ce cas d’une simple rendu PNG standard. Mais les performances sont alors exceptionnelles :

• MapServer, format PNG 256, communes BDCarto(c) France entière :
  real 0m0.638s
  user 0m0.560s
  sys 0m0.070s

6 dixièmes de seconde pour dessiner les 36500+ communes de France en 600 x 600, c’est remarquable, et peut tenir la dragée haute à bien des SIG desktop (faites vos tests…). Mapnik ne fonctionnant qu’en mode AGG, il ne peut atteindre de tels résultats. De sorte que son rayon d’action se trouve fortement réduit, à la différence d’un MapServer avec lequel on peut jouer avec les différents formats de sortie pour optimiser le rendu ou la rapidité selon les besoins, l’échelle, la couche, le contexte (visualisation / impression) etc.

Petite mise à jour de la carte de localisation des stations de Vélôs de Toulouse aujourd’hui, avec quelques améliorations :

• utilisation de tilecache pour les rasters
• récupération des données de disponibilité des vélos en temps réel depuis le webservice de l’application de la ville

Et après ? au programme une version dédiée téléphone mobile. Parce que c’est bien de connaître la disponibilité depuis chez soi sur internet, mais c’est mieux de pouvoir la consulter quand on cherche un vélo dans la rue ! Les beta-testeurs sont les bienvenus.

Au chapître des nouveautés webmapping, PortailSIG nous fait découvrir aujourd’hui deux superbes applications :

• Le PLU du Grand Lyon, sous OpenLayers, fluide et esthétique
• Le nouveau portail INSEE des statistiques locales, avec une partie cartographique en Flash(Géoclip). Excellent outil de géostatistiques, d’une grande rigueur et d’une grande richesse fonctionnelle et surtout impressionnante liste de données consultables ET téléchargeables. Dommage que le plugin Flash ne puisse afficher une France communale en entier, car ce niveau d’analyse garde toute sa pertinence à petite échelle.