GEO 583 Internet Mapping and Distributed GIServices

Back Up Next

Unit  FOUR (Session One):


horizontal rule


horizontal rule


A Uniform Resource Locator (URL) is a short string that identifies resources in the Web.  The format of URL strings indicates the syntax and semantics of formalized information for location and access of resources via the Internet.

A URL contains the name of the scheme being used (http, ftp, gopher,...etc.) followed by a colon and then a string (:// whose interpretation depends on the scheme. 

For resiliency, programs interpreting URLs should treat upper case letters as equivalent to lower case in scheme names (e.g., allow "HTTP" as well as "http"). 

The interpretation of a URL depends only on the identity of the characters used.  In most URL schemes, the sequences of characters in different parts of a URL are used to represent sequences of octets used in Internet protocols.  For example, in the ftp scheme, the host name, directory name and file names are such sequences of octets, represented by parts of the URL. 

(Source: W3C, RFC1738, by T. Berners-Lee et. al, 1994,  )

Examples:   --> change the Border --> border
      \_/   \______________/\________/ \___________/ \__/
       |           |            |            |        |
    scheme     authority       path        query   fragment


The use of URL was introduced in 1994.  Later on, the W3C developed a few extended schemes called "URN" and "URI".  The scopes of URL, URI and URN are illustrated in the following graph. 

        |         ________________                              |
        |        |  ftp:          |                             |
        |        |  gopher:       |                             |
        |        |  http:       __|____________                 |
        |        |  etc        |  |  urn:      |                |
        |        |_____________|__|            |                |
        |                URLs  |               |                |
        |                      |_______________|                |
        |                             URNs                      |
Uniform Resource Identifier. The generic set of all names/addresses that are short strings that refer to resources.
Uniform Resource Locator. The set of URI schemes that have explicit instructions on how to access the resource on the internet.
Uniform Resource Name.  An URI that has an institutional commitment to persistence, availability, etc. Note that this sort of URI may also be a URL.

(Source: Naming and Addressing, W3C,


horizontal rule

The Function of URL

horizontal rule

URLs can be used to communicate between HTTP servers (Web servers) and clients or send user's commands to the Web servers.

Example: Google Search Engine:  Search for "Internet/Mapping"  ( )

Google search example


%URL example: (to prevent the confusion of Non-ASCII characters)

"Internet/Mapping" =  %22Internet%2FMapping%22

%22 = "

%2F = /



HTML URL-encoding Reference

URL-encoding reference

horizontal rule

The Software Architecture of Internet Map Server

horizontal rule


1. The Xerox Map Viewer Example (Two-tier Architecture)

The software framework of the Xerox map viewer is a two-tier architecture (Clients and Servers).  The HTTP clients can submit their requests by sending URL to the HTTP server.  The HTTP server will parse the URL strings and then launch the extension (Common Gateway Interface) to invoke two perl programs (MAPWRITER and RASTOGIF) located on the same machine.

Map images in GIF format were generated by the two separate utility programs on the Sun UNIX server.  The first program, MAPWRITER, produced raster map images from two public domain vector map databases.  The second program, RASTOGIF, converted raster images to GIF format. 

After the RASTOGIF generate a new GIF image, the CGI program on the server will create a new HTML with the new GIF image link and POST the new HTML file back to the client-side Web browser.



Here are the two examples of encoded URL for Xerox Map Viewer.


border=1  (Turn on the country-border theme)

lon=117.75 (Longitude)

lat=25.03 (Latitude)

proj=rect (Projection uses Rectangles)


color= 1 (Turn on the color display)

db=usa (Access USA database)

feature=alltypes (Turn on all types of features)



More URL-command-based Example:

 (TerraServer USA)

TerraServer USA


Some Web-based Mapping Services DO NOT use URL for the communication between Client browsers and the server.  ( They can use XML,  ArcXML, GML, KML, or Socket (binary) communication directly).


horizontal rule


Generic Web Mapping Service Framework (THREE TIER architecture)

In general, most Internet map servers adopt a three-tier architecture for the system implementation .  The first tier is called “the client tier” which includes the user-side web browser and user-resident Java applets/HTML documents.  The client tier is used by the user to make requests and to view maps and remote sensing data.  The second tier is the middleware tier that includes the Web Server and the Server Connectors (such as Servlet connectors or ASP connectors) to bridge the communication between clients and the map servers.  The third tier is the data storage tier that includes the map server and the database server.  The three-tier software architecture of web-based GIS provides customizable functions for different mapping applications and scalable implementation for different hardware.

Web GIS architecture



2. The System Architecture of Alexandria Digital Library 



Three-tier client-server architecture


Client----(HTTP/URL)---Middleware (Web Server)---(SQL)---Server (Database server)


Multiple services (map browsing, catalog indexing, metadata searching...)


(Source: Frew, J., Freitas, N., Hill, L., Lovette, K., Nideffer, R., & Zheng, Q. (1998). The Alexandria Digital Library System Architecture. In J. Strobel & C. Best (Eds.), Proceedings of the Earth Observation & Geo-Spatial Web and Internet Workshop '98, February 17-19th, 1998 (Salzburger Geographische Materialien, vol. 27). Salsburg: Instituts für Geographie der Universität Salzburg.


horizontal rule

OGC Web Map Services (WMS)

Implementation Specifications (1.0 and 1.3)

horizontal rule


OverView  (source: OGC, new:  2005)


OGC specifications:

This specification describes a standardized communication mechanism and interface syntax for Web Map Servers. 


In Version 1.0OpenGIS Web Map Server Interface (WMS) defines (2000)

A Map Server can do three things.  It can:

1. Produce a map (as a picture, as a series of graphical elements, or as a packaged set of geographic feature data),

2. Answer basic queries about the content of the map, and

3. Tell other programs what maps it can produce and which of those can be queried further.

To first order, a standard web browser can ask a Map Server to do these things just by submitting requests in the form of Uniform Resource Locators (URLs).  The content of such URLs depends on which of the three tasks is requested.  All URLs include a Web Mapping Technology specification version number and a request type parameter.  In addition, 

1. To produce a map, the URL parameters indicate which portion of the Earth is to be mapped, the coordinate system to be used, the type(s) of information to be shown, the desired output format, and perhaps the output size, rendering style, or other parameters.

2. To query the content of the map, the URL parameters indicate what map is being queried and which location on the map is of interest.

3. To ask a Map Server about its holdings, the URL parameters includes the "capabilities" request type.

(source: The OpenGIS WMI specification 1.0.0, OGC, 2000, p. 9)

Three Operations: 







horizontal rule

2004  OGC Web Map Service (edited by ISO/TC 211).

A Web Map Service (WMS) produces maps of spatially referenced data dynamically from geographic information.

This International Standard defines a "map" to be a portrayal of geographic information as a digital image file suitable for display on a computer screen. A map is not the data itself. WMS-produced maps are generally rendered in a pictorial format such as PNG, GIF or JPEG, or occasionally as vector-based graphical elements in Scalable Vector Graphics (SVG) or Web Computer Graphics Metafile (WebCGM) formats.

(Questions:  What is a "Map " based on ISO's definition?  Is a shapefile a map? Is a JPEG image a map?)

This International Standard defines three operations:


one returns service-level metadata;


another returns a map whose geographic and dimensional parameters are well-defined; and


an optional third operation returns information about particular features shown on a map.


Web Map Service operations can be invoked using a standard web browser by submitting requests in the form of Uniform Resource Locators (URLs). The content of such URLs depends on which operation is requested.

In particular, when requesting a map the URL indicates what information is to be shown on the map, what portion of the Earth is to be mapped, the desired coordinate reference system, and the output image width and height. When two or more maps are produced with the same geographic parameters and output size, the results can be accurately overlaid to produce a composite map. The use of image formats that support transparent backgrounds (e.g., GIF or PNG) allows underlying maps to be visible. Furthermore, individual maps can be requested from different servers. The Web Map Service thus enables the creation of a network of distributed map servers from which clients can build customized maps.

This International Standard applies to a Web Map Service that publishes its ability to produce maps rather than its ability to access specific data holdings. A basic WMS classifies its geographic information holdings into "Layers" and offers a finite number of predefined "Styles" in which to display those layers. This International Standard supports only named Layers and Styles, and does not include a mechanism for user-defined symbolization of feature data.

(What are the difference between maps and feature data?)

horizontal rule


Four Types of Services


There are four main processing stages in a Web Map Server:



Filter Service: This stage is to create a connection between the Map server to the GIS database (relational or OO DBMS).  Usually, the connection channels could be established by standard DBMS communication techniques, such as SQL, ODBC, or OLE DB.  Filter Service will only retrieve a subset of geographic data objects based on user's requests.



Display Element Generator (DEG) Service:  This stage is to process the information item received from the filter service (a subset of geodata objects) from the original database format (coverages, shapfiles,...) into a graphic representation (could be either vector or raster) with appropriate symbols and colors defined for each geodata object.



Render Service:  This stage is to convert the well-defined geodata objects from the display elements (objects with symbols, colors) to an actual graphic format (GIF, JPG, or PNG). 



Display: This stage is to display the graphic format on the client-side's screen.  


(source: The OpenGIS WMI specification 1.0.0, OGC, 2000)


Three Types of Clients

Based on the service catagories defined by the OpenGIS WMI specification, there are three types of clients:


(source: The OpenGIS WMI specification 1.0.0, OGC, 2000)



In networking terminology, the thick client is defined as having operations and calculations executed on the client-side. On the other hand, a "thin client" may require that selected operations run on the server-side. Whether the client-side GIS component should be thick or thin will depend on the task and associated performance requirements. 

For example, it may be appropriate to use thick clients for map display services to let the user take over the many intuitive decisions of graphic design, layout, etc. Alternatively, network routing or location modeling may be better off to run on the server side because complicated calculations and algorithms may be more efficiently handled by the server, without an intervening network.  The role of client and server components should be dynamic and changeable.  The balance of functionality between client services and server components will be a critical issue for the success of Internet mapping and distributed GIS (Tsou and Buttenfield, 1998).

Interface Specification (URLs)


Only focus on the picture case (thin clients). 


The next version of WMI will focus on the other cases.



Three Interfaces: 







1. The Map Request (GetMap)

(source: The OpenGIS WMI specification 1.0.0, OGC, 2000)



1. The Feature Request (GetFeature)

(source: The OpenGIS WMI specification 1.0.0, OGC, 2000)


1. The Capabilities Request (GetCapabilities)

(source: The OpenGIS WMI specification 1.0.0, OGC, 2000)

horizontal rule

WMS Examples:

horizontal rule

Microsoft TerraServer USA (A good example to show the GetMap operation.



Examples: OGC WMS Viewer

(Show the advantage of WMS to connect to multiple Servers to form a single map.)


horizontal rule

Three User Case Scenarios:


1. The Picture Case (OpenGIS WMI Specification)   (Raster-based)

(ArcIMS Image Server)


(source: The OpenGIS WMI specification 1.0.0, OGC, 2000)


2. The Graphic Element Case (Pre-defined symbols, colors with vectors)

(AutoDesk MapGuide)

(source: The OpenGIS WMI specification 1.0.0, OGC, 2000)


3.  The Data (Feature) Case (OpenGIS WFS Specification)  (Vector-based, GML)


ArcIMS Feature Server


ARC/INFO 8 as a client to access remote databases


(source: The OpenGIS WMI specification 1.0.0, OGC, 2000)

horizontal rule

Web Feature Service (WFS) and Web Coverage Services (WCS)

horizontal rule

Open GIS Consortium (OGC) initiated two types of communication protocol standards for web-based GIS.  The first one is the OpenGIS Web Map Server (WMS) Implementation Interface Specifications, which provides guidelines for current raster-based Internet map servers with the specifications of HTTP contents and Uniform Resource Locators (URLs) communication syntax (OGC, 2002a). 

The second standard is the OpenGIS Web Feature Service (WFS) Implementation Specification.  The Web Feature Service allows a client to retrieve geospatial data encoded in GML (vector-based) from multiple Web Feature Services (OGC, 2002b).  The development of WFS adopted XML-based communication interfaces and GML for describing vector-based features (points, lines, and polygons).   The differences between WMS and WFS reflect the fundamental challenge of information display, which is the incompatibility between a vector-based map and a raster-based image. 

In 2003, OGC release a third Web GIS specification, called Web Coverage Service (WCS).  The Web Coverage Service (WCS) supports electronic interchange of geospatial data as "coverages" – that is, digital geospatial information representing space-varying phenomena.

A WCS provides access to potentially detailed and rich sets of geospatial information, in forms that are useful for client-side rendering, multi-valued coverages, and input into scientific models and other clients. The WCS may be compared to the OGC Web Map Service (WMS) and the Web Feature Service (WFS); like them it allows clients to choose portions of a server's information holdings based on spatial constraints and other criteria.

Unlike WMS (OGC document 01-068r3), which filters and portrays spatial data to return static maps (rendered as pictures by the server), the Web Coverage Service provides available data together with their detailed descriptions; allows complex queries against these data; and returns data with its original semantics (instead of pictures) which can be interpreted, extrapolated, etc. -- and not just portrayed.

Unlike WFS (OGC Document 02-058), which returns discrete geospatial features, the Web Coverage Service (WCS) returns representations of space-varying phenomena that relate a spatio-temporal domain to a (possibly multidimensional) range of properties.

The Web Coverage Service provides three operations: GetCapabilities, GetCoverage, and DescribeCoverage. The GetCapabilities operation returns an XML document de-scribing the service and brief descriptions of the data collections from which clients may request coverages. Clients would generally run the GetCapabilities operation and cache its result for use throughout a session, or reuse it for multiple sessions. If GetCapabilities cannot return descriptions of its available data, that information must be available from a separate source, such as an image catalog. The DescribeCoverage operation lets clients request a full description of one or more coverages served by a particular WCS server. The server responds with an XML docu-ment that fully describes the identified coverages. The GetCoverage operation of a Web Coverage Service is normally run after GetCapa-bilities and DescribeCoverage replies have shown what requests are allowed and what data are available. The GetCoverage operation returns a coverage (that is, values or prop-erties of a set of geographic locations), bundled in a well-known coverage format. Its syntax and semantics bear some resemblance to the WMS GetMap and WFS GetFeature requests, but several extensions support the retrieval of coverages rather than static maps or discrete features.

horizontal rule


Picture Case (raster images):  Open GIS Consortium, Inc. (OGC) (2002a). OpenGIS Web Map Server Interface Implementation Specification (Version 1.1.1). Open GIS Consortium, Inc., Wayland, Massachusetts, URL: (access date: 2-3-2003).

Data Case (vector features): Open GIS Consortium, Inc. (OGC) (2002b). OpenGIS Web Feature Server Interface Implementation Specification (Version 1.0.0). Open GIS Consortium, Inc., Wayland, Massachusetts, URL:  (access date: 2-3-2003).

Open GIS Consortium, Inc. (OGC) (2003). OpenGIS Geography Markup Language (GML) Implementation Specification (Version 3.0). Open GIS Consortium, Inc., Wayland, Massachusetts, URL:  (access date: 2-3-2003).



horizontal rule

Unit FOUR (Session Two):

horizontal rule

Google Earth Demo (3D and temporal changes). (Show Google Earth with Time Animation Functions )


Internet and GIS Applications:

( See Tsou's article 2004 in the Journal of Geographical Systems).

Tsou, M.H. (2004). Integrating Web-based GIS and On-line Remote Sensing Facilities for Environmental Monitoring and Management.  In special issue on the potential of web-based GIS, the Journal of Geographical Systems, No. 6: 1-20.


The three-level integration of web-based GIS


1. GIS Data or Remote Sensing Images Archive Centers:


Washington State Geospatial Data Arcive

Canada Center for Remote Sensing (CCRS)

EPA Mapping Links

The World Data Center System


2. GIS Data Clearinghouses: (metadata) 

The National Spatial Data Infrastructure

FGDC (Federal Geographic Data Committee)  Clearinghouse information resource page

USGS Geospatial Data Clearinghouse

NYS GIS Clearinghouse

Geospatial One Stop  (USGS):  (



3. Interactive Mapping Facilities:


    The National Map Viewer:

    The National Atlas:

    NASA  Earth Science Gateway:



4. Full function on-line GIS applications:

(not available right now except the GrassLinks prototype.  Do you know why?)

Web Service Chains:  A new direction...


The Implementation of Internet GIS applications:



The Data Archive Center and the Data Clearinghouses are the easiest tasks.  Current Internet protocols and Web technologies can easily be applied on these applications.



The interactive mapping facilities are more difficult to set up.  They usually will require additional Web server extensions and GIS packages for the implementation. 



The full function GIS operations are the most difficult task.


Security Issue?   Access control (limited IP address or user password.)




Sensitive Data or Images.  



NASA ARC Project Example:


horizontal rule

On-line Forum Discussion

Blackboard URL:


( See Tsou's article 2004 in the Journal of Geographical Systems).

Tsou, M.H. (2004). Integrating Web-based GIS and On-line Remote Sensing Facilities for Environmental Monitoring and Management.  In special issue on the potential of web-based GIS, the Journal of Geographical Systems, No. 6: 1-20.

horizontal rule

Back Home Up Next