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 !

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.

Je suis donc heureux de valoriser ce travail en proposant un mirroir à la distribution.

Site officiel en anglais (le lien ci-dessus étant réservé aux lusophones…)

• la taille de la fenêtre cartographique ne doit pas dépasser 400 x 400 pixels (autant dire du webmapping du siècle dernier). C’est tellement petit que même dans les pages d’exemple ils n’ont pas osé respecter cette clause, la carte y est en 900 x 500. Même la mini-carte est en 500 x 400 !
• le nombre de pages vues ne doit pas dépasser 100 / jour ou le nombre de tuiles chargées ne doit pas dépasser 10000/j. Rien qu’avec les fautes de frappe et les petites optimisations liées à la conception d’une page carto, il va me falloir 1 semaine pour faire quelquechose de potable.

Ensuite, l’API est en fait une surcharge d’OpenLayers. Comme ses collègues britanniques de l’Ordnance Survey, l’IGN a donc choisi cette API OpenSource (licence BSD) à la communauté dynamique pour créer un produit complètement propriétaire. La documentation pointe d’ailleurs directement vers les pages d’OpenLayers pour les composants « standard ». Sauf que sans mention de la version d’OL utilisée, on risque rapidement de se retrouver avec une documentation déconnectée de la version utilisée (une « fork » comme on dit dans le Lot).

Plus rigolo encore sont les « Obligations des Bêta-Testeurs ». On a déjà vu qu’ils avaient juste le droit de montrer une fenêtre de 400 x 400 à quelques membres de leur famille, mais pour pouvoir bénéficier de ce privilège, il faut quand-même respecter quelques règles de bonne conduite (c’est moi qui souligne le plus beau passage) : « A aucun moment vous ne devez effectuer (ou sciemment laisser faire) une utilisation illégale, trompeuse ou mensongère de l’API bêta ou de données du Géoportail, y compris, mais sans exhaustivité, le dénigrement de l’IGN ou du Géoportail ou d’autres pratiques qui peuvent être préjudiciables à l’IGN ou au Géoportail. » Donc pas de banderole genre « Riquiqui, limité, fermé – Bienvenue à l’API Géoportail ! » au prochain géo-événement ok ?

C’est plutôt complet, un peu aride diront les esthètes, mais c’est surtout mis à jour régulièrement.

Merci à Stephan Steiniger pour cette réalisation fort utile.

L’association (« educationnal charity » en anglais, à but non lucratif donc) Oxford Archeology vient d’être notifiée par ESRI qu’elle ne pouvait plus se prévaloir des remises « éducation » pour ses licences ArcGIS car les associations étaient désormais exclues de ce périmètre. L’association, qui utilise 60 postes de travail sous ArcGIS, verra ses licences actuelles désactivées à la fin du mois (!), à moins de s’acquitter des tarifs « standard » d’ici là. Comme Oxford Archeology n’a pas les moyens de poursuivre avec ESRI, elle réfléchit à un basculement vers des solutions OpenSource. Question de coût donc ? Pas que. Car des logiciels propriétaires plus abordables pourraient être envisagés. Mais question de liberté surtout. Car tout autre logiciel propriétaire, s’il pourrait alléger les coûts, ne changerait pas la situation de base : la totale dépendance de l’utilisateur vis-à-vis de la politique commerciale (tarifs, conditions d’utilisation) et industrielle (mises à jour, correctifs, support…) de son éditeur, donc la subordination de son activité, et partant de là de son coût de revient et de sa productivité, à un tiers.

L’OpenSource a une approche inverse : mettre à la disposition de tous des outils informatiques et des ressources permettant à chacun d’être indépendant, autonome et libre dans leur utilisation :

« Free software is software that gives you the user the freedom to share, study and modify it. We call this free software because the user is free. » (Free Software Foundation)

Cela a parfois un coût aussi, direct ou induit, mais c’est celui de la liberté.

PS : ESRI a trouvé bon de faire remarquer à Jo Cook, auteur de l’article sus-mentionné dans son blog personnel, que les négociations en cours pourraient se trouver compromises par les propos tenus dans son blog. Liberté je vous dis !

via Technical Ramblings

• « Promouvoir la concurrence entre les logiciels propriétaires et les logiciels libres dans les appels d’offres, notamment publics. Un objectif de 20 % des applications nouvellement développées ou installées au profit du secteur public en open source pourrait être fixé à l’horizon 2012.
• Considérer fiscalement, comme aux États-Unis, les aides aux communautés des logiciels libres comme du mécénat de compétence.
• Exiger, à un niveau européen dans le cadre de la politique de la concurrence entre solutions logicielles, la fixation de normes internationales garantissant l’interopérabilité entre logiciels libres et les logiciels propriétaires, en priorité. »

Dans son préambule, l’article indique par ailleurs que le recours aux logiciels libres « induit une économie moyenne de 36 % en recherche et développement pour les entreprises utilisatrices ».

Que du bon donc. Las, 20 % des marchés publics c’est encore trop pour certains et l’AFDEL (Association Française des éditeurs de logiciels, le lobby français du logiciel donc, qui regroupe des sociétés telles que Dassaults Systèmes ou Microsoft) a trouvé bon de juger le rapport « iconoclaste » car défendant la promotion « exclusive et discriminatoire » du logiciel libre, qui réalise aujourd’hui seulement 2 % de parts de marché. L’AFDEL ajoute que « le logiciel libre n’a ainsi, de l’avis des spécialistes, pas débouché à ce jour sur des innovations de rupture. La plupart de ses produits phare s’avèrent des clones –parfois améliorés – de produits déjà existant sous modèle propriétaire. » Outre que le concept d’innovation de rupture mériterait une juste définition, on aimerait aussi avoir les noms et les publications de ces spécialistes. Quant à voir Apache, PostgreSQL, MySQL, PHP, et tant d’autres ramenés à de simples clones si ce n’est pas de l’humour, ça fait rire quand-même. Cette analyse a un point de vue exclusivement industriel, opposant des produits, des modèles économiques et des parts de marchés. Mais le logiciel libre a une autre dimension que le logiciel propriétaire n’a pas, c’est sa dimension pédagogique, éducative et communautaire. Le logiciel libre permet à tous de s’impliquer dans le développement logiciel, la mise en oeuvre de sites web, la rédaction de documentation sans avoir à s’acquitter d’un ticket d’entrée sous forme de coût de licence. Cette facilité crée de la connaissance, en favorise le partage et fait émerger de nouvelles idées et de nouveaux concepts. Que certains proposent du service payant autour de ces technologies (moi le premier) n’est pas intrinsèquement lié au produit lui-même, et le service ainsi rendu est indépendant tant du produit que du prestataire. Par son libre accès (au logiciel lui-même, au code) le logiciel libre favorise la dissémination et l’expérimentation. En retour, cela implique ouverture et interopérabilité. Quand une géodatabase ESRI ne peut être exploitée que par les logiciels conçus par la même société, ou au travers d’outils de transformation payants, une base PostGIS peut l’être par une multitude de clients, libres ou pas. C’est sans doute là que se situe l’innovation de rupture fondamentale.

Voir aussi le communiqué de l’AFUL sur le sujet.

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