Commissariat Général au Développement DurableDirection de la Recherche et de l'Innovation Mission de l'Information Géographique

CAHIER DES CLAUSES TECHNIQUES PARTICULIERES(C.C.T.P.)

Réalisation de la version 3.4de l'application informatique PRODIGE

CGDDDRIMIGProdige34

Table des matières

1 Présentation du projet, objet du marché.......................................................................................4

Cahier des charges Prodige V3.4 (CCTP) 1/19

MINISTÈRE DE L’ÉCOLOGIE, DU DÉVELOPPEMENT DURABLE ET DE L'ÉNERGIE

1.1 Documents mis à disposition pour étudier et valoriser la prestation demandée....................5 1.2 Description des termes utilisés dans le projet.......................................................................5 1.3 Description des contraintes non fonctionnelles.....................................................................6

1.3.1 Adaptabilité, maintenabilité, réutilisabilité, robustesse du code.....................................6 1.3.2 Contrainte de non-régression........................................................................................7 1.3.3 Composants système et logiciels..................................................................................7 1.3.4 Sécurité / hébergeabilité................................................................................................7 1.3.5 Modularité.....................................................................................................................7

1.4 Installation et migration.........................................................................................................8 1.4.1 Installation..........................................................................................................................8 1.4.2 Documentation...................................................................................................................8 1.5 Dossiers de spécifications.....................................................................................................9

2 Prestation P0 : Evolution de GéoSource et des métadonnées...................................................10 2.1 Nouvelle version de GéoSource.........................................................................................10 2.2 Script de migration des IRU existants.................................................................................10

3 Prestation P1 : Gestion des métadonnées..................................................................................11 3.1 Corrections de structures ISO dans des fiches de métadonnées de données....................11 3.2 Gestion des métadonnées de cartes...................................................................................14 3.3 Gestion de la date de révision des métadonnées...............................................................15

4 Prestation P2 : Mise en œuvre du téléchargement avec le protocole ATOM..............................16 5 Prestation P3 : Flux WMS, contextes.........................................................................................20

5.1 Production de flux WMS 1.3................................................................................................20 5.2 Mise en conformité des contextes générés avec les schémas définis par l'OGC................20

6 Prestation P4 : Evolutions fonctionnelles....................................................................................21 6.1 Gestion des cartes, cartes personnelles et contextes.........................................................21 6.2 Fonctions complémentaires sur les cartes personnelles.....................................................21 6.3 Ajout automatique des serveurs WxS connus du catalogue Prodige..................................21 6.4 Accès aux informations attributaires....................................................................................21 6.5 Cartes en accès restreint :..................................................................................................22 6.6 Requêteur de localisation :..................................................................................................23 6.7 Lien avec annuaire LDAP :.................................................................................................23 6.8 Augmenter la taille de la fenêtre d’extraction cartographique:.............................................23

7 Prestation P5 : Changement de librairie Gdal.............................................................................24

Cahier des charges Prodige V3.4 (CCTP) 2/19

1 Présentation du projet, objet du marché

Cahier des charges Prodige V3.4 (CCTP) 3/19

PRODIGE est un logiciel libre permettant la mise en œuvre de plateformes de stockage, de catalogage, de visualisation, d'échanges et de traitements de données géolocalisées. C'est un outil d'échange d'informations géographiques sous la forme d'une application combinant des fonctions d'entrepôt de stockage des données, de catalogage de métadonnées et de cartographie. Il est exploité par des services de l'État et des collectivités territoriales.

Les évolutions de Prodige sont pilotées par le groupe technique « Plate-forme Prodige Etat et collectivités territoriales », qui associe l’Etat (notamment le ministère du développement durable) et les collectivités territoriales intéressées (notamment des conseils régionaux).

Prodige est adossé au projet du ministère du développement durable et du ministère de l’agriculture de convergence de leurs outils dans le domaine de l’information géographique. Ce projet a été baptisé Géo-IDE (pour Infrastructure de données électroniques). Il prend en compte les outils de stockage, de catalogage et de cartographie.

La version 3.3 de Prodige a permis une intégration sous forme modulaire de la nouvelle version V2.9.2 de Géosource, des modifications mineures sur toute l’IHM et une mise en conformité de l'interopérabilité du moissonnage de Prodige.

L'objet de la prestation faisant l'objet du présent marché est le développement de la version 3.4 de l'application informatique PRODIGE.

L'objectif principal de cette version consiste à continuer à intégrer les dernières versions des normes et standards, en particulier le téléchargement ATOM et la norme WMS1.3, et de procéder à l’intégration de la nouvelle version V2.11 de Géosource.

1.1 Documents mis à disposition pour étudier et valoriser la prestation demandée

Toute la documentation relative à PRODIGE est disponible sur l'ADDULACT :https://adullact.net/projects/prodige/

Exemple d'utilisation de PRODIGE : http://catalogue.sigloire.fr

Le logiciel Géosource, dont la dernière version est la V2.11, et la documentation sur Géosource sont disponibles sous http://www.geosource.fr.

1.2 Description des termes utilisés dans le projet

Les différents administrateurs :

Administrateur de site PRODIGE : rôle d'administrateur de l'application, soit paramétrage de l'application pour son site (couleurs, temps d'inactivité...), création des utilisateurs, gestion des droits, modification du moteur de recherche, consultation des logs de connexion, consultation de la base de données... Il y a en général une personne par site (donc le plus souvent par région) pour ce rôle.

Administrateur local : rôle de création et mise à jour des métadonnées, d'importation et publication des données et des cartes. Il peut y avoir une personne par service producteur.

Administrateur système : rôle de maintenance du système informatique. Il intervient sur la machine au niveau du système d'exploitation et des composants comme Apache ou Tomcat en cas de problème. Il procède à l'installation et aux mises à jour de Prodige. Il peut être

amené à paramétrer les routines de nettoyage de fichiers par exemple.

Utilisateur : personne qui accède aux fonctionnalités de Prodige. Il peut être authentifié par un identifiant et un mot de passe. Dans ce cas, l'administrateur général l'a intégré dans un profil qui lui donne des droits particuliers sur les fonctionnalités (navigation cartographique, téléchargement, etc.).

Site ou plate-forme : Implantation de l'application configurée en fonction des besoins des utilisateurs des services adhérents. Cette configuration est faite par l'administrateur du site Prodige pour les fonctionnalités et par l'administrateur système pour les réglages informatiques. Il y a une adresse URL par site. Actuellement, on a le plus souvent un site par région.

1.3 Description des contraintes non fonctionnelles

Les contraintes figurant dans ce chapitre s'appliquent à l'ensemble des prestations. Le prestataire indiquera dans sa réponse comment il prend en compte ces demandes.

PRODIGE est libre de droits sous licence CECILL V2.0 et doit le rester.

Les développements doivent être réalisés conformément aux normes et recommandations du W3C, de l’ISO, de l’Open Geospatial Consortium (OGC) et de la DISIC (Direction interministérielle des systèmes d’information et de communication) en matière d’interopérabilité, de métadonnées, de services en ligne et d’utilisation des logiciels libres.

Le prestataire respectera les prescriptions des règlements européens relatifs à la directive Inspire et de leurs guides techniques, accessibles sous http://inspire.ec.europa.eu/

Les seuls langages autorisés sont HTML, PHP, CSS, JAVA et JAVASCRIPT.

PRODIGE doit pouvoir être utilisé par tout type de navigateur (principalement : Internet Explorer 9 et supérieure, Mozilla Firefox 24.5 et supérieure, et Chrome 34 et supérieure). Le cas échéant, le soumissionnaire indiquera dans sa réponse la nécessité d'une dérogation à cette contrainte et les raisons.

1.3.1 Adaptabilité, maintenabilité, réutilisabilité, robustesse du codeD’une manière générale, le développement de l’application doit s’intégrer dans un souci de sécurité, de modularité, d’interopérabilité, de pérennité, d'accessibilité et d’évolutivité.

Le code produit devra être commenté de manière à pouvoir être facilement maintenu et en indiquant en particulier :

La signification des constantes dans le fichier de paramétrage où elles sont définies.

La signification des variables lors de leur initialisation.

La signification des différentes fonctions.

1.3.2 Contrainte de non-régressionL'ensemble des fonctionnalités de la version 3.3 doit être maintenu. Le développement de la version 3.4 ne doit pas entraîner de régression.

1.3.3 Composants système et logiciels

La version 3.3 s'appuie sur les composants suivants : Debian Squeeze 6.0.3, Java 6.26/Tomcat 6.0, Serveur Apache version 2.2.16 (mod_rewrite, mod_proxy, mod_php5), Geos 3.2.0, proj4 4.7.0, Gdal 1,8,1 (avec libecw 3.3), Php 5.3.3, php_ogr 1.1.1, Postgresql (version 8.4.8) et sa cartouche spatiale Postgis (version 1.5.1), Mapserver 5.6.7(avec librairie AGG2.5.5).

La version 3.4 utilisera également Mapserver 6.4 et Gdal 1.11.0.

Les versions des composants pour la version 3.4 devront au minimum être au niveau de ceux utilisés par la version 3.3.

1.3.4 Sécurité / hébergeabilitéProdige est actuellement hébergé par différents hébergeurs. Il est souhaité que PRODIGE puisse à terme être également hébergé sur un centre serveur national du ministère du développement durable, mais l'adaptation nécessaire ne fait pas partie des prestations du présent marché.

La prestation ne doit pas remettre en cause les différents hébergements actuels, et doit continuer de respecter les règles de sécurité mises en œuvre dans la V3.3, et permettre de fonctionner derrière un reverse proxy.

La configuration du reverse proxy, basé sur Apache2, se fera uniquement au moyen des directives proxypass et proxypassreverse et sera fournie au prestataire qui sera retenu s'il le souhaite.

En particulier, les URL doivent se conformer strictement aux RFC relatives au protocole HTTP. Par exemple, les caractères accentués doivent être correctement encodés. Pour des raisons de sécurité, les remontées d'arborescence dans les URL sont interdites. Les URL doivent mentionner des chemins ne comportant pas les caractères ../ et ./

1.3.5 ModularitéL’architecture logicielle de PRODIGE est modulaire et doit le rester. Il existe une distinction logique entre les grands espaces applicatifs :

l’outil de gestion de catalogue et de métadonnées ;

la publication des données et leur stockage ;

le dépôt des données avant leur intégration dans PRODIGE,

les outils de consultation et d’administration des cartes.

Les développements devront au minimum conserver et si possible accentuer la modularité de PRODIGE avec la recherche d'un couplage faible entre composants.

Le prestataire identifiera les fonctions critiques dans l'intégration de la nouvelle version du logiciel de catalogage Géosource (ex: import de données...) et définira la gestion des transactions pour maintenir des liens corrects entre les fiches de métadonnées, les données, les services et les cartes (mapfile).

1.4 Installation et migration

Le prestataire définira et fournira les scripts de migration des données et métadonnées des sites existants pour chaque prestation le nécessitant.

La migration elle-même sera réalisée par les services du ministère et ne fait pas partie des prestations du présent marché.

Dans le cas de prestations réalisées simultanément ou avec un faible décalage dans le temps, le ministère pourra décider d'effectuer une seule migration pour ces prestations. Les scripts de migration devront donc pouvoir être enchaînés : afin de transférer l'ensemble des informations existantes sur les sites au moment des phases de recette et de migration, un script global devra permettre de migrer de la version 3.3.x vers la version 3.4.n, le x étant déterminé 15 jours avant la livraison de la version 3.4.n, en permettant d’activer ou non les différents scripts suivant le choix de chaque site.

Il est également demandé de fournir une procédure permettant de dupliquer une plateforme 3.3.x de manière à produire une plateforme de test ayant des urls d'appel différentes. Le prestataire s'inspirera de la documentation et des scripts similaires réalisés dans le cadre du développement de la version 3.2 et disponibles sur l'adullact:

https://adullact.net/frs/download.php/6411/MIGRATION_PRODIGEV3.2_V1.1.pdf

1.4.1 InstallationActuellement, quand on installe une nouvelle version de Prodige, les noms des cookies et des fichiers javascript de l’ancienne version sont conservés, ce qui crée des perturbations lors de l’utilisation de la nouvelle version. Il est demandé de renommer les cookies à chaque version de Prodige ainsi que de renommer les fichiers javascript. L’objectif est que les fichiers javascript et les cookies de la version précédente ne perturbent pas le fonctionnement de la nouvelle version dès son installation.

Prodige doit pouvoir s'installer de façon simple. Pour cela, le prestataire fournira une installation complètement intégrée et documentée avec un suivi de son déroulement à l'écran et avec des interfaces pour saisir les options de paramétrage (si besoin) ainsi que la documentation la concernant.

1.4.2 Documentation Pour chaque prestation le nécessitant, il est demandé de mettre à jour l'ensemble de la documentation (manuels utilisateur, d'installation et d’exploitation) ainsi que l'aide en ligne de l'application. L'ensemble de la documentation à jour sera fourni aux formats HTML et OpenOffice.

Le manuel d'installation de Prodige devra décrire toutes les procédures, notamment les phases de paramétrages de l'installation. Le script d'installation vérifiera la présence des paquets nécessaires et proposera une mise à jour ou une installation complète.

Dans le cas de prestations réalisées simultanément ou avec un faible décalage dans le temps, donnant lieu à une seule migration, la mise à jour de la documentation et du manuel d'installation consolidera les mises à jour de ces prestations et sera fournie pour cette migration.

1.5 Dossiers de spécificationsLes dossiers de spécifications fonctionnelles détaillées et techniques sont à fournir après le lancement de la prestation. Cette fourniture se fera par mail et par courrier aux adresses suivantes :

gaelle.diouris@cerema.fr

christophe.bocquet@developpement-durable.gouv.fr

Cerema

Département Villes et Territoires

MAN rue René Viviani BP 46223

44262 Nantes Cedex 2

2 Prestation P0 : Evolution de GéoSource et des métadonnées

2.1 Nouvelle version de GéoSource

Il est demandé d’intégrer la version à jour de Géosource (V2.11 en mai 2014).

Une des évolutions de Géosource 2.11 consiste à permettre de générer automatiquement dans les métadonnées de données l’identificateur de ressource unique (IRU) au sens INSPIRE (identificationInfo[1]/*/citation/MD_Identifier/identifier) sous forme d’URL (IRU HTTP) à partir de l’identifiant du fichier de métadonnées (fileIdentifier) et de gérer les liens avec les métadonnées de services à partir de cet identifiant de ressource.

Actuellement la V3.3 de Prodige génère un IRU non HTTP à partir du nom de la table correspondant à la donnée dans la base PostGIS.

Dans le cadre de cette évolution pour Prodige, l’IRU HTTP généré par GéoSource, conforme aux prescriptions d’INSPIRE, sera intégré et utilisé au sein de Prodige, et en particulier pour les liaisons avec toutes les fiches de métadonnée de services. La structuration de la ressource couplée (operatesOn) deviendra de la forme : xlink:href="[Identificateur de ressource unique]".

2.2 Script de migration des IRU existants

Un script sera généré afin de permettre automatiquement pour chaque ressource existante d’une plateforme Prodige soit simplement l’ajout de l’IRU HTTP calculé par GéoSource, en laissant les IRU existants (car une ressource peut avoir plusieurs IRU), soit d’écraser les IRU existantes pour les remplacer par les IRU HTTP (le choix sera effectué par chaque site).

De même, ce script permettra de mettre à jour les liens en propageant les IRU HTTP pour les liens entre métadonnées de service et métadonnées de données et au sein du document de capacité des services de Prodige (réponse à la requête GetCapabilities).

3 Prestation P1 : Gestion des métadonnées

3.1 Corrections de structures ISO dans des fiches de métadonnées de donnéesCertaines fiches de métadonnées de données (MDD) ont gardé trace d’un défaut de structuration hérité d’un import/export d’une ancienne version. Il s’agit d’une structure « gco :isotype » au sein de gmd :MD_DataIdentification, ce qui n’est pas conforme au modèle ISO. Ex : <gmd:MD_DataIdentification gco:isoType="gmd:MD_DataIdentification">

Il est demandé de définir un premier script permettant de corriger automatiquement ces structures sur l’ensemble des fiches de métadonnées, et de les rendre conformes au modèle ISO sur ce point. Ce script pourra être utilisé lors de la migration des données.

Par ailleurs, dans les anciennes versions de Géosource, la référence au thésaurus INSPIRE dans les métadonnées se faisait par référence à un thésaurus dont le titre était “external.theme.themeINSPIRE” au lieu du titre du Thesaurus GEMET. Un deuxième script sera généré et proposé afin de permettre la mise en conformité de ce titre aux obligations INSPIRE.

De même, un troisième script sera généré et proposé afin de permettre une mise à niveau des fiches de métadonnées de données n’ayant pas eu leur système de référence de coordonnées précisé.

Après l’exécution de ce script, les fiches n’ayant pas de structure XML «gmd:referenceSystemInfo» verront ce bloc défini avec les valeurs par défaut choisies pour ce script. Par exemple, création de la structure XML : <gmd:referenceSystemInfo>

<gmd:MD_ReferenceSystem><gmd:referenceSystemIdentifier><gmd:RS_Identifier><gmd:code><gco:CharacterString>RGF93 / Lambert-93 (EPSG:2154)</gco:CharacterString></gmd:code><gmd:codeSpace><gco:CharacterString>EPSG</gco:CharacterString></gmd:codeSpace><gmd:version><gco:CharacterString>7.4</gco:CharacterString></gmd:version></gmd:RS_Identifier></gmd:referenceSystemIdentifier></gmd:MD_ReferenceSystem>

</gmd:referenceSystemInfo>

Un quatrième script sera généré et proposé afin de permettre une mise à niveau des fiches de métadonnées de données relevant de thèmes Inspire et n’ayant pas eu leur conformité précisée dans la partie Qualité.

En ce cas, les exigences de conformité seront remplies au moyen des éléments de métadonnées «spécification» et «degré» en ajoutant la référence au règlement européen relatif à l’interopérabilité dans le cadre d’INSPIRE.

Après l’exécution de ce script les fiches n’ayant pas eu de conformité précisée par rapport à ce

règlement verront ce bloc défini dans la section <gmd:dataQualityInfo> avec les valeurs suivantes qui indiquent que cette conformité n’a pas été évaluée (la valeur « non-évalué » n’est pas stockée dans les métadonnées mais correspond à l’absence de la sous-structure <gmd:pass>) :

<gmd:report><gmd:DQ_DomainConsistency><gmd:result><gmd:DQ_ConformanceResult><gmd:specification><gmd:CI_Citation><gmd:title><gco:CharacterString>COMMISSION REGULATION (EU) No 1089/2010 of 23 November 2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services</gco:CharacterString></gmd:title><gmd:date><gmd:CI_Date><gmd:date><gco:Date>2010-11-23</gco:Date></gmd:date><gmd:dateType><gmd:CI_DateTypeCodecodeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/Codelist/ML_gmxCodelists.xml#CI_DateTypeCode"codeListValue="publication"/></gmd:dateType></gmd:CI_Date></gmd:date></gmd:CI_Citation></gmd:specification><gmd:explanation><gco:CharacterString>-- More information on the test --</gco:CharacterString></gmd:explanation></gmd:DQ_ConformanceResult></gmd:result></gmd:DQ_DomainConsistency>

</gmd:report>

Pour les métadonnées de carte (métadonnées de service de type « invoke »), un cinquième script sera généré et proposé afin de permettre une meilleure conformité au format ISO. En effet, l’élément « containsOperations » est encapsulé dans l’élément « connectPoint », alors que ce devrait être l’inverse.

Ces scripts pourront être utilisés lors de la migration des données. 3.2 Gestion des métadonnées de cartes

Actuellement une carte dans Prodige peut être un simple document (pdf) mis à disposition, ou une carte dynamique réalisée à partir des données hébergées dans la plateforme Prodige, ou distantes mais accessibles via des services web. L’IHM de Prodige permet également à partir de la carte dynamique de générer un fichier de context (ows) sur le serveur ou sur sa machine.

Enfin, une carte dynamique pourra être rendue accessible comme un service WMS (comme

demandé plus loin dans le présent CCTP).

Prodige gère déjà les métadonnées de carte en tant que métadonnées de service de type invoke, ce qui permet de garder une unicité de fiche de métadonnées de carte tout en articulant ces différents modes éventuels de fourniture de la même carte. La fiche de métadonnées de service invoke permet de décrire tous les éléments permettant à l’utilisateur de comprendre le contenu et l’objectif de la carte, et d’appeler à partir du même service invoke toutes les modalités d’accès à la carte (visualiseur de la plateforme, WMS, OWS context, PDF…).

Afin de permettre une meilleure prise en compte des cartes et des liens entre une carte et les différentes données qui la composent, il est demandé d’enrichir les métadonnées de carte en générant en automatique les champs suivants :

Localisateur de la ressource (Resource locator) : cet élément (cf. règlement européen sur les métadonnées http://eur-lex.europa.eu/legal-content/FR/ALL/?uri=CELEX%3A32008R1205, notamment le tableau 2 de la partie C de l’annexe) est obligatoire « si un lien avec le service est disponible » et répétable : on indiquera l’URL de chaque modalité disponible d’accès à la carte, dans l’ordre suivant : URL de la fiche de métadonnées du service WMS de la carte, si ce service existe. URL donnant accès à la carte par le visualiseur d’une plateforme, si cet accès existe

(cas déjà géré par Prodige). URL du fichier XML du contexte (OWS Context)., si ce contexte existe (ou peut être

généré à la volée à partir de la carte dynamique via une URL prédéfinie). URL du fichier PDF de la carte, si ce fichier existe (cas déjà géré par Prodige), ou

peut être généré à la volée à partir de la carte dynamique via une URL prédéfinie. Ressource couplée (Coupled resource) : cet élément est obligatoire « si des liens avec les

séries de données avec lesquelles le service opère sont disponibles » et répétable (cf. même tableau du règlement européen sur les métadonnées). Il s’agit obligatoirement d’un URI. On mentionnera donc les URI des séries de données constituant la carte.

Si la carte fait l’objet d’un service WMS, ce service devra lui-même être décrit par une fiche de métadonnées de service de visualisation (c’est une obligation de la directive Inspire), mais le contenu de celle-ci devra se déduire automatiquement de celui de la fiche invoke.

L’IHM de Prodige permettra de choisir à partir de la fiche de métadonnées de carte une modalité d’accès parmi celles existantes, ou d’accéder aux fiches de métadonnées de données des séries de données constituant la carte.

Un script sera généré pour permettre aux sites qui le souhaiteront l’enrichissement des fiches de métadonnées de carte dynamique avec l’URL du fichier de contexte s’il peut être généré en automatique à partir de la carte.

3.3 Gestion de la date de révision des métadonnées Actuellement, quand on modifie une fiche de métadonnée c'est la date de validité qui est mise à jour dans PRODIGE ; or il faut que ce soit le champ date de révision qui soit mis à jour. Un script de correction permettant pour les fiches existantes la recopie des dates de validité en dates de révision devra également être réalisé dans le script de migration.

4 Prestation P2 : Mise en œuvre du téléchargement avec le protocole ATOM

Prodige dispose déjà d’un flux RSS sur les Nouveautés et les Mises à jour, qui permet de recevoir automatiquement les infos des couches mises à jour et qui renvoie sur les fiches de métadonnées des données. A partir de ces fiches de métadonnées il est possible de procéder aux actions autorisées, dont le téléchargement.

Le guide technique INSPIRE : http://inspire.ec.europa.eu/documents/Network_Services/Technical_Guidance_Download_Services_v3.1.pdf préconise l’utilisation d’un service de téléchargement direct (Direct Access Download Service) et d’un service de téléchargement à partir de données préconstruites (Pre-defined Dataset Download Service).

Dans cette prestation, il s’agit de la mise en œuvre d’un service de téléchargement à partir de données préconstruites via la mise en œuvre de flux ATOM comme précisé dans le guide technique.

Il ne s’agit pas ici de permettre à une plateforme Prodige d’utiliser automatiquement les flux ATOM d’une autre plateforme. Cet usage de flux ATOM externes se fera ultérieurement par l’évolution de l’automate de mise à jour de Prodige, qui en mode « récupération » offre également un outil d'abonnement aux données.

Prodige permet actuellement plusieurs modes de téléchargement des données déposées dans la plateforme.

Le téléchargement direct est fourni par le biais du service WFS (1.1). Une page de téléchargement, accessible à partir du panier, ou directement à partir de la

fiche de métadonnées de donnée (MDD), permet de gérer les droits d’accès et d’accéder aux données en spécifiant le format, le système de coordonnées, éventuellement la zone d’extraction des données, et de gérer une exécution immédiate ou différée.

Quant au téléchargement à partir de données préconstruites, il peut être assuré dans le cadre d’Inspire par le WFS ou un fichier de syndication ATOM.

Pour PRODIGE 3.4, il est demandé de mettre en place des téléchargements ATOM uniquement pour les données en téléchargement libre qui, pour des raisons de volumétrie et de sollicitation des services, ne nécessitent pas de téléchargement différé (nécessaire pour les RASTER, MNT...).

Processus demandé :

Il existera 2 types de fichier ATOM en XML pour Prodige:

1 fichier ATOM conteneur (feed) de la plate-forme dont les balises « entry » renvoient vers les fichiers ATOM (feed) de chaque donnée :

Titre Résumé URL du service ATOM Organisation responsable : organisation, mail Limites d’utilisations Conditions d’accès

Date de dernière modification du service Données téléchargeables : titre, identifiant, url de métadonnée (d’où l’intérêt des

nouveaux IRU de Géosource sous forme d’URL), lien vers fichier ATOM de donnée (décrit ci-après)

Le format Atom dispose d'une balise updated pour la date de dernière modification et published pour la date de première parution. Seule la première semble vraiment utile dans ce flux.

1 fichier ATOM (feed) par donnée de type « série de données », dont les balises « entry » renvoient vers les liens de téléchargement correspondant à chaque type de format et de systèmes de projections de sortie sélectionnés, et éventuellement pour chaque territoire d’extraction. Il contient les informations suivantes :

champs identiques au précédent le SRS de téléchargement, le format et éventuellement le territoire d’extraction. URL de téléchargement (URL du fichier GML ou du fichier ZIP contenant les fichiers

au format shapefile par exemple, dans un des SRS)

Figure : illustration de structures de fichier ATOM

Le fichier ATOM global sera accessible à partir de l’IHM de la plateforme Prodige.

On créera une fiche de MDS (métadonnées de service) de téléchargement globale correspondant à l’ensemble des données téléchargeables sous forme ATOM à partir de la plateforme. Cette fiche de MDS aura un champ « localisateur de ressource » pointant sur le fichier ATOM de téléchargement global de la plateforme et sera associée à toutes les fiches de métadonnées de donnée (MDD) des données servies par le flux ATOM.

En outre, chaque fiche de métadonnées de donnée (MDD) offrira les différents modes de téléchargement via la répétition des champs « localisateur de ressource » :

Un champ localisateur de la ressource de la MDS de téléchargement pointera sur l'accès à la page de téléchargement de PRODIGE pour la ressource considérée (usage actuel) :

Ex. : distributionInfo/*/transferOptions/*/onLine/*/linkage : http://catalogue.sigloire.fr/PRRA/panierDownloadFrontal_parametrage.php?LAYERIDTS=106251

Un champ localisateur de la ressource de la MDS de téléchargement pointera sur le fichier ATOM (feed) de donnée correspondant, quand la donnée est également servie de cette façon.

Il n’y a pas lieu a priori de référencer via le champ « localisateur de ressource » le service WFS qui diffuse la donnée, car la fiche de MDS du service WFS de Prodige référence déjà les données servies.

Dans le cas d’une donnée de type « ensembles de séries de données » constituée de données diffusées par flux ATOM, les balises « entry » de son fichier ATOM (feed) renvoient vers les fichiers ATOM des données qui les composent.

Certaines projections INSPIRE sont rendues obligatoires.Les listes de formats, de projection et de territoire seront centralisées et définies par l’administrateur de site pour l’ensemble des données téléchargeables selon le protocole ATOM.

Le fichier ATOM de série de donnée sera créé au moment de la publication de la série en téléchargement libre, sans intervention supplémentaire de l’administrateur de données.A l’image des métadonnées des services WMS, une métadonnée du service ATOM de la plate-forme sera générée et visible du catalogue.

Le fichier ATOM de la plate-forme facilitera la communication d’outil à outil. Cette prestation a pour but de permettre à Prodige de générer des flux ATOM, mais il ne s’agit pas dans cette prestation de réaliser un client Prodige d’utilisation des flux ATOM.

Pour les utilisateurs individuels, les usages de ces flux ATOM reposeront soit sur la fonctionnalité de navigation (par exemple via les navigateurs) au sein du flux ATOM afin de permettre le téléchargement, soit sur la fonctionnalité d’abonnement à un flux ATOM, via le client de leur choix.

Les abonnements seront donc possibles soit au niveau du flux ATOM global de la plateforme, soit au niveau du flux ATOM d’une donnée.

Lors d’une mise à jour de la donnée, les flux ATOM seront modifiés, et l’abonné sera informé. Il pourra alors télécharger cette donnée via l’URL indiquée dans le flux ATOM.

Les fichiers de téléchargement de la donnée ne sont a priori générés que lorsqu’ils sont demandés.

Il est demandé au prestataire de développer les fonctionnalités de téléchargement idoines en indiquant les choix retenus en matière de stockage des fichiers pré-générés éventuellement (gestion des suppressions d’anciens fichiers en fonction des dates de mises à jour des données, ou de quotas d’espace de stockage).

Un script sera généré afin de permettre aux sites existants de créer les fichiers ATOM pour toutes les données déjà publiées en téléchargement libre.

5 Prestation P3 : Flux WMS, contextes

5.1 Production de flux WMS 1.3

PRODIGE fonctionne actuellement avec une version Mapserver 5.6.7. Cette version contraint à publier les flux WMS en version 1.1 uniquement. La mise en conformité avec INSPIRE impose que les flux soient publiés en version 1.3.La demande consiste à étudier et mettre en œuvre la solution retenue par le BRGM dans le cadre des dernières évolutions de CARMEN en utilisant simultanément deux versions de Mapserver : Mapserver 5.6.7 pour l’ensemble des fonctions cartographiques, hormis la production des WMS qui se fera via Mapserver 6.4.

5.2 Mise en conformité des contextes générés avec les schémas définis par l'OGC

Des écarts ont été constatés entre les contextes générés par PRODIGE et la norme de ceux-ci (OWS Context ).

Citons quelques exemples :

- absence de xmlns dans l’élément racine,· - plusieurs éléments ne possédant pas l’alias de leur espace de nommage (exemple : BoundingBox appartient à ows, plutôt qu’à l’espace de nommage par défaut ows-context),· - la référence au nom de la couche est erronée (elle utilise wms_name dans l’extension layer plutôt que l’attribut name de la couche),· - faute d’orthographe sur OnLineResource (devrait être OnlineResource),· - la propriété OnLineResource pointant sur l’URL n’est pas une url mais un xlink:href,· - absence de OutputFormat (pas une obligation mais ne pas avoir cette information est contraignant pour les applications qui exploitent le contexte),- Layer -> queryable="" au lieu de "0" ou "1"- pour l’élément Name des styles utilisation de valeurs ressemblant plus un Title qu’à un Name- absence pour LegendURL des attributs width, height et format en sus de xlink:href, et non server, mapfile, layer, classIdx- utilisation de DataURL pour désigner le service au lieu de Server- utilisation de l'extension propriétaire layerSettings_MetadataFile pour pointer la fiche de métadonnée, au lieu de MetadataURL- utilisation de MaxBoundingBox non défini dans le schéma de OWS Context (dans la partie standard et non dans les extensions apportées au standard)- utilisation de ows-context:Server service="WMS" au lieu de ows-context:Server service="urn:ogc:serviceType:WMS"

Il est demandé au prestataire d’identifier tous les écarts entre la mise en œuvre actuelle et les recommandations de la norme, puis de faire les développements nécessaires pour que PRODIGE génère des OWS-Context conformes.

6 Prestation P4 : Evolutions fonctionnelles 6.1 Gestion des cartes, cartes personnelles et contextes

Prodige dispose de deux modules permettant de créer des cartes.

Le premier module est dédié aux administrateurs cartographiques (traitement spécifique de la gestion des droits). Il permet à un administrateur la création de cartes à partir des données stockées dans la base PostGis de Prodige auxquelles il a droit, ou à partir de serveur WxS définis dans Prodige, et de cataloguer cette carte dans Prodige.

Le deuxième module, dit « carte personnelle », est dédié aux utilisateurs connectés. Il permet à l’utilisateur, via une interface de composition cartographique simplifiée, de réaliser des cartes à partir des couches publiées de la plateforme ou de données externes accessibles via des flux WMS ou WFS, ou de charger un contexte (ou de charger une carte déjà définie par le premier module, mais cette dernière fonction peut-être interdite globalement pour des raisons de sécurité d’accès aux données). Ces cartes ne sont pas cataloguées (pas de métadonnées de service invoke) a priori même si une intégration ultérieure au catalogue reste possible.

Enfin, par la recherche dans le catalogue, Prodige permet de sélectionner des fiches de métadonnées de données dans un panier et d’en demander la co-visualisation. Et le visualisateur du panier permet de générer ou charger un fichier de contexte.

Il est demandé de compléter le module d'administration cartographique par la possibilité d'ajouter des couches publiées (fonctionnalité actuellement absente), et d'harmoniser les 2 modules afin d’y permettre les actions suivantes sur les contextes :

- génération ou ajout d'un fichier de contexte. Le chargement d’un contexte doit proposer le choix de remplacer complètement la carte (remplacement de la carte existante par celle définie dans le contexte) ou de compléter la carte existante par les couches définies dans le contexte.

- suppression individuellement de couches des cartes, même si elles ont été chargées par un contexte unique.

Il est demandé dans le premier module de pouvoir choisir ou non d’associer un fichier de contexte à la carte que l’on catalogue, et dont l’URL sera indiquée dans un champ « Localisateur de la ressource » (Resource locator) de la fiche de métadonnées de carte.

Il est demandé également de pouvoir générer ou non un flux WMS correspondant à la carte, et dont l’URL sera indiquée dans un autre champ « Localisateur de la ressource » (Resource locator) de la MDS de carte.

Pour le chargement d’une carte, la gestion des droits d’accès aux cartes Prodige sera respectée par une restriction des cartes proposées aux seules cartes pour lesquelles l’utilisateur a un droit de consultation.

6.2 Fonctions complémentaires sur les cartes personnelles La fonction d’enregistrement des cartes personnelles devra permettre également un enregistrement sous un autre nom de la carte personnelle (cela permettra de créer une nouvelle carte personnelle).

6.3 Ajout automatique des serveurs WxS connus du catalogue ProdigeActuellement, pour l’ajout d’une couche WMS, WFS, WMTS ou WMS-C dans une carte, l'application présente une liste des serveurs pré-définis par l'administrateur de site. Il est également possible de saisir dans le champ « Nom du serveur » l'URL d'un serveur. Mais, Prodige peut moissonner d’autres plateformes et dispose ainsi dans son catalogue de

métadonnées de service (MDS) qui décrivent les services WMS, WFS, WMTS ou WMS-C.

Il est demandé d’ajouter une fonction dans le panneau d’ajout de couches, qui permette d’enrichir la liste des serveurs prédéfinis par tous ceux connus via des MDS dans le catalogue, afin d’en permettre l’utilisation de la même manière.

6.4 Accès aux informations attributairesAu sein d’une carte, Prodige permet d’interroger les données attributaires d’une couche en générant des requêtes attributaires. Mais l’interrogation sans critère de requête pour filtrer les données n’est pas autorisée.

Il est demandé de pouvoir interroger la couche également en n’appliquant aucun critère de restriction afin de permettre une visualisation complète des informations d’une couche.

Un pop-up d’information sera affiché si les données provenant d’une requête sont considérées comme trop volumineuses pour être traitées sans danger par le navigateur (la limite de volume sera paramétrable par l’administrateur de Prodige), et l’accord de l’utilisateur pour continuer sera demandé. Un filtre permettant d'afficher un nombre restreint de ligne pourra être proposé, par exemple :

Bien entendu, seuls les champs paramétrés en visualisation par l'administrateur de la donnée ou de la carte seront retournés.

L’outil de requêtes attributaires sera également enrichi pour proposer à l’utilisateur une aide à la saisie des valeurs des attributs pour constituer la requête. Cette aide se présentera sous la forme d’un bouton à côté du champ « Valeur » permettant d’obtenir la liste des valeurs distinctes du champ sélectionné, en intégrant comme restriction à cette liste l’éventuel début de saisie dans le champ valeur afin de correspondre à une fonctionnalité d’auto-complétion sans pour autant générer systématiquement à chaque frappe dans le champ « valeur » des requêtes sur la table.

Si la requête sur les valeurs distinctes renvoie trop de résultats pour être affichés, le contenu de la liste est tronqué avec ajout d’un texte indiquant cette troncature.

La sélection d’une valeur dans la liste des valeurs distinctes proposées actualise le champ « Valeur » avec cette valeur.

Le bouton actuel « Ajouter la valeur dans la requête » reste inchangé.

Un bouton « Réinitialiser » sera également ajouté (à côté du bouton « Interroger ») afin de permettre une réinitialisation de l’ensemble des champs de l’outil de requêtes attributaires.

6.5 Cartes en accès restreint :Lorsqu'une carte n'est pas dans le domaine internet, son accès nécessite d'être identifié sur la plateforme. Il est demandé que le pavé d'identification puisse être proposé à l'ouverture de l'url de cette carte. Cela permettra à un groupe d'utilisateurs d'accéder à une carte restreinte par leur compte (login/mot de passe), sans avoir à se connecter à la plateforme au préalable.

Aujourd'hui le résultat pour ouvrir une carte protégée (par exemple la carte http://carto.sigloire.fr/1/r_aagdv_p_r52.map) est :

Cela devra devenir :

6.6 Requêteur de localisation :Par défaut, toutes les cartes contiennent un requêteur de localisation permettant de centrer la carte courante sur des entités géographiques. Ce requêteur est défini par l'administrateur du site, mais l'administrateur peut néanmoins personnaliser le requêteur en fonction de la carte courante.

L'interface « Requêteur localisation » permet actuellement de gérer jusqu'à 4 listes déroulantes liées ou non entre elles.

Il est demandé dans la prestation de permettre de gérer jusqu’à 8 listes déroulantes.

Il est également demandé de pouvoir intégrer dans l’interface la possibilité d’une recherche d’adresse à partir d’une saisie libre. La résolution de cette adresse saisie et le positionnement de la carte courante à cette adresse se fera en utilisant un service de recherche au standard OpenLS 1.2, afin de pouvoir utiliser au moins le service de recherche d’une adresse du Géoportail de l’IGN.

6.7 Lien avec annuaire LDAP :Prodige permet actuellement d’importer des utilisateurs depuis un fichier d’export d’un annuaire LDAP au format LDIF.

Il est demandé de permettre l’association d’un profil prédéfini dans Prodige aux utilisateurs créés par l’import d’un fichier LDIF.

De même, l’onglet membres d’un profil doit permettre de définir comme membres de ce profil les utilisateurs résultant d’une connexion dynamique sur un annuaire LDAP, en plus de la gestion actuelle des utilisateurs interne déclarés dans Prodige.

Cette connexion doit permettre la définition d’un filtre LDAP afin de n’autoriser pour ce profil par exemple que les utilisateurs d’un service particulier défini dans l’annuaire LDAP.

L’apparition d’un nouvel utilisateur, ou la suppression d’un utilisateur existant, défini dans cet annuaire LDAP doit être gérée afin de garantir une bonne gestion des droits.

6.8 Augmenter la taille de la fenêtre d’extraction cartographique:Prodige permet actuellement de télécharger des données avec extraction sur un territoire dessiné à l’écran. Il est demandé de pouvoir augmenter la taille de la fenêtre de définition de la zone d’extraction cartographique.

7 Prestation P5 : Changement de librairie Gdal

Il est demandé de remplacer la librairie de transformation de données Gdal version 1.8.1 par la version 1.11.0

https://adullact.net/frs/download.php/6411/MIGRATION_PRODIGEV3.2_V1.1.pdf