• JEQL : un langage de script dont la syntaxe est proche de SQL. Il ne s’agit pas d’une interface pour exécuter des requêtes sur une base de données relationnelle mais bien d’un outil pour écrire des traitements sur des données géospatiales avec des capacités de lecture/écriture supportant des formats tels que shapefile et KML. Pour plus d’infos et des exemples, jetez un œil ici et là ;
• Fiona : un module Python écrit par Sean Gillies dont le but est d’offrir une interface élégante à OGR. Il y a quelques mois ce projet se nommait encore WorldMill. Un exemple concis de lecture/écriture de shapefiles avec Fiona et Shapely : Yours truly, Fiona ;
• FDO Toolbox : une IHM graphique pour FDO écrite en .NET (il n’existe qu’une version pour Windows de cet outil) permettant d’accéder de manière unifiée à de nombreux formats de données. Cet outil permet de réaliser des conversions et des traitements de données. Il est possible d’écrire des scripts en Python. Il semblerait que cet outil ne doive plus évoluer (cf. ici).

Bien entendu, ces outils n’ont pas la richesse fonctionnelle d’un ETL tel que Talend Spatial. Ils n’en sont pas moins intéressants.

On peut sans doute prévoir pour 2015 un premier tweet du genre : « Folks, I guess something is rotten in the OGC specs ».

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 !

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 !

C’est précisément l’API du Géoportail qui a incité l’IGN a franchir ce pas. Pour la future version, prévue sous peu, il a été décidé qu’elle deviendrait un type de couche d’OpenLayers, à la manière de ce qui existe pour GoogleMaps. Cette décision renforce le niveau d’intégration de l’API dans OpenLayers, et ce faisant le niveau d’implication de l’IGN dans le projet global (résolution de bugs, patches, nouvelles fonctionnalités…). Mais il était difficile à l’IGN de se soumettre aux Conditions de licence de Metacarta, qui, même si elles sont protectrices pour le projet lui-même, en reviennent à soumettre une institution publique française au droit de regard d’une entité privée américaine, damned ! Le passage par l’OSGeo, fondation à but non lucratif, permettrait de contourner cet obstacle, même si Metacarta reste le détenteur final du copyright.

Toujours est-il que les buts des développeurs de l’IGN est clairement de contribuer régulièrement à la solution OpenLayers, afin d’en faire le standard européen pour les Géoportails. A la différence de l’Ordnance Survey britannique, et à ce que la bêta avait pu faire croire, l’IGN se place donc résolument dans le camp de la généricité et de la mise en commun de ses efforts, ce qui mérite un grand respect et de chaleureux remerciements. Que l’été va sembler long, à attendre la nouvelle version de l’API Geoportail…

Le GeoJSON est un format cartographique un peu particulier puisqu’il n’est pas destiné au stockage mais plutôt au transfert des données cartographiques entre un serveur et un client web exécutant du javascript. Car dans GeoJSON il y a JSON (JavaScript Object Notation) ! Hors de ce contexte donc, point de GeoJSON. L’un des principaux intérêts de ce format est de structurer naturellement son contenu en objets javascript un fois interprété par celui-ci. Par exemple :

{« type »: « FeatureCollection », « features »: [{"type": "Feature","geometry": {"type" : "Point","coordinates" : [527904.26, 1844683.7]}, »properties »: {« nom »: »PLACE ESQUIROL », »adresse »: »15 PL ETIENNE ESQUIROL », »numero »: »0102″, »bornes »: »18″}}]}

génère un objet fait de features, features dont les éléments ont une propriété nom, à laquelle on accède par features[i].properties["nom"], mais aussi une propriété geometry caractérisée par un type et un tableau de coordonnées.

Surtout, les protagonistes à l’oeuvre dans ces specifications ont tenu à l’enrichir suffisamment pour couvrir de très larges contextes d’utilisation. On retrouve donc des objets tels que les multi-lignes, multi-polygones, bounding boxes, ou même des systèmes de référence spatiaux qui peuvent être faits de liens http vers une définition externe (sur http://www.spatialreference.org par exemple).

Enfin, ce format a connu un succès rapide, dès avant sa formalisation complète. OGR l’intègre depuis quelques mois, OpenLayers et FeatureServer également, ça va de soi, mais on le retrouve aussi dans des logiciels propriétaires tels que FME de Safe Software. En tout, plus de vingt logiciels l’utilisent déjà sous une forme ou une autre.

Rien ne synthétise sans doute mieux les récentes évolutions de la néocartographie qui s’affranchit des frontières classiques du SIG que ce format, destiné à faire le lien entre la données carto « classique » et des contextes d’utilisation web de plus en plus diversifiés.

Pour la réaliser, dans un délai très serré, j’ai mis en oeuvre ce que j’estime être le meilleur des technologies OpenSource : un back-office en python, s’appuyant sur le framework Django couplé à une (petite) base de données PostgreSQL, un serveur WMS/WFS avec MapServer, une pincée de GDAL/OGR pour la manipulation des données, un serveur de cache avec TileCache, et bien sûr côté client la dernière version d’OpenLayers et quelques composants MooTools pour les menus. L’intérêt principal de cette architecture est le faible couplage des éléments entre eux. En utilisant des standard d’échange (WMS, XML, JSON…) chaque élément peut être remplacé facilement par un équivalent pour peu qu’il propose les mêmes entrées et sorties. Les données cartographiques sont directement exploitées dans leur format originel, en MapInfo .TAB ou en ECW, afin de faciliter les tâches de mise à jour, qui se font ainsi par simple remplacement des fichiers.

Au niveau fonctionnel, l’application propose visualisation, téléchargement, reprojection, changement de format sur une cinquantaine de couches de données différentes, dont une orthophotographie à 12.5 cm, le parcellaire cadastral, un Modèle Numérique d’Elévation (avec export 3D vers GoogleEarth !) le tout filtré selon le profil de l’utilisateur et les territoires qui lui sont ouverts. Quelqu’un peut ainsi avoir le droit de « voir » une couche sur l’ensemble de l’agglomération, mais ne pouvoir en télécharger qu’une partie. Les utilisateurs peuvent aussi intégrer des ressources WMS externes, ou uploader leurs propres données vers la plateforme. Après validation par l’administrateur, celles-ci deviennent alors visibles par tous.

Le principal défi a été de proposer quelque chose de parfaitement opérationnel en un délai très bref (moins de 30 jours). Pour le relever, le recours à Django s’est révélé être un choix particulièrement judicieux tant la rapidité de développement dans cet environnement et la stabilité du résultat sont impressionnantes. J’en ai par contre peu utilisé les templates, afin de privilégier l’évolutivité et l’autonomie du client. Ainsi la plupart des échanges se font en JSON, notamment l’initialisation de la liste des couches à intégrer dans OpenLayer.
Autre gros avantages de l’utilisation de Django, c’est la constitution quasi-automatique d’un module d’administration très complet. A partir de quelques formulaires, l’administrateur peut ajouter des couches, tout en spécifiant leurs conditions d’accès (droits utilisateurs en visualisation/export), d’affichage (AGG ou PNG, tuilage ou pas, niveau de transparence par défaut…) ou encore le contenu des métadonnées (qui se basent sur template ISO-19139 minimaliste).

Le but à moyen terme, après avoir décontextualisé certains aspects liés aux demandes spécifiques du Grand Toulouse, est aussi de placer cette solution en OpenSource, afin de pouvoir en faire profiter le plus grand nombre. A suivre donc. Si vous passez par Toulouse cette semaine, venez faire un tour du côté du centre des congrès Pierre Baudis, ou n’hésitez pas à me contacter directement pour toute information complémentaire.

• Si les données sources ne sont pas en shapefile, mais en .TAB par exemple, préférer ogr2ogr à un passage par un shapefile intermédiaire, car cela permettra de préserver les noms de champs longs, systématiquement tronqués à 10 caractères lors d’un passage en DBF (avec un shapefile donc).
• Si l’identifiant de la table à créer DOIT être « gid » pour correspondre à des requêtes existantes, prendre shp2pgsql car la modification du nom de la clé primaire par défaut dans ogr (nommée ogc_fid) passe par des variables d’environnement de postgresql, pas très pratiques.
• pour transcrire directement des données 3D en 2D, utiliser ogr2ogr avec l’option -lco DIM=2
• pour spécifier la projection de la nouvelle table, les deux logiciels sont équivalents, mais pour PROJETER les données à la volée (les stocker dans un autre système de projection que celui du fichier source) ogr2ogr est la seule solution.
• chacun propose aussi les options nécessaires pour le mode de « création » : création réelle, remplacement, mise à jour. A noter que l’option spécifique d’ogr pour postgresql (-lco OVERWRITE=yes) ne fonctionne pas sans l’option générale -overwrite
• Seul shp2pgsql permet de spécifier facilement l’encodage de la donnée source (ASCII par défaut) à l’aide de l’option -W. Ogr utilise la variable d’environnement PG_CLIENT_ENCODING, et c’est donc par là qu’il faut passer pour intégrer des données particulières. Ca marche mais c’est moins pratique.
• Création d’un index spatial : seul shp2pgsql propose cette option. L’utilisation d’ogr doit donc être suivie d’une requête SQL spécifique pour le créer. A ne pas négliger car la présence d’un tel index optimise toutes les requêtes exploitant le champ géométrique.
• Conversion des champs : par défaut, ogr2ogr crée des champs à l’identique du DBF. Donc si vous aviez un champ type caractère de taille 10, il en résultera un CHAR(10) dans Postgresql, rempli de blancs quand le contenu du champ n’est pas suffisamment long. Ca peut créer de mauvaises surprises lors de requêtes… Donc ajouter l’option -lco PRECISION=NO si c’est le cas.

Pour compléter ce bref comparatif, voici des requêtes types pour chacun des logiciels :

shp2pgsql -s 27572 -c -D -i -I nom_du_shape nom_de_la_table > nom_fichier.sql

A noter que shp2pgsql est en fait un transcripteur de shape en SQL. Il faut donc ensuite faire lire ce résultat à postgresql : psql -d nom_de_la_base -f nom_fichier.sql
Sous linux, les deux commandes peuvent se piper facilement : shp2pgsql -s 27572 -c -D -i -I nom_du_shape nom_de_la_table | psql -d nom_de_la_base
Dans cet exemple, il est demandé de créer une table en Lambert II étendu (SRID 27572), en mode création (option -c), en mode COPY (-D) nettement plus rapide que des INSERT, mais qui pose parfois problème avec des caractères spéciaux, de mettre les champs de type integer en mode INT4 (option -i, à ne pas utiliser si les données dépassent cette capacité), et enfin de créer un index spatial (-I) ce qui s’avère souvent indispensable. A noter aussi une option intéressante (-S) pour intégrer les géométries en mode simple et non multiple (pour un shapefile contenant des lignes, un table de MULTILINESTRING est sinon créée par défaut). Il faut cependant s’assurer auparavant que tous les objets du shapefile ont bien des géométries simples.

La syntaxe d’ogr2ogr est un peu plus verbeuse, rebutante même de prime abord. L’équivalent de la requête précédente donne en effet :

ogr2ogr -overwrite -a_srs « EPSG:27572″ -f PostgreSQL PG: »host=serveur user=postgres password=postgres dbname=nom_base » fichier_shape.shp -lco LAUNDER=yes -lco DIM=2 -lco GEOMETRY_NAME=the_geom -lco PRECISION=NO -nln nom_table
dans laquelle il est spécifié :
-overwrite pour remplacer la table si elle existe
-a_srs « EPSG:27572″ : pour indiquer que la table est en Lambert II étendu
-f PostgreSQL + chaîne de connexion pour spécifier la base cible
ensuite viennent les options spécifiques à l’exportation vers postgreSQL :
-lco LAUNDER=yes : permet de corriger les noms des champs pour les rendre compatibles avec postgresql sans utilisation de guillemets dans les requêtes
-lco DIM=2 : nombre de dimensions (x,y,z,m, donc 4 maximum pour un shapefile. Mais ogr ne gère que les trois premières). En spécifiant 2 on contraint la table cible à être en 2D.
-lco GEOMETRY_NAME = the_geom : indique le nom à donner à la colonne géométrique
-lco PRECISION=NO pour avoir des VARCHAR plutôt que des CHAR dans la table cible
-nln nom_table: option New Layer Name (nln) pour spécifier le nom à donner à la table cible, si celui-ci est différent du nom du fichier shape.

Les valeurs par défaut des deux logiciels (pour le nom du champ géométrique par exemple : the_geom dans shp2pgsql, wkb_geometry dans ogr2ogr) impose la plus grande vigilance dans leur manipulation conjointe pour alimenter une base de données. Sans oublier de faire suivre tout import ogr par la création d’un index spatial sur la nouvelle table.