Mise en place d`une infrastructure de données
publicité
Stage de fin d’étude
Master 2 Systèmes d’information géographique et gestion de l’espace,
parcours professionnel
Mise en place d’une infrastructure de données
géographiques dans la communauté d’agglomération du
Pays Viennois
Septembre 2014
Julien FRANCOIS
Maitre de stage : Jean-Luc Pontier
Professeur référent : Thierry Joliveau
Remerciements
Je tiens à remercier Jean-Luc Pontier, mon maitre de stage, pour m’avoir laissé carte
blanche pour mener à bien mon stage. Merci aussi pour son aide dans la construction de mon
rapport de stage.
Ensuite j’aimerais remercier Fabien Allamanche, pour ses précieuses aides techniques tout
au long du stage.
Mes remerciements vont aussi à tout le personnel de ViennAgglo qui a permis à mon
stage de bien se dérouler (notamment Claude Michelon, Isabelle Fontvieille et Rémi Delory de la
DSI).
Merci à toute l’équipe pédagogique du master qui m’a permis d’acquérir les compétences
pour réaliser ce stage.
Pour ces relectures, je remercie Solenn Chaudet, toujours aussi patiente.
Pour terminer, merci aux contributeurs du Google group geOrchestra qui nous ont
donné de nombreuses pistes pour résoudre nos problèmes techniques.
Sommaire
Liste des abréviations et sigles .................................................................................................................... 1
Introduction .................................................................................................................................................. 2
I. ViennAgglo ................................................................................................................................................ 4
1.1. Le territoire ....................................................................................................................................... 4
1.2. Le fonctionnement de ViennAgglo .............................................................................................. 4
1.3. Les compétences .............................................................................................................................. 5
1.4. Le service SIG .................................................................................................................................. 6
II. Pourquoi une plateforme de catalogage et d’échange à ViennAgglo .............................................. 8
2.1. Centraliser et connaitre les données ............................................................................................. 8
2.1.1. Centralisation/homogénéisation des données géographiques ......................................... 8
2.1.2. Documentation........................................................................................................................ 8
2.1.3. Connaitre/faire connaitre ...................................................................................................... 9
2.2. Réponse à INSPIRE ....................................................................................................................... 9
2.2.1. INSPIRE KEZAKO ? ........................................................................................................... 9
2.2.2. INSPIRE et les EPCI ........................................................................................................... 10
2.2.3. La plateforme de catalogage et de partage, une réponse à INSPIRE ............................ 11
2.3. Augmenter l’autonomie des services métier/communes et des partenaires ......................... 11
2.3.1. Les services métier/communes........................................................................................... 11
2.3.2. Les structures partenaires..................................................................................................... 12
2.4. Ouverture des données au public ................................................................................................ 12
2.5. Complémentaire à DynMAP et outils d’observatoires ............................................................ 13
2.5.1. DynMap .................................................................................................................................. 13
2.5.2. Outils d’observatoire ............................................................................................................ 14
2.6. Imbrication du catalogue avec les autres plateformes .............................................................. 14
III. Solution technique : mise en place et configuration ....................................................................... 16
3.1. GeOrchestra ................................................................................................................................... 16
3.1.1 Choix de la solution geOrchestra......................................................................................... 16
3.1.2 Présentation de la solution .................................................................................................... 16
3.2. Prises en main des outils ............................................................................................................... 17
3.2.1. Prérequis ................................................................................................................................. 18
3.2.2. geOrchestra ............................................................................................................................ 18
3.3. Configuration geOrchestra ........................................................................................................... 19
3.3.1. Configuration générale ......................................................................................................... 19
3.3.2. Site web................................................................................................................................... 20
3.4. Dimensionnement et architecture du serveur de production ................................................. 20
3.4.1. Architecture de la solution ................................................................................................... 20
3.4.2. Matériel / Dimensionnement / Architecture Système .................................................... 25
3.5. Sécurité ............................................................................................................................................ 27
IV. Production, maintenance et transfert de connaissances ................................................................ 30
4.1. Mise en production........................................................................................................................ 30
4.1.1. Licence, droits d’accès .......................................................................................................... 30
4.1.2. Geoserver ............................................................................................................................... 31
4.1.3. Geonetwork ........................................................................................................................... 33
4.2. Maintenance ................................................................................................................................... 34
4.2.1 Détecter des défaillances ....................................................................................................... 34
4.2.2 Redémarrer les services ......................................................................................................... 34
4.2.3. Compilation des sources ...................................................................................................... 35
4.2.4. Processus de mise à jour ...................................................................................................... 35
4.3. Documentation utilisateur ............................................................................................................ 35
4.3.1. Sensibiliser à la géomatique ................................................................................................. 35
4.3.2. Documentation technique ................................................................................................... 35
V) Perspectives, évolution......................................................................................................................... 38
5.1. Trop complexe pour une majorité ? ........................................................................................... 38
5.2. Le réseau internet........................................................................................................................... 39
5.2.1. La fibre.................................................................................................................................... 39
5.2.2. Hébergement externe ........................................................................................................... 39
5.3. Automatiser l’administration ........................................................................................................ 40
5.4. Métadonnées .................................................................................................................................. 40
Conclusion ................................................................................................................................................... 42
Bibliographie ............................................................................................................................................... 44
Listes des figures......................................................................................................................................... 45
Table des annexes....................................................................................................................................... 46
Liste des abréviations et sigles
ALUR : Accès au Logement et un Urbanisme Rénové
AJP : Apache JServ Protocol
BDD : Base De Données
CAS : Central Authentication Service
CGI : Common Gateway Interface
CMS : Content Management System (Système de gestion de contenu)
DGFiP : Direction Générale des Finances Publiques
DMZ : Demilitarized Zone (Zone démilitarisée)
DSI : Direction des Systèmes d’Information
EPCI : Établissement Public de Coopération Intercommunale
HA : High Availibility (Haute disponibilité)
HTTP : HyperText transfert Protocol
IDG : Infrastructure de Données Géographiques
INSPIRE : Infrastructure for Spatial Information in Europe
IP : Internet protocole
JEE : Java Enterprise Edition
LDAP : Lightweight Directory Access Protocol
Mbps : Megabits per second
OFPI : Observatoire Foncier Partenarial de l’Isère
OGC : Open Geospatial Consortium
OS : Operating System (Système d’exploitation)
PIGMA : Plateforme d’Information Géographique Mutualisée en Aquitaine
PLU : Plan Local d’Urbanisme
PLUi : Plan Local d’Urbanisme intercommunal
RAM : Random Access Memory
SAFER : Sociétés d'Aménagement Foncier et d'Etablissement Rural
SIG : Système d’Information Géographique
SPOF : Single Point Of Failure (Point individuel de défaillance)
REST : Representational State Transfer
SSH : Secure SHell
SSL : Secure Sockets Layer
VM : Virtual Machine (Machine Virtuelle)
WFS : Web Feature Service
WMS : Web Map Service
-1Julien FRANCOIS - 31/07/2014
Introduction
En parallèle des technologies web, les outils géomatiques ont subi une évolution
exponentielle durant les dernières années. Le développement de l’informatique et plus
particulièrement celui des technologies liées au web permettent d’aller de plus en plus loin dans
les processus de collecte, d’analyse et de diffusion de l’information géographique. Ce dernier
enjeu est devenu une des problématiques principales de la géomatique actuelle. Pour cadrer cette
problématique, la directive européenne INSPIRE a été publié en 2007. Elle vise à promouvoir le
partage des données par la mise en place de norme d’interopérabilité, la documentation
systématique et la mise en place d’outils de catalogage et de diffusion.
Au-delà des obligations légales, ViennAgglo souhaite depuis plusieurs années mettre en
place un catalogue et une plateforme de partage des données qu’elle possède, et ce pour plusieurs
raisons qui seront évoquées au cours de ce rapport. Au terme d’une étude interne, c’est la
solution geOrchestra qui a été retenu. Le temps de mise en place d’une telle solution ne pouvant
pas être absorbé par l’équipe en place, ViennAgglo a donc envisagé deux possibilités, l’aide d’un
prestataire de services ou le recrutement d’un stagiaire de niveau ingénieur. Pour des raisons
économiques c’est cette deuxième option qui a été retenue. J’ai donc rejoint l’équipe de
ViennAgglo avec comme mission de mettre en place la solution geOrchestra au sein de
l’agglomération.
Ce rapport s’articule autour de plusieurs parties. Les deux premières parties présentent le
contexte du stage, à savoir la structure d’accueil, ViennAgglo, et les enjeux du stage. La troisième
partie décrit la mise en place de la solution technique. Ensuite la quatrième s’attarde sur les
éléments liés à la mise en production de la plateforme et enfin la dernière partie présente les
perceptives ouvertes par le stage.
-2Julien FRANCOIS - 31/07/2014
-3Julien FRANCOIS - 31/07/2014
I. ViennAgglo
1.1. Le territoire
La Communauté d’Agglomération du Pays Viennois est un Établissement Public de
Coopération Intercommunale (EPCI). Née en 2002 de la transformation de l’ancien District de
Vienne, qui regroupait 7 communes, l’Agglomération est aujourd’hui composée de 18 communes,
17 en Isère et une dans le Rhône, et compte environ 70 000 habitants.
Figure 1 : Carte de présentation de ViennAgglo (Source : plaquette d’information ViennAgglo)
1.2. Le fonctionnement de ViennAgglo
Un bureau communautaire
Le bureau de la Communauté d’agglomération du Pays Viennois est composé du
Président, des 9 Vice-présidents et de 9 conseillers délégués. Le bureau communautaire est un
lieu d’information et d’orientation, il participe au processus d’élaboration de l’ordre du jour du
conseil. Le bureau examine et arbitre les projets présentés par la communauté.
-4Julien FRANCOIS - 31/07/2014
Un conseil communautaire
La Communauté d’agglomération du Pays Viennois est administrée par un conseil
communautaire, composé de conseillers élus des 18 communes membres. Le conseil
communautaire délibère et vote les projets qui lui sont soumis par les différentes commissions.
Le conseil communautaire de ViennAgglo est ainsi composé de 54 conseillers dont les 9 Viceprésidents et 9 conseillers délégués
360 agents
Les services de la Communauté d’Agglomération sont répartis entre 3 pôles (le Pôle
Ressources dit PRESS, le Pôle Stratégie et Développement Territorial dit PSDT, le Pôle
Ingénierie et Technique Urbaine dit PITU) et la Direction Générale des Services (DGSRV).
1.3. Les compétences
La communauté d’agglomération exerce en lieu et place des communes qui la composent
des compétences obligatoires, optionnelles et complémentaires, dans la limite, pour la plupart
d’entre elles, de l’intérêt communautaire.
Les compétences obligatoires :
o Développement économique
o Aménagement de l’espace communautaire
o Équilibre social de l’habitat
o Politique de la ville
Les compétences optionnelles :
o Création ou aménagement et entretien de voirie d’intérêt communautaire
o Protection et mise en valeur de l’environnement et du cadre de vie
o Construction, aménagement, entretien et gestion d’équipements culturels et
sportifs d’intérêt communautaires
o Aménagement du territoire
Les compétences facultatives
o Environnement
o Transport et déplacements
o Développement touristique
o Rayonnement communautaire
o Action sociale d’intérêt communautaire
-5Julien FRANCOIS - 31/07/2014
o Autres domaines (Informatique des écoles, gestion des aires d’accueil des gens du
voyage)
1.4. Le service SIG
Le service SIG et observatoires de ViennAgglo est combiné avec le service Foncier et
sous la direction de l’Aménagement urbain.
Moyens humain
Deux personnes composent le service SIG :
Jean-Luc Pontier, Responsable du service SIG-Foncier
Fabien Allamanche, Géomaticien
Moyens matériel
Toutes
les
données
du
service
sont
stockées
et
gérées
sous
une
base
PostgreSQL/PostGIS, hébergée sur les serveurs de ViennAgglo. Tous les services de ViennAgglo
ont accès aux données via le webSIG DynMAP. Les logiciels SIG utilisés sont QGIS et Cadcorp
SIS. Concernant le matériel mis à ma disposition, j’ai travaillé sur un Dell Optiplex 780 (6Go
RAM, Intel Core 2 Duo, 110Go Disque dur) ainsi que sur des serveurs virtuels montés par le
service informatique.
-6Julien FRANCOIS - 31/07/2014
-7Julien FRANCOIS - 31/07/2014
II. Pourquoi une plateforme de catalogage et
d’échange à ViennAgglo
2.1. Centraliser et connaitre les données
La mise en place d’un catalogue permet à la structure concernée de centraliser,
documenter et partager toutes ses données.
2.1.1. Centralisation/homogénéisation des données géographiques
D’un point de vue interne, la centralisation des données est très importante, elles sont en
effet souvent réparties sur les postes personnels ou sur différents serveurs dans différents formats
et différentes projections. Un projet comme la mise en place d’un catalogue permet de les
homogénéiser et de les rassembler. A ViennAgglo, la centralisation est déjà très bien faite
puisqu’elles sont stockées sur un serveur de base de données PostgreSQL/PostGIS (en interne)
avec des projections homogènes et légales : Lambert 93 cc45 pour les données locales (Echelle
EPCI, Département) ou Lambert 93 pour les données générales (Région, France). Des
conventions de nommage des couches sont utilisées.
2.1.2. Documentation
En revanche, leur documentation n’a pas encore été faite. La création de métadonnées est
devenue obligatoire avec la directive INSPIRE (cf 2.2. Réponse à INSPIRE). La mise en place du
catalogue doit permettre une saisie simplifiée et un catalogage des métadonnées. La saisie des
métadonnées doit répondre à certains standards (INSPIRE propose un standard). Les
métadonnées permettent de connaitre la donnée concernée via de nombreux attributs tels que :
Le nom et la description synthétique des données
Les liens d’accès à la données (flux WMS, WFS ou URL)
Les dates liées à la donnée (Création, mise à jour, publication, etc)
Des mots clés
L’emprise géographique, le système de coordonnées de référence.
Les points de contact pour la données (gestionnaire, auteur, etc)
Les contraintes d’accès et d’utilisation
Une fiche de métadonnées peut contenir potentiellement plus de 100 champs mais une
trentaine sont obligatoire pour répondre à la directive INSPIRE
-8Julien FRANCOIS - 31/07/2014
Les catalogues disponibles sur le marché permettent de répondre à ces standards en
proposant des modèles de saisie et des fonctions de vérification et de validation.
2.1.3. Connaitre/faire connaitre
La mise en place du catalogue permettra au service SIG de faire un point sur les données
qu’il possède, de connaitre son patrimoine. Cette mise au point pourra permettre de relancer
certains projets en collaboration avec les services métier concernés et ainsi de mettre en valeur les
données stockées. En effet, certaines informations présentes dans la base ne sont pas utilisées par
méconnaissance de leur existence. On pourra ainsi contacter le service qui avait commandé
l’acquisition de cette donnée et savoir s’il souhaite la mettre à jour, l’utiliser, la diffuser ou
l’abandonner. Cette relance des services s’inscrit dans une volonté d’impliquer, d’associer et de
faire connaitre le service SIG dans les différents projets métier.
2.2. Réponse à INSPIRE
2.2.1. INSPIRE KEZAKO ?
Tiré du site inspire.ign [IGN, 2014] :
« La directive INSPIRE, élaborée par la Direction générale de l'environnement de la Commission
européenne, vise à établir en Europe une infrastructure de données géographiques pour assurer l’interopérabilité
entre les bases de données et faciliter la diffusion, la disponibilité, l'utilisation et la réutilisation de l’information
géographique en Europe. » [IGN, 2014]
La directive INSPIRE s’appuie sur plusieurs principes :
Les données géographiques doivent être collectées une seule fois afin d'éviter la
duplication, puis stockées, mises à disposition et actualisées par l'autorité la plus
compétente. (principe de subsidiarité).
Il doit être possible de combiner facilement et de manière cohérente des
informations géographiques provenant de différentes sources à travers l’Europe,
et de les partager entre différents utilisateurs et applications.
Une information collectée par une autorité publique doit pouvoir être partagée
par l’ensemble des autres organismes publics, quel que soit leur niveau
hiérarchique ou administratif, par exemple des données de détail pour des
enquêtes fines, et des informations générales pour des sujets stratégiques.
-9Julien FRANCOIS - 31/07/2014
L’information géographique doit être disponible dans des conditions qui ne
fassent pas indûment obstacle à une utilisation extensive.
Il doit être facile de connaître quelles sont les informations géographiques
disponibles, à quels besoins particuliers elles peuvent répondre, et sous quelles
conditions elles peuvent être acquises et utilisées.
La réponse à cette directive se fait par :
La création de métadonnées : elles sont la porte d'entrée de l'infrastructure
puisqu'elles permettent de connaître les données et les services disponibles ainsi
que leurs utilisations possibles,
La mise à disposition des données géographiques : elles doivent être disponibles
dans des formats et des structures harmonisés afin d'en faciliter l'utilisation par
tous,
Les services en ligne : toutes les données et métadonnées doivent être accessibles
via Internet, vecteur privilégié d'échange,
Le partage entre autorités publiques : les principes d’échange, de tarification et les
conditions d’utilisation doivent faciliter l’accès aux données et aux services en
ligne,
La mise en place de mécanismes de coordination et de suivi de la directive : il
s'avère nécessaire de mettre en place des structures de coordination tant des
contributeurs que des utilisateurs.
Toutes les données ne sont pas concernées par cette directive, les thèmes concernés sont
énumérés en annexe de la directive.
2.2.2. INSPIRE et les EPCI
L’article L 127 - 1 précise qu’INSPIRE « est applicable aux séries de données
géographiques détenues par une commune ou au nom de celle-ci, uniquement si des dispositions
législatives en imposent la collecte ou la diffusion ». Pour l’essentiel, les communes ne sont
concernées que pour leur document d’urbanisme : PLU (plan local d'urbanisme), POS (anciens
plans d’occupation des sols), ou carte communale. Les EPCI détenant leurs prérogatives des
communes : ils sont soumis à INSPIRE de la même façon que les communes. De plus, avec la loi
ALUR, le PLU devient PLUi (sauf si un quart des communes représentant au moins 20 % de la
population s’y oppose), ce sont donc les EPCI qui récupèrent la compétence PLU.
- 10 Julien FRANCOIS - 31/07/2014
ViennAgglo est donc concernée partiellement par la directive INSPIRE. En revanche,
pour favoriser les échanges de données, il convient de respecter les normes imposées par
INSPIRE même si ce n’est pas une obligation législative. L’amélioration des échanges de données
passe par l’utilisation de standards d’interopérabilité qui se présentent sous la forme de format ou
de services répertoriés par des organismes comme Open Geospatial Consortium.
L’interopérabilité est la capacité des systèmes à communiquer, à échanger des données, à
"travailler" ensemble, sans que l’utilisateur ait besoin de connaître les caractéristiques spécifiques à
chaque système. L’interopérabilité est basée sur l’utilisation de standards définissant les interfaces des
composants des systèmes. Une application connaissant les interfaces standards est capable d’utiliser
n’importe quel composant respectant ces standards. [OGC, 2014]
2.2.3. La plateforme de catalogage et de partage, une réponse à
INSPIRE
Grâce aux services qu’elle propose, la plateforme permet d’apporter une réponse à la
directive INSPIRE. Pour reprendre les points énumérés ci-dessus, la plateforme permet :
De créer et diffuser des métadonnées « INSPIRO-compatible » via un catalogue
De mettre à disposition les informations géographiques en téléchargement ou
sous forme de services web (WMS, WFS, etc) sous plusieurs formats.
De conserver le lien entre les données et les métadonnées.
De centraliser les données.
2.3. Augmenter l’autonomie des services métier/communes et des
partenaires
2.3.1. Les services métier/communes
Actuellement, à ViennAgglo, seul le service SIG a accès aux données brutes. Aucun
personnel n’a de logiciel permettant la consultation de celles-ci. En revanche, tout le personnel
(technicien et mairie) a accès au WebSIG DynMAP pour créer des cartes thématiques. Ces cartes
(mise en forme, couches, etc) sont déjà préconfigurées par le service SIG. La création de cartes
spécifiques passe donc par le service SIG. DynMAP s’apparente plus à un logiciel métier (Voir
2.5. Complémentaire à DynMAP). La mise en place d’une plateforme permettra de partager des
cartes statiques déjà produites par le service SIG. Les agents pourront aussi directement fournir
aux partenaires externes l’adresse de la plateforme pour qu’ils puissent récupérer les données dont
ils ont besoin.
- 11 Julien FRANCOIS - 31/07/2014
2.3.2. Les structures partenaires
ViennAgglo est régulièrement amenée à travailler avec des structures extérieures.
Aujourd’hui, toutes les demandes de données géographiques passent par le service SIG. Le temps
consacré pour les extraire et les élaborer, en vue de les transmettre, est considérable. La
plateforme permettra de répondre à cette demande des partenaires.
De plus, du côté des partenaires, la présence du catalogue leur permettra de connaitre
toutes les données disponibles et de choisir les plus pertinentes pour leurs études. La mise à
disposition de service d’accès (WMS et/ou WFS) permet de distribuer des données toujours
actualisées. Ainsi, la structure partenaire peut entrer une fois l’adresse du flux dans son logiciel
SIG et n’a plus à se préoccuper de la validité des données. L’utilisation de flux évite aussi le
stockage en local pour les structures partenaires.
2.4. Ouverture des données au public
L’ouverture des données (Open Data) connait un essor considérable ces dernières années.
Ainsi, différentes structures mettent à disposition leurs données sans contrepartie financière. Le
citoyen a donc accès librement aux données produites et mises à disposition par les collectivités.
Cette libération permet de valoriser l’information et peut contribuer à une meilleure transparence
du service public vis à vis du citoyen.
Les données géographiques sont spécifiques et sont souvent stockées dans des formats
inconnus du grand public. En effet, si on permet aux citoyens de télécharger une donnée au
format WMS ou Shapefile, celui-ci ne saura probablement pas comment la visualiser ni même ce
qu’elle signifie. Il faut donc permettre la visualisation directe de ces données dans un visualiseur
cartographique. Avec Google Maps ou Geoportail, les gens commencent à être habitués à ces
types d’interfaces cartographiques.
Aussi l’Open Data peut permettre de valoriser l’information géographique stockée par
ViennAgglo. Grâce aux données géographiques gratuites, certaines personnes peuvent créer, par
exemple, des applications mobiles ou en ligne (Ou garer mon vélo à ViennAgglo ? Gestion de
l’assainissement, offre des transports publics, etc). Pour favoriser l’innovation, certaines
collectivités (CU Strasbourg1, CU Toulouse2, etc.) organisent même des concours de création
d’application à partir des données disponible sur leur portail Open Data.
1
2
http://www.strasbourg.eu/ma-situation/professionnel/open-data/concours-applications-open-data
http://data.toulouse-metropole.fr/concours-opendata
- 12 Julien FRANCOIS - 31/07/2014
Enfin, en consultant les données, les citoyens pourront prendre connaissance des projets
et des actions de ViennAgglo. Ainsi, à partir de la participation du public, de nouveaux jeux de
données seront ajoutés à la base de ViennAgglo et ceux existants pourront être complétés et mis
à jour. On s’oriente ici vers des démarches participatives/collaboratives qui sont une des
orientations que la géomatique est en train de prendre avec un citoyen au cœur des changements
territoriaux, elle va contribuer à la participation et au débat citoyen.
2.5. Complémentaire à DynMAP et outils d’observatoires
2.5.1. DynMap
DynMAP est un logiciel métier dont la vocation n’est pas la diffusion ou le catalogage des
données. C’est un logiciel interne à ViennAgglo : accessible par les services de la communauté
d’agglomération, par les communes et certains partenaires mais pas par la population. La
plateforme, quant à elle, est ici pour répondre à la fois à une volonté de partager, d’ouvrir et de
valoriser les données et à des exigences nationales et européennes. DynMAP sera donc toujours
présent et permettra aux agents de continuer à alimenter les bases de données (éclairage public,
signalisation verticale, voirie, etc.). Actuellement avec la version 8 de DynMAP, toutes les
données doivent être stockées sur les serveurs DynMAP pour pouvoir être utilisées. Ceci
implique un doublon de toutes les données entre les serveurs de ViennAgglo et le serveur de
DynMAP. Les mises à jour entre les bases sont faites manuellement. Avec l’arrivée prochaine de
la version 9, DynMAP permettra de se connecter directement à une base PostgreSQL : « Dans sa
nouvelle version majeure 9, DynMAP franchira un nouveau cap très important dans son processus d’ouverture.
Business Geografic proposera en effet une connexion directe entre DynMAP et les principales bases de données
spatiales du marché » [DynMAP, 2014]. Ainsi seule la base de données de ViennAgglo sera
maintenue et elle sera donc toujours à jour. La figure suivante résume la complémentarité et
l’interaction qu’ont DynMAP et la plateforme.
- 13 Julien FRANCOIS - 31/07/2014
Catalogue & plateforme
Figure 2 : Complémentarité DynMAP/geOrchestra
geOrchestra est la solution technique retenue pour mettre en place la plateforme.
geOrchestra est présentée dans la partie III
2.5.2. Outils d’observatoire
Dans le cadre de l’observation des politiques publiques, ViennAgglo doit réaliser des
observatoires et souhaite se doter d’un outil le permettant. Grâce aux partenariats avec l’OFPI
et la SAFER-RA, les outils en ligne Geoclip et VigiFoncier sont d’ores et déjà disponibles. Ils
proposent des analyses thématiques et des indicateurs à partir de données issues de l’INSEE, de
la DGFIP et de PERVAL (base de données sur l’immobilier remplie par les notaires) entre
autres. L’objectif est, comme pour DynMap, différent de celui de la plateforme. En revanche, la
plateforme permettra de cataloguer le résultat des observatoires et d’accéder aux outils cités
précédemment.
2.6. Imbrication du catalogue avec les autres plateformes
L’importance d’effectuer un catalogage a déjà été argumentée dans les paragraphes
précédents. Chaque structure publique ou privée qui créée, stocke ou encore diffuse de
- 14 Julien FRANCOIS - 31/07/2014
l’information géographique devrait avoir un catalogue. Les EPCI sont particulièrement concernés
car ils sont de gros producteurs de données. En 2011, l’Association des Ingénieurs Territoriaux
de France a lancé son sondage « INSPIRE : catalogage des données géographiques en France ».
Le sondage a été fait auprès de 117 organismes (Conseils Régionaux, services de l’Etat, Conseil
Généraux, EPCI, etc.) dont 35 EPCI.
Ci-dessous le résultat du sondage de l’avancement des projets de catalogage spécifique
aux EPCI.
Au stade de réflexion
17%
20%
Cadré mais pas encore effectif
17%
Effectif
46%
Suspendu, a l'arret
Figure 3 : Etat d’avancement des projets de catalogue dans les EPCI
Une des fonctions principales des catalogues est de pouvoir se connecter entre eux. Or,
un des objectifs de la directive INSPIRE est d’éviter de recréer de la donnée existante. En se
connectant à d’autres catalogues on peut accéder à toutes les données d’une structure. C’est ce
qu’on appelle le moissonnage (cf. définition ci-dessous). Notre catalogue local pourra donc être
accessible et « moissonable » à partir de n’importe quelle autre plateforme, il en sera de même
dans le sens inverse.
Le moissonnage et un mécanisme permettant de collecter des métadonnées sur un catalogue distant
et de les stocker sur le nœud local pour un accès plus rapide. Cette action de moissonnage est une
action périodique, par exemple, une fois par semaine. Le moissonnage n’est pas un import simple
: les métadonnées locales et celle du catalogue distant sont synchronisées. En effet, un catalogue est
capable de découvrir quelles sont les métadonnées ayant été ajoutée, supprimée ou mise à jour dans
le nœud distant. [Geonetwork, 2014]
- 15 Julien FRANCOIS - 31/07/2014
III. Solution technique : mise en place et
configuration
3.1. GeOrchestra
3.1.1 Choix de la solution geOrchestra
Au terme d’une pré-étude réalisée avant la publication de l’offre de stage, ViennAgglo
avait choisis d’utiliser la solution geOrchestra. Cette solution a été retenue pour différents points :
L’entreprise Camptocamp est porteuse du projet (gage de qualité).
Le projet geOrchestra est un projet vivant (site web, développeurs de
Camptocamp réactifs, plusieurs groupes Google existent et sont très actifs)
Projet libre (licence GNU GPL) donc réutilisable gratuitement.
Plusieurs collectivités ont déjà mis en place geOrchestra.
Réponse aux besoins de ViennAgglo.
3.1.2 Présentation de la solution
geOrchestra est un ensemble de logiciels qui forment ce qu’on appelle une infrastructure
de données spatiales. Cette solution a été développée par la société Camptocamp dans le cadre de
la mise en place de GéoBretagne financée par la région Bretagne et l’Etat. La structure en brique
logiciel permet d’utiliser ou non chaque logiciel sans nuire au fonctionnement des autres. Les
fonctionnalités principales proposées par cette solution sont les suivantes :
1
Un catalogue de données (Geonetwork)1
Un extracteur de données (Extractorapp)
Un visualiseur cartographique (Mapfishapp)
Un serveur cartographique (Geoserver)
Un logiciel de gestion du cache (Geowebcache)
Une gestion des droits d’utilisateur (ldapadmin)
Un service d’authentification (CAS)
Un proxy interne basé sur Spring security (ROOT)
Statistiques de consultation et de téléchargement (Analytics & Downloadform)
Les noms entre parenthèses correspondent au nom du composant dans geOrchestra
- 16 Julien FRANCOIS - 31/07/2014
Exemple de plateforme basée sur geOrchestra : GeoBretagne1, PIGMA2, GéoPicardie3,…
Solutions similaires basées sur une solution technique autre que geOrchestra :
Prodige : En France : GeoRhoneAlpes4, GeoBourgogne5, GeoNormandie6.
EasySDI7 : En France : CRIGEOS8 (Centre Régional de l’Information Géospatiale),
OPCC (Observatoire Pyrénéen du Changement Climatique)
Cette solution peut donc supporter de très gros projets (à l’échelle de région), mais peut
aussi s’adapter à des projets moins importants.
Les sources de geOrchestra sont accessibles via un dépôt GitHub.
3.2. Prises en main des outils
Dans cette partie je présenterais la stratégie mise en place pour obtenir une installation
geOrchestra stable et fonctionnelle. En effet, plusieurs tests sur des machines virtuelles sont
nécessaires avant de comprendre les différents mécanismes de fonctionnement de cet outil.
De nombreux termes informatiques seront cités ici et de nombreux ne seront pas expliqués
si ils ne sont pas indispensables à la compréhension du rapport. En général, les explications
sur les concepts d’informatiques seront présentées dans des cadres identiques à celui-là.
« Une machine virtuelle (anglais virtual machine, abr. VM) est une illusion d'un appareil
informatique créée par un logiciel d'émulation. Le logiciel d'émulation simule la présence de
ressources matérielles et logicielles telles que la mémoire, le processeur, le disque dur, voire le
système d'exploitation et les pilotes, permettant d'exécuter des programmes dans les mêmes
conditions que celles de la machine simulée » [WIkipedia]
http://cms.geobretagne.fr/
http://www.pigma.org/
3 http://www.geopicardie.fr/portail/
4 http://www.georhonealpes.fr/accueil
5 http://www.geobourgogne.fr/accueil
6 http://www.geonormandie.fr/accueil
7 http://www.crigeos.org/
8 http://www.opcc-ctp.org/
1
2
- 17 Julien FRANCOIS - 31/07/2014
3.2.1. Prérequis
Avant même de comprendre comment fonctionne geOrchestra, il a fallu assimiler des
concepts sur le fonctionnement des serveurs. Pour ce faire, j’ai utilisé des machines virtuelles, ce
qui permet de faire des tests facilement et sans risques (On peut sauvegarder l’état de la machine
à un instant t et revenir à cet état plus tard).
Apport des machines virtuelles :
-
Configurer la distribution Debian de Linux. Nous avons retenu Debian pour nos
serveurs puisque c’est lui qui est préconisé pour installer geOrchestra. En règle
générale, c’est aussi la distribution par excellence installée sur les serveurs web.
-
Prendre en main les commandes Debian. Aucune interface graphique n’est installée,
tout est donc réalisé en ligne de commande Shell.
-
Installer et configurer les logiciels prérequis à l’installation de geOrchestra (Tomcat,
Apache 2, LDAP, PostgreSQL, JAVA, GDAL/OGR)
-
Assimiler les notions de protocoles de communication et de transfert de données
(HTML, SSL, SSH, AJP, etc)
-
Assimiler les notions d’identifiant serveur (Nom d’hôte, ports d’écoute, IP)
3.2.2. geOrchestra
Une fois que les bases pour accueillir geOrchestra sont prêtes, on passe à son installation.
Les sources de geOrchestra sont disponibles sur un dépôt GitHub (service web d'hébergement et
de gestion de développement de logiciels, utilisant le logiciel de gestion de versions Git). Les
premières installations se sont faites aussi sur des machines virtuelles pour bien comprendre le
fonctionnement.
Apport des machines virtuelles :
-
Prendre en main la compilation de geOrchestra avec le logiciel Apache Maven (Outils
pour produire un logiciel à partir de ses sources, en optimisant les tâches réalisées à
cette fin et en garantissant le bon ordre de fabrication)
-
Comprendre comment s’imbriquent les différents composants de geOrchestra
-
Installer geOrchestra
-
Configurer geOrchestra (Voir 3.3. Configuration geOrchestra)
-
Tester des architectures logicielles pour les serveurs de production (Voir 3.4.
Dimensionnement et architecture du serveur de production)
- 18 Julien FRANCOIS - 31/07/2014
3.3. Configuration geOrchestra
Dans cette partie, je reviens sur les adaptations que nous avons faites pour que
geOrchestra soit parfaitement intégrée au contexte de ViennAgglo.
3.3.1. Configuration générale
Pour simplifier la configuration, les développeurs de geOrchestra ont rassemblé les
fichiers de configuration dans un dossier. On peut créer plusieurs dossiers qui seront appelés
« profil de configuration ». Par défaut, un dossier « template » est livré avec les sources. Les
profils de configuration sont composés :
D’un fichier « shared.maven.filters » qui permet de rassembler tous les paramètres
commun à l’application. On y retrouve par exemple : la langue, les identifiants de
connexion aux bases de données, la hauteur de la barre des menus, etc.
De sous-répertoires dont les noms correspondent à chaque module de
geOrchestra (Mapfish, Geoserver, ldapadmin, etc). Ces dossiers contiennent des
fichiers de configuration spécifiques à chaque module.
Exemple d’éléments configurés :
La barre de navigation (header) qui s’adapte à l’appareil utilisé (smartphone,
ordinateur, etc.) et à l’utilisateur connecté.
Ecran d’ordinateur, administrateur
Ecran d’ordinateur, utilisateur anonyme
Ecran de smartphone, utilisateur anonyme
Figure 4 : Barre de navigation de l'application
Les réponses mail automatique.
Les serveurs WMS et WFS accessibles par défaut dans le visualiseur et
l’extracteur.
Les redirections du security-proxy.
Création de contexte de cartes par défaut.
- 19 Julien FRANCOIS - 31/07/2014
3.3.2. Site web
L’intégration de la plateforme dans un site web qui lui est dédié est une étape importante.
C’est la première page qui sera accessible par le client lorsque celui-ci accède au site. Les
principales plateformes ont toutes une interface d’accueil qui présente le projet, les actualités, les
groupes de travail ou encore les ressources d’aide.
Cette partie a été réalisée par Fabien Allamanche qui a utilisé le Framework Bootstrap
pour concevoir le modèle du site couplé à Wordpress pour l’administrer (ajout de billet, etc). Le
site se présentera sous forme d’une page unique.
3.4. Dimensionnement et architecture du serveur de production
La question du dimensionnement et de l’architecture du/des serveur(s) est très
importante dans ce genre de projet. De nombreuses questions doivent être posées pour définir la
meilleure solution, celle qui sera capable de répondre aux différentes requêtes des utilisateurs.
Cette réflexion est menée conjointement avec la DSI. La première question à se poser est
l’hébergement : Où sera hébergée notre plateforme ? Nous avons choisis l’hébergement en
interne. En effet le matériel informatique déjà présent à l’agglomération est suffisant pour notre
plateforme, aucun surcoût matériel n’est donc engagé. De plus, le parc disponible possède les
ressources nécessaires pour permettre une éventuelle évolution de la plateforme. La question de
la bande passante sera aussi évoquée puisque c’est souvent le facteur limitant des applications en
réseau. Je présenterais d’abord l’architecture logicielle que nous avons retenue et ensuite
l’architecture physique et le dimensionnement qui en découlent.
3.4.1. Architecture de la solution
Pour choisir la bonne architecture, une multitude de questions ont été posées. Je vais
commencer par présenter l’architecture que nous avons retenue (Figure 5) et succinctement le
fonctionnement lors d’une requête émise par le client (Figure 6). Ensuite, j’expliquerais ses
qualités et pourquoi elle a été choisie. L’objectif est d’obtenir une architecture dite HA (High
availability). On pourra trouver en Annexe 1 l’évolution de l’architecture au fil du stage.
Tomcat est un serveur d’applications, il permet donc de faire fonctionner des applications web
(abrégées webapps) sur un serveur. Celles-ci génèrent des réponses aux requêtes du client.
- 20 Julien FRANCOIS - 31/07/2014
LB
LB : Load balancing
Figure 5 : Architecture finale retenue
Figure 6 : Fonctionnement de la solution
- 21 Julien FRANCOIS - 31/07/2014
Une répartition sur deux serveurs et 3 instances.
Pour augmenter la stabilité de l’application et répartir la charge, il est souvent conseillé de
répartir les différentes applications qui composent geOrchestra sur plusieurs « instances » de
Tomcat. Ceci a aussi l’avantage de favoriser le débogage puisqu’on isole les applications. Les
instances peuvent être réparties selon deux concepts expliqués dans l’encadré ci-dessous
[LANGLET, 2008] :
Les deux concepts de répartition des instances de Tomcat :
Répartition verticale : Toutes les instances sont sur le même serveur. On isole ainsi les
applications sujettes aux défaillances dans leur machine virtuelle Java (chaque instance fait
tourner sa propre machine virtuelle Java). Si cette application perturbe la machine virtuelle Java,
les autres applications ne sont pas impactées. En revanche cette technique ne permet pas de se
prémunir des pannes de serveur.
Répartition horizontale : Les instances sont réparties sur plusieurs serveurs. On se
prémunit ici de la panne matérielle en revanche comme les instances sont réparties sur plusieurs
serveurs, les échanges entre instances dépendent du réseau.
Nous avons donc ici utilisé ces deux types de répartition, en utilisant plusieurs instances
sur plusieurs serveurs.
Nous avons isolé Geoserver du fait que c’est l’application la plus sensible et la plus
consommatrice en ressource. Ainsi, si Geoserver perturbe la machine virtuelle Java de son
instance Tomcat, il ne perturbe pas le fonctionnement du reste de l’application. Isoler Geoserver
sur un serveur permet aussi de lui allouer plus de ressources.
Ensuite les webapps CAS (Système d’authentification) et ROOT (proxy interne) sont
aussi isolés. Ces deux applications sont très stables et peu consommatrices de ressources. De
plus, si la webapp ROOT ne fonctionne plus le reste de l’application ne peut plus fonctionner
(plus de redirection d’URL). C’est ce qu’on appelle un SPOF (Single Point Of Failure). Pour
éviter que des webapps, comme Mapfishapp ou Geonetwork, ne perturbent le fonctionnement
du CAS et du ROOT, on isole ces deux webapps. On peut aussi se permettre de n’attribuer que
très peu de ressources à l’instance de Tomcat qui les contient.
- 22 Julien FRANCOIS - 31/07/2014
Un serveur web en frontal1
Un serveur web est un logiciel permettant de distribuer des pages web à des clients. Nous utilisons le
serveur web Apache 2.
Une fois l’url validée dans le navigateur, la première étape est le serveur web Apache. Une
fois Apache passé, on accède à Tomcat. C’est la configuration par défaut de geOrchestra mais
voyons quels sont les avantages d’une telle configuration. D’après E. Langlet [LANGLET,
2008] :
Dans une architecture d’entreprise, il est souvent recommandé d’utiliser un serveur Web en frontal d’un
serveur d’application. Ces recommandations s’appliquent également dans le cas de l’utilisation d’un conteneur Web
JEE comme Tomcat 6, et ce, pour les raisons suivantes :
Sécurité : Le serveur Web sert de « bastion » pour les requêtes entrantes dans l’infrastructure, et isole le
conteneur Web de l’Internet. Le conteneur Web se trouve également au plus près des données qu’il doit manipuler.
Apache propose des paramètres de proxy de sécurité qui nous permettront de solidifier la
sécurité de notre application.
Performances : le moteur HTTP de Tomcat reste quand même plus lent que le moteur HTTP d’un
serveur Web, il n’est qu’un moyen d’invoquer les composants Web JEE dynamiques (Servlet, JSP). Positionné
ainsi dans l’infrastructure, le serveur Web a la responsabilité de servir le contenu statique (Pages HTML, images,
applets Java, …) d’un site ou d’une application aux clients, alors que Tomcat 6 sert le contenu dynamique et
s’occupe de l’intégration avec l’existant du système d’information.
En effet, dans notre cas, le contenu statique (page d’accueil) est directement servi par
Apache sans solliciter Tomcat.
Configurabilité : un serveur Web comme le serveur Apache par exemple, dispose de plus grandes
possibilités de configuration (d’un point de vue de la communication HTTP) que Tomcat 6.
On profite par exemple d’Apache pour effectuer le load balancing (Voir point ci-dessous)
En frontal signifie que les requêtes du client passe par le serveur web avant d’être redirigées (si nécessaires)
vers le serveur d’application Tomcat.
1
- 23 Julien FRANCOIS - 31/07/2014
Load balancing geoserver
L'équilibrage de charge (parfois appelé répartition de charge ou en anglais load balancing) consiste à
distribuer une tâche à un pool de machines ou de périphériques afin :
de lisser le trafic réseau, c'est-à-dire de répartir la charge globale vers différents équipements;
de s'assurer de la disponibilité des équipements, en n'envoyant des données qu'aux équipements
en mesure de répondre, voire à ceux offrant le meilleur temps de réponse. [BERT, 2010]
Le load balancing a donc deux objectifs, améliorer les performances en répartissant la
charge et doublonner certaines applications sensibles pour qu’elles restent toujours accessibles. Le
load balancing se fait avec le module proxy_balancer d’Apache
L’algorithme utilisé pour réaliser la répartition de charge est appelé Round-Robin. C’est
en fait un algorithme très simple qui envoie une requête au premier serveur, une autre au second
puis de retour au premier et ainsi de suite. Utilisée tel quel, cette configuration pose un problème
puisque le client perd ses informations de session dès qu’il change de page. Ça n’a pas
d’importance quand les échanges se passent uniquement dans le sens serveur–client. En revanche
dès que le client a envoyé une information au serveur, celui-ci ne peut pas en tenir compte à la
requête suivante.
Pour résoudre ce problème, on utilise des affinités de session (sticky session). L'utilisation
de cette technologie implique qu'un utilisateur ayant une session active travaillera toujours avec le
même serveur : toutes ses requêtes seront traitées par le même serveur.
On remarquera que les deux instances de Geoserver partagent le même « geoserver_datadir ». C’est dans ce dossier qu’est stockée toute la configuration (sécurité, user, groupe, connexion
aux BDD,…) de Geoserver. Un second problème apparait avec ce dossier. En effet, la
configuration est importée au démarrage de Geoserver (donc au démarrage de l’instance de
Tomcat), les changements fait sur une instance ne sont donc pas dynamiquement reportés sur la
deuxième. Pour résoudre ce problème, un script python a été créé par Camptocamp, il permet de
recharger la configuration via l’api REST (pour simplifier l’api REST nous permet ici de lancer
des commandes directement via une url1) de Geoserver. Lorsque l’administrateur fait une
modification de la configuration, il faut lancer le script pour synchroniser toutes les instances. Un
1
http://host/geoserver/rest/reload?recurse=true
- 24 Julien FRANCOIS - 31/07/2014
bouton, permettant d’exécuter le script en mode CGI (script exécuté du coté serveur), a été
ajouté à la barre des menus lorsque l’on est connecté en administrateur.
D’autres améliorations ?
Il existe certes d’autres améliorations pour augmenter la stabilité et la performance de
l’application. Celles-ci n’ont pas été adoptées dans notre projet car elles compliquent trop
l’architecture pour un apport moindre. Comme pour la question de la résolution d’un raster (il n’y
a pas de meilleure résolution, seulement une résolution optimale pour chaque projet),
l’architecture doit répondre aux besoins du projet et il ne sert à rien de la surdimensionner
(augmentation de la consommation électrique des serveurs, complication de débogage, de mise à
jour, etc.)
3.4.2. Matériel / Dimensionnement / Architecture Système
La solution retenue se basera sur deux serveurs. Lorsque l’on parle de deux serveurs, il
s’agit dans la réalité de deux machines virtuelles distinctes mais virtualisées sur le même serveur
physique. Les serveurs seront nommés SRV3SIG et SRV4SIG par la suite.
Le serveur physique (matériel)
L’applicatif est déployé sur des serveurs DELL R320 (processeur Intel Xeon E5-2420, 6
cœurs). Ces serveurs fonctionnent par paire. En cas de panne d’un serveur physique, les machines
s’exécutent sur le deuxième serveur du pool de manière automatique ou bien via une
manipulation manuelle (moins de 2 minutes).
Le stockage disque et partitionnement
Le dimensionnement de l’espace de stockage doit être réfléchit avant la mise en place de
l’installation. Il est en effet assez complexe de le modifier une fois la machine virtuelle configurée.
Il convient donc de prendre en compte les évolutions futures de la plateforme et ainsi d’anticiper
l’augmentation du volume de données à stocker. Il faut aussi partitionner le disque dur.
Le partitionnement consiste à créer des zones sur le disque dont les données ne seront pas mélangées. Il
permet par exemple de formater uniquement la partie système tout en conservant intacte les autres
partitions.
La figure ci-après montre le partitionnement et l’espace disque mis en place.
- 25 Julien FRANCOIS - 31/07/2014
Figure 7 : Dimensionnement de l'espace disque nécessaire
- 26 Julien FRANCOIS - 31/07/2014
La mémoire vive
Contrairement au disque dur, la taille de la mémoire vive peut être augmentée ou
diminuée assez rapidement et facilement. Pour démarrer, nous avons décidé d’attribuer 3 Go de
RAM au serveur SRV3SIG et 4 Go au serveur SRV4SIG.
La bande passante
Dans le cas d’hébergement en interne, c’est bien souvent le facteur limitant d’un projet
informatique ouvert vers l’extérieur. En théorie, les débits disponibles annoncés par le
fournisseur sont :
o 20 Mbps en download (On reçoit jusqu’à 20Mb par seconde depuis
l’extérieur débit entrant)
o 1 Mbps en upload (on envoie jusqu’à 1Mb par seconde vers l’extérieur
débit sortant)
Tous les accès à la plateforme depuis ViennAgglo se font via le réseau interne et ne
passent pas par le réseau internet. Cela permet de limier la surcharge du réseau. Cette bande
passante limitée est discutée dans la dernière partie du rapport (5.2. Le réseau internet)
3.5. Sécurité
La mise en place d’une plateforme accessible depuis l’extérieur via internet implique des
règles de sécurité strictes pour éviter toute intrusion dans le système informatique de ViennAgglo.
Ce sont ici des questions qui sont gérées principalement par le service informatique, mes
connaissances étant très limitées dans le domaine. Je ne détaillerai donc pas tous les mécanismes
utilisés ici.
De mon côté, j’ai simplement défini que le seul point d’entrée de l’application soit le
serveur web Apache de SRV3SIG. Après discussion avec la DSI, le choix a été fait de mettre
SRV3SIG dans la DMZ et de laisser SRV4SIG sur le réseau local. Les connexions entre les deux
serveurs seront limitées au maximum (on ouvre uniquement les ports utilisés). L’ouverture des
ports nécessaires est faite par la DSI. Les échanges entre les deux services ont donc été très
importants durant cette partie.
- 27 Julien FRANCOIS - 31/07/2014
La DMZ (Demilitarized Zone) est un sous-réseau situé entre le réseau local et Internet. C'est une
partie du réseau contenant tous les services accessibles de l'extérieur. Elle est séparée du réseau local
par un pare-feu. Cela permet d'avoir une partie du réseau accessible depuis le monde IP sans pour
autant laisser l’accès à tout le réseau.
Figure 8 : Fonctionnement de la DMZ
- 28 Julien FRANCOIS - 31/07/2014
- 29 Julien FRANCOIS - 31/07/2014
IV. Production, maintenance et transfert de
connaissances
4.1. Mise en production
Cette partie s’attarde sur les aspects pratiques de chargement et mise à disposition des
données.
4.1.1. Licence, droits d’accès
L’objectif de la plateforme, outre le fait de cataloguer les données, est de pouvoir les
partager avec les partenaires et le public. Toutes les données ne peuvent pas être diffusées au
grand public. Il convient donc de définir des groupes d’utilisateurs privilégiés qui auront des accès
sur certaines données. Cette gestion des droits se fait via deux applications, ldapadmin qui permet
de gérer les groupes et les utilisateurs ainsi que Geoserver qui permet de servir des flux WMS et
WFS en limitant les accès à certains groupes (voir 4.1.2. Geoserver)
Aussi, la mise à disposition des données impose de les mettre sous licence. Plusieurs
licences existent pour une diffusion gratuite. Nous avons retenu la licence proposée par Etalab1 :
la Licence Ouverte (Open Licence). Cette licence facilite et encourage la réutilisation des données
publiques mises à disposition gratuitement.
La « Licence Ouverte / Open Licence » présente les caractéristiques suivantes :
Une grande liberté de réutilisation des informations :
o Une licence ouverte, libre et gratuite, qui apporte la sécurité juridique nécessaire aux
producteurs et aux réutilisateurs des données publiques ;
o Une licence qui promeut la réutilisation la plus large en autorisant la reproduction, la
redistribution, l’adaptation et l’exploitation commerciale des données ;
o Une licence qui s’inscrit dans un contexte international en étant compatible avec les
standards des licences Open Data développées à l’étranger et notamment celles du
gouvernement britannique (Open Government Licence) ainsi que les autres standards
internationaux (ODC-BY, CC-BY 2.0).
Une exigence forte de transparence de la donnée et de qualité des sources en rendant
obligatoire la mention de la paternité.
Une opportunité de mutualisation pour les autres données publiques en mettant en place un
standard réutilisable par les collectivités territoriales qui souhaiteraient se lancer dans
l’ouverture des données publiques. [Etalab, 2014]
Service du Premier Ministre chargé de l'ouverture des données publiques et du développement de la
plateforme française Open Data. http://www.etalab.gouv.fr/pages/Qui_sommes_nous_-5883786.html
1
- 30 Julien FRANCOIS - 31/07/2014
4.1.2. Geoserver
Gestion des couches
Geoserver est un serveur cartographique open-source qui permet de publier des couches
sous forme de services cartographiques (WMS, WFS, etc.). L’organisation des couches est
importante puisque c’est à travers elle que les droits d’accès vont s’appliquer. Trois niveaux de
gestion de stockage sont présents dans Geoserver (voir Figure 9) :
-
Le « workspace » (espace de travail) : il rassemble en générale des couches
similaires, qui appartiennent à une même thématique. C’est aussi via ce conteneur
que l’on va gérer les droits : on peut décider qui a accès au workspace et de quelle
manière (lecture, écriture ou admin).
-
Le « store » (entrepôt) : les entrepôts sont des connexions aux sources de
données. Une source de données peut être un fichier (raster ou vecteur) ou un
groupe de fichiers, autant qu’une table dans une base de données (PostGIS).
-
Le « layer » (couche) : les couches sont les données géographiques à proprement
parler.
Figure 9 : Architecture de gestion des couches de Geoserver [PennState, 2014]
- 31 Julien FRANCOIS - 31/07/2014
A ViennAgglo, nous avons donc décidé de créer un workspace par thématique de
données. Ce workspace pourra être doublonné pour permettre des accès restreint à certaines
couches. Par exemple :
Le workspace cadastre_public contiendra les couches du cadastre avec seulement la
géométrie (pas d’information nominative, ni numéro de parcelle). Les couches présentes
pourront être diffusées au grand public et sans création de compte sur geo.viennagglo.fr
Le workspace cadastre_privé contiendra les couches du cadastre avec la totalité des
attributs. En revanche, son accès sera permis uniquement aux personnes autorisées par le service
SIG.
Création des styles
La publication de couche WMS implique la création de style. En effet les tuiles affichées
par le client doivent être esthétiques et compréhensibles. Au-delà de l’aspect esthétique, les styles
doivent être optimisés pour ne pas surcharger Geoserver. Quelques règles doivent être respectées
[GeoSolutions, 2013] :
- Ne pas afficher plus de 1000 entités
- Afficher les couches uniquement au zoom utile (ne pas afficher les parcelles à l’échelle
régionales)
- Eviter la transparence
- Montrer les détails progressivement (Label à certaines échelles)
1/125 000ème
1/30 000ème
Figure 10 : Style appliqué au stationnement vélo
- 32 Julien FRANCOIS - 31/07/2014
1/10 000ème
4.1.3. Geonetwork
Les métadonnées
La gestion d’un catalogue de données et la rédaction de métadonnées n’est pas une chose
aisée et il est facile de se perdre entre la multitude de champs présents dans GeoNetwork et le
flou toujours persistant autour de la directive INSPIRE. Certaines entités, comme Cigalasce,
préfèrent ne pas utiliser le mode édition de métadonnées de Geonetwork et utilise une feuille
Excel avec uniquement les champs obligatoire pour INSPIRE. Cette feuille doit ensuite être
transformée, via une application, au format xml. Ce fichier xml pourra ensuite être intégré dans
Geonetwork. Nous préfèrerons le mode d’édition natif de Geonetwork. Pour faciliter les
prochaines entrées, une fiche de métadonnée type a donc été rédigée pour servir de modèle
[CNIG, 2013].
La mise à disposition
L’accès aux données via Geonetwork se fait de plusieurs manières pour les données
vectorielles :
-
Mise à disposition d’un flux WMS (avec accès direct au visualiseur de geOrchestra)
-
Visualisation sur un visualiseur simplifiée
-
Téléchargement d’un dossier zippé contenant la couche au format Shapefile via un
flux WFS
Ces différentes méthodes d’accès correspondent au degré d’expertise et au besoin de
l’utilisateur.
Acces Mapfish
Visualiseur simple
Dossier zip
Figure 11 : Mise à disposition des données dans Geonetwork
- 33 Julien FRANCOIS - 31/07/2014
Flux WMS
4.2. Maintenance
La mise en place de ce type de solution nécessite un suivi technique. Le projet étant en
constante évolution, celui-ci nécessite des mises à jour pour profiter du meilleur produit
disponible. La défaillance d’une partie du système est possible, il faut donc que le service SIG soit
capable de comprendre le problème et de relancer l’application le plus facilement possible.
4.2.1 Détecter des défaillances
Il peut arriver que la plateforme comporte des bugs ou que certaines parties de celle-ci
subissent un crash. Pour résoudre ces problèmes, différents fichiers logs permettent d’identifier la
source du problème. Pour faciliter l’accès aux logs, j’ai ajouté une petite interface en ligne pour les
consulter (Bootstrap + jQuery +Ajax pour la partie cliente, python en CGI pour la partie
serveur).
Figure 12 : Capture de l'interface de consultation des logs
4.2.2 Redémarrer les services
Une fois le problème détecté et résolu, l’application en question doit être relancée. Pour
les différentes instances de Tomcat, un service (daemon) a été créé pour permettre un
redémarrage plus facile via une seule commande (service tomcat60d start|stop|restart).
- 34 Julien FRANCOIS - 31/07/2014
4.2.3. Compilation des sources
Pour prendre en compte les modifications dans la configuration de geOrchestra, il faut
recompiler les sources (avec Apache Maven). Cette compilation génère des fichiers « *.war »,
formats d’archives contenant une application web destinée à un serveur d’application (Tomcat).
Une fois créés, les fichiers war doivent être déployés sur leur instance de Tomcat et pour
automatiser ce déploiement, un script bash a été conçu (partie « Codes » de la documentation
disponible en Annexe 4).
4.2.4. Processus de mise à jour
Les développeurs de geOrchestra ont programmé un rythme d’environ 2 versions par an.
En plus de corriger les bugs déclarés par les utilisateurs, celles-ci permettent d’ajouter de
nouvelles fonctionnalités à l’outil. Les développeurs mettent à disposition un fichier des
instructions pour migrer correctement son application. J’ai pu réaliser la mise à jour de
geOrchestra de la version 14.01 à 14.061. Le changement de version était assez bien documenté,
la transition s’est faite assez facilement. C’est avec cette version que nous avons mis à disposition
de la communauté notre documentation d’installation multi-instances de geOrchestra en Licence
Ouverte (Disponible en Annexe 4).
4.3. Documentation utilisateur
4.3.1. Sensibiliser à la géomatique
La mise en place de la plateforme est aussi un moyen de mettre en avant et de faire
connaitre la géomatique au grand public. Ainsi, plusieurs vidéos ludiques sont directement
ajoutées à la page d’accueil : Un épisode de « C’est pas sorcier » sur la cartographie, le
film « Geospatial Revolution » réalisé par le Penn State Public Broadcasting ou encore un épisode du
« Dessous des cartes ».
4.3.2. Documentation technique
Les possibilités offertes par geOrchestra en font un outil SIG à part entière et nécessite
donc un apprentissage de son fonctionnement.
De nombreuses documentations ont été réalisées sur les différentes plateformes déjà en
production. Celles-ci peuvent prendre plusieurs formes. GéoBretagne met, par exemple, des kits
de formation permettant aux personnes de s’auto-former, CIGAL met en ligne des manuels
d’utilisation et Camptocamp propose des tutoriels vidéo. Les documentations produites par les
1
http://www.georchestra.org/blog/2014/07/10/version-14.06/
- 35 Julien FRANCOIS - 31/07/2014
régions concernent aussi bien l’utilisateur que le producteur de données. Nous ne sommes
intéressés que par la partie utilisateur de données (consommateur), puisque la seule entité à
produire des données à ViennAgglo est le service SIG (qui est déjà formé !).
Les vidéos de Camptocamp ont été ajoutées directement au site puisqu’elles traitent du
fonctionnement utilisateur des applications de geOrchestra. Ensuite, nous avons demandé à la
région Bretagne s’il était possible d’utiliser leur kit de formation comme base pour notre
documentation, leur réponse a été favorable. Nous avons donc utilisé leurs supports pour créer
des
diaporamas
explicatifs
en
ligne
avec
la
bibliothèque
(http://viennagglo.github.io).
- 36 Julien FRANCOIS - 31/07/2014
Javascript
Reveal.js
- 37 Julien FRANCOIS - 31/07/2014
V) Perspectives, évolution
Du fait de sa modularité, geOrchestra peut être modifié pour s’adapter au besoin des
utilisateurs. Les perspectives d’évolution dépendent beaucoup des retours sur l’utilisation et du
public concerné. On peut cependant émettre certaines remarques sur la solution mise en place.
Les échanges que nous avons eus avec les autres développeurs/utilisateurs de geOrchestra lors du
GeoCom (Voir Annexe 2 le programme du meeting) nous ont permis d’avoir des premiers
retours d’utilisation. Ces retours viennent en majorité de structures régionales, donc avec des
charges beaucoup plus importantes que nous.
5.1. Trop complexe pour une majorité ?
Les outils proposés par geOrchestra permettent une utilisation avancée des données. Le
visualiseur en est l’exemple parfait, il permet par exemple de définir des styles personnalisés, de
réaliser requêtes attributaires et spatiales ou encore d’éditer les données. Ce sont des fonctions
présentes dans les logiciels desktop classiques utilisés par les géomaticiens. Est-ce que ces outils
ne sont pas trop complexes pour un public non expert ? Lors du meeting annuel des utilisateurs
et développeurs de geOrchestra (le GeoCom), les responsables du projet GeoBretagne annoncent
que 90 % des utilisateurs de leur plateforme ne sont pas experts et que le visualiseur est trop
complexe pour ces personnes. Il n’est pas question de remettre en cause la pertinence de celui-ci,
il est utile pour les 10% qu’il reste, qui sont experts. En revanche, comment réussir à rester
accessible à tous ? Pour répondre à cette demande, différents autres visualiseurs voient le jour ces
dernier temps :
-
Le Sviewer (simple viewer) permet l’affichage d’une seule couche déjà stylisée
-
le Mviewer (middle viewer) permet d’afficher plusieurs couches préconfigurées
(pas de services en plus).
La problématique est de réussir à intégrer ces niveaux de complexité sans perdre
l’utilisateur dans des choix multiples de visualiseur. A ViennAgglo, nous utilisons déjà le Sviewer
pour les aperçus à partir de Geonetwork.
Autre application disponible dans geOrchestra, l’extracteur. Celui-ci permet d’extraire des
données sur une emprise rectangulaire dans un format et une projection que l’on choisit. C’est un
outil qui va être réservé aux experts puisqu’on rentre dans des notions de projection et de formats
de données. Je ne suis pas convaincu de la pertinence de cet outil pour ViennAgglo. Je pense
- 38 Julien FRANCOIS - 31/07/2014
qu’un des objectifs est d’encourager au maximum les partenaires à utiliser des flux WMS et WFS
pour obtenir les données. L’enjeu est de leur faire comprendre qu’une fois l’URL entrée dans leur
logiciel, il n’y a plus à se préoccuper de la mise à jour et de la validité des données. Pour les
personnes qui souhaitent absolument avoir les données en local, le WFS permet de télécharger
des fichiers Shape zippé.
Exemple de WFS fournissant un shape zippé :
http://geo.viennagglo.fr/geoserver/wfs?service=wfs&version=1.0.0&request=getFeature&typeName=transport
:capv_transport_arret&outputFormat=shape-zip
5.2. Le réseau internet
La solution est actuellement hébergée à ViennAgglo qui n’est pas rattaché au réseau par la
fibre mais par ADSL et SDSL. En fonction de la popularité de la plateforme (saturation du
réseau), il faudra peut-être envisager de l’externaliser ou bien de réaliser les travaux pour apporter
la fibre. En effet, le temps de réponse d’un site est un élément essentiel à la fidélisation d’un
client. Selon des enquêtes effectuées par Gomez et Akamai, près de la moitié des internautes s'attendent à ce
qu'un site se charge en 2 secondes voir moins, et ils ont tendance à abandonner un site qui n'est pas chargé dans les
3 premières secondes. 80% des acheteurs sur le web qui ne sont pas satisfaits des performances du site disent qu'ils
ne reviendront pas sur le même site pour acheter à nouveau et plus d'un tiers ont parlé aux autres de leur mauvaise
expérience. [Weboxeur, 2014]
5.2.1. La fibre
L’installation de la fibre dans plusieurs villes ou agglomération du département Isérois est
en cours de discussion. Si ces discussions arrivent à terme, ViennAgglo pourrai être équipé en
fibre d’ici quelques années.
5.2.2. Hébergement externe
Concernant l’hébergement externe, plusieurs étapes sont envisageables.
La première étape serait d’héberger sur un serveur très peu couteux (du type Kimsufi1) le
cache de nos tuiles. Ainsi les données en cache utilisées dans le visualiseur ne passeraient plus par
ViennAgglo et soulageraient donc le réseau. Ce type de serveur est peu cher car il n’y a aucun
service derrière (backup, hotline, dépannage, etc.) et ils ne sont pas puissant (2 Gb de RAM,
processeur Intel Atom pour le moins chers). La puissance et les services sont utiles lorsque l’on
héberge des applications mais pour stocker du cache, il est inutile d’avoir un serveur très puissant
1
https://www.kimsufi.com/fr/index.xml
- 39 Julien FRANCOIS - 31/07/2014
mais plutôt un bon débit internet et un bon disque de stockage, c’est le cas ici (100Mbps et
500Go pour le basique). Le prix de départ est 5€/mois HT.
La seconde étape serait d’héberger toute l’application sur un serveur dédié externe. Cette
fois il faut se tourner vers un service comprenant des garanties de disponibilité, des services de
sauvegarde et de dépannage. Chez OVH1, les serveurs dédiés de base (largement suffisant en
terme de puissance pour héberger notre application) démarrent à 82 €/mois HT (hors frais
d’installation) en revanche les services proposés ne comportent pas de restauration de système en
cas de crash. Il faut prévoir 2400€/an environ pour un serveur suffisant pour notre plateforme.
5.3. Automatiser l’administration
Actuellement, toutes les actions de gestion des applications (compilation, déploiement,
redémarrage, etc.) doivent être réalisées via une console SSH (connexion à distance sur le
serveur). Des scripts et services ont certes été créés pour faciliter leur exécution, mais on continue
avec des lignes de commande et uniquement sur les postes de ViennAgglo. L’étape suivante serait
de pouvoir gérer toute ces actions via une interface web. GeoBretagne utilise par exemple l’outil
Jenkins2 pour monitorer son serveur.
5.4. Métadonnées
Maintenant que le catalogue est fonctionnel, un gros travail de documentation des
données existantes est nécessaire. Cette charge de travail ne pourra probablement pas être
absorbée par l’équipe actuelle, il faudrait envisager d’ajouter une personne temporairement au
service.
Une fois le retard rattrapé, le service SIG devra prendre le « reflexe métadonnée » pour
chaque donnée créée. Cette charge de travail supplémentaire pourra, quant à elle, normalement
être absorbée.
1
2
http://www.ovh.com/fr/serveurs_dedies/enterprise/
http://jenkins-ci.org/
- 40 Julien FRANCOIS - 31/07/2014
- 41 Julien FRANCOIS - 31/07/2014
Conclusion
A la fin du stage, ViennAgglo a donc une solution technique opérationnelle, basée sur
geOrchestra, et prête à être mise en production. Avec la plateforme on a donc accès à un outil de
catalogage des données, un visualiseur avancé, un serveur cartographique, un extracteur de
données et des outils d’administration. Toutes ces fonctionnalités permettent à la plateforme de
répondre à la directive INSPIRE et de s’articuler avec les autres plateformes du territoire. De
plus, des modèles de métadonnées ont été produites pour servir de modèles aux prochaines
données renseignées. Enfin, une documentation, de toute la procédure de mise en place de
geOrchestra, a été rédigée. Celle-ci a été diffusée à toute la communauté geOrchestra et est
disponible sous Licence Ouverte en Annexe 4 ou sur GitHub1.
ViennAgglo doit maintenant faire face à différents enjeux. D’abord, la plateforme doit
être validée par les élus de l’agglomération. Pour ça, une note est en cours de validation par le
directeur général adjoint des services avant d’être transmise aux élus (la note est consultable en
Annexe 3). Ensuite, une procédure de demande de financement est en cours avec le chargé de
mission Politiques territoriales. La communication de l’ouverture de la plateforme se fera en
premier lieu sur l’AggloMag (Magazine trimestriel tiré à 32 000 exemplaires et distribué sur toute
l’agglomération). Ensuite le site de ViennAgglo offrira un accès à la plateforme. Enfin, le dernier
enjeu de taille est la rédaction des métadonnées pour toutes les données. Cette rédaction ne
pourra pas se faire avec les moyens humains actuellement présent. Il sera donc nécessaire de se
doter de moyen humain supplémentaire, actuellement c’est la piste d’un stage qui est envisagé.
L’objectif du stagiaire serait de rencontrer les services commanditaires des données présentes
dans la base actuelle et de savoir si ceux-ci sont intéressés par une mise à jour, une publication ou
un abandon. De plus celui-ci devra aussi entrer les métadonnées dans le catalogue, travailler sur la
conformité avec INSPIRE et sur les conditions de mise à disposition.
D’un point de vue personnel, ce stage m’a apporté les différents éléments qu’ils me
manquaient en sortant du Master : des connaissances sur les mécanismes liés au fonctionnement
des serveurs. J’ai pu découvrir la distribution Linux Debian, les différents protocoles d’échange et
d’identification (ssh, IP, http, ssl, ports d’écoute, etc.) ou encore, comment configurer un serveur
web et un serveur d’application. D’un point de vue applicatif, j’ai pu découvrir la solution
geOrchestra et tous les logiciels qui la composent (Geoserver, Geonetwork, mapfish,etc.). D’un
point de vue moins technique, j’ai pu prendre le temps de comprendre la directive INSPIRE et
1
https://github.com/viennagglo/georchestra-doc
- 42 Julien FRANCOIS - 31/07/2014
de rédiger des métadonnées conformes. Finalement, ce stage s’est présenté comme un excellent
complément à mon année de master 2.
- 43 Julien FRANCOIS - 31/07/2014
Bibliographie
Document & Livres
CNIG, Groupe de travail « Métadonnées ». Guide de saisie des éléments de métadonnées INSPIRE
(Version 1.1). 2013
GeoSolutions. GeoServer on steroids. FOSS4G 2013, Nottingham 20/09/2013
Langlet, É. Apache Tomcat 6: guide d’administration du serveur Java EE sous Windows ou Linux.
(Editions ENI, 2008).
Sites Web
Bert L. Tutoriel : Load balancing avec Apache et Tomcat. http://java4it.blogspot.fr/2008/09/tutorielload-balancing-avec-apache-et.html, [consulté le 27/05/2014]
DynMAP, Actualités, http://www.dynmap.com/actualites/, [consulté le 23/04/2014]
Etalab, Licence Ouverte / Open Licence, http://www.etalab.gouv.fr/pages/licence-ouverteopen-licence-5899923.html, [consulté le 09/07/2014]
Geonetwork, Moissonage, http://geonetwork-opensource.org, [consulté le 21/05/2014]
IGN,
Présentation
INSPIRE,
http://inspire.ign.fr/directive/presentation,
[consulté
le
14/04/2014]
OGC,
Forum
Français
de
l’OGC,
http://www.forumogcfrance.org/Interoperabilite-et-
OGC/Specifications-OGC/, [consulté le 27/05/2014]
PennState, GeoServer Admin Interface and Concepts,
https://www.e-education.psu.edu/cloudGIS/node/53, [consulté le 09/07/2014]
Weboxeur,
Pourquoi
le
Temps
de
Chargement
de
vos
Pages
http://weboxeur.com/temps-de-chargement/, [consulté le 03/07/2014]
- 44 Julien FRANCOIS - 31/07/2014
est
Important,
Listes des figures
FIGURE 1 : CARTE DE PRESENTATION DE VIENNAGGLO (SOURCE : PLAQUETTE D’INFORMATION VIENNAGGLO) .............................. 4
FIGURE 2 : COMPLEMENTARITE DYNMAP/GEORCHESTRA ................................................................................................. 14
FIGURE 3 : ETAT D’AVANCEMENT DES PROJETS DE CATALOGUE DANS LES EPCI ....................................................................... 15
FIGURE 4 : BARRE DE NAVIGATION DE L'APPLICATION ........................................................................................................ 19
FIGURE 5 : ARCHITECTURE FINALE RETENUE ..................................................................................................................... 21
FIGURE 6 : FONCTIONNEMENT DE LA SOLUTION ............................................................................................................... 21
FIGURE 7 : DIMENSIONNEMENT DE L'ESPACE DISQUE NECESSAIRE ........................................................................................ 26
FIGURE 8 : FONCTIONNEMENT DE LA DMZ ..................................................................................................................... 28
FIGURE 9 : ARCHITECTURE DE GESTION DES COUCHES DE GEOSERVER [PENNSTATE, 2014] ...................................................... 31
FIGURE 10 : STYLE APPLIQUE AU STATIONNEMENT VELO .................................................................................................... 32
FIGURE 11 : MISE A DISPOSITION DES DONNEES DANS GEONETWORK................................................................................... 33
FIGURE 12 : CAPTURE DE L'INTERFACE DE CONSULTATION DES LOGS..................................................................................... 34
- 45 Julien FRANCOIS - 31/07/2014
Table des annexes
ANNEXE 1 : EVOLUTION DE L'ARCHITECTURE DE LA SOLUTION ............................................................................................. 47
ANNEXE 2 : PROGRAMME GEOCOM 2014 ..................................................................................................................... 50
ANNEXE 3 : NOTE A DESTINATION DES ELUS..................................................................................................................... 51
ANNEXE 4 : DOCUMENTATION INSTALLATION GEORCHESTRA .............................................................................................. 52
- 46 Julien FRANCOIS - 31/07/2014
Annexe 1 : Evolution de l'architecture de la solution
Cette annexe présente l’évolution de l’architecture logicielle au cours du projet. En
générale un changement de machine virtuelle entrainait une amélioration de l’architecture.
1) Architecture n°1 (VM1)
Toutes les applications sont concentrées sur un seul serveur et toutes les webapps sont
dans une seule instance de Tomcat. La base de données est une base interne. C’est la solution
décrite sur le dépôt GitHub de geOrchestra.
2) Architecture n°2 (VM 2)
Ici, une première répartition des webapps intervient. On créé des instances de Tomcat
pour répartir la charge et augmenter la stabilité.
- 47 Julien FRANCOIS - 31/07/2014
3) Architecture n°3 (Mise en situation).
Premier test sur serveurs réelles, cette fois en plus d’être séparé on isole sur un autre
serveur l’instance de Tomcat hébergeant Geoserver. On accède aussi directement à la base de
données existante de ViennAgglo.
- 48 Julien FRANCOIS - 31/07/2014
4) Architecture 4 (finale)
On rajoute ici un load balancing sur les deux instances de Geoserver pour anticiper une
éventuelle panne sur l’une des deux.
- 49 Julien FRANCOIS - 31/07/2014
Annexe 2 : Programme GeoCom 2014
- 50 Julien FRANCOIS - 31/07/2014
Annexe 3 : Note à destination des élus
- 51 Julien FRANCOIS - 31/07/2014
Direction de l’Aménagement Urbain
Information Géographique
Jean-Luc PONTIER
S/C Isabelle FONTIVIELLE
Mise en place d’une plate-forme de
catalogage et de diffusion des données
géographiques
10 Juillet 2014
Destinataire : Samuel RIBLIER - Directeur Général Adjoint des Services et du PSDT
Plan de la note :
I- Motivations du projet
I-1 La connaissance patrimoniale et l’environnement juridique
I-2 Les aspects sociaux économiques
II-Les moyens d’amélioration et d’évolution de la plateforme
II-1 Des moyens techniques pour prévoir une montée en charge progressive
II-2 Des moyens humains en adéquation
II-3 Les questions
ANNEXE 1 L’OPENDATA
ANNEXE 2 Pages d’accueil de la plate-forme geo.viennagglo.fr
ANNEXE 3 Exemple de fiche de métadonnées
Pour faire face à la montée en charge de notre système d’information géographique
et aux besoins de l’intercommunalité, le service SIG et Observatoires a entrepris de
centraliser progressivement les données dans une base unique. Par ailleurs, il envisage
depuis quelque temps de mettre en place un catalogue informatique de métadonnées1
géographiques.
Ce projet est motivé par le besoin de connaître notre patrimoine de données, son
organisation et les contraintes règlementaires de diffusion qui s’imposent à nous, comme la
directive Européenne INSPIRE ou le futur portail national de l’urbanisme.
Pour cela nous avons fait le choix d’installer une plateforme
diffusion des données géographiques. Elle nous permettra à la
informations disponibles à travers d’autres plateformes comme celle
Alpes (GeoRhonealpes), auprès de nos partenaires ou d’accéder à
travers d’autres catalogues.
de catalogage et de
fois de rendre nos
de la région Rhônedes informations au
Il convient tout d’abord d’aborder les motivations du projet entrepris par le service
SIG dans ce domaine, puis les moyens d’amélioration et d’évolution de la plate-forme. Cela
soulève cependant des questions que nous allons proposer à la validation des élus.
1
Une métadonnée est une donnée servant à définir ou décrire une autre donnée quelque soir son support (papier ou
électronique).
1
I- Motivations du projet
Pour la plupart des collectivités qui ont mis en œuvre un système de catalogage2, les
principaux arguments sont :
la connaissance patrimoniale des données,
les aspects sociaux économiques,
la nécessité de répondre aux prescriptions juridiques.
I-1 La connaissance patrimoniale et l’environnement juridique
Les collectivités territoriales sont des acteurs incontournables dans la production de
données géographiques. A ce titre, nous avons effectivement produit ou agrégé tout un
patrimoine d’informations thématiques qu’il nous appartient d’inventorier, de cataloguer et
de diffuser, par exemple :
les boucles cyclo touristiques,
les zones d’activité et leur signalétique,
le balisage des sites d’hébergement,
la gestion de l’ambroisie,
la gestion des réseaux d’assainissement, la collecte de déchets …
De plus, l’environnement juridique nous y contraint et en particulier la Directive
Européenne INSPIRE. En effet, partant du constat que les phénomènes ne s’arrêtent pas aux
frontières, cette directive, transposée en droit français en 2009 vise à établir une
infrastructure pour assurer l’interopérabilité3 entre les bases de données géographiques des
pays de l’union.
La directive précise pour chaque thème les modalités de mise en œuvre, en termes
d’interopérabilité, de normalisation et les délais à respecter pour y parvenir.
Au niveau national, on citera la création d’un Géoportail de l’urbanisme qui obligera dès le 1er
janvier 2016 l’ensemble des communes et groupement de transmettre « à l’Etat sous format
électronique, au fur et à mesure des modifications de leurs dispositions, la version en
vigueur des schémas de cohérence territoriale, des plans locaux d’urbanisme, des documents
en tenant lieu et des cartes communales applicables sur leur territoire incluant les
délibérations les ayant approuvés ».
Par ailleurs, la modernisation des politiques publiques entreprise par l’Etat tend vers
l’ouverture des données au travers notamment du concept de l’Open-Data4. En effet, cette
tendance se traduit dans l’article 29 du projet de loi de développement des solidarités
territoriales et de la démocratie locale, qui vise, dans le cadre fixé par la loi du 17 juillet 1978
(CADA*), « à rendre obligatoire pour les collectivités territoriales de 3500 habitants et plus
ainsi que, pour les établissements publics de coopération intercommunale à fiscalité propre
auxquels elles appartiennent, la mise à disposition de données publiques dont elles disposent
au format électronique par une mise en ligne sur leur site internet ».
2
Un logiciel de catalogage est capable de parcourir le réseau pour rechercher des données thématiques disponibles à
travers d’autres catalogues. Un catalogue peut aussi être moissonné : c’est-à-dire qu’on l’autorise à fournir des informations
cataloguées vers l’extérieur.
3
L’interopérabilité est la capacité que possède un produit ou un système, dont les interfaces sont intégralement connues, à
fonctionner avec d’autres produits ou systèmes existants ou futurs et ce sans restrictions d’accès ou de mise en œuvre.
4
Open data : l’ouverture des données (en anglais Open data) représente à la fois un mouvement, une philosophie d’accès à
l’information et une pratique de publication de données librement accessibles et exploitables.
2
I-2 Les aspects sociaux économiques
Les technologies de l’information et des communications (TIC) notamment
« internet » ainsi que les applications et technologies « mobiles » se développent à grande
vitesse et facilitent l’accès aux données. Il en est de même, qu’elles soient produites par les
collectivités ou issues de contributeurs externes. Un nombre croissant de données sont ainsi
consultables ou téléchargeables à partir de plates-formes publiques telles que Géobretagne,
PIGMA ou GéoRhonealpes ou associatives (privées) comme le projet « OpenStreetMap ». En
effet, ce site propose une cartographie des voies de communications et il est nourri par des
utilisateurs répartis dans le monde entier.
Nous devons saisir ces opportunités pour proposer aux communes, partenaires et
usagers des services nouveaux, synonymes de proximité, de limitations des déplacements,
de meilleures informations aux citoyens et d’économies d’échelle.
La mise en place d’un catalogue et d’une plate-forme de diffusion favorise également
la participation citoyenne et collaborative en associant les personnes à nos projets ; on citera
par exemple :
l’implantation de points d’apport volontaire de déchets,
l’implantation de stationnements vélo,
On s’oriente donc vers des services innovants développés pour les usagers où une
expertise citoyenne peut s’exprimer et un marché se développer. Le monde économique est
de plus en plus consommateur du web et la réutilisation des données publiques peut créer
des retombées non négligeables. C’est le cas de la « base Adresse » qui alimente les
répertoires d’entreprises ou des applications de géolocalisation, de la cartographie des
commerces et des services mobiles à travers le potentiel des smartphones.
La commission Européenne estime le marché des données publiques à 27 milliards
d’Euros.
II-Les moyens d’amélioration et d’évolution de la plateforme
II-1 Des moyens techniques pour prévoir une montée en charge
progressive
En 2012, le service informatique de ViennAgglo, a mis à la disposition du SIG une
solution matérielle suffisamment dimensionnée pour héberger à la fois les données et les
solutions logicielles avec une anticipation des capacités techniques. Elle a également été
prévue pour être utilisée comme serveur internet et ainsi permettre la diffusion ultérieure
des informations à travers le catalogue de métadonnées.
La partie matérielle installée et éprouvée, nous avons réfléchi aux solutions logicielles
de catalogage et de diffusion. Nous avons donc orienté notre choix vers des technologies
open source5 avec la solution « GeOrchestra » dont le développement a été commandé par
la région Bretagne dans le courant de l’année 2010. Les principales raisons qui ont motivé ce
5
Open source : La désignation open source, ou « code source ouvert », s'applique aux logiciels dont la licence respecte des
critères précisément établis par l'Open Source Initiative, c'est-à-dire les possibilités de libre redistribution, d'accès au code
source et de créer des travaux dérivés.
3
choix sont le modèle économique et la communauté de développement de GeOrchestra, le
respect des normes internationales préconisées par la directive INSPIRE, l’interopérabilité,
ainsi que des modèles de plates-formes qui ont été développées.
Pour la partie catalogage, GeOrchestra utilise l’application « GeoNetwork »,
accompagnée d’un extracteur destiné aux téléchargements. La solution permettra aussi de
gérer la confidentialité des données à l’aide d’un module d’administration des droits.
Dans un premier temps, la plate-forme sera hébergée dans les locaux de ViennAgglo.
La seule interrogation réside dans le dimensionnement et le débit des lignes ADLS alimentant
le bâtiment Antares.
Pour éviter les frais liés à la création d’un nom de domaine, la plate-forme portera
celui de « geo.viennagglo.fr ».
II-2 Des moyens humains en adéquation
Le service SIG et Observatoires est doté de deux personnes et l’utilisation des
solutions open source et technologies web font partie de la vie quotidienne du service. La
compétence dans ce domaine existe donc en interne. Cependant, la charge de travail n’a pas
permis de dégager le temps nécessaire pour mettre en place une telle solution.
Nous avons donc envisagé deux possibilités, l’aide d’un prestataire de services ou le
recrutement d’un stagiaire de niveau ingénieur avec le potentiel adéquat. Bien que plus
aléatoire et risquée, nous avons choisi la deuxième solution. C’est l’argument économique
qui a été déterminant mais il a été long et difficile de trouver le bon profil. Après neuf mois
de consultations, nous avons recruté pour une durée de 5 mois une personne en Master II
SIG et Aménagement de l’espace de l’université de Saint-Etienne.
Ses missions sont les suivantes :
L’installation du système et la configuration des solutions logicielles telles qu’un
serveur de données géographiques et toute la suite logicielle « GeOrchestra »,
La gestion administrative des données,
Le développement des pages d’interfaces,
La documentation des paramétrages des briques logicielles et des sources pour le
transfert de compétence,
La saisie de fiches du catalogue.
Le travail collaboratif effectué entre les personnels du service SIG et le stagiaire a
permis l’installation de la plate-forme qui est en cours de mise au point. A son départ, fin
juillet 2014, le service SIG disposera de tous les moyens nécessaires à sa pérennisation.
La suite du projet consistera à finaliser et à maintenir la plate-forme. C’est-à-dire :
enrichir l’application de toutes les ressources géographiques que nous possédons,
en passant par la donnée géographique brute aux cartes au format PDF réalisées
pour les services de ViennAgglo.
4
Il sera peut-être utile de réviser notre mode d’hébergement si celui-ci impacte les
performances de la plateforme. A cette occasion, nous allons tirer parti de cette dynamique
pour intensifier la diffusion des données produites par ViennAgglo et relancer des projets
métiers comme les observatoires.
A terme, nous disposerons d’une plateforme de catalogage et de diffusion de
données géographiques basée sur des techniques ouvertes et interopérables. Les
informations seront donc visibles et téléchargeables en fonction des droits qui seront
attribués aux utilisateurs et/ou aux données. Il en sera de même pour le personnel de
ViennAgglo lorsqu’il cherchera des informations situées sur d’autres plates-formes.
Nous respecterons donc les contraintes juridiques et adhérerons à la démarche
globale de libération et de réutilisation des données publiques. Ces moyens contribueront à
accroitre notre rôle économique et à faire vivre nos données.
II-3 Les questions
La plate-forme de diffusion et de catalogage est quasiment opérationnelle et nous
disposons de moyens pour poursuivre son développement. Nous avons évoqué ci-dessus les
arguments qui justifient sa mise en place. Cependant nous devons faire valider la poursuite
du projet tout en précisant certains éléments.
Sur l’aspect humain, le suivi et la mise en place des données de ViennAgglo dans le
système ne nécessitent pas de moyens supplémentaires. Ce travail peut être absorbé par
l’équipe actuelle. Il subsiste cependant les opérations très importantes de documentation des
fiches du catalogue. Nous envisageons de confier ce travail à un stagiaire dans le cadre d’un
sujet qui porterait sur :
l’inventaire et la définition de la pertinence des données en relation avec les
services et les partenaires,
la détermination des droits et des conditions juridiques et financières de leur
diffusion,
la conformité à INSPIRE et le choix de la licence de diffusion.
Sur l’aspect matériel, comme indiqué précédemment, les outils et les capacités de
stockage sont suffisants. Cependant, nous risquons à terme de ne pas disposer d’un débit
entrant/sortant suffisant lorsque la plate-forme montera en puissance.
C’est pourquoi nous préconisons de sous-traiter l’hébergement de la solution chez un
prestataire externe (type OVH). Le coût annuel de ce service est estimé à 2400,00 € Hors
TVA.
*Références
Loi n° 78-753 du 17 juillet 1978 portant diverses mesures d’amélioration des relations entre
l’administration et le public, modifiée par l’ordonnance 2005-650 du 6 juin 2005 relative à la liberté
d’accès aux documents administratifs et à la réutilisation des informations publiques. Et en particulier
le chapitre II de la loi.
Directive européenne n°2003/98/CE du 17 novembre 2003 concernant la réutilisation des
informations du secteur public (transposée par l’ordonnance de 2005).
Décret n° 2005-1755 du 30 décembre 2005, Titre III concernant la réutilisation. Circulaire du
Premier ministre n° 5156/SG du 29 mai 2006.
5
ANNEXE 1
L’OPENDATA
6
ANNEXE 2
Pages d’accueil de la plate-forme geo.viennagglo.fr
7
ANNEXE 3
Exemple de fiche de métadonnées
8
9
Annexe 4 : Documentation installation geOrchestra
Pour la mise en place de cette documentation le logiciel Sphinx a été utilisé.
Sphinx est un logiciel libre de type générateur de documentation. Il s'appuie sur des
fichiers au format rst (reStructuredText), qu'il convertit en HTML, PDF, man, et autres formats.
Il a été développé par Geord Brandl pour la communauté Python en 2008. (Wikipedia)
Pour générer une documentation avec Sphinx tout se passe dans un ou plusieurs fichiers
*.rst. Ensuite il suffit de compiler ces fichiers en choisissant un type de fichier de sortie (html
pour en faire un site web, LaTeX pour générer ensuite un pdf, …)
- 52 Julien FRANCOIS - 31/07/2014
geOrchestra Documentation
Release 2.0
Julien
July 28, 2014
CONTENTS
1
Introduction
1
2
Configuration des serveurs
2.1 Logiciels prérequis . . . . . . . . .
2.2 Configuration PostgreSQL/PostGIS
2.3 LDAP (Serveur 1) . . . . . . . . .
2.4 APACHE 2 (Serveur 2) . . . . . . .
2.5 APACHE 2 (Serveur 1) . . . . . . .
2.6 JAVA (serveur 1&2) . . . . . . . .
2.7 TOMCAT (serveur 1&2) . . . . . .
2.8 GDAL/OGR/JAI . . . . . . . . . .
.
.
.
.
.
.
.
.
3
3
3
3
4
4
8
8
11
3
Georchestra
3.1 Point de départ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Deploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
13
13
13
4
Configuration
4.1 shared.maven.filter
4.2 analytics . . . . .
4.3 cas-server-webapp
4.4 extractorapp . . .
4.5 geoserver-webapp
4.6 header . . . . . .
4.7 LDAP Admin . . .
4.8 mapfishapp . . . .
4.9 security-proxy . .
.
.
.
.
.
.
.
.
.
15
15
15
15
15
16
16
16
16
16
5
Gestion des addons
5.1 Cadastre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Loupe Orthophoto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
19
20
6
Mise à jour 14.06
6.1 Dossier de configuration . .
6.2 Migration base geonetwork
6.3 Supressions des “-privates”
6.4 LDAP . . . . . . . . . . . .
.
.
.
.
23
23
24
25
25
Codes
7.1 Création de la base PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
27
7
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
i
7.2
7.3
8
ii
Code Python CGI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Script de compilation & deploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
31
Memo, pense-bête
8.1 Fonctionnement du proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2 Accès privé aux couches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3 Créer un service tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
35
35
36
CHAPTER
ONE
INTRODUCTION
Cette documentation a pour but de décrire la mise en place de la plateforme geOrchestra suivant l’architecture cidessous. Cette architecture est composée de deux serveurs* et les webapps de geOrchestra sont divisées sur quatres
instances de Tomcat. Le serveur 2 met en place un load balancing entre deux instances de Tomcat contenant chacunes
un Geoserver.
La rédaction de cette documentation est passée par la mise en place de plusieurs machine virtuelle et a pour base la
documentation disponible sur le dépot geOrchestra de GitHub. Elle n’est pas exhaustive et a été rédigé par prise de
notes.
Avant d’entrer à proprement dit dans l’installation de geOrchestra, il est necessaires de configurer les serveurs.
Serveur Linux sous Debian 7.4
Ce travail est ditribué sous licence Licence Ouverte
1
geOrchestra Documentation, Release 2.0
Figure 1.1: Architecture de la solution.
2
Chapter 1. Introduction
CHAPTER
TWO
CONFIGURATION DES SERVEURS
2.1 Logiciels prérequis
Avant de commencer avec les logiciels requis, quelques logiciels facultatifs pour le confort de travail:
• Openssh pour travailler avec putty
• Samba pour partager les dossiers avec le poste de travail
• Postfix comme serveur mail
apt-get install openssh-server samba postfix
Pour pouvoir compiler depuis les sources
apt-get install build-essential python-virtualenv python-dev
2.2 Configuration PostgreSQL/PostGIS
PostgreSQL est déjà installé sur un serveur distant. Il ne reste plus qu’à créer la base qui accueillera nos données. On
peut le faire à partir du client PGAdmin. PostGIS est déjà installé et configuré.
Attention la base geofence n’est pas deployée ici.
• Se connecter avec un utilisateur ayant les droits d’ecriture
• Création d’une base “georchestra” avec comme template celui livré à l’installation de PostGIS
• Execution des requêtes SQL du dépot GitHub geOrchestra(Pour le code complet à executer, voir Création de la
base PostgreSQL)
• Création d’une base “geonetwork” avec comme template celui livré à l’installation de PostGIS
2.3 LDAP (Serveur 1)
Installation
apt-get install slapd ldap-utils git-core
cd /home/user/download
git clone git://github.com/georchestra/LDAP.git
cd LDAP
3
geOrchestra Documentation, Release 2.0
Configuration
ldapadd -Y EXTERNAL -H ldapi:/// -f georchestra-bootstrap.ldif
ldapadd -D"cn=admin,dc=georchestra,dc=org" -W -f georchestra-root.ldif
ldapadd -D"cn=admin,dc=georchestra,dc=org" -W -f georchestra.ldif
2.4 APACHE 2 (Serveur 2)
Pour le serveur 2 on installe simplement apache
apt-get install apache2
2.5 APACHE 2 (Serveur 1)
Installation d’apache et configuration du site georchestra.
apt-get install apache2
a2enmod proxy_ajp proxy_connect proxy_http proxy ssl rewrite headers
service apache2 graceful
#Création du fichier de configuration du nouveau site
cd /etc/apache2/sites-available
a2dissite default default-ssl #Desactivation des sites par defaut
touch georchestra #Creation du Virtual host de notre site
Modification du fichier créé
<VirtualHost *:80>
ServerName vm-georchestra
DocumentRoot /var/www/georchestra/htdocs
LogLevel warn
ErrorLog /var/www/georchestra/logs/error.log
CustomLog /var/www/georchestra/logs/access.log "combined"
Include /var/www/georchestra/conf/*.conf
ServerSignature Off
</VirtualHost>
<VirtualHost *:443>
ServerName vm-georchestra
DocumentRoot /var/www/georchestra/htdocs
LogLevel warn
ErrorLog /var/www/georchestra/logs/error.log
CustomLog /var/www/georchestra/logs/access.log "combined"
Include /var/www/georchestra/conf/*.conf
SSLEngine On
SSLCertificateFile /var/www/georchestra/ssl/georchestra.crt
SSLCertificateKeyFile /var/www/georchestra/ssl/georchestra-unprotected.key
SSLCACertificateFile /etc/ssl/certs/ca-certificates.crt
ServerSignature Off
</VirtualHost>
Configuration du dossier
a2ensite georchestra
cd /var/www
mkdir georchestra
4
Chapter 2. Configuration des serveurs
geOrchestra Documentation, Release 2.0
cd georchestra
mkdir conf htdocs logs ssl
chgrp www-data logs/
chmod g+w logs/
Page d’erreur
mkdir -p /var/www/georchestra/htdocs/errors
wget http://sdi.georchestra.org/errors/50x.html -O /var/www/georchestra/htdocs/errors/50x.html
ProxyPass (/var/www/georchestra/conf/proxypass.conf)
<IfModule !mod_proxy.c>
LoadModule proxy_module /usr/lib/apache2/modules/mod_proxy.so
</IfModule>
<IfModule !mod_proxy_http.c>
LoadModule proxy_http_module /usr/lib/apache2/modules/mod_proxy_http.so
</IfModule>
RewriteLog /tmp/rewrite.log
RewriteLogLevel 3
SetEnv no-gzip on
ProxyTimeout 999999999
AddType application/vnd.ogc.context+xml .wmc
RewriteEngine On
RewriteRule ^/analytics$ /analytics/ [R]
RewriteRule ^/cas$ /cas/ [R]
RewriteRule ^/catalogapp$ /catalogapp/ [R]
RewriteRule ^/downloadform$ /downloadform/ [R]
RewriteRule ^/extractorapp$ /extractorapp/ [R]
RewriteRule ^/geoserver$ /geoserver/ [R]
RewriteRule ^/geofence$ /geofence/ [R]
RewriteRule ^/geowebcache$ /geowebcache/ [R]
RewriteRule ^/header$ /header/ [R]
RewriteRule ^/ldapadmin$ /ldapadmin/ [R]
RewriteRule ^/ldapadmin/privateui$ /ldapadmin/privateui/ [R]
RewriteRule ^/mapfishapp$ /mapfishapp/ [R]
RewriteRule ^/proxy$ /proxy/ [R]
RewriteRule ^/geonetwork-private/?(.*)$ /geonetwork/$1 [R]
ErrorDocument 502 /errors/50x.html
ErrorDocument 503 /errors/50x.html
ProxyPass /casfailed.jsp ajp://localhost:8009/casfailed.jsp
ProxyPassReverse /casfailed.jsp ajp://localhost:8009/casfailed.jsp
ProxyPass /j_spring_cas_security_check ajp://localhost:8009/j_spring_cas_security_check
ProxyPassReverse /j_spring_cas_security_check ajp://localhost:8009/j_spring_cas_security_check
ProxyPass /j_spring_security_logout ajp://localhost:8009/j_spring_security_logout
ProxyPassReverse /j_spring_security_logout ajp://localhost:8009/j_spring_security_logout
<Proxy ajp://localhost:8009/analytics/*>
Order deny,allow
Allow from all
</Proxy>
2.5. APACHE 2 (Serveur 1)
5
geOrchestra Documentation, Release 2.0
ProxyPass /analytics/ ajp://localhost:8009/analytics/
ProxyPassReverse /analytics/ ajp://localhost:8009/analytics/
<Proxy ajp://localhost:8009/cas/*>
Order deny,allow
Allow from all
</Proxy>
ProxyPass /cas/ ajp://localhost:8009/cas/
ProxyPassReverse /cas/ ajp://localhost:8009/cas/
<Proxy ajp://localhost:8009/catalogapp/*>
Order deny,allow
Allow from all
</Proxy>
ProxyPass /catalogapp/ ajp://localhost:8009/catalogapp/
ProxyPassReverse /catalogapp/ ajp://localhost:8009/catalogapp/
<Proxy ajp://localhost:8009/downloadform/*>
Order deny,allow
Allow from all
</Proxy>
ProxyPass /downloadform/ ajp://localhost:8009/downloadform/
ProxyPassReverse /downloadform/ ajp://localhost:8009/downloadform/
<Proxy ajp://localhost:8009/extractorapp/*>
Order deny,allow
Allow from all
</Proxy>
ProxyPass /extractorapp/ ajp://localhost:8009/extractorapp/
ProxyPassReverse /extractorapp/ ajp://localhost:8009/extractorapp/
<Proxy ajp://localhost:8009/geonetwork/*>
Order deny,allow
Allow from all
</Proxy>
ProxyPass /geonetwork/ ajp://localhost:8009/geonetwork/
ProxyPassReverse /geonetwork/ ajp://localhost:8009/geonetwork/
<Proxy ajp://localhost:8009/geonetwork-private/*>
Order deny,allow
Allow from all
</Proxy>
ProxyPass /geonetwork-private/ ajp://localhost:8009/geonetwork-private/
ProxyPassReverse /geonetwork-private/ ajp://localhost:8009/geonetwork-private/
<Proxy ajp://localhost:8009/geoserver/*>
Order deny,allow
Allow from all
</Proxy>
ProxyPass /geoserver/ ajp://localhost:8009/geoserver/
ProxyPassReverse /geoserver/ ajp://localhost:8009/geoserver/
<Proxy ajp://localhost:8009/geofence/*>
Order deny,allow
Allow from all
</Proxy>
ProxyPass /geofence/ ajp://localhost:8009/geofence/
ProxyPassReverse /geofence/ ajp://localhost:8009/geofence/
6
Chapter 2. Configuration des serveurs
geOrchestra Documentation, Release 2.0
ProxyPass /geowebcache/ ajp://localhost:8009/geowebcache/
ProxyPassReverse /geowebcache/ ajp://localhost:8009/geowebcache/
<Proxy ajp://localhost:8009/ldapadmin/*>
Order deny,allow
Allow from all
</Proxy>
ProxyPass /ldapadmin/ ajp://localhost:8009/ldapadmin/
ProxyPassReverse /ldapadmin/ ajp://localhost:8009/ldapadmin/
<Proxy ajp://localhost:8009/mapfishapp/*>
Order deny,allow
Allow from all
</Proxy>
ProxyPass /mapfishapp/ ajp://localhost:8009/mapfishapp/
ProxyPassReverse /mapfishapp/ ajp://localhost:8009/mapfishapp/
<Proxy ajp://localhost:8009/proxy/*>
Order deny,allow
Allow from all
</Proxy>
ProxyPass /proxy/ ajp://localhost:8009/proxy/
ProxyPassReverse /proxy/ ajp://localhost:8009/proxy/
<Proxy ajp://localhost:8009/header/*>
Order deny,allow
Allow from all
</Proxy>
ProxyPass /header/ ajp://localhost:8009/header/
ProxyPassReverse /header/ ajp://localhost:8009/header/
<Proxy ajp://localhost:8009/_static/*>
Order deny,allow
Allow from all
</Proxy>
ProxyPass /_static/ ajp://localhost:8009/_static/
ProxyPassReverse /_static/ ajp://localhost:8009/_static/
Certification SSL
cd /var/www/georchestra/ssl
openssl genrsa -des3 -out georchestra.key 1024
openssl req -new -key georchestra.key -out georchestra.csr
Common name : vm-georchestra
openssl rsa -in georchestra.key -out georchestra-unprotected.key
openssl x509 -req -days 365 -in georchestra.csr -signkey georchestra.key -out georchestra.crt
service apache2 graceful
sudo nano /etc/hosts
127.0.0.01 vm-georchestra
Test : http://vm-georchestra https://vm-georchestra
2.5. APACHE 2 (Serveur 1)
7
geOrchestra Documentation, Release 2.0
2.6 JAVA (serveur 1&2)
apt-get install openjdk-7-jdk
2.7 TOMCAT (serveur 1&2)
Le schéma de l’architecture montre que trois instances de Tomcat sont présentes. Elles seront nommées comme suit :
Serveur 1 :
• Tomcat60 : Instance contenant le CAS et le security proxy.
• Tomcat61 : Instance contenant toutes les webapps sauf geoserver, le CAS et le proxy.
Serveur 2 :
• Tomcat62 : Instance contenant geoserver.
• Tomcat63 : Instance contenant geoserver.
2.7.1 Utilisateur
Un utilisateur spécifique est créé pour gérer Tomcat.
groupadd tomcat
useradd -g tomcat -s /usr/sbin/nologin -m -d /home/tomcat tomcat
Cet utilisateur ne peut pas se logguer il sert uniquement à lancer Tomcat et stopper Tomcat de cette manière :
cd /opt/tomcat6/tomcat6X/bin #Avec X, une instance de Tomcat
su -p -s /bin/sh tomcat startup.sh
su -p -s /bin/sh tomcat shutdown.sh
Il est possible de créer des services pour gérer plus facilement les instances (Voir Créer un service tomcat)
2.7.2 Installation
Pour créer plusieurs instances de Tomcat, la solution la plus souple est de télécharger le tar.gz plutôt que d’utiliser un
apt-get install (liens symboliques...).
#Serveur 1&2
mkdir /opt/tomcat6
cd /opt/tomcat6
wget http://apache.crihan.fr/dist/tomcat/tomcat-6/v6.0.39/bin/apache-tomcat-6.0.39.tar.gz
tar -xf apache-tomcat-6.0.39.tar.gz
Cloner le dossier une fois pour chaque instance.
#serveur 1
cp -R apache-tomcat-6.0.39 tomcat60
mv apache-tomcat-6.0.39 tomcat61
#serveur 2
cp -R apache-tomcat-6.0.39 tomcat62
mv apache-tomcat-6.0.39 tomcat63
L’utilisateur tomcat est propriétaire des trois instances.
8
Chapter 2. Configuration des serveurs
geOrchestra Documentation, Release 2.0
#serveur
chown -R
chown -R
#serveur
chown -R
chown -R
1
tomcat:tomcat
tomcat:tomcat
2
tomcat:tomcat
tomcat:tomcat
tomcat60
tomcat61
tomcat62
tomcat63
2.7.3 Configuration
• Variable d’environnement
Les scripts startup.sh et shutdown.sh des dossiers bin doivent être modifiés. (/opt/tomcat6/tomcat6X/bin)
export
export
export
export
export
JAVA_HOME=/usr/lib/jvm/java-1.7.0-openjdk-amd64
PATH=$JAVA_HOME/bin:$PATH
BASEDIR=/opt/tomcat6/tomcat6X
CATALINA_BASE=/opt/tomcat6/tomcat6X
CATALINA_HOME=/opt/tomcat6/tomcat6X
Dans les scripts catalina.sh (/opt/tomcat6/tomcat6X/bin), rajouter :
Tomcat60
JAVA_OPTS="$JAVA_OPTS -Djava.awt.headless=true -Xms128m -Xmx256m -XX:MaxPermSize=256m"
JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.trustStore=/opt/share/keystore -Djavax.net.ssl.trustStorePasswo
Tomcat61
JAVA_OPTS="$JAVA_OPTS
JAVA_OPTS="$JAVA_OPTS
#GEONETWORK
JAVA_OPTS="$JAVA_OPTS
#EXTRACTORAPP
JAVA_OPTS="$JAVA_OPTS
#GDAL
JAVA_OPTS="$JAVA_OPTS
-Djava.awt.headless=true -Xms512m -Xmx1024m -XX:MaxPermSize=256m"
-Djavax.net.ssl.trustStore=/opt/share/keystore -Djavax.net.ssl.trustStorePasswo
-Dgeonetwork.dir=/home/user/geonetwork_datadir -Dgeonetwork-private.schema.dir=
-Dorg.geotools.referencing.forceXY=true -Dextractor.storage.dir=/home/user/tmp_
-Djava.library.path=/var/sig/gdal/NativeLibs"
Tomcat62 & Tomcat63
JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.trustStore=/opt/share/keystore -Djavax.net.ssl.trustStorePasswo
#GEOSERVER
JAVA_OPTS="$JAVA_OPTS -Xms2G -Xmx2G -XX:PermSize=256m -XX:MaxPermSize=256m -DGEOSERVER_DATA_DIR=/var/
L’utilisateur Tomcat doit être propriétaire des dossiers qu’il utilise : geoserver_datadir, geowebcache_datadir...
chown -R tomcat:tomcat geoserver_datadir
• server.xml
Ensuite, les numéros de port doivent être modifiés pour que chaque instance écoute sur un port différent. Les instances
1, 2 et 3 n’ont pas besoin du port SSL.
Nom de l’instance
Tomcat60
Tomcat61
Tomcat62
Tomcat63
Connecteur HTTP
8080
8180
8280
8380
Connecteur JK
8009
8109
8209
8309
Port d’arrêt
8005
8105
8205
8305
Port SSL
8443
x
x
x
Modifier les ports dans le fichier server.xml en suivant le tableau ci-dessus.
2.7. TOMCAT (serveur 1&2)
9
geOrchestra Documentation, Release 2.0
cd /opt/tomcat6/tomcat6X/conf
nano server.xml
Modifier la configuration des connecteurs
#Exemple pour l’instance 1
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
URIEncoding="UTF-8"
redirectPort="8443" />
<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
URIEncoding="UTF-8"
maxThreads="150" scheme="https" secure="true"
clientAuth="false"
keystoreFile="/opt/share/keystore"
keystorePass="mdp"
compression="on"
compressionMinSize="2048"
noCompressionUserAgents="gozilla, traviata"
compressableMimeType="text/html,text/xml,text/javascript,application/x-javascript,application/java
<Connector URIEncoding="UTF-8"
port="8009"
protocol="AJP/1.3"
connectionTimeout="20000"
redirectPort="8443" />
• Manager
Par défaut, le manager n’est pas accessible puisque aucun utilisateur n’existe. Pour créer l’utilisateur, modifier le
fichier /opt/tomcat6/tomcat6X/conf/tomcat-users.xml dans chaque instance de Tomcat
<tomcat-users>
<role rolename="manager-gui"/>
<user username="admin" password="mdp" roles="manager-gui"/>
</tomcat-users>
• WebApp ROOT
Supprimer la webapp ROOT des trois instances
• Keystore
Création du keystore (dans le dossier share)
cd /opt/share/keystore
keytool -genkey -alias georchestra_localhost -keystore keystore -storepass mdp -keypass mdp -keyalg R
Prénom et nom : localhost
2.7.4 Load Balancing (serveur 2)
Mise en place
D’après http://java4it.blogspot.fr/2008/09/tutoriel-load-balancing-avec-apache-et.html
• Copier depuis /etc/apache2/mods-available
proxy_balancer.load, proxy_balancer.conf
10
vers
/etc/apache2/mods-enabled
:
proxy_ajp.load,
Chapter 2. Configuration des serveurs
geOrchestra Documentation, Release 2.0
• Ajouter l’attribut jvmroute à l’élément engine (dans /opt/tomcat6/tomcat6X/conf/server.xml)
#Tomcat62
<engine name="Catalina" defaulthost="localhost" jvmroute="tomcat62">
#Tomcat63
<engine name="Catalina" defaulthost="localhost" jvmroute="tomcat63">
• Ajouter au fichier proxy_balancer.conf (dans /etc/apache2/mods-enabled/):
<Proxy balancer://mycluster>
BalancerMember ajp://ip_server2:8209 min=10 max=100 route=tomcat62 loadfactor=1
BalancerMember ajp://ip_server2:8309 min=10 max=100 route=tomcat63 loadfactor=1
Order deny,allow
Allow from all
</Proxy>
ProxyPass / balancer://mycluster/ stickysession=JSESSIONID
• Redémarrer les deux instances de Tomcat puis apache2
Gestion du geoserver_datadir
La configuration contenu dans le geoserver_data_dir est chargée uniquement au lancement de Geoserver (donc au
lancement de Tomcat). Il faut donc qu’après chaque modification sur une instance, les autres instances soient synchronisées. L’api REST de Geoserver permet de recharger la conf via la commande reload en mode POST Camptocamp
a écrit un script python qui permet d’exécuter les commandes REST sur chaque instance. Nous l’avons légèrement
modifié pour l’intégrer à notre plateforme. Ce script est executé en mode CGI. Pour ce faire il faut :
• Activer le module cgi d’Apache
• Ajouter dans le virtualhost du site (/etc/apache2/sites-available/georchestra)
ScriptAlias /scripts/ /var/www/georchestra/scripts/
<Directory /var/www/georchestra/scripts/>
AddHandler cgi-script .cgi .py
AllowOverride None
Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from all
</Directory>
• Attention : Les sauts de lignes du fichier python doivent être au format Unix (LF), le propriétaire du dossier est
www-data (l’utilisateur Apache).
• Pour le script voir Code Python CGI
2.8 GDAL/OGR/JAI
L’installation de GDAL est nécessaire pour l’extracteur et permet l’ouverture de plus de format dans Mapfishapp. Elle
permet aussi à Geoserver de supporter plus de formats.
• Activer le support JAI (Serveur 2)
D’après le blog geomatips :
cd /usr/lib/jvm/java-1.7.0-openjdk-amd64/
#Librairies JAI
wget http://download.java.net/media/jai/builds/release/1_1_3/jai-1_1_3-lib-linux-amd64-jdk.bin
2.8. GDAL/OGR/JAI
11
geOrchestra Documentation, Release 2.0
sh jai-1_1_3-lib-linux-amd64-jdk.bin
#Librairies JAI imageIO
wget http://download.java.net/media/jai-imageio/builds/release/1.1/jai_imageio-1_1-lib-linux-amd64-jd
export _POSIX2_VERSION=199209
sh jai_imageio-1_1-lib-linux-amd64-jdk.bin
A noter que les paquets Debian sont disponibles
Relancer TOMCAT (le support JAI doit être passé à TRUE dans l’etat du serveur, si geOrchestra a déjà été déployé)
• Installer les Natives Libs (Serveur 1&2)
Au début, nous avions pris les Natives de geo-solutions, maintenant C2C met à disposition les siennes
cd /home/user/download
wget http://sdi.georchestra.org/%7Epmauduit/gdalogr-java-bindings/gdal-georchestra-debian6-amd64-mifm
tar xvzf gdal-georchestra-debian6-amd64-mifmid-patched.tar.gz
mkdir -p /var/sig/gdal/NativeLibs/
cd /var/sig/gdal/NativeLibs/
#Copier le contenu du dossier java
cd ..
mkdir gdal-data
#Copier le contenu du dossier share
Il faut ensuite définir les variables d’environnement correspondantes. Dans /etc/environnement :
GDAL_DATA="/var/sig/gdal/gdal-data"
LD_LIBRARY_PATH="/var/sig/gdal/NativeLibs:/lib:/usr/lib"
• Installer la libECW
Récupérer l’archive http://mirror.ovh.net/gentoo-distfiles/distfiles/libecwj2-3.3-2006-09-06.zip
unzip libecwj2-3.3-2006-09-06.zip
cd libecwj2-3.3-2006-09-06
./configure
make
make install
• Installer GDAL
Avant de lancer la compilation de GDAL, le paquet libxerces peut-être necessaire :
apt-get install libxerces-c-dev
cd /home/igeo/download
wget http://download.osgeo.org/gdal/1.10.1/gdal-1.10.1.tar.gz
tar xzf gdal-1.10.1.tar.gz
cd gdal-1.10.1
./configure
make
make install
• Installer l’extension GDAL Geoserver
cd /opt/tomcat6/tomcat62/webapps/geoserver/WEB-INF/lib/
wget http://downloads.sourceforge.net/geoserver/geoserver-2.3.2-gdal-plugin.zip
unzip geoserver-2.3.2-gdal-plugin.zip
rm -f geoserver-2.3.3-gdal-plugin.zip
Retour au Sommaire
12
Chapter 2. Configuration des serveurs
CHAPTER
THREE
GEORCHESTRA
3.1 Point de départ
• Cloner le dépôt GitHub de georchestra :
cd /home/user/download
git clone -b 14.01 --recursive https://github.com/georchestra/georchestra.git
• Compiler
cd georchestra
./mvn -Dmaven.test.skip=true -Ptemplate install
3.2 Configuration
La configuration de georchestra se fait en clonant le dossier template du dossier config/configuration. On peut ensuite
modifier les élément de ce dossier et lancer la compilation comme suit.
cd georchestra
./mvn -Dmaven.test.skip=true -Dserver=viennagglo install
On peut aussi compiler une seule webapp à la fois
cd /home/user/download/georchestra/mapfishapp
../mvn -Dmaven.test.skip=true -Dserver=viennagglo install
3.3 Deploiement
Pour compiler/deployer les différentes webapps dans les trois instances de Tomcat, nous avons réalisé le script bash
disponible ici Script de compilation
Retour au Sommaire
13
geOrchestra Documentation, Release 2.0
14
Chapter 3. Georchestra
CHAPTER
FOUR
CONFIGURATION
La configuration de Georchestra se fait en dupliquant le dossier template disponible sous config/configurations/template. Ce dossier est divisé en sous-dossier représentant chacun une webapp. Un seul
fichier est transversale à toutes les webapps : shared.maven.filter. Ce fichier contient des variables qui seront
réutilisées dans toutes les webapps (nom du serveur, adresse mail, utilisateur postgres...). Cette doc présente la
configuration par dossier/webapp. Certains fichiers/dossiers ne sont pas, par défaut, dans la config template, il faut les
copier depuis config/default.
Warning: Seuls les dossiers modifiés dans le cadre de la mise en place de notre plateforme sont présents. Cette
page est donc vouée à évoluer au fur et à mesure de la personnalisation.
4.1 shared.maven.filter
C’est le fichier qui définit les variables globales. La plupart des variables disponibles sont largement commentées. On
y trouve notamment : la langue de l’interface, les paramètres de connexion aux BDD, le niveau de log, l’activation ou
non du formulaire de téléchargement ou encore l’activation ou non des statistiques.
4.2 analytics
Pas de conf particulière, les paramètres sont définis à partir du shared.maven.filter
4.3 cas-server-webapp
Définition du css de la page de login.
4.4 extractorapp
• WEB-INF/templates : Modèles des mails envoyés lors des extractions
• app/js/GEOR_CUSTOM.js
Ce fichier permet de configurer la page d’extraction (couches présentes par défaut dans l’extracteur, emprise par défaut,
les SRS ...)
15
geOrchestra Documentation, Release 2.0
Warning: Il faut utiliser les services WMS pour les startups layers. Les services WFS ne fonctionnent pas
4.5 geoserver-webapp
Le fichier web.xml copié depuis georchestra/geoserver/geoserver-submodule/src/web/app/src/main/webapp/WEBINF/web.xml permet de determiner le geoserver_datadir.
4.6 header
• Modification du logo du header via le dossier img
• Modification du header via le fichier header.jsp (copié depuis home/igeo/download/georchestra/header/src/main/webapp/WEBINF/jsp)
4.7 LDAP Admin
Dans WEB-INF/template (copié depuis default) –> modification des mails envoyés lors d’inscription.
4.8 mapfishapp
• Dans WEB-INF/print : Modification des templates d’impression
• Dans app/js/GEOR_CUSTOM : C’est le fichier principal de configuration. On peut choisir les WMC présents,
les echelles de visualisation, les addons (voir ici), les services proposés par défaut...
• [*].wmc : Web Map Context : Ce sont des fichiers qui chargent une configuration. Une fois dans mapfish on
peut choisir un des contextes disponibles. Ils définissent principalement l’emprise et les couches disponibles.
Note: D’après le cours laval : Standardisé par l’OGC depuis 2005 Document permettant le regroupement d’une ou
plusieurs cartes provenant d’un ou plusieurs services cartographiques (WMS).
On y décrit les informations suivantes:
• le(s) serveur(s) fournissant le(s) couche(s) de la carte générale,
• l’étendue géographique et la projection cartographique de chaque couche partagée,
• des métadonnées opérationnelles pour qu’un logiciel client puisse reproduire la carte générale,
• des métadonnées auxiliaires pour annoter et décrire les cartes et leur provenance.
4.9 security-proxy
Dans le maven.filter, il faut modifier les ports et IP de redirection
16
Chapter 4. Configuration
geOrchestra Documentation, Release 2.0
proxy.defaultTarget=http://localhost:8080
# DEVIENT
proxy.defaultTarget=http://localhost:8180
proxy.geoserver=http://ipserver2:8280
# Avec le load balancing, on ne précise plus le port de geoserver
proxy.geoserver=http://ipserver2
Deuxième chose à modifier, geoserver-private devient geoserver
<entry key="geoserver" value="${proxy.defaultTarget}/geoserver-private/" />\
<entry key="geoserver" value="${proxy.defaultTarget}/geoserver/" />\
Retour au Sommaire
4.9. security-proxy
17
geOrchestra Documentation, Release 2.0
18
Chapter 4. Configuration
CHAPTER
FIVE
GESTION DES ADDONS
L’activation d’un addon se fait dans le fichier de configuration GEOR_custom de Mapfishapp (/configuration/profil/app/js/).
5.1 Cadastre
Ce plugin permet de localiser une parcelle en renseignant la commune, la section cadastrale et le numero de section.
La recherche par propriétaire est aussi disponible mais elle ne permet pas la localisation de la parcelle. Il faut être
connecté pour avoir accès à cette fonctionnalité.
5.1.1 Activation du plugin
Rajouter dans la variable ADDONS
{
"id": "cadastre", // Nom tel qu’il est présent dans l’arborescence
"name": "Cadastre", // Nom d’affichage
"title": {
"en": "Cadastre",
"es": "Cadastro",
"fr": "Cadatsre"
},
"description": {
"en": "Allow to locate a cadastral parcel",
"es": "Puede localizar una parcela catastral",
"fr": "Permet de localiser une parcelle cadastrale"
}
}
5.1.2 Configuration du plugin
Dans les sources de GeOrchestra/mapfishapp/src/main/webapp/app/addons/cadastre
Le fichier cities.json doit contenir toutes les villes pour lesquelles la recherche est possible. Mise en forme :
{"type":"FeatureCollection","features":[
{"type":"Feature","id":"19","properties":{"nom":"VIENNE","insee":"38544"}},
{"type":"Feature","id":"20","properties":{"nom":"SEYSSUEL","insee":"38487"}},
...
]}
19
geOrchestra Documentation, Release 2.0
Dans le fichier manifest.json modifier les serveurs wfs pour qu’ils correspondent à nos sections et parcelles.
"tab1": {
"field1": {
"file": "citiesVA.json",
"geometry": "the_geom",
"wfs": "http://vm-georchestra/geoserver/wfs",
"typename": "julien:capv_dgi_commune",
"valuefield": "insee",
"displayfield": "nom",
"template": "<b>{nom}</b> ({insee})"
},
"field2": {
"wfs": "http://vm-georchestra/geoserver/wfs",
"typename": "julien:capv_dgi_section",
"geometry": "the_geom",
"matchingproperties": {
"field1": "insee"
},
"valuefield": "designation",
"displayfield": "designation",
"template": "<b>{designation}</b>"
},
"field3": {
"wfs": "http://vm-georchestra/geoserver/wfs",
"typename": "julien:capv_dgi_parcelle",
"geometry": "the_geom",
"matchingproperties": {
"field1": "insee",
"field2": "section"
},
"valuefield": "numparc",
"displayfield": "numparc",
"template": "<b>{numparc}</b> {section}"
}
},
"tab2": {
"field1": {
"this field": "is currently the same as field1 from tab1",
"no config option here": "is taken into account"
},
"field2": {
"wfs": "http://vm-georchestra/geoserver/wfs",
"typename": "julien:capv_dgi_parcelle_unite_fiscale_avancee",
"matchingproperties": {
"field1": "insee"
},
"valuefield": "ddenom",
"displayfield": "ddenom"
}
}
5.2 Loupe Orthophoto
La loupe orthophoto permet d’afficher dans une fenêtre flottante un service wms autre que le fond de plan. On peut
zoomer dans cette fenêtre. Elle est déjà activée par défaut dans le GEOR_custom. Par défaut c’est une image satellite
20
Chapter 5. Gestion des addons
geOrchestra Documentation, Release 2.0
proposée par un service de GeoBretagne. Pour modifier le service c’est dans le manifest.json que ça ce passe
"default_options": {
"mode": "static",
"baseLayerConfig": {
"wmsurl": "http://vm-georchestra/geoserver/wms",
"layer": "julien:CAPV_ORTHO_2009",
"format": "image/jpeg",
"buffer": 8
}
},
Retour au Sommaire
5.2. Loupe Orthophoto
21
geOrchestra Documentation, Release 2.0
22
Chapter 5. Gestion des addons
CHAPTER
SIX
MISE À JOUR 14.06
Le processus de mise à jour est decrit dans les release_notes du depot GiHub de geOrchestra. Nous decrivons ici, les
changements effectués à ViennAgglo
6.1 Dossier de configuration
Quelques modifications dans le dossier de configuration sont à noter :
• Remplacement du dossier CAS par le nouveau
• Suppression du dossier security-proxy (le proxy est définit dans le script GenerateConfig.groovy)
• Suppression des éléments du shared.maven.filter devenu obsolètes
• Ajout du script GenerateConfig.groovy, et modification pour que le proxy fonctionne
...
/**
* updateSecProxyMavenFilters
*/
def updateSecProxyMavenFilters() {
def proxyDefaultTarget = "http://localhost:8180"
def proxyGeoserver= "http://192.168.20.114"
new PropertyUpdate(
path: ’maven.filter’,
from: ’defaults/security-proxy’,
to: ’security-proxy’
).update { properties ->
properties[’cas.private.host’] = "localhost"
properties[’public.ssl’] = "443"
properties[’private.ssl’] = "8543"
properties[’proxy.defaultTarget’] = proxyDefaultTarget
properties[’proxy.geoserver’] = proxyGeoserver
properties[’proxy.mapping’] = """
<entry key="analytics"
value="proxyDefaultTarget/analytics/" />
<entry key="catalogapp"
value="proxyDefaultTarget/catalogapp/" />
<entry key="downloadform" value="proxyDefaultTarget/downloadform/" />
<entry key="extractorapp" value="proxyDefaultTarget/extractorapp/" />
<entry key="geonetwork"
value="proxyDefaultTarget/geonetwork/" />
<entry key="geoserver"
value="proxyGeoserver/geoserver/" />
<entry key="geowebcache"
value="proxyDefaultTarget/geowebcache/" />
<entry key="geofence"
value="proxyDefaultTarget/geofence/" />
23
geOrchestra Documentation, Release 2.0
<entry
<entry
<entry
<entry
key="header"
value="proxyDefaultTarget/header/" />
key="ldapadmin"
value="proxyDefaultTarget/ldapadmin/" />
key="mapfishapp"
value="proxyDefaultTarget/mapfishapp/" />
key="static"
value="proxyDefaultTarget/header/" />""".replaceAll("\n|\t","").repla
properties[’header.mapping’] = """
6.2 Migration base geonetwork
Dans la version 14.06, la base PostgreSQL de Geonetwork devient un schéma de la base georchestra.
• Recuperation de la base geonetwork –> georchestra.sql
• Injection dans la base georchestra
pg_dump.exe --host 192.168.20.101 --port 5432 --username "dyndb" --role "dyndb" --no-password
• Changement des droits d’accès
postgres=# ALTER ROLE geonetwork WITH ENCRYPTED PASSWORD ’www-data’;
postgres=# GRANT ALL PRIVILEGES ON DATABASE georchestra to geonetwork;
postgres=# GRANT ALL PRIVILEGES ON TABLE geonetwork.categories to geonetwork;
georchestra=#
georchestra=#
georchestra=#
georchestra=#
georchestra=#
georchestra=#
georchestra=#
georchestra=#
georchestra=#
georchestra=#
georchestra=#
georchestra=#
georchestra=#
georchestra=#
georchestra=#
georchestra=#
georchestra=#
georchestra=#
georchestra=#
georchestra=#
georchestra=#
georchestra=#
georchestra=#
georchestra=#
georchestra=#
georchestra=#
georchestra=#
georchestra=#
georchestra=#
georchestra=#
georchestra=#
georchestra=#
georchestra=#
georchestra=#
24
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
PRIVILEGES
PRIVILEGES
PRIVILEGES
PRIVILEGES
PRIVILEGES
PRIVILEGES
PRIVILEGES
PRIVILEGES
PRIVILEGES
PRIVILEGES
PRIVILEGES
PRIVILEGES
PRIVILEGES
PRIVILEGES
PRIVILEGES
PRIVILEGES
PRIVILEGES
PRIVILEGES
PRIVILEGES
PRIVILEGES
PRIVILEGES
PRIVILEGES
PRIVILEGES
PRIVILEGES
PRIVILEGES
PRIVILEGES
PRIVILEGES
PRIVILEGES
PRIVILEGES
PRIVILEGES
PRIVILEGES
PRIVILEGES
PRIVILEGES
PRIVILEGES
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
geonetwork.categories to geonetwork;
geonetwork.categoriesdes to geonetwork;
geonetwork.cswservercapabilitiesinfo to geonetwork;
geonetwork.customelementset to geonetwork;
geonetwork.groups to geonetwork;
geonetwork.groupsdes to geonetwork;
geonetwork.harvesthistory to geonetwork;
geonetwork.isolanguages to geonetwork;
geonetwork.isolanguagesdes to geonetwork;
geonetwork.languages to geonetwork;
geonetwork.metadata to geonetwork;
geonetwork.metadatacateg to geonetwork;
geonetwork.metadatanotifications to geonetwork;
geonetwork.metadatanotifiers to geonetwork;
geonetwork.metadatarating to geonetwork;
geonetwork.metadatastatus to geonetwork;
geonetwork.operationallowed to geonetwork;
geonetwork.operations to geonetwork;
geonetwork.operationsdes to geonetwork;
geonetwork.params to geonetwork;
geonetwork.regions to geonetwork;
geonetwork.regionsdes to geonetwork;
geonetwork.relations to geonetwork;
geonetwork.requests to geonetwork;
geonetwork.serviceparameters to geonetwork;
geonetwork.services to geonetwork;
geonetwork.settings to geonetwork;
geonetwork.sources to geonetwork;
geonetwork.statusvalues to geonetwork;
geonetwork.statusvaluesdes to geonetwork;
geonetwork.thesaurus to geonetwork;
geonetwork.usergroups to geonetwork;
geonetwork.users to geonetwork;
geonetwork.validation to geonetwork;
Chapter 6. Mise à jour 14.06
-
geOrchestra Documentation, Release 2.0
6.3 Supressions des “-privates”
Les applications ne comportent plus le suffixe “-private” dorénavant. Plusieurs fichiers sont donc à modifier :
• Les JAVA_OPTS de geonetwork dans le catalina.sh
• Le script de deploiement
6.4 LDAP
Notre base LDAP n’étant pas encore en production au moment du changement de version, nous l’avons supprimé puis
recréé avec les nouvelles préconisations de la version 14.06
Retour au Sommaire
6.3. Supressions des “-privates”
25
geOrchestra Documentation, Release 2.0
26
Chapter 6. Mise à jour 14.06
CHAPTER
SEVEN
CODES
7.1 Création de la base PostgreSQL
-- MAPFISHAPP
create schema mapfishapp;
create table mapfishapp.geodocs (
id bigserial primary key, -- 1 to 9223372036854775807 (~ 1E19)
username varchar(200), -- can be NULL (eg: anonymous user)
standard varchar(3) not null, -- eg: CSV, KML, SLD, WMC
raw_file_content text not null, -- file content
file_hash varchar(32) unique not null, -- md5sum
created_at timestamp without time zone default NOW(), -- creation date
last_access timestamp without time zone, -- last access date
access_count integer default 0 -- access count, defaults to 0
);
create
create
create
create
create
create
index
index
index
index
index
index
geodocs_file_hash on mapfishapp.geodocs using btree (file_hash);
geodocs_username on mapfishapp.geodocs using btree (username);
geodocs_standard on mapfishapp.geodocs using btree (standard);
geodocs_created_at on mapfishapp.geodocs using btree (created_at);
geodocs_last_access on mapfishapp.geodocs using btree (last_access);
geodocs_access_count on mapfishapp.geodocs using btree (access_count);
-- LDAP
CREATE SCHEMA ldapadmin;
SET search_path TO ldapadmin,public,pg_catalog;
CREATE TABLE user_token (
uid character varying NOT NULL,
token character varying,
creation_date timestamp with time zone
);
ALTER TABLE ONLY user_token
ADD CONSTRAINT uid PRIMARY KEY (uid);
CREATE UNIQUE INDEX token_idx ON user_token USING btree (token);
-- DOWNLOAD FORM
create schema downloadform;
27
geOrchestra Documentation, Release 2.0
set search_path to downloadform,public,pg_catalog;
create table log_table (
id serial primary key,
username varchar(200), -- can be NULL (eg: anonymous user)
sessionid varchar(32) not null, -- this is the security-proxy JSESSIONID
first_name varchar(200) not null,
second_name varchar(200) not null,
company varchar(200) not null,
email varchar(200) not null,
phone varchar(100),
requested_at timestamp without time zone default NOW(),
comment text
);
create index log_table_username on log_table using btree (username);
create index log_table_sessionid on log_table using btree (sessionid);
-- GN: log MD id and filename (resource.get parameters)
create table geonetwork_log (
metadata_id integer not null, -- this is not the UUID, but the local ID
filename varchar(200) not null
) inherits (log_table);
create index geonetwork_log_id_fname on geonetwork_log using btree (metadata_id, filename);
-- extractorapp log table, which contains just the JSON spec for now (could be exploited later client
-- json_spec example : {"emails":["[email protected]"],"globalProperties":{"projection":"EPSG:4326","reso
create table extractorapp_log (
json_spec text not null
) inherits (log_table);
create index extractorapp_log_json_spec on extractorapp_log using btree (json_spec);
create table data_use (
id serial primary key,
name varchar(100)
);
-- sample data:
insert into data_use
insert into data_use
insert into data_use
insert into data_use
insert into data_use
insert into data_use
insert into data_use
insert into data_use
insert into data_use
insert into data_use
(name)
(name)
(name)
(name)
(name)
(name)
(name)
(name)
(name)
(name)
values
values
values
values
values
values
values
values
values
values
(’Administratif et budgétaire’);
(’Aménagement du Territoire et Gestion de l’’Espace’);
(’Communication’);
(’Environnement’);
(’Fond de Plan’);
(’Foncier et Urbanisme’);
(’Formation’);
(’Gestion du Domaine Public’);
(’Mise en valeur du Territoire (Tourisme)’);
(’Risques Naturels et Technologiques’);
create table logtable_datause (
logtable_id integer not null,
datause_id integer not null,
primary key (logtable_id, datause_id)
);
-- commented out because it generates an error:
--alter table logtable_datause add constraint fk_logtable_id foreign key (logtable_id) REFERENCES log
28
Chapter 7. Codes
geOrchestra Documentation, Release 2.0
--org.postgresql.util.PSQLException: ERROR: insert or update on table "logtable_datause" violates for
--Detail: Key (logtable_id)=(2) is not present in table "log_table".
-- at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2102)
alter table logtable_datause add constraint fk_datause_id foreign key (datause_id) REFERENCES data_us
create table extractorapp_layers (
id serial primary key,
extractorapp_log_id integer NOT NULL,
projection character varying(12),
resolution double precision,
format character varying(10),
bbox_srs character varying(12),
"left" double precision,
bottom double precision,
"right" double precision,
top double precision,
ows_url character varying(1024),
ows_type character varying(3),
layer_name text
);
create index extractorapp_layers_layer_name on extractorapp_layers using btree (layer_name);
-- STATISTIQUES
CREATE SCHEMA ogcstatistics;
SET search_path TO ogcstatistics,public,pg_catalog;
CREATE TABLE ogc_services_log (
user_name character varying(255),
date date,
service character varying(5),
layer character varying(255),
id bigserial NOT NULL,
request character varying(20),
org character varying(255),
CONSTRAINT primary_key PRIMARY KEY (id )
);
CREATE
CREATE
CREATE
CREATE
INDEX
INDEX
INDEX
INDEX
user_name_index ON ogc_services_log USING btree (user_name);
date_index ON ogc_services_log USING btree (date);
service_index ON ogc_services_log USING btree (service);
layer_index ON ogc_services_log USING btree (layer);
7.2 Code Python CGI
Le script d’origine est disponible ici https://gist.github.com/fvanderbiest/f5d5e467c7ca004ce73b
#!/usr/bin/env python
#-*- coding: utf-8 -*print ’Content-Type: text/html; charset=utf-8\n’
"""This is a script that we use to reload geoserver catalogs when load balancing them"""
7.2. Code Python CGI
29
geOrchestra Documentation, Release 2.0
"""
Copyright 2014 Camptocamp. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are
permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of
conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list
of conditions and the following disclaimer in the documentation and/or other materials
provided with the distribution.
THIS SOFTWARE IS PROVIDED BY CAMPTOCAMP ‘‘AS IS’’ AND ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL CAMPTOCAMP OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
The views and conclusions contained in the software and documentation are those of the
authors and should not be interpreted as representing official policies, either expressed
or implied, of Camptocamp.
"""
config = {
’geoserver’: [
’ipserver2:8280’,
’ipserver2:8380’,
#’’, # next one
]
}
# DO NOT MODIFY ANYTHING BELOW THIS #
# (unless you know what you’re doing)
import cgi
import sys, os
import urllib2
headers = {
"sec-roles": "ROLE_ADMINISTRATOR",
"sec-username": "fake_user",
}
failures = []
for host in config[’geoserver’]:
req = urllib2.Request("http://"+host+"/geoserver/rest/reload?recurse=true", "nothing", headers)
try:
r = urllib2.urlopen(req)
except urllib2.URLError as e:
failures.append((host, e.reason))
#Le retour est json qui sera exploité avec jquery
30
Chapter 7. Codes
geOrchestra Documentation, Release 2.0
if len(failures) == 0:
print ’{"message": "Reload OK", "style": "btn-success"}’
else:
#print "Status: 500 Internal Server Error"
#print ""
#for f in failures:
#print "Reload failed for host %s, reason is ’%s’" % f
print ’{"message": "Reload failed for ’+ failures[0][0] +’, reason is ’+ failures[0][1] +’", "sty
7.3 Script de compilation & deploiement
Script serveur1
#!/bin/bash
date
#VARIABLE DE PROFIL, VERSION et repertoire GitHub
PROFILE=viennagglo
VERSION=14.06
GITDIR=/home/user/download/georchestra_1406/
TOMCAT60=/opt/tomcat6/tomcat60
TOMCAT61=/opt/tomcat6/tomcat61
#REPERTOIRE GEORCHESTRA
cd ${GITDIR}
#COMPILATION
./mvn -Dmaven.test.skip=true -Dserver=${PROFILE} install
#CREATION D’UN DOSSIER TEMPORAIRE
mkdir /tmp/georchestra_deploy_tmp
cd /tmp/georchestra_deploy_tmp
#COPIE DE TOUT LES WAR COMPILE DANS LE DOSSIER TEMPORAIRE
find /root/.m2/repository/ -name "*${VERSION}-${PROFILE}.war" -exec cp {} /tmp/georchestra_deploy_tmp
echo COPY TMP OK
#RENOMMER TOUT LES WAR
mv security-proxy-${VERSION}-${PROFILE}.war ROOT.war
mv analytics-${VERSION}-${PROFILE}.war analytics.war
mv cas-server-webapp-${VERSION}-${PROFILE}.war cas.war
mv catalogapp-${VERSION}-${PROFILE}.war catalogapp.war
mv downloadform-${VERSION}-${PROFILE}.war downloadform.war
mv extractorapp-${VERSION}-${PROFILE}.war extractorapp.war
mv geonetwork-main-${VERSION}-${PROFILE}.war geonetwork.war
mv geoserver-webapp-${VERSION}-${PROFILE}.war geoserver.war
mv ldapadmin-${VERSION}-${PROFILE}.war ldapadmin.war
mv mapfishapp-${VERSION}-${PROFILE}.war mapfishapp.war
mv header-${VERSION}-${PROFILE}.war header.war
mv geowebcache-webapp-${VERSION}-${PROFILE}.war geowebcache.war
echo RENAME OK
#ARRET DE TOMCAT60
service tomcat60d stop
echo TOMCAT60 SHUTDOWN
7.3. Script de compilation & deploiement
31
geOrchestra Documentation, Release 2.0
#ARRET DE TOMCAT61
service tomcat61d stop
echo TOMCAT61 SHUTDOWN
#SUPRESSION DES FICHIERS WAR (TOMCAT60)
rm -Rf ${TOMCAT60}/webapps/ROOT*
rm -Rf ${TOMCAT60}/webapps/cas*
echo WAR60 DELETED
#SUPRESSION DES FICHIERS WAR (TOMCAT61)
rm -Rf ${TOMCAT61}/webapps/analytics*
rm -Rf ${TOMCAT61}/webapps/catalogapp*
rm -Rf ${TOMCAT61}/webapps/downloadform*
rm -Rf ${TOMCAT61}/webapps/extractorapp*
rm -Rf ${TOMCAT61}/webapps/geonetwork*
rm -Rf ${TOMCAT61}/webapps/ldapadmin*
rm -Rf ${TOMCAT61}/webapps/mapfishapp*
rm -Rf ${TOMCAT61}/webapps/header*
rm -Rf ${TOMCAT61}/webapps/geowebcache*
echo WAR61 DELETED
#COPIER le cas et root vers les webapps de TOMCAT60
cp -f /tmp/georchestra_deploy_tmp/cas.war ${TOMCAT60}/webapps
cp -f /tmp/georchestra_deploy_tmp/ROOT.war ${TOMCAT60}/webapps
echo COPY WAR60 OK
#COPIER TOUT LES WAR VERS LES WEBAPPS DE TOMCAT61 SAUF GEOSERVER
cp -f /tmp/georchestra_deploy_tmp/analytics.war ${TOMCAT61}/webapps
cp -f /tmp/georchestra_deploy_tmp/catalogapp.war ${TOMCAT61}/webapps
cp -f /tmp/georchestra_deploy_tmp/downloadform.war ${TOMCAT61}/webapps
cp -f /tmp/georchestra_deploy_tmp/extractorapp.war ${TOMCAT61}/webapps
cp -f /tmp/georchestra_deploy_tmp/geonetwork.war ${TOMCAT61}/webapps
cp -f /tmp/georchestra_deploy_tmp/ldapadmin.war ${TOMCAT61}/webapps
cp -f /tmp/georchestra_deploy_tmp/mapfishapp.war ${TOMCAT61}/webapps
cp -f /tmp/georchestra_deploy_tmp/header.war ${TOMCAT61}/webapps
cp -f /tmp/georchestra_deploy_tmp/geowebcache.war ${TOMCAT61}/webapps
echo COPY WAR61 OK
#DEMARRAGE DE TOMCAT 60
service tomcat60d start
echo TOMCAT60 STARTED
#DEMARRAGE DE TOMCAT 61
service tomcat60d start
echo TOMCAT61 STARTED
#Copie du war geoserver sur le serveur 2
scp /tmp/georchestra_deploy_tmp/geoserver.war root@ipserveur2:/home/user/compil_data
#Lancement du script de deploiement de geoserver sur le serveur 2
ssh root@ipserveur2 /home/user/scripts/DEPLOY.sh
echo -----------------------------------echo -COMPILATION TERMINEE
-date
echo ------------------------------------
Script serveur2
32
Chapter 7. Codes
geOrchestra Documentation, Release 2.0
#!/bin/bash
#ARRET DE TOMCAT62
cd /opt/tomcat6/tomcat62/bin/
su -p -s /bin/sh tomcat shutdown.sh
echo TOMCAT62 SHUTDOWN
#ARRET DE TOMCAT63
cd /opt/tomcat6/tomcat63/bin/
su -p -s /bin/sh tomcat shutdown.sh
echo TOMCAT63 SHUTDOWN
#SUPRESSION DES FICHIERS WAR (TOMCAT62)
rm -Rf /opt/tomcat6/tomcat62/webapps/*geoserver*
echo WAR62 DELETED
#SUPRESSION DES FICHIERS WAR (TOMCAT63)
rm -Rf /opt/tomcat6/tomcat63/webapps/*geoserver*
echo WAR63 DELETED
#COPIER GEOSERVER VERS LES WEBAPPS DE TOMCAT62
cp /home/user/compil_data/geoserver.war /opt/tomcat6/tomcat62/webapps/
mkdir /opt/tomcat6/tomcat62/webapps/geoserver
#DEPLOYER GEOSERVER
cd /opt/tomcat6/tomcat62/webapps
unzip geoserver.war -d geoserver
#AJOUT DU LOG POUR GEOSERVER62
sed -i "60a <context-param>\n<param-name>GEOSERVER_LOG_LOCATION</param-name>\n<param-value>/var/geose
#AJOUT DE L’EXTENSION ECW
cd /opt/tomcat6/tomcat62/webapps/geoserver/WEB-INF/lib/
wget http://downloads.sourceforge.net/geoserver/geoserver-2.3.2-gdal-plugin.zip
unzip geoserver-2.3.2-gdal-plugin.zip
echo WAR62 OK
#COPIER LE GEOSERVER VERS LES WEBAPPS DE TOMCAT63
cp /home/user/compil_data/geoserver.war /opt/tomcat6/tomcat63/webapps/
mkdir /opt/tomcat6/tomcat63/webapps/geoserver
#DEPLOYER GEOSERVER
cd /opt/tomcat6/tomcat63/webapps
unzip geoserver.war -d geoserver
#AJOUT DU LOG POUR GEOSERVER63
sed -i "60a <context-param>\n<param-name>GEOSERVER_LOG_LOCATION</param-name>\n<param-value>/var/geose
#AJOUT DE L’EXTENSION ECW
cd /opt/tomcat6/tomcat63/webapps/geoserver/WEB-INF/lib/
wget http://downloads.sourceforge.net/geoserver/geoserver-2.3.2-gdal-plugin.zip
unzip geoserver-2.3.2-gdal-plugin.zip
echo WAR63 OK
#DEMARRAGE DE TOMCAT 62
cd /opt/tomcat6/tomcat62/bin/
7.3. Script de compilation & deploiement
33
geOrchestra Documentation, Release 2.0
su -p -s /bin/sh tomcat startup.sh
echo TOMCAT62 STARTED
#DEMARRAGE DE TOMCAT 63
cd /opt/tomcat6/tomcat63/bin/
su -p -s /bin/sh tomcat startup.sh
echo TOMCAT63 STARTED
Retour au Sommaire
34
Chapter 7. Codes
CHAPTER
EIGHT
MEMO, PENSE-BÊTE
8.1 Fonctionnement du proxy
Dans Georchestra, les urls sont redirigées plusieurs fois entre le client et la webapp concernée. Le schéma ci-dessous
récapitule les étapes de redirection :
8.2 Accès privé aux couches
Problématique : On veut limiter l’accès à certaines couches à certains utilisateurs. On prend l’exemple des partenaires
urbanistes qui accèdent à toutes les données publiques + les données d’urbanismes
Dans Ldap_admin : Créer un groupe nommé URBA
Dans Geoserver :
• Créer un nouvel espace de travail
• Créer un nouveau rôle ‘ROLE_URBA’
35
geOrchestra Documentation, Release 2.0
• Editer les règle d’accès à l’espace de travail.
• Catalog Mode : mélangé
8.3 Créer un service tomcat
Problématique : On veut démarrer/stopper/redemarrer chaque instance de tomcat facilement via une simple commande. Tomcat doit aussi être lancé au démarrage du serveur.
• Dans /etc/init.d, créer un fichier tomcat60d
#!/bin/bash
### BEGIN INIT INFO
# Provides:
# Required-Start:
# Required-Stop:
# Default-Start:
# Default-Stop:
# Short-Description:
# Description:
### END INIT INFO
/etc/init.d/tomcat60d
$remote_fs $syslog
$remote_fs $syslog
2 3 4 5
0 1 6
Start daemon at boot time
Enable service provided by daemon.
START_TOMCAT=/opt/tomcat6/tomcat60/bin/startup.sh
STOP_TOMCAT=/opt/tomcat6/tomcat60/bin/shutdown.sh
PROG="tomcat60"
start(){
echo -n "Starting $PROG: "
#Demarrer avec l’utilisateur tomcat
su -p -s /bin/sh tomcat ${START_TOMCAT}
echo "done."
}
stop(){
echo -n "Shutting down $PROG: "
su -p -s /bin/sh tomcat ${STOP_TOMCAT}
echo "done."
}
restart(){
stop
sleep 10
start
}
reload(){
restart
}
case "$1" in
start)
start
;;
stop)
stop
;;
36
Chapter 8. Memo, pense-bête
geOrchestra Documentation, Release 2.0
restart)
restart
;;
reload)
reload
;;
)
*
echo "Usage : $0 {start|stop|restart|reload}"
esac
exit 0
• Ajouter le script au services Debian
chkconfig --add tomcat60d
• Rendre executable le script
chmod +x tomcat60d
• Gérer le service via les commandes
service tomcat60d start/stop/restart/reload
• Même chose pour les autres instances de Tomcat
Retour au Sommaire
8.3. Créer un service tomcat
37
