One more geek - Mot-clé - ll

PyDeb from PyPI to .deb

Rodolphe Quiédeville — Wed, 06 Feb 2013 13:01:00 +0100

Dans mon précédent billet j'évoquais les paquets debian que j'avais réalisé pour Django au sein du projet Pyrede. Cette activité de packaging ayant pris de l'ampleur les paquets seront désormais disponibles au sein du Projet Pydeb.

Le projet PyDEB se compose d'un dépôt de paquets et d'un blog sur lequel je publie les nouveaux paquets ainsi que leurs mises à jour.

Les derniers paquets réalisés sont redis, hamlpy, vectorformats, ...

Le projet Pyrede d'analyse de fichier requirements.txt continue son activité avec PyDEB comme ressource bien évidemment.

Les serpents ne dorment pas l'hiver

Rodolphe Quiédeville — Thu, 17 Jan 2013 11:09:00 +0100

Au cours du développement de mon dernier projet Pyrede j'ai mis en place des statistiques sur le flux de mises à jour des paquets python dans PyPI. Au bout de quelques jours de collecte de données je suis impressionné par l'activité des développeurs. La base contient à ce jour plus de 27000 paquets et ce sont prêt de 300 paquets qui sont mis à jour chaque 24H.

Les stats avec munin sont publiques et consultables ici

Happy hacking !

De whoosh à Solr avec Django Haystack

Rodolphe Quiédeville — Thu, 20 Dec 2012 12:43:00 +0100

Sur un déploiement Django avec une indexation réalisée avec Haystack je me suis retrouvé face à un problème bloquant. L'application doit permettre à différents users unix de la machine d'insérer des données au moyen d'une commande de management de Django ; les objets insérés dans la base de données sont indéxés en temps réels avec un RealTimeSearchIndex. Le peu de volume de données avait orienté le choix du backend d'indexation vers whoosh, whoosh travaillant avec des fichiers locaux l'appel de la commande manage par différents users unix a engendré des problèmes de permissions sur les fichiers d'index. Une première solution de contournement a été d'utiliser la commande sudo mais cela n'est pas satisfaisant sur le long terme sans une formation des utilisateurs à sudo, pour contourner ce problème je me suis orienté vers l'utilisation d'un backend Solr. Je vais décrire ici la mise en oeuvre de cette solution sur une Debian Wheezy car cela ne s'est pas fait sans problèmes.

Installation de Solr

Le choix fait a été d'utiliser Solr avec le server d'application Jetty, l'installation sous Debian est toujours aussi simple qu'apt-get dans notre cas de figure ici il est nécessaire d'installer les paquets

jetty
solr-jetty

Le serveur d'indexation étant sur une machine séparée de l'instance Django il faut également installer le package python-pysolr sur le serveur qui fait tourner l'application Django elle même.

Il existe un bug dans le paquet solr-jetty, l'installation créé un lien symbolique cassé.

/var/lib/jetty/webapps/solr doit pointer vers /usr/share/solr/web et non vers /usr/share/solr/webapp comme le fait l'installation du package

Schema généré non conforme

Une fois le serveur installé il faut configurer Solr en conformité avec les données de l'application Django, pour cela on génère un fichier nommé schema.xml avec la commande :

manage.py build_solr_schema > schema.xml

Une fois ce fichier généré copiez le sur le serveur Solr dans /etc/solr/conf/schema.xml

J'utilise une version 2.0.0 de Haystack et il est nécessaire de modifier quelque peu le fichier généré pour le rendre compatible avec Solr 3.6.0 présent à l'heure d'écriture de ce billet dans Wheezy.

Tout d'abord il faut remplacer la chaine stopwords_en.txt par lang/stopwords_en.txt pour spécifier le bon chemin vers le fichier. (ref)

Un autre problème rencontré qui peut ne pas être votre cas,mais autant le signaler au cas où, lors du premier appel de la commande ./manage.py build_solr_schema le fichier schema.xml généré contenait des définitions de champs erronés :

<field name="" type="" indexed="True" stored="True" multiValued="" />

<field name="" type="" indexed="True" stored="True" multiValued="" />

Un nouvel appel à build_solr_schema a cette fois généré un fichier valide, une fois copié sur le serveur solr l'indexation fonctionne, et on peut désormais mettre à jour l'index avec manage.py rebuild_index de même que celui-ci se met à jour lors de l'import des objets dans la base.

Suivant votre configuration réseau vous pourrez vouloir changer le port ou l'interface d'écoute, cela s'effectue dans le fichier /etc/default/jetty ; il ne reste plus enfin qu'à redémarrer jetty.

Ce ne fût pas sans peine, mais au final l'indexation fonctionne et désormais tous les utilisateurs peuvent indexer leurs documents sans problèmes de permissions.

Passer le temps en geekant

Rodolphe Quiédeville — Wed, 12 Dec 2012 11:32:00 +0100

Un inconvénient d'être freelance et que l'on a parfois du temps chômé entre les missions, l'avantage quand on est geek c'est que cela donne du temps pour geeker :-) J'ai donc profité de ces derniers jours pour assouvir mon envie de jouer avec icecast ; depuis toujours passionné de radio il me tardait de trouver l'idée qui me permettrait de créer un projet autour de cet outil. Deux autres éléments ont été à l'origine de mon idée, tout d'abord la découverte de l'excellente radio http://www.ledjamradio.com/ puis plus récemment de jukebox. Je serais presque jaloux de ledjam d'avoir eu l'idée de cette radio et du système de vote, mais je le suis totalement de leur jingles ; là vous devez faire une pause et lancer la radio dans un onglet. En ce qui concerne Jukebox j'ai apprécié l'interface mais beaucoup moins l'architecture qui en fait au final un outil un plutôt instable (notamment à cause de libshout).

Cette introduction faite il est temps de lâcher le morceaux, j'ai utilisé ces 4 derniers jours à coder Calorine (jeu concours : trouver ce qui a inspiré ce nom), la base de l'idée avoir une radio communautaire, dédiée à un groupe restreint comme le serait par exemple un canal IRC Écouter une radio à plusieurs même dans des lieux physiques différent créé une ambiance de groupe qui se rapproche de la sensation d'équipe dans un bureau commun, c'est très agréable de pouvoir chambrer un peu les collègues sur leurs goûts musicaux du vendredi (ils se reconnaîtront).

Venons-en aux fonctionnalités de Calorine, stream d'une playlist composées à plusieurs de façon communautaire sans hiérarchie, ça c'est la base. La radio dispose d'un pool de fichier ogg/vorbis dans lequel l'auditeur pioche, il ajoute ses titres à la playlist commune. Tout un chacun peut également consulter la playlist en cours et ajouter un vote à un titre, les titres avec le plus grand nombre de votes sont joués en premier, viennent ensuite les titres les plus anciens dans la playlist, et enfin si celle-ci est vide un titre aléatoire est joué. On a pour faire cela une interface écrite en Django ainsi qu'un bot IRC qui annonce le titre joué sur le canal et permet d'ajouter un titre à la playlist en effectuant une recherche full-text sur les ID3 du fichier musical.
Sur le principe technique, les path des fichiers sont stockés dans la base de données utilisées par l'app django. Icecast2 stream le flux audio, ices2 alimente le flux avec le mode script, ices2 appelle un script pour obtenir le chemin du fichieir audio à lire. J'ai préféré cette méthode de couplage ices/icecast plus robuste que d'utiliser libshout comme le fait Jukebox, cela donne aussi une totale indépendance entre l'ihm et le flux radio. L'indexage full-text est lui réalisé avec Haystack et le backend whoosh (des tests de solR sont en cours). Dans le repo il y 2 scripts qui permettent pour l'un d'alimenter la base de données (fill.py) et pour l'autre de convertir un répertoire de fichier mp3 en ogg (covert.py).
Comme tout projet de 4 jours il y a des petits bugs partout et beaucoup de chose à finir, mais c'est déjà fonctionnel et nous permet de nous faire mutuellement découvrir des titres.
Si vous souhaitez monter votre radio communautaire tout est dispo sous GPL sur github.

Penser à xauth

Rodolphe Quiédeville — Fri, 30 Nov 2012 12:38:00 +0100

Devant installer un outil dont je tairais la nom sur un serveur, outil qui ne se configure qu'avec un client X (ça commence mal) j'ai bloqué sur le X forwarding pendant une demi-journée. Après avoir fait un connexion ssh -X vers le dit serveur impossible de récupérer l'affichage sur ma machine. Un ssh -v m'a mis la puce à l'oreille avec comme dernière ligne :

debug1: Remote: No xauth program; cannot forward with spoofing.

Sans xauth effectivement difficile de reporter l'affichage au travers de la session ssh, la solution simpliste au possible consiste à installer le paquet xauth sur Debian.

apt-get install xauth

Espérons que la prochaine fois j'y penserai plus tôt.

Recherche outil de gestion des participants

Rodolphe Quiédeville — Tue, 27 Nov 2012 10:47:00 +0100

A l'occasion de mes derniers travaux sur Hypadrie j'ai été contacté pour savoir si il serait possible d'utiliser Hypadrie afin de gérer des listes de participants comme le font aujourd'hui des sites comme gestlistapp ou Eventbrite. Il existe déjà des outils de billeterie en ligne évolué comme e-voucher ou de gestion complète de conférences comme Pentabarf, mais je n'ai pas trouvé d'outil plus basique dans le fonctionnement. Les fonctionnalités de l'outil doivent rester simple afin de minimiser le temps d'enregistrement et permettre des inscriptions rapides, pas besoin de créer de compte ou de renseigner son CV complet avec antécédents à 4 générations. Nul besoin non plus de gérer le paiement en ligne. Hypadrie permet déjà cela mais est orienté spectacle vivant à ce jour, alors avant de généraliser l'outil et au lieu de ré-iventer la roue je fais appel à vos bookmarks afin de trouver l'outil existant ou approchant.

Bien évidemment le critère premier est la licence qui doit être libre.

Si vous connaissez un outil approchant laissez l'info en commentaire, merci à tous.

Hypadrie dans Ouest-France

Rodolphe Quiédeville — Tue, 20 Nov 2012 16:43:00 +0100

Ouest-France, dans son édition de Vannes, a publié un article sur Hypadrie intitulé ''Logiciel de réservation : les assos disent merci".

I will be the.re

Rodolphe Quiédeville — Fri, 16 Nov 2012 09:30:00 +0100

C'est avec plaisir et enthousiasme que j'ai rejoint le projet the.re hier avec mon dernier serveur. Celui-ci sera utilisé en partie pour augmenter les ressources de mes développements SIG, de pérenniser l'hébergement d'Hypadrie et d'y accueillir également quelques projets amis.

Merci à Loic pour son accueil au sein de the.re et son inépuisable énergie à faire progresser la liberté en ligne

Session PHP redondées dans memcache

Rodolphe Quiédeville — Tue, 13 Nov 2012 11:40:00 +0100

Pour partager les sessions PHP entre les serveurs web au sein d'un cluster il est fréquent d'utiliser le stockage des dites sessions dans un backend memcache. Si ce partage permet de servir un même client depuis n'importe quel serveur tout en conservant ses sessions cela introduit néanmoins un SPOF dans l'architecture, on va voir dans ce billet qu'il est possible de gérer le failover avec 2 ou plus serveurs memcache.

PHP gère depuis la version 3.0.0. de la librairie php-memcache le paramètre memcache.redundancy qui bien que non documenté est déjà fonctionnel, le principe est d'associer ce paramètre à memcache.allow_failover et de définir plusieurs serveurs memcache pour le stockage des sessions.

Dans l'exemple suivant on configure php pour utiliser 2 serveurs qui ont pour ip 10.0.42.1 et 10.0.42.2

; On indique à php de gérer les sessions dans memcache
session.save_handler = memcache

; le save_path est composé des adresses des 2 serveurs
; séparées par une virgule
session.save_path = "udp://10.0.42.1:11211?persistent=1&weight=1&timeout=1&retry_interval=15,udp://10.0.42.2:11211?persistent=1&weight=1&timeout=1&retry_interval=15"

; permet d'avoir les clés indiques sur tous les serveurs
memcache.hash_strategy = consistent

; force php à lire/écrire sur un autre serveur en cas de
; défaillance du premier appelé
memcache.allow_failover = 1

; nb de serveurs memcache + 1
memcache.session_redundancy=3

L'explication de session_redundancy qui vaut le nombre de serveurs memcache + 1 est issue de ce document

Dorénavant si l'un des serveurs memcache est coupé les sessions sont sauvegardées, et à son retour il récupérera les sessions utilisées au fil de l'eau. Cette solution est satisfaisante dans le cas des sessions à durée de vie limitée ; pour une durée de 30 minutes il vous faudra ne pas couper les 2 serveurs memcache à moins de 30 minutes d'intervalles afin d'avoir toujours les sessions actives dans l'un des memcache. Pour conserver des sessions ad vitam aeternam il faudra se tourner vers un stockage dans une base de données ou s'assurer de répliquer le serveur memcache renaissant avec les données du serveur actif.

Monitorer les mises à jour de sécurité Debian

Rodolphe Quiédeville — Wed, 31 Oct 2012 12:02:00 +0100

Jusqu'à peu j'utilisais des scripts maison pour suivre les mises à jour de sécurité à faire sur les serveurs Debian que j'administre, scripts shell qui à grand coup de sed, grep, gawk sur les sorties de apt-get update / upgrade permet de connaître les mises à jour à faire. Une fois de plus Debian à des outils internes pour faire cela beaucoup mieux. Utilisant aussi Debian sur mon desktop je me suis penché sur la méthode mise en oeuvre qui permet à mon gestionnaire de bureau de signaler dans une popup les màj à faire après chaque action apt, je suis tombé sur le paquet update-notifier-common qui contient tout ce qu'il faut pour refactoriser mes sondes Nagios.

La commande apt-chek (qui est un script python) permet de savoir tout de go si il existe des mises à jour à faire :

rodo@arz: $ /usr/lib/update-notifier/apt-check
110;57

donne une sortie facilement scriptable qui indique ici qu'il y a 110 mises à jour disponibles dont 57 mises à jour de sécurité (tests effectués sur mon desktop, n'ayez craintes)

rodo@arz: $ /usr/lib/update-notifier/apt-check --human-readable
110 packages can be updated.
57 updates are security updates.

donne une sortie plus compatible avec le genre humain.

Enfin l'option -p elle va afficher la liste des noms de paquets à mettre à jour. Pour parfaire le script on souhaiterait avoir une option qui permette de n'afficher que les noms de paquets issus de security à mettre à jour, gageons que cela soit dans une future release.

Il ne reste plus qu'à utiliser cette commande dans une sonde nagios telle que celle décrite dans ce billet

Pour conclure il me reste à dire que apt-check se base sur la librairire python apt_pkg disponible dans python-apt que je vous invite à découvrir si vous souhaitez manipuler les commandes apt à partir de python.

MàJ : après ma réflexion sur une option supplémentaire j'ai envoyé un patch au mainteneur du paquet

Nagios et les MIBS perdues dans Debian

Rodolphe Quiédeville — Mon, 29 Oct 2012 14:42:00 +0100

Il faut désormais activer non-free dans Debian pour pouvoir utiliser les MIBS snmp ( voir http://wiki.debian.org/SNMP), action qui n'est pas réalisable dans de nombreuses architectures. Sans les MIBS utiliser SNMP devient vite une gageure, devoir déclarer les commandes Nagios en se basant sur les OID des directives extend est fastidieux et difficilement maintenable dans le temps. Afin de simplifier cette utilisation j'ai écrit un script pour simplifier la déclaration dans Nagios en se passant des MIBS.

mibchecks génère les définitions Nagios en analysant le fichier de configuration du démon snmp, il est disponible sur gitorious pour download et/ou fork.

Repo : https://gitorious.org/mibchecks/mibchecks

mibchecks lit le fichier /etc/snmp/snmpd.conf, en extrait les définitions extend, convertit les noms de commandes en OID et écrit sur la sortie standard les définitions de command à inclure dans la configuration de nagios. Un exemple de sortie.

Le script est actuellement en version 1.0.2 et attend vos patch et/ou amélioration.

sslh pour se connecter en ssh sur 443

Rodolphe Quiédeville — Fri, 14 Sep 2012 09:37:00 +0200

Au détour d'un tweet d'Arthur Lutz 1 j'ai découvert un outil fort pratique que tout bon admin/sys devrait mettre dans sa boîte à outil pour contrer les firewall ; sslh 2 un multiplexer ssl/ssh. Le principe de sslh est d'être à l'écoute sur un port TCP et de rediriger le traffic suivant le protocole client qui se connectera sur le port idoine. Le cas pratique le plus courant sera de mettre sslh à l'écoute sur le port HTTPS (443) et de le configurer pour rediriger le HTTPS et SSH. On voit tout de suite l'intérêt d'une telle configuration, on pourra se connecter en ssh sur la machine par le port 443 qui n'est que très rarement filtré par les firewall restrictif.

sslh est présent dans sa dernière version stable (1.13) dans Debian/Wheezy 3, sa configuration se fait dans /etc/default/sslh par la définition des options, la configuration par défaut est :

DAEMON_OPTS="--user sslh --listen 0.0.0.0:443 --ssh 127.0.0.1:22 --ssl 127.0.0.1:443 --pidfile /var/run/sslh/sslh.pid"

Par défaut sslh est en écoute sur le port 443 et gère ssh et https. Dans sa mise en place on prendra soin au préalable de faire écouter sshd et apache sur le loopback avant de démarrer sslh.

Il reste à dire que sslh gère également OpenVpn, XMPP, HTTP, tinc et tous les protocoles qui peuvent être détecté au moyen d'un regexp.

1. https://twitter.com/arthurlutz/status/246167110705897472

2. http://www.rutschle.net/tech/sslh.shtml

3. http://packages.debian.org/wheezy/sslh

Utiliser CLOC avec Jenkins

Rodolphe Quiédeville — Thu, 16 Aug 2012 13:43:00 +0200

J'utilise depuis quelque temps l'outil d'integration continue jenkins et j'apprécie de pouvoir suivre le nombre de lignes de codes dans mes développements, peut-être pas orgeuil, mais découvrir 3 mois plus tard l'existence d'une librairie qui remplace 10K lignes de code maison rend aussi plus humble. Je me suis donc penché sur la longue liste de plugins pour Jenkins et ai utilisé pendant un temps le SLOCCount Plugin.

SLOCCount bien que faisant le travail n'a pas évolué depuis 2004 et surtout il ne détecte pas l'ensemble des langages utilisés dans mes projets, comme par exemple JavaScript. J'ai alors recherché d'autres outils de métriques de code et j'ai trouvé CLOC qui est plus récent et plus exhaustif que SLOCCount. CLOC annonce (cloc --show-lang) reconnaitre 100 langages quand SLOCCount n'en identifie que 27, loin d'utiliser autant de langage CLOC couvre au moins mes besoins en identifiant ceux qui m'intéressent.

Voulant utiliser CLOC au lieu de SLOCCount j'ai cherché en vain un plugin pour Jenkins. Le plugin SLOCCount lui par contre me satisfaisant j'ai décidé de contourner le problème en écrivant un script python exécutant CLOC et formattant la sortie de celui-ci au format de SLOCCount attendu par Jenkins. J'ai désormais tous mes langages de comptabilisés pour un moindre effort.

Si le script clokins.py vous intéresse il est disponible sur gitorious et pour l'anecdote il est utilisé pour compter ses propres lignes sur http://jenkins.quiedeville.org/job/Clokins/.

Et si vous utilisez une autre méthode de comptage dans Jenkins commentez ce billet cela sera utile pour tout le monde.

Publié en GPLv3 toutes les contributions sont les bienvenues.

L'OpenData toulousain

Rodolphe Quiédeville — Fri, 22 Jun 2012 18:14:00 +0200

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

Backport python-dbf pour squeeze

Rodolphe Quiédeville — Wed, 13 Jun 2012 08:59:00 +0200

Il existe peu de librairie pour manipuler le format DBase dans le monde du libre. Peu utilisé pour les usages standards des base de données, au regard d'outil comme Postgresql ou Sqlite, le format DBase reste néanmoins incontournable dans l'univers du SIG. Utilisé comme format de stockage des données attributaires pour les fichiers Shapefile il est encore manipulé tous les jours par les géomaticiens. Il existe néanmoins une librairie python nommée python-dbf mais uniquement dans Wheezy, j'ai retroporté celle-ci vers squeeze.

python-dbf 0.88.16-1~bpo60+1

python-dbf-doc 0.88.16-1~bpo60+1

Adresse du dépôt : dépôt personnel.

Hypadrie bientôt sur vos écrans

Rodolphe Quiédeville — Sun, 25 Mar 2012 12:13:00 +0200

J'entends que Django est un framework formidable depuis maintenant trop longtemps pour que mon aversion pour les ORM résiste encore face à l'envie d'essayer la bête. Je me suis donc enfin lancé dans un petit projet nommé Hypadrie, que vous pourrez bientôt tester sur hypadrie.eu.

Déployer Geoserver 2.1.2 avec Tomcat7 sur Debian Squeeze

Rodolphe Quiédeville — Thu, 15 Dec 2011 13:29:00 +0100

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.

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.

Backport Tomcat 6 et 7 pour squeeze

Rodolphe Quiédeville — Thu, 15 Dec 2011 10:02:00 +0100

J'ai mis en ligne hier soir les backports pour squeeze des versions de Tomcat suivante :

tomcat7 7.0.23
tomcat6 6.0.33

Disponible sur mon dépôt personnel.

Je testerai prochainement la dernière version de Geoserver sur Tomcat7.

Registre parcellaire graphique en OpenData et BadData

Rodolphe Quiédeville — Fri, 09 Dec 2011 23:38:00 +0100

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.

Bilan des backports pour Openstreetmap

Rodolphe Quiédeville — Tue, 06 Dec 2011 11:08:00 +0100

L'avantage indéniable de Debian sur d'autres distributions est à mes yeux sa stabilité exemplaire, cela entraine malheureusement d'avoir régulièrement des versions un peu obsolète des logiciels empaquetés. Il est possible de contourner cela en créant des backports de la version de développement de Debian (Wheezy) vers la version stable (Squeeze). J'ai réalisé les backports des principaux outils utilisés dans l'univers OpenStreetMap, ceux-ci sont diponibles sur mon dépôt privé (voir ce billet pour la mise en place du dépôt sur votre machine.

A ce jour les outils ci-dessous sont disponibles dans ces versions :

dans-gdal-scripts 0.18
gdal 1.7.3
mapnik 2.0.0
osm2pgsql 0.70.5
openlayers 2.11
gpsprune 13.1
viking 1.2.1

Les paquets n'ont pas été poussés dans le dépôt des backports officiels car ils représentent une utilisation trop faible au vu de la communauté Debian, un paquet comme osm2pgql est utlilisé à ce jour par moins de 300 personnes d'après popcon quand les outils apache2 le sont par plus de 60000 (popcon apache2-utils).