Installer un serveur de tuile sur Opensuse 12.1 (mod_tile)

L’installation et le fonctionnement d’un serveur de tuile (une tuile est une image d’une carte. Les cartes “web” sont en fait l’assemblage d’images carrées, mises côte à côte) est bien documentée sur la plate forme Ubuntu. Peu d’articles, par contre, portent sur la distribution OpenSUSE. Or, alternatif dans l’alternatif, c’est celle que j’ai choisie.

Petit tour des difficultés que j’ai rencontrée, et des solutions que j’ai pu trouver.

Trouver mod_tile.so

Première difficulté: trouver le fichier mod_tile.so. Ce fichier est le module d’apache qui “sert” les tuiles. Lors de la compilation, il s’était caché… dans un répertoire caché, à l’endroit suivant:

Pour le trouver, la commande find est utile:

Charger le module dans apache

Là encore, le fichier de configuration par défaut proposé ne rend pas service… En effet, le fichier contient à la fois le code de chargement de mod_tile, mais également la configuration du vhost. Or, par facilité, j’ai voulu terminer la configuration du vhost avec l’installateur automatique… ce qui a supprimé le code avant la définition du vhost.

Le code prévu :

Pour plus de facilité, j’ai déplacé le fichier mod_tile.so dans le répertoire des modules d’apache (chez moi, /usr/…) et il est apparu dans la liste des modules du configurateur Yast. Je n’ai plus eu qu’à suivre les étapes de l’installateur automatique des modules et du vhost, puis à copier/coller les variables par défaut de la configuration de mod_tile dans le fichier ad hoc dans le répertoire /etc/apache2/vhosts.d/

Renderd

Autre fil à retordre: renderd. C’est un service qui semble faire l’interface entre mapnik et apache.

Chez moi, les librairies libiniparser3.0, requises par le service, étaient installées en version 32 et 64 bit. Cela empêchait renderd de démarrer. Il a suffit que je supprime la version 32bits et il semblait démarrer… Mais je dis bien “semblait”, car en fait, le service s’arrêtait au démarrage, mais cela n’était pas communiqué. Quelques recherches plus tard, je découvre que la commande -f permet d’afficher des informations de débogages

Ce qui m’a permis de constater qu’il s’arrêtait, ne pouvant localiser le répertoire de mapnik qui contenait les librairies nécessaire à l’utilisation de données postgis… La commande suivante m’a permis de les localiser :

Et il a suffit, alors, de modifier le fichier /etc/renderd.conf (qui n’est pas lui-même nativement à cette place) pour l’adapter (comparez avec la version par défaut):

Les informations de débogage m’ont également permis de constater que renderd établissait un fichier .sock dans le répertoire /tmp du système. Pas très propre. Il a donc fallu créer le répertoire /var/run/renderd/, auquel l’utilisateur qui lance renderd a accès:

Puis décommenter la ligne correspondante dans /etc/renderd.conf:

Stockage des tuiles

Par défaut, les fichiers meta des tuiles sont stockées dans le répertoire /var/lib/mod_tile. Mais mon disque est partitionné en deux (comme la plupart des utilisateurs linux): d’un côté le répertoire racine, de l’autre le répertoire /home. Le répertoire racine étant limité en taille, et devant contenir les données des programmes, mieux vaut éviter de l’encombrer inutilement…

J’ai donc créer un lien symbolique vers un répertoire spécifique créé sur la partition /home:

J’espère que partager ces informations pourra aider…

Doctrine2 2.2 et types géographiques

Une lacune des premières version de Doctrine2 était de restreindre l’emploi de données géographiques. C’est maintenant comblé avec la version 2.2: une demande d’amélioration a été implémentée dans la nouvelle version, sortie le 29 janvier 2012. A l’heure d’écrire ces lignes, les nouvelles fonctionnalités n’ont pas encore été documentées.

Mise à jour les développeurs ont intégré les modifications proposées dans la documentation, qui sont reprises ici.

Voici comment je suis arrivé à créer un type “point” avec Symfony2 et Doctrine2.2, sur une base de donnée géographiques Postgresql + Postgis.

Toute la difficulté résidait dans le fait que les données géographique sont stockées dans des colonnes qui n’étaient pas directement exploitable, dans un format qui n’est pas “standard” (La documentation de postgis signale que le format n’est pas directement utilisable). Dès lors, pour les lire et les exploiter, il faut transformer les données vers un format connu, comme le geoJson (qui est utilisé dans cette exemple) ou le WKT.

Pour suivre cet exemple, l’installation de l’extension géographique postgis doit avoir été réalisée au préalable.

Tout d’abord, j’ai créé une classe Point, qui me servira, par la suite, à effectuer la manipulation de cet objet particulier.

 

Notez que j’ai rendu le constructeur privé afin de pouvoir forcer les vérifications des coordonnées. Le principe est discutable et je serai ravi d’entendre d’autres opinions.

J’ai ensuite créé une classe PointType qui étend la classe Type de Doctrine2, tel que décrit dans la documentation de Doctrine2

Notez ces trois fonctions, importantes, qui font la différence entre la version 2.1 et la version 2.2 de Doctrine:

La première transforme le type géographique de la base de donnée en une chaine GeoJSON, chaine qui sera ensuite transformée en objet Point par la fonction convertToPHPValue :

La deuxième transforme la chaine de la requete SQL qui introduit les coordonnées géographique J’avais donc supposé que j’aurais dû utiliser le constructeur ST_GeographyFromText de postgis et que la fonction soit la suivante :

Mais, pour une raison que je ne m’explique pas, cette chaine doit rester identique: apparemment une conversion a déjà lieu automatiquement quelque part.

(Encore une fois, vos idées sont les bienvenues). Dès lors, il n’est pas nécessaire, ici, de la modifier (elle n’a même pas besoin d’être surchargée). Nous la laissons donc en l’état :

La dernière rend effective les deux autres: pour des raisons de performances: elle doit renvoyer “true” pour activer l’utilisation des deux autres:

Il ne suffit plus, alors, que de renseigner le type “PointType” à Doctrine. Dans Symfony2 en Yaml, cela se fait de la manière suivante :

ACTA, nouveau danger pour nos libertés

Quelques semaines après une victoire contre les décrets SOPA et PIPA, qui mettaient en péril la liberté d’expression sur le net aux Etats-Unis, une autre initiative menace non seulement les libertés d’expression sur internet, mais également la distribution de médicament générique et l’utilisation de semences.

Dossier complet sur la quadrature du net.


Say no to ACTA par QuadratureDuNet