Archive pour le mot-clef ‘OpenLayers’

Polymaps

Lundi 23 août 2010

Je me souviens d’une présentation faire à FOSS4G 2009 intitulée There is no alternative to OpenLayers…?. Le constat était qu’OpenLayers tendait à devenir l’unique client cartographique web dans le domaine open source. Bonne chose ou pas ? Je n’en sais rien.

Je ne sais pas non plus si Polymaps peut constituer une alternative dont les capacités seraient comparables à celles d’OpenLayers. Ce projet libre à base de JQuery a été lancé officiellement en fin de semaine dernière (cf. ici) et présente déjà quelques capacités intéressantes : jetez un œil aux exemples. Une des principales particularités de Polymaps est d’être basé sur le format SVG du W3C.

Via WebResourcesDepot.

On est les champions !

Vendredi 24 avril 2009

Question : dans quelle discipline la France occupe-t-elle la première place devant l’Espagne, l’Allemagne et l’Australie ? Non, ce n’est le foot (l’Australie pff…), ni la chasse aux paradis fiscaux, mais l’activité OpenSource ! Des gens très sérieux (RedHat et le Georgia Institute for Technology) ont fait un index, l’OSI, pour OpenSource Index, et donc un classement non moins sérieux, avec une belle carte,  dans lequel la France obtient le premier rang pour son activité OpenSource. Elle le doit surtout à la note dans la catégorie « Gouverment », ce qui va faire chaud au coeur de nos députés (qui utilisent Ubuntu), de la Gendarmerie Nationale qui a entrepris une migration de grande ampleur vers le libre, mais aussi de l’ADDULACT ou du BRGM. Qui sait, le dernier GeoSource a peut-être permis de faire la différence avec l’Espagne (2e du classement) qui la ramène un peu avec GvSIG

Pour mieux comprendre le classement, il y a toute la démarche qui est expliquée, du moins pour ceux qui ont le courage de lire les 23 pages serrées… Plus court, une FAQ répond aux questions d’usage, genre « Pourquoi mon pays n’apparaît pas dans la liste ? » Et bien ce n’est pas parce que ton pays est tout nul en OpenSource, c’est tout simplement parce qu’il est tellement arriéré qu’on a même pas pu trouver une donnée pertinente. Content ? Pour les obsessionnels, le dernier paragraphe explique comment la carte a été créée : à partir d’un shapefile fourni par thematicmapping.org, les géométries ont été allégées des trucs inutiles (Corse, Sardaigne, Irlande du Nord…), puis simplifiées. Le tout a été transformé en GeoJSON (760 ko quand-même) par OGR, et est reprojeté à la volée par OpenLayers, ce qui explique sans doute pourquoi c’est si lent.

Vive la France, vive la République, vive le Logiciel Libre !

Anti-sèche pour OpenLayers 2.7

Vendredi 20 mars 2009

Une bonne idée pour ne jamais être pris de court.

SAO : Saisie assistée par OpenLayers

Jeudi 12 mars 2009

Deux nouveaux contrôles vont faire leur apparition dans OpenLayers 2.8 (ici pour la traduction française, à la grammaire près). Il s’agit d’outils d’aide à la saisie, bien utiles pour faciliter le travail et augmenter sa qualité géométrique.

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.

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.