neogeo » Rest

GeoDjango, LE framework cartographique.

Guillaume Sueur — Fri, 09 Jan 2009 22:48:13 +0000

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.

ArcDevelopper REST API

Guillaume Sueur — Mon, 10 Mar 2008 20:59:21 +0000

Ca bouge chez ESRI, qui réinvente FeatureServer... Une interface REST en cours de développement mais déjà opérationnelle (l’exemple est fait avec OpenLayers, pas ArcIMS…) dans le cadre du projet ArcDevelopper illustre bien l’intérêt porté aux Architectures Orientée Ressources par les plus gros acteurs du marché SIG. Ca retourne même du GeoJSON (essayez ce lien : http://65.101.234.201/rest/rest.svc/TestService/Flyways/10?g=true) , preuve que ce format est en train de s’imposer tranquillement comme le standard pratique d’échange de données vectorielles sur le web, tandis que l’architecture REST procure souplesse et lisibilité. On aura l’occasion d’en reparler bientôt.

P.S. : même Microsoft s’intéresse à REST, le framework .NET 3.5 intègre une classe .NET d’URI templating, pour interpréter directement les URLs Restful selon des modèles prédéfinis…

Pour un 2008 RESTFul !

Guillaume Sueur — Mon, 17 Dec 2007 14:33:37 +0000

Il semblerait que quelques poids lourds (via zcologia) de l’industrie paleo-geographique et non des moindres s’orientent vers l’adoption d’architectures orientées ressources.

Histoire de finir l’année sur de bonnes résolutions pour celle à venir, quelques principes de base de la « Budgetecture » pour partir du bon pied donc.

Brevetage d’URL

Guillaume Sueur — Wed, 24 Oct 2007 11:34:06 +0000

Ca semble un peu inouï dit comme ça, mais un brevet a été déposé par A9.com, une société du groupe Amazon.com, concernant un « Search engine system supporting inclusion of unformatted search string after domain name portion of URL », soit en bon français : « Moteur de recherche acceptant l’inclusion d’une chaine de recherche non formatée après le nom de domaine dans l’URL », donc quelque chose du genre : http://www.recherche.com/spaghetti bolognaise (les espaces sont acceptés). Voir ici pour les détails. Il y est précisé que le principe breveté concerne la soumission d’une chaîne de caractères à un moteur de recherche si cette chaîne ne correspond pas à une ressource existante.
Est-ce que cela signifie que toute structuration un rien RESTFul tombe dans le champ d’application de ce brevet pour peu que l’URL corresponde au modèle breveté ? Si http://www.communes.com/31555 pointe sur une ressource, ça semble bon, mais si http://www.communes.com/Toulouse passe au travers d’un mod_rewrite qui appelle http://www.communes.com/search.php?q=Toulouse pour renvoyer ensuite la ressource http://www.communes.com/31555, on est bien dans le champ d’application du brevet.

Je ne suis pas spécialiste des brevets, mais je frissonne déjà à l’idée de devoir vérifier si ma structuration d’URL, et donc l’architecture de mon application web, ne tombe pas sous une telle protection. Car si A9.com a pu le faire pour quelque chose d’aussi simple et basique, qui va se gêner ? Wikipedia pourrait deposer les URL en http://xxxx/wiki/chaine_de_recherche par exemple. Enorme bourde de l’USPTO ou nouvel eldorado des verrouilleurs de tout poil ?

Via slashdot

Heureuse initiative

Guillaume Sueur — Fri, 27 Jul 2007 09:51:44 +0000

Chris Schmidt et Howard Butler viennent de mettre en ligne un petit site web qui référence les projections EPSG et des projections personnelles, chargées par les utilisateurs du site. Rien de bien excitant ? Et bien si, car ils mettent aussi à disposition des webservices de publication des définitions des projections, aux formats GML, Proj4, EsriWKT, OGC WKT, USGS et JSON. Grâce à une architecture RESTFull, les définitions (ou les ressources, pour utiliser la terminologie REST) sont accessibles par un simple appel d’URL :

http://spatialreference.org/ref/epsg/27572/Proj4 renvoie ainsi un flux texte correspondant au Lambert II structuré selon la norme Proj4.

L’intérêt ? Pouvoir à terme intégrer ces URL en lieu et place des définitions elles-mêmes dans l’utilisation de GDAL ou de MapServer par exemple. Donc un moyen simple d’accéder à des définitions maintenues à jour, sans avoir à mettre les mains dans les fichiers EPSG de la librairie proj, ainsi que de créer ou d’utiliser des projections non définies par l’EPSG.

Autre intérêt du site : bâti autour du framework Django, donc écrit en Python, avec une architecture REST, il montre ce que ces technologies peuvent apporter en termes de simplicité et de flexibilité dans la mise en oeuvre de webservices cartographiques.