GéoBretagne. Réalisation d'une plate-forme. géomatique internet. inter-services. Cahier des clauses techniques particulières (CCTP)

Transcription

1 GéoBretagne Réalisation d'une plate-forme géomatique internet inter-services Cahier des clauses techniques particulières (CCTP)

2 Paternité-Pas d'utilisation Commerciale-Partage des Conditions Initiales à l'identique 2.0 France Vous êtes libres : de reproduire, distribuer et communiquer cette création au public de modifier cette création Selon les conditions suivantes : Paternité. Vous devez citer le nom de l'auteur original (mais pas d'une manière qui suggérerait qu'il vous soutiennent ou approuve votre utilisation de l'oeuvre). Nom de l'auteur : DRE Bretagne Pas d'utilisation Commerciale. Vous n'avez pas le droit d'utiliser cette création à des fins commerciales. Partage des Conditions Initiales à l'identique. Si vous modifiez, transformez ou adaptez cette création, vous n'avez le droit de distribuer la création qui en résulte que sous un contrat identique à celui-ci. A chaque réutilisation ou distribution de cette création, vous devez faire apparaître clairement au public les conditions contractuelles de sa mise à disposition. La meilleure manière de les indiquer est un lien vers cette page web. Chacune de ces conditions peut être levée si vous obtenez l'autorisation du titulaire des droits sur cette oeuvre. Rien dans ce contrat ne diminue ou ne restreint le droit moral de l'auteur ou des auteurs. Ce qui précède n'affecte en rien vos droits en tant qu'utilisateur (exceptions au droit d'auteur : copies réservées à l'usage privé du copiste, courtes citations, parodie...) Ceci est le Résumé Explicatif du Code Juridique (la version intégrale du contrat).

3 Sommaire 1. PRÉSENTATION GÉNÉRALE DE L'OPÉRATION LES ACTEURS DE L'OPÉRATION La maîtrise d'ouvrage Le Chef de Projet pour la Maîtrise d'ouvrage Le Chef de Projet fonctionnel L assistance à maîtrise d ouvrage La maîtrise d'œuvre de l opération L'assistance à la maîtrise d'œuvre de l opération Services utilisateurs appelés partenaires "Lieux de rencontre" des différents acteurs MÉTHODOLOGIE DE PROJET : KHEFREN L EXISTANT LE SYSTÈME D'INFORMATION (SI) CIBLE GÉOBRETAGNE, COMPOSANT D UN SYSTÈME URBANISÉ L ARCHITECTURE FONCTIONNELLE DE LA PLATE-FORME GÉOBRETAGNE Les grands principes fonctionnels retenus La communication avec des systèmes externes Sous-domaines fonctionnels Aide en ligne DESCRIPTION DE L'ENVIRONNEMENT TECHNOLOGIQUE ACAI LES RÈGLES ACAI APPROPRIATION DU CADRE TECHNIQUE ACAI PAR LES CANDIDATS LES GRANDES LIGNES DE L'ARCHITECTURE ACAI ACAI ET LA CARTOGRAPHIE WEB MISE EN PRATIQUE D'ACAI ET DÉROGATIONS DESCRIPTION DES EXIGENCES LES EXIGENCES FONCTIONNELLES Description des sous-domaines Fiche descriptive du sous-domaine Catalogue DESCRIPTION FONCTIONNELLE DU SOUS-DOMAINE CATALOGUE Fiche descriptive du sous-domaine Cartographie DESCRIPTION FONCTIONNELLE DU SOUS-DOMAINE CARTOGRAPHIE Fiche descriptive du sous-domaine Administration DESCRIPTION FONCTIONNELLE DU SOUS-DOMAINE ADMINISTRATION Fiche descriptive du sous-domaine Site Editorial Proposition d'organisation du site éditorial Description des rubriques Fiche descriptive du sous-domaine Outils Référentiels Description des cas d'utilisation par sous-domaine Fiche descriptive du sous-domaine Catalogue Le bloc fonctionnel Paramétrage Local Le bloc fonctionnel Gestion des Lots Le bloc fonctionnel Gestion des Fiches Le bloc fonctionnel Recherche des fiches et Accès aux ressources Fiche descriptive du sous-domaine Cartographie Le bloc fonctionnel Visu Le bloc fonctionnel Couches affichées Le bloc fonctionnel Couches disponibles Le bloc fonctionnel Localisation Le bloc fonctionnel Explorateur Le bloc fonctionnel Requêteur Fiche descriptive du sous-domaine Site Editorial Le bloc fonctionnel Gestion du site

4 Le bloc fonctionnel Actualités Le bloc fonctionnel «Rechercher et cartographier» Fiche descriptive du sous-domaine Outils Référentiels Le bloc fonctionnel Accéder au cadastre Le bloc fonctionnel Extraire des rasters Fiche descriptive du sous-domaine Administration Le bloc fonctionnel Administration de la plate-forme Le bloc fonctionnel Administration du catalogue Le bloc fonctionnel Administration de la Cartographie Le bloc fonctionnel Administration du Site Editorial LES EXIGENCES NON FONCTIONNELLES Les exigences techniques Les composants Exigences pour l'interopérabilité Exigences sur la qualité des produits Exigences pour la fiabilité et la robustesse Exigences pour la performance Exigences pour l'utilisation Utilisation Gestion de la sémiologie Qualité de service et Exploitabilité Exigences sur le format données spatiales Exigences pour l'ergonomie Exigences sur la sécurité Authentification CAS (Central Authentification Service) Accès WMS/WFS Conversion de format Exigences de cycle de vie Evolutivité fonctionnelle et technique "Maintenabilité" Convergence et "réutilisabilité" Testabilité Déploiement/intégration Exigences pour la qualité de la documentation Exigences pour la qualité pilotage DESCRIPTION DE LA PRESTATION ATTENDUE STRATÉGIE DE RÉALISATION Réalisation par incréments Définition des incréments Exigence pour les incréments Gestion de la version des incréments Procédure de validation d'un incrément Gestion des packs de livraison RÉCAPITULATIF SYNTHÉTIQUE DES PHASES, ÉTAPES DE LA PRESTATION DESCRIPTION DÉTAILLÉE DES PHASES OPTION : TÉLÉCHARGEMENT DE FICHIERS RASTER LA COMMANDE DE LA PERSONNE PUBLIQUE DESCRIPTION DU BESOIN EXIGENCES FONCTIONNELLES EXIGENCES NON FONCTIONNELLES INTÉGRATION DE L'OPTION DANS LA PLATE-FORME PRESTATION ATTENDUE DOCUMENTS FOURNIS PAR LA PERSONNE PUBLIQUE EN ANNEXE DU CCTP ORGANISATION DU PROJET... 56

5 8.1 EQUIPE PROJET PERSONNE PUBLIQUE EQUIPE PROJET TITULAIRE RÉUNIONS Réunions de pilotage Réunions de suivi Réunions de présentation COMMUNICATION EN COURS DE PROJET Site de W collaboratif Messagerie électronique Format des documents Journal de projet Annuaire contacts titulaire PLANNINGS PRÉVISIONNELS RÉCEPTION DES LIVRABLES PRINCIPES GÉNÉRAUX D'ORGANISATION CHEVAUCHEMENT DES ÉTAPES TABLEAU DES LIVRABLES RÉCEPTION DE L'APPLICATION GARANTIE MANAGEMENT DE LA QUALITÉ GESTION ET SUIVI DE LA QUALITÉ DU PROJET Stratégie générale Procédure de suivi et d'avancement du projet SUIVI DE LA QUALITÉ DES PRODUITS Conformité "Maintenabilité" Facilité d'installation "Exploitabilité" RESPECT DES RÈGLES DE SÉCURITÉ, RESPONSABILITÉS...61

6 Préambule : GéoBretagne, une organisation et une plate-forme géomatique régionale L opération initialement désignée «SIGIS, évolution vers la version 2» sera désormais désignée par le vocable «GéoBretagne». Le projet de Système d'information Géographique inter-services en Bretagne (SIGIS) a été engagé en 2005 dans le cadre du Plan d'action Stratégique en Région Bretagne (PASER). Sa vocation fondamentale est de permettre l'échange et l'utilisation de l'information géographique dans une perspective de connaissance et d'analyse des territoires en Bretagne. Le SIGIS est un outil d'aide à la décision dans le cadre de la mise en œuvre des politiques publiques. La plate-forme SIGIS a officiellement été ouverte le 20 avril La première phase de ce projet a été clôturée par cette action. A ce jour, 17 services ont contribué par la mise à disposition d'une quarantaine de lots de données, tous accessibles et/ou téléchargeables sur la plate-forme. Le Contrat de Projet Etat-Région en Bretagne signé le 12 avril 2007 pour la période intègre dans ses actions le projet d'évolution du SIGIS. La démarche se poursuit donc en partenariat avec les collectivités territoriales sous le nom "Evolution du SIGIS vers la version 2". Au-delà de la plate-forme technique, GéoBretagne est un dispositif d animation et d échanges en matière d information géographique : il a vocation à contribuer à la mutualisation des moyens et des compétences des différents partenaires de la sphère publique sur le territoire breton. Pour favoriser les échanges de données, le SIGIS V1 s appuie sur un dispositif fédérateur qui permet de stocker, cataloguer et mettre à disposition de l information localisée pour la communauté d utilisateurs. 1.Présentation générale de l'opération 1.1Les acteurs de l'opération 1.1.1La maîtrise d'ouvrage L'opération GéoBretagne étant financée dans le cadre du Contrat de Projet Etat Région (CPER), la maîtrise d'ouvrage est double. Chacune des parties a nommé un représentant, l'un à la Direction Régionale de l'equipement de Bretagne (Direction, Mission Prospective), l'autre au Conseil Régional de Bretagne (Mission stratégie, évaluation et prospective). Les décisions sont prises sur consensus entre les deux structures et par souci d'efficacité et de simplification, toute les formalisations de décisions, validation, sont assurées par la maîtrise d'ouvrage Etat Le Chef de Projet pour la Maîtrise d'ouvrage Ce rôle est assuré par la personne chargée du développement de la géomatique en région au sein du pôle géomatique, lui même positionné dans la mission prospective.

7 1.1.3Le Chef de Projet fonctionnel Ce rôle est assuré par la même personne chargée du développement de la géomatique en région au sein du pôle géomatique L assistance à maîtrise d ouvrage Elle est assurée par le Centre d Etudes technique de l Equipement de l Ouest (CETE), ainsi que par le Bureau des Technologies de l'information de la Direction Régionale de l'equipement de Bretagne (DRE/CSM/BTI) La maîtrise d'œuvre de l opération Elle est assurée par le Pôle géomatique de la DRE, pilotée par l'agent chargé du développement de la géomatique en région L'assistance à la maîtrise d'œuvre de l opération Elle est assurée : - par le Centre d'etudes Technique de l'ouest (CETE). Il est représenté par 2 personnes positionnées dans la Division Informatique et Organisation (DIOG) du CETE de l Ouest - par le Centre Support Mutualisé (CSM) de la DRE Bretagne, et par une personne positionnée au Bureau des Technologies de l Information (BTI), au sein du pôle développement Services utilisateurs appelés partenaires Au démarrage du projet d'évolution du SIGIS vers la V2, objet de ce document, les utilisateurs de la version initiale du SIGIS (V1) sont les services de l'etat dans la région. 17 services de l'etat sont à ce jour représentés et contributeurs. Ils sont désignés comme les "partenaires". Pour le projet GéoBretagne, le contour des utilisateurs s'élargit aux collectivités territoriales et aux services départementaux de l'etat, et à tout signataire de la charte partenariale après approbation du comité de pilotage "Lieux de rencontre" des différents acteurs Les rôles des différentes instances GéoBretagne sont balisés et formalisés dans un document nommé "Charte partenariale du SIGIS Bretagne" (annexée au présent CCTP). Le comité de pilotage (renommé comité de concertation) Il est présidé par la Préfecture de la Région Bretagne. Il est à ce jour constitué des Directeurs des services de l'etat dans la Région (y compris la DRE), des Préfets des 4 départements bretons et du Président du Conseil régional de Bretagne. Le rôle du Comité de pilotage est défini dans la charte partenariale en ces termes : -"fixe les orientations du SIGIS Bretagne, -prend les décisions relatives à l organisation du SIGIS Bretagne,

8 -définit, valide et permet la mise en oeuvre des moyens humains, matériels et financiers nécessaires au fonctionnement et à l évolution du SIGIS, -organise et met en oeuvre le financement du SIGIS Bretagne, -propose aux participants des modes de fonctionnement, -propose et décide toute modification de la présente charte, -accepte ou refuse l entrée d un partenaire." 1. Le comité technique Il est présidé par le maître d ouvrage, animé par le CPMO et rassemble les représentants techniques des services partenaires, ainsi que l'équipe d'assistance à maîtrise d'œuvre et d'ouvrage du CETE. Les utilisateurs "métiers" ne sont pas représentés au comité technique. 1.2Méthodologie de projet : Khefren Son rôle est défini comme suit dans la charte partenariale : -coordonne la mise en œuvre des orientations du comité de pilotage, -propose des orientations au comité de pilotage, -suit les réalisations des orientations et des précédentes décisions, -coordonne les travaux réalisés par les partenaires - en commun ou non - dans le domaine de l information géographique, dont les projets d acquisitions de matériels, logiciels ou données, -coordonne les travaux des pôles métiers, Le projet est conduit selon la méthodologie Khefren, élaborée au Ministère pour aider les maîtrises d'œuvre dans le cadre de la réalisation d'applications informatiques. Dans ce cadre, GéoBretagne, objet du présent CCTP constitue et sera désigné par le terme "opération". L'opération est elle-même découpée en projets : 1. projet d'étude d'opportunité 2. projet fonctionnel 3. projet technique 4. projet de recette 5. projet d'acquisition 6. projet d'accompagnement Le synoptique ci-dessous permet de visualiser le phasage des différents projets ainsi que les points de jalonnement matérialisés par les points de numérotation.

9 Points de jalonnement de la maîtrise d'ouvrage 1 Après validation des enjeux, des objectifs et de la stratégie globale de l'opération, décision du maître d'ouvrage de poursuivre ou non 2 Décision de lancer l'opération en fin d'étude d'opportunité 3 Actualisation de l'organisation générale de l'opération (fonctionnel, technique, recette, accompagnement, acquisition) 4 Validation des spécifications fonctionnelles 5 Validation de l'architecture technique applicative 6 Validation du plan "d'accompagnement du changement" 7 Décision de l'installation en site pilote 8 Vérification ultime de l'adéquation aux besoins et et exigences 9 Décision de fin d'opération, date de fin Aux points de jalonnement Khefren se rajoutent les points de jalonnement ACAI (Architecture Commune pour les Applications Informatiques). Cette architecture élaborée au METATTM détermine les spécifications non fonctionnelles à respecter pour le développement des applications informatiques afin de pouvoir les certifier par rapport au Cadre Commun d Interopérabilité défini par la circulaire du 1er Ministre du 21 janvier Le chapitre 5 du présent CCTP expose les exigences de cette architecture et les conditions dans lesquelles le prestataire devra élaborer son offre dans ce cadre. Le choix ACAI s'est justifié sur les critères suivants :

10 - garantie d'un niveau de qualité au bénéfice des utilisateurs et des administrateurs du système - pérennité, évolutivité et maintenabilité de la plate-forme - possibilité d'un hébergement à haut niveau de service au CETE Bordeaux (MEDAD) sans compromettre un autre choix d hébergement - réponse à une grande partie des exigences non fonctionnelles de la maîtrise d ouvrage (interopérabilité, modularité, évolutivité) Le projet d'étude d'opportunité est terminé et a fait l'objet d'un rapport (annexe n ). Le projet fonctionnel est constitué de deux grandes "phases" : analyse et conception. La prestation objet du présent CCTP, couvre la partie conception du projet fonctionnel et le projet technique tel qu'il est défini dans Khefren. Le prestataire trouvera en annexe les documents qui lui permettront d'appréhender les grands principes de la méthode. 1.3 L existant Processus "métier" du domaine cible actuel Dans sa version actuelle, le SIGIS offre des fonctionnalités de catalogage, de visualisation et de composition de cartes. Les grands processus métier traités sont les suivants: - visualisation d'indicateurs au travers de la "cartothèque" - composition d'une carte grâce à "l'explorateur" - consultation de fiches de méta-données et téléchargements de lots de données grâce au catalogue. Le patrimoine des données actuellement mis à disposition est constitué : - Des cartes indicateurs, pertinentes pour l'essentiel à l'échelle régionale - Des référentiels IGN (SCAN 25, orthophotoplan) - Des lots de données de zonage du 1/25000 au 1/50000 Techniquement, l'accès à des données stockées sur des serveurs distants configurés WMS est possible, il est par exemple opérationnel sur le serveur SETRA pour lequel le serveur SIGIS a été référencé comme "autorisé". Jusqu'en juillet 2007, les lots de données étaient intégrés par le CETE, selon une procédure qui n'était pas automatisée (structuration des fichiers fournis par les services "diffuseurs", préparation des fichiers Mapfile, intégration sur le serveur de développement, synchronisation avec le serveur de production par les services techniques du CETE). Un transfert de compétence a eu lieu en juillet avec le recrutement d'un administrateur technique du SIGIS à la DRE. Un serveur de développement a été installé à la DRE et cette prestation est aujourd'hui assurée en régie. La synchronisation entre le serveur de développement et le serveur de production est toujours assurée par le CETE qui héberge la plate-forme chez un prestataire privé. L'application ne permet à ce jour aucun traitement des droits des utilisateurs sur les lots de données et les fonctionnalités de l'outil.

11 Les acteurs cibles de l'existant Ils sont actuellement : - les chargés d'études qui souhaitent télécharger des données pour des besoins d'analyses - les décideurs qui visualisent les indicateurs ou les données localisées - Les administrateurs de données localisées (ADL) qui administrent et cataloguent les lots de données Existant fonctionnel et technique Outils Client L'architecture actuelle du SIGIS est composée de briques fonctionnelles répondant à la première phase de réalisation prévue dans l'étude d'opportunité initiale. La cartothèque La cartothèque permet à toute personne s'étant connectée à l'application de visualiser une carte. Les cartes sont proposées à la visualisation en fonction de mots clefs relatifs au thème sur lequel elles portent. L'utilisateur bénéficie de l'ensemble du patrimoine de cartes publiques offertes, et dispose des outils classiques de navigation (zoom, pan...) grâce au composant «Visualisateur» qui assure la visualisation et la navigation dans une carte. L'explorateur L'explorateur permet à un utilisateur de composer sa propre carte en empilant : - les couches du SIGIS déclarées au moteur cartographique - les couches disponibles auprès des serveurs WMS disponibles - les couches issues d'une carte disponible dans la cartothèque L'utilisateur peut ordonner les diverses couches de sa carte et affecter un pourcentage de transparence. Après l'avoir nommée et y avoir affecté des mots clefs, l'utilisateur peut enregistrer sa carte (WMC) et la rendre disponible soit par la cartothèque (carte publique) soit en diffusant son adresse (carte privée). Les possibilités offertes par l'explorateur sont assurées par le composant «Visualiseur» auquel on ajoute des plugins afin d'étendre sa couverture fonctionnelle. L'entrepôt L'entrepôt est une application écrite en langage Java qui gère les cartes stockées sous forme de contexte OGC. Cette application délivre la liste des mots-clefs contenus dans chaque contexte (carte) pour la cartothèque, stocke sous forme de contexte la liste des couches que lui adresse l'explorateur, adresse à la demande la description de chaque

12 carte sous forme de fichier XML. Les fonctions publiques de l'entrepôt sont accessibles par adresse (URL) selon une syntaxe définie pour les besoins du SIGIS. Il existe une nouvelle version du composant entrepôt qui intègre les fonctionnalités du Printer. Ce composant pallie les manques fonctionnels du catalogue. Le printer Prototypé en langage PHP, le printer génère à partir d'un fichier XML (WMC) décrivant une carte et délivré par l'entrepôt, une image ou un fichier PDF de la carte demandée. Les fonctions publiques du Printer sont accessibles par adresse (URL) selon une syntaxe définie pour le SIGIS. Ce composant PHP devrait laisser sa place à la nouvelle version de l'entrepot. Le catalogue Le composant Catalogue est assuré par l'outil du CERTU nommé Reports. Cet outil permet de stocker des fiches de méta-données. Chaque fiche décrit un lot de données et peut le référencer au travers d'une URL pour le télécharger. L'outil Reports offre des fonctionnalités de recherche. Forces et faiblesses Les composants du SIGIS présentent les forces suivantes : - ils apportent une réponse concrète aux besoins exprimés dans la phase initiale de réalisation de l'outil SIGIS tel que définie dans l'étude d'opportunité initiale - ces composants sont indépendants les uns des autres et leurs fonctions sont accessibles par une simple adresse Internet (Architecture REST) - les composants Cartothèque et Explorateur s'exécutent dans le navigateur et sollicitent peu le serveur - les normes d'interopérabilité de l'ogc sont utilisées pour la visualisation, l'interrogation et le stockage de carte. - Par contre, on peut mettre en exergue les faiblesses du SIGIS actuel pour une évolution vers le nouveau périmètre fonctionnel : - la gestion des droits utilisateurs n'existe pas - il n'existe pas de gestion des droits d'accès aux données - la sécurisation applicative des composants n'est pas intégrée à la conception - l'organisation de la cartothèque autour de mots-clefs s'avère peu satisfaisante; pas de possibilité de recherche, de classement par thématique métier... - il n'existe pas d'interface de gestion et d'administration des cartes et données - le format de stockage des fiches de méta-données n'est pas normée - il n'existe pas de liaison entre le composant de création de carte (explorateur) et le catalogue - le catalogue n'est pas accessible par d'autres composants internes ou externes au SIGIS. - Les conditions d'hébergement ne font pas l'objet d'un contrat stipulant le niveau de service attendu. Toutes ces faiblesses devront être corrigées dans la version 2.

13 2.Le système d'information (SI) cible 2.1 GéoBretagne, composant d un système urbanisé Le système d information GéoBretagne s inscrit dans une architecture générale au sein de la région qui permet de partager des données localisées entre sites distants, à compétence régionale ou infra-régionale. Cette architecture régionale s'inscrit elle-même au sein d'une architecture nationale qui compte également des plate-formes d échanges de données, des sites ou des applications thématiques traitant, utilisant, diffusant des données localisées. L'architecture visée permettra la collaboration entre ces différents systèmes par le respect de normes et de standards spécifiés dans le présent CCTP. 2.2 L architecture fonctionnelle de la plate-forme GéoBretagne La plate-forme géomatique GéoBretagne n a pas uniquement vocation à administrer les données géographiques communes aux différents partenaires mais également à faciliter l accès aux données géographiques de plusieurs plate-formes de gestion et d échange. Elle se positionne à la fois comme portail fédérateur indexant des sites existants régionalement et comme entrepôt pour des services ne disposant pas d infrastructure propre Les grands principes fonctionnels retenus Pour cheminer vers et atteindre cet objectif, la description fonctionnelle de la plate-forme GéoBretagne est basée sur quelques grands principes généraux.

14 La communication avec des systèmes externes Tout au long du document, il est fait référence aux normes et standards qui visent à garantir que la plate-forme communique avec les systèmes externes Sous-domaines fonctionnels Vue urbanisée de la plate-forme GéoBretagne Le domaine de la plate-forme GéoBretagne est décomposé en 7 sous-domaines dont 1 externe à l'application. Les objectifs opérationnels par sous-domaines sont les suivants : Site éditorial de GéoBretagne - son objectif est d informer sur les décisions et acquisitions du partenariat et de référencer le contenu de plates-formes de gestion existantes. Il comprend donc des fonctions d administration de site Web pour la structuration et mise en ligne des informations, des fonctions d indexation afin d interroger le sous-domaine Catalogue sur les fiches de méta-données. - Il a vocation à être le "portail d'entrée" des partenaires pour l'accès à l'information localisée accessible Administration : sous-domaine permettant la gestion et le paramétrage de la plate-forme Catalogue : - Il permet de stocker, cataloguer et mettre à disposition l information. Ce sousdomaine offre les outils de gestion et d échanges du patrimoine de données et services référencés. - il permet de gérer les fiches de méta-données qui peuvent référencer des ressources telles que des lots de données, des cartes (dynamiques ou statiques), des couches. Chaque ressource de la plate-forme est attachée à une fiche de métadonnées. Il est ainsi possible de retrouver, grâce au moteur de recherche du catalogue, les fiches et donc les ressources qu elles référencent. Une fiche a un cycle de vie et est accessible en fonction de son état et des droits dont disposent les groupes. Les droits des groupes sont déterminés par les fonctions allouées sur le thème\sous-thème de la fiche, voire par une limitation de l étendue géographique. Il est toutefois possible que le groupe créateur de la fiche exclut explicitement un

15 groupe ayant les droits sur le thème\sous-thème. Les droits des groupes sont donc fonction du profil, mais sont également modulables par ressources Cartographie : - ce sous-domaine propose les fonctionnalités de visualisation, constitution et interrogation de cartes dynamiques - il permet de consulter, créer, modifier des cartes\couches, mais également de manipuler des objets géographiques. Ces ressources sont soit accessibles sans authentification (cas des ressources de type «tout public»), soit nécessitent une authentification (cas des ressources «public restreint») tant par les groupes que par les systèmes externes Outils Référentiel : - ce sous-domaine propose les fonctionnalités autour des référentiels cadastre et raster disponibles sur la plate-forme. La réalisation des fonctionnalités autour du raster sont optionnelles. Entrepôt : gestion du stock de cartes et du stock de données Supervision du système informatique [hors marché] Habilitation des acteurs effectuée au travers du composant CAS (Central Authentification Service) La plate-forme intègre également deux outils : l outil cadastre : il permettra de visualiser et de télécharger les fichiers cadastraux l outil raster : il offrira les fonctions d extraction et de mise à disposition de raster. La réalisation de cet outil est une option. Les deux outils "cadastre" et "raster" décrits dans le présent document s appuient pour partie sur les blocs fonctionnels des grands domaines Cartographie et Catalogue Aide en ligne Tout au long de sa navigation dans la plate-forme GéoBretagne, l utilisateur disposera d une aide en ligne lui décrivant les actions attendue. Tous les moyens seront utilisés pour que cette aide soit le plus pédagogique possible (utilisation de vidéo par exemple). Un lien sera fait avec la documentation utilisateurs, les deux pouvant être complémentaires. 3.Description de l'environnement technologique ACAI L'utilisation du référentiel et la réalisation d'applications informatiques au sein du Ministère de l'ecologie du Développement et de l'aménagement Durables (MEDAD) selon l'architecture Commune des Applications Informatiques (ACAI) ont été officialisées par la circulaire n du 30 mars 2005, publiée au journal officiel du METATM (aujourd'hui MEDAD). La réalisation d'une application informatique ACAI implique de respecter un cadre technique formalisé au travers de plusieurs documents. Il s'agit également de respecter une procédure de validation ponctuée de points de "jalonnement", points d'arrêt conditionnant la poursuite du projet.

16 Ces points de jalonnement sont joints en annexe du présents CCTP et intégrés dans le planning général de l'opération. Le maître d'ouvrage de GéoBretagne a fait le choix de développer l'application selon cette architecture. Elle est fondée sur l'utilisation des technologies issues de l'internet et du langage de programmation Java. 3.1Les règles ACAI Le référentiel est structuré de la façon suivante : - Règles d'ergonomie - Règles de réalisation - Règles de persistance - Règles de modélisation Au sein de chacune de ces "catégories", les règles sont caractérisées par 3 niveaux possibles d'exigences, traduits selon la typologie suivante : Incontournable Recommandée Suggérée Règle dont l application est obligatoire Recommandation (possibilité de dérogation sous réserve de justification) L'utilisation de cette règle est proposée mais ne s'impose pas dans le cadre de la certification ACAI Objectifs La construction d'une application en architecture ACAI permet d'atteindre les objectifs suivants : Portabilité "Maintenabilité", évolutivité "Réutilisabilité" Robustesse, stabilité Performance Sécurité Ergonomie Accessibilité Les priorités pour le GéoBretagne seront : 1. De garantir l'interopérabilité 2. De garantir des niveaux de performance spécifiés 3. De garantir des possibilités d'hébergement spécifiées

17 4. De garantir les possibilités d'utilisation 5. De garantir la pérennité de la plate-forme 3.2Appropriation du cadre technique ACAI par les candidats Pour concevoir la solution la plus conforme possible aux exigences du maître d'ouvrage, le prestataire devra s'approprier les guides suivants : - Guide de conception-réalisation - Guide de persistance - Guide de l'ergonomie - Modèles d'ergonomie - Guide de modélisation Il trouvera également dans les documents suivants des informations nécessaires pour la conception de la solution : - Guide de la recette technique ACAI et ses fiches techniques - Conditions d'hébergement ACAI - Dossier de Conception Type ACAI - Cahier des clauses techniques générales Ils sont téléchargeables à l'adresse : Et/ou joints en annexe du présent CCTP. Le tableau ci-dessous regroupe l ensemble des guides devant être pris en compte pour la réalisation de cette application selon les spécifications ACAI exigées. Guide Version Cahier des clauses techniques ACAI 1.5(mars 2005) Guide de persistance pour les applications 1.5(mars internet ou intranet 2005) Guide de conception-réalisation pour les 1.5(mars applications internet ou intranet 2005) Guide de modélisation pour les apllications 1.5(mars internet ou intranet 2005) Guide d ergonomie pour les applications 1.5(mars interner ou intranet 2005) ACAI-RecetteTechnique 1.0(oct 2006) 3.3Les grandes lignes de l'architecture ACAI Le socle de l'architecture ACAI est structuré à partir des éléments suivants : - Architecture logicielle type Web, client léger - Privilégier les composants libres «reconnus», les composants modulaires et évolutifs - Utilisation de l environnement Java standard J2EE - Navigateurs cibles : Mozilla Firefox, IE

18 - Systèmes et logiciels - Réseau - Cartographie Système d exploitation Linux ou Unix Serveur Web Apache BDD par défaut : PostgreSQL et extension PostGIS pour données géomatiques exigences de débit protocoles HTTP et HTTPS si besoin de sécurité Utilisation des principes de l OGC Serveurs de cartes : WMS Serveurs d objets géographiques : WFS - Authentification et droits Utilisation du système d authentification Cerbère : une dérogation est demandée. - Conception et réalisation Modélisation UML Incitation à l élaboration de schémas XML Quel que soit l outil de développement utilisé, livraison du produit final accompagné des sources et des fichiers de configuration Documentation réalisée au format Javadoc 3.4 ACAI et la cartographie WEB La circulaire ACAI impose la mise en œuvre de toute solution implémentant des fonctionnalités cartographiques selon les principes de l'ogc (Open GIS Consortium) : - Persistance des données : serveurs de cartes WMS (Web Map Server) et serveurs d'objets géographiques WFS (Web Feature Serveur) - Accès à ces serveurs par les interfaces WMS (Web Map Service) ou WFS (Web Feature Service) sur le protocole HTTP - L application en elle-même ajoute simplement à sa logique métier la gestion des images ou des flux GML rendus par ces interfaces.flux GML 3.5Mise en pratique d'acai et dérogations La procédure ACAI prévoit que des dérogations puissent être demandées par le maître d'ouvrage ou par le maître d'œuvre technique. Demandes de dérogation préalables formalisées par le maître d'ouvrage

19 La DRE Bretagne a d'ores et déjà formalisé et demandé un certain nombre de dérogations. Elles sont mentionnées dans le document "fiche descriptive d'une application informatique", jointe en annexe du présent CCTP. Demande de dérogation par le prestataire Si dans le cadre de la conception de son offre le prestataire souhaite soumettre une demande de dérogation, il la mentionnera alors dans le tableau correspondant des règles ACAI joint en annexe au présent CCTP, sur la ligne correspondant à la règle à déroger. Il précisera si cette dérogation est : - Incontournable pour répondre à un (des) besoin(s) fonctionnel(s) exigé(s) - Suggérée car apportant une plus-value indéniable (mais pas indispensable) à la solution proposée, et préciser sur quel domaine (ergonomie, performance, robustesse, interopérabilité, évolutivité) 4.Description des exigences 4.1Les exigences fonctionnelles Description des sous-domaines Fiche descriptive du sous-domaine Catalogue La plate-forme géomatique GéoBretagne est un dispositif centralisé pour la gestion et la mise à disposition de données, cartes et services géographiques dans la région Bretagne. Les différents organismes désireux d'être partenaires autour GéoBretagne pourront utiliser les outils mis à disposition par la plate-forme ou bien leur propre dispositif d'administration de données afin d'alimenter le portail GéoBretagne. Les partenaires ne disposant pas d'outil d'administration de données (catalogage, mise à disposition de données) pourront utiliser le catalogue du GéoBretagne pour partager leurs données avec la communauté. Toutefois, ces partenaires peuvent également souhaiter gérer des données «non-partageables» ou héberger localement leurs propres données. Bien que par défaut les fiches de méta-données du catalogue soient visibles par tous, le sous-domaine «Catalogue» permettra de limiter la visibilité des fiches à des groupes restreints d'utilisateurs. Les fiches de méta-données sont nécessaires pour décrire des jeux de données, des cartes ou des services et faciliter l'accès à ces informations lors de recherches. Ce sous-domaine propose des outils de recherche, de consultation et d'affichage de ces fiches. Ce sous-domaine pourra également échanger avec des catalogues distants en vue de partager des fiches de méta-données. Par le respect

20 des normes et standards, ce sous-domaine offrira des interfaces accessibles par de futures applications géomatiques. Description fonctionnelle du sous-domaine Catalogue Schéma du sous-domaine Catalogue Le sous-domaine Catalogue est composé de quatre blocs fonctionnels qui répondent aux besoins suivants: Paramétrage local : les paramètres partagés entre tous les administrateurs de données du GéoBretagne sont définis dans le sous-domaine Administration. Ce bloc fonctionnel autorise les administrateurs de données à étendre une partie de la nomenclature commune pour répondre à leurs besoins spécifiques. Gestion des lots : chaque administrateur de données se verra allouer un espace de stockage par l administrateur du système. A l intérieur de cet espace, l administrateur pourra gérer son arborescence de répertoires afin de gérer ses lots de données. Gestion des fiches : ce bloc regroupe l ensemble des fonctions de gestion du cycle de vie d une fiche de méta données. Recherche des fiches et accès aux ressources : décrit la consultation des fiches et l accès aux données et cartes.

21 Fiche descriptive du sous-domaine Cartographie Description fonctionnelle du sous-domaine Cartographie Schéma du sous-domaine Cartographie Le sous-domaine Cartographie est composé d un quartier et de trois blocs fonctionnels qui assurent les besoins suivants : Quartier Visualiseur : ce quartier fonctionnel est composé de trois blocs fonctionnels nommés : - Visu : ensemble des fonctions de visualisation et de navigation dans une carte. - Localisation : ensemble des fonctionnalités de positionnement géographique - Gestion des couches : gère les couches constitutives de la carte - Explorateur : bloc fonctionnel qui inclut les fonctions de création de carte pour la plate-forme et de téléchargement Bloc Styleur : ce bloc offre les fonctions de représentation (stylage) d une couche Bloc Requêteur : ensemble des fonctions permettant d effectuer des requêtes sur les couches, soit pour créer de nouvelles couches soit à but d analyses simples Fiche descriptive du sous-domaine Administration Description fonctionnelle du sous-domaine Administration Fiche descriptive du sous-domaine Site Editorial GéoBretagne est une plate-forme partenariale des services de la région Bretagne. Afin de favoriser l'animation entre partenaires, il est également souhaité un site WEB proposant des espaces d'échanges d'expérience et

22 de communication afin de valoriser les différents travaux et actions communes. D'autre part, GéoBretagne peut évoluer dans ses objectifs afin d'améliorer l'information du public sur des sujets aussi divers que la réglementation, les communiqués, les cartes portées à connaissance. Le site Editorial se positionnera comme la porte d'entrée de GéoBretagne avec une double objectif de service et de communication. Une attention particulière sera notamment portée à la qualité de son ergonomie. Le prestataire s'attachera à constituer une équipe qui comprendra les compétences nécessaires pour obtenir un site de qualité Proposition d'organisation du site éditorial Le schéma ci-après propose une vue des différentes rubriques du site éditorial. Il est totalement indicatif et des propositions sont attendues de la part du prestataire. Les principales fonctionnalités attendues du Site Editorial sont assurées par un outil de gestion de contenu. Le prestataire proposera un outil simple et évolutif pour créer et gérer un site Internet ou Intranet sans connaissance technique. Cet outil sera issu du monde libre et soutenu par une communauté active Description des rubriques Le site contiendra deux types de rubriques: celles dites publiques pour lesquelles aucune authentification n'est requise pour accéder à l'information et celles dîtes privées nécessitant une authentification. En outre, on trouvera l affichage de l'agenda du GéoBretagne: comité de pilotage, comité technique, pôles métiers, évènements locaux et la

23 Les rubriques publiques Les rubriques privées possibilité d ouvrir un formulaire d'échange avec les administrateurs techniques du GéoBretagne. Par défaut, on accède au site éditorial sur une page d'accueil comprenant : une rubrique Actualités proposant les dernières actualités mises en ligne. Ces actualités peuvent être : un article récemment publié, les dernières fiches de méta-données dîtes «tout public» (Cf. les règles de visibilité d'une fiche) publiées ou les dernières cartes. Il sera possible de s abonner ou se désabonner à un flux RSS ou GéoRSS une rubrique Contacts affichant les coordonnées des partenaires du GéoBretagne une rubrique Pôles métiers dans laquelle on visualisera les documents publics une rubrique Liens utiles référençant le Géoportail et Inspire une rubrique Actualités proposant les dernières actualités mises en ligne. Ces actualités peuvent être : un article récemment publié, les dernières cartes ou les dernières fiches de méta-données dîtes «tout public» ou «public restreint». Il sera possible de s abonner ou se désabonner à un flux RSS ou GéoRSS une rubrique Contacts comprenant: un annuaire qui affiche les coordonnées des partenaires de GéoBretagne, permettra d'imprimer les coordonnées des partenaires, télécharger l'annuaire des producteurs de données... des formulaires de contacts vers les administrateurs techniques de GéoBretagne, qui permettent d'adresser un mail vers un contact choisi ou une liste de diffusion. une rubrique Pôles métiers dans laquelle on visualisera des documents tels que les compte-rendus de réunion, les tableaux de bord des actions entreprises et offre un accès vers une base documentaire par pôle métier. Cette base documentaire serait alimentée par les partenaires. une rubrique Base documentaire dans laquelle seront ordonnées des documentations technique, juridique. Dans cette base documentaire, les fonctionnalités suivantes sont attendues : Déposer, supprimer un document Afficher la documentation selon l arborescence retenue, au sein de laquelle l'administrateur pourra mettre en œuvre une organisation en dossiers Rechercher un document par saisie de mot clé (sur titre, contenu du document ou résumé?), par date, par auteur? Paramétrer un champ de tri pour l'affichage du résultat de la recherche. Sélectionner les documents et les déposer dans le "panier" Télécharger les documents du panier

24 Imprimer les documents du panier Une rubrique Mes Cartes Favorites dans laquelle l utilisateur authentifié retrouvera la liste des cartes/couches qu il a souhaité conserver (cf. CU_ Ajouter à mes Cartes favorites). Dans cet espace, l utilisateur pourra supprimer une référence à une carte. Une rubrique Référentiels qui porte à connaissance et délivre les informations et données sur les référentiels accessibles sur la plate-forme. Il est à noter que cette rubrique et les fonctionnalités auxquelles elle donne l'accès sont particulièrement attendues par les utilisateurs. Les lots de données cadastre n'étant pas associés à des fiches de métadonnées, une fiche "méta-donnée générique" sera accessible sur le site Fiche descriptive du sous-domaine Outils Référentiels La plate-forme GéoBretagne permet également l'utilisation de données référentielles, indispensables pour l'exercice des différents métiers. Ces données référentielles sont constituées notamment par les fichiers raster provenant des fonds référentiels Raster et par les données relatives au cadastre. Les fonctionnalités relatives à l extraction Raster sont optionnelles. Le Cadastre Les principales fonctionnalités attendues sont: la consultation et l intégration du cadastre dans GéoBretagne en partant des fichiers Édigéo livrés à la commune ; le téléchargement des fichiers du cadastre, à la commune, en Édigéo et aux formats des différents logiciels du marché dans le souci d être le plus ouvert possible ; l accès en WMS/WFS (en attendant que la DGI le fasse) : aux couches du cadastre intégrées dans GéoBretagne pour qu elles puissent être réutilisées dans les outils locaux directement et afin de pourvoir bénéficier simplement de données actualisées ; les liens vers les plateformes ou sites locaux existants en matière de cadastre. Les référentiels raster (option) L utilisateur devra donc : pouvoir définir la zone de travail qui l intéresse et pour laquelle il souhaite télécharger les données correspondantes visualiser les données sur cette zone télécharger automatiquement les dalles ou fichier extrait correspondants à la zone définie

25 4.1.2Description des cas d'utilisation par sous-domaine Tous les cas d'utilisation sont décrits dans l'annexe "Description fonctionnelle Fiches cas d'utilisation". Ils sont classés par domaine, selon la table des matières ci-dessous. Le prestataire peut se rapporter aux numéros de page pour y accéder Fiche descriptive du sous-domaine Catalogue Le bloc fonctionnel Paramétrage Local CU_Gérer la liste des producteurs personnalisés 11 CU_Gérer la liste des contacts personnalisés 12 CU_Gérer la liste des couvertures administratives personnalisées 12 CU_Visualiser les statistiques du groupe Le bloc fonctionnel Gestion des Lots CU_Gérer son arborescence 13 CU_Créer un lot de données 13 CU_Supprimer un lot de données 13 CU_Ajouter des fichiers dans un lot de données 14 CU_Supprimer des fichiers dans un lot de données Le bloc fonctionnel Gestion des Fiches Cycle de vie d une fiche de méta-données 14 Les méta-données non visibles 15 Les actions autorisées sur les fiches 15 CU_Créer manuellement une fiche de méta-données 16 CU_Créer automatiquement une fiche de méta-données 16 CU_Modifier une fiche de méta-données 16 CU_Supprimer une ou des fiches 17 CU_Dupliquer une fiche 17 CU_Exporter manuellement une fiche 18 CU_Exporter automatiquement une à plusieurs fiches 18 CU_Importer manuellement une fiche 18 CU_Importer automatiquement une ou plusieurs fiches(1) 19 CU_Moissonner un catalogue distant(1) 19 CU_Demander une fiche à un catalogue distant (1) 19 CU_Valider une fiche 19 CU_Publier une fiche 20 CU_Dépublier une fiche 20 CU_Imprimer une fiche 21 CU_Imprimer des fiches 21 CU_Publier des données comme couche WMS 21 CU_Publier des données comme couche WFS Le bloc fonctionnel Recherche des fiches et Accès aux ressources 22 Les règles de visibilité sur les fiches 22 Les règles de visibilité sur les ressources référencées par les fiches 22 Les critères de recherche d une fiche de méta-données 23

26 Présenter le résultat de la recherche 23 CU_Rechercher une fiche de méta-données 23 CU_Visualiser les méta-données 24 CU_Accéder aux lots de données 24 CU_Ajouter au panier 25 CU_Définir l extraction de données Fiche descriptive du sous-domaine Cartographie 26 Le quartier fonctionnel Visualiseur Le bloc fonctionnel Visu 27 Utilisation des normes OGC WMS et WMC 27 CU_Visualiser une carte 27 CU_Zoomer avant/arrière par pas prédéfinis 27 CU_Zoomer avant par zoom rectangle 27 CU_Zoomer par choix d une échelle 27 CU_Revenir à l'emprise initiale de la carte 27 CU_Se déplacer dans la carte (pan) 27 CU_Interrogation attributaire des couches 28 CU_Visualiser les informations de la carte (échelle, système de projection) 28 CU_Ajouter à mes Cartes favorites 28 CU_Imprimer une carte 28 CU_Sauvegarder une carte sur son poste 28 CU_Charger une carte depuis son poste Le bloc fonctionnel Couches affichées 29 Utilisation de la norme OGC WMS 29 CU_Présenter les couches affichées 29 CU_Positionner une couche dans la carte 29 CU_Rendre une couche invisible 30 CU_Rendre une couche visible 30 CU_Supprimer une couche 30 CU_Gérer l opacité de la couche 30 CU_Accéder aux informations d une couche Le bloc fonctionnel Couches disponibles 30 Utilisation de la norme OGC WMS 30 CU_Consulter les couches de la plate-forme 30 CU_Présenter les couches disponibles 31 CU_Interroger un serveur WMS 31 CU_Ajouter une couche à la carte Le bloc fonctionnel Localisation 32 Utilisation des normes et standards WFS - GéoJSON 32 CU_Se positionner par le navigateur 32 CU_Se positionner par emprises géographiques prédéfinies 32 CU_Se positionner par recherche plein texte Le bloc fonctionnel Explorateur 33 Utilisation des norme OGC 33 CU_Enregister une carte 34 CU_Interroger un serveur WFS 34

27 CU_Visualiser la structure des données associées à une couche WFS 34 CU_Mesurer une distance 34 CU_Mesurer une surface 34 CU_Importer des données tabulaires 34 Le bloc fonctionnel Styleur 35 CU_Styler une couche à partir de SLD existants 35 CU_Symboliser manuellement une couche 35 CU_Gérer les champs 35 CU_Gérer les étiquettes 35 CU_Gérer la sémiologie 36 CU_Définir les plages de visibilité de la couche Le bloc fonctionnel Requêteur 37 Utilisation de la norme OGC 37 CU_Enregistrer une couche Dessin 37 CU_Dessiner un objet géographique 38 CU_Sélectionner un objet géographique 38 CU_Modifier un objet géographique 38 CU_Effectuer une requête entre objets de couches différentes 39 CU_Saisir une requête SQL 39 CU_Créer un objet déduit 40 CU_Définir un buffer 40 CU_Supprimer un objet géographique 40 CU_Réaliser une analyse par plages de couleurs 40 CU_Réaliser une analyse par symboles proportionnels 40 CU_Réaliser une analyse par valeurs individuelles Fiche descriptive du sous-domaine Site Editorial 41 Description fonctionnelle du sous-domaine Site Editorial 41 Proposition d'organisation du site éditorial 41 Description des rubriques 41 Les rubriques publiques 42 Les rubriques privées Le bloc fonctionnel Gestion du site Le bloc fonctionnel Actualités 43 CU_Présenter les dernières actualités 43 CU_Demander un flux RSS 44 CU_Demander un flux GeoRSS Le bloc fonctionnel «Rechercher et cartographier» 44 CU_Rechercher des fiches de méta-données 44 CU_Rechercher des fiches de méta-données de cartes statiques (atlas) Fiche descriptive du sous-domaine Outils Référentiels Le bloc fonctionnel Accéder au cadastre CU_Consulter les sites sur le cadastre 49 CU_Visualiser le cadastre 49

28 CU_Consulter les données cadastrales 50 CU_Consulter son panier cadastral 50 CU_Télécharger les données cadastrales Le bloc fonctionnel Extraire des rasters CU_Extraire une zone d un raster Fiche descriptive du sous-domaine Administration Le bloc fonctionnel Administration de la plate-forme 46 CU_Créer un utilisateur 46 CU_Récupérer les utilisateurs d'un annuaire LDAP existant 46 CU_Modifier les paramètres d un utilisateur créé 46 CU_Supprimer un utilisateur 46 CU_Autoriser l accès à un serveur WMS / WFS 46 CU_Supprimer l autorisation d accès un serveur WMS / WFS 46 CU_Modifier les paramètres d un composant externe 46 CU_Créer un groupe 46 CU_Modifier un groupe 46 CU_Supprimer un groupe 46 CU_Imprimer la liste des utilisateurs 46 CU_Consulter la BAL de l administrateur 47 CU_Définir l espace disque alloué aux groupes 47 CU_Consulter les quotas disques 47 CU_Consulter les statistiques de connexions Le bloc fonctionnel Administration du catalogue 47 CU_Définir les droits des groupes 47 CU_Modifier les droits des groupes 48 CU_Définir les droits des systèmes externes 48 CU_Créer - supprimer un thème de la nomenclature interne 48 CU_Créer - supprimer un sous- thème de la nomenclature interne 49 CU_Créer une catégorie de la nomenclature ISO CU_Supprimer une catégorie de la nomenclature ISO CU_Créer une catégorie de la nomenclature INSPIRE 50 CU_Supprimer une catégorie de la nomenclature INSPIRE 50 CU_Gérer la correspondance entre nomenclatures 50 CU_Imprimer la liste des thèmes ou catégories 50 CU_Définir la liste des producteurs communs 50 CU_Définir des couvertures administratives communes 51 CU_Définir la liste des contacts communs 51 CU_Définir la taille maximale des archives téléversables 51 CU_Référencer un catalogue distant Le bloc fonctionnel Administration de la Cartographie 52 CU_Définir les droits des groupes 52 CU_Modifier les droits des groupes 52 CU_Référencer un serveur WMS distant 52 CU_Dé-référencer un serveur WMS distant 53 CU_Référencer un serveur WFS distant 53 CU_Dé-référencer un serveur WFS distant 53 CU_Référencer un serveur de noms 53 CU_Consulter les statistiques de téléchargement 54

29 CU_Définir des SLD 54 CU_Définir la liste des codes EPSG utilisables 54 CU_Définir les droits des systèmes externes 54 CU_Définir la taille limite autorisée des images WMS Le bloc fonctionnel Administration du Site Editorial 55 CU_Définir les rôles des groupes 55 CU_Modifier les rôles des groupes 55 CU_Paramétrer les dernières mises en ligne 55 Illustration de quelques cas 55 Publier un lot de données 55 Publier un lot de données vecteur 56 Consulter l atlas de cartes du site éditorial profil visiteur 56 Consulter l atlas de cartes du site éditorial profil utilisateur Les exigences non fonctionnelles Les exigences ci-dessous détaillées doivent permettre de répondre aux objectifs de l'architecture ACAI choisie pour le développement de l'application. Rappel des objectifs ACAI Portabilité "Maintenabilité", évolutivité "Réutilisabilité" Robustesse, stabilité Performance Sécurité Ergonomie Accessibilité Priorités pour le GÉOBRETAGNE Interopérabilité Performance Hébergement Utilisation

30 Pérennité Les exigences techniques Les composants Catalogue Bibliothèques JAVASCRIPT AJAX Le serveur de base de donnée Le serveur cartographique Client langage Authentification Géolocalisation Navigateur Geosource ou MdWeb2 La bibliothèque préconisée par la Maîtrise d ouvrage est Openlayers. Une liste des fonctionnalités, non exhaustive, présentées dans le tableau en annexe 5, pourra être complétée par le prestataire en fonction des besoins fonctionnels ou des évolutions technologiques. PostgreSQL et son extension Postgis Géoserver A ce jour, Geoserver n implémente pas la gestion des formats raster ECW et TIF mais ces évolutions sont prévues en Le prestataire proposera le développement de plugins. bibliothèque javascript AJAX Openlayers JAVA CAS Le prestataire pourra proposer 2 types de solutions : - l'implémentation sur la plate-forme de bases de données d'adresses comme Navtec ou TéléAtlas - l'accès à un service externe Firefox version 2.0 et supérieure Internet explorer version 7 et supérieure Exigences pour l'interopérabilité - Cf. "L'environnement technologique, ACAI et la cartographie Web" les serveurs OGC et l application implémenteront les spécifications OGC WMS, WMC, WFS, WFS-T, FEI, SLD, selon les exigences fonctionnelles souhaitées : - Dérogation ACAI

31 La spécification WMC et le format d échange JSON/GEOJSON ( ) ont fait l'objet d'une demande de dérogation aux spécifications ACAI. Les versions, les requêtes utilisées ainsi que la gestion des entrées/sorties des différentes normes sont détaillées ci-dessous. Par convention, les entrées/sorties seront positionnées côté client WEB. Pour le composant de catalogage, le prestataire implémentera la norme ISO (profil français) et sa déclinaison XML au format ISO Requêtes Requêtes OGC WMS, V1.1.1 utilisées - Getcapabilities - Getmap - Getfeatureinfo - Descripblayer - Getlegendgraphic Gestion des entrées/sorties En entrée L'application pourra recevoir en entrée des flux WMS incluant le SLD et les traiter. En sortie et dans le cas d'une requête Getmap L'application utilisera les SLD avec, si besoin, les filtres FEI (et donc GML) si besoin. La méthode de diffusions des SLD Le maître d'ouvrage a à ce jour identifié trois solutions sont : - requête WMS HTTP type GET avec SLD_BODY - requête WMS HTTP type GET avec liaison vers un fichier SLD(.xml sur le serveur) - requête WMS HTTP type POST contenant le SLD Le prestataire proposera l'alternative la plus appropriée pour respecter les contraintes de temps d'affichage en tenant compte du nombre d'objets visualisés ou des couleurs demandées. Requêtes : OGC WFS, WFS-T 1.0 (transactional) utilisées - Getfeature - Getcapabilities - DescribeFeatureType - Lockfeature - Transaction: -Insert -Delete -Update

32 Gestion des entrées/sorties En entrée : l'application pourra recevoir en entrée des flux GML ou JSON et les traiter. Sortie ou requête l'application utilisera si besoin les filtres FEI et GML avec paramétrage du format de sortie GML2,GML3, GML2-GZIP, SHAPE-ZIP ou JSON/GEOJSON en fonction des besoins. La méthode de diffusions des SLD Le prestataire proposera la méthode de diffusion POST ou GET la plus appropriée pour respecter les contraintes imposées par le maître d'ouvrage. - Spécifications OGC WMC (Web Map Context) Gestion des entrées/sorties : Entrée Le support WMC permettra à l application de visualiser des compositions locales (poste client) ou provenant de systèmes externes. Sortie L application aura la possibilité de sauvegarder des contextes (Couches, niveau de zoom,sld). - OGC Styled Layer Descriptor Specification (SLD) - OGC Filter Encoding Specification (FEI) - Geography Mark up Langage(GML) version 2.0 et supérieure Exigences sur la qualité des produits Exigences pour la fiabilité et la robustesse En cas d'anomalie (due à l'application ou à l'environnement), l'application continue à fonctionner normalement pour les autres cas d'utilisation, et en mode dégradé. L'utilisateur est prévenu du mode de résolution immédiat, moyen ou long terme Exigences pour la performance Objectifs de temps de réponse La solution proposée permettra d'atteindre les objectifs de temps de réponse attendus en tenant compte des éléments définis dans le tableau ci-dessous.

33 L'application devra permettre un déploiement sur une architecture "scalable" en fonction de la montée en charge (multiplication des serveurs si nécessaire) et pour une haute disponibilité si cela s'avère nécessaire. Régime moyen d'utilisation Régime exceptionnel d'utilisation Volume de données en stock Volume Base de données Taux de disponibilité Garantie de temps de rétablissement (GTR) Débit moyen internet au sein du ministère Durée d'affichage moyen d'une page Web contenant une carte <100 sessions de saisies/consultations par jour >100 sessions de saisies/consultations par jour 2 teraoctets 100 Mo Arrêt annuel < 15 jours 2 jours 128 Kb/s (prévision janvier 2009 au MEDAD) Voir Annexe 6 Le prestataire prendra connaissance de l'annexe correspondante. Contraintes d'affichage des couches raster L'objectif étant d accélérer l affichage des couches rasters, un système de tuilage en complément d un système de cache est souhaité par la maîtrise d'ouvrage. Il a été évalué à ½ Teraoctet par couche raster pour l étendue géographique GéoBretagne(300 Km X 300Km), sur onze niveaux de zoom. Pour chaque couche raster, les niveau de zoom seront paramétrables par l administrateur système. Toutes les dalles raster seront pré-chargées en cache en fonction des niveaux de zoom (cf. annexe 6) Traitement des Requêtes Objectif en fonction de la requête soumise ou des couches interrogées, contrôler et limiter le volume de données reçues afin de limiter le temps d exécution et le trafic réseau. Contrainte d'architecture technique : les couches vecteur seront stockées sur le serveur dans la base de données spatiales PostGIS. Seules les couches déposées en tant que couches WFS seront proposées à l utilisateur pour un traitement de requête. Les délais fixés sont définis pour un débit moyen de 128 Kb/s Contrainte d'architecture applicative : l'accès aux données stockées sur le serveur se fera par des connexions SGBD (requêtes spatiales ou alphanumériques sur la base de données PostgreSQL/PostGIS). L'objectif

34 est de pallier aux déficiences actuelles des spécifications WFS et FEI suivantes : - complexité des requêtes (ex :intersection ou requête croisée entre plusieurs couches et un objet géométrique) - optimisation des temps de réponse - limitation des filtres OGC La maîtrise d'ouvrage fait part ici d'éléments de réflexion sur la conception technique de la solution. Il appartient au candidat d'enrichir son offre par tout élément de veille technologique pertinent, permettant d'envisager d'éventuelles alternatives, et d'apporter une plus-value aux résultats et objectifs exprimés par la maîtrise d'ouvrage. Dans tous les cas, elles seront justifiées et documentées. Ceci vaut pour les requêtes spatiales et SQL Traitement des requêtes spatiales : "CU_Effectuer une requête entre objets de couches différentes" Traitement Le délai d exécution comprenant la requête sur le serveur, le téléchargement et l affichage ne devra pas excéder 5 secondes. Afin d anticiper un dépassement de temps, certaines opération doivent être effectuées avant que la requête ne soit exécutée En fonction des couches interrogées, le temps de réponse de la requête, le téléchargement et l affichage peuvent être important. Le prestataire proposera des solutions pour contrôler /limiter le volume de données reçues et ceci en fonction de la requête soumise ou des couches interrogées afin de ne pas dépasser le temps d exécution fixé Exemple de requête et de contrôle: Sélection de parcelles de la couche parcelle, intersectées avec la couche commune, la couche PPRI (inondation) et délimitée par un cercle de 700 mètres de rayon. L'emprise maximale définie en exemple pour la table parcelle est 0,75Km2, la requête est refusée et l utilisateur est averti. annexe 8. Le nombre d objets retourné serait trop important et un dépassement de délais est prévisible. Affichage Grahique Le format d export de réponse à la requête sera GeoJSON Format reconnu par la librairie Openlayers L affichage se fera au format vecteur, SVG ou VML, en fonction du navigateur. (annexe 4) Affichage alphanumérique

35 L affichage se fera dans un tableau, dans la page courrante, dans une fenêtre que l on puisse déplacer et redimensionner. (annexe 2) Interaction objet graphique et résultat alphanumérique En sélectionnant un objet graphique, retourné par la requête, la ligne correspondante du tableau est en sur-brillance (annexe 2) et inversement, quand on sélectionne un élément du tableau, l'objet graphique est en sur brillance Requête SQL CU_Saisir une requête SQL Le délai d exécution comprenant la requête sur le serveur, le téléchargement et l affichage ne devra pas excéder 5 s Afin d anticiper un dépassement de temps, certaines opérations doivent être effectuées avant l exécution de la requête. Le prestataire proposera des solutions pour contrôler /limiter le volume de données reçues et ceci en fonction de la requête soumise ou des couches interrogées afin de ne pas dépasser le temps d exécution fixé Affichage alphanumérique L affichage se fera dans un tableau, dans la page courante, dans une fenêtre que l on puisse déplacer et redimensionner. Optimisation des requêtes Postgis Optimisation des requêtes Postgis (documentation : ) Index spatiaux GIST et && Afin d optimiser les temps de réponse des requêtes sur des tables volumineuses, les GIST seront posés sur tout champ géographique. Dans le cas de certaines fonctions de PostGIS, parmi lesquelles nous pouvons citer Distance() ; WithIn(), Intersects() [...].,il est parfois nécessaire de les coupler à && (opérateur de chevauchement des étendues géographiques). En effet, celui-ci sait tirer profit des index spatiaux en interne de son implémentation. En annexe 3 un exemple de temps de réponse d une requête spatiale utilisant les index spatiaux et l opérateur

36 &&(intersection de 2 couches dont l une comporte objets et d un objet géométrique dessiné par l utilisateur). Toutes les couches intégrées dans Postgis et les requêtes sur ces tables devront suivre ce protocole : En annexe 2, un exemple d affichage du résultat d une requête spatiale. Index B-tree et R-Tree Les "B Tree" seront posés sur tout champs sollicité lors de traitements de recherche sur des identifiants (exemple : numéro INSEE). Les "R Tree" seront posés sur tout champ sollicité pour des traitements de recherche sur des valeurs numériques; ceci comprend la symbolisation par classe de valeur. Pour l ensemble des index Les index seront générés automatiquement lors de l'import de données Exigences pour l'utilisation Utilisation Cf. annexe fiche des contraintes non fonctionnelles L application est accessible internet. Elle doit être accessible via un navigateur de type Firefox ou Internet Explorer et de versions minimum respectivement 2.0 et 7. Elle est utilisée de manière de façon régulière principalement aux heures et jours ouvrables. Elle sera donc accessible sur ces périodes. Aucune pointe d utilisation n'est à ce jour identifié de façon systématique. Il est cependant possible que des procédures, opérations métiers entraînent une pointe d'utilisation de façon exceptionnelle. De la même façon, le maître d'ouvrage n'a pas identifié de période critique. Dans l'évolution du dispositif et avec le développement d'applications métiers corrélées au GÉOBRETAGNE, ces deux dernières données pourraient évoluer. Le nombre d utilisateurs simultanés (en termes de sessions parallèles) est estimé à ce jour dans une fourchette de 10 à 100. Le nombre d utilisateurs instantané maximum est estimé entre 10 et Gestion de la sémiologie Les interruptions tolérables sont de 4 heures ouvrées (j+0.5) en période normale. Une représentation des symboles, des trames et des lignes sera fournie au prestataire sous forme de fichier PDF. A partir de ces représentations "statiques", le prestataire créera une

37 bibliothèque qui sera intégrée à Géoserver. Pour gérer la sémiologie d'une couche, l'utilisateur sélectionnera dans cette bibliothèque la représentation des objets souhaitée Qualité de service et Exploitabilité Traçabilité, journalisation, supervision Toute action de l'utilisateur doit être enregistrée. Toute erreur doit être enregistrée dans les journaux avec son contexte. En mode courant, l'application ne doit pas générer de traces techniques. Capacité/Performances/volumes (disque, réseau, mémoire) L'application nécessite 2 TéraOctets d'espace disque et de 100 Go pour la base de données. Partage de ressources, bon voisinage, innocuité L'application ne cohabitera pas avec d'autres applications déployées sur le même serveur. Elle ne réservera pas de façon immodérée de ressources partagées (mémoire au travers de systèmes de cache notamment) Exigences sur le format données spatiales Les couches géographiques seront stockés en Lambert 93. Les fichiers existants en Lambert II étendu seront transformés en intégrant la grille corrective de l'ign Exigences pour l'ergonomie Utilisateurs Les utilisateurs seront de niveaux hétérogènes quant à leur maîtrise des outils informatiques. Ils sont tous accoutumés à l utilisation du poste de travail windows, du navigateur, des outils bureautiques courants. Certains peuvent maîtriser des outils SIG comme Mapinfo. Ils peuvent être décideurs, chargés d'études, techniciens L'ergonomie sera donc adapté à tous les profils professionnels. Les règles d'ergonomie ACAI s'appliqueront en tenant compte des dérogations demandées par le maître d'ouvrage. Si le prestataire juge pertinent de faire une proposition (pour le site éditorial notamment) demandant une dérogation supplémentaire, il présentera alors cette solution comme une option en précisant la plus value apportée. La qualité de l'ergonomie ne doit bien-sûr en aucun cas être traitée au détriment des autres exigences (de performances notamment).

38 Taille d'affichage Les pages contenant les cartes s'adapteront automatiquement à la résolution de l'écran ainsi la zone d'affichage de la carte prendra la dimension maximale disponible dans cette page. L'affichage se fera sans ascenseur avec navigateur "maximisé" et ses barres d outils standards. Cependant si cela s'avère nécessaire, les acteurs GéoBretagne ayant les droits nécessaires pour le faire pourront paramétrer une taille maximale d affichage de la zone cartographique. Auto complétion des champs à renseigner L auto complétion permettra d affiner la liste de recherche dans un champ de saisi au fur et à mesure des caractères rentrés Exigences sur la sécurité Authentification CAS (Central Authentification Service) Les utilisateurs seront authentifiés grâce à l'utilisation du système CAS. Il s'agit d'un système d'authentification unique (SSO) développé par l'université de Yale et implanté dans plusieurs universités et organismes dans le monde. Son mode de fonctionnement est très similaire à celui utilisé dans Cerbère, à cela près que CAS ne gère que l'authentification des utilisateurs et non leurs droits. Lorsqu'un utilisateur d'une application sécurisée par CAS se connecte à cette application, il est re-dirigé vers le serveur d'authentification CAS, indique son identifiant et mot de passe puis est re-dirigé vers l'application qui peut ensuite obtenir son identité. De nombreuses librairies clientes pour les applications ont été développées dans cadre du projet CAS, ce qui permet d utiliser ce système d authentification dans de nombreux environnements techniques L'utilisation du système CAS fait l objet d une demande de dérogation ACAI.

39 Liens utiles afin de mettre en œuvre CAS - Page d'accueil du projet CAS : - Protocole CAS : - APIs CAS disponibles : - CAS et Java : - CAS et Apache: - Présentation (en français) des architectures SSO : Accès WMS/WFS Afin de limiter le traitement aux cas d utilisation prévus dans l application, en fonctionnement normal et en tenant compte des possibilités techniques existantes, l accès direct par flux WMS et WFS sera limité par authentification. La solution technique devra être libre, reconnue et validé par la maîtrise d ouvrage. Il devra être possible à de futures applications métiers et après authentification, d utiliser tous les services et modules gérés par cette application Conversion de format Conversion de format Afin de posséder une implémentation sécurisée, la librairie GDAL (Geospatial Data Abstraction Library ) est préconisée et devra être exécutée par l intermédiaire de classes JAVA. L instruction "EXEC" ne sera pas autorisée Exigences de cycle de vie Evolutivité fonctionnelle et technique L'application doit continuer à fonctionner si les standards et normes qu'elle respecte évoluent.