Module 4.2 - Interoperability Standards - WFS & WCS

Background

This week’s class focuses on two other key Open Geospatial Consortium standards that were created to enable access to geospatial data of a variety of types.

Web Feature Service (WFS)

A standard designed for providing on-demand access to features (typically points, lines, and polygons and more complex combinations of these feature types) and their associated attributes, in a variety of formats, and optionally filtered by spatial and other query parameters.

Web Coverage Services (WCS)

A standard focused on providing access to coverages representing a variety of data types, but particularly optimized for dynamic delivery of data based upon multi-dimensional gridded data.

Expected Outcomes

At the end of this class students should have an understanding of the following:

• The request-response model for OGC WFS, including the required and optional request parameters for the GetCapabilities, DescribeFeatureType, and GetFeature requests; and the response types generated in response to those requests.

• The request-response model for OGC WCS, including the required and optional request parameters for the GetCapabilities, DescribeCoverage, and GetCoverage requests; and the response types generated in response to those requests.

• An understanding of the distinction between WMS, WFS, and WCS for use in different usage scenarios (e.g. map images, vector, raster data access)

Key Concepts

• OGC WFS as a data access standard for features and their attributes with support for a variety of query methods including spatial and parameter values.

• OGC WCS as a data access standard for coverages representing spatio-temporal gridded data represented in 1- or more dimensions.

Lecture: Interoperability Standards - WFS & WCS

Note: The services demonstrated in the lecture may no longer work, or present different information as they are periodically modified by their providers

Presentation Slides

Lab Assignment: WMS and KML in Google Earth

You might have noticed in the WMS requests that you generated in the previous lab returned images that didn’t look “quite right” relative to what you may know of the shape of familiar features.

For example, a WMS request for a 200x200 pixel image for an area surrounding Bernalillo County (-107.2,34.7,-106,35.25) from the previous lab would be:

http://gstore.unm.edu/apps/rgis/datasets/609320d1-8d95-47a7-818f-64ca7bc66c3d/services/ogc/wms?
VERSION=1.1.1&SERVICE=WMS&REQUEST=GetMap&BBOX=-107.2,34.7,-106,35.25&
LAYERS=2007fe_35_county00&FORMAT=image/png&TRANSPARENT=TRUE&STYLES=&
SRS=EPSG:4326&WIDTH=200&HEIGHT=200

this request results in a map image that does not agree with the standard shape of Bernalillo county (depicted in the Google Map below) that we are accustomed to, regardless of the specific map projection being used.

This discrepancy is the result of a difference in the aspect ratio of the requested BBOX (-107.2,34.7,-106,35.25) and the requested image dimensions (200x200 pixels). When you compose a WMS GetMap request, you need to make sure that the aspect ratio of both the image size and BBOX match.

For example, if we calculate the aspect ratio of the BBOX we obtain the following values (remember that the BBOX is specified as a comma separated list of x,y coordinates: minx,miny,maxx,maxy):

BBOX width = (maxx) - (minx) = (-106) - (-107.2) = 1.2 degrees
BBOX height = (maxy) - (miny) = (35.25) - (34.7) = 0.55 degrees
BBOX aspect ratio = (BBOX width) / (BBOX height) = (1.2) / (0.55) = 2.1818

If we want to retrieve a map image that is 200 pixels wide, we need to calculate an image height that yields an aspect ratio that matches the BBOX aspect ratio. Harking back to basic algebra:

width = 200
aspect ratio = width / height = 200 / height = 2.1818
height = (height) / (aspect ratio) = 200 / 2.1818 = 91.667

So, if we request an image that is 200x92 (we have to request pixel dimensions in integers, so rounding to the nearest integer) we should get a representation that closely approximates the proper shape of features. The modified WMS request with the new images size is the following:

http://gstore.unm.edu/apps/rgis/datasets/609320d1-8d95-47a7-818f-64ca7bc66c3d/services/ogc/wms?
VERSION=1.1.1&SERVICE=WMS&REQUEST=GetMap&BBOX=-107.2,34.7,-106,35.25&
LAYERS=2007fe_35_county00&FORMAT=image/png&TRANSPARENT=TRUE&STYLES=&
SRS=EPSG:4326&WIDTH=200&HEIGHT=92

This process may be reversed to request images of a fixed size for use in a client interface, with the requested BBOX modified to match the aspect ratio of the target image. If, for example, images are being requested for a client interface with a fixed map size of 600x400 pixels, a corresponding BBOX can be derived using the same calculation.

If, for example, the area of interest for a map is 2 degrees wide, we can calculate the target height (in degrees) using the aspect ratio of the desired image.

image aspect ratio = (width) / (height) = (600) / (400) = 1.5
BBOX aspect ratio = (width) / (height) = (2) / (height in degrees) = 1.5
BBOX height = (width) / BBOX aspect ratio = (2) / (1.5) = 1.3333

If our area of interest extends from -106 to -108 degrees East Longitude, we can use the known target height of 1.3333 to generate a WMS BBOX of the appropriate aspect ratio. If the minimum Latitude of interest is 34.7 degrees North Latitude, the maximum BBOX Y value would be

BBOX Max Y = (BBOX Min Y) + (BBOX height) = (34.7) + (1.3333) = 36.0333

This set of calculations may be used to compose the following WMS request:

http://gstore.unm.edu/apps/rgis/datasets/609320d1-8d95-47a7-818f-64ca7bc66c3d/services/ogc/wms?
VERSION=1.1.1&SERVICE=WMS&REQUEST=GetMap&BBOX=-108,34.7,-106,36.0333&
LAYERS=2007fe_35_county00&FORMAT=image/png&TRANSPARENT=TRUE&STYLES=&
SRS=EPSG:4326&WIDTH=600&HEIGHT=400

Given that McKinley County NM is contained within the following BBOX: -109.5, 34.5, -106.5, 36.5

Question 1

What is the aspect ratio of this geographic region?

Question 2

What would be the height (in whole pixels) for a map image for this region that is 600 pixels wide?

Question 3

Formulate a WMS request that reflects the values determined in 1.1 and 1.2 above for the WMS service used above in the examples. Include in your answer both the actual WMS request and the returned map image.

Question 4

Formulate a WMS request for a 900x600 pixel map image that represents the full 3-degree width of the geographic region, and is based upon the minimum Y value of 34.5 degrees North Latitude. Include in your answer both the WMS request and the returned map image.

Question 5

Given a WMS that is represented by the following GetCapabilities request (the downloaded file will need to be manually opened in a text editor such as Notepad [Windows] or TextEdit [Mac]), formulate individual GetMap requests (using the same BBOX, WIDTH, and HEIGHT values that you used for Question 3 above) for each of the following layers: bmng2km, bmng500mA1, landsat, and doqq05

http://edacwms.unm.edu/cgi-bin/mapfiles/edacimagery?
SERVICE=WMS&VERSION=1.1.1&REQUEST=GetCapabilities 


Question 6

Which layers return map images that display image content? In other words, which images display actual aerial or satellite imagery as opposed to a "blank" image?

Sometimes when WMS layers are accessed, there is a limit on the map scales for which the map image will be returned. If a request is submitted for a map scale that is outside the range specified for a given layer, typically, a blank map image (an image that does not display any layer data) will be returned.

Questions 7

From examining the information for these layers in the GetCapabilities XML document requested above - which element in each layer’s service metadata do you think provides information about the scales for which the layer will return map images containing data?

You can effectively change the scale of a map image by changing the pixel dimensions of the requested image.

Question 8

Which map images display data for each of the following map image widths (remember to adjust the image height to match the BBOX of the request)

100 pixels

1000 pixels

Below is a link to a KML file that includes a single GroundOverlay element that, in turn, contains a single Icon and href element that contains a WMS request (including all layers in the service in the “LAYERS” parameter) to the imagery service you worked with in question 2, above.


EDACImagery.kml 


Open the supplied KML file in Google Earth and enable it by clicking the checkbox next to its name in the “Temporary Places” pane on the left side of the user interface. Zoom in over several steps (i.e. pause after zooming in to allow the imagery WMS requested by the KML file to load - the white box with the rounded arrows will be replaced by the imagery) to the intersection of Interstate 25 and 40 in Albuquerque.

Question 9

What do you notice as you stop zooming?

Question 10

How does what you see relate to the scale dependencies that were highlighted in question 5-8 above?

Open the KML file in a text editor (like Notepad or TextEdit). Using the original GroundOverlay element and its content as a template, create new KML files, one for each layer in the downloaded KML file, with each of the multiple layers in the original file being the only one included in the Layers parameter of the WMS request in the href element (remember to rename the GroundOverlay element so that they can be distinguished in the legend).

For example, change the following:

to:

in a kew KML file named:

mrgoc_2008_rast.kml

Question 11

What do you see in the map when you add the KML file depicting bmng2km to Google Earth and enable it?

Question 12

What happens when you change (by editing the KML file, saving the change, and re-adding the modified file to Google Earth) the image format in the KML WMS request from

image/jpeg

to

image/png

? If there is a change in what you see, why do you think it happens?

BONUS Question

What WMS parameter(s) are missing from the href element in the GroundOverlay in the KML? Why do you think it/they are missing?