Réunion Géoportail du 13 février 2008 à l`IGN

Réunion Géoportail du 13 février 2008 à l`IGN

Plate-forme de recherche et d’expérimentation
pour le développement de l’information multimodale
URBA 2000
39, rue du Ranelagh
F - 75016 Paris
Tél: +33 (0)1 44 14 30 00
Fax: +33 (0)1 44 14 30 01
www.predim.org
Réunion Géoportail du 13 février 2008 à l’IGN
Participants
Matthieu AUBINEAU – Communauté d’Agglomération de la Rochelle
Christophe BEAUCOURT – STIF
Jacques BIZE - CERTU
Alain CHAUMET – IGN
Philippe DELCOURT – URBA 2000/PREDIM
Patrick GENDRE – CETE Méditerranée
Jean-Louis GRAINDORGE – URBA 2000/PREDIM
Jean-François JANIN – DGMT/MTI
Roger LAMBERT – DGMT/MTI
Patrick LEBOEUF – IGN
Personnes excusées
Olivier CLARIMON – SMTC Toulouse
Frédéric SCHETTINI - MobiGIS
Compte rendu précédent
Remarques sur le compte rendu précédent : aucune remarque
M. JANIN propose de réaliser un guide pédagogique à partir des compte rendus et des
documents qui ont été fournis depuis quelques mois, en apportant des explications sur les
termes spécifiques liés à l’information géographique.
Type de démonstrateur
Un prototype est plus élaboré qu’une maquette. Cette dernière consiste à montrer un service
fonctionnant en autonome mais un prototype permet de représenter le futur service en ligne,
avec des choix qui préfigurent à son fonctionnement en mode opérationnel. Le prototype
envisagé ne serait pas ouvert au public mais son accès serait filtré par un mot de passe.
Le but de ce prototype n’est pas d’entrer en concurrence avec un service existant destiné à
satisfaire un public déterminé mais à aider à résoudre les problèmes d’interopérabilité des
systèmes et d’homogénéité des données en vue de constituer un service minimum. Il faut
également prendre en compte que les moyens et les développements seront différents d’un site
à l’autre.
Présentation de l’API Géoportail par Pascal PONS (IGN)
L’API Javascript est en cours de développement et elle est en version Béta.
L’exemple 1 montre une mini carte intégrée dans un site Web dont on peut régler la taille. En
transparence il y a la carte IGN qu’il est possible de déplacer à la souris.
Techniquement la page web fait appel à des fonctions Javascript. Il n’y a peu de lignes de code
à intégrer et le développeur a la possibilité de personnaliser le code Javascript. La
documentation fournira des explications sur chaque fonction Javascript.
Sur l’exemple, la mini carte est affichable à n’importe quelle échelle. Il est possible de zoomer
(ou de dézoomer) grâce à la molette de la souris. Les données visibles ne sont pas vectorielles
mais sont représentées en mode raster. (la carte est une image).
Le Géoportail procède par agrégation de cartes : suivant le zoom on a la carte régionale,
départementale, au 100 000ième, au 25 000ième , et le géoportail reconstitue la couche
bâtiment, route, Bdcarto, Bdtopo, Bdparcellaire suivant l’échelle à laquelle on se trouve. Il faut
hiérarchiser les informations et réaliser une pyramide d’échelles comportant pour chacune les
informations à afficher.
L’exemple 2 est un peu plus évolué et possède un gestionnaire de couches. Il y a 3 couches :
- La carte
- La photo aérienne
- une couche WMS extérieure au serveur Géoportail en mode raster : les cours d’eau (on
pourrait également, sur le même principe, afficher une couche des arrêts de bus à l’aide
d’un serveur WMS).
Le gestionnaire de couche peut gérer la transparence d’une couche par rapport à une autre. Le
problème de l’affichage des données issues d’un serveur WMS est lié au système de projection.
La version actuelle de l’’API ne prend pas encore en compte le WFS en raison de problèmes de
configuration système : à terme il sera toutefois possible d’afficher, dans une couche, des
données vecteur.
L’exemple 3 montre l’intégration d’un fichier KML1. (résultats des élections législatives de 2007
par circonscription). Ce fichier contient des données et des instructions de mise en forme de ces
données et a été récupéré sur le site du Ministère de l’Intérieur. Le Géoportail a dû s’adapter
au format KML qui n’est cependant pas un standard bien que beaucoup d’administrations et
collectivités utilisent ce format. L’API repose sur l’application libre « open layer »2 (qui permet
d’étendre les fonctions de base de l’API et la lecture de fichier KML).
Les arrêts de bus peuvent très bien figurer dans un fichier KML. Ce type de fichier a d’ailleurs
déjà été produit à partir de l’application CHOUETTE. En cliquant sur un pictogramme, dans la
carte, on pourrait obtenir des informations liées à chaque arrêt comme les noms de commune,
lignes ou les horaires.
1
Format de fichier permettant d'afficher des données géographiques dans un navigateur terrestre
comme Google Earth ou Google Maps. Ce format utilise une structure basée sur des balises avec des
éléments et des attributs imbriqués et reposant sur la norme XML
2
Il s'agit d'un client cartographique open source facilement intégrable dans un site internet. Il peut se
connecter à différents types de serveurs (WMS,WFS). Il bénéficie d'une interface propre et d'un bon
nombres de fonctions
2
Un particulier peut exploiter ses propres fichiers KML ou autre à partir de l’API Géoportail : un
développeur peut créer sa page web et aller chercher un fichier KML localisé sur le même
serveur que sa page web ou sur un serveur distant. Des problèmes de ‘crossdomain’ sont
toutefois liés aux requêtes envoyées sur des serveurs distants. Le navigateur bloque cet accès
en considérant qu’il y des problèmes de sécurité. Pour contourner ce blocage, un proxy3 sera
mis en place sur le Géoportail dès le lundi 11 février 2008 dans le cadre d’une nouvelle version
de l’API.
Sur l’exemple choisi il est possible de rajouter facilement une couche de données comme les
limites administratives (fonction addlayer dans Javascript).
L’exemple 4 montre les zones d’avalanche dans les Alpes. Ces zones sont affichées dans le
Géoportail sans aucune reprojection. A gauche, sur l’écran il y a le gestionnaire de couches et à
droite, les outils de zoom. Ces outils peuvent aussi se rétracter. Leur ergonomie va encore
évoluer dans les prochaines semaines.
L’API sera documentée à la fois pour les webmasters et pour les développeurs. Cette
documentation a vocation à s’enrichir dans le temps. Il y a aura une documentation détaillée de
toutes les fonctions javascript (gestion des outils de contrôle, ajout de couches, surcouche
‘getmap’ sur l’API OpenLayer pour apporter encore plus de fonctionnalités – pour cela il faut
aller rechercher la documentation complémentaire sur le site OpenLayer qui n’existe qu’en
anglais).
L’utilisateur de l’API doit s’enregistrer préalablement pour recevoir une clé qui devra être
intégrée dans la page web construite par ce même utilisateur. Ce dernier doit respecter les
termes du contrat qu’il a souscrit en ligne, notamment la fréquence d’utilisation de l’API. Pour
un usage commercial (plus de données, plus de capacité, plus de connexions), le contrat sera
payant. Google procède de la même manière. La clé permet à l’IGN de contrôler le flux de
données d’un utilisateur sur un site donné.
Techniquement il est possible de représenter des objets mobiles mais il faut utiliser OpenLayer.
Les fonctionnalités de base de l’API ne fournissent pas directement cette possibilité.
A terme des partenariats pourraient se nouer entre les opérateurs de téléphonie mobile et le
Géoportail. Mais pour le moment l’IGN n’a prévu ses développements que pour 3 clients : le
www.geoportail.fr, l’API Javascript et l’API ‘riche’ JAVA.
Utilisation des données de la Rochelle et Toulouse pour alimenter le
prototype
Pour Toulouse, un projet de lettre en cours de signature précise que le SMTC est prêt à être
partenaire de l’expérimentation Géoportail et à fournir ses données selon un planning
dépendant du développement et de la mise en place de la Centrale d’Information.
Sur Toulouse il y aura plusieurs développements successifs et une dynamique pour
l’expérimentation.
3
serveur recevant des requêtes et qui les transmet aux autres serveurs. Cela permet à quelqu'un qui se
trouve derrière un firewall d'avoir accès à des ressources sans prendre de risques.
3
Les arrêts actuellement ne sont pas fiabilisés du point de vue géographique mais doivent être
recalés par rapport à leur référentiel Navtech (et à terme sur le Géoportail conformément au
RGE).
Dés l’été, les lignes (donc le cheminement entre arrêts) seront disponibles et en septembre il y
aura de l’information sur l’état du service et les événements liés au réseau.
M. Maxime BONNOT, Président de la Communauté d’agglomération, a adressé une lettre à
Jean-François JANIN pour lui indiquer son accord pour participer au développement du
démonstrateur et son intérêt pour le projet. La Communauté d’Agglomération de La Rochelle a
fourni des données au CETE Méditerranée. Le fichier ne comporte que des arrêts (nom des
arrêts, leurs coordonnées en latitude et longitude) mais Matthieu AUBINEAU confirme que ce
fichier sera enrichi au moins par les numéros et noms de lignes et les noms de commune.
Il serait également intéressant de disposer du sens de parcours. Les cas particuliers (boucles,
fourches) sont également à prendre en compte. Ces informations complémentaires peuvent
être extraites du logiciel de graphicage HEURES qui équipe la RTCR (Réseau de Transport de la
Communauté Rochelaise).
Il faut étudier un format de sortie des données à partir d’HEURES sans y intégrer de suite les
horaires pour des raisons de simplification. Il sera ainsi possible, et assez rapidement, de
représenter graphiquement les arrêts et de leur associer des informations complémentaires
(nom d’arrêt, numéro de ligne, nom de commune, à terme un lien pour pointer vers la photo de
l’arrêt ou sa fiche horaire).
Pour la démonstration Géoportail, le STIF n’a pas achevé sa réflexion aujourd'hui. Au niveau
technique, les données STIF sont dans un format spécifique mais une passerelle
vers CHOUETTE existe via le format XML Trident. Un export KML à partir du format CHOUETTE
serait alors possible.
Communication
Plusieurs manifestations sont prévues :
-
Le salon ‘Space Show’ (semaine internationale des applications spatiales) du 22 au 25
avril auquel assistera la MTI.
-
Le Géo-événement sur la cartographie numérique, de l'information géographique et de la
géomatique les 8,9 et 10 avril 2008. L’IGN et les partenaires de POTIMART y assistent.
-
Le salon de l’internet le 4 et 6 avril auquel l’IGN participera
Il est possible de montrer une présentation PowerPoint, une animation à partir d’un PC sur un
stand ou montrer le prototype, de discuter des problèmes d’organisation avec le public intéressé
par le sujet. (Qui détient les données de bus sur les arrêts de bus en France ? , comment les
mettre sur le Géoportail ? …)
Avec toutes les informations qui ont été capitalisées au cours des réunions, un document à
vocation pédagogique doit être réalisé.
4
Principes d’organisation de la démonstration
Dans le Géoportail il y a :
-
un site de qualification où on teste de nouvelles fonctionnalités
-
un site de préproduction (une fois les fonctionnalités testées) qui permet de valider la
demande du partenaire
-
le site de production
On peut se servir dans un premier temps du site de préproduction. Ce site n’est pas performant
sur le plan de la vitesse. Mais pour une démonstration à court terme, cette solution est à
retenir. Il sera accessible avec un nom d’utilisateur et un mot de passe.
Les données des AO seront fournies au CETE Méditerranée qui met en place un serveur WMS
dans le cadre du projet POTIMART (ou utilisera le serveur WMS Cartélie), lui même relu par le
Géoportail. Il est toutefois possible d’héberger directement des données sur le Géoportail même
si cette solution sera plus longue à mettre en œuvre que le recueil de données à partir d’un
serveur WMS.
Le serveur de Préproduction Géoportail respecte les critères normatifs de l’OGC et les
problèmes avec la liaison des serveurs WMS extérieurs proviennent généralement de la
compatibilité entre les couches Géoportail et du serveur distant (problèmes de projection et de
légende).
En résumé, on peut tester les 2 solutions en parallèle :
-
Intégrer directement les données dans le Géoportail
Tester le branchement sur un serveur WMS
Ces 2 possibilités seront testées sur le serveur Géoportail de préproduction. Pour la seconde
solution, il faut être conscient que le serveur WMS peut rapidement être ralenti par le nombre
de connexions simultanées. D’un point de vue pédagogique, il est intéressant, au départ,
d’effectuer des tests de performance en fonction du nombre de connexions. A terme il faudra
dimensionner correctement les ressources de ce serveur.
Géocatalogage de la couche transport
- Le processus de géocatalogage est lié au processus de visualisation des données dans le
Géoportail. A terme une couche transport public sera cataloguée et via le géocatalogue, cette
couche pourra être visualisée. Le géocatalogue sera capable de référencer les adresses de
serveurs WMS et pourra jouer le rôle d’aiguillage. Aujourd’hui il n’y a pratiquement que des
données IGN qui sont référencées dans le géocatalogue.
- il est utopique de croire que l’on pourra afficher facilement des données provenant de
différents serveurs : il y a en effet des problèmes de sémiologie. Les couches doivent être
préparées en terme de légende et de performance.
5
Le gestionnaire de couches est actuellement retravaillé par l’IGN. Au départ l’IGN s’est calé sur
la nomenclature Inspire qui est à dominante environnementale. Le Géoportail offrira différentes
possibilités : la nomenclature Inspire sera proposée par défaut mais il y aura la possibilité de
réordonner les couches dans les différentes thématiques : transport, environnement, tourisme,
loisirs et culture … Il y aura aussi des profils (à l’intérieur de la couche transport, il sera possible
de créer le profil transport public)
Pour le moment il vaut mieux classer les données transport dans la thématique Inspire qui
décrit assez bien la thématique réseaux de transport. Dedans il y a les réseaux routier,
ferroviaire, aérien et navigable, ainsi que les infrastructures associées. Sont également inclus
les correspondances entre les différents réseaux, ainsi que le réseau de transport
transeuropéen. (voir http://www.cnig.gouv.fr/upload/ressource/r1195489280.PDF) Il sera
possible d’ajouter à cette liste « transport public ».
Comment constituer la couche transport (une couche pour le réseau, une couche par ligne … ?)
Il faut créer une typologie correspondant à des choix à cocher (exemple typologie en fonction
des modes de transport).
Manière d’utiliser le démonstrateur
Voici la manière de rechercher et d’afficher les informations :
- Retrouver l’information dans le gestionnaire de couche : voir la nomenclature Inspire. Pour
savoir où trouver les informations il est possible de se servir de PASSIM (un fichier KML
PASSIM a déjà été créé).
- Sélectionner et l’afficher sur fond Géoportail
- Afficher les informations : cliquer sur un objet du réseau (un arrêt par exemple) et visualiser
la fiche de renseignement qui lui est associée
- Accéder à d’autres services c’est à dire qu’à l’intérieur de la fiche (tag) associée à un arrêt, il
peut y avoir des liens qui pointent vers des fiches horaires par exemple. Lancer une requête
à partir d’une URL pour aller rechercher les horaires associés à un arrêt demande toutefois
un travail de développement assez conséquent. Ne peut-on pas utiliser le serveur CHOUETTE
pour répondre aux requêtes des horaires lancées à partir d’une URL située dans un tag ? S’il
existe une photo du point d’arrêt il suffit d’ajouter un lien dans le tag. A terme il vaudra
mieux la mettre en cache au niveau du Géoportail (information qui ne change pas souvent)
pour des raisons de performance. Volumétrie des photos : Sur la Rochelle il y a 500 arrêts
physiques sur la 1ère couronne. Sur Toulouse il y a 2000 à 3000 arrêts.
Comme il n’est pas possible dans l’immédiat de tout représenter, il vaut mieux se focaliser sur
les bus.
Pour établir un répertoire national des point d’arrêt, il faut définir l’identifiant d’un arrêt. En
billettique il y a déjà eu un travail d’identification des arrêts.
6
Conclusions
- Pour la démonstration, la réalisation d’un serveur WMS dans le cadre du projet POTIMART
ou l’utilisation du serveur WMS Cartélie est à envisager. En parallèle les données de
Toulouse et La Rochelle seront envoyées à l’IGN.
- A court terme le catalogage n’apparaît pas prioritaire mais il faut réfléchir à la définition des
couches du transport public.
- Il faut définir une couche avec des points d’arrêt et définir des attributs qui ne seront pas
forcément identiques entre les réseaux de Toulouse et de La Rochelle. Il faut aussi étudier
les problèmes de précision de visualisation entre 2 arrêts physiques proches, suivant
l’échelle. Apparemment le Géoportail pourra faire la distinction entre 2 arrêts proches
(affichage jusqu’au 800ème).
- SIRI peut définir l’interface pour accéder à un horaire de bus (exemple prochain horaire de
passage). Le STIF travaille sur SIRI. L’organisation des échanges de données ne sont pas
encore définis mais le profil d’échange a été déterminé. Le document sera publié pour les
autres AO au niveau national. Cette diffusion pourra être relayée par le site du CERTU ou de
la PREDIM.
- Sur Toulouse la nature des données est bien identifiée. Sur La Rochelle, Frédéric
SCHETTINI prendra contact avec Matthieu AUBINEAU pour faire le point sur les données à
récupérer.
- Le 25/26 février il y a une réunion de projet POTIMART à Chambéry. Après cette date les
partenaires POTIMART seront en mesure d’annoncer ce qu’ils sont capables de proposer,
dans quel budget et dans quel délai.
La prochaine réunion aura lieu dans les locaux de l’IGN à Saint-Mandé
le jeudi 20 mars 2008 à 10H30
7