Suite

La demande Openlayers3 WMS GetFeatureInfo ne renvoie que des informations pour une fonctionnalité

La demande Openlayers3 WMS GetFeatureInfo ne renvoie que des informations pour une fonctionnalité


J'ai un jeu de données de points dans une carte Openlayers 3. Le but est de pouvoir cliquer sur chaque point et d'afficher les informations sur ce point. Le code ci-dessous fonctionne très bien, il charge toutes les couches et lorsque je clique sur un point, il récupère des informations. Cependant, il ne renverra des informations que pour un point, peu importe où je clique sur la carte. Quelqu'un peut-il voir où je me suis trompé ici?

var layer = [ new ol.layer.Tile({ source: new ol.source.MapQuest({layer: 'sat'}) }), new ol.layer.Image({ extent: [16935988.2390421, -3393028.96482803, 17102996.5023459, -3207079.63356002], source : new ol.source.ImageWMS({ url : 'http://geonct.com:80/geoserver/NCTPROP/wms', paramètres : {'LAYERS' : 'NCTPROP:corr'}, serverType : 'geoserver' }) }), nouvelle ol.layer.Image({ étendue : [16935988.2390421, -3393028.96482803, 17102996.5023459, -3207079.63356002], source : nouvelle ol.source.ImageWMS({ url : 'http://geonct.com :80/geoserver/NCTPROP/wms', paramètres : {'LAYERS' : 'NCTPROP:br_web'}, serverType : 'geoserver' }) }), new ol.layer.Tile({ source : new ol.source.TileWMS ({ url : 'http://geonct.com:80/geoserver/NCTPROP/wms', paramètres : {'LAYERS' : 'NCTPROP:br_point'}, serverType : 'geoserver' }) }) ] ; function loadMap(){ var map = new ol.Map({ layer: layer, target: 'map', view: new ol.View({ center: [17031695, -3310901], zoom: 9 }) }); var view = new ol.View({ center : [0, 0], zoom : 1 }); map.on('singleclick', function(evt) { document.getElementById('info').innerHTML ="; var viewResolution = /** @type {number} */ (view.getResolution()); var url = couches[3].getSource().getGetFeatureInfoUrl( evt.coordinate, viewResolution, 'EPSG:3857', {'INFO_FORMAT': 'text/html'}); if (url) { document.getElementById('info'). interneHTML = ''; } }); } ; function layerSwap(evt){layers[evt.value].setVisible(evt.checked); }

Vous devez spécifier les paramètres WMS dans la fonction getGetFeatureInfoUrl().
Dans votre cas, essayez de demander plus de fonctionnalités en ajoutant le paramètre FEATURE_COUNT après INFO_FORMAT.

Par exemple:

var url = layer[3].getSource().getGetFeatureInfoUrl( evt.coordinate, viewResolution, 'EPSG:3857', { 'INFO_FORMAT': 'text/html', 'FEATURE_COUNT': '20' //ou ce que vous voulez } );

Bonne chance


Le paramètre buffer spécifie le nombre de pixels de bordure supplémentaires qui sont utilisés dans les opérations GetMap et GetFeatureInfo. La syntaxe est :

où <bufferwidth> est la largeur du tampon en pixels.

Dans l'opération GetMap, la mise en mémoire tampon inclut des fonctionnalités qui se trouvent en dehors de la zone de délimitation de la demande, mais dont le style est suffisamment épais pour être visible à l'intérieur de la zone de carte.

Dans l'opération GetFeatureInfo, la mise en mémoire tampon crée un “rayon de recherche” autour de l'emplacement de la demande. Les informations sur les entités sont renvoyées pour les entités qui croisent la zone de recherche. Ceci est utile lorsque vous travaillez avec une carte OpenLayers (telle que celles générées par la page Aperçu de la couche) car cela évite de cliquer précisément sur un point pour que les informations sur l'entité appropriées soient renvoyées.

Dans les deux opérations, GeoServer tente de calculer automatiquement la valeur tampon en inspectant les styles de chaque couche. Tous les symboliseurs actifs sont évalués et la taille du plus grand est utilisée (c'est-à-dire le plus grand symboliseur de point, le plus gros symboliseur de ligne). Le dimensionnement automatique de la mémoire tampon ne peut pas être calculé si :

  • le SLD contient des tailles qui sont spécifiées en tant que valeurs d'attribut de fonctionnalité
  • le SLD contient des graphiques externes et ne spécifie pas explicitement leur taille

Dans ce cas, les valeurs par défaut suivantes sont utilisées :

  • 0 pixel pour les requêtes GetMap
  • 5 pixels pour les requêtes GetFeatureInfo (une valeur minimale différente peut être définie via la variable système org.geoserver.wms.featureinfo.minBuffer, par exemple, ajoutez -Dorg.geoserver.wms.featureinfo.minBuffer=10 pour que la mémoire tampon minimale soit de 10 pixels )

Si ceux-ci ne sont pas suffisamment grands, le paramètre explicite peut être utilisé.


Obtenir des capacités¶

Demander¶

Un serveur WMS répondant à un Obtenir des capacités request renvoie des métadonnées sur le service, y compris les opérations et les paramètres pris en charge, ainsi qu'une liste des couches disponibles.

Voici un exemple de requête GetCapabilities :

Trois paramètres (et valeurs) sont transmis au serveur WMS, SERVICE=WMS , VERSION=1.3 et REQUEST=GetCapabilities .

Le paramètre SERVICE indique au serveur qu'une requête WMS est à venir.

Le paramètre VERSION indique au serveur quelle version du WMS est demandée.

Le paramètre REQUEST indique au serveur que l'opération demandée est l'opération GetCapabilities.

La norme WMS exige que les requêtes incluent toujours ces trois paramètres. Le tableau ci-dessous récapitule les paramètres et valeurs nécessaires à l'exécution de la requête.

Paramètres de l'opération GetCapabilities ¶

La description

Nom du service. La valeur est WMS .

Version de service. La valeur est l'une des 1.0.0 , 1.1.0 , 1.1.1 , 1.3 .

Nom de l'opération. La valeur est GetCapabilities .

Réponse¶

La réponse est un document XML de capacités avec une description détaillée du service WMS. Il contient trois sections principales :

Section Capacités Document ¶

Contient des métadonnées de service telles que le nom du service, des mots-clés et des informations de contact pour l'organisation qui exploite le serveur.

Décrit les opérations fournies par le service WMS ainsi que les paramètres et les formats de sortie pour chaque opération.

Répertorie les systèmes de coordonnées et les couches disponibles. Dans certains serveurs (par exemple Geoserver), les couches sont nommées sous la forme « namespace:layer ». Chaque couche fournit des métadonnées de service telles que le titre, le résumé et les mots-clés.

Section de style de couche GetCapabilities¶

La réponse GetCapabilites contient un Couche section, qui détaille le style disponible pour cette couche. Dans l'exemple ci-dessous, le style disponible est défaut.


Obtenir des capacités¶

le Obtenir des capacités opération demande des métadonnées sur les opérations, les services et les données (“capacités”) qui sont offerts par un serveur WMS.

Les paramètres de l'opération GetCapabilities sont :

Paramètre Obligatoire? La description
un service Oui Nom du service. La valeur est WMS .
version Oui Version de service. La valeur est l'une des 1.0.0 , 1.1.0 , 1.1.1 , 1.3 .
demander Oui Nom de l'opération. La valeur est GetCapabilities .

GeoServer fournit les paramètres spécifiques au fournisseur suivants pour l'opération GetCapabilities. Ils sont entièrement documentés dans la section Paramètres du fournisseur WMS.

Paramètre Obligatoire? La description
espace de noms Non limite la réponse aux couches dans un espace de noms donné

Un exemple de requête GetCapabilities est :

Trois paramètres sont transmis au serveur WMS, service=wms , version=1.1.1 et request=GetCapabilities . Le paramètre de service indique au serveur WMS qu'une requête WMS est à venir. Le paramètre de version fait référence à la version de WMS demandée. Le paramètre request spécifie l'opération GetCapabilities. La norme WMS exige que les requêtes incluent toujours ces trois paramètres. GeoServer assouplit ces exigences (en définissant la version par défaut si elle est omise), mais pour la conformité aux normes, elles doivent toujours être spécifiées.

La réponse est un document XML de capacités qui est une description détaillée du service WMS. Il contient trois sections principales :

Un service Contient des métadonnées de service telles que le nom du service, des mots-clés et des informations de contact pour l'organisation qui exploite le serveur.
Demander Décrit les opérations fournies par le service WMS ainsi que les paramètres et les formats de sortie pour chaque opération. Si vous le souhaitez, GeoServer peut être configuré pour désactiver la prise en charge de certaines opérations WMS.
Couche Répertorie les systèmes de coordonnées et les couches disponibles. Dans GeoServer, les couches sont nommées sous la forme “namespace:layer”. Chaque couche fournit des métadonnées de service telles que le titre, le résumé et les mots-clés.


Obtenir la carte¶

le ObtenirCarte L'opération demande que le serveur génère une carte. Les paramètres principaux spécifient une ou plusieurs couches et styles à afficher sur la carte, un cadre de délimitation pour l'étendue de la carte, un système de référence spatiale cible et une largeur, une hauteur et un format pour la sortie. Les informations nécessaires pour spécifier les valeurs des paramètres tels que les couches , les styles et les srs peuvent être obtenues à partir du document Capabilities.

La réponse est une image de carte ou un autre artefact de sortie de carte, selon le format demandé. GeoServer fournit une grande variété de formats de sortie, décrits dans les formats de sortie WMS .

Les paramètres standard pour l'opération GetMap sont :

Paramètre Obligatoire? La description
un service Oui Nom du service. La valeur est WMS .
version Oui Version de service. La valeur est l'une des 1.0.0 , 1.1.0 , 1.1.1 , 1.3.0 .
demander Oui Nom de l'opération. La valeur est GetMap .
couches Oui Couches à afficher sur la carte. La valeur est une liste de noms de couches séparés par des virgules.
modes Oui Styles dans lesquels les calques doivent être rendus. La valeur est une liste de noms de styles séparés par des virgules, ou vide si le style par défaut est requis. Les noms de style peuvent être vides dans la liste, pour utiliser le style de calque par défaut.
srs ou alors crs Oui Système de référence spatiale pour la sortie cartographique. La valeur est au format EPSG:nnn . crs est la clé de paramètre utilisée dans WMS 1.3.0.
bbox Oui Cadre de délimitation pour l'étendue de la carte. La valeur est minx,miny,maxx,maxy en unités du SRS.
largeur Oui Largeur de la sortie de la carte, en pixels.
la taille Oui Hauteur de sortie de la carte, en pixels.
format Oui Format pour la sortie de la carte. Voir Formats de sortie WMS pour les valeurs prises en charge.
transparent Non Si l'arrière-plan de la carte doit être transparent. Les valeurs sont vraies ou fausses. La valeur par défaut est false
bgcolor Non Couleur d'arrière-plan de l'image de la carte. La valeur est sous la forme RRGGBB . La valeur par défaut est FFFFFF (blanc).
exceptions Non Format dans lequel signaler les exceptions. La valeur par défaut est application/vnd.ogc.se_xml .
temps Non Valeur temporelle ou plage des données cartographiques. Voir Prise en charge du temps dans GeoServer WMS pour plus d'informations.
sld Non Une URL référençant un fichier XML StyledLayerDescriptor qui contrôle ou améliore les couches de carte et le style
corps_sld Non Un document XML StyledLayerDescriptor codé en URL qui contrôle ou améliore les couches de carte et le style

GeoServer fournit un certain nombre de paramètres utiles spécifiques au fournisseur pour l'opération GetMap. Ceux-ci sont documentés dans la section Paramètres du fournisseur WMS.

Exemple de requête WMS pour la couche topp:states à sortir en tant qu'image de carte PNG dans SRS EPGS:4326 et l'utilisation du style par défaut est :

La norme spécifie de nombreux paramètres comme étant obligatoires, GeoServer fournit le WMS Reflector pour permettre à beaucoup d'entre eux d'être spécifiés en option.

Expérimenter cette fonctionnalité est un bon moyen de connaître les paramètres de GetMap.

Exemple de requête WMS utilisant un document XML GetMap :

Depuis GeoServer 2.2.0, GeoServer prend en charge un attribut TIME pour les requêtes WMS GetMap comme décrit dans la version 1.3.0 de la spécification WMS. Ce paramètre permet de filtrer un jeu de données par tranches temporelles ainsi que des tuiles spatiales pour le rendu. Voir Prise en charge du temps dans GeoServer WMS pour plus d'informations sur son utilisation.


Le service Sentinel WMS est conforme à la norme WMS. Il donne non seulement accès aux 13 bandes non traitées de Sentinel-2 (B01 à B12 - avec B8A suivant B08), mais également aux produits traités tels que l'imagerie en couleurs vraies et le NDVI. L'accès au service se fait via une instance de serveur personnalisée URL qui vous sera fournie lors de votre inscription.

Il est possible d'obtenir plusieurs instances distinctes (qui agissent comme des services WMS distincts) chacune avec sa propre configuration et sa propre liste de couches qui seront probablement utiles aux utilisateurs avancés. Pour plus d'informations, consultez le chapitre "Configuration WMS".

L'URL de base du service WMS :

Par exemple, une requête GetCapabilities peut être effectuée en modifiant le à l'ID d'instance que vous avez fourni et en ouvrant l'URL suivante :

Certains des produits fournis les plus courants :

  • TRUE_COLOR - une image RVB éclaircie
  • FALSE_COLOR - utilise le proche infrarouge au lieu de la bande bleue
  • NDVI - Indice de végétation par différence normalisée
  • EVI - Indice de végétation amélioré

Liste de tous les produits disponibles produits EO disponibles

Des superpositions d'informations supplémentaires sont également fournies sous forme de couches pour plus de commodité :

  • OUTLINE - dessine un contour autour des zones qui contiennent des données valides
  • REMPLIR - remplit les zones qui contiennent des données valides
  • DATE - dessine les dates des granulés
  • ID - dessine les ID des granulés

Ces superpositions d'informations supplémentaires prennent en charge les styles suivants :

  • COLORÉ (par défaut) - chaque tuile est colorée différemment, avec la couleur calculée à partir de l'ID de la tuile
  • ROUGE, VERT, BLEU, BLANC et NOIR - couleur unie

Le service prend en charge les requêtes WMS standard : GetMap , GetCapabilities , GetFeatureInfo , ainsi que certaines requêtes personnalisées. Les versions WMS prises en charge sont 1.1.1 et 1.3.0.

Le type d'image de sortie du service WMS (Web Map Service) peut être un PNG ou JPEG 8 bits à 1 ou 3 composants ou également un TIFF 8 ou 16 bits à n composants. Utilisez le type approprié lors du réglage du paramètre "FORMAT". Pour JPEG, utilisez "image/jpeg" ou "image/jpg" et pour PNG, utilisez "image/png". Pour le TIFF, si vous utilisez uniquement "image/tiff", le service générera un TIFF 8 bits pour les produits et un TIFF 16 bits pour les bandes Sentinel-2 brutes.

Si vous souhaitez forcer une profondeur de bits TIFF spécifique, utilisez "image/tiffdepth=8", "image/tiffdepth=16" ou "image/tiffdepth=32f" (pour la virgule flottante 32 bits). Lorsque PNG ou TIFF est demandé, le paramètre "TRANSPARENT" détermine si l'image produite aura des pixels transparents où aucune donnée d'entrée n'est disponible ou non.

Pour une liste des systèmes de référence de coordonnées pris en charge, vérifiez le résultat GetCapabilities.

Paramètres d'URL WMS

Paramètres d'URL WMS communs standard (les noms de paramètres sont insensibles à la casse, les valeurs sont sensibles à la casse) :

Norme de version WMS. Facultatif, par défaut : "1.3.0". Valeurs prises en charge : "1.1.1" et "1.3.0".

Ce qui est demandé, valeurs valides : GetMap , GetFeatureInfo , GetCapabilities ou le nom d'une demande personnalisée. Obligatoire.

(lorsque REQUEST = GetMap ou GetFeatureInfo ) L'heure ou la plage horaire pour laquelle renvoyer les résultats, au format ISO8601 (année-mois-date, par exemple : 2016-01-01). Lorsqu'une seule heure est spécifiée, le service renvoie les données jusqu'à l'heure spécifiée. Si une plage de temps est spécifiée, le résultat est basé sur toutes les scènes entre les dates spécifiées conformément aux critères de couverture nuageuse et empilés en fonction du paramètre de priorité - par ex. le plus récent en haut. La plage de temps est écrite sous la forme de deux valeurs de temps séparées par une barre oblique, suivies d'une deuxième barre oblique et d'un paramètre de période (qui doit être P1D). Facultatif, par défaut : aucun (la dernière image valide est renvoyée). Exemples : "TIME=2016-01-01", "TIME=2016-01-01/2016-02-01/P1D".

En plus des paramètres d'URL WMS standard, le service WMS prend également en charge de nombreux paramètres d'URL personnalisés. Voir Paramètres d'URL de service personnalisés pour les détails.

Paramètres d'URL de requête GetMap standard :

Spécifie le cadre de délimitation de l'image demandée. Les coordonnées doivent être dans le système de référence de coordonnées spécifié. Les quatre coordonnées représentant le coin supérieur gauche et inférieur droit du cadre de délimitation doivent être séparées par des virgules. Obligatoire. Exemple : BBOX=-13152499,4038942,-13115771,4020692

(lorsque VERSION 1.3.0 ou supérieure) le système de coordonnées de référence dans lequel la BBOX est spécifiée et dans lequel renvoyer l'image. Facultatif, par défaut : "EPSG:3857". Pour une liste des CRS disponibles, voir le résultat GetCapabilities.

(lorsque VERSION 1.1.1 ou inférieure) le système de référence de coordonnées dans lequel la BBOX est spécifiée et dans lequel renvoyer l'image. Facultatif, par défaut : "EPSG:3857". Pour une liste des CRS disponibles, voir le résultat GetCapabilities.

Le format d'image renvoyé. Facultatif, par défaut : "image/png". Informations détaillées sur les valeurs prises en charge.

Largeur de l'image renvoyée en pixels. Obligatoire, sauf si RESX est utilisé.

Hauteur de l'image renvoyée en pixels. Obligatoire, sauf si RESY est utilisé.

Résolution de l'image horizontale renvoyée en unités UTM (si m est ajouté, par exemple 10 m, en unités métriques). (facultatif au lieu de HAUTEUR)

Résolution de l'image verticale renvoyée en unités UTM (si m est ajouté, par exemple 10 m, en unités métriques). (facultatif au lieu de LARGEUR)

Couleur d'arrière-plan par défaut. Option, par défaut : "FFFFFF". Formats pris en charge : "0xRRGGBB", "0xAARRGGBB", "#RRGGBB", "#AARRGGBB", "RRGGBB", "AARRGGBB".

(lorsque FORMAT = "image/png" ou "image/tiff") L'image renvoyée a un canal alpha qui est vide pour les pixels sans données d'entrée valides ou disponibles. Facultatif, par défaut = "false". Valeurs prises en charge : "true", "false", "0", "1".

La couche préconfigurée (image) à renvoyer. Vous devez spécifier exactement une couche et éventuellement ajouter des superpositions supplémentaires. Obligatoire. Exemple : LAYERS=TRUE_COLOR,OUTLINE

Le format des exceptions. Facultatif, par défaut : "XML". Valeurs prises en charge : "XML", "INIMAGE", "BLANK" (les trois pour la version >= 1.3.0), "application/vnd.ogc.se_xml", "application/vnd.ogc.se_inimage", "application/vnd .ogc.se_blank" (les trois pour la version < 1.3.0).

Paramètres d'URL de requête GetFeatureInfo standard :

Spécifie le cadre de délimitation de la zone qui contient le point interrogé. Les coordonnées sont dans le CRS/SRS spécifié. Quatre coordonnées représentant le coin supérieur gauche et inférieur droit du cadre de délimitation doivent être séparées par une virgule. Obligatoire. Exemple : BBOX=-13152499,4038942,-13115771,4020692

(lorsque VERSION 1.3.0 ou supérieure) le système de référence de coordonnées dans lequel la BBOX est spécifiée. Facultatif, par défaut : "EPSG:3857". Pour une liste des CRS disponibles, voir le résultat GetCapabilities.

(lorsque VERSION 1.1.1 ou inférieure) le système de coordonnées de référence dans lequel la BBOX est spécifiée. Facultatif, par défaut : "EPSG:3857". Pour une liste des CRS disponibles, voir le résultat GetCapabilities.

La largeur de l'espace image contenant le point interrogé, en pixels. Obligatoire.

La hauteur de l'espace image contenant le point interrogé, en pixels. Obligatoire.

Le format de sortie du contenu des informations sur les fonctionnalités. Consultez GetCapabilities pour obtenir une liste des formats pris en charge.

Les couches pour lesquelles les informations sur les caractéristiques sont demandées.

(lorsque VERSION 1.3.0 ou supérieure) Les coordonnées X et Y dans l'espace de l'image de sortie en pixels de l'entité interrogée.

(lorsque VERSION 1.1.1 ou inférieure) Les coordonnées X et Y dans l'espace de l'image de sortie en pixels de l'entité interrogée.

L'exemple ci-dessous montre le contenu de l'objet de résultat de l'analyse d'une réponse de capacités WMS :

Le CREODIAS souhaite placer des cookies sur votre ordinateur pour aider à améliorer ce site Web. En continuant à utiliser le site, vous acceptez notre utilisation des cookies. Si vous n'êtes pas d'accord avec les termes et conditions, veuillez ne pas utiliser le site Web. Apprendre encore plus. J'accepte


La demande Openlayers3 WMS GetFeatureInfo ne renvoie que des informations pour une entité - Systèmes d'information géographique

Marine Regions fournit plusieurs services Web qui permettent à l'utilisateur d'avoir un accès direct aux données géographiques, aux cartes et aux métadonnées à partir d'un bureau SIG ou pour des applications en ligne.

Services Web OGC

Service de carte Web (visualisation des données)

La norme Web Map Service (WMS) fournit une interface HTTP simple pour demander des images cartographiques géo-enregistrées à partir d'une ou plusieurs bases de données géospatiales distribuées. Une requête WMS définit la ou les couches géographiques et la zone d'intérêt à traiter. La réponse à la demande est une ou plusieurs images cartographiques géo-enregistrées (renvoyées au format JPEG, PNG, etc.) qui peuvent être affichées dans un Système d'Information Géographique (SIG) ou dans votre propre application web (OpenLayers, Leaflet. ). Le WMS prend en charge les opérations GetCapabilities, GetMap et GetFeatureInfo telles que définies dans la norme WMS Open Geospatial Consortium (OGC).

Le service WMS des régions marines est accessible à partir du point de terminaison suivant :

Métadonnées WMS (GetCapabilities)

L'opération obligatoire GetCapabilities permet aux clients WMS de récupérer des métadonnées de service à partir d'un serveur. La réponse à une requête GetCapabilities doit être un document XML contenant les métadonnées du service (couches proposées, projections associées, auteur...).

La norme pour construire une requête WMS GetCapabilities, selon la version :

https://geo.vliz.be/geoserver/MarineRegions/wms?SERVICE=WMS&VERSION=X.X.X&REQUEST=Obtenir des capacités

Exemple de requête GetCapabilities adressée au service de visualisation des régions marines :

Visualisation de la carte (GetMap)

En utilisant les informations fournies dans la requête GetCapabilities, la requête GetMap renvoie une image de la couche de données demandée sélectionnée parmi toutes les couches disponibles telles que définies dans le document XML. Les éléments tels que la couche de données, la région, la projection, la taille de l'image renvoyée, le format de l'image, etc. sont définis sous forme d'arguments.

Exemple de requête GetMap qui renvoie une image de la Zone Economique Exclusive de Belgique :

Utilisation des services de carte Web dans les langages SIG/de programmation

Afin d'étudier plus en détail les données fournies ou de les ajouter comme images d'arrière-plan dans les cartes, elles peuvent être chargées dans un logiciel SIG ou invoquées à l'aide de divers langages de programmation. La procédure à suivre sur certaines des plates-formes les plus courantes est expliquée dans les manuels ci-dessous :

  • Charger une couche WMS dans QGIS
  • Chargement d'une couche WMS dans ArcGIS Pro
  • Chargement d'une couche WMS dans R
  • Charger une couche WMS en Python

Service de fonctionnalités Web (téléchargement de données)

WFS définit une norme pour l'échange de données vectorielles en interrogeant à la fois la structure des données et les données source. Les opérations de base sont GetCapabilities, DescribeFeatureType et GetFeature. WFS prend en charge une variété de formats de sortie WFS (par exemple, GML, shapefile, JSON, GeoJSON, CSV. ). La liste complète des formats de sortie pris en charge peut être trouvée en effectuant une requête WFS GetCapabilities.

Le service WFS des régions marines est accessible à partir du point de terminaison suivant :

Métadonnées WFS (GetCapabilities)

Une requête GetCapabilities génère un document de métadonnées (xml) décrivant un service WFS fourni par le serveur ainsi que des opérations et paramètres WFS valides.

La norme pour construire une requête WFS GetCapabilities, selon la version :

https://geo.vliz.be/geoserver/MarineRegions/wfs?SERVICE=WFS&VERSION=X.X.X&REQUEST=Obtenir des capacités

Un exemple de requête GetCapabilities adressée au service de téléchargement Marine Regions :

Informations sur le type d'entité (DescribeFeatureType)

Une demande DescribeFeatureType renvoie une description des types d'entités pris en charge par un service WFS.

Exemple de requête Marine Regions DescribeFeature :

Télécharger les données (GetFeature)

Une requête GetFeature renvoie une sélection d'entités à partir d'une source de données, y compris la géométrie et les valeurs attributaires.

Créer une requête WFS pour obtenir des données

Pour composer votre propre requête, vous devez combiner différentes parties :

  1. l'url de base
  2. la couche demandée
  3. options de filtrage (facultatif)
  4. le format de sortie

Le lien de base pour effectuer une demande WFS vers les régions marines est :

2. La couche demandée

Toutes les couches disponibles dans le service de téléchargement des régions marines peuvent être demandées à l'aide d'une demande getCapabilities.

La syntaxe pour spécifier une couche est :

Si vous souhaitez uniquement télécharger des enregistrements spécifiques d'une couche, vous pouvez ajouter un filtre à la requête WFS. Ce filtre peut prendre en compte (entre autres) la géométrie et les valeurs d'attributs. Les attributs disponibles peuvent être découverts à l'aide d'une requête DescribeFeatureType.

Cet exemple renverra un shapefile de la zone économique exclusive belge (MRGID 3293).

https://geo.vliz.be/geoserver/MarineRegions/wfs?service=WFS&version=1.0.0&request=GetFeature&typeNames=eez&cql_filter=mrgid=3293&outputFormat=FORME-ZIP

Une description plus détaillée de l'utilisation des filtres CQL peut être trouvée dans le manuel GeoServer.

Les données des régions marines sont disponibles dans un certain nombre de formats de sortie, qui sont indiqués à la fin de la demande WFS comme :

Pour les autres formats de sortie, voir la requête GetCapabilities qui renvoie la liste complète des formats de sortie disponibles pour chaque type de requête WFS : https://geo.vliz.be/geoserver/MarineRegions/wfs?service=WFS&version=1.0.0&request=GetCapabilities

Utilisation des services d'entités Web dans les langages SIG/de programmation

Afin d'étudier les données fournies plus en détail ou d'effectuer d'autres analyses spatiales sur celles-ci, elles peuvent être chargées dans un logiciel SIG ou invoquées à l'aide de divers langages de programmation. La procédure à suivre sur certaines des plates-formes les plus courantes est expliquée dans les manuels ci-dessous :

  • Charger une couche WFS dans QGIS
  • Chargement d'une couche WFS dans ArcGIS Pro
  • Chargement d'une couche WFS dans R
  • Charger une couche WFS en Python

Service de catalogue pour le Web (métadonnées)

Le catalogue des régions marines offre la possibilité de rechercher dans sa collection de métadonnées des données, des services et des objets d'information connexes. Le catalogue de données offre un point de terminaison CSW à d'autres applications clientes pour se connecter au service et interroger les métadonnées contenues dans le catalogue.


Procédure pas à pas : superposer un WMS sur une carte en mosaïque avec Leaflet

L'objectif de cette procédure pas à pas est de vous entraîner à superposer différents types de services Web dans Leaflet. Vous publierez d'abord un WMS montrant les marchés de producteurs à Philadelphie. Vous utiliserez ensuite Leaflet pour placer cette couche au-dessus des tuiles de fond de carte Philadelphie que vous avez créées avec TileMill dans la leçon précédente. Vous ajouterez également du code, afin qu'un utilisateur de votre application puisse cliquer sur n'importe quel marché de producteurs et voir plus d'informations dans une fenêtre contextuelle.

Mise en place des marchés de producteurs WMS

La première étape consiste à mettre en place un WMS (passablement) beau montrant les marchés de producteurs à Philadelphie. Dans cette application, le WMS des marchés de producteurs jouera le rôle de la couche métier.

La configuration de ce WMS sera une bonne révision de certaines des compétences que vous avez apprises dans la leçon 4. Dans les endroits où les instructions étape par étape font défaut, vous devriez pouvoir revenir à la procédure pas à pas de la leçon 4 pour vous souvenir des procédures.

  1. Téléchargez ce shapefile des marchés fermiers de Philadelphie. Ceci a été obtenu de la ville de Philadelphie via la bibliothèque PASDA. C'est probablement plus facile si vous l'extrayez dans votre dossier C:dataPhiladelphia.
  2. Ouvrez la page d'administration Web de GeoServer et publiez le fichier de formes du marché des agriculteurs en tant que couche dans GeoServer à l'aide du système de coordonnées EPSG:3857. Mettez-le dans votre espace de travail geog585. Cela devrait ressembler à ce qui suit lorsque vous prévisualisez le calque.

Lorsque vous avez appliqué avec succès le SLD, le WMS doit ressembler à ce qui suit lorsque vous prévisualisez la couche dans GeoServer :

Préparation de l'environnement de développement web

Vous allez maintenant faire quelques préparatifs pour rédiger une simple demande de dépliant. Nous allons héberger cette application sur le mini serveur Web appelé Jetty qui est installé avec GeoServer. N'oubliez pas que dans "le monde réel", vous demanderiez probablement à votre personnel informatique d'installer un serveur Web de niveau entreprise, tel qu'Apache, où vous pourriez exécuter à la fois GeoServer et vos pages HTML. Si vous n'avez pas de personnel informatique, vous aurez peut-être même la chance de le faire vous-même un jour ! :-)

    Arrêtez GeoServer. (Tous les programmes > GeoServer 2.x.x > Arrêter GeoServer)

Tant que GeoServer est démarré, vous devriez maintenant pouvoir accéder à vos pages HTML via une URL telle que http://localhost:8080/geog585/mypage.html (où mypage.html doit être remplacé par le nom du fichier html réel).

Le CSS ci-dessus définit la taille du conteneur de la carte, la taille et la couleur de la bordure de la carte et la couleur de l'arrière-plan.

  1. Enregistrez le fichier dans votre nouveau dossier Jetty sous c:Program FilesGeoServer 2.x.xwebappsgeog585style.css. Si vous obtenez une erreur d'accès refusé, vous devrez modifier les droits d'accès du dossier geog585 afin que votre utilisateur dispose des droits d'accès en lecture et en écriture sur le dossier. Alternativement, vous pouvez essayer d'exécuter votre éditeur de texte en mode Administrateur.
  2. Testez que votre CSS est accessible en ouvrant un navigateur pour http://localhost:8080/geog585/style.css. Vous devriez voir le même fichier CSS.

Si vous obtenez une erreur HTTP 404 "Page non trouvée" et que vous êtes certain que votre URL est correcte (ou essayez-la sans l'extension .css - http://localhost:8080/geog585/style), alors quelque chose s'est peut-être mal passé avec Jetty reconnaissant votre nouveau dossier geog585. J'ai pu contourner cette situation en effectuant un redémarrage complet de la machine et en redémarrant GeoServer. Après cela, le dossier a été reconnu.

Création de la page HTML et écriture du code

Vous allez maintenant créer une page HTML et insérer le code JavaScript qui configure la carte et les fenêtres contextuelles. Les étapes ci-dessous ne fournissent pas le code de manière linéaire. Vous devez insérer le code aux bons endroits, comme indiqué dans les instructions. Le code est hiérarchique, dans le sens où certains blocs s'exécutent dans d'autres. Il est plus intuitif de décrire les blocs de code que de donner le code dans son ordre exact. Si vous ne savez pas où le code est censé aller, reportez-vous à l'exemple de code complet à la fin de cette page de procédure pas à pas.

    Créez un fichier texte vide et enregistrez-le sous marchés.html dans votre dossier Web Jetty (en d'autres termes, c:Program FilesGeoServer 2.x.xwebappsgeog585).

Le code ci-dessus contient l'en-tête et le corps HTML. Cela devrait vous donner un shell d'une page, même si vous ne verrez pas encore la carte s'afficher.

Dans la tête, notez les références aux fichiers Leaflet JavaScript et CSS, tous deux exécutés sur le CDN CloudFlare. Il existe également une référence au style.css que vous avez placé précédemment dans votre dossier Web, qui, dans certains cas, remplace la feuille de style Leaflet. Enfin, il y a une référence à la bibliothèque JavaScript jQuery qui s'exécute sur le CDN de Google. jQuery est une bibliothèque d'assistance qui simplifie grandement certaines tâches JavaScript. Nous allons l'utiliser ici pour faire une demande Web pour interroger le WMS, car il n'y a pas de moyen simple de faire une demande WMS GetFeatureInfo dans Leaflet.

Dans le corps, notez qu'il y a un élément div avec l'identifiant "mapid" qui est destiné à contenir notre carte Web Leaflet. Le style CSS de cet élément est défini dans style.css et définit la largeur et la hauteur de la carte en pixels. Si vous vouliez changer la largeur et la hauteur de la carte, vous modifieriez le CSS.

Lorsque le corps de la page est chargé, il exécute la fonction init() à partir du code JavaScript que nous ajouterons plus tard. C'est pourquoi vous voyez <body onload="init()">.

À partir de ce moment, nous n'apporterons aucun changement à la tête ou au corps. Nous allons insérer la logique JavaScript dans la balise <script>.

Cela configure une variable globale nommée map qui peut être utilisée dans tout votre code JavaScript. Ensuite, une fonction d'initialisation appelée init() est définie, dont vous vous souviendrez qu'il s'agit de la fonction que vous avez définie pour qu'elle s'exécute lorsque le corps de la page se charge. La première chose que fait la fonction est d'instancier un objet map Leaflet dans votre mapid div. Il centre ensuite la carte sur 39,9526 N 75,1652 W au niveau de zoom 13.

Dans cette procédure pas à pas, vous insérerez le JavaScript restant à l'intérieur de la fonction init() où vous voyez le . . . dessus.

  1. Vous allez maintenant ajouter du code pour importer vos tuiles de fond de carte Philly. Insérez ce qui suit dans la fonction init() de votre code, directement après la ligne où vous avez appelé map.setView().

Le code ci-dessus crée une couche de tuiles Leaflet qui fait référence à votre PhillyBasemap que vous avez créé avec TileMill dans la leçon 5. Dans le code ci-dessus, vous devez modifier l'URL pour contenir votre identifiant de compte d'accès PSU afin que l'URL pointe correctement vers votre espace PASS. Votre code peut nécessiter d'autres modifications si l'URL de vos vignettes est légèrement différente. Vérifiez la structure des dossiers de votre espace PASS si vous avez des doutes.

L'URL des tuiles est fournie dans un format générique où z signifie numéro de niveau de zoom, x signifie numéro de colonne et y signifie numéro de ligne. Tant que vous donnez à Leaflet cette structure d'URL de tuile, il sera assez intelligent pour demander les tuiles correctes lorsque vous effectuez un panoramique et un zoom sur la carte.

Remarquez comment la méthode tileLayer.addTo() est utilisée pour ajouter la couche à la carte. L'objet map est passé en paramètre. Dans certaines autres API de mappage comme OpenLayers, vous appelez une méthode add sur la carte elle-même et fournissez la couche en tant que paramètre.

Cela ajoute la couche WMS des marchés fermiers à la carte. Remarquez comment la classe wms de Leaflet est utilisée pour cela. Vous lui donnez certaines propriétés telles que l'URL, les calques et le format d'image que vous souhaitez (tout en utilisant une syntaxe compatible WMS), et Leaflet se charge de formater et d'envoyer les requêtes GetMap et d'afficher les réponses lorsque l'utilisateur effectue un zoom et un panoramique autour de la carte. .

Jusqu'à présent, la création de la carte et l'ajout des couches étaient assez simples. It’s clicking the WMS and seeing a popup that turns out to be more complex. In order to do this, you have to send a WMS GetFeatureInfo request to the server. Leaflet offers no options for this, so you have to do it yourself by constructing a URL, sending it to the server, and reading the response. So how do you make a web request like this using JavaScript?

One way is by using jQuery, an open source API designed for simplifying things that JavaScript programmers have to do day in and day out. One of these tasks is sending web requests to a server while the end user is interacting with a web page (ie, clicking your map). The request is sent using a technique called AJAX (Asynchronous JavaScript and XML) which avoids a total page refresh.

With this in mind, let’s write an Identify function that we can fire off whenever someone clicks the map. This function will construct a WMS GetFeatureInfo request, send the request to the server using AJAX, and put the response into a popup.

  1. Add the following to your code directly after the lines you added above in the place of the . . .:

Above is the Identify function that runs whenever you fire off a mouse event. I haven’t provided this entire function yet because it is long however, I have inserted a … so you can see that together with the definition of this function, an “event listener” is added to the map to keep on the alert for any mouse clicks that occur. If someone clicks the map, the Identify function will be fired and a Leaflet event object called ‘e’ containing some properties of the clicked point will be brought into the function.

Some key things we need in order to construct a GetFeatureInfo request are the bounding coordinates of the map, the width of the map in pixels, and the height of the map in pixels. The Leaflet map object provides ways of getting those properties. That’s what’s happening in the code above. The southwest and northeast corner coordinates of the map are retrieved, and these are formatted into a comma-delimited string in the syntax required by the BBOX parameter. Then the width and height are also retrieved from the Leaflet map.

  1. Continue filling in the Identify function by replacing the … in the code above with the following:

The purpose of this code is to figure out the clicked point and construct the request URL. Although the lines above seem a bit complex, they are essentially getting the row and column of the clicked pixel from the event object (named ‘e’) generated by the mouse click. A URL is then constructed for the GetFeatureInfo request, plugging in the values we derived above for the BBOX, WIDTH, HEIGHT, I, and J parameters.

Be aware that if you named your WMS something other than FarmersMarkets, put it in a workspace other than philadelphia, or placed it in a folder other than geog585, you will need to modify the URL in the above code.

Now let’s add some code to send this request.

  1. Continue filling in the Identify function by replacing the … in the code above with the following code.

The above is a function that uses jQuery to make a GetFeatureInfo request using AJAX. Typically when you see $. in a piece of JavaScript code, it means a jQuery function is being invoked. Remember we brought in a reference to the jQuery library at the top of our page, allowing us to use these functions.

To make the web request, the AJAX function needs a number of options passed in, including the URL, the dataType, the type of request, etc. Another important thing is what to do with the response therefore, we define a little function to handle the response data if the request was successful. First of all, this function checks if a feature came back, because someone could very feasibly click an empty area of the map and get no features in return. Any returned features are provided in an array, and the first feature in that array is referenced above using the variable returnedFeature. For simplicity here, we don’t handle cases where multiple features were returned.

The next order of business is to examine returnedFeature and construct a popup window using its properties. A new Leaflet popup balloon is created using the L.popup class. It is then populated with a little piece of HTML constructed from some of the properties of returnedFeature, namely the NAME and ADDRESS fields of the selected farmers market.

The popup needs to be “anchored” to the map somewhere, therefore the mouse click event object ‘e’ is referenced again to construct the anchor point. A final line of code then opens the popup.

  1. Test your map by opening http://localhost:8080/geog585/markets.html. It should look like the image below. If it doesn't, continue reading for some troubleshooting tips.

Figure 6.7 Final web page after completing the walkthrough

Troubleshooting

If you don't get the expected result at the end of the walkthrough, please verify the following:

  1. Make sure that you are connected to the Internet. In this course, we always reference Leaflet from a content delivery network (CDN) website rather than hosting it on our own server. All of the Leaflet logic is being pulled from the Internet in our case.
  2. Check that GeoServer is started. Note that you may need to stop GeoServer while making adjustments to your code, then start it when you have made your edits and want to preview your work.
  3. Make sure that you are opening the page in your browser via the http://localhost:8080/geog585/markets.htmlURL and not as a local file, e.g. by double-clicking the .html file in the Windows File Explorer.
  4. Check that you have inserted your Penn State Access Account ID into the tile URL as described above.
  5. Check that you have inserted the correct workspace and web service name in your WMS URL as described above.
  6. Make sure your code exactly matches the final code below other than the parts your personalized in the two previous steps.

Final code for the walkthrough

Below is the code used in this walkthrough from start to finish. This should help you get some context of where each block should be placed. If you’re curious how the code would look in a different API, you can download an OpenLayers 3 example here.


Reference Section¶

The following metadata are available in the setup of the mapfile:

(Note that each of the metadata below can also be referred to as ‘ows_*’ instead of ‘wms_*’. MapServer tries the ‘wms_*’ metadata first, and if not found it tries the corresponding ‘ows_*’ name. Using this reduces the amount of duplication in mapfiles that support multiple OGC interfaces since “ows_*” metadata can be used almost everywhere for common metadata items shared by multiple OGC interfaces.)

Web Object Metadata¶

ows_allowed_ip_list (or wms_allowed_ip_list)

Description: (Optional) A list of IP addresses that will be allowed access to the service.

ows_denied_ip_list (or wms_denied_ip_list)

Description: (Optional) A list of IP addresses that will be denied access to the service.

ows_http_max_age

Description: (Optional) an integer (in seconds) to specify how long a given map response should be considered new. Setting this directive allows for aware WMS clients to use this resulting HTTP header value as a means to optimize (and minimize) requests to a WMS Server. More info is available at http://www.mnot.net/cache_docs/#CACHE-CONTROL

ows_schemas_location

Description: (Optional) (Note the name ows_schemas_location and not wms_… this is because all OGC Web Services (OWS) use the same metadata) Root of the web tree where the family of OGC WMS XMLSchema files are located. This must be a valid URL where the actual .xsd files are located if you want your WMS output to validate in a validating XML parser. Default is http://schemas.opengis.net.

ows_sld_enabled

Description: (Optional) A value (true or false) which, when set to “false”, will ignore SLD and SLD_BODY parameters in order to disable remote styling of WMS layers. Also, SLD is not advertised in WMS Capabilities as a result

ows_updatesequence

Description: (Optional) The updateSequence parameter can be used for maintaining the consistency of a client cache of the contents of a service metadata document. The parameter value can be an integer, a timestamp in [ISO 8601:2000] format, or any other number or string.

wms_abstract

WMS TAG Name: Abstract (WMS1.1.1, sect. 7.1.4.2)

Description: (Optional) A blurb of text providing more information about the WMS server.

wms_accessconstraints

WMS TAG Name: AccessConstraints (WMS1.1.1, sect. 7.1.4.2)

Description: (Optional) Access constraints information. Use the reserved word “none” if there are no access constraints.

wms_addresstype, wms_address, wms_city, wms_stateorprovince, wms_postcode, wms_country

WMS TAG Name: ContactAddress and family (WMS1.1.1, sect. 7.1.4.2)

Description: Optional contact address information. If provided then all six metadata items are required.

wms_allow_getmap_without_styles

Noter

wms_allow_getmap_without_styles will be included in the MapServer 8.0 release.

Description: (Optional) “true” or “false”. If true, the “STYLES=” GetMap parameter will not be required in the request. If false (the default as of MapServer 8.0) the “STYLES=” GetMap parameter will be required in the request.

wms_attribution_logourl_format

Description: (Optional) The MIME type of the logo image. (e.g. “image/png”). Note that the other wms_attribution_logourl_* metadata must also be specified.

refer to section 7.1.4.5.11 of the WMS 1.1.1 spec.

wms_attribution_logourl_height

Description: (Optional) Height of the logo image in pixels. Note that the other wms_attribution_logourl_* metadata must also be specified.

refer to section 7.1.4.5.11 of the WMS 1.1.1 spec.

wms_attribution_logourl_href

Description: (Optional) URL of the logo image. Note that the other wms_attribution_logourl_* metadata must also be specified.

refer to section 7.1.4.5.11 of the WMS 1.1.1 spec.

wms_attribution_logourl_width

Description: (Optional) Width of the logo image in pixels. Note that the other wms_attribution_logourl_* metadata must also be specified.

refer to section 7.1.4.5.11 of the WMS 1.1.1 spec.

wms_attribution_onlineresource

Description: (Optional) The data provider’s URL.

refer to section 7.1.4.5.11 of the WMS 1.1.1 spec.

wms_attribution_title

    Description: (Optional) Human-readable string naming the data

refer to section 7.1.4.5.11 of the WMS 1.1.1 spec.

wms_bbox_extended:

Description: (Optional) “true” or “false”. If true, bounding boxes are reported for all supported SRS / CRS in the capabilities document. If false, only the bounding box of the first SRS / CRS is reported.

wms_contactelectronicmailaddress

    WMS TAG Name: ContactElectronicMailAddress (WMS1.1.1,

Description: Optional contact Email address.

wms_contactfacsimiletelephone

WMS TAG Name: ContactFacsimileTelephone (WMS1.1.1, sect. 7.1.4.2)

Description: Optional contact facsimile telephone number.

wms_contactperson, wms_contactorganization, wms_contactposition

WMS TAG Name: ContactInformation, ContactPerson, ContactOrganization, ContactPosition (WMS1.1.1, sect. 7.1.4.2)

Description: Optional contact information. If provided then all three metadata items are required.

wms_contactvoicetelephone

WMS TAG Name: ContactVoiceTelephone (WMS1.1.1, sect. 7.1.4.2)

Description: Optional contact voice telephone number.

wms_enable_request (ou alors ows_enable_request)

Description: Space separated list of requests to enable. The default is none. The following requests can be enabled: GetCapabilities , GetMap , GetFeatureInfo and GetLegendGraphic . A “!” in front of a request will disable the request. “*” enables all requests.

To enable only GetMap and GetFeatureInfo :

To enable all requests except GetFeatureInfo

wms_encoding

Description: Optional XML capabilities encoding type. The default is ISO-8859-1.

wms_feature_info_mime_type

WMS TAG Name: Feature_info_mime_type

Used to specify an additional MIME type that can be used when responding to the GetFeature request.

For example if you want to use the layer’s HTML template as a base for its response, you need to add “WMS_FEATURE_INFO_MIME_TYPE” “text/html”. Setting this will have the effect of advertising text/html as one of the MIME types supported for a GetFeature request. You also need to make sure that the layer points to a valid html template (see Templating ). The client can then call the server with INFO_FORMAT=text/html.

If not specified, MapServer by default has text/plain and GML implemented.

WMS TAG Name: Fees (WMS1.1.1, sect. 7.1.4.2)

Description: (Optional) Fees information. Use the reserved word “none” if there are no fees.

wms_getcapabilities_version

Description: (Optional) Default version to use for GetCapabilities requests that do not have a version parameter. If not set, the latest supported version will be returned.

wms_getlegendgraphic_formatlist

Description: (Optional) A comma-separated list of valid formats for a WMS GetLegendGraphic request.

wms_getmap_formatlist

Description: (Optional) A comma-separated list of valid formats for a WMS GetMap request.

wms_keywordlist

WMS TAG Name: KeywordList (WMS1.1.1, sect. 7.1.4.2)

Description: (Optional) A comma-separated list of keywords or keyword phrases to help catalog searching. As of WMS 1.1.0 no controlled vocabulary has been defined.

wms_keywordlist_vocabulary

WMS Attribute Name: vocabulary of KeywordList -> Keyword

Description: (Optional) Name of vocabulary used in wms_keywordlist_[vocabulary’s name]_items as described below.

wms_keywordlist_[vocabulary’s name]_items

WMS TAG Name: KeywordList -> Keyword

Description: (Optional) A comma-separated list of keywords or keyword phrases to help catalog searching for given vocabulary.

wms_languages

Description: (Optional) A comma-separated list of supported languages. For details please refer to the section Multi-language support for certain capabilities fields in the INSPIRE View Service documentation.

wms_layerlimit

WMS TAG Name: LayerLimit (WMS1.3.0, sect. 7.2.4.3)

Description: (Optional) The maximum number of layers a WMS client can specify in a GetMap request. If not set, then no limit is imposed.

wms_onlineresource

WMS TAG Name: OnlineResource (WMS1.1.1, sect. 6.2.2)

Description: (Recommended) The URL that will be used to access this WMS server. This value is used in the GetCapabilities response.

Sections “Setup a Mapfile / wms_onlineresource metadata” and “More About the Online Resource URL” above.

wms_remote_sld_max_bytes

Description: (Optional) Maximum size in bytes authorized when fetching a remote SLD through http. Defaults to 1 MegaByte (1048596).

wms_resx, wms_resy

WMS TAG Name: BoundingBox (WMS1.1.1, sect. 6.5.6)

Description: (Optional) Used in the BoundingBox tag to provide info about spatial resolution of the data, values are in map projection units.

wms_rootlayer_abstract

WMS TAG Name: Abstract (WMS1.1.1, sect. 7.1.4.2)

Description: (Optional) Same as wms_abstract, applied to the root Layer element. If not set, then wms_abstract will be used.

wms_rootlayer_keywordlist

WMS TAG Name: KeywordList (WMS1.1.1, sect. 7.1.4.2)

Description: (Optional) Same as wms_keywordlist, applied to the root Layer element. If not set, then wms_keywordlist will be used.

wms_rootlayer_name

WMS TAG Name: Name (WMS1.1.1, sect. 7.1.4.1)

Description: (Optional) Same as MAP.NAME, applied to the root Layer element. If not set, then MAP.NAME will be used. If set to “” , then Name element is suppressed and the root layer name will not be advertised as a GetMap capable layer.

wms_rootlayer_title

WMS TAG Name: Title (WMS1.1.1, sect. 7.1.4.1)

Description: (Optional) Same as wms_title, applied to the root Layer element. If not set, then wms_title will be used.

wms_service_onlineresource

Description: (Optional) Top-level onlineresource URL. MapServer uses the onlineresource metadata (if provided) in the following order:

3. wms_onlineresource (or automatically generated URL, see the onlineresource section of this document)

WMS TAG Name: SRS (WMS1.1.1, sect. 6.5.5)

Description: (Recommended) Contains a list of EPSG projection codes that should be advertised as being available for all layers in this server. The value can contain one or more EPSG:<code> pairs separated by spaces (e.g. “EPSG:4269 EPSG:4326”) This value should be upper case (EPSG:3978…..not epsg:3978) to avoid problems with case sensitive platforms.

See Also: section “Setup a Mapfile / Map PROJECTION and wms_srs metadata” above.

wms_timeformat

Description: The time format to be used when a request is sent. (e.g. “wms_timeformat” “%Y-%m-%d %H, %Y-%m-%d %H:%M”). Please see the WMS Time Support Howto for more information.

WMS TAG Name: Title (WMS1.1.1, sect. 7.1.4.1)

Description: (Required) A human-readable name for this Layer.

Layer Object Metadata¶

gml_exclude_items

Description: (Optional, applies only to GetFeatureInfo GML requests) A comma delimited list of items to exclude. As of MapServer 4.6, you can control how many attributes (fields) you expose for your data layer with metadata. The previous behaviour was simply to expose all attributes all of the time. The default is to expose no attributes at all. An example excluding a specific field would be:

gml_geometries

Description: (Optional, applies only to GetFeatureInfo GML requests) Provides a name for geometry elements. The value is specified as a string to be used for geometry element names. By default, GML geometries are not written in GML GetFeatureInfo output, unless gml_geometries and gml_[geometry name]_type are both set. By default, only the bounding box is written. If gml_geometries is set to “none”, neither the bounding box nor the geometry are written.

Description: (Optional, applies only to GetFeatureInfo GML requests) A comma delimited list of group names for the layer.

gml_[group name]_group

Description: (Optional, applies only to GetFeatureInfo GML requests) A comma delimited list of attributes in the group. Here is an example:

gml_include_items

Description: (Optional, applies only to GetFeatureInfo GML requests) A comma delimited list of items to include, or keyword “all”. As of MapServer 4.6, you can control how many attributes (fields) you expose for your data layer with this metadata. The previous behaviour was simply to expose all attributes all of the time. You can enable full exposure by using the keyword “all”, such as:

You can specify a list of attributes (fields) for partial exposure, such as:

The new default behaviour is to expose no attributes at all.

gml_[item name]_alias

Description: (Optional, applies only to GetFeatureInfo GML requests) An alias for an attribute’s name. The served GML will refer to this attribute by the alias. Here is an example:

gml_[item name]_type

Description: (Optional) Specifies the type of the attribute. Valid values are the OGR data types: Integer|Long|Real|Character|Date|Time|DateTime|Boolean. MapServer translates these to valid GML data types.

Long is to be used for 64-bit integers, starting with MapServer 7.0.1.

Time and DateTime have been added in MapServer 8. And since MapServer 8, Date semantics is a date, without time, whereas in previous versions, it was used indifferently for Date, Time or DateTime.

gml_[geometry name]_type

Description: (Optional, applies only to GetFeatureInfo GML requests) When employing gml_geometries, it is also necessary to specify the geometry type of the layer. This is accomplished by providing a value for gml_[geometry name]_type, where [geometry name] is the string value specified for gml_geometries, and a value which is one of:

gml_xml_items

Description: (Optional, applies only to GetFeatureInfo GML requests) A comma delimited list of items that should not be XML-encoded.

Same as ows_allowed_ip_list in the Web Object.

ows_denied_ip_list

Same as ows_denied_ip_list in the Web Object.

wms_abstract

Same as wms_abstract in the Web Object.

wms_attribution_logourl_format

Description: (Optional) The MIME type of the logo image. (e.g. “image/png”). Note that the other wms_attribution_logourl_* metadata must also be specified.

refer to section 7.1.4.5.11 of the WMS 1.1.1 spec.

wms_attribution_logourl_height

Description: (Optional) Height of the logo image in pixels. Note that the other wms_attribution_logourl_* metadata must also be specified.

refer to section 7.1.4.5.11 of the WMS 1.1.1 spec.

wms_attribution_logourl_href

Description: (Optional) URL of the logo image. Note that the other wms_attribution_logourl_* metadata must also be specified.

refer to section 7.1.4.5.11 of the WMS 1.1.1 spec.

wms_attribution_logourl_width

Description: (Optional) Width of the logo image in pixels. Note that the other wms_attribution_logourl_* metadata must also be specified.

refer to section 7.1.4.5.11 of the WMS 1.1.1 spec.

wms_attribution_onlineresource

Description: (Optional) The data provider’s URL.

refer to section 7.1.4.5.11 of the WMS 1.1.1 spec.

wms_attribution_title

    Description: (Optional) Human-readable string naming the data

refer to section 7.1.4.5.11 of the WMS 1.1.1 spec.

wms_authorityurl_name, wms_authorityurl_href

Description: (Optional) AuthorityURL is used in tandem with Identifier values to provide a means of linking identifier information back to a web service. The wms_identifier_authority should provide a string that matches a declared wms_authorityurl_name. Both wms_authorityurl_name and wms_authorityurl_href must be present for an AuthorityURL tag to be written to the capabilities.

refer to section 7.1.4.5.12 of the WMS 1.1.1 spec.

wms_bbox_extended:

Description: (Optional) “true” or “false”. If true, bounding boxes are reported for all supported SRS / CRS in the capabilities document. If false, only the bounding box of the first SRS / CRS is reported.

wms_dataurl_format

Description: (Optional) Non-standardized file format of the metadata. The layer metadata wms_dataurl_href must also be specified.

refer to section 7.1.4.5.14 of the WMS 1.1.1 spec.

wms_dataurl_href

Description: (Optional) The URL to the layer’s metadata. The layer metadata wms_dataurl_format must also be specified.

refer to section 7.1.4.5.14 of the WMS 1.1.1 spec.

wms_enable_request (ou alors ows_enable_request)

Description: Space separated list of requests to enable. The default is none. The following requests can be enabled: GetCapabilities , GetMap , GetFeatureInfo and GetLegendGraphic . A “!” in front of a request will disable the request. “*” enables all requests.

To enable only GetMap and GetFeatureInfo :

To enable all requests except GetFeatureInfo

wms_exclude_items

Description: (Optional, applies only to GetFeatureInfo text/plain requests) A comma delimited list of items to exclude, or keyword “all”.

See gml_exclude_items above.

WMS TAG Name: BoundingBox (WMS1.1.1, sect. 6.5.6)

Description: (Optional) Used for the layer’s BoundingBox tag for cases where it is impossible (or very inefficient) for MapServer to probe the data source to figure its extents. The value for this metadata is “minx miny maxx maxy” separated by spaces, with the values in the layer’s projection units. If wms_extent is provided then it has priority and MapServer will NOT try to read the source file’s extents.

For Rasters served through WMS, MapServer can now use the wms_extent metadata parameter to register the image. If a .wld file cannot be found, MapServer will then look for the wms_extent metadata parameter and use the extents of the image and the size of the image for georegistration.

wms_getfeatureinfo_formatlist

Description: (Optional) Comma-separated list of formats that should be valid for a GetFeatureInfo request. If defined, only these formats are advertised through in the Capabilities document.

wms_getlegendgraphic_formatlist

Description: (Optional) Comma-separated list of image formats that should be valid for a GetLegendGraphic request. If defined, only these formats are advertised through in the Capabilities document.

wms_getmap_formatlist

Description: (Optional) Comma-separated list of image formats that should be valid for a GetMap request. If defined, only these formats are advertised through in the Capabilities document.

wms_group_abstract

Description: (Optional) A blurb of text providing more information about the group. Only one layer for the group needs to contain wms_group_abstract, MapServer will find and use the value. The value found for the first layer in the group is used. So if multiple layers have wms_group_abstract set then only the first value is used.

wms_group_title

WMS TAG Name: Group_title (WMS1.1.1, sect. 7.1.4.1)

Description: (Optional) A human-readable name for the group that this layer belongs to. Only one layer for the group needs to contain wms_group_title, MapServer will find and use the value. The value found for the first layer in the group is used. So if multiple layers have wms_group_title set then only the first value is used.

wms_identifier_authority, wms_identifier_value

Description: (Optional) Identifier is used in tandem with AuthorityURL end points to provide a means of linking identifier information back to a web service. The wms_identifier_authority should provide a string that matches a declared wms_authorityurl_name. Both wms_identifier_authority and wms_identifier_value must be present for an Identifier tag to be written to the capabilities.

refer to section 7.1.4.5.12 of the WMS 1.1.1 spec.

wms_include_items

Description: (Optional, applies only to GetFeatureInfo text/plain requests) A comma delimited list of items to include, or keyword “all”.

See gml_include_items above.

Same as wms_keywordlist in the Web Object.

wms_keywordlist_vocabulary

Same as wms_keywordlist_vocabulary in the Web Object.

wms_keywordlist_[vocabulary’s name]_items

Same as wms_keywordlist_[vocabulary’s name]_items in the Web Object.

wms_layer_group

Description: (Optional) Can be used to assign a layer to a number of hierarchically nested groups. This grouped hierarchy will be expressed in the capabilities.

From MapServer 7.2, WMS_LAYER_GROUP is similar to the GROUP keyword in that it always publishes the name and the tile of the group in the capabilities. As a consequence the groups set with WMS_LAYER_GROUP can always be requested with a GetMap or GetFeatureInfo request (see section 7.1.4.5.2 of the WMS implementation specification version 1.1.1. (OGC 01-068r2)).

A difference with GROUP is that GROUP does not support nested groups. The purpose of this metadata setting is to enable making a WMS client aware of layer grouping.

All group names should be preceded by a forward slash (/). It is not allowed to use both the WMS_LAYER_GROUP setting and the GROUP keyword for a single layer. GROUP can be seen as deprecated!

wms_metadataurl_format

Description: (Optional) The file format MIME type of the metadata record (e.g. “text/plain”). The layer metadata wms_metadataurl_type and wms_metadataurl_href must also be specified.

refer to section 7.1.4.5.10 of the WMS 1.1.1 spec.

To output several MetadataURL elements, use wms_metadataurl_list

wms_metadataurl_href

Description: (Optional) The URL to the layer’s metadata. The layer metadata wms_metadataurl_format and wms_metadataurl_type must also be specified.

refer to section 7.1.4.5.10 of the WMS 1.1.1 spec.

To output several MetadataURL elements, use wms_metadataurl_list

wms_metadataurl_list

Noter

wms_metadataurl_list will be included in the MapServer 8.0 release.

Description: (Optional) Space-separated list of parts of metadata keys, to be able to specify several MetadataURL. If the value of wms_metadataurl_list is “foo bar”, then wms_metadataurl_foo_href, wms_metadataurl_foo_format, wms_metadataurl_foo_type, wms_metadataurl_bar_href, wms_metadataurl_bar_format, wms_metadataurl_bar_type will be queried with the semantics of the wms_metadataurl_href, wms_metadataurl_format and wms_metadataurl_type items.

wms_metadataurl_type

Description: (Optional) The standard to which the metadata complies. Currently only two types are valid: “TC211” which refers to [ISO 19115], and “FGDC” which refers to [FGDC-STD-001-1988]. The layer metadata wms_metadataurl_format and wms_metadataurl_href must also be specified.

refer to section 7.1.4.5.10 of the WMS 1.1.1 spec.

To output several MetadataURL elements, use wms_metadataurl_list

WMS TAG Name: Opaque (WMS1.1.1, sect. 7.1.4.6.3)

Description: (Optional) Set this metadata to “1” to indicate that the layer represents an area-filling coverage of space (e.g. a bathymetry and elevation layer). This should be taken by the client as a hint that this layer should be placed at the bottom of the stack of layers.

Same as wms_srs in the Web Object .

Description: (Optional) The LegendURL style name. Requires the following metadata: wms_style_[style’s_name]_width, wms_style_[style’s_name]_legendurl_height, wms_style_[style’s_name]_legendurl_format, wms_style_[style’s_name]_legendurl_href

refer to section 7.1.4.5.4 of the WMS 1.1.1 spec.

wms_style_[style’s_name]_legendurl_format

Description: (Optional) The file format MIME type of the legend image. Requires the following metadata: wms_style_[style’s_name]_width, wms_style_[style’s_name]_legendurl_height, wms_style, wms_style_[style’s_name]_legendurl_href.

refer to section 7.1.4.5.4 of the WMS 1.1.1 spec.

wms_style_[style’s_name]_legendurl_height

Description: (Optional) The height of the legend image in pixels. Requires the following metadata: wms_style_[style’s_name]_width, wms_style, wms_style_[style’s_name]_legendurl_format, wms_style_[style’s_name]_legendurl_href.

refer to section 7.1.4.5.4 of the WMS 1.1.1 spec.

wms_style_[style’s_name]_legendurl_href

Description: (Optional) The URL to the layer’s legend. Requires the following metadata: wms_style_[style’s_name]_width, wms_style_[style’s_name]_legendurl_height, wms_style_[style’s_name]_legendurl_format, wms_style.

refer to section 7.1.4.5.4 of the WMS 1.1.1 spec.

wms_style_[style’s_name]_legendurl_width

Description: (Optional) The width of the legend image in pixels. Requires the following metadata: wms_style_[style’s_name]_format, wms_style_[style’s_name]_legendurl_height, wms_style, wms_style_[style’s_name]_legendurl_href.

refer to section 7.1.4.5.4 of the WMS 1.1.1 spec.

wms_timedefault

Description: (Optional for Time Support) This value is used if it is defined and the Time value is missing in the request. Please see the WMS Time Support Howto for more information.

wms_timeextent

Description: (Mandatory for Time Support) This is used in the capabilities to return the valid time values for the layer. The value defined here should be a valid time range. Please see the WMS Time Support Howto for more information.

wms_timeitem

Description: (Mandatory for Time Support) This is the name of the field in the DB that contains the time values. Please see the WMS Time Support Howto for more information.

Same as wms_title in the Web Object.

Layer Metadata API¶

If wms_metadataurl_href is not defined, MapServer will provide a link to the Layer Metadata API for the given layer in the <MetadataURL> element See the Layer Metadata API documentation for more information.

Vendor specific WMS parameters¶

Angle (in degrees) to rotate the map.

Noter

The angle value is in degrees clockwise.

This parameter accepts two types of input:

An integer that specifies the search radius in pixels.

The special value bbox that will change the query into a bbox query based on the bbox given in the request parameters.

bbox_pixel_is_point

If this parameter is “TRUE”, MapServer will treat the BBOX received in WMS GetMap requests as if it was provided in pixel_is_point mode. Essentially disabling the conversion from pixel_is_area (WMS model) to pixel_is_point that is present in mapwms.c for that specific mapfile.

Cascading WMS Requests¶

Currently, there are 3 requests that support WMS cascading:

Before MapServer 6.2, a GetLegendGraphic request was not cascaded. A legend was returned using the layer classes. To preserve that behavior, a GetLegendGraphic request will be cascaded only si:

The GetLegendGraphic request is enabled via the _enable_request metadata.

The layer does not contain any class with the name property set. ie:

This layer won’t be cascaded because it contains at least a class with the property NAME set.

If you know that the remote WMS server does not support a given WMS request, you should disable this request explicitly for your layer using the (ows/wms)_enable_request metadata. Otherwise, you will simply get the XML exception from the cascaded server.

Sample WMS Server Mapfile¶

The following is a very basic WMS Server mapfile:


OpenLayers 3 Client Development

The final part is configuring the Web client using OpenLayers 3.

The first step is quite basic we the definition of our html file. Three parts here: the map, the title bar and the legend.

Our three layers are added via this way.

Notice how we get the most of performances using the gwc application. It uses the caches we generated in Geoserver.

Finally, we add a phantom underlying layer which is only used for the GetFeatureInfo functionnality. It is called each time we click on the map to get the relevant information about how many people voted for who.

Finally, add the layers to the map.

One last thing! le GetFeatureInfo returns pieces of information that are not necessary to the user. These are the fid and the id. For resolving this issue, we define a file called content.ftl in the Geoserver data folder. We will format the returning information to send to the user.

At last, wrap the all application in a very nice css and you got the result we observe in the short introductory video!

All the scripts are available here to reproduce at home!

I am now waiting the 2016 Presidential Election Results by Counties to make and publish an updated map!


Voir la vidéo: Web feature service