More

Openlayers3 WMS GetFeatureInfo request only returns info for one feature


I have a point dataset in an Openlayers 3 map. The aim is to be able to click each point and get the information about that point displayed. The code below works just fine, it loads all the layers up and when I click a point, it retrieves some information. However it will only return information for one point, no matter where I click on the map. Can anyone see where I have gone wrong here?

var layers = [ 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', params: {'LAYERS': 'NCTPROP:corr'}, serverType: 'geoserver' }) }), 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', params: {'LAYERS': 'NCTPROP:br_web'}, serverType: 'geoserver' }) }), new ol.layer.Tile({ source: new ol.source.TileWMS({ url: 'http://geonct.com:80/geoserver/NCTPROP/wms', params: {'LAYERS': 'NCTPROP:br_point'}, serverType: 'geoserver' }) }) ]; function loadMap(){ var map = new ol.Map({ layers: layers, 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 = layers[3].getSource().getGetFeatureInfoUrl( evt.coordinate, viewResolution, 'EPSG:3857', {'INFO_FORMAT': 'text/html'}); if (url) { document.getElementById('info').innerHTML = ''; } }); }; function layerSwap(evt){ layers[evt.value].setVisible(evt.checked); }

You need to specify WMS params in getGetFeatureInfoUrl() function.
In your case, try to ask for more features by adding the param FEATURE_COUNT after INFO_FORMAT.

For instance:

var url = layers[3].getSource().getGetFeatureInfoUrl( evt.coordinate, viewResolution, 'EPSG:3857', { 'INFO_FORMAT': 'text/html', 'FEATURE_COUNT': '20' //or whatever you want } );

Good luck


The buffer parameter specifies the number of additional border pixels that are used in the GetMap and GetFeatureInfo operations. The syntax is:

where <bufferwidth> is the width of the buffer in pixels.

In the GetMap operation, buffering includes features that lie outside the request bounding box, but whose styling is thick enough to be visible inside the map area.

In the GetFeatureInfo operation, buffering creates a “search radius” around the location of the request. Feature info is returned for features intersecting the search area. This is useful when working with an OpenLayers map (such as those generated by the Layer Preview page) since it relaxes the need to click precisely on a point for the appropriate feature info to be returned.

In both operations GeoServer attempts to compute the buffer value automatically by inspecting the styles for each layer. All active symbolizers are evaluated, and the size of the largest is used (i.e. largest point symbolizer, thickest line symbolizer). Automatic buffer sizing cannot be computed if:

  • the SLD contains sizes that are specified as feature attribute values
  • the SLD contains external graphics and does not specify their size explicitly

In this event, the following defaults are used:

  • 0 pixels for GetMap requests
  • 5 pixels for GetFeatureInfo requests (a different min value can be set via the org.geoserver.wms.featureinfo.minBuffer system variable, e.g., add -Dorg.geoserver.wms.featureinfo.minBuffer=10 to make the min buffer be 10 pixels)

If these are not sufficiently large, the explicit parameter can be used.


GetCapabilities¶

Request¶

A WMS server responding to a GetCapabilities request returns metadata about the service, including supported operations and parameters, and a list of the available layers.

An example of a GetCapabilities request is:

There are three parameters (and values) being passed to the WMS server, SERVICE=WMS , VERSION=1.3 , and REQUEST=GetCapabilities .

The SERVICE parameter tells the server that a WMS request is forthcoming.

The VERSION parameter tells the server what version of the WMS is being requested.

The REQUEST parameter tells the server that the operation requested is the GetCapabilities operation.

The WMS standard requires that requests always includes these three parameters. The table bellow summarizes the parameters and values required to perform the request.

Parameters of the GetCapabilities Operation ¶

Description

Service name. Value is WMS .

Service version. Value is one of 1.0.0 , 1.1.0 , 1.1.1 , 1.3 .

Operation name. Value is GetCapabilities .

Response¶

The response is a Capabilities XML document with a detailed description of the WMS service. It contains three main sections:

Sections Capabilities Document ¶

Contains service metadata such as the service name, keywords, and contact information for the organization operating the server.

Describes the operations the WMS service provides and the parameters and output formats for each operation.

Lists the available coordinate systems and layers. In some servers (e.g. Geoserver) layers are named in the form “namespace:layer”. Each layer provides service metadata such as title, abstract and keywords.

GetCapabilities Layer Style Section¶

The GetCapabilites response contains a Layer section, which details about the style available to that layer. In the example bellow the available style is default.


GetCapabilities¶

The GetCapabilities operation requests metadata about the operations, services, and data (“capabilities”) that are offered by a WMS server.

The parameters for the GetCapabilities operation are:

Parameter Required? Description
service Yes Service name. Value is WMS .
version Yes Service version. Value is one of 1.0.0 , 1.1.0 , 1.1.1 , 1.3 .
request Yes Operation name. Value is GetCapabilities .

GeoServer provides the following vendor-specific parameters for the GetCapabilities operation. They are fully documented in the WMS vendor parameters section.

Parameter Required? Description
namespace No limits response to layers in a given namespace

A example GetCapabilities request is:

There are three parameters being passed to the WMS server, service=wms , version=1.1.1 , and request=GetCapabilities . The service parameter tells the WMS server that a WMS request is forthcoming. The version parameter refers to which version of WMS is being requested. The request parameter specifies the GetCapabilities operation. The WMS standard requires that requests always includes these three parameters. GeoServer relaxes these requirements (by setting the default version if omitted), but for standard-compliance they should always be specified.

The response is a Capabilities XML document that is a detailed description of the WMS service. It contains three main sections:

Service Contains service metadata such as the service name, keywords, and contact information for the organization operating the server.
Request Describes the operations the WMS service provides and the parameters and output formats for each operation. If desired GeoServer can be configured to disable support for certain WMS operations.
Layer Lists the available coordinate systems and layers. In GeoServer layers are named in the form “namespace:layer”. Each layer provides service metadata such as title, abstract and keywords.


GetMap¶

The GetMap operation requests that the server generate a map. The core parameters specify one or more layers and styles to appear on the map, a bounding box for the map extent, a target spatial reference system, and a width, height, and format for the output. The information needed to specify values for parameters such as layers , styles and srs can be obtained from the Capabilities document.

The response is a map image, or other map output artifact, depending on the format requested. GeoServer provides a wide variety of output formats, described in WMS output formats .

The standard parameters for the GetMap operation are:

Parameter Required? Description
service Yes Service name. Value is WMS .
version Yes Service version. Value is one of 1.0.0 , 1.1.0 , 1.1.1 , 1.3.0 .
request Yes Operation name. Value is GetMap .
layers Yes Layers to display on map. Value is a comma-separated list of layer names.
styles Yes Styles in which layers are to be rendered. Value is a comma-separated list of style names, or empty if default styling is required. Style names may be empty in the list, to use default layer styling.
srs or crs Yes Spatial Reference System for map output. Value is in form EPSG:nnn . crs is the parameter key used in WMS 1.3.0.
bbox Yes Bounding box for map extent. Value is minx,miny,maxx,maxy in units of the SRS.
width Yes Width of map output, in pixels.
height Yes Height of map output, in pixels.
format Yes Format for the map output. See WMS output formats for supported values.
transparent No Whether the map background should be transparent. Values are true or false . Default is false
bgcolor No Background color for the map image. Value is in the form RRGGBB . Default is FFFFFF (white).
exceptions No Format in which to report exceptions. Default value is application/vnd.ogc.se_xml .
time No Time value or range for map data. See Time Support in GeoServer WMS for more information.
sld No A URL referencing a StyledLayerDescriptor XML file which controls or enhances map layers and styling
sld_body No A URL-encoded StyledLayerDescriptor XML document which controls or enhances map layers and styling

GeoServer provides a number of useful vendor-specific parameters for the GetMap operation. These are documented in the WMS vendor parameters section.

Example WMS request for topp:states layer to be output as a PNG map image in SRS EPGS:4326 and using default styling is:

The standard specifies many of the parameters as being mandatory, GeoServer provides the WMS Reflector to allow many of them to be optionally specified.

Experimenting with this feature is a good way to get to know the GetMap parameters.

Example WMS request using a GetMap XML document is:

As of GeoServer 2.2.0, GeoServer supports a TIME attribute for WMS GetMap requests as described in version 1.3.0 of the WMS specification. This parameter allows filtering a dataset by temporal slices as well as spatial tiles for rendering. See Time Support in GeoServer WMS for information on its use.


The Sentinel WMS service conforms to the WMS standard. It not only provides access to Sentinel-2's 13 unprocessed bands (B01 through B12 - with B8A following B08) but also to processed products such as true color imagery and NDVI. Access to the service is done via a custom server instance URL which will be provided to you upon registration.

It is possible to obtain multiple separate instances (which act as separate WMS services) each with their own configuration and list of layers which will likely be useful to advanced users. For more information see the "WMS configuration" chapter.

The base URL for the WMS service:

For example, a GetCapabilities request can be done by changing the to your provided instance ID and opening the following URL:

Some of the most common provided products:

  • TRUE_COLOR - a brightened RGB image
  • FALSE_COLOR - uses near-infrared instead of the blue band
  • NDVI - Normalized Difference Vegetation Index
  • EVI - Enhanced Vegetation Index

List of all available products available EO products

Additional informational overlays are also provided as layers for convenience:

  • OUTLINE - draws an outline around areas which contain valid data
  • FILL - fills the areas which contain valid data
  • DATE - draws the dates of the granules
  • ID - draws the IDs of the granules

These additional informational overlays support the following styles:

  • COLORED (default) - each tile is colored differently, with the color computed from the tile's ID
  • RED, GREEN, BLUE, WHITE and BLACK - solid color

The service supports standard WMS requests: GetMap , GetCapabilities , GetFeatureInfo , and also some custom requests. Supported WMS versions are 1.1.1 and 1.3.0.

The WMS (Web Map Service) service output image type can be a 1 or 3 component 8-bit PNG or JPEG alternatively also an n-component 8 or 16-bit TIFF. Use the proper type when setting the "FORMAT" parameter. For JPEG, use "image/jpeg" or "image/jpg" and for PNG use "image/png". For TIFF, if you use just "image/tiff", the service will generate 8-bit TIFF for the products and 16-bit TIFF for the raw Sentinel-2 bands.

If you want to force a specific TIFF bit depth, use "image/tiffdepth=8", "image/tiffdepth=16" or "image/tiffdepth=32f" (for 32-bit floating point). When PNG or TIFF is requested, the "TRANSPARENT" parameter determines whether the produced image will have transparent pixels where no input data is available or not.

For a list of supported coordinate reference systems check the GetCapabilities result.

WMS URL parameters

Standard common WMS URL parameters (parameter names are case insensitive, values are case sensitive):

WMS version standard. Optional, default: "1.3.0". Supported values: "1.1.1" and "1.3.0".

What is requested, valid values: GetMap , GetFeatureInfo , GetCapabilities or a custom request's name. Required.

(when REQUEST = GetMap or GetFeatureInfo ) The time or time range for which to return the results, in ISO8601 format (year-month-date, for example: 2016-01-01). When a single time is specified the service will return data until the specified time. If a time range is specified the result is based on all scenes between the specified dates conforming to the cloud coverage criteria and stacked based on priority setting - e.g. most recent on top. The time range is written as two time values separated by a slash, followed by a second slash and a period parameter (which must be P1D). Optional, default: none (the last valid image is returned). Examples: "TIME=2016-01-01", "TIME=2016-01-01/2016-02-01/P1D".

In addition to the standard WMS URL parameters, the WMS service also supports many custom URL parameters. See Custom service URL parameters for details.

Standard GetMap request URL parameters:

Specifies the bounding box of the requested image. Coordinates must be in the specified coordinate reference system. The four coordinates representing the top-left and bottom-right of the bounding box must be separated by commas. Required. Example: BBOX=-13152499,4038942,-13115771,4020692

(when VERSION 1.3.0 or higher) the coordinate reference system in which the BBOX is specified and in which to return the image. Optional, default: "EPSG:3857". For a list of available CRSs see the GetCapabilities result.

(when VERSION 1.1.1 or lower) the coordinate reference system in which the BBOX is specified and in which to return the image. Optional, default: "EPSG:3857". For a list of available CRSs see the GetCapabilities result.

The returned image format. Optional, default: "image/png". Detailed information about supported values.

Returned image width in pixels. Required, unless RESX is used.

Returned image height in pixels. Required, unless RESY is used.

Returned horizontal image resolution in UTM units (if m is added, e.g. 10m, in metrical units). (optional instead of HEIGHT)

Returned vertical image resolution in UTM units (if m is added, e.g. 10m, in metrical units). (optional instead of WIDTH)

Default background color. Option, default: "FFFFFF". Supported formats: "0xRRGGBB", "0xAARRGGBB", "#RRGGBB", "#AARRGGBB", "RRGGBB", "AARRGGBB".

(when FORMAT = "image/png" or "image/tiff") The returned image has an alpha channel which is blank for pixels with no valid or available input data. Optional, default = "false". Supported values: "true", "false", "0", "1".

The preconfigured layer (image) to be returned. You must specify exactly one layer and optionally add additional overlays. Required. Example: LAYERS=TRUE_COLOR,OUTLINE

The exception format. Optional, default: "XML". Supported values: "XML", "INIMAGE", "BLANK" (all three for version >= 1.3.0), "application/vnd.ogc.se_xml", "application/vnd.ogc.se_inimage", "application/vnd.ogc.se_blank" (all three for version < 1.3.0).

Standard GetFeatureInfo request URL parameters:

Specifies the bounding box of the area which contains the queried point. Coordinates are in the specified CRS/SRS. Four coordinates representing the top-left and bottom-right of the bounding box must be separated by comma. Required. Example: BBOX=-13152499,4038942,-13115771,4020692

(when VERSION 1.3.0 or higher) the coordinate reference system in which the BBOX is specified. Optional, default: "EPSG:3857". For a list of available CRSs see the GetCapabilities result.

(when VERSION 1.1.1 or lower) the coordinate reference system in which the BBOX is specified. Optional, default: "EPSG:3857". For a list of available CRSs see the GetCapabilities result.

The image-space width containing the queried point, in pixels. Required.

The image-space height containing the queried point, in pixels. Required.

The output format of the feature info content. Check GetCapabilities for a list of supported formats.

The layers for which the feature info is requested.

(when VERSION 1.3.0 or higher) The X and Y coordinates in the output image space in pixels of the feature queried.

(when VERSION 1.1.1 or lower) The X and Y coordinates in the output image space in pixels of the feature queried.

Example below shows the contents of the result object from parsing a WMS capabilities response:

The CREODIAS would like to place cookies on your computer to help make this website better. By continuing to use the site you are agreeing to our use of cookies. If you do not agree with the terms and conditions, please do not use the website. Learn More. Accept


Openlayers3 WMS GetFeatureInfo request only returns info for one feature - Geographic Information Systems

Marine Regions provides several web services which allow the user to have direct access to the geographic data, maps and metadata from a GIS desktop or for online applications.

OGC web services

Web Map Service (data visualisation)

The Web Map Service standard (WMS) provides a simple HTTP interface for requesting geo-registered map images from one or more distributed geospatial databases. A WMS request defines the geographic layer(s) and area of interest to be processed. The response to the request is one or more geo-registered map images (returned as JPEG, PNG, etc) that can be displayed in a Geographic Information System (GIS) or in your own web application (OpenLayers, Leaflet. ). The WMS supports the GetCapabilities, GetMap and GetFeatureInfo operations as defined in the Open Geospatial Consortium (OGC) WMS standard.

The Marine Regions WMS service is accessible from the following endpoint:

WMS metadata (GetCapabilities)

The mandatory GetCapabilities operation allows WMS clients to retrieve service metadata from a server. The response to a GetCapabilities request shall be an XML document containing metadata of the service (proposed layers, associated projections, author . ).

The standard to construct a WMS GetCapabilities request, depending on the version:

https://geo.vliz.be/geoserver/MarineRegions/wms?SERVICE=WMS&VERSION=X.X.X&REQUEST=GetCapabilities

An example of a GetCapabilities request addressed to the Marine Regions view service:

Map visualisation (GetMap)

Using the information given in the GetCapabilities request, the GetMap request returns an image of the requested data layer selected from all the available layers as defined in the XML document. The elements such as the data layer, region, projection, size of the returned image, image format, etc. are defined in the form of arguments.

Example of a GetMap request that returns an image of the Exclusive Economic Zone of Belgium:

Using Web Map Services in GIS/programming languages

In order to study the provided data in more detail or add them as background images in maps, they can be loaded into GIS software or invoked using various programming languages. How to do this on some of the most common platforms is explained in the manuals below:

  • Loading a WMS layer in QGIS
  • Loading a WMS layer in ArcGIS Pro
  • Loading a WMS layer in R
  • Loading a WMS layer in Python

Web Feature Service (data download)

WFS defines a standard for exchanging vector data by querying both the data structure and the source data. The basic operations are GetCapabilities, DescribeFeatureType, and GetFeature. WFS supports a variety of WFS output formats (e.g. GML, shapefile, JSON, GeoJSON, CSV. ). The full list of output formats supported can be found by performing a WFS GetCapabilities request.

The Marine Regions WFS service is accessible from the following endpoint:

WFS metadata (GetCapabilities)

A GetCapabilities request generates a metadata document (xml) describing a WFS service provided by server as well as valid WFS operations and parameters.

The standard to construct a WFS GetCapabilities request, depending on the version:

https://geo.vliz.be/geoserver/MarineRegions/wfs?SERVICE=WFS&VERSION=X.X.X&REQUEST=GetCapabilities

An example of a GetCapabilities request addressed to the Marine Regions download service:

Feature type information (DescribeFeatureType)

A DescribeFeatureType request returns a description of feature types supported by a WFS service.

An example of a Marine Regions DescribeFeature request:

Download data (GetFeature)

A GetFeature request returns a selection of features from a data source including geometry and attribute values.

Building a WFS query to get data

For composing your own query, you need to combine different parts:

  1. the base url
  2. the requested layer
  3. filtering options (optional)
  4. the output format

The base link for performing a WFS request to Marine Regions is:

2. The requested layer

All available layers in the Marine Regions download service can be requested using a getCapabilities request.

The syntax for specifying a layer is:

If you only want to download specific records of a layer, you can add a filter to the WFS request. This filter can take into account (among others) geometry and attribute values. Available attributes can be discovered using a DescribeFeatureType request.

This example will return a shapefile of the Belgian Exclusive Economic Zone (MRGID 3293).

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

A more detailed description of using CQL filters can be found in the GeoServer manual.

Marine Regions data are available in a number of output formats, which are indicated at the end of the WFS request as:

For other output formats, see the GetCapabilities request which returns the complete list of output formats available for each type of WFS request: https://geo.vliz.be/geoserver/MarineRegions/wfs?service=WFS&version=1.0.0&request=GetCapabilities

Using Web Feature Services in GIS/programming languages

In order to study the provided data in more detail or perform further spatial analyses on them, they can be loaded into GIS software or invoked using various programming languages. How to do this on some of the most common platforms is explained in the manuals below:

  • Loading a WFS layer in QGIS
  • Loading a WFS layer in ArcGIS Pro
  • Loading a WFS layer in R
  • Loading a WFS layer in Python

Catalogue Service for the Web (metadata)

The Marine Regions catalogue offers the ability to search its collection of metadata for data, services and related information objects. The data catalogue offers a CSW endpoint to other client applications to connect to the service and query the metadata held in the catalogue.


Walkthrough: Overlaying a WMS on a tiled map with Leaflet

The goal of this walkthrough is to get some practice overlaying different kinds of web services in Leaflet. You will first publish a WMS showing farmers' markets in Philadelphia. You will then use Leaflet to place this layer on top of the Philadelphia basemap tiles you made with TileMill in the previous lesson. You'll also add code, so that a user of your application can click any farmers market and see some more information in a popup.

Setting up the farmers' markets WMS

The first step is setting up a (passably) good-looking WMS showing farmers' markets in Philadelphia. In this application, the farmers' markets WMS will play the role of the business layer.

Setting up this WMS will be a nice review of some of the skills you learned in Lesson 4. In places where step-by-step instructions are lacking, you should be able to go back to the Lesson 4 walkthrough to remember the procedures.

  1. Download this shapefile of Philadelphia farmers' markets. This was obtained from the City of Philadelphia via the PASDA library. It's probably easiest if you extract it into your C:dataPhiladelphia folder.
  2. Open the GeoServer web admin page, and publish the farmers market shapefile as a layer in GeoServer using coordinate system EPSG:3857. Put it into your geog585 workspace. It should look like the following when you preview the layer.

When you have successfully applied the SLD, the WMS should look like the following when you preview the layer in GeoServer:

Preparing the web development environment

Now you'll make a few preparations for writing a simple Leaflet application. We’re going to host this app on the mini web server called Jetty that is installed with GeoServer. Just remember that in "the real world" you would probably get your IT staff to install an enterprise grade web server, such as Apache where you could run both GeoServer and your HTML pages. If you don't have an IT staff, you may even be lucky enough to do this yourself someday! :-)

    Stop GeoServer. (All Programs > GeoServer 2.x.x > Stop GeoServer)

As long as GeoServer is started, you should now be able to access your HTML pages through a URL such as http://localhost:8080/geog585/mypage.html (where mypage.html needs to be replaced by the name of the actual html file).

The above CSS sets the size of the map container, the size and color of the map border, and the color of the background.

  1. Save the file in your new Jetty folder as c:Program FilesGeoServer 2.x.xwebappsgeog585style.css. If you get an access denied error, you will have to modify the access rights of the geog585 folder so that your user has read and write access rights to the folder. Alternatively, you can try to run your text editor in Administrator mode.
  2. Test that your CSS is accessible by opening a browser to http://localhost:8080/geog585/style.css. You should see the same CSS file.

If you get an HTTP 404 “Page not found” error and you are certain your URL is correct (or try it without the .css extension - http://localhost:8080/geog585/style), then something might have gone wrong with Jetty recognizing your new geog585 folder. I have been able to work around this situation by doing a full restart of the machine and starting GeoServer again. After that, the folder was recognized.

Creating the HTML page and writing the code

Now you'll create an HTML page and insert the JavaScript code that configures the map and popups. The steps below do not provide the code linearly you are expected to insert the code in the correct places as given in the instructions. Code is hierarchical, in the sense that some blocks run within others. It's more intuitive to describe the blocks of code rather than to give the code in its exact sequence. If you get confused about where the code is supposed to go, refer to the full example code at the end of this walkthrough page.

    Create an empty text file and save it as markets.html in your Jetty web folder (in other words, c:Program FilesGeoServer 2.x.xwebappsgeog585).

The above code contains the HTML head and body. This should give you a shell of a page, although you won't see the map show up yet.

In the head, notice the references to the Leaflet JavaScript and CSS files, both running on the CloudFlare CDN. There's also a reference to the style.css that you placed in your web folder earlier, which in some cases overrides the Leaflet stylesheet. Finally, there is a reference to the jQuery JavaScript library which is running on Google’s CDN. jQuery is a helper library that greatly simplifies some JavaScript tasks. We’re going to use it here to make a web request to query the WMS, since there’s no easy way to do a WMS GetFeatureInfo request in Leaflet.

In the body, notice there is a div element with id "mapid" that is intended to hold our Leaflet web map. The CSS style for this element is defined in style.css and it sets the width and the height of the map in pixels. If you wanted to change the map width and height, you would modify the CSS.

When the body of the page has loaded, it runs the init() function from the JavaScript code we’ll add later. That’s why you see <body onload="init()">.

From this point on, we will not make any changes to the head or body. We will be inserting JavaScript logic in the <script> tag.

This sets up a global variable named map that can be used throughout your JavaScript code. Then an initialization function called init() is defined, which you’ll recall is the function you set to run when the page body loads. The first thing the function does is instantiate a Leaflet map object within your mapid div. It then centers the map at 39.9526 N 75.1652 W at zoom level 13.

In this walkthrough you will insert the remaining JavaScript inside of the init() function where you see the . . . above.

  1. Now you’ll add some code to bring in your Philly basemap tiles. Insert the following in the init() function of your code, directly after the line where you called map.setView().

The above code creates a Leaflet tile layer that references your PhillyBasemap that you made with TileMill in Lesson 5. In the code above, you must modify the URL to contain your PSU Access Account ID so that the URL correctly points at your PASS space. Your code may require other modifications if the URL for your tiles is slightly different. Check your PASS space folder structure if you have doubts.

The URL to the tiles is provided in a generic format where z means zoom level number, x means column number, and y means row number. As long as you give Leaflet this tile URL structure, it will be smart enough to request the correct tiles as you pan and zoom around the map.

Notice how the tileLayer.addTo() method is used to add the layer to the map. The map object is passed in as a parameter. In some other mapping APIs like OpenLayers you call an add method on the map itself and provide the layer as a parameter.

This adds the WMS layer of the farmers markets to the map. Notice how Leaflet’s wms class is used for this. You give it some properties such as the URL, layers, and image format you want (all using WMS-friendly syntax), and Leaflet takes care of formatting and sending the GetMap requests and displaying the responses as the user zooms and pans around the map.

So far creating the map and adding the layers were pretty simple. 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

Note

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 (or 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 (or 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

Note

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.

Note

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 if:

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! The 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!


Watch the video: 3. Styling Geoserver data with SLD (September 2021).