GEO 583 Internet Mapping and Distributed GIServices

Unit  FOUR (Session One):

URL, URN, URI

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 (://map.sdsu.edu) 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, http://www.w3.org/Addressing/URL/url-spec.txt  )

Examples: 

ftp://ftp.is.co.za/rfc/rfc1808.txt

http://geoinfo.sdsu.edu:8080/automatic/   --> change the Border --> border

mailto:mduerst@ifi.unizh.ch

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. 

URI 

Uniform Resource Identifier. The generic set of all names/addresses that are short strings that refer to resources.

URL

Uniform Resource Locator. The set of URI schemes that have explicit instructions on how to access the resource on the internet.

URN

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,  http://www.w3.org/Addressing/)

The Function of URL

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"  ( http://www.google.com/ )

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

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

%22 = "

%2F = /

 

The Software Architecture of Internet Map Server

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)  http://terraserverusa.com/default.aspx

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).

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.

(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. http://www.sbg.ac.at/geo/eogeo/Authors/Frew/Frew.htm)

OGC Web Map Services (WMS)

Implementation Specifications (1.0 and 1.3)

OverView  (source: OGC http://www.opengis.org/, new: http://www.opengeospatial.org/  2005)

OGC specifications: http://www.opengeospatial.org/specs/?page=specs

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

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: 

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:

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?)

Four Types of Services

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

(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)

Note:  

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)

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)

WMS Examples:

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

http://terraserverusa.com/default.aspx

Examples: OGC WMS Viewer

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

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)

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

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

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.

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: http://www.opengis.org/techno/implementation.htm (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: http://www.opengis.org/techno/implementation.htm  (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: http://www.opengis.org/techno/implementation.htm  (access date: 2-3-2003).

Unit FOUR (Session Two):

Google Earth Demo (3D and temporal changes). (Show Google Earth with Time Animation Functions http://declanbutler.info/blog/?p=96 )

Internet and GIS Applications:

The three-level integration of web-based GIS

1. GIS Data or Remote Sensing Images Archive Centers:

SanDAG http://www.sandag.org/index.asp?subclassid=100&fuseaction=home.subclasshome  

Washington State Geospatial Data Arcive http://wagda.lib.washington.edu/data/

Canada Center for Remote Sensing (CCRS)  http://www.ccrs.nrcan.gc.ca/

EPA Mapping Links  http://www.epa.gov/region08/gis/

The World Data Center System  http://www.ngdc.noaa.gov/wdc/wdcmain.html

 

2. GIS Data Clearinghouses: (metadata) 

The National Spatial Data Infrastructure http://www.fgdc.gov/nsdi/nsdi.html

FGDC (Federal Geographic Data Committee)  Clearinghouse information resource page  http://www.fgdc.gov/clearinghouse/clearinghouse.htm

USGS Geospatial Data Clearinghouse http://nsdi.usgs.gov/

NYS GIS Clearinghouse http://www.nysgis.state.ny.us/

Geospatial One Stop  (USGS):  http://geodata.gov  (http://gos2.geodata.gov/wps/portal/gos)

 

 

3. Interactive Mapping Facilities:

   

    The National Map Viewer: http://nationalmap.gov/

    The National Atlas: http://www.nationalatlas.gov/index.html

    NASA  Earth Science Gateway: http://esg.gsfc.nasa.gov/web/guest/home

 

 

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:

NASA ARC Project Example:   http://map.sdsu.edu/arc

On-line Forum Discussion

Blackboard URL: https://blackboard.sdsu.edu/

 
MAP.SDSU.EDU