Linked images are images that are stored outside of a Manifold project file and which are dynamically fetched into the project as necessary when the linked image is opened or otherwise used. Note that linked images cannot normally be re-projected (see comments below).
Images may be linked from a variety of external sources, including:
· Image libaries - Folders on disk that contain image tiles consisting of images in graphics formats supported by Manifold. For example, a large linked image may be linked in from an image library folder that contains dozens of smaller images in .tif format (the image tiles) that mosaic together to form the larger image. Image libraries are good for smaller collections of images. Larger collections of images or image tiles should be stored within a spatial DBMS (see below) for performance.
· Compressed images - Images stored on disk in ECW or JPEG2000 format.
· ECWP image servers - Servers providing compressed image data streams using ECW format.
· Google servers - Google servers providing images rendering maps or satellite images.
· Manifold IMS Web Sites - Manifold IMS can be configured, in addition to standard IMS usage or to OGC WMS image serving, to serve images as an image server.
· OGC WMS servers - Servers providing data streams of image data using OGC WMS format.
· Oracle servers - Oracle DBMS servers providing Oracle Spatial or Locator facilities within standard Oracle databases to store images.
· Spatial DBMS servers - Almost any databases managed by Manifold as spatial DBMS can store images and surfaces in a high performance way.
· TerraServer - Servers providing image data in TerraServer format.
· Tables and Queries - Linked images may be created dynamically from tables or queries.
Linked images are shown in the project pane using an icon that includes a yellow "database" cylinder to show they are created from some other source. Linked images are normally read-only.
Opening a linked image brings the data for the image in from the source. When the image window is first opened, it will appear with a gray, partially transparent background that will fill in as the image is brought into Manifold. Most linked images are linked to sources that send the image in as tiles, that is, as rectangular pieces that form a seamless mosaic of the complete image. As we zoom in or out of the image, or as we pan in different directions, Manifold will fetch tiles from the image source to create the appropriate view.
As the tiles are fetched from the source, they will fill in more and more of the image window. Manifold tries to fetch tiles that are closest to the center of the visible area of the imager and then will fetch tiles that are nearer to the edge of the visible area, in the expectation that we are usually most interested in seeing the center of the image and would like to begin viewing that while the rest of the image fills in.
The speed with which image tiles appear depends on the technology used by the image source as well as by the connection to the image source. For example, a linked image created from an ECW file stored on local disk will be breathtakingly fast even if the image is many gigabytes in size. Likewise, an image linked from a local Oracle server will be amazingly fast. However, an image using a slower technology, such as an image library assembled from .bmp files could be much slower to come into view.
Images linked from remote servers accessed by Internet connections, such as TerraServer or OGC WMS servers cannot be any faster than the Internet connection to that server or the speed of the server. Some OGC WMS servers, for example, are appallingly slow to begin with and are further overloaded with too many users. It can take seemingly forever to get images from such servers.
Manifold will try to help us out in such situations by caching any fetched tiles if the Cache data between sessions option is turned ON (the default) in the image linking dialog. In that case, if we ever return to a view already fetched, such as, for example, by panning to the right and then panning back to the left, Manifold will not need to fetch the necessary tiles a second time: they will be saved in cache and will instantly display.
Another important command used to get around slow image servers is the Image - Download command, which we can use to instruct Manifold to get all tiles for a desired view in background while we continue working on other things.
Linked Images from Tables or Queries
The tables and queries used to create linked images may be inside the Manifold project or they may be in external databases.
Linked images may also be created in a two step process, where the virtual table for an existing image is used in a query to manipulate that image or to fetch part of the image based upon desired criteria. A linked image can then be created from that query. This technique is often used within Manifold projects that will be used in an IMS website.
Linked images may also be created from tables or queries stored in external databases. For example, we could use a query to select all columns for all pixels in an image's virtual table and then export that query as a table into an .mdb file or to some other database storage.
When an image is linked from a table or query, each record in the table or query produces a pixel. The coordinates of the pixel are taken from the X and Y columns (cast to integer) specified in the Link dialog. The color of the pixel is taken from either the Color column or the channel columns.
Editing Linked Images
Although a linked image that appears in the project pane is normally read-only, in the case of linked images created from tables or queries it is often possible to edit that linked image by editing the data source from which it is created. For example, suppose we have a linked image created from a query that uses the virtual table of another image. We could change that linked image by editing either the original image or by editing the query.
Linked Images and IMS
Linked images are therefore perfect for a wide class of Manifold Internet Map Server applications where images must be dynamically updated based on changing information stored in database management systems. For example, an image providing a background to a map may be taken from an ECWP streaming server that provides a satellite image showing the weather in the region as it exists at the time, or an image showing a weather chart may be fetched from an OGC WMS server that synthesizes an image from a vector representation of weather data.
Linked Image Tiles are Fetched on Demand
One especially useful characteristic of images linked from image servers is that the tiles that comprise an particular view are fetched on demand only when that particular scene is viewed. When a user zooms or pans into a particular view (or jumps directly there as a result of a Goto or other navigation command) Manifold contacts the image server and fetches image tiles of the required resolution that are automatically formed into a seamless mosaic for the visual display that fills the image window at the desired zoom at the location specified. If the user zooms further into the image then higher resolution tiles will be fetched to the limit of resolution provided by the image server. Zooming yet further into the image inflates the single, full resolution tile on view to create an ever more pixilated display.
By default, the image tiles used to build requested views of a linked image will be cached on disk by Manifold. If a particular view of a linked image is revisited, such as by using the Back navigation toolbar button, Manifold will redisplay the desired view by fetching necessary tiles from the disk cache rather than from the image server. Such redisplayed views will normally be much faster than previously unseen views since disk access is a much faster process than streaming data through even a fast network.
If portions of a very large linked image, such as a linked image of the entire United States, are never viewed then the image tiles for those portions will never be fetched. This characteristic together with caching allows us to use linked images to great effect in certain applications, such as IMS applications.
Suppose our IMS application is a web site that shows the location of schools in Ohio. We would like to have an image layer in our web site that, when zoomed in, shows aerial photography from an image server so that photographic details of each school, such as the location and nature of athletic fields and other facilities, can be seen. Perhaps the intent of the site is to assist the operation of a state-wide soccer league so that league planners, coaches and parents can get a visual preview of different facilities before scheduling or attending soccer matches.
If the image server we would like to use provides state-wide data, we could create this application by simply creating a linked image for all of Ohio to use as a layer in our web site's map. The initial view when we create our application would consist of a relatively small number of very low-resolution tiles that form a mosaic to show the entire state.
As visitors to our site navigate to various individual schools (say, by giving the school's street address and going directly to each school, by picking names from drop down lists of counties and then school names or by some other suitably efficient navigation method), they will get portions of the overall Ohio linked image served to them at whatever resolution is required for the zooming and panning they do about each school. Image tiles for each view will be cached on disk.
The schools of greatest interest to visitors will naturally be viewed first and so the image tiles for those schools will be the first to be saved in cache. As a result, views for those schools will be fast and require no connection overhead to the image server, exactly the result we would like in a well-architected web site.
After a while as a result of many views of many schools by many visitors, the server machine will have many image tiles stored in cache on its hard disk. A visit to virtually any school in the system used for soccer games will utilize cached image tiles and will not require download from the image server. The cached image tiles on disk will represent a fraction of image tiles that are available for all of Ohio, clustered as they will be in a patchwork of tiles at the location of each school. But no image tiles will be wasted on high resolution views of vast stretches of farmland or other regions not viewed by visitors to the web site. Since a visit to almost any school will used cached tiles, the web site will be very fast as it will rarely need to fetch new tiles from the image server.
If we wanted to assure even greater efficiency we could apply a zoom range to the linked image layer so that it only appears when visitors to the web site are zoomed far into the map. If they are zoomed far into the map we can safely reckon they are looking at a close-up view of a particular school site and so the linked image layer should be displayed. In that case, should users choose to navigate to a particular school by successively panning and zooming further into the web site map (which presumably shows major streets and towns as an aid to navigation) instead of by jumping directly to a school using whatever clever navigation user interface we have provided, then no image will be displayed as background during the process of finding a particular school. No image will be displayed until the user zooms into a particular school and thus no image tiles will be cached during the process of finding a particular school.
That would be more efficient because we would avoid any delay while low resolution images of parts of Ohio are fetched in order to provide a background visual for such pan and zoom navigation to a particular school, and no space on disk would be consumed for any cached image tiles used in such navigation. It is true that if we did not use zoom ranges over time the server would accumulate in cache all of the low resolution image tiles for Ohio and many of the medium resolution tiles used in such navigation, so this method of navigation would become faster and faster as more tiles would become available from disk cache. It is also true that disk space is nearly free so that most webmasters for such a useful application wouldn't worry about using a few tens of gigabytes of additional disk space to allow showing a background image all of the time.
However, it does take time to build up a fast cache and a perceptual delay when panning is something that for psychological user interface reasons especially should be avoided. Most people have used Internet so much that they expect when they jump to a new location they may have to wait a few moments to get the display they want, but when they pan through an apparently seamless view of a map or an image they expect fewer delays. A further point is that for large regions the number of tiles saved for various intermediate views could get very large as users take various random paths of panning and successively zooming to find a particular location. Finally, although everyone enjoys a view from space, the visual clutter of a background image is usually not the fastest and most comprehensible way of helping visitors orient themselves. Simple, clear maps, the simpler the better, are usually the best way, with detailed images reserved for close-up views once a location of interest has been found.
Therefore, although we might get away with not using zoom ranges on a linked image of Ohio used in a web site, it is unlikely we would not use zoom ranges if the web site showed the entire United States. Even for a smaller region such as Ohio most webmasters would use zoom ranges to suppress the background image until zoomed far enough into the map to view an individual school.
Note: On demand retrieval of tiles as discussed above applies to images linked from Manifold Image Servers, images linked from OGC WMS servers and images linked from TerraServer.
Relink and Unlink
If a connection is lost between a linked image and its originating data, the Image - Relink command allows us to restore the connection. If we would like to convert a linked image into a regular image, the Image - Unlink command will sever all connections to the originating source and will convert it into a regular image.
Converting a Linked Image to a Local Image
An image linked from a remote server can be converted to a native (local) image within the project using the Image - Convert To command.
Limitations on Re-Projection
Except for limited exceptions of interest only to experts, compressed images, linked images and image libraries cannot in general be re-projected. They can only be re-projected into a projection that is affinely equivalent (change of scale and location only) to the projection in which the image exists. As a practical matter, this means that for most purposes such images cannot be re-projected or used in maps that use a projection different from the image.
For example, opening an ECW compressed image and attempting to re-project it to a different projection or dragging and dropping either an ECW compressed image or an image linked from some image server into a map that uses a different projection will fail. In such cases, Manifold will pop open a dialog telling us of the projection incompatibility.
If we would like to re-project such images, we should first convert them to an unlinked local image (in the case of linked images) or to an uncompressed image type (in the case of compressed images) or to a regular local image (in the case of an image library). We can then re-project the image as desired.
Linked Images and Map Projections
If we need to use a linked image in a map, the map should be created from the image so that the map uses the same projection as the image. If we try to include a linked image as a layer within a map that uses a projection different from the linked image, the image will not appear in the map because it cannot be re-projected into the projection used by the map. Manifold will warn us if we attempt to drop a linked image into a map with an incompatible projection.
One way around this projection limitation is to unlink the linked image so that it is converted into a local image. We can then re-project as we please, although of course in this case the dynamic linkage between the image and the source will no longer apply. It will be a static, local image stored in the project just like any ordinary image.
Note by the way that attempting to re-project such images on the fly by dropping them into a map that uses a different projection usually indicates a poor performance choice on the part of the user: usually, large images of the sort that are used as compressed images, linked images or image libraries are likely to be the largest, or among the largest, layers in any such map. It is therefore would be wisest to use their native projection as the projection for the map, so that when the map is displayed it is other, smaller layers that must be re-projected on the fly to display the map and not the large image layer.
To do so, create the map using the image layer first. This will assure that the map uses the image's projection. Next, drag and drop the other layers into the map. For maximum speed, re-project the other layers to match the projection used by the map. This is easily accomplished by (in the map window) right-clicking on the layer's tab and choosing Project to Map from the context menu.
If we attempt to create a map using several linked images at once that use different projections, then at least some of those images will have projections incompatible with that chosen for the map. Manifold will display a warning message if we attempt to do this.
The View - Properties dialog for components shows the data source of a linked component (such as an image library or other linked image) and other relevant information.
The Link / Share dialog accessed from the [...] browse button for linked or shared components accessed from the View - Properties dialog will provide a summary of the link or share properties. This will show the status of a shared component and whether or not changes in a linked component will propagate back to the data source.
For Enterprise Edition Users
Sharing a linked image to an Enterprise server places the linking information into the Enterprise server and not the actual image data. Importing or linking such a shared linked image to a local project will re-establish the connection to the relevant file or server. See the Enterprise Edition topic for information on Enterprise Edition.
Tech Tip: Using Linked Images in Print Layouts
It's not a good idea to use in layouts images that are linked from external servers (such as from ECWP servers, OGC WMS servers or TerraServer servers) because such images are downloaded as necessary to fill a particular view at a given zoom level and pan.
If such images are used in print layouts, it could well be that the tiles necessary to show the image at whatever resolution ends up being necessary for printing at a given printer resolution will not have been downloaded at the time the print job runs. Since it can take a long time to fetch such tiles, the system will use whatever is available for the print job, resulting in odd effects such as images that are blank or partially blank.
A further problem is that the image might change on the server between the time a print layout is created and when it is actually printed.
The way to avoid any unexpected effects is to first download the image to a regular image at the desired resolution and then use the regular image in the print layout.
Tech Tip: Permissions and Linked Images in IMS Applications
When using linked images in an IMS web application it is important that the web application has read and write permissions in the cache folder, or otherwise it will not be able to use the tiles cached for the linked image.
Linked Images from Google Servers
Linked Images from OGC WMS Servers
Linked Images from Oracle Servers
Linked Images from TerraServer
Virtual Tables for Images and Surfaces
Queries and Images or Surfaces