Archive pour la catégorie ‘Architectures’

OSGIS 2010… raid over England

Jeudi 8 juillet 2010

La fine fleur de la géomatique Open Source hexagonale a fièrement porté haut les couleurs de la France à Nottingham (Angleterre) lors de la conférence OS-GIS 2010. Comme on ne va pas au fin fond des Midlands pour s’amuser, Gérald Fenoy, de Geolabs, et Olivier Courtin, d’Oslandia, y ont présenté leurs merveilles technologiques dédiées aux web services cartographiques, à savoir respectivement le déjà célèbre Zoo Project, serveur WPS, et le non moins fameux TinyOWS, serveur WFS-T, hautes performances nous dit-on. La présentation d’Olivier a même remporté le 1er prix de la meilleure présentation. Gérald de son côté a dû remplacer Nicolas Bozon au pied levé, ce dernier ayant raté l’avion après s’être mis à l’heure anglaise par anticipation.

Toutes nos félicitations à nos deux représentants nationaux, et n’hésitez pas à retrouver leurs prestations dans la rubrique webcasts du site de l’OSGIS 2010.

Le soleil se lève sur le ZOO Project

Mercredi 18 novembre 2009

Ce vendredi 20 novembre se tiendra à Montpellier le premier ZooDay réunissant autour des concepteurs initiaux du projet, et au premier rang desquels Gérald Fenoy de Geolabs, les amateurs éclairés désireux de se plonger dans cet environnement WPS (Web Processing Service). Nicolas Bozon vient d’en publier le programme sur la ZooDiscuss-List :

8:30 – 9:30 : ZOO project presentation to LIRMM’s researchers
9:30 – 10:15 : Business meeting 3LIZ / GeoLabs / Neogeo Technologies
10:15 – 10:30 : Everybody should be there for coffee
10:30 – 11:30 : Intro / Meeting scheduling
ZOO Kernel presentation (ZOOKernelInternal)
ZOO Services demos (OGR, GDAL, GCAL, QRCode…)
Discussions
11:30 – 12:30 : ZOO Project orgnanization (PSC (ZOO Tribal Council), Tribe, Sponsors, Knowledge partners)
ZOO Project objectives (community, buisness, licensing, marketing)
ZOO Development plans (ZOO Server, ZOO Web Client, ZOO Desktop Client)
Discussions

12:30 – 14:00 : Lunch (restaurant to be booked)

14:00 – 15:00 : ZOO Kernel and ZOO Services session
(Brain storming on Kernel Limitations/Enhancements, Services implementation, ZOO Server and REST API)
15:00 – 16:00 : ZOO Web Client session
(Brainstorming on Client architecture, interactions with OpenLayers and other libs, GUI…)

Je sens que je vais passer mon tour sur le Kernel Limitations/Enhancements…

Depuis mon dernier post, ReLuc a mis au point une petite démo, mettant en oeuvre quelques-uns des services actuellement implémentés. Mais la finalité d’un WPS est-elle d’afficher un résultat dans un navigateur web ? Pas que. De mon point de vue, le WPS permet au geoweb d’effectuer un changement de paradigme, au sens où de cartographie SUR le web il devient cartographie VIA le web. La finalité ultime est de pouvoir enchaîner des traitements prédéfinis sur les données distantes (de type WFS), pour récupérer une donnée adaptée à l’usage que l’on souhaite en faire localement, sans avoir à télécharger/manipuler la donnée source. Ceci sans pré-supposé quant au client utilisé. Mais vu l’immaturité des principaux logiciels SIG en termes d’implémentation de client WPS (déjà qu’avec le WMS/WFS il y a des progrès à faire), il sera nécessaire de prévoir un Zoo Client (web ou pas) générique, capable de conserver références des serveurs et des process, de les assembler, et d’en rediriger la sortie vers ce qui convient le mieux à l’utilisateur (affichage, fichier à enregistrer…) De quoi faire sortir le GeoWeb de la « Naïve Geography« .

A la semaine prochaine pour un compte-rendu !

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.

Certains durent d’autres pas…

Mardi 12 août 2008

Phénomène assez inhabituel pour un projet quasi-institutionnel puisque sous couvert de l’OSGeo, le développement de  MapBuilder vient d’être arrêté par son comité de pilotage. Les raisons invoquées sont d’une part l’aboutissement technique de la solution, désormais stable, complet et conforme aux standards; d’autre part la concurrence féroce livrée, bien involontairement, par OpenLayers, tant au niveau des utilisateurs que des développeurs. De ce que j’en constate, c’est aussi la fin d’un modèle de produit de webmapping, associant étroitement les environnements client et serveur. Comme Cartoweb, remplacé par le plus flexible MapFish (qui utilise également OpenLayers), MapBuilder était un produit tout en un, où un client spécifique communiquait avec un serveur idoine. Or, la diffusion des standards (WMS, WFS, mais aussi GeoRSS ou GeoJSON) exige du client que celui-ci soit indépendant d’une quelconque configuration serveur, pour peu que celui-ci puisse lui communiquer des flux répondant aux normes. MapFish client et MapFish serveur sont ainsi deux environnements complètement indépendants, même s’ils sont associés sous une même appellation.

De même, dans mes récents développements pour le Grand Toulouse, j’ai utilisé un framework Python (Django) sur le serveur (mais ça aurait pu être Symfony, enfin, presque…), et le même client que tout le monde, OpenLayers. L’intérêt d’OpenLayers, et la principale raison de son succès (voir aussi l’API du Géoportail…), est qu’il sait se faire oublier tout en pouvant intégrer une quantité de types de données impressionnante.

De ce fait, la récente intégration de GeoDjango dans la version principale de Django ouvre des perspectives plus qu’intéressantes. Outre le fait de pouvoir disposer du meilleur framework actuel (sans exagérer bien sûr, cf le lien plus haut), la possibilité ainsi offerte de manipuler (lire, interroger, croiser…) les données géographiques à partir d’un ORM est très séduisante car elle répond aux besoins du moment : stocker la donnée au meilleur format possible (PostGIS, what else ?) pour la diffuser sous quelque format que ce soit (XML, GML, GeoJSON, KML…) pour s’adapter à son contexte d’utilisation.

Brevetage d’URL

Mercredi 24 octobre 2007

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