Certes, mais il y a un hic. Le code de ladite projection est le 3857 (voir les détails sur http://www.epsg-registry.org/ et notamment cette remarque : « It is not a recognised geodetic system »…Tout est dit !). Or toutes les applications web ont pris l’habitude de traiter cette projection sous le pseudo-code 900913 qui est ainsi répandu dans tout ce qui fait le geoweb d’aujourd’hui. On rentre donc dans une phase de turbulences qui va voir les deux codes coexister, ou pas, dans les différents composants. Avec les blocages associés. Si Openlayers se met à appeler les WMS en 3857 lorsque la carte est en Spherical Mercator, que vont dire les serveurs configurés pour servir du 900913 ? Aïe.

D’où l’importance d’une rapide prise en compte de cet aspects de la part des différents responsables de projets Open Source Géographiques. Au final, tout sera quand-même bien plus clair, même si incorporer l’EPSG donne à cette projection des lettres de noblesse qu’elle ne mérite pas de par ses qualités intrinsèques.

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 !

Ce référentiel utilise un nouveau namespace, c’est-à-dire qu’il se situe au même niveau que celui de l’EPSG. Cela pose quelques problèmes, puisque MapServer par exemple ne prévoit que de rechercher le namespace epsg. Une projection définie par « +init=IGNF:LAMBE » ne sera donc pas interprétée comme du Lambert Etendu, mais fera planter MapServer. Pour pallier ce manque, et en attendant qu’une prochaine version de MapServer intègre cette modification, une version custom IGN de MapServer 5.0.0. est disponible. On peut lui parler en IGNF sans la vexer. Comme me le rappelait Gilles Martinoty, chef de projet Lambert 93 à l’IGN, ce nouveau registre garantit traçabilité et fiabilité des paramètres puisqu’il est fourni par le Service de Géodésie de l’IGN, responsable des systèmes géodésiques français.

En outre, ce registre comporte aussi la description des projections utilisées par le Géoportail, ce qui peut permettre d’intégrer ses propres couches ainsi reprojetées à une application utilisant l’API Géoportail (en 800 x 600, et à raison de 10000 tuiles par jour et par clé selon les nouvelles conditions d’utilisation). On y apprend que la projection utilisée est une projection équirectangulaire, dont seul le parallèle de référence change pour les diverses zones représentées (Métropole, DOM, TOM et autres…)

A noter que le registre IGNF existe aussi pour PostGIS (469 injectées dans la table spatial_ref_sys) et pour QGis. On dit merci qui ?

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…

http://spatialreference.org/ref/epsg/27572/Proj4 renvoie ainsi un flux texte correspondant au Lambert II structuré selon la norme Proj4.

L’intérêt ? Pouvoir à terme intégrer ces URL en lieu et place des définitions elles-mêmes dans l’utilisation de GDAL ou de MapServer par exemple. Donc un moyen simple d’accéder à des définitions maintenues à jour, sans avoir à mettre les mains dans les fichiers EPSG de la librairie proj, ainsi que de créer ou d’utiliser des projections non définies par l’EPSG.

Autre intérêt du site : bâti autour du framework Django, donc écrit en Python, avec une architecture REST, il montre ce que ces technologies peuvent apporter en termes de simplicité et de flexibilité dans la mise en oeuvre de webservices cartographiques.