Archive pour la catégorie ‘Langages’

GeoDjango, LE framework cartographique.

Samedi 10 janvier 2009

J’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.

Neogeo change de peau…

Mercredi 17 septembre 2008

Grande nouvelle dans le monde de l’OpenSource GeoSpatial, Neogeo n’est plus… ou du moins plus sous la même forme. L’entreprise individuelle fait place à une superbe SARL au capital de 14000 €. Pourquoi cette mutation ? Il y a plusieurs éléments de réponse :

  • ma volonté de pouvoir intervenir dans des domaines plus larges que ceux réservés à l’activité libérale
  • la possibilité de mieux contrôler la croissance de l’entreprise, et de pouvoir embaucher si nécessaire (ce qu’on peut aussi faire en libéral, mais on est alors responsable de manière illimitée à la fois sur le versement des salaires mais aussi pour toute procédure légale).
  • la nécessité de gagner en crédibilité pour remporter certains appels d’offres auxquels le statut libéral correspondait mal

Au passage, Neogeo change un peu de nom aussi et devient Neogeo Technologies. Neogeo étant une marque déposée de Sega SNK (oui, la console de jeu des années 80…), ce nom ne pouvait être utilisé comme raison sociale. J’ai donc rajouté un mot suffisamment long pour ne pas être employé dans la conversation, et pouvoir donc rester virtuellement « neogeo ».

Adresses web et mail ne changent pas pour l’instant, même si je n’aime pas beaucoup le ‘-online’, mais ce n’est pas pire que ‘-technologies’ ou neogeotech… Si vous avez des idées sur la question, n’hésitez pas à m’en faire part !

Un nouveau départ donc, dans la stricte continuité des activités précédentes, mais avec un périmètre d’intervention plus large. Des annonces viendront bientôt…

Merci à tout ceux qui ont fait confiance à Neogeo et qui lui ont permis de croître, Neogeo Technologies SARL est désormais là pour satisfaire leurs besoins.

Du KML pour Noël

Jeudi 6 décembre 2007

Pour ceux qui ne sauraient pas quoi faire pendant les fêtes et que la lecture de 268 pages de spécifications techniques ne rebute pas, l’OGC diffuse depuis hier un RFC (Request For Comments) sur les spécifications du format KML 2.2. Il y a aussi de belles illustrations dedans, genre « la carto pour les nuls » :

Illustration KML 2.2

Du GeoJSON dans OGR

Mercredi 7 novembre 2007

Mateusz Loskot vient de publier un nouveau driver pour OGR, la célèbre bibliothèque d’abstraction/conversion de formats SIG, qui va donc désormais pouvoir accéder en lecture seule à des flux GeoJSON. On en a déjà parlé, le GeoJSON est la version Geo (malin non ?) de la notation JSON (Javascript Simple Object Notation) qui permet d’échanger facilement des objets structurés entre un serveur et un client. Un tableau associatif PHP se converti ainsi directement en un objet javascript.

La particularité du driver de Mateusz est de pouvoir accéder directement à un flux http renvoyant du GeoJSON, car ce « format » n’est pas à proprement parler un format de stockage comme le Shapefile ou le GML, mais bien un format d’échange. Avoir un fichier .gjson serait par là même une aberration ! Le driver ouvre donc une connexion vers un service web délivrant du GeoJSON, et permet alors toutes les opérations habituelles des modules OGR : info sur le fichier et conversion :
ogr2ogr -f « ESRI Shapefile » cities.shp http://featureserver/cities/.geojson OGRGeoJSON transforme en shapefile le flux GeoJson des villes issu du serveur de données.

L’intérêt de cette implémentation est tout naturellement son utilisation dans un contexte mobile, où la limitation de bande passante empêche l’exploitation de « gros » formats tels que le WFS-GML, un petit client pouvant ainsi récupérer les données vectorielles dynamiquement pour une exploitation locale.

Notez bien que ce driver n’est pas encore disponible dans la version officielle de GDAL-OGR, mais uniquement à partir du svn osgeo . Le portage dans la version officielle devrait être faite sous peu.

Du neuf dans les GeoFormats ?

Dimanche 30 septembre 2007

En complément à un précédent post, le FOSS m’a permis d’y voir un peu plus clair sur les différents formats « interropérables » pour les données géographiques et surtout de percevoir un distinction majeure entre ceux-ci : il y a d’un côté les formats issus du monde géographique et créés pour diffuser l’information géographiques sous la formes de services web : WMS, WFS et donc GML sont de ceux-là.
D’un autre côté, on trouve les formats du Web 2.0 qui intègrent peu à peu la dimension géographique : AtomPub, GeoRSS en font partie. Le KML/Z quant à lui se situant entre ces deux approches : imaginé pour diffuser de l’information géographique (et rien de plus, comme le rappelle Raj Singh), il intègre aussi étroitement la notion d’interropérabilité totale.

Car c’est bien en termes d’interropérabilité que les formats se distinguent. Là où les premiers ont été faits pour permettre à des systèmes géographiques d’interropérer (afficher dans MapInfo une carte issue d’un serveur WMS, crééer un application web à partir de multiples serveurs WMS-WFS différents), le deuxième groupe est fait pour permettre à des applications web d’interropérer, nonobstant leur capacité à analyser ou traiter la donnée géographique. Ce point est central pour la compréhension des avantages et inconvénients de chacuns. Là où un flux AtomPub intégrant des balises de géolocalisation en GeoRSS pourra être interprété par n’importe quel client Atom, qu’il exploite les données géographiques ou pas, le flux GML d’un serveur WFS ne sera correctement affiché sous forme de carte que par des clients dédiés à l’affichage cartographique. Cependant, pour des raisons d’homogénéité et de standardisation, l’AtomPub, tout comme le KML, ne diffuse qu’un contenu attributaire restreint (nom – description de l’objet, même si celle-ci peut-être complexe, de la forme d’un bloc HTML complet), tandis que le GML transporte toute la richesse attributaire nécessaire à une réelle exploitation des données. Les usages sont donc forcément différents. Là où le GeoRSS répond au besoin de « Affiche mes posts dans GoogleMaps », le GML est porteur d’une réelle richesse attributaire et d’une plus value qualitative évidente, qui se paye par une plus grande complexité.