Manifold Server, called Server for short, is a read-only, parallel, spatial database server that also includes a TCP data sharing server, an HTTP map server and WMS server. This topic discusses use of Manifold Server as a WMS server to serve images and structured information in response to WMS requests.
Server can run in three modes:
See the Manifold Server, topic for basic instructions on installing, activating, and running Manifold server in either TCP or HTTP mode, including a complete list of command line options.
To use the Manage
Services dialog, a Server license must
be installed for all users. If
the license is not installed
for all users, it will not be possible to run new services from the dialog.
Check that setting in the Help
- About dialog to verify that the license has been installed
for all users.
Server operation as a WMS server is closely integrated with Server operation as an HTTP server to publish maps to Internet. Please make sure to review the Server: Publish Web Maps topic before proceeding with this topic.
When the HTTP server creates a web page, it automatically also creates an OGC WMS 1.3.0 compliant WMS data source that any client capable of using WMS can use. The WMS data source provides the following features:
OGC WMS - Manifold Server's HTTP server now supports OGC WMS 1.3.0, generating a WMS page.
Automatic WMS - WMS support is automatic and does not need any additional configuration. To connect to the WMS server, add /wms to the end of the URL for the web page served by the HTTP server for the WMS URL. For example, if Server is serving an HTTP page to http://127.0.0.1:8080, the WMS URL will be http://127.0.0.1:8080/wms.
GetCapabilities, GetMap, GetFeatureInfo - The WMS server responds to OGC standard requests such as GetCapabilities for an overview of what the server provides, GetMap to generate an image of desired size covering a specified bounding box, and GetFeatureInfo to provide attribute data at a particular spot in an image produced at a desired size covering a specified bounding box.
Single Layer - The published component is served to WMS as a single layer. Responses for GetFeatureInfo requests choose layers for which attributes are provided at the clicked spot by using the same precedence and pick status specified for layers as is used by the Info tool in the web user interface. Future builds will likely expose multiple layers to allow turning them on and off via the WMS API.
Automatic Coordinate Systems - If the published component's coordinate system is an EPSG coordinate system, the coordinate system of the WMS layer wil be that coordinate system. If the published component's coordinate system is not an EPSG coordinate system, the coordinate system of the WMS layer will be the default pseudo-Mercator coordinate system, with the published component's coordinate system reprojected on the fly into pseudo_Mercator, which is EPSG:3857.
PNG Images - Images produced by the WMS interface are always PNG with transparent background. Future builds will likely allow specifying a solid background with desired background color via the WMS API.
Partial PNG Opacity by Layer - Server uses smart transparency (opacity) to generate PNGs for WMS. If a layer in the originating Server component uses partial opacity, that same partial opacity will be used for pixels involved in that layer when constructing the PNG images served by WMS. That allows using the resulting WMS layer in WMS clients as a layer above other layers, which will be partially visible through the partially transparent sections of the PNG. See that effect in the video showing WMS use.
Non-virtual Layers - Rendering images for WMS does not render virtual layers such as North arrows, scale bars, legends or the Layers pane background color. This is done to support WMS clients (first and foremost 9 itself) that cache rendered WMS tiles and stitch final screens from cached data.
The following URL strings are examples of what can be entered into a browser to try various requests, using the example Total Eclipses web site at https://manifold.net/ims9 - adding a /wms to the end creates the base URL for the WMS server. URLs should be entered into the browser as a single line with no spaces.
A GetCapabilities request returns overview information about the WMS server at the specified URL. The minimum URL string includes the base URL, the name of the service (WMS), the version (1.3.0) and the request (GetCapabilities).
https://manifold.net/ims9/wms?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetCapabilities
Try the URL above by copying it and pasting it into the URL box for a browser like Microsoft's new Edge browser or Google Chrome. The result is XML text displayed by the browser that provides an overview of the capabilities of the WMS data source at the https://manifold.net/ims9/wms URL. For example, it reports that the coordinate reference system (CRS) used by that WMS site is EPSG:3857, that the format for GetFeatureInfo requests is application/json., and that the maximum width and size of the image that can be returned is 4096 by 4096 pixels. It also reports the maximum bounding box of the data set in the coordinates used by the data.
A GetMap request returns an image of the requested size that encloses the requested bounding box in the coordinates of the data. An example of a minimum URL string for a GetMap request is:
https://manifold.net/ims9/wms?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&CRS=EPSG:3857&BBOX=1450000,5000000,2600000,6000000&WIDTH=800&HEIGHT=600&FORMAT=image/png
Try that URL string by copying and pasting it into a browser to see the image it produces. If the web browser displaying this page refomats the URL to be more than one line, make sure that it is entered into the browser as a single line with no spaces. It should be a portion of the example website centered on the Balkan Peninsula to the east of the Adriatic Sea (illustration reduced in size):
Note that the image generated is what the web site would show, with layers automatically turning on based on zoom ranges and other settings. The WMS image uses transparent color in between vector objects and does not show the blue color created by the background layer in the Layers pane in the web site. In the image above, the browser shows a gray-beige color in such regions. If the PNG image were saved and then opened in a graphics editor like Photoshop, we would see that the regions for ocean areas where there are no country objects in the vector layer that is used in the project are indeed transparent pixels. That allows stacking such WMS GetMap generated images in web applications that compose custom displays.
The URL string shows use of the minimum parameters required:
SERVICE |
Always WMS. |
VERSION |
1.3.0, or if working with future releases that might be supporting a newer version of WMS, whatever is reported by a GetCapabilities request. |
GETMAP |
Use GetMap, or if some other request is desired, GetCapabilities or GetFeatureInfo. |
CRS |
The Coordinate Reference
System (projection)
used by the WMS server. For the example site, EPSG:3857.
For other sites, whatever is the EPSG coordinate system
reported by a GetCapabilities request.
When a Manifold component served by Server uses a
projection other than an EPGS projection, it will be automatically
re-projected on the fly into EPSG:3857, the Pseudo-Mercator projection
almost universally used by web servers showing maps.
Important: WMS versions before 1.3.0 used an SRS parameter. Version 1.3.0 changed that to a CRS parameter. When recyling URL strings from prior WMS versions, make sure to change the SRS parameter to a CRS parameter. |
BBOX |
The bounding box to
be displayed, with the image zoomed to fit the bounding box. Coordinates
are in minimum x, minimum y, maximum x, maximum y order, where
the x coordinates are longitude and y coordinates are latitude.
The bounding box coordinates are numbers in the coordinate reference system used by the WMS site, as should be specified in the CRS parameter. The example string above uses EPSG:3857, the Pseudo-Mercator projection, which uses coordinates that are in meters. If the CRS is the latitude / longitude WGS 84 projection, EPSG:4326, then the BBOX coordinates will be in decimal degrees latitude and longitude. For example, if the CRS is in latitude / longitude, EPSG:4326, then a BBOX=-104,22,-100,26 parameter will specify a bounding box for a region in central Mexico. |
WIDTH |
The width of the image to generate, in pixels. |
HEIGHT |
The height of the image to generate, in pixels. |
FORMAT |
Always image/png. Future editions of server might add options to output in other formats. |
Try variations of the above URL but using a different BBOX specification to generate images for different parts of the world. Note how the zoom level will be varied automatically to just fit the desired bounding box within the specified width and height of the image that is generated. For example:
BBOX=-1450000,-5000000,2600000,6000000
Will be a larger bounding box, that includes Africa in the generated image (illustration reduced in size):
Using a different BBOX parameter...
BBOX=2950000,2620000,4000000,3700000
...will generate a view of the eclipse in Egypt, approximately the same as picking the Egypt location in the demonstration HTTP Total Eclipses web site (illustration reduced in size):
Figuring out coordinates to use for bounding boxes when experimenting with WMS is easy: create a new, blank drawing that uses Pseudo-Mercator projection and create a map that has that drawing as a layer with Bing Streets or some other desired image server layer as the background. Pan and zoom to the desired view, and then in the drawing create a rectangular area in the drawing covering the desired view that has about the same aspect ratio (horizontal to vertical proportion) as the width and height of the image that will be created. Style the area to use transparent fill color.
Next, alt-click the area to pick it, and in the Coordinates tab of the Info pane note the coordinates of the four corners of the rectangular area to use in the BBOX parameter specification. For use in bounding boxes those can be rounded to reasonably even numbers, like those used in the examples. Since changing the coordianates in the coordinates pane dynamically updates the rectangular area shown in the map, it is easy to round coordinates to reasonable values and still get the bounding box desired.
A more sophisticated way to get bounding box coordinates for web applications is programmatically or using SQL. For example, if we have a web site that we would like to show a zoomed to fit view of a country, we can ask the user what country is desired and then using a local table of countries generate on the fly the enclosing bounding box, pick out the coordinates of that bounding box and then use those coordinates within the BBOX parameter in a WMS URL string we assemble on the fly to fetch the desired image from a WMS site.
A feature is Esri nomenclature for an object, such as an area, line, or point. A GetFeatureInfo request gets the attribute data for an object at a particular location. A GetFeatureInfo request uses most of the same parameters as a GetMap request to define a view of interest, and in addition it specifies a location within that image in pixel coordinates, fetching attribute data for the object at that location and reporting in JSON text format the attribute data for that object.
A GetFeatureInfo request is an indirect way of using a raster image served by WMS to get data from vector objects that are in a vector layer from which that image was created. There are no vector objects in the images that are served by a WMS server: there are only pixels. However, when images are created from vector layers, for example, an image that shows a map of countries where the countries in the GIS data are vector area objects, the server knows that regions of pixels in an image showing that country were created from a vector area object in that location. It knows that if it is told to fetch data from a specific location within the region of pixels that show the country, to fetch attribute data for the vector area object at that location.
The GetFeatureInfo request does not generate an image. Instead, it uses the BBOX, WIDTH and HEIGHT parameters to imagine what image would be created by GetMap, and then it uses the pixel location specified to know what object, if any is at that location, to query for attributes. One way to understand how GetFeatureInfo works is to imagine that the specified image is created by GetMap, and then to see what the "click" location would be based on the pixel location.
In fact, that is how GetFeatureInfo requests often are used by web developers: they first generate an image using GetMap, saving all the BBOX parameters used, and then when a user clicks at a spot on the image the web app notes where on the image the user clicked and uses those pixel coordinates to create a GetFeatureInfo request to fetch the desired data. The web app then consumes the JSON text returned and formats it however the web app wants, to display a nice table or to use the information in further steps, such as fetching a URL from one of the attributes and popping open another web page. That workflow is why pixel coordinates are used to specify the desired location in a GetFeatureInfo request, because those are easy for a web developer to get from clicks on a web page, without any need for messy or confusing conversions into whatever spatial coordinates are used by the web site.
An example of a minimum URL string for a GetFeatureInfo request is:
https://manifold.net/ims9/wms?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetFeatureInfo&CRS=EPSG:3857&BBOX=2950000,2620000,4000000,3700000&WIDTH=800&HEIGHT=600&i=400&j=300&
INFO_FORMAT=application/json
Try that URL string by copying and pasting it into a browser to see the image it produces. If the web browser displaying this page refomats the URL to be more than one line, make sure that it is entered into the browser as a single line with no spaces.
The result should be a short page with JSON text that reports the attributes for the total eclipse segment at the i, j pixel location specified.
The equivalent GetMap request to show the image that the imagines it is using is:
https://manifold.net/ims9/wms?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&CRS=EPSG:3857&BBOX=2950000,2620000,4000000,3700000&WIDTH=800&HEIGHT=600&FORMAT=image/png
That shows the region of Egypt for the 2027 August total eclipse, with the eclipse path crossing over the center of the image (illustration reduced in size):
The i, j pixel location specified for the GetFeatureInfo request of &i=400&j=300 is right at the center of the 800 by 600 pixel image, so it is querying the eclipse path segment at the center of the image to get the attributes for that segment, which is an area object in the underlying vector drawing that is used to produce the WMS raster image. That segment just happens to be very near the maximum totality duration for the eclipse path, a whopping 383.1 seconds of totality, a totality duration that will not be exceeded for over 65 years.
A GetFeatureInfo request uses most of the parameters used in a GetMap request, with one change and two additions:
SERVICE |
Always WMS. |
VERSION |
1.3.0, or if working with future releases that might be supporting a newer version of WMS, whatever is reported by a GetCapabilities request. |
GETMAP |
Use GetMap, or if some other request is desired, GetCapabilities or GetFeatureInfo. |
CRS |
The Coordinate Reference
System (projection)
used by the WMS server. For the example site, EPSG:3857.
For other sites, whatever is the EPSG coordinate system
reported by a GetCapabilities request.
When a Manifold component served by Server uses a
projection other than an EPGS projection, it will be automatically
re-projected on the fly into EPSG:3857, the Pseudo-Mercator projection
almost universally used by web servers showing maps.
Important: WMS versions before 1.3.0 used an SRS parameter. Version 1.3.0 changed that to a CRS parameter. When recyling URL strings from prior WMS versions, make sure to change the SRS parameter to a CRS parameter. |
BBOX |
The bounding box to
be covered by the virtual image imagined by the request, with
the image zoomed to fit the bounding box. Coordinates are
in minimum x, minimum y, maximum x, maximum y order, where the
x coordinates are longitude and y coordinates are latitude.
The bounding box coordinates are numbers in the coordinate reference system used by the WMS site, as should be specified in the CRS parameter. The example string above uses EPSG:3857, the Pseudo-Mercator projection, which uses coordinates that are in meters. If the CRS is the latitude / longitude WGS 84 projection, EPSG:4326, then the BBOX coordinates will be in decimal degrees latitude and longitude. For example, if the CRS is in latitude / longitude, EPSG:4326, then a BBOX=-104,22,-100,26 parameter will specify a bounding box for a region in central Mexico. |
WIDTH |
The width of the virtual image imagined by the request, in pixels. |
HEIGHT |
The height of the virtual image imagined by the request, in pixels. |
i |
The distance in pixels
from the left margin of the image to the desired location.
Important: WMS versions before 1.3.0 used an x parameter. Version 1.3.0 changed that to an i parameter. When recyling URL strings from prior WMS versions, make sure to change the x parameter to an i parameter. |
j |
The distance in pixels
from the top margin of the image to the desired location.
Important: WMS versions before 1.3.0 used a y parameter. Version 1.3.0 changed that to a j parameter. When recyling URL strings from prior WMS versions, make sure to change the y parameter to a j parameter. |
INFO_FORMAT |
Always application/json. Future editions of server might add options to output in other formats. This is different than the FORMAT parameter used in GetMap requests. |
Important: A GetFeatureInfo request reports attribute data for the object at the i, j pixel location specified, if there is an object at that location and if the layer containing that object is the uppermost and pickable, as set in the Layers pane. If there is no vector object at that location in the component being served by Manifold Server, or if that layer cannot be picked, there will be no data returned. If there are multiple objects overlapping from more than one vector layer that can be picked at the i, j pixel location specified, attributes for the object in the uppermost layer will be returned.
A good example is the Total Eclipses demonstration site, where the layers in the map being published have been set up so only the eclipse path layers are pickable. In some locations eclipse paths from different layers overlap each other. The drawing layers for most of the map in the demonstration site are layers showing countries, and those have been set to not be pickable, so that clicks on them using the Info tool in the demonstration web site will not generate any attribute data. Only the eclipse path layers are pickable, so clicking on one of them with the Info tool will show attribute info.
Likewise, using a GetFeatureInfo request for an i, j pixel location which would not generate any attribute info in the web site also will not generate any attribute info for the GetFeatureInfo request: a blank web page will result, with no JSON info. A custom web application that used GetFeatureInfo requests to pull data for clicks on a desired eclipse location using the demonstration WMS server would use logic that in the event of a click that returned no info to report to the user some error message, such as "No eclipse path at that location... please click on an eclipse path."
Alas, the demonstration WMS site is limited so that anyone wanting to use it as a general-purpose background map or for custom eclipse web sites will find it not responding after a while. It is provided to illustrate WMS use for this documentation, not for unlimited production use.
Web pages created by Server usually serve map components that contain many layers, some of which will use Layer Opacity to create the desired visual effect.
For example, the screenshot at left below illustrates a portion of the example Server web site that shows totality paths for total eclipses of the sun. The site is created from a map of many layers, where the eclipse path layers use 50% opacity so the elements of the map underneath the eclipse paths are visible to provide context. The islands seen in the screenshot are in a layer that has 100% opacity, so objects in that layer completely cover anything in layers below. The blue ocean regions are part of the background of the map.
The screenshot at right above illustrates how the layers are rendered in a WMS image. The screenshot shows the WMS image used in a WMS client (Manifold Release 9) as a layer above an image server layer that shows satellite imagery for land areas and hill-shaded bathymetry in ocean areas.
Pixels in the WMS image have been rendered by Server in a range of opacity from fully opaque (pixels for the islands) to partially opaque (pixels for the eclipse path) to fully transparent (pixel locations not covered by any of the objects in any layer in the original map). The WMS image pixels for regions covered by the eclipse path but not by any other layer in the original map have been rendered with partial opacity, so the bathymetry layer can be seen through those partially opaque pixels.
We can see the transparency used in the PNG images served by right-clicking the image in a browser created by a GetMap request and choosing Save image as to save it as a PNG file. We can then open the PNG file in Photoshop or some other graphics editor to see that it does indeed use transparent and partially transparent pixels.
For example, the illustration above shows a screenshot of such an image in a graphics editor where a checkerboard background is used to enable regions of transparent pixels to be seen. The image is taken from a WMS GetMap request using the demonstration Server web site.
The use of such partial opacity in original layers can be used to create useful visual effects when combined in WMS clients with other layers below the WMS layer. Achieving partial transparency in WMS images is one reason Server uses PNG format for the image tiles it sends out via WMS, since PNG format allows per-pixel variation in opacity.
WMS clients send requests to WMS servers for image tiles that cover the geographic region the user has brought into view by panning and zooming. The Manifold WMS server renders on the fly the stack of vector and raster layers it is displaying into a single raster image for the desired view, chops that image into image tiles of standard size using a standard format (in Manifold's case, PNG), and sends those tiles through Internet to the WMS client.
Sending images through Internet takes time, so to speed up the responsiveness of the client many WMS clients will use cache, local memory in the client that stores tiles that have already been fetched from the WMS server. If the user pans and zooms to a view that has already been seen, for example, by using a "back" arrow to see a previous view, the WMS client will not ask the WMS server to re-send those same tiles, but instead will re-display them from local memory. Getting image tiles from local memory is far faster than resending them through Internet.
Many WMS clients will also use cache in cases where a requested view is not exactly the same as a previously displayed view but differs slightly in zoom. In such cases the WMS client will reuse image tiles previously fetched, but will interpolate them slightly to the desired zoom level. Such interpolation also is far faster than fetching new tiles from the WMS server.
Manifold Release 9 when operating as a WMS client also caches data when the Cache data option is checked (it is by default) when creating a new WMS data source. Release 9 both caches image tiles, and it also interpolates from cached tiles to avoid re-fetching tiles for slight changes in zoom. We can therefore use Release 9 to explore how cache may affect the display.
When a WMS client caches image tiles, changing zoom level can cause discontinuous changes in appearance of the display as previously-fetched tiles in cache are interpolated to match the zoom level being viewed by the user.
For example, when using Release 9 as a WMS client we are getting tiles from a slightly higher scale interpolated down or from a slightly lower scale interpolated up. The text size will thus always fluctuate between being slightly bigger or lightly smaller than it would be if each tile was always fetched directly from the server, without using cache, and thus always rendered on the fly for the exact zoom level used for the view.
The visual result will be that the display will be fuzzier (from interpolation), especially with text labels where fuzziness is more visible, than it would be if cache was not used. Text size in labels will also vary in size as cached tiles fetched for a smaller zoom are interpolated to be larger to fit a larger zoom, and vice versa for tiles fetched for a larger zoom than currently viewed.
We can avoid both effects by unchecking the Cache data button when creating the WMS data source. That will force 9 when used as a client to always fetch fresh tiles that are an exact match for the current zoom level used by the view.
Note that this is a client setting when using any WMS viewing client to connect to and to view WMS data. It applies to any WMS client that connects to a WMS page served by Server. It is not a Server setting. Server is perfectly happy to render on the fly and to send out all image tiles that any WMS client requests of it. Effects like fuzziness or labels that jump between larger and smaller, depending on zoom level, are caused by client software that decides it is faster to reuse tiles that have already been fetched, even if they do not match the current zoom level, than it is to ask Server to send new tiles that exactly match the zoom level used.
Note also that this discussion only applies to WMS servers, like Manifold Server, which can render on the fly tiles that precisely match the zoom level requested by a client. Some WMS servers are not capable of on the fly rendering, but instead are limited to only serving image tiles from a pre-rendered collection of tiles provided by some other package. With such WMS servers, it does not matter if WMS clients that connect to the server cache or do not cache image tiles, because the server can only provide the tiles it has on hand, which likely will not match the exact zoom level the client wants and thus must be interpolated.
For example, suppose we create a map of Mexico that shows the states and state names of Mexico in a larger font and also the main cities and city names in a smaller font:
Seen in a desktop display like the illustration above, the features and labels are razor sharp. If the same map is served by Server as shared data (that is, not as a web site), the features and labels also always will be razor sharp.
Features and labels also will be razor sharp when viewing the HTTP web site produced by Server from that map in a browser, like in the illustration above. That is because Server always renders on the fly images that are sent out through HTTP to browsers.
The situation can be different when using a WMS client. We can see that by creating two different data sources using the exact same WMS URL served by Server, one with the Cache data box checked in the New Data Source dialog, and the other with the Cache data box not checked.
We launch Release 9 and then choose File - Create - New Data Source - More...
In the New Data Source dialog we enter a name for the data source that reminds us the data in it is cached. We choose the wms server dataport in the Type box and we enter the URL to the WMS data source in the Source box. In this case, we are running Server locally on the same machine that is being used for our desktop Manifold Release 9 session, so the URL is a local IP address. We add /wms to the address to connect to the WMS service that Server automatically provides for any web site it creates.
We make sure the Cache data box is checked (the default) and we press Create Data Source.
We then repeat the above procedure to create an uncached WMS data source to the same WMS URL:
For the WMS uncached data source we create, we uncheck the Cache data box. Press Create Data Source.
We create maps for the image in both data sources, and then open both in the same sized, undocked windows next to each other on our desktop, to make comparisons easy. Both open windows show the same map, using image tiles fetched from exactly the same WMS data source, which in this case is a Manifold Server WMS data source.
Starting with the cached version, we pan and zoom to a view that shows the characteristic, slight fuzziness in WMS views that fall into zoom levels between tiles that have already been fetched are are now being interpolated from cache:
The fuzziness is less apparent in thin features like the boundary lines between states, but it is more apparent in text labels. We can compare that view to the window that shows the same view, but taken from the uncached data source:
We immediately notice three differences in the window showing the uncached WMS data source compared to the cached WMS data source:
The uncached display is razor sharp, just like in a desktop window, or in an Internet browser showing the HTTP display served by Server.
The number and arrangement of labels is different from the cached data source, with more labels appearing in the uncached window.
A manifold.net watermark appears in the uncached window.
All three differences arise from the uncached version fetching fresh tiles that precisely match the zoom level of the view, and not reusing tiles that have already been fetched and are stored in cache, but which do not match the zoom level of the view:
The display is razor sharp because there is no interpolation of tiles that use a slightly larger or smaller scale than the zoom level of the view. In the uncached window, fresh tiles have been precisely rendered to match the zoom level of the view and sent through Internet to be displayed.
Label number and arrangement are different in the uncached data window because Manifold on the fly arranges labels to suit the precise view being used. The cached data source's window uses image tiles that were rendered for a scale where fewer labels could fit, so some labels were not rendered for those tiles. When the cached data source's image tiles were reused and interpolated to match the scale used in the cached window, those image tiles did not include all the labels that might have fitted into the new scale. In contrast, the image tiles rendered for the uncached data source's window could have label placement computed for the scale used in that window, which allowed more labels to be rendered.
The watermark does not appear in the cached data source's window because, although it was within the view when the image tiles being fetched from cache were rendered, at the current scale/zoom used by the cache window it is no longer in view. The uncached window has asked for freshly rendered tiles to be sent from Server that match exactly the window's viewport and scale, so Server can position the watermark in view. With cached Server WMS data sources the watermark will appear and disappear depending on how tiles can be reused from cache, while with uncached Server WMS data sources the watermark will always appear.
When connecting to WMS data sources served by Manifold Server, if the Internet connection to the server is fast and we want displays that are always sharp, uncheck the Cache data box when creating the WMS data source in Release 9.
If our Internet connection is slow, the server is slow, or if we want the fastest possible display even at the cost of fuzziness, leave the Cache data box checked, the default.
When used as a WMS client, Manifold gives us the option to turn off use of cache by unchecking the Cache data box. If we are not using Manifold as a client to connect to a WMS data source but instead are using some other software package as a client, that other package might not give us the ability to turn cache off and on.
Note also that while Manifold Server always renders tiles on the fly for maximum sharpness, other WMS servers might not have that capability. If we are using Release 9 as a client to connect to WMS data sources and the WMS server to which we connecting does not have the ability to render image tiles on the fly to precisely match the requests our client makes, it will not make any difference whether we check or uncheck the Cache data box when using Release 9 as a WMS client.
WMS vs WMTS - According to OGC, WMS is a service for which servers render tiles on the fly, and WMTS is a service for which servers issue tiles from pre-generated collections of image tiles. So why the discussion in this topic that some WMS servers might not render tiles on the fly? The reason is that some software packages which provide WMS protocol services might not generate tiles on the fly but instead might use tiles from pre-generated collections, either interpolating them or otherwise serving something other than a freshly rendered tile that precisely matches the view in use by the client.
File - Create - New Data Source