TMS Servers

Manifold's TMS Server dataport connects to web servers using the Tile Map Service (TMS) protocol developed by the Open Geospatial Consortium (OGC).  TMS servers provide raster data, that is, images.   They do not provide vector drawings.   TMS servers are similar to WMS servers, but using a simpler protocol.   In recent years TMS servers have become rare, with most web servers switching to newer technology such as WMS or WMTS.

 

We can bring data from TMS servers into Manifold by creating a new data source of type Web Server: tms using the File - Create - New Data Source command.   Creating a data source from a TMS server leaves the data on the TMS server and links a read-only image and table into the project.   

 

See the Example: Spectacular Images and Data from Web Servers topic for illustrations from WMS servers providing raster data.

 

Connecting to a TMS server:

 

  1. Choose File - Create - New Data Source in the main menu, or right-click in the Project pane and choose New Data Source.

  2. In the dropdown menu choose More... to launch the New Data Source dialog.

  3. Choose Web Server: tms in the Type box.

  4. Enter the URL for the TMS data in the Source box.

  5. Default settings for other options will usually work for most TMS data.   Press Create Data Source.

  6. A new data source appears in the project.  Open it to see the image and table that is linked in from the TMS server.

 

Images and tables that are linked from TMS servers are neither selectable nor editable.

New Data Source Dialog and Controls

In the main menu, choose File - Create - New Data Source.   The dropdown menu provides a list of favorites to choose from as well as a More... option.  

 

 

Choose More... to launch the New Data Source dialog.   Choose Web Server: tms in the Type box.

 

 

Name

Name for the new data source, "Data Source" by default.  Specify a more memorable name as desired.  If we forget the origin of a data source we can hover the mouse over the data source name in the Project pane and a tool tip will provide connection information.

Type

Choose Web Server: tms in the Type box to connect to a TMS server over the web.

Source

A connection string to the web server TMS data. This may be a simple URL, or a very lengthy, complex  URL/connection string that embeds parameters such as keys that grant access or other parameters.  The connection string can also be entered using the Web Login dialog launched by the [...] browse button.

 Browse button

Click to launch the Web Login dialog, to allow use of a login and password plus use of a proxy server if desired.   The Web Login dialog is also handy for providing a Test button that can be used to test the connection.

Open as read-only

Open the data source read-only.  Has no effect with TMS servers since they are read-only in any event.

Cache data

Cache data downloaded from the server while the project is open.  Provides better interactive performance and greater flexibility with read-only data sources.  Checked by default.  Leave this box checked.

Save cached data between sessions

Save the cached data for the next time this project is opened, within the .map project itself in a Cache sub-folder in the System Data hierarchy.   Caution: checking this box can result in very large .map files when the results of browsing very large data from web servers are all saved.  However, having such data cached in the .map is handy for offline browsing of the project.

Create Data Source

Create the new data source in the project pane and close the dialog.

Edit Query

Launch the Command Window loaded with a query that creates the data source using the given settings.  A great way to learn how to use SQL to create data sources.

Cancel

 Exit the dialog without doing anything.

 

 

 Pressing the browse button next to the Source box launches the Web Login dialog, to specify a server and connection characteristics.

 

 

Server

The connection string for the server.  This may be a simple URL, or a very lengthy, complex  URL/connection string that embeds parameters such as keys that grant access or other parameters

Use login and password

Check this box for servers that require logging in with a login name and a password, providing the required name and password in the Login and Password boxes.

Use proxy server

Check this box when connecting through a proxy server.   The Proxy, Login, and Password boxes allow specifying the connection string to the proxy server as well as the login name and password required to use the proxy server.

User agent

Identifies what application (Manifold) is asking for a connection.  Some web servers want to know what client software is connecting, for compatibility or for business reasons.  The default string optimizes compatibility (Mozilla is very generic) while also identifying Manifold Release 9 as the client.  Users can adjust the string as necessary to comply with any special server requirements.

API key

Provide a key that authorizes use of an API when connecting to a proprietary data source that requires such a key.  This option is disabled for server dataports that do not use it.

Application key

A secondary application key or authentication code for those servers that may require it.   This option is disabled for server dataports that do not use it.

Timeout

Specify a time in milliseconds to wait for connecting to the specified server.  Use 0 for the default timeout, or specify whatever is the desired time to wait before giving up on the server.

Test

Press the Test button to try the connection using the specified parameters.   If successful, a Connection established information dialog will pop open.

 

Notes

Download manager - This dataport is accelerated using Manifold's internal, parallel, download manager, to fetch data from the server using multiple threads.

 

Problems connecting - Check the Log Window to see what is going on behind the scenes if an attempted connection does not work.     The problem is usually a wrong connection string, failure to provide required credentials such as an key string that authorizes access, wrong choice of protocol (the server uses TMS and the user picks something else), an incredibly slow server, a server that is offline or a server that is wrongly configured and which is not correctly using the protocol it claims to use.  

 

Visit the Manifold community forum and talk out difficulties with other users.  Make sure to post full information on what you are doing, the connection URL you used, all details of how you tried to connect (including all settings in the data source dialog), what happened, and what the Log Window reported.    If other users cannot help you, spending a tech support incident will produce an authoritative analysis of the issue.

 

Try the URL in a browser - Checking the URL by launching it in a browser can reveal many problems with the URL or with the web server.  If a URL does not work in a Manifold web server dataport, try exactly the same URL in a browser.  If a browser cannot connect to the URL, the Manifold web server dataport will not be able to connect to it either.  If a browser cannot connect to that URL, that indicates the problem is the URL or the web server.   For example, the web server might be offline.  Or, for example, If the browser connects to a page other than the actual web service endpoint, such as, to a web page that lists various options for web servers, that shows the URL is not a URL for a web server but a URL to some other sort of web page.   

 

Connection problems are often caused by incorrect URLs.  There might be a typographical error in the URL or the URL might not be an endpoint to a functioning server but instead a URL to some other web page.  The server responding to the URL may have geographic restrictions (surprisingly common) that does not respond to connections from IP addresses that are thought to be in a canceled country.  Trying the URL in a browser will fail in such cases.  Web servers may also have other restrictions, such as only allowing connections from white listed IP addresses, from paying clients, or from those clients that use a special security scheme.  

 

Web servers are often slow or mis-configured -   Some web servers to which we might connect using TMS, WMS, WMTS, WFS or other connection standards can be incredibly unresponsive or, despite allowing a connection, will not allow data to be fetched.   If pressing the Test button results in a successful connection, or if layers available are displayed when we expand the data source, but then when we try to display an advertised layer nothing happens, we can open the Log Window to see what is going on.

 

Here are a few lines of log window information for a happy session, connecting to a WMS server in New Zealand run by the ever-efficient LINZ organization:

 

Web request: (root)::[Data Source] (GetCapabilities) (0.578 sec, 13.0 KB)

Web request: (root)::[Data Source]::[layer-767] (GetMap) (1.255 sec, 47.9 KB)

Render: [Data Source]::[layer-767 Image] (1.561 sec @1.0)

 

In contrast, a few lines of log window information for an unhappy session, attempting to connect to the WMTS server run by the French cartographic service IGN but getting no image for a cadastral parcels layer:

 

Web request: (root)::[IGN]::[CADASTRALPARCELS.PARCELS_bdparcellaire_b] (GetTile) (0.070 sec, 0 B)

*** (root)::[IGN]::[CADASTRALPARCELS.PARCELS_bdparcellaire_b] (GetTile) The remote server returned an error: (403) Forbidden.

Render: [IGN]::[CADASTRALPARCELS.PARCELS_bdparcellaire_b Image] (0.315 sec @1.0)

 

From the above we see an empty cadastral parcels image was rendered because the remote server refused to provide tiles in response to the GetTile request, returning a 403 error Forbidden.    Finding out why a web server refuses service can involve some detective work.  

 

The server might require a special key for access, a key we are trying to use may be out of date, a login and password may be required for some resources, the connection string may have been copied and pasted inaccurately or, of course, in the case of IGN, the server may be refusing to work to show solidarity with striking railroad workers or air traffic controllers.

 

Keep in mind that just because a web server offers tiles via various standards like TMS or whatever does not mean that it will be fast or even reasonably tolerable.  Some web servers are painfully, incredibly slow and will take many seconds or even minutes per tile.   When images do not appear or fill in with painful slowness a look at the Log Window can show the problem is not our Internet connection or Manifold, but just incredibly slow response from the web server.

 

Some webmasters may insist their web servers are correctly configured even when explicit errors are pointed out.   That can happen even in the case of  national cartographic services as reported, for example, as discussed in various threads in the georeference forum.  

 

User-unfriendly server configurations - Correctly configured web servers may sometimes make user unfriendly configuration choices, for example, only starting to show data when the view is zoomed in to some specific area. That is a perfectly legal configuration, but it may catch users by surprise if they open a web served layer and it is blank, because they have not yet zoomed sufficiently far into a particular region.  If a web server layer is blank, add it to a map with a "known good" background layer, such as Bing Streets, and then zoom into the area of interest that is likely to be covered.  The Geosciences Australia web server, for example, often serves blank layers until one zooms into Australia, and at times far into Australia.

 

Must Have Internet - It seems obvious that to connect to a web server we must have a live, functioning Internet connection.  What might not be obvious is that sometimes we may have only a partial Internet connection, without realizing we do not have a full Internet connection.  A classic example is using a browser, such as Opera, which may ignore failed IPv6 DNS resolution but work OK using IPv4 DNS resolution.  Without IPv6 DNS resolution we can browse Internet using Opera but we might not be able to connect to Microsoft, Google, or some other web servers.   

 

Manifold's web server connections, just like the latest Google Chrome and Microsoft Edge browsers, require full IPv6 DNS resolution.   That normally happens automatically using whatever IPv6 DNS servers are assigned by our Internet service provider, but at times IPv4 DNS continues to work OK while the IPv6 DNS servers assigned by our ISP do not work.  If we are using Opera, and not Edge or some other browser that uses IPv6 DNS resolution, we might not notice that our ISP-provided IPv6 DNS resolution is not functioning.    We might only notice the problem when trying to use an image server or other web server within Manifold and it does not work.

 

If we cannot get a display from a web server, we can check the Manifold Log Window. If the log reports that a connection cannot be made, in Windows network dialogs for our Internet connection  we can try setting the IPv6 DNS servers to some "known good" DNS servers.   A good choice is using Google's public DNS service, using the following addresses for primary and backup DNS server addresses:

 

2001:4860:4860::8888
2001:4860:4860::8844

 

Collections of Web Servers - Check the Product Downloads page for pre-packaged project files in Release 9 / Viewer .map format that Manifold publishes which contain collections of dozens of popular web servers data sources.

 

Embedded command tokens:  Some web servers, notably TMS servers but possibly WMS servers,, use embedded command tokens.  Use Manifold's custom setting to connect to those.   See the File - Create - New Data Source topic for how to do that.

 

 

See Also

Project Pane

 

Web Servers

 

File - Create - New Data Source

 

ArcGIS REST Servers

 

CSV Servers

 

Custom Servers

 

GeoJSON Servers

 

Image Servers

 

JSON Servers

 

OSM Servers

 

WFS Servers

 

WMS Servers

 

WMTS Servers

 

Example: Spectacular Images and Data from Web Servers - A must see topic providing a gallery of views illustrating how Manifold can use web servers such as image servers and other free resources to provide a seemingly endless selection of spectacular background maps, satellite images and GIS data with nearly zero effort.

 

Example: Vector Layers from an ArcGIS REST Feature Server - Visit an ESRI web site, copy a URL, and then use that URL to connect to an ArcGIS REST web server that shows petroleum fields in Kansas, getting the data as a vector drawing layer. Style the layer as if it were local.  ESRI refers to ArcGIS REST servers that provide vector data as feature servers.  

 

Example: Connect to a WMS Server for National Map Layers - Visit the National Map services web page, copy a URL for a shaded relief layer from USGS, and then use Style to enhance that shaded relief data for combination with other layers and really spectacular effects.

 

Example: Connect to a WFS Server for State Government Data - Gathering our courage, we connect to a WFS server that provides 1200 vector layers, run by the state of Massachusetts.   We open a layer showing airports and then scrape the vector data into our own local storage.  

 

Example: Connect to a Custom Server for Cadastral Data - We connect to a custom image server that provides cadastral information originally from the French national cartographic agency, IGN.  We create a map and use the Style pane to re-style the web served image on the fly into a more usable form.

 

Example: Connect to a Custom OpenRailwayMap Server - We connect to a custom server that provides an OpenRailwayMap view of railroads worldwide, showing railway, tram, and subway infrastructure based on OpenStreetMap data.  Our first try at creating a data source does not work.  After consulting the Log Window we try again with a slight adjustment and our second try works.

 

Example: Connect to an OSM Vector Server - We connect to an OSM Server that provides a vector layer containing points and lines in the OpenStreetMap database.  We then show how to scrape (copy) data from the OpenStreetMap server into local storage.  We extract building footprints from the local copy.

 

Example: Raster Layers from an ArcGIS REST Image Server - Visit an ESRI web site, copy a URL, and then use that URL to connect to an ArcGIS REST web server that provide a raster layer showing a mosaic of aerial photographs near Portland, Oregon.