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.

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 !

Un outil de snapping (accrochage aux objets existants) avec une belle granularité des options puisqu’il propose l’accrochage aux noeuds, simples sommets et même bordures, chacune étant complètement configurable indépendamment des autres (activation, tolérance).

Un outil de découpage (split) qui permet de décomposer des géométries existantes à partir d’un nouveau tracé. C’est par exemple utile lors de la création de réseaux linéaires, une nouvelle ligne découpant automatiquement celles qu’elle coupe aux intersections, de manière à obtenir un réseau non pas encore topologique (il faudra séparer noeuds et arcs pour cela) mais bien structuré. Ca parait plus simple que le snapping, mais c’est plus délicat que ça en a l’air, car l’utilisation de cet outil impacte des géométries existantes à la différence du premier qui ne faisait que les utiliser. Un objet linéaire disposant d’un id et d’un attribut longueur par exemple va se retrouver segmenté en deux parties distinctes, dont il faudra donc corriger les attributs (nouveaux ids, recalcul des longueurs…). Fort heureusement l’outil de découpage a été bien conçu puisqu’il intègre un événement aftersplit qui permet de récupérer les objets venant d’être recomposés. Charge au développeur d’implémenter ce dont il a besoin à ce niveau.

Les objets à découper peuvent également être filtrés en fonction d’un attribut (afin, par exemple, de ne pas découper les autoroutes quand on trace des départementales)

Enfin, les deux contrôles peuvent être activés conjointement, et permettent d’interagir (en découpe ou accroche) avec d’autres couches que celles utilisées pour la saisie.

Au-delà de la prouesse technique, j’avoue que je suis surtout séduit par le professionnalisme de l’approche « métier ».  Sans doute que le sponsor de ces développements, SWECO, spécialisé dans le génie civil et le BTP n’y est pas étranger ! Un seul défaut à mon sens, l’absence de curseur de contrôle du positionnement en tout début de saisie, qui fait que le premier point est placé sans savoir si l’accrochage est effectif ou pas. Et si la taille de celui-ci, qui serait alors un cercle, pouvait reprendre la tolérance, on toucherait au nirvana !

Plus prosaïquement, on se rapproche lentement de solutions full-web de saisie cartographique. Quelques contrôles de topologie effectués sur le serveur (au hasard avec… GeoDjango !) peuvent venir améliorer encore le résultat sans trop d’efforts (absence d’intersection entre les polygones, validité des géométries…). Reste que la manipulation d’objets vectoriels dans un navigateur a une limite liée à la capacité de ce même navigateur. Au-delà d’un certain nombre de points (sommets, noeuds…), l’application se fige et devient inutilisable. Mais cette limite est sans cesse repoussée par l’améliration des navigateurs et la puissance des machines. Donc oui, ça devient envisageable, sans être trivial.

Un très beau guide d’installation de GeoSource V2, de la configuration du serveur lui-même à la personnalisation des interfaces, réalisé par le GIP Ecofor dans le cadre de son projet
Catalogue des Sources d’Information sur la Forêt (Ca-SIF). On peut juste regretter que la distribution cible soit une Debian Etch, alors que la version Lenny vient de passer à stable. Ce n’est pas si souvent que Debian met à jour sa distribution, alors il ne faut pas se gâcher le plaisir d’avoir enfin des paquetages récents dans la version stable !

(via georezo/geolibre)

L’originalité, outre le fait qu’il soit écrit en PHP, vient de sa capacité à stocker le tuilage dans Google App Engine, ce qui rendra vos tuiles beaucoup plus disponibles que sur votre propre serveur puisqu’elles bénéficieront de l’infrastructure Google.

via James Fee GIS Blog

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.

Seuls deux produits bénéficient aujourd’hui d’une telle labellisation, à savoir ArcGIS 9.3 et AutoCadMap 2009 (toujours en avance sur leur temps chez Autodesk !). Ce processus se fait sur demande, et est payant, afin de financer les opérations de tests et de contrôle des résultats.

Concernant nos deux produits fétiches, Proj et Gdal/Ogr, le processus se fera en interne à l’IGN et semble être en cours. La labellisation devrait se faire après celle d’IgnMap, produit maison grand public, et portera essentiellement sur les exécutables gdalwarp (rectification de rasters) et ogr2ogr dans ses opérations de reprojection.

Connaissant la souplesse et la maniabilité de ces outils, voilà qui devrait permettre de pousser un grand ‘ouf’ de soulagement à tous ceux qui voyait 2009, date à laquelle les produits IGN ou DGI seront livrés en L93, approcher avec effroi.

L’équation du jour : OpenSource + compétence technique + certification = un souci de moins pour tout administrateur SIG !