Discussion :

[eclesia]

Bonjour,

Pour ma part je ne suis pas féru d'application web toutefois ces données font de bon fond de plan et il serait intéressant de pouvoir y acceder différement. (meme si elles peuvent etre en contre partie bridé ou limité)

Est il possible d'accéder aux données qu'utilise le geoportail via des services plus classiques ? j'entend par la des services de type WMS / WFS , voir meme spécifique au geoportail ?

[dgrichard]

Bonne question ...

Les flux actuels qui sont servis par l'API reposent sur un service WMS-C.
Les contrats API autorisent seulement des flux vers des navigateurs (Cf. CGU ... que je ne retrouve plus sur le site API, argh).

La page qui ne manquera pas d'intéresser les développeurs aguerris est là ... (cela devrait répondre à la question)

Sinon et globalement :

Nous travaillons à de nouvelles CGU pour l'accès aux flux WMS-C sans passer par un navigateur.

Nous travaillons sur les flux WMS/WFS qui ne sont donc pas encore ouverts (problèmes de performances où nous souhaitons être compatible avec les règles de la directive INSPIRE)

Des flux OpenLS (moteurs de recherche lieux et adresse) seront aussi ouverts.

Globalement, si tout se passe bien et d'ici à la fin de l'année, il y aura de la nouveauté ...

[eclesia]

Merci pour les informations, je vais donc attendre que tous ca se mette tranquillement en place.

Une derniere question :
Comment se fait le "comptage" dans ces cas la ? ou est ce que ses services a acces direct necessiteront forcement un contrat (pour obtenir des jetons particulier) ?
car ici il n'est pas possible de comptabiliser le nombre de page vue.

[dgrichard]

Oui, tout service nécessitera un contrat.
Le comptage s'effectue déjà (depuis la 1.0beta4) selon plusieurs métriques (nombre de requêtes, sessions, taille du flux, ...).
Selon la typologie du service, on en déduit la statisque finale.

Les contrats portent aussi des informations sur les ressource employées (données, service y accédant, emprise --facultatif--, IP/FQDN, ...).

Nous sommes en cours de redéfinition du terme "page vue" pour l'API Web 2D Javascript afin de bien spécifier que c'est la notion de l'environnement cartographique qui monte vers le butineur et non directement la page web elle-même.

C'est donc un sujet globalement pas simple. Notre job (nous les techos!-) a été de mettre en place les métriques minimales.

Aux Conditions Générales d'Utilisation de définir (justement) l'utilisation faîte du flux Géoportail par l'application cliente.

J'espère que cela éclaire mieux le dispositif.

[eclesia]

merci bien.

[Max_B]

Bonjour,
je viens de m'inscrire.
Je suis actuellement en train d'évaluer la faisabilité d'une application autonome, permettant l'accès au ressource cartographiques de l'IGN. Cela pose deux questions:

1. La license et les CGU, les contrats: Un élément de réponse se trouve ci-dessus et je suis en contact avec un commercial pour obtenir plus de précisions. En particulier sur le système de décompte en WMS-c, et sa disponibilité.
2. L'aspect technique: même si j'apprécie JavaScript, ce langage n'est pas le plus adapté au développement pour un application embarquée et pose le problème de la performance comme tout langage interprété. La question à laquelle je pense trouver une réponse autorisée ici est : existe-t-il un document spécifiant le protocole question/réponse utilisé par l'API, afin de l'implémenter, partiellement, dans un autre language?

Il est possible de reconstruire le protocole à partir des source JS, mais ce n'est pas une méthode optimale.
Dans tous les cas, cela resterait dans le cadre de requêtes-réponse HTTP qui n'est pas forcément le mieux. Mais d'après ce que je comprend, un protocole WMS-c est prévu mais pas encore prêt. Est-ce bien le cas? Ou est il en prêt mais pas encore commercialisé? Dans ce dernier cas, si on connaît la date de commercialisation, il est peut-être possible de commencer le développement sur ce protocole, en attendant la dispo.

edit: En fouillant, je trouve des éléments de spécification WMS/WMS-c. Elles sont partielles et au stade de proposition. Je cherche le document de référence valable pour l'IGN. Par contre je me rend compte que WMS est systématiquement construit sur HTTP, correct?

[dgrichard]

1. La license et les CGU, les contrats: Un élément de réponse se trouve ci-dessus et je suis en contact avec un commercial pour obtenir plus de précisions. En particulier sur le système de décompte en WMS-c, et sa disponibilité.

Comme indiqué précédemment, notre mission juridique se penche sur cet aspect du point de vue définition.

1. L'aspect technique: même si j'apprécie JavaScript, ce langage n'est pas le plus adapté au développement pour un application embarquée et pose le problème de la performance comme tout langage interprété. La question à laquelle je pense trouver une réponse autorisée ici est : existe-t-il un document spécifiant le protocole question/réponse utilisé par l'API, afin de l'implémenter, partiellement, dans un autre language?

Cette page contient normalement tous les élements techniques. Que manquerait-il ?

Il est possible de reconstruire le protocole à partir des source JS, mais ce n'est pas une méthode optimale.
Dans tous les cas, cela resterait dans le cadre de requêtes-réponse HTTP qui n'est pas forcément le mieux. Mais d'après ce que je comprend, un protocole WMS-c est prévu mais pas encore prêt. Est-ce bien le cas? Ou est il en prêt mais pas encore commercialisé? Dans ce dernier cas, si on connaît la date de commercialisation, il est peut-être possible de commencer le développement sur ce protocole, en attendant la dispo.

Effectivement, traduire le code javascript en un autre langage ne serait vraiment pas optimal. C'est pourquoi nous avons décrit le protocole en question dans la page référencée "Clé API" de la documentation technique.

Les requêtes sont du pur HTTP, nous supportons le GET avec un paramètre qui indique la nature de la réponse (JSON, XML, raw).

Le protocole WMS-C est supporté. Ce qui ne l'est juridiquement pas, c'est l'accès au flux WMS-C par une application autre qu'un butineur car, pour l'instant, les contrats API oblige à passer l'en-tête "Referer" dans la requête montant vers le service de jetons. Techniquement parlant, le dialogue est possible via un proxy ...

Vous pouvez développer votre connecteur (j'ai rêve d'ailleurs que des développeurs QGIS ajoute le support WMS-C, puis GeoDRM "à la Géoportail" pour ouvrir ces flux dans ce merveilleux outil). Nous vous aiderons comme nous l'avons fait pour des éditeurs "privés" qui ont montés des POC (Prove Of Concept - Preuve de concept) sur les flux Géoportail.

edit: En fouillant, je trouve des éléments de spécification WMS/WMS-c. Elles sont partielles et au stade de proposition. Je cherche le document de référence valable pour l'IGN. Par contre je me rend compte que WMS est systématiquement construit sur HTTP, correct?

De manière générale, les standards OGC/OSGeo sont construits sur le protocole HTTP. Les standards supportent aussi en général le GET/POST de type formulaire web, mais aussi (exemple OpenLS) le POST XML.
Il y a aussi des frémissements pour supporter une protocole applicatif supplémentaire : SOAP (au dessus d'HTTP/POST en général) ...

[Max_B]

Cette page contient normalement tous les élements techniques. Que manquerait-il ?

Cette page décrit exactement ce que je cherche à faire, c'est sa lecture qui a motivé ma question, mais elle ne répond que partiellement. Il y est précisé comment obtenir un jeton. Ensuite, en possession de ce jeton, comment structurer mes requêtes? C'est là ma question : quel est le document qui me permet de construire mes requête et interpréter les réponses?

An plan légal, on serait hors des clous, car il n'y a plus ici de "referer". Il est toujours possible d'en passer un correspondant à la clé API, au moins en phase de maquette avant la sortie des conditions d'accès pour ce type d'application.

[Mr.P.]

Après obtention d'un jeton, il suffit de le rajouter à toute requête valide au format WMS-C. (ie. un paramètre url du type "gppkey=le_jeton").

Techniquement toutes les clés API actuelles imposent un referer. Il sera prévu à terme d'ouvrir des contrats sans referer, mais leur tarification sera certainement différente. Les CGU actuelles indiquent : "... API Géoportail permettant d’afficher des données du Géoportail sur votre propre site Internet, Intranet ou Extranet"

[Max_B]

Ce que je ne comprend toujours pas, au plan commercial, c'est pourquoi il faudrait un tarif distinct pour l'accès en WMS-c, puisque l'API fait justement du WMS-c. Le protocole sous-jacent effectif étant le même, le distinguo est donc commercial.

À cet effet il y a déjà deux tarifs, l'un pour les sites "publics" l'autre pour les site dédiés (=intranet/extranet). Dans ce dernier contexte, il n'y a aucune différence de charge ou de fonction entre une solution qui utilise un serveur dédié (proxy) et une application qui communique directement avec les serveurs IGN.

Enfin, dgrichard, a expliqué que le mode de décompte était tout juste redéfini, peut on trouver cette info? Elle est utile pour évaluer la faisabilité de mon projet.

[dgrichard]

Ce que je ne comprend toujours pas, au plan commercial, c'est pourquoi il faudrait un tarif distinct pour l'accès en WMS-c, puisque l'API fait justement du WMS-c. Le protocole sous-jacent effectif étant le même, le distinguo est donc commercial.

Je leur demande donc répondre sur le forum ...

[achaumet]

(Cf. CGU ... que je ne retrouve plus sur le site API, argh).

Sur cette page http://api.ign.fr/geoportail/registration.do:

et "Lire les conditions générales d'utilisation".

[taumeunier]

Ce que je ne comprend toujours pas, au plan commercial, c'est pourquoi il faudrait un tarif distinct pour l'accès en WMS-c, puisque l'API fait justement du WMS-c. Le protocole sous-jacent effectif étant le même, le distinguo est donc commercial.

Oui, il s'agit de distinctions commerciales, dues au modèle économique de l'IGN. L'IGN commercialise des licences sur des bases de données géographiques, dont le prix dépend :
- de la base de données achetée,
- de l'utilisation qui est faite de ces données

Ce principe de licences existe que les données soient livrées sur support physique ou accédées en webservices.

[Max_B]

Donc au plan commercial, je dois attendre que ça mûrisse côté IGN…

Question technique (par avance veuillez excuser cette question qui a sûrement sa réponse dans la doc, mais je suis en phase d'évaluation et la réponse tient en 2 mots pour qui connaît les protocoles en question) :

La formation d'une requête pour obtenir un fond de carte seul, sans les objets UI et décoration présents par défaut sur les exemples API, est elle possible :
- avec l'API js ? (je redoute la réponse négative)
- en WMS-c "cru" ? (j'espère !)

Merci

[Mr.P.]

- avec l'API js ? (je redoute la réponse négative)

Je ne comprends pas très bien la question : vous demandez s'il est possible d'utilise le code javascript de l'API alors que votre but est de ne pas l'utiliser ?

Pour information,
comme Openlayers, le code de l'API Geoportail est diffusé sous license BSD permettant une réutilisation de tout ou partie des source (y compris pour des utilisations commerciales ou non libres).

Les partie chargées de forger les requêtes WMS-C sont les classes Openlayers.Layer.WMS, Openlayers.Layer.Grid et Openlayers.Layer.HTTPRequest d'Openlayers.
Geoportal.GeoRMHandler se charge de la gestion du jeton et Layer.Grid a été légèrement modifié par rapport à sa version Openlayers.

- en WMS-c "cru" ? (j'espère !)

Oui. Il faut de plus gérer le mécanisme de jeton.

[dgrichard]

Les partie chargées de forger les requêtes WMS-C sont les classes Openlayers.Layer.WMS, Openlayers.Layer.Grid et Openlayers.Layer.HTTPRequest d'Openlayers.
Geoportal.GeoRMHandler se charge de la gestion du jeton et Layer.Grid a été légèrement modifié par rapport à sa version Openlayers.

En complèment des informations données par Mr.P, je rappelle que c'est exactement le rôle de l'API minimale : fournir les éléments en Javascript pour obtenir et fournir le jeton lors des requêtes effectuées par les sous-classes d'OpenLayers.Layer.HTTPRequest. Cette API minimale fournit aussi PROJ4JS pour la gestion des systèmes de référence de coordonnées avec le dictionnaire de l'IGN, mais pas du tout la bibliothèque OpenLayers.

[Max_B]

Je ne comprends pas très bien la question : vous demandez s'il est possible d'utilise le code javascript de l'API alors que votre but est de ne pas l'utiliser ?

En effet je n'ai pas été assez clair dans ce fil, par confusion avec un échange de mèl par ailleurs. Il m'est possible d'utiliser javascript, ce sera même sans doute une solution plus rapide de prototypage. À terme, ce n'est pas une solution optimale dans le contexte projeté. C'est pourquoi ma question concerne les deux solutions.

Edit: OK, j'ai mis les mains dans le camboui et validé mes réponses.
Merci