Olivier Courtin nous propose un joli résumé du New York Sprint 2010. Deux posts plus techniques vont bientôt apparaître, quand la fatigue du voyage se sera estompée sans doute… On devrait aimerait alors en savoir plus sur les roadmaps de PostGIS et MapServer quant à leurs versions respectives 2.0 et 6.0. Pour Microsoft Word, ça avait été des évolutions majeures…
Archive pour le mot-clef ‘PostGIS’
Retour sur le sprint
Lundi 1 mars 2010Fresh meat
Samedi 25 avril 2009Deux sorties dignes d’intérêt ces derniers jours : OpenJump 1.3 et MapServer 5.4.
Concernant le premier, on note l’arrivée de nouvelles méthodes de discrétisation (moyenne, seuils naturels et Jenks notamment) et d’informations statistiques sur les couches (min, max, moyenne…), ainsi que de nouvelles fonctions d’édition des géométries (auto-complétion des polygones sur tracé existant, simplification de polygones sans incohérence, double fenêtrage synchrone…) qui en font un outil de choix pour tout ce qui touche à la manipulation des données.
MapServer voit quant à lui intégrées les améliorations promises par le Toronto Code Sprint. J’ai fait quelques tests habituels sur des extraits de larges couches PostGIS et Shapefile, et les résultats sont assez troublants. Voici un comparatif avec la version 5.2 pour la génération d’une image de 600 x 600 pixels comprenant deux couches, communes et ROUTE250 sur une zone couvrant à peu près la Gironde :
| 5.2 | 5.4 | ||
|---|---|---|---|
| Postgis | GIF | 0.142 | 0.159 |
| PNG | 0.388 | 0.386 | |
| AGG | 0.920 | 0.707 | |
| Shapefile | GIF | 0.101 | 0.101 |
| PNG | 0.297 | 0.318 | |
| AGG | 0.920 | 0.842 | |
| SHP + QIX | GIF | 0.058 | 0.060 |
| PNG | 0.315 | 0.284 | |
| AGG | 0.834 | 0.606 | |
Il y a à mon avis quelques informations utiles à tirer de ces résultats, qui n’ont pas vocation à présenter des index de performance pure, mais bien à comparer les deux versions dans des situations analogues. Considérons le format GIF comme celui de référence car impactant le moins de temps final de création de l’image.
Premièrement, on note une perte de performances légère (moins de 10 %) entre la version 5.2 et la nouvelle version 5.4 en GIF. Paul Ramsey m’a expliqué que c’est dû au passage à un curseur texte pour parcourir la base de données en lieu et place du précédent curseur binaire, plus performant certes, mais beaucoup plus difficile à maintenir et à utiliser dans le code car devant être manipulé au sein de transactions (et je veux bien le croire…).
Deuxièmement, on note toujours l’avantage significatif du shapefile, a fortiori quand il est indexé. Les modifications indiquées ci-dessus portent le ratio à 1.5 avec un Shapefile standard et à plus de 2 avec un fichier .qix. On peut en conclure que pour obtenir les meilleures performances, c’est cette association SHP + QIX + GIF qu’il faut choisir.
Cependant le rapport s’inverse avec les autres formats, comme si le nouvel handicap de l’accès à Postgis était compensé par une meilleure prise en charge du PNG et de l’AGG/PNG. C’est avec ce dernier choix, l’anticrénelage AGG, que l’amélioration est la plus significative, preuve s’il en fallait que Thomas Bonfort (créateur et mainteneur de l’intégration AGG dans MapServer) n’aura pas fait le déplacement à Toronto pour rien. Mais ce que je ne comprends pas, c’est qu’une image PNG ou AGG semble mieux bénéficier des données indexées (Postgis ou qix) que d’un simple shapefile. Thomas, si tu lis ces lignes…
In fine, 20 % de mieux pour le couple le plus sexy (PostGIS + AGG), c’est une vraie bonne nouvelle.
En français s’il vous plaît
Mardi 17 mars 2009Une fois n’est pas coutume, la parole de l’oracle de Victoria nous est délivrée directement dans notre langue, ce qui nous permet de savourer un peu mieux la pertinence de ses analyses… Et il y en aura encore la semaine prochaine.
GeoDjango, LE framework cartographique.
Samedi 10 janvier 2009J’en ai parlé dans le post précédent, mais pas de manière suffisamment détaillée pour satisfaire les curieux qui m’ont rappelé à l’ordre et soumis des questions diverses. Donc je vais essayer de me rattraper…
Qu’est-ce que GeoDjango ?
C’est une extension de Django (ça existe même en français) destinée à gérer les données géographique. OK, mais on n’avance pas là. Qu’est-ce que Django ? Un framework web en Python sous licence OpenSource BSD qui permet de structurer un site web au travers d’une structure Modele – Vue – Template très rapidement. Les modèles sont les tables de votre BD, mais en mode objet; les vues sont les actions et les manipulations diverses que vous voulez effectuer, et les templates sont des modèles de mise en page HTML destinés à présenter les résultats des vues. De plus, Django génère automatiquement un module d’administration des Modèles (des tables donc), qui permet facilement de CRUDer (lire, retrouver, mettre à jour, supprimer) le contenu de votre SI. Un peu comme PhpMyAdmin, mais en mieux !
A ceci, GeoDjango ajoute donc la dimension spatiale, tout comme PostGIS ajoute la dimension spatiale à PostgreSQL. Cela peut fonctionner avec PostgreSQL, MySQL ou Oracle, mais pour ces deux derniers toutes les fonctions ne sont pas encore intégrées (voir la table de compatibilité). Vous obtenez alors des tables spatiales référencées en tant que modèles, et manipuler les objets géométriques (intersection, union, extent, aire…). Ceci grâce au portage dans le code de GeoDjango des librairies bien connues GDAL et GEOS.
Depuis août 2008, GeoDjango fait partie intégrante de Django, tout en gardant sa propre doc et son wiki.
KiCéKiLaFé ?
Justin Bronn, qui va bientôt passer ses examens pour devenir District Attorney (procureur…). A l’occasion de la mise en place de son application Houston Crime Maps, il a choisi Django et y a progressivement intégré la dimension spatiale dont il avait besoin.
Et on peut voir ça où ?
Une petite application de démonstration est accessible ici. Elle a été construite par Dane Springmeyer, Josh Livni et Christopher Schmidt. Vous pouvez utiliser le login/passwd geo/geo pour vous connecter au module d’administration. Surprise, les données géographiques sont éditables grâce à l’intégration d’OpenLayers dans la page et de votre objet en mode vectoriel !
Sinon la présentation faite par Justin Bronn au Forum Texas GIS en octobre 2008 donne aussi quelques liens.
Ok, c’est beau, mais il y a de la doc ?
Oui, aussi. D’abord un tutoriel : http://geodjango.org/docs/tutorial.html#geographic-data
Un kit d’installation : http://geodjango.org/docs/install.html
Les spécificités des modèles GeoDjango (qui surclassent les modèles standard Django)
La DB-API, qui intègre les opérateurs spatiaux.
et plein d’autres trucs (sur GDAL, GEOS…)
et enfin, un groupe de discussion !
et sinon, tu en penses quoi ?
Je ne suis pas forcément très objectif, mais je suis un inconditionnel de Django en général et de GeoDjango en particulier. Ce que j’apprécie le plus est de pouvoir stocker les données géographiques sous PostGIS et de les manipuler ensuite pour les envoyer vers le client en GeoJSON par exemple après les avoir reprojetées ou simplifiées. Le GeoAdmin, et la capacité d’édition de la donnée qu’il apporte, même si elle est imparfaite, est aussi très agréable.
La prise en main n’est pas très difficile. Les tutoriels de Django et GeoDjango sont très accessibles, et la vitesse à laquelle on arrive à des résultats concrets donne vite envie d’aller plus loin.
des trous dans vos index GiST ?
Dimanche 16 novembre 2008Paul Ramsey nous fait part d’un bug affectant les implémentations GiST des dernières versions de PostgreSQL (8.1.14, 8.2.10 et 8.3.4). Lors de la suppression d’un enregistrement, la suppression de son entrée dans l’index affecte en fait un autre item, ce qui, sans supprimer la donnée, la rend invisible pour toute requête effectuée sur la base de l’index GiST. GiST est l’index spatial utilisé notamment sur les colonnes géométriques, pour préalablement filtrer les objets à requêter en fonction de leur bounding box. Ce bug peut donc fortement affecter les résultats de requêtes géographiques. Il est corrigé dans la toute dernière version 8.3.5 (c’est bien de PostgreSQL qu’il s’agit, et non de PostGIS qui ne fait qu’exploiter ce type d’index).