Retour d’expérience sur l’API IGN 2.0

J’ai passé une bonne partie de l’été à plancher sur la mise à jour de plusieurs applications web (Atlas des patrimoines, GeoFoncier entre autres) dont la particularité était de faire un usage immodéré et hautement stratégique des services de l’API IGN. A l’occasion de la sortie du Geoportail v3 en juillet, la célèbre API de l’IGN a en effet évolué de manière significative pour déboucher sur une version 2.0 bien différente de la précédente.

  • Une nouvelle projection…
    La première de ces évolutions est assez bouleversante. L’API IGN a désormais une projection unique en Spherical Mercator, le truc inventé par Google pour ne pas se compliquer la vie avec des ellipsoïdes et leurs petits et grands axes. La Terre y est donc une sphère parfaite. Force est cependant de constater que cela n’a jamais perturbé grand monde quand il s’agit de manipuler GoogleMaps. L’IGN était précédemment resté sur une posture « géographesque » et avait refusé d’utiliser ce genre de camelote. On avait donc dans l’API v1.x un subtil mélange de projection de Miller pour les petites échelles (de quoi assurer une continuité de consultation sur l’ensemble du globe, la France étant présente dans tous les hémisphères et océans), et une projection plus adaptées aux échelles locales (la fameuse GeoportalFXX en France, qui n’était jamais qu’une cylindrique équidistante centrée sur la latitude 46,5). On avait donc une projection spécifique pour chaque glorieux vestige de notre passé colonial, ce qui pouvait un tantinet secouer les applications quand on passait d’un territoire à l’autre (d’où très souvent des accès différenciés pour chacun et non un déplacement vers tel ou tel).
    Néanmoins, le principal avantage de cette approche était la totale compatibilité avec les services WMS en plate-carrée, donc de l’EPSG:4326 extrêmement répandu (non que l’EPSG:4326 ou WGS84 soit de la plate-carrée, mais son utilisation pour générer directement une image par définition plate donne de la plate-carrée.). Dès lors, il était très facile d’intégrer des flux WMS externes à une carte bâtie à partie de l’API IGN et ce quelque soit le territoire.
    Avec le Spherical Mercator, ça se complique un peu. Gros avantage, il faut quand même le souligner et le saluer, on gagne une compatibilité totale avec les autres API (GoogleMaps, Bing, OpenStreetMap). Il devient donc hyper simple de superposer une carte OSM à un fond d’orthophotographie de l’IGN, et ça a de la gueule (teaser : on attend donc maintenant l’autorisation expresse de l’IGN de numériser de la donnée OSM à partir de ses données…). Mais le Spherical Mercator reste extrêmement peu répandu dans les services WMS, au prétexte que « ce n’est pas une vraie projection de vrai géomaticien quand-même »… Au prétexte aussi que l’élaboration d’un code EPSG pour cette chose a été un vrai bordel, avec d’abord le 900913 imposé par l’usage (car 900913 c’est Google en Leet) mais jamais officiellement référencé, puis le 3758, le 3587 suite à une faute de frappe et enfin le EPSG:3857 qui est le désormais le code officiel pour le Spherical Mercator (aussi appelé Web Mercator). Personne ne s’est donc franchement précipité pour la proposer dans son service WMS (rappelons en passant que Cartorisque utilise encore une version dépréciée du code EPSG pour le Lambert II étendu, soit le 27582 plutôt que le 27572. Mais comme le Lambert II lui-même est déprécié, il n’y a pas urgence). Donc, à moins d’avoir le contrôle de l’ensemble des services web additionnels à intégrer dans la carte (mais qui ne propose plus d’ajouter un WMS externe de nos jours ?) l’utilisation du 3857 reste encore un vœu pieu si ce n’est un fol espoir, et je pressens qu’il y aura suffisamment de fondamentalistes de la géomatique à ne vouloir jamais le proposer pour tout de suite envisager le plan B.
    Le plan B, c’est celui qui permet à l’API IGN de se targuer d’être compatible INSPIRE. Or le Spherical Mercator ne l’est pas (ceux qui ont de l’appétit peuvent s’enquiller ça). En gros, INSPIRE dit ETRS89 (EPSG:4258, mais WGS84 est compatible) et selon les échelles du Lambert Conforme Conique (EPSG:3034) ou du Transverse Mercator. Sur ces bases, l’API IGN ne serait pas INSPIREd. Sauf qu’il y a une astuce. A grande échelle (disons supérieure au millionième), l’affichage d’une plate-carrée (EPGS:4326) sur du Spherical Mercator est possible. Il y a une légère déformation élastique vers le nord, mais qui s’amenuise graduellement à mesure que l’échelle augmente. Donc de fait, on peut toujours intégrer des flux EPSG:4326 dans l’API IGN. Aux petites échelles (France entière notamment), la déformation est trop importante, elle est très visible (de l’ordre de 50 km au nord de la France), car une trop large plage de latitude est couverte. La solution ? Appeler le flux externe en mode tuilé. Chacune des tuiles couvrant une faible latitude, la déformation restera indécelable.
    Il s’agit donc soit de limiter l’affichage des couches issues de services en EPSG:4326 aux moyennes et grandes échelles, soit de les utiliser en mode tuilé, ce qui n’est pas forcément toujours pertinent. Côté inter-opérabilité, il y a mieux.
  • De chouettes nouveaux services
    J’ai fait mon désagréable dans le paragraphe précédent. Si j’ai encore des lecteurs arrivés jusqu’ici, j’aimerais souligner la mise en oeuvre des services WMTS. J’en ai parlé précédemment, il s’agit de la récente norme OGC concernant les services tuilés. La précédente version de l’API utilisait la pseudo-norme WMS-C. Désormais c’est du fermier AOC.
    Ces services WMTS couvrent ainsi le monde entier (il le faut bien puisque c’est la même pyramide de tuiles que celle de GoogleMaps et consorts qui est utilisée), sans les contraintes de changement de projection de la version précédente. Mais un service WMTS a des contraintes structurelles que le WMS-C n’avait pas. Puisqu’on fait des appels aux tuiles selon un conformisme x,y,z (dénommés TILECOL, TILEROW et TILEMATRIX dans la requête), il faut bien ajuster sa configuration cliente. Tant qu’on garde toutes les résolutions, pas de problème, puisque ce sont les résolutions par défaut d’OpenLayers. Mais si on veut limiter la consultation aux échelles les plus grandes, et donc configurer sa carte avec uniquement les 10 dernières résolutions de la pyramide, il faudra veiller à utiliser le paramètre zoomOffset dans la configuration des couches, qui seul permettra de recaler correctement votre résolution 0 avec celle qui n’est pas 0 mais 11 pour le service, puisque l’API publie 21 niveaux.
  • Un chargement dans le corps de la page.
    L’API v1 s’appelait avec sa clé, par des urls de la forme http://api.ign.fr/geoportail/api?key=YOUR_KEY. On recevait donc l’API parce qu’on avait la bonne clé pour le referer appelant. On charge désormais d’abord l’API d’abord, puis on s’authentifie à l’aide de la clé. C’est assez pratique car cela permet de conserver toutes les sources en local, sans avoir à manipuler l’ancien paramètre includeEngine. Mais pour s’authentifier, il faut que l’API soit chargée. C’est pour cela que l’IGN conseille (voir la doc) d’appeler l’API dans le corps (body) de la page puis de lancer la procédure d’authentification sur l’événement window.onLoad qui garantit que le script appelé précédemment a bien été chargé. C’est effectivement efficace mais pas forcément adapté à toutes les situations. Avec un environnement ExtJS, j’ai utilisé un appel sur Ext.onReady, car rien ne garantissait que tout l’environnement ExtJS soit chargé au window.onLoad. Mais on peut surtout faire l’authentification bien après dans le code, au moment de l’instanciation des couches OpenLayers par exemple. Le retour asynchrone du ‘OK’ de l’IGN peut poser des problèmes de temporisation avec le chargement d’autres composants mais rien qui ne soit insurmontable. Le meilleur compromis que j’ai pu trouver est d’utiliser les classes OpenLayers classiques (pour créer la map notamment), puis d’appeler l’authentification et au retour de celle-ci charger les couches IGN puis appeler une autre fonction chargeant les autres couches et contrôles. De la sorte, on peut mettre un timer en amont pour appeler cette dernière fonction quoi qu’il arrive (si l’API ne répond pas, si la clé n’est pas valide…). L’échec du chargement des couches IGN ne compromet ainsi pas le bon fonctionnement de l’application dans son ensemble.
  • Des contrats compliqués.
    Jusqu’alors, quand on souscrivait un contrat, pour avoir une clé d’authentification, on avait accès à toutes les couches de l’API (Ortho, Scan mais aussi Etat-Major, Cassini, Corine Land Cover…). Désormais, tout nouveau contrat ne donne accès qu’à l’orthophotographie et aux cartes (pyramide des Scans). Pour avoir droit au reste, il faut passer par le service commercial, ce qui n’est pas forcément payant, mais qui peut être fastidieux. Surtout, les contrats de développements sont uniquement utilisables en localhost ce qui est très contraignant car la plupart du temps on fait tourner les applications sur un serveur de développement qui n’est pas localhost. Il faut alors jongler avec des plugins divers pour tromper l’adversaire en changeant le referer. Pas très simple, surtout quand on configure. On ne sait pas forcément d’où vient l’erreur. Quelques indices issus de l’expérience : si les appels WMTS renvoient du 403 (forbidden), le couple clé/referer n’est pas bon. S’ils renvoient du 404 (non trouvé), c’est plutôt que votre configuration n’est pas bonne, entraînant l’appel d’une tuile (ligne, colonne, zoom) inexistante. Si c’est du 400 (bad request), cela peut vouloir dire que vous demandez un format non proposé (JPEG pour le cadastre par exemple).
    Toujours est-il qu’au final, la mise en œuvre d’une grosse application web avec ses divers intervenants, plateformes de développement, de recette et de production, peut être compliquée par cet aspect contractuel. Je remercie donc chaleureusement les équipes techniques et commerciales de l’API IGN pour leurs interventions diverses.

En conclusion de cette découverte de la nouvelle API IGN, je dirais que c’est le temps de la maturité. Une approche pragmatique de la projection utilisée pour faciliter l’adoption par le plus grand nombre et dans des applications grand public. Parallèlement un habile compromis avec INSPIRE, permettant, sous certaines conditions, d’afficher une compatibilité avec les services normalisés. Enfin, des contrats plus carrés, plus pro, certes contraignants à l’usage, mais indiquant clairement que l’API IGN n’est plus un joujou pour les geeks, mais bien un nouveau produit IGN et qu’à ce titre, son usage passe par les canaux généraux. Ce qui est aussi, in fine, pas encore une garantie, mais déjà une espérance de qualité de service.

 

 

6 commentaires :

  1. Publié le 13 septembre 2012, 13:18 par IGN_IGN

    Pour un usage web, les ressources proposées par défaut ont en effet été limitées à l’essentiel (service WMTS sur les cartes et photos, service OpenLS sur la BD ADRESSE) afin de ne pas ralentir le chargement de l’API pour les 95 % des utilisateurs qui n’utilisent que ces ressources, le reste faisant l’objet d’un ajout à la demande.

    Bonne nouvelle cependant : la possibilité de modifier soi-même les ressources des contrats API en libre-service, sans avoir à appeler l’unité en charge de la gestion des contrats, est programmée pour d’ici 6 à 8 semaines.

    A noter que les utilisateurs qui faisaient historiquement appel à d’autres ressources du Géoportail, telles que le cadastre, ont retrouvé leurs petits post-bascule vers le Géoportail 3.

  2. Publié le 13 septembre 2012, 13:45 par Guillaume Sueur

    Bonne nouvelle que de trouver un peu plus de souplesse dans la gestion de son compte.
    Pour la bascule des contrats, c’est sans doute vrai des applications en « tout automatique », mais je peux vous garantir qu’il a été compliqué de synchroniser le contenu des contrats v3 des nouvelles clés et de leurs déclinaisons (dev, recette, prod…) avec les contenus des anciens, toujours en service et en production au même moment.

  3. Publié le 13 septembre 2012, 20:21 par Laurent Pierre

    5(_)|*3R 4R71(13

    • Publié le 18 septembre 2012, 11:46 par Guillaume Sueur

      Il m’a fallu un peu de temps pour te lire, mais |v|32[1 !

  4. Publié le 21 septembre 2012, 18:05 par Benoit David

    Je ne suis pas d’accord sur l’analyse concernant l’astuce de compatibilité Inspire de la projection EPSG:3857.
    Ce n’est pas l’API Javascript qui permet à l’IGN d’être conforme à Inspire. L’obligation Inspire est notamment de fournir pour ses données un service de consultation gratuit et, pour cela, l’IGN propose un service de consultation WMS en projection EPSG:4258.
    L’astuce est plutôt que le service de consultation Inspire est beaucoup moins utilisé que le service WMTS et qu’un service WMS devrait suffire.

    • Publié le 21 septembre 2012, 21:06 par Guillaume Sueur

      Bonsoir,

      Notez bien que je n’ai pas indiqué que l’API était le moyen trouvé par l’IGN pour se mettre en règle vis à vis d’Inspire, mais bien qu’au sein de l’API c’était bien la compatibilité relative entre 4326 et 3857 à partir des échelles moyennes qui permettait d’y prétendre pour les services qu’elle propose, à savoir les services WMTS qui sont une des options utilisables dans le cadre des View Services. Mais l’IGN à en effet plus d’une corde à son arc, et des services WMS inspiro-compatibles existent aussi en dehors de l’API Javascript.

Publier un nouveau commentaire