An OGC WMS server is one that can communicate using "Open" GIS Consortium Web Mapping Service (WMS) or similar communications specification. A WMS server produces an image of GIS data and streams the image to requesters. If the original data is vector data such as a drawing, the WMS server does not provide the drawing data, it only provides an image view of the data in some image form like a GIF or JPG.
Manifold is capable of linking images from WMS servers. Manifold will automatically negotiate with the WMS server to achieve a mutually understood level of the various WMS specifications that have been published. When operating as a WMS client Manifold will automatically correct several types of malformed URLs that may be returned by defective servers.
Manifold can also function as a WMS server as part of Manifold's Internet Map Server capabilities. See the Map Server Overview topic for additional information on running Manifold as a WMS Server..
WMS servers create an image at the desired size and then stream views of that image in tiles to the client depending upon the view position and the zoom desired. As we zoom farther into the image more tiles of greater detail are sent up to the limit of resolution implied by the specified size of the image. Note that the original choice of image size implies a limit of resolution per pixel implied by the extent of the original data divided by the number of pixels.
Manifold will cache image tiles streamed from an OGC WMS server so that panning and zooming in the image can be as fast as possible. For example, when zooming into an OGC WMS image Manifold will make use of less detailed image tiles that have already been fetched to quickly render the desired view as best as possible and then progressively update the display as more detailed tiles stream in.
Images linked from WMS servers are read-only images and cannot be re-projected. They can only participate in maps that use the same projection as the image, although they may be used in maps that have the same projection (coordinate system) except for the datum used. At any time, an image linked from a WMS server may be unlinked to create a local image that may be re-projected and otherwise altered as desired.
An image linked from an image server may be converted to a local image within the project either by using the Image - Unlink command or the Image - Download command. The Unlink command converts the existing linked image to a local image at whatever resolution is currently in use. The Download command may be used to automatically fetch all image tiles at any available resolution to create a local image at that resolution.
Images linked from a WMS server may also be exported to image files. In that case, the exported image will be the same as that which would be obtained by unlinking the WMS image.
Note that exporting or unlinking an image linked from a WMS server will only use the data already downloaded from the server and will not attempt to download any more data. It will also only use the data for the most detailed image level. It is usually a good idea to use Image - Download to check how much data has already been downloaded for the most detailed image level prior to exporting or unlinking the image.
If the connection is severed between a linked image in a project and the image server (such as, for example, if the project is moved to a different machine and a local URL must be changed to a global URL) the link to the image server may be re-established using the Image - Relink command.
Another way to create a local image from a linked image is to open the linked image and then to use the keyboard F6 command or the Tools - Make Image command. The Make Image dialog allows us to create a local image in several different ways from the linked image without unlinking the linked image. For example, we can use this command to create an image of the displayed window or of the entire linked image at a desired number of pixels or scale.
To create a linked image from an OGC WMS Server:
1. Choose File - Link - Image
2. In the Link dialog's Files of type box choose OGC WMS Servers ()
3. In the Link OGC WMS Data dialog enter a connection string for the Server and press the Refresh button in the dialog's toolbar.
4. When the Refresh button is pressed, Manifold will communicate with the WMS server to find out what layers are available. This can take a very long time, minutes at a time, in the case of slow WMS servers. When the catalog of layers (the "Capabilities" in WMS server jargon) has been fetched, it will be displayed in the Layers pane.
5. Specify the desired image Size, select the desired Layers and the desired Style for each layer and then press OK. Choosing more than one layer tells the WMS server to create an image that combines all selected layers into one image.
6. An image using a linked image icon will appear in the project pane using a name based on the name of the WMS server. Highlighting the image in the project pane will report it as an OGC WMS image in the status bar. This image can now be opened and used like other images. OGC WMS images are read-only. Until the image is completely fetched, it will appear in an image window as a partially transparent gray rectangle covering the extents of the image. If the image is used as a layer in a map, it will appear in transparent color in those parts not yet fetched as tiles from the WMS server.
Link OGC WMS Data Dialog Controls
URL to be used to connect to the WMS server. The Server combo remembers recently used WMS servers, including those used in earlier sessions of Manifold.
Desired size of the image. For maximum efficiency, use image sizes that are evenly dividable by the Tile Size.
Size of tiles to use when fetching the image, ranging from 64 x 64 pixels to 1024 x 1024 pixels. Larger sizes take longer to download but use storage space more efficiently.
Refresh - Update the Layers pane with layers available from the WMS server.
Select All - Check all layers for retrieval.
Select None - Uncheck all layers.
Select Inverse - Uncheck all checked layers and check all unchecked layers. A fast way to retrieve all but one layer: click Select None, check the one layer not desired and then click Select Inverse.
After the Refresh button is pressed, the Layers pane shows images available from the WMS server. The Style option chooses which optional style will be used.
Controls the background color of the image. If the server can serve images in PNG, GIF or other format that retains invisible pixels, the option is turned off (but can be turned on). If the server can not serve images in a format that retains invisible pixels, the option is turned on and can not be turned off.
Cache data between sessions
Controls whether the cache folder used to cache image tiles retains its content between different sessions of Manifold or not. By default, the option is turned on.
Link each layer as a separate image
If unchecked (the default) all layers will be composed into a single image. If checked, all layers will be linked as separate images in the Manifold project. If the Link OGC WMS Data dialog is used to relink an existing image, the option is disabled (and turned off).
Calls up the Tools - Options - Proxy server dialog that allows configuration of a proxy server connection, if a proxy server is used to connect to the Internet. Passwords supplied for proxy servers will be stored in encrypted form.
Most WMS servers cannot provide a default image size, so the Link OGC WMS Data dialog provides a Size control to specify the desired size of the image. The larger the dimensions, the greater the resolution per pixel and thus the deeper we will be able to zoom into the image. The default dimensions are 4096 x 4096, which is a good tradeoff between deepness of zoom and the amount of data which must be fetched from the server to display the entire image at high zoom.
Images are served by WMS servers as tiles. Tiles may range in size from 64 x 64 pixels to 1024 x 1024 pixels. The default setting of 256 x 256 is a good tradeoff between efficiency and flexibility.
Because images are fetched as tiles, the default dimensions for overall image SIze are slightly uneven (4096 instead of, say, 4000) because the image is fetched in tiles that are 256 x 256. Dimensions of 4000 x 4000 would work, but would not be as efficient because the overall size dimensions are not evenly dividable by the tile size.
Layers displayed in the Layers pane are arranged according to their hierarchy on the server. Layers that contain no data and are used to group other layers (virtual layers) use gray checkboxes. Layers that contain real data (data layers) use black checkboxes. The total number of checked data layers is shown in the status readout below the layer tree.
User Names and Passwords
When connecting to some image servers, the URL given must include a user name and a password in the URL string. Manifold supports a common way of doing so using URLs in the form of:
For example, if our user name was johnbgood and our password was 3bart8tt2 and the hostname for the image server was imagesupermarket.com, we could use a URL connection string of:
Note that the above style is just one popular way webmasters arrange to accept user login names and passwords as part of an image server URL. There are various other methods in use. If the image server we work with uses the above method we are in luck
Some WMS servers may offer to display a given layer using one or more optional styles within the synthesized image. If so, the Style cell for that layer will be a combo that allows choice.
For example, in the above illustration the Crosshairs layer has a variety of styles advertised by the server. We can change the style from the default red wire to blue wire if we like.
Not all layers will have a Style option. What styles are available for any given layer will be up to the WMS server providing the data, not Manifold.
Fetching Image Tiles from a WMS Server
Consider the following scenario: We link an image from a WMS server and a new linked image icon appears in the project pane. We open the image in a window zoomed to fit. Manifold will paint the area occupied by the image in semi-transparent gray and will start retrieving the image tiles required for the current view from the WMS server. As tiles are retrieved, Manifold will update the display.
Because image tile retrieval occurs in a background thread, we can continue doing other work as the image assembles from tiles retrieved from the WMS server. If the WMS server is fast and our Internet connection to the WMS server is fast, the image will assemble much faster than if the WMS server is slow or if our Internet connection is slow.
Suppose we zoom in to some region within the image, which we can do before all tiles have been fetched. Manifold will immediately begin retrieving tiles for the new view, which take priority over tiles in the old view. When Manifold retrieves all tiles in the new view, it will go back and continue retrieving any tiles in the old view that were not fetched when we zoomed in. Manifold does this so that the old view is ready for use just in case we decide to return to it later, say, by using View - Go Back. If we close the project file or delete the image the system will stop retrieving tiles from the server.
Tiles are retrieved one at a time, but tiles for several images can be retrieved simultaneously and more than one window containing an OGC WMS image can be open. The active window has elevated priority when rendering OGC WMS images in more than one open window. If we display an OGC WMS image in two windows (for example, in two maps), Manifold will first try to retrieve tiles for the active window, that is, the window that has the focus, and then for the window in the background.
Note that some WMS servers are run as advertising functions for the company providing the data shown in the images. WMS servers are often configured to mark each tile they send with a copyright text, a logo or some other mark. If this is the case the mark will be repeated on each tile. Do not blame Manifold for this behavior as it is the WMS server that is disfiguring the tiles.
Manifold caches tile files retrieved from the WMS server so that panning or zooming to previously-viewed scenes does not require a re-fetch of previously retrieved tiles.
The Cache data between sessions option controls whether or not cached tile files will be retained in the cache folder between different sessions of Manifold. By default, the option is turned on.
The location of the cache folder is specified by the Data Cache item in Tools - Options - File Locations. The default value for the location is %MyDocuments%, so by default each user's files will be stored in the user's own cache folder. If we actually use the My Documents folder for other documents, we might not want to have many cache files appear in the same folder as various other working documents we use.
In that case, it is a good idea to create a folder within the My Documents folder, perhaps called Cache and then we can set the location for the data cache to %MyDocuments%\Cache. This will keep all of our WMS cached files in a separate folder so that we will not have to wade through long lists of cached files when working with other documents.
When multiple users are working it might make sense to modify the default Data Cache setting so the cache folder is on a shared resource available from all machines on the local network. For example, if there is a machine called Storage on our local network with a Cache folder on its C: drive, we might use a Data Cache setting of \\Storage\C\Cache for all users. In that case, any tile files that are retrieved by one user will be available to all users so that tile files for a given view will never have to be fetched twice over the network.
Cache folders are organized as is as follows:
· Each combination of layers, styles and background color for a given URL is given a separate subfolder used to store PNG, GIF or other files containing individual image tiles.
· Names of tiles include the level and the XY coordinates of a tile.
· The overall dimensions of the image are in level . The dimensions in level 1 are half those of level 0, and so on.
· The subfolder containing the tiles also contains an XML file (currently named RESOURCE.XML) with the URL, layers, styles and background color used for the image.
Caution: Cache files persist forever and, in extreme cases, use up your free disk space unless they are manually deleted. See the recommended actions in the Managing Cache Files topic.
WMS Version Negotiation
Clicking Refresh the Link OpenGIS WMS Data dialog begins a negotiation with the WMS Server of the WMS protocol version to be used. Regrettably, the spastic approach used by OGC to design WMS has resulted in a plethora of irritatingly dissimilar WMS protocols that do pretty much the same thing. Manifold must negotiate with the WMS server to learn what protocol it uses. Manifold first tries to use the protocol version suggested by the WMS server. If the server refuses to suggest a WMS version or the version it suggests is not supported by Manifold, Manifold tries to use versions 1.3.0, 1.1.2, 1.1.1, 1.1.0 or 1.0.0. If the WMS server supports none of these versions, the connection fails. As the OGC bureaucracy dreams up yet more WMS variations, future versions and service packs of Manifold will add them to the roster of protocols to attempt.
The negotiation process initiated by clicking Refresh is done in a background thread to avoid locking the user interface.
Images linked from a WMS server will have their coordinate systems automatically adjusted by Manifold so the image has the same aspect in X and Y dimensions. This corrects images fetched from servers that do not conform to the WMS specification and thus distort the images they return (a surprisingly frequent problem).
Projections and OGC WMS
There is no standard way for an OGC WMS server to describe the coordinate systems (projections) it supports that covers all coordinate systems supported by Manifold. There are several semi-standard ways using schemas to describe the coordinate system used by a WMS server that cover various subsets of coordinate systems.
When used as an OGC WMS client, Manifold supports all schemas for describing coordinate systems that have been uncovered by manifold.net, no matter how many or how few OGC WMS servers that currently exist actually use them. Given the tendency of OGC to come up with new "standards" that are never used to any significant degree, it is always possible yet another schema may be introduced in the future that is not recognized by Manifold as an OGC WMS client; however, we feel confident that the current edition of Manifold when used as an OGC WMS client covers all such schemas either proposed or in actual use.
In contrast, when used as an OGC WMS server, Manifold only supports EPSG codes. EPSG is arguably both the richest and the most widely used schema within the OGC community. Manifold running as a WMS server only supports EPSG mostly to avoid confusing various non-Manifold WMS clients, some of which, unlike Manifold, cannot auto-adapt to a variety of coordinate system encoding schemas.
As rich as it is, the EPSG schema only supports a fraction of the coordinate systems that can be used in Manifold. If the coordinate system used by the component served by Manifold can not be expressed using the EPSG schema, that is, if it does not have an equivalent EPSG code, then the Manifold OGC WMS server reports the coordinate system as latitude / longitude and will re-project the data for that component on the fly into Latitude / Longitude. For large components that will have a terrible impact on performance.
Obviously, it is essential that any webmaster setting up a Manifold application as an OGC WMS server should check the projections used by the components being served and should make sure that they are coordinate systems that can be expressed using the EPSG schema.
The current list of coordinate systems which have EPSG codes may be obtained free of charge from the following link, clicking the link to the epsg-v69.zip or subsequently published file.:
If all we are doing is using Manifold as an OGC WMS client we don't need to worry about the above because any schema used by the OGC WMS server we access as an image server will be recognized by Manifold.
Most WMS Servers are Absurdly Slow
In a perfect world, Internet connections to WMS servers will be very fast and images obtained from such servers will pop open with the click of a mouse. It may be possible to achieve such performance if the WMS server is an in-house machine serving private clients over a purely local network or over a private, high speed Intranet.
In the real world, WMS servers are often too slow to use for most practical purposes. There are two reasons for such incredible slowness: First, WMS servers tend to be very slow in their response to requests because, of course, like any popular site they are overloaded and the bureaucracies that run most of them tend to skimp on resources for public users. Second, it is almost a rule of nature that the Internet connection between our computer and the distant WMS server will be excruciatingly slow. Therefore, if we plan on using WMS servers we should get used to seeing semi-transparent gray images that get slowly assembled, tile by tile, into a final image.
Even if we have a fast link to Internet, such as a 6000/608 DSL connection, we must keep in mind that the rest of Internet and, in particular, the link to the WMS server can be very, very slow. With some slow servers it can take five minutes to fetch layers available once the Refresh button is pressed and then another five or ten minutes for an image to be populated. It only takes a few experiences with WMS servers to be very grateful that Manifold can download WMS image tiles in background while we continue on with other work.
Once the image has been fetched and browsed to whatever extents and zooms are needed then it will be saved in Manifold's cache. From then on, response will be fast as tiles are fetched from the local cache on our machine and not through an (incredibly slow) Internet connection.
A WMS server does not serve the original GIS data: it serves a snapshot of that data in the form of an image. To understand the difference, consider a map within a Manifold project that consists of a dozen layers, where each layer might be a drawing, surface or other component. At any time we can open the map and use the Tools - Make Image command to create an image from that map.
We can then open that image. However, the image we made from the map is not the map nor does it contain the vector data from that map. It's more like a screenshot. The image created and served by a WMS server is the same sort of image. It's just a "screenshot" at the resolution specified.
If the objective is to grab data that was originally in raster form, the use of WMS servers can be a very good idea and very useful. If the objective is to make authentic use of real data, then, unfortunately it is not such a good idea as raster images are very poor, at best partial replacements for bona fide vector data.
When used to serve images of vector data, the WMS server does not provide the original data to users in a form that is genuinely useful to GIS users. Instead, only a raster image representation of the original, true vector data is provided. Instead of getting access to the original data so the user can create his or her own maps, edit them, analyze them as they see fit and publish them as they would like, the user only gains access to that image view that the publisher deems appropriate to present.
When used in this way, WMS servers are therefore becoming popular with bureaucracies that would like to give the appearance of public access to data without actually providing any public access to the real data. This is a good example of how so-called "Open" GIS specifications are used in real life to assure "closed" systems and to enforce centralized control.
It is, of course, perfectly legitimate for private data owners not to want to publish the underlying data that is used to create WMS server images. We simply want to emphasize that publishing a WMS image is not the same as providing the underlying data, a distinction that many government WMS server sites fail to make.
There are many ways of using WMS servers. For example, Manifold itself can function as a WMS server. In theory, WMS servers can be a great way of creating background layers that can be varied, or to serve images or images of surfaces in a variety of applications. In the case of vector data, there's nothing wrong with using a WMS server to provide a handy source of images of that data (for people who do not have GIS capability). If desired, access to the underlying data can be assured by providing some means of easy download of the original vector data, such as an FTP or other link for downloads.
OGC WMS Servers and ISI Drivers
While most connections to image servers within Manifold (connections to TerraServer, Virtual Earth Maps, Virtual Earth Earth and Manifold Image Servers) are accomplished using Manifold Image Server Interface (ISI) drivers, the connection to OGC WMS servers does not use ISI drivers. OGC WMS servers are a standard unto their own and are sufficiently unlike other image servers (such as TerraServer or the Virtual Earth servers) that they cannot use ISI. Therefore, the internal Manifold connection to OGC WMS servers is specifically hard-wired for those servers.
Manifold's Image Server Interface (ISI) is an open standard published by manifold.net to make it easy for third party developers to create drivers that connect image servers to Manifold System. Image servers that can work with Manifold System using an ISI driver are called Manifold Image Servers and can be automatically accessed as if they were a built-in part of Manifold System using the File - Link - Image dialog. See the Linked Images from Manifold Image Servers topic.
Linked images from Manifold Image Servers
Linked Images from Manifold IMS Web Sites
Linked Images from TerraServer
Image - Download
Image - Relink / Unlink
Images can be Inefficient
Tools - Make Image
Public Access to Public Data
GIS and Networking
Map Server Overview