Programmation web: serveur S.I.G. Web JP Kasprzyk & JP ...

Click here to load reader

  • date post

    27-Oct-2021
  • Category

    Documents

  • view

    3
  • download

    0

Embed Size (px)

Transcript of Programmation web: serveur S.I.G. Web JP Kasprzyk & JP ...

Présentation PowerPointProgrammation web: serveur 1
Notes de cours: http://geomatics.ulg.ac.be/download/sigweb/cours/
Programmation web: serveur
• 1. Serveur web
• effectuées par un client (ex: navigateur, SIG-logiciel, …)
» Un serveur web est accessible
• via une adresse IP fixe (ex: 139.165.57.70)
• éventuellement via un nom de domaine (ex: www.monsite.com)
» Adresse IP et nom(s) de domaine permettent la définition d’URL (« Uniform Resource Locator) pour atteindre le serveur
» Le serveur web communique à travers un port (généralement 80 ou 8080)
• Ex: http://www.monsite.com:8080
» Le serveur web peut stocker des pages web statiques (HTML) ou les construire dynamiquement (PHP, Python, Java, NodeJS, …)
» Le serveur web communique avec une base de données locale (architecture 2-tiers) ou distante (architecture 3-tiers)
2
Programmation web: serveur
» PHP + Apache
• PHP est un langage de programmation très populaire pour les serveurs web
• PHP dispose de nombreux frameworks
• Souvent imposé avec le SGBD MySQL dans les hébergements mutualisés
– = hébergements de sites web « low cost » où le programmeur n’a pas accès directement à la machine mais seulement à une BD (interface phpMyAdmin) et à un répertoire web via le protocole FTP
– A l’inverse, un serveur dédié ou cloud offre un accès complet à la machine (connexion « bureau à distance », connexion SSH, …) Linux ou Windows
– Exemples de sociétés d’hébergement « low cost »: OVH (France), Infomaniak (Suisse), …
• Assez pauvre en fonctionnalités spatiales mais compatible avec Postgres/PostGIS
• Apache = serveur HTTP (= serveur web) utilisé conjointement avec PHP
3
4.
Programmation web: serveur
• Langage de référence dans le domaine du SIG
– Langage de programmation de QGIS (PyQGIS) et ArcGIS (ArcPy) pour la création de scripts et d’extensions
– Plusieurs librairies spatiales: GDAL, Geopandas, Cartopy, …
• Permet la création d’un serveur web grâce au module server de la librairie http
• Compatible avec le SGBD Postgres/PostGIS via la librairie psycopg2
• Langage performant avec gestion automatique de la mémoire (« ramasse-miettes »)
• Syntaxe simple
Programmation web: serveur
» Java + Tomcat
• De nombreux outils web populaires dans le domaine spatial sont programmés en Java
– GeoServer: implémentation des services web spatiaux de l’OGC
– 52° North: implémentation du « Sensor Observation Service » de l’OGC
– (Geo)Mondrian: implémentation d’un serveur (S)OLAP pour la manipulation d’entrepôts de données
– GeoNetwork: implémentation d’un catalogue de métadonnées
• Tous ces outils communiquent avec un client HTTP et peuvent être facilement déployés via le serveur web Java Tomcat
– Attention: exploiter deux serveurs http sur la même machine implique l’utilisation de deux ports différents (ex: Python sur port 80 et Tomcat sur port 8080)
• Autre outils SIG développés en Java mais n’étant pas des serveurs web:
– (Geo)Kettle
– OpenJump
Programmation web: serveur
» JavaScript + Node.JS
• NodeJS permet l’exécution de code JavaScript directement sur la machine, en dehors d’un navigateur
• Un serveur http peut être créé avec NodeJS en exploitant uniquement ses modules natifs (programmation « bas niveau »)
• Le serveur web bénéficie ainsi des avantages de JavaScript
– Programmation asynchrone (boucle d’événements)
– Librairies JS côté client généralement compatibles avec NodeJS
– Un même langage pour le backend et le frontend!
6
4.
Programmation web: serveur
– Principes de base du serveur Web
» Peu importe le langage et les outils utilisés, un serveur web fonctionne à peu près de la même manière
» Une fois le serveur web implémenté, un répertoire du serveur (généralement appelé « www » ou « htdocs ») accueille tous les fichiers nécessaires au fonctionnement de votre site/service web: html, css, js, php, py, jpg, gif, …
» En tapant l’adresse (IP ou nom de domaine) de votre serveur dans un navigateur, l’utilisateur accède à la racine de ce répertoire en lecture seule (protocole http)
• ex: http://www.monsite.com
» En nommant un fichier « index.html » (ou index.php), dans le répertoire « www », le serveur http répond en envoyant le contenu de la page index.html au navigateur de l’utilisateur quand celui-ci accède au répertoire
» Idem pour un sous-répertoire
Programmation web: serveur
» Tous les hyperliens faisant référence à d’autres fichiers de votre site sont des adresses relatives au sein du répertoire « www »
• Exemples:
– <script src=‘js/leaflet.js’></script>
= accès au fichier leaflet.js du sous-répertoire « js » de la page courante (ex: index.html à la racine de « www »)
– <a href=‘../page.html’>Lien</a>
= redirection vers la page « page.html » se trouvant dans le répertoire « au dessus »
» Attention, même si tout se trouve au même endroit (répertoire « www »), les codes clients (html, css, js) sont interprétés par le navigateur et les codes serveurs (php, py, …) sont interprétés par le serveur.
• Le navigateur client n’a donc aucun accès à votre code serveur mais uniquement au résultat de son interprétation (par le serveur)
– Ce résultat peut être un string JSON, une image, une page, un « hello world », une page html, …
• La communication entre votre javascript client et votre serveur n’est possible que via une requête ajax
8
4.
Programmation web: serveur
– Exemple concret: peuplement dynamique d’un menu déroulant par des données provenant du serveur
» Démo sur http://geomatics.ulg.ac.be/autres/sigweb
Programmation web: serveur 10
événement onclick
(menu déroulant)
Appel du fichier fonctions.js avec la
définition de la fonction peupleMenu()
4.
Programmation web: serveur
» Fichier fonctions.js
• La fonction peupleMenu() comprend une requête ajax pour demander les <options> du <select>
11
traitement serveur (adresse relative
objet JS
pour la réception du code html
définissant les <options> du <select>
Ajout des <options> dans le <select>
4.
Programmation web: serveur
Programmation web: serveur
• Démo sur: http://geomatics.ulg.ac.be/autres/sigweb/ajax/traitement.php
Programmation web: serveur
2. Protocole des services web géographiques
– L’échange de messages entre clients et serveurs utilisent le langage WSDL et les protocoles HTTP
2.1. WSDL (« Web Service Description Language ») est le standard pour décrire les interfaces des services Web
• Il fournit une grammaire XML décrivant les messages de requêtes et de réponses reçus et envoyés par le serveur, considérés respectivement comme input et output du service décrit.
– À noter que tous les messages n’ont pas besoin de requête / de réponse, et qu’un message d’erreur peut aussi être engendré à la place d’un message d’output.
• Les objets géographiques sont décrits au format GML
4.
Programmation web: serveur
3.1. OWS et WSC
» Parmi les multiples services Web disponibles, l’OGC fournit actuellement plusieurs services géographiques fondamentaux (OWS, pour « OGC Web Services »), permettant le développement d’autres services et applications exploitant l’information géographique.
» Les principaux services ayant le statut de standard international sont :
• WMS / WMTS : Web Map Service.
• WFS : Web Feature Service.
• WCS : Web Coverage Service.
• CSW / WRS : Catalogue Service for the Web / Web Registry Service.
» Les 3 premiers services utilisent tous une interface standard (WSC « Web Services Common ») qui spécifie les éléments communs, tels que :
• Opérations de requêtes et réponses.
• Paramètres et structures de données impliqués dans les requêtes et réponses.
• Encodage XML ou KVP des opérations des requêtes et réponses.
– KVP (« Keyword Value Pair ») : un des types d’encodage des méthodes HTTP utilisant une paire « paramètre : valeur ».
4.
Programmation web: serveur
Spécifications des paramètres et structures de données traités par WSC
4.
Programmation web: serveur
3.2. Opération « GetCapabilities »
» Opération obligatoire fournie par chaque OWS, permettant à tout client de trouver les métadonnées relatives aux capacités d’un serveur implémentant une interface OWS.
• La réponse à cette opération sera transmise au client sous la forme d’un document de métadonnées (par défaut en XML) reprenant, par exemple, les types de données, les formats, etc.
» L’opération admet 6 paramètres, dont 2 sont obligatoires :
• Le nom de la requête : GetCapabilities.
• Le type de service : WFS, WMS ou WCS.
» Le message transmis à l’opération est généralement codé en KVP, à la suite de l’URL (derrière « ? »), avec le caractère « & » comme séparateur des paramètres et le caractère « , » comme séparateur des valeurs (méthode get de HTTP) :
» Il peut aussi être encodé sous la forme d’un document XML (méthode post de HTTP).
4.
Programmation web: serveur
3.3. Opération « ExceptionReport »
» À la suite de la réception d’une erreur dans le message envoyé par le client, chaque OWS doit transmettre un rapport d’erreur signalant au client la cause de l’invalidité de la requête.
» Chaque opération réalisable par un OWS doit pouvoir être documentée par un rapport d’erreur, reprenant plusieurs paramètres, dont :
• Code : code de l’erreur selon une codification littérale standard (obligatoire).
• « Locator » : endroit (paramètre) de la requête où apparaît l’erreur.
» Le rapport d’erreur est un document XML.
• Exemple :
4.
Programmation web: serveur
3.4. Paramètres communs à toute autre opération de requête
» Les requêtes différentes de « GetCapabilities » doivent toujours incorporer 3 paramètres, en plus de leurs paramètres propres permettant l’exécution de l’opération :
• Le type de service : WFS, WMS ou WCS.
• Le nom de la requête : dépend des opérations offertes par le service choisi.
• La version : identifiée par trois entiers positifs séparés par des points.
» Exemple d’encodage en KVP :
3.5. Paramètres communs aux opérations de plusieurs OWS
» Les paramètres suivants sont largement utilisés dans les requêtes et réponses de plusieurs OWS et sont également décrits dans l’interface commune WSC :

Programmation web: serveur
4. WMS (« Web Map Service ») 4.1. Serveur de cartes
» Premier service proposé par l’OGC, dès 2000, les spécifications de WMS ont et continuent d’évoluer (ex. WMTS pour Web Map Tile Service).
» Un service WMS produit dynamiquement une « carte géoréférencée » au départ de données géographiques accessibles au serveur.
• Carte : fichier numérique affichable sur un ordinateur, restituant une image dans un des formats JPEG, PNG ou GIF, ou éventuellement une collection d’éléments vectoriels dans un format SVG (« Scalable Vector Graphics ») ou WebCGM (« Web Computer Graphic Metafile »).
» Construction des cartes composites par le client WMS
• Deux cartes ou plus construites selon les mêmes paramètres peuvent être superposées précisément sur le client pour produire une carte composite.
– L’usage des formats GIF et PNG autorisant un fond transparent, permet de visualiser les cartes superposées.
• Les cartes formant la carte composite peuvent être téléchargées depuis des serveurs distincts.
– Les WMS rendent possible la création d’un réseau de serveurs distributeurs de cartes, à partir desquels les clients peuvent réaliser des cartes originales (mais le mécanisme ne permet pas une symbolisation libre des objets géographiques par l’utilisateur).
4.
Programmation web: serveur
4.2. Types de WMS
» Deux types de WMS peuvent être distingués, en fonction des fonctionnalités qu’ils offrent et des ressources client qu’ils réclament.
• WMS de base dont l’interface contient deux opérations :
– « GetCapabilities » : permettant d’obtenir les métadonnées du service.
– « GetMap » : permettant de télécharger la carte sur le client. Cette opération réclame de nombreux paramètres, mais si la réponse retournée ne contient qu’un fichier image JPEF, GIF ou PNG, un navigateur standard sur le client suffit.
• WMS interrogeable dont l’interface contient une opération supplémentaire :
– « GetFeatureInfo » : permettant d’obtenir des informations sur les objets géographiques formant la carte. Réclame toujours un « client WMS ».
» Client WMS
• Le client doit disposer / accéder à un logiciel dédié à la réception et l’affichage des informations transmises par le service : métadonnées du service et informations sur les objets (XML), cartes raster ou vectorielles.
• Ces logiciels (« viewers ») peuvent utiliser plusieurs technologies Web :
– « JavaScript », « Applet Java », « Java Bean », « ActiveX » ou « Desktop GIS » sur le client.
4.
Programmation web: serveur
Programmation web: serveur
http://cartopro2.wallonie.be/wmspicc/wms110.do?REQUEST=GetCapabilities&VERSION=1.1.0
Interface de connexion et d’ajout de couches WMS (« layers ») dans Q-GIS
« Layers »
Programmation web: serveur
« GetCapabilities »
• Les paramètres d’entrée suivent les spécifications de l’interface commune (WSC), le paramètre définissant le type de service étant WMS.
• Un WMS classe ses conteneurs d’information géographique en couches (« Layers ») et offre un nombre limité de styles pour afficher ces couches.
– Les paramètres principaux de la réponse à cette opération décrivent les layers.
• Principales métadonnées des layers
– Un WMS fournit un ou plusieurs layers, tous documentés, et éventuellement organisés de façon hiérarchique (avec héritage de la plupart des métadonnées).
– Un layer doit toujours avoir un titre et peut avoir un nom (non hérité). S’il a un nom, ce layer peut être invoqué par l’opération « GetMap ».
– Un résumé textuel et des mots clés peuvent être associés au layer.
– « Style » : un ou plusieurs styles peuvent être associés à un layer. Chaque style à un titre « lisible », et un nom codifié utilisable par l’opération « GetMap ». Le style peut disposer d’un résumé et d’un paramètre « LegendURL » contenant la localisation d’une image de la légende exprimée dans le style en question. La légende a deux attributs « width » et « height » qui déterminent la taille de l’image en pixels. S’il n’y a qu’un style associé au layer, le paramètre est omis.
4.
Programmation web: serveur
– « Ex_GeographicBoundingBox » : un layer nommé doit avoir un cadre capable décrit en coordonnées géographiques (j, l – WGS84 implicite).
– « CRS » : un layer doit être associé à au moins un système de référence des coordonnées cartographiques (x, y – plusieurs CRS par layer sont possibles).
– « BoundingBox » : cadre capable en (x, y) du layer toujours associé à un CRS.
– Intervalle d’échelles : dénominateurs des échelles minimale et maximale souhaitables pour l’affichage (résolution estimée à 0,28 mm) du layer. Permet au serveur de sélectionner les layers et les éléments des layers cohérents, notamment dans la construction de cartes composites.
– « Dimension » : fixe les unités et les intervalles de valeurs admises dans chacune des dimensions du layer.
– « MetadataURL » : permet de pointer vers une ressource décrivant les données géographiques du layer dans le détail, selon la norme ISO19115
– « FeatureListURL » et « DataURL » : permettent de pointer vers une liste décrivant tous les objets géographiques présents dans le layer, ou vers une ressource décrivant les données sous-jacentes.
• Chaque layer peut en outre utiliser 6 attributs (héritables) déterminant :
– S’il est questionnable par « GetFeatureInfo »; accédé en cascade depuis un ou plusieurs autres serveurs en amont; opaque ou transparent; affichable par partie, de largeur et hauteur maximales fixes ou modifiables par l’utilisateur.
4.
Programmation web: serveur
• L’opération utilise 15 paramètres en entrée, dont 9 obligatoires.
– « Version » :
– « Request » : « GetMap ».
– « Layer » : liste d’un ou plusieurs noms de layers (voir layers nommés), séparés par des virgules. L’ordre d’affichage mettra le premier layer (gauche dans la liste) à l’arrière plan, et ainsi de suite jusqu’au dernier layer cité à l’avant plan.
– « Styles » : liste d’un ou plusieurs noms de styles (voir paramètres de style), séparés par des virgules et présentés dans le même ordre que les layers dans le paramètre précédent (association automatique par numéro d’ordre). S’il n’existe qu’un style par défaut, la valeur du paramètre est nulle (« STYLES= » ).
– « CRS » : détermine quel système de référence, parmi ceux associés au layer, est à appliquer au paramètre « BBOX ». Le même CRS s’applique à tous les layers d’une même requête. Le standard WMS ne permet pas de réaliser une re- projection en ligne. Néanmoins si le CRS est un système géodésique, le serveur réalisera une projection « Plate-Carrée » de dimensions standard.
– « BBOX » : limites (xmin, ymin, xmax, ymax) définies dans le CRS précédent, de la partie du layer à afficher. Si le layer est affichable par partie (voir attribut du layer), ces limites doivent couvrir au moins une partie du territoire correspondant aux limites annoncées dans les métadonnées du layer mais peuvent les dépasser. Sinon, elles doivent correspondre aux limites des métadonnées du layer.
4.
Programmation web: serveur
– « Format » : format de l’image à transférer, parmi ceux prévus pour le layer. Une requête <Request><GetMap><Format> est utilisée pour connaître les formats disponibles.
– « Width » et « Height » : dimensions en pixels de l’image à construire. Si le rapport hauteur/largeur ne correspond pas à celui défini dans BBOX, le serveur effectue une transformation pour conserver l’aspect défini par BBOX. Si le layer n’est pas modifiable en dimensions (voir attributs du layer), les valeurs de ces deux paramètres doivent être égales à celles fournies par les attributs du layer.
• Les paramètres optionnels d’entrée permettent de choisir si le fond (no data) de l’image est transparent ou non, et de fixer sa couleur (RVB).
• La réponse de l’opération « GetMap »
– Si la requête est valide, le service retourne une carte du layer demandé, géo-référencé, dans le style choisi, et selon la fenêtre, la taille et la transparence souhaitées.
– Si la requête est invalide, le serveur retourne un rapport d’exception (voir WSC).
4.
Programmation web: serveur
« GetFeatureInfo »
• Opération optionnelle, ne pouvant s’appliquer que sur un layer dont le paramètre « queryable » est vrai (=1).
• L’opération retourne des métadonnées (XML) sur l’objet géographique pointé dans la carte par l’utilisateur.
– L’interaction se traduit par le choix des coordonnées-image d’un pixel.
• Comme le protocole HTTP est sans état, il faut rappeler au serveur dans quelle carte la recherche doit être effectuée.
– Il faut reprendre une grande partie des paramètres de l’opération « GetMap ».
• Comme une carte peut contenir plusieurs layers, la requête peut porter sur plusieurs layers (à spécifier) simultanément.
• Les principaux paramètres d’entrée sont :
– « Version » : ‘1.3.0’ et « Request » : « GetFeatureInfo ».
– Tous les paramètres obligatoires du « GetMap » qui a construit la carte interrogée (y compris les deux précédents).
– La liste des layers à interroger (même format que la liste de « GetMap »).
– Le format de sortie (MIME – ex. txt/xml).
– Les coordonnées-image du pixel de recherche.
– Le nombre maximum d’objets à interroger par layer (1 par défaut).
4.
Programmation web: serveur
Interrogation d’un WMS par la fonctionnalité GetFeatureInfo sur le client WMS QGIS
Réponse à
dans le champ de
la carte WMS affichée
Programmation web: serveur
5.1. Serveur d’objets géographiques décrits en GML (par défaut)
» Adopté dès 2002, ce service constitue un des éléments clés du déploiement de GML.
» L’interface fournit un accès standardisé à un objet stocké :
• Elle permet à l’utilisateur de retrouver, charger, créer, mettre à jour ou supprimer, des objets (géographiques), localement ou à travers Internet.
• Les objets et types d’objets géographiques, manipulés par les requêtes et réponses WFS sont décrits par des documents ou des schémas GML.
→ WFS peut donc être considéré comme un serveur de données GML.
» Il est cependant possible de définir un format de récupération des données différent de GML, tel que Shapefile ou JSON, sans garantie de conserver la richesse de description du GML.
• Les formats de sortie prévus sont décrits par l’opération « GetCapabilities »
» Source à lire : Web Feature Service Implementation Specification, Vers. 2.0.0, 02/11/2010, Document OGC 09-025r1 (http://www.opengeospatial.org/standards/wfs).
Programmation web: serveur
– Installations
• https://www.java.com/fr/download/windows-64bit.jsp
• Nécessaire pour faire tourner GeoServer
• https://tomcat.apache.org/
• Déployer la version binaire à la racine du disque C:\
• Configurer une variable d’environnement CATALINA_HOME avec l’adresse du répertoire tomcat (voir étape précédente)
• Configurer une variable d’environnement JRE_HOME avec le répertoire de Java (dans le répertoire « program files »)
• Démarrer le serveur web Tomcat avec la commade « startup.bat » (dans répertoire « bin » de tomcat)
• Tester http://localhost:8080
Programmation web: serveur
• http://geoserver.org/release/stable/
• Copier le fichier war dans le répertoire web de Tomcat (« webapps »)
• Tester http://localhost:8080/geoserver
• Par défaut, les identifiants de l’interface d’administration de geoserver sont:
– Username: admin
– Password: geoserver
» Tutoriel:
• https://docs.geoserver.org/latest/en/user/gettingstarted/postgis- quickstart/index.html
» En résumé:
• Création d’un espace de travail (ex: « sigweb ») = ensemble de couches accessible depuis une URL
• Création d’un « entrepôt » = source de données (PostGIS)
• Création d’une couche associée à un espace de travail et un entrepôt (ex: « cadastre »)
Programmation web: serveur
4.
Programmation web: serveur
4.
Programmation web: serveur
4.
Programmation web: serveur
Programmation web: serveur