S'abonner au Flux RSS

Sous-catégories

jeudi, décembre 5 2013

Rejoindre la GeoTribu

C'est avec plaisir que j'ai rejoint cette semaine la joyeuse équipe de la GeoTribu ; je publierai désormais mes articles liés à la géomatique sur www.geotribu.net et continuerai par contre à publier ici tout ce qui est lié à mon activité sur les tests de performance et mes contributions à Tsung.

Je vous laisse le soin de découvrir le premier billet publié intitulé Temps de réponses comparés OSRM vs GraphHopper

vendredi, juin 22 2012

L'OpenData toulousain

La communauté urbaine de Toulouse à récemment lancé son portail des données libres, le site accessible sur http://data.grandtoulouse.fr/ dispose à la date de publication de ce billet de 48 jeux de données couvrant des domaines comme l'éducation, les résultats électoraux ou encore la topographie avec l'altimétrie des voies. Je ne suis pas toulousain mais je me suis tout de même penché sur les données publiées avec un regard de bon père de famille, j'ai pour cela regardé de près les données liées aux écoles et aux équipements sportifs.

Pour les tout petits on trouve les coordonnées des crèches sur la commune de Balma, de même que pour les équipement sportifs seules cette ville a mis ses données à disposition semble-t'il. Pour les écoles on dispose déjà de beaucoup plus d'informations 90 écoles élémentaires publiques et 105 maternelles, cela donne déjà plus de données à analyser, au passage je ne note aucune donnée sur Blagnac dans ces fichiers. Je n'ai pas trouvé de données pour l'enseignement supérieur, ni collèges ni lycées, le portail étant jeune gageons qu'il gagnera en exhaustivité avec le temps.

Sur les formats de données c'est un peu disparate il ne faut pas hésiter à retraiter, les données géographiques sont parfois en 2 dimensions, parfois en 3. Les fichiers kmz ne sont pas directement exploitables pour les conversions, certains champs de données contenant directement du code HTML par exemple. Les fichiers CSV contiennent parfois une colonne avec les coordonnées géographiques parfois non. Le bilan global reste tout de même positif, même si il a fallu parfois utiliser les fichier MapInfo, parfois les kml, parfois les CSV pour obtenir un résultat homogène, mais sur l'ensemble j'ai réussit à récupérer les données que je cherchais dans ce qui était publié.

L'ensemble de ces données a été mise en oeuvre sur une carte en ligne.

Dernier point les données ont été publiées sous licence Open Data Commons Open Database License.

Merci à la CU de Toulouse et vivement la suite des données ....

PS : je cherche toujours le lien direct pour télécharger les fichiers sans passer par l'interface web

jeudi, décembre 15 2011

Déployer Geoserver 2.1.2 avec Tomcat7 sur Debian Squeeze

Le but de ce mini tutoriel est de mettre en oeuvre la dernière version stable de GeoServer sur une Debian/Squeeze avec Tomcat7. C'est aussi une façon pour moi de conserver la méthode, car n'étant pas de culture javaiste c'est toujours difficile de se replonger dans la logique Tomcat et ses multiples emplacements de fichiers de conf.

Tomcat7 n'étant pas disponible dans Squeeze (il l'est dans wheezy) nous allons utiliser un backport disponible sur mon dépôt non-officiel, voir ce billet pour la mise en oeuvre du dépôt. Une fois le dépôt configuré et apt-get udpate effectué comme il se doit on va installer les 2 paquets suivants ; tomcat7 pour la base et tomcat7-admin pour disposer de la webapp manager bien pratique.

apt-get install tomcat7 tomcat7-admin

Après l'installation des paquets le serveur se lance automatiquement et vous devez obtenir le classique It works ! à l'adresse http://127.0.0.1:8080/

Pour le déploiement de GeoServer nous allons utiliser le manager interne de Tomcat, il est nécessaire pour cela de définir un utilisateur avec les bonnes permissions en éditant le fichier /etc/tomcat7/tomcat-users.xml. Nous allons y ajouter un utilisateur foobar avec le mot de passe barfoo, cela va consister à ajouter les 2 lignes suivantes :

<role rolename="manager-gui"/>
<user username="foobar" password="barfoo" roles="manager-gui"/>

Le fichier contient des exemples qui aident à suivre la bonne syntaxe, ce qui est important ici est le rôle manager-gui.

La configuration par défaut de tomcat limite la taille des fichiers web archive à 50Mo, hors la taille du .war de geoserver dépasse cette limite, il faut par conséquent l'augmenter. Il faut pour cela éditer le fichier /usr/share/tomcat7-admin/manager/WEB-INF/web.xml. Recherchez les balise <max-file-size> et <max-request-size>, puis remplacez leur valeur par 78643200 soit 75MB de limite au lieu des 50MB par défaut.

La dernière version de GeoServer stable est la 2.1.2 qui est disponible en ligne à l'adresse http://geoserver.org/display/GEOS/Stable, il convient de télécharger la version Web archive. Vous obtiendrez un fichier geoserver-2.1.2-war.zip qu'il conviendra de décompresser.

Maintenant que nous avons installé et configuré Tomcat, téléchargé le .war de GeoServerger, nous pouvons ouvrir le manager à l'adresse http://127.0.0.1:8080/manager/html et y rechercher le formulaire Déployer comme le montre l'image suivante.

tomcat-war.png

Indiquez l'emplacement du fichier .war dans le champs nommé Choisir le fichier WAR à téléverser et cliquez sur Déployer, si tout se passe bien ça y est GeoServer est installé.

Il reste à tester l'url http://127.0.0.1:8080/geoserver/web/ et hop Geoserver 2.1.2 sous Tomcat7.

De base GeoServer contient un ensemble de données de test, regardez le lien à gauche Prévisualisation de la couche et appréciez la richesse de l'outil.

Pour se connecter en tant qu'admin sur GeoServer utilisez les login/pass par défaut admin/geoserver, ceux-ci sont définis dans le fichier /var/lib/tomcat7/webapps/geoserver/data/security/users.properties.

Il est à noter que cette méthode bien que valable dans le principe pour Tomcat6 certain emplacement de fichiers sont différents dans la pratique.

vendredi, décembre 9 2011

Registre parcellaire graphique en OpenData et BadData

Nombreux sont ceux qui comme moi se sont réjouit de l'ouverture de la Plateforme française d'ouverture des données publiques ce lundi avec ces 352.000 jeux de données. Sa naissance a même été saluée par data publica qui en a fait un inventaire exhaustif, il reste maintenant à faire une analyse qualitative de ceux-ci.

J'ai pour ma part essayé le jeu de données du registre parcellaire graphique qui recense plus de 6 millions de parcelles déclarées par les exploitants agricoles avec la culture majoritaire de l'année à l'échelle de la France. On trouve sur data.gouv.fr les données pour l'année 2010 au format shapefile directement exploitable par les outils SIG. L'utilisation de ce format est a saluer car il facilite de fait la réutilisation des données et surtout leur visualisation sans pré-traitement.

Jusque là tout va bien, le hic c'est que les shapefiles contiennent des erreurs, chaque parcelle (îlot) est représentée par un polygone regoupés dans des shapefiles par département, mais une fois ces shapefiles intégrés à une base postgis les outils de rendus (geoserver utilisé ici) ne peuvent effectuer leur travail à cause de géométries invalides (Ring Self-intersection, Points of LinearRing do not form a closed linestring, ...), ce qui rend les données un peu moins attractives de prime abord.

Après une analyse détaillées des 92 fichiers représentant les données de l'hexagone on note une moyenne de 0.26% de géométries invalides par fichier avec un maximum de 0.94% sur le département de la Mayenne, pour au total 0.29% d'erreur. Ces chiffres paraissent ridiculement petit mais lors du rendu par tuilage un polygone défectueux en plein milieu rend la tuile vide, à l'échelle de la France on obtient rien sur la carte. Après suppression des erreurs de la base on arrive tout de même à faire un rendu comme celui-ci, sympa toutes ces couleurs ;-) Maintenant vous savez ce qu'il y a eu dans le champs à coté de chez vous si vous avez la chance d'habiter à la campagne.

Le fichier de statistiques complet est attaché au billet

NB : le RPG est disponible sur le geoportail pour les années 2007 à 2009, pour pas aussi sur data.gouv.fr, on pourrait mesurer ainsi la perte de surface agricole année par année.

mardi, novembre 29 2011

Installer mapnik2 sur Debian Squeeze

La version de mapnik disponible dans squeeze est actuellement la 0.7.1 alors que la version 2.0 de Mapnik est déjà disponible pour Wheezy, j'ai backporté les paquets nécessaires pour faire du rendu avec mpanik2 pour la version squeeze de debian. Les .deb sont disponibles au téléchargement sur http://osm.fsffrance.org/debian-backports/

Un README détaille les étapes et les dépendances pour installer Mapnik2 sur votre Debian Squeeze.

jeudi, novembre 17 2011

Remplir ses caches sur plusieurs niveaux de façon smart

J'utilise tilecache pour générer des tuiles à la volée sur des rendus plus ou moins complexe, et pour réduire un peu la charge du serveur de rendu j'ai mis en place des caches (avec varnish) au devant de celui-ci. L'architecture de cache repose sur 2 niveaux, un cache en frontal direct non public, et 3 caches devant celui-ci qui sont appelés pas les clients OpenLayers (ou autres) et ouvert sur le net. L'intérêt des 3 caches est de bénéficier de l'astuce bien connu des a.tile.., b.tile.., c.tile bien connu des utilisateurs d'OpenStreetMap. Avec tilecache est fournit tilecache_seed qui permet de remplir les cache mais celui-ci ne remplissait pas entièrement mon besoin. En effet il me faut remplir les 3 caches publics, avec l'ensemble des layers rendus et ceci sans mettre à genoux le serveur de rendu. Idéalement l'opération se ferait en une passe sans avoir à ancer plusieurs commandes à la suite. Pour cela j'ai écrit un script perl qui rassemble toutes ces fonctionnalités plus quelques autres.

Le script permet de spécifier autant de serveur à remplir que souhaité, un ensemble de cache à générer, une bbox sur la zone voulue, et un couple de zoom min et max. Lors du lancement le script va extraire un premier serveur du groupe de serveurs indiqués, il va ensuite boucler pour générer tous les layers sur ce serveur sur la première tuile du zoom min, de cette façon le cache en frontal de la machine de rendu va se remplir. Ensuite il va appeler les mêmes tuiles sur les autres serveurs, à cet instant nous avons donc dans tous les caches, tous les layers dans l'espace d'une tuile. Le script va ensuite boucler de même pour toutes les autres tuiles en descendant dans les niveau de zoom après avoir complété le précédent.

Des problèmes fréquemement rencontrés avec des processus comme les remplissage de cache, la saturation du backend, la rupture d'un élément obligent à tout reprendre ou stopper le processus. J'ai essayé d'être le plus smart possible et de faire en sorte que le script aille le plus loin possible en générant le moins d'erreur, les mécanismes mis en oeuvre sont décrits ci-dessous :

  • suppression automatique d'un serveur défaillant, en cours de remplissage un des serveurs caches fait défaut, au bout de 10 réponses consécutives en erreur le serveur est ignoré et le remplissage continu sur les autres normalement
  • réduction de la sollicitation du backend, en cours de remplissage si le serveur source surcharge, à chaquer erreur 503 reçues le remplissage ralentit, le temps d'attente entre tuiles est augmenté afin de réduire la charge endurée. De même au bout d'un nombre de requête sans erreur le temps d'attente est réduit pour éviter un de traitement trop long. Si le temps d'attente dépasse un seuil le processus prend fin.
  • une option simulate permet de se rendre compte avant de le faire que l'on va faire plus de 3 millions de requêtes HTTP, des fois cela peut-être long :-)

Bien évidemment le script peut-être utlisé au plus simple avec un layer et un seul serveur de cache en direct, si vous n'aimez pas tilecache_seed.

Le script est nommé fill-cache.pl (original) et publié sur Gitorious dans le projet osmtools

Comme tout script/programme celui-ci n'est évidemement pas finit et peut être amélioré, alors comme il est libre, profitez-en, contribuez ! Si vous ne codez pas et avez l'idée de génie, un petit commentaire sur ce billet pourrait voir vos voeux se réaliser.

mardi, mai 24 2011

Leaflet la sobre, OpenLayers la gourmande

En utilisant Leaflet sur quelques pages de test je trouvais son comportement assez rapide en comparaison à OpenLayers, voulant comprendre ce qui pourrait expliquer ce sentiment j'ai décidé de mesurer le nombre de tuiles téléchargées par chacune des librairie pour une utilisation identique. J'ai pour cela monté ce soir un rapide test que je vous livre ici.

Le protocole de test est le suivant, une page contenant 2 cartes identiques de 512px par 512px, une pour LeafLet et l'autre pour OpenLayers. Les deux cartes sont déplacées simultanément en appelant des commandes identiques.

Les commandes de déplacement sont décrites ci-dessous avec à chaque fois le nombre de tuiles totale téléchargées depuis le début du test comptées depuis le serveur web.

Au chargement de la page

  • Leaflet : 9 tuiles
  • OpenLayers : 42 tuiles
  • ratio : 4.6

Deux zoom out :

  • Leaflet : 27 tuiles
  • OpenLayers : 126 tuiles

Deux zoom in (toujours sans changer de position) :

  • Leaflet : 27 tuiles
  • OpenLayers : 192 tuiles

Déplacement d'un degré au nord puis d'un degré à l'est

  • Leaflet : 33 tuiles
  • OpenLayers : 212 tuiles

Deux zoom in

  • Leaflet : 51 tuiles
  • OpenLayers : 296 tuiles

Pan de 100px à gauche, puis 100px en bas

  • Leaflet : 54 tuiles
  • OpenLayers : 316 tuiles
  • ratio : 5.85

Là le match est sans appel, Leaflet gagne haut la main dans le registre de la sobriété. Mais si OpenLayers déborde sur les cotés alors la différence va s'amenuiser lors d'une ballade sur la carte. Ce que j'ai fais en tournant un peu en rond, quelques zoom out et in pour me recentrer et au final après une visite autour d'un point fixe on obtient :

  • Leaflet : 182 tuiles
  • OpenLayers : 1449 tuiles
  • ratio : 7.96

La ratio final de 7.96 comparé au ratio inital de 4.6 lors du chargement de la page me laisse un peu pantois sur l'efficacité du chargement des tuiles périphériques par OpenLayers.