WO2001098925A2 - Method, system and computer program product for delivering spatially referenced information in a global computer network - Google Patents

Abstract

A scalable geospatial information management system and method for the assembly, packaging and online distribution of worldwide geospatial or geographic images and related information. The system includes a cluster computing architecture, capable of metering media and derivative product delivery streams. At the heart of this system is custom content processing, load balancing, caching, and delivery software. The dynamic rendering of geospatial images and related information permits a user to interact with the system to pan, zoom and navigate in real time or near term. The system includes a content management database for storing a worldwide collection of spatially indexed information and supporting metadata. The system also supports the real time generation of derivative products from the geospatial information.

Description

Method, System and Computer Program Product for Delivering Spatially Referenced Information in a Global

Computer Network

Background of the Invention

1. Field of the Invention

The present invention relates generally to geographic information systems. More particularly, the invention relates to the generation and delivery of geographic information over a global computer network.

2. RelatedArt

With the advent of the World Wide Web, global computer networks have quickly become cost-effective and reliable mediums for the exchange and management of information within an extensive array of computers and smaller computer networks. The computer networks vary in size and type such as, local internets, corporate intranets, local area networks (LAN), wide area networks (WAN), private enterprise networks, and the like. The Internet is the most commonly known global computer network.

The evolution of global computer networks and supporting technologies have made it possible for government officials, educational institutions, businesses, nonprofit organizations, and individuals to communicate with the local networks or personal computers of other persons or organizations. Many businesses, for instance, have been able to established web sites or home pages to promote, sell, and distribute their products (e.g., goods and services). Therefore, a web user browsing another's web site can request information, services, or order goods directly from the web site. Graphic images and photographs can be distributed over global networks, along with text and audio data. With respect to graphics, typically an image is formatted as a TIFF or GIF file for transport. Higher level formats, such as JPEG, can be used, but requires substantial memory and bandwidth. Hence, the delivery of high quality imagery over the Internet is hindered by the instability of global network environments due to latency, packet loss, and insufficient or unguaranteed bandwidth.

Consequently, a system and method are needed to solve the above-identified problems and provide a fast and affordable manner to instantaneously deliver high quality earth imagery over the Internet.

Summary of the Invention

The present invention is directed to a scalable geospatial information management system for the assembly, packaging and online distribution of worldwide geospatial or geographic images and related information. The system includes a cluster computing architecture, capable of metering media and derivative product delivery streams . At the heart of this system is custom content processing, load balancing, caching, and delivery software. The dynamic rendering of geospatial images and related information permits a user to interact with the system to pan, zoom and navigate in real time or near term.

The system includes a content management database that contains a worldwide collection of spatially indexed information and supporting metadata that can be used to service the user request. The content management database includes a directory or master metadata cross-referencing information stored within the content management database or located on other machines throughout the system. In one embodiment, the content management database uses the geocoordinates provided by a sessions controller to identify the requisite geospatial information and provide the path to the data to the sessions controller.

A feature of the present invention is the real time access of over twelve terabyte of geospatial information over a global computer network. Another feature of the present invention is the handling of heterogeneous image, vector and tabular content in different proj ections , from a wide variety of sources in such a manner that it can be used by several applications in a consistent manner. Another feature of the present invention is the ability to scale content access capacity to the dynamic demand patterns of millions of map views per day. Demand patterns can be quite dynamic since any piece of content can suddenly become extremely "hot" with a major news event, or strategic customer initiative. In such case, multiple clients may be accessing the same content at the same resolution simultaneously.

An advantage of the present invention is that a user can quickly and easily visualize any area of the world by simple hypertext transfer protocol (http) access.

Another advantage is the ability to use a desktop and browser to enter a street address and quickly obtain an image of the house at the address with its environment. Then, by panning and zooming, the area surrounding the house can be explored by moving a pointing device or with the click of a mouse. Additionally, any other media type (Real Audio/Video streams, paragraphs of text documents, etc) that are geographically cross-referenced using the Oracle 8i database to this area of interest may be selected and streamed to the user in a metered fashion.

Another advantage is the ability to juxtapose earth imagery with a scanned map on a common display. The imagery and map are linked to permit an image to navigate around the map, and obtain a corresponding view of the imagery, and vice versa. Brief Description of the Figures

The present invention is described with reference to the accompanying drawings. In the drawings, like reference numbers indicate identical or functionally similar elements. Additionally, the left-most digit of a reference number identifies the drawing in which the reference number first appears.

FIG. 1 illustrates a high level block diagram of the configuration of an embodiment of a geospatial information management system;

FIG. 2 illustrates a partitioned and indexed image tile according to an embodiment of the present invention; FIG.3 illustrates a block diagram of an example computer system us eful for implementing the present invention;

FIG. 4 illustrates a progressively partitioned image tile according to an embodiment of the present invention;

FIG. 5 illustrates a high level operational flow diagram for the steps involved in querying image tile cache 127;

FIG. 6 illustrates a graphical user interface for a client workstation 103 according to an embodiment of the present invention; and

FIG. 7 illustrates a high level operational flow diagram for the steps involved in processing a request for geospatial information according to an embodiment of the present invention;

FIG. 8a illustrates a pre-mosaiced image map according to an embodiment of the present invention;

FIG. 8b illustrates amosaicedimage map according to an embodiment of the present invention; and FIG. 9 illustrates a flow diagram for generating a derivative information product according to an embodiment of the present invention. Detailed Description of the Preferred Embodiments

I. Overview of Geospatial Information Management System

The present invention relates to a system, method and computer program product for the assembly, packaging and online distribution of worldwide geospatial or geographical information which includes geospatial images and related information. The geospatial images include high quality aerial photographs, satellite images, scanned maps, and the like. Related information include three dimensional terrain, building models depicting cities, as well as text paragraphs, audio/video streams or generic computer objects (e.g. , Java classes,

Shockwave files, etc.), and the like. Using the methods and systems of the present invention, the entire world can be captured at arbitrary resolution, with most urban areas represented in better than one meter resolution. The geospatial information can be used to dynamically create derivative information products, such as driving directions, normalized derived vegitation index (NDVI) maps, or other items useful to decision-support. Information sources from multiple projection systems can be combined dynamically to create desired output products.

FIG. 1 illustrates, according to one embodiment of the present invention, a block diagram of geospatial information management system 100 (referred to as "system 100"). FIG. 1 is a conceptual illustration of geospatial information management system 100 that allows an easy explanation of the present invention. That is, one or more of the blocks can be performed by the same piece of hardware or module of software. It should also be understood that embodiments of the present invention can be implemented in hardware, software, or a combination thereof. In such an embodiment, the various components and steps would be implemented in hardware and/or software to perform the functions of the present invention. As shown in FIG. 1, a preferred embodiment of geospatial information management system 100 includes a front end load balancer 118, one or more front end application servers 121, geocode databank 124, image tile cache 127, content load balancer 130, content management database 133, one or more primary back end content servers 136 and one or more auxiliary back end content servers 139. Front end load balancer 118 communicates with a plurality of computer workstations 103 over a diverse computer network 110, which includes wired or wireless local area networks (LAN) and/or wide area networks (WAN), such as an organization's intranet, the global-based Internet or the like. Front end load balancer 118 receives data packets (e.g., IP datagrams and the like) that contain user requests for geospatial information and/or derivative products that are sent from a plurality of computer workstations 103 and routes the data packets to a suitable front end application server 121. Likewis e, content load balancer 130 receives the data packets from front end application server 121 and routes the packets to a suitable primary back end content server 136 and, if appropriate, one or more auxiliary back end content servers 139. Front end load balancer 118 and content load balancer 130 are configured to perform real time or near term analyses to forecast the processing requirements for the respective requests and evaluate the availability of servers 121, 136 and 139 that process the requests and/or the availability or location of the best copy of the content to service the request. Thus, the data packets remain in a routing queue (not shown) within the respective load balancer 118 or 130 until, for example, a suitable server (121 or 136/139, respectively) can be identified. Each load balancer 118 or 130 determines s erver availability by, for example, evaluating the capacity and current workload of each server (121 or 136/139, respectively) and the resources required by the submittedjob. Other considerations include which servers having copies of the content are in service, and metrics such as, the background load of the servers, which server serviced the last request, number of CPUs, amount of free memory, swap space, and the like. In one embodiment, the data packets are routed to the first available server. In another embodiment, the data packets can be routed to designated servers based on other criteria, such as, the type of request (e.g., satellite images, aerial photographs, navigational data, audio streams and the like), geographic regions, and the like as would be apparent to one skilled in the relevant art(s). Therefore, front end load balancer 118 and content load balancer 130 optimize the use of computer resources by evenly distributing workloads to the appropriately available server(s) (121 and 136/139, respectively). As a result, front end load balancer 118 and content load balancer 130 prevent system 100 from becoming overloaded. Front end load balancer 118 and content load balancer 130 (or a combination of multiple front end load balancers 118 and content load balancers 130) support the aggregation of an unlimited number of servers (121 and 136/139, respectively). In one embodiment, each front end load balancer 118 and content load balancer 130 is specialized hardware, and can be, for example, a BIG/ip® Controller developed by F5 Networks Inc., IOS server load balancing products from Cisco Systems, or similar hardware, software, or a combination thereof, as would be apparent to one skilled in the relevant art(s). Front end load balancer 118 and content load balancer 130 are general enough to accommodate any CPU-intensive operations, particularly transcoding multimedia streams from high-quality archives, such as RealAudio and RealVideo servers, and the like.

In a preferred embodiment and as shown in FIG. 1 , content load balancer 130 is an application program or daemon located and operating on front end application servers 121. Content load balancer 1301ies dormantuntil oneormore specified conditions have been met. For example, content load balancer 130 can remain lurking until the number of requests for specific content exceeds a prescribed threshold value. As such time, content load balancer 130 would become active and allocate content to one or more servers (i.e., 136 or 139) as discussed. In an embodiment, the servers (121, 136 or 139) are queried to determine the location or availability of the best copy of the content needed to service the request. Alternatively, content load balancer 130 can be activated each time front end application server 121 receives a request of any content. In one embodiment, content load balancer 130 tracks or counts all content requests. This information is used to perform statistical analysis to forecast future demands and predict periods of high usage for specific content. Content load balancer 130 would activate itself during these forecasted periods of high demand.

For example, since content load balancer 130 receives all content requests, it can determine system-wide trends in resource utilization. This trend analysis is used to make adaptive decisions about anticipated res ource utilization. A content demand curve that is determined to exceed system-wide capabilities in the very near future will initiate replication of the content to other resources that can share the load. A content demand that is determined to be diminishing sufficiently can initiate distributed "garbage collection" and freeing of system-wide resources. Content demand thresholds are content and process specific, and user definable. Content demand functions can be "chained" to determine composite cost functions for replication and garbage collection.

As shown in FIG. 1 , geospatial information management system 100 also includes multiple servers: front end application servers 121, primary back end content servers 136 and auxiliary back end content servers 139. Each server (121, 136 and 139) processes the user requests to compose and deliver geospatial information as discussed below. Each server is one or more computers providing various shared resources to other network computers. The shared resources include files for programs, web pages, libraries and databases; output devices such as, printers, plotters, display monitors, facsimile machines, and audio/video recorders and players; and communications devices such as modems and Internet access facilities. The communications devices can support wired and wireless communications, including satellite, terrestrial (fiber optic, copper, coaxial and the like), radio, microwave and any other form or method of transmission.

In one embodiment, each server supports the standard Internet Protocol (IP) developed to govern communications over public and private Internet backbones. The protocol is defined in Internet Standard (STD) 5, Request for Comments (RFC) 791 (Internet Architecture Board). Each server can also support transport protocols, such as, Transmission Control Protocol (TCP), User Datagram Protocol (UDP) and Real Time Transport Protocol (RTP). The transport protocols supports various types of data transmission standards, such as File Transfer Protocol (FTP), Hypertext Transfer Protocol (HTTP), Simple

Network Management Protocol (SNMP), Network Time Protocol (NTP) and the like. Each server is also configured to support various operating systems, such as, Netware™ available from Novell®; MS-DOS®, Windows NT® and Windows® 3.xx/95/98/2000 available from Microsoft®; Linux® available from Linux Online Inc.; Solaris™ available from Sun Microsystems, Inc.; andthelike as would be apparent to one skilled in the relevant art(s).

In one embodiment, front end application servers 121 are configured to support the OpenGIS Web Mapping Testbed (WMT) 1.0 specification. This (Uniform Resource Locator) URL-based specification embeds query parameters into a name- values pair. An example is:

"http://www.globexplorer.com/servlet gexservlet?WM^rrNER=1.0&RE QUEST=map&SRS=EPSG%3A4326&BBOX=-97.105,24913,78.794, 36.358&WTDTH=560&HEIGHT=350&LAYERS=BUILTUPA_1M& FORMAT=PΝG."

This format atomically specifies the mapping extent, determines which layers to add, the size of the presentation, and the format of the result(s) returned to the user. Currently, WMT 1.0 is only capable of expressing a raster image result in screen coordinates. In addition to purely coordinate-basedbasemap queries, front end application servers 121 also support queries for an overview map (i.e., rendered against a different set of rules for content and symbology) and queries based upon addresses andfamous places (i.e., geolocate request). An example of a HTML overview map request is: "http://server.domain/gexservlets/gex?cmd=hovm&xul=-134.6426 3115451482&yul=41.56765004855089&xlr=-134.6424288454851 7&ylr=41.5674899514491 l&imagewidth=200&imageheight=l 50"

An example of a HTML geolocate request is:

"http://server.domain/gexservlets/gex?cmd=hgeo&address=600+m arket+st&city=san+fransisco&state=ca&iw=489&ih=365"

In another embodiment, front end application servers 121 are formatted to support more robust specifications such as the Global Geomatics Geographic Library Transfer Protocol (GLTP). GLTP is session oriented and therefore, carries context into each subsequent request. In one embodiment, third party geographic information systems (such as ESRI ArcEVIS™ developed by Environmental Systems Research Institute, Inc., and the like) can access the real vector content within system 100 by using, for example, native Global Geomatics application program interfaces (APIs). As shown in FIG. 1, front end application servers 121, in an exemplary embodiment, are two Sun Enterprise™ 420R servers, each equipped with four CPUs that manages geocode databank 124, image tile cache 127, content load balancer 130 and content management database 133. Located within front end application servers 121 is a sessions controller 145 that manages geospatial data processing and sessions with the user. Although client-server sessions are well- known to one skilled in the relevant art(s), the term sessions, as used herein, also includes both requests for geospatial information content as well as administrative and accounting activities with the users. For instance, sessions controller 145 manages the lookup functions by communicating with geocode databank 124, image tile cache 127 and content management database 133. As shown in FIG. 1, sessions controller 145 contains a content generator 148 that manages content production (e.g, assembly and packaging of geospatial images and derivative products) by communicating with content load balancer 130, primary back end content servers 136 and auxiliary back end content servers 139. Sessions controller 145 communicates with a security agent 142 that is also located within front end application server 121. Security agent 142 authorizes the user to receive geospatial information and implements the security protocol. Thus, security agent 142 protects user access, data, and communications . Access to any resource within front end application server 121 is controlled by using user authentication, firewalls, encryption, and like security techniques. In one embodiment, security agent 142 can require user authentication (e.g., usemame/password; fingerprint, retina or facial identification; and the like) to control access to the geospatial information assets and related system functionality. In this embodiment, the user authentication would determine database access, roles, security level, and functions. For instance, user roles can be used to manage access to data and features of system 100 for each user.

Thus, sessions control and management really begins when sessions controller 145 begins execution within, for example, aUNLX or NT environment with a known user with well known privilege behaviors . Once started, the session can be short as required to service an atomic operation (such as an individual URL get request) or a longer transaction that is facilitated by a dedicated socket connection. In one embodiment, a Secure Sockets Layer (SSL) provides for a secure datapath for all communications. In another embodiment, atop level web page can be used to provide open access to the general public, and secure web pages can be controlled through the Secure Hypertext Transfer Protocol (HTTPS). The top level web page, therefore, supports anonymous users. In this case, anonymous users accept the default privileges of sessions controller 145. To restrict duplication of content provided to anonymous users, the images can be restricted to, for example, Joint Photographic Experts Group (JPEG) format with an identifying logo burned into the pixels in such a manner that geographic referencing is lost after the image is created. Additionally, authorized users can be restricted from providing interfaces enabling the widespread production of useful derivative information that is delivered outside of a web browser.

In one embodiment, a subset of the functionality of back end content servers 136 and 139 can be available as a client plug-in, which would deliver useful information products directly to users in an authenticated session, but would not allow the users to save the received content in an unrestricted manner on local hard drives. Rather, high quality content that is routed from front end application servers 121 would be encrypted and only viewable with a runtime licensing token. Licensed token management can be achieved via the FLEXlm® infrastructure developed (by GLOBEtrotter Software, Inc.) and the like.

In one embodiment, primary back end content servers 136 and auxiliary back end content servers 139 are each three Sun Enterprise™ 420R servers, also equipped with four CPUs apiece. Three 2-CPU Sun Enterprise™ 220R web servers (not shown) deliver the geospatial information to the users over computer network 110. A Sun Enterprise Ultra™ 5S server (not shown) runs a Sun

Enterprise Solstice™ Domain Manager™ (not shown) forthis configuration, and two more Ultra™ 5S servers (not shown) manage the Solstice™¹ Tape Backup system (not show) that consists of DLT tape units for tape loading and backup. Each of the above Sun Enterpris e™ s ervers provides mainframe-class computing with the advanced network features of a Solaris™ 7 or higher operating system.

In this embodiment, the application programs used by geospatial information management system 100 can be developed in Java language and C++ on a combination of SPARC® and Intel™ based platforms.

As can be seen in FIG. 1, system 100 also includes geocode databank 124 which determines the coordinates for locating a geospatial image. Geocode databank 124 contains a list of addresses (including street address, city and states) and geocoordinates forthe addresses. Accordingly, geocode databank 124 reads the address or place name specified in the data packet supplied by the user and determines the geocoordinates for the request. As discussed below, the geocoordinates can be expressed in latitude/longitude format or like coordinate systems. In one embodiment, the geocoordinates for the requested image can be obtained by querying databases or search engines hosted by third parties, such as MapQuest.com, Inc. and the like.

Another component of system 100 is image tile cache 127 which is an intermediate repository for recently created image tiles of the geospatial images.

Image tile cache 127 makes recently rendered imagery available for subsequent requests which, in turn, significantly improves system response in cache hit situations but introduces no more than a half second in overhead. Image tile cache 127 can be located on a front end applications server 121 or in a separate data processing unit (not shown).

System 100 also includes content management database 133 which comprises a collection of integrated records used to support front end application servers 121, primary back end content servers 136, auxiliary back end content servers 139 and other components of system 100. The record content includes a worldwide collection of geospatial images and related information. In one embodiment, content management database 133 includes a relational or object oriented (OO) / component based database management system (not shown) that controls the storing, retrieving and updating of data andmeta-data in the records of content management database 133. The database management system also controls data integration, enforces integrity rules and constraints, and enforces security constraints. Referring again to FIG. 1, the database management system receives communications from front end application servers 121 (or other components of system 100) and manipulates content management database 133 to retrieve, store or update the records, as appropriate. The communications include instructions to copy, read and or write to the database records . An Open

DataBase Connectivity (ODBC) or JavaDataBase Connectivity (JDBC) protocol can be provided for direct connection to content management database 133.

In one embodiment, content management database 133 is a twelve terabyte Oracle™ 8.1.6 database stored on twelve Sun StorEdge™ A1000 disk arrays (not shown). Content management database 133 contains an metadata library catalog (not shown) for all geospatial images and related information stored in content management database 133 and other components of geospatial information management system 100 (e.g., within image tile cache 127). For example, content management database 133 can determine the machine (e.g., disk array(s), front end application server 121, primary back end content server

136, auxiliary back end content server 139, image tile cache 127, or other storage devices communicating with system 100) containing the most recent versions of the requested geospatial information. When it is queried, content management database 133 returns the path to the requested information (i.e., machine, disk and file) to front end application server 121 for processing.

The geospatial information includes the actual imagery as well as supporting metadata, including vector and tabular content. In one embodiment, the geospatial images are stored as wavelet-based compressed raster files in Mr. Sid™ format (developed by LizardTech) and the like. The raster geographic content is mosaiced or aggregated into layers, first, by virtue of bounding polygons of the raster content and, second, by thresholds in a scale factor (e.g., all images ranging from one foot to one meter resolution). Once aggregated into various layers, the content can be further qualified by whether it is color or black and white, and whether it is at the upper or lower end of a threshold factor for the layer.

FIG.8 a illustrates three images 801, 803 and 805 priorto being mosaiced, andFIG. 8b illustrates aresulting mosaiced image 807. As shown, image 801 can be, for example, a one foot color aerial photograph of an area of interest. Images 803 and 805 are higher quality three inch black-and-white images (e.g., photographs) of regions within image 801. To produce mosaiced image 807, the black-and-white images 803 and 805 are superimposed on top of image 801. Therefore, if a region shown in image 803 or image 805 is requested by a user, the higher quality images would be delivered. As such, polygons having the highest quality (e.g., images 803 and 805) are overlayed against the next highest quality factor (e.g. , image 801), such that whenever a query is made for content in overlapping areas, the higher quality can be selected. If the query is for a region outside of the highest quality areas, then lower quality segments of image 801 would be delivered. If the area of interest falls across a boundary, the layers are added sequentially from the lowest quality to the highest quality, with a transparent background. In other words , the area of interest would be an opaque image with one or more layers of images, but the ranging outside of the area of interest would become transparent. Therefore, to produce and store the mosaiced images, imagery of various degrees of resolution, type and quality are aggregated together. For example, three inch black-and-white, one foot color, two feet black-and-white, two feet color images, and the like can be added to the layer covering the scale range between one foot and one meter resolution to produce image 807. As such, the geospatial images within system 100 are more than pre- processed photographs stored on a server. The geospatial images are continuously updated and maintained to provide a multi-resolutional, seamless digital rendition of the earth.

Content management database 133 also mcludes an index and/or provides storage for other supporting media assets (i.e., text, sound, video, multimedia, opaque granular data such as VRML and generic Java objects and a combination thereof). The supporting metadata and media assets are retrieved from content management database 133, or other locations specified by content management database 133, and integrated with the imagery as discussed below. The media assets and geospatial images can be formatted to support Apple®, Microsoft®, or RealNetworks® multimedia applications; Netscape® and Microsoft® browsers capable of handling Java 1.1 or higher; Windows®, Novell® or Linux® operating systems; HyperText Markup Language (HTML),

Synchronized Multimedia Integration Language (SMIL), Allaire® Cold Fusion, Apple® Web Objects®, Haht Site®, PHP, Aestiva® scripting languages; or the like as would be apparent to one skilled in the relevant art(s). In one embodiment, the media assets can be formatted to support GIF for graphics, JPEG for photographs, Apple® QuickTime® for dynamic media (i.e., audio and video), Macromedia® Flash™ for simple animation, Macromedia® Shockwave® for more advanced animation, and Adobe® Acrobat® for manuals. All geospatial images and related information are classified according to established, preferably hierarchical, numbering conventions (such as, the computing classification system for computational elements developed by

Association for Computing Machinery, Inc. (ACM), Library of Congress machine-readable catalogingrecord standards (MARC), Federal Geographic Data Committee, and the like), where appropriate. As such, a unique "Object ID" would be issued for all data collections to be tracked internally. The geospatial images can also be organized by category. The categories include aerial photographs, satellite images, scanned maps, three dimensional terrain, building models depicting cities and the like. The geographic information, andparticularly outlines of media assets, are stored and spatially indexed in content management database 133. Beyond strictly two-dimensional information, any content that can be cross-indexed by location on the Earth is given spatial attributes . This includes inherently serialized media (such as, text, sound, and video), as well as opaque, granular data (such as VRML and generic Java objects.)

In the case of serial media, references to individual "sections" (denoted by start and stop points) of serialized media are assigned a feature type, unique identifier, and geographic extent, and ingested into the metadata library catalog as spatial objects. The sections can be overlapping. An example might be the diary entry made by Captain Cook when he first arrived in Tahiti, or video clips of different houses taken from a moving vehicle equipped with GPS. The metadata library catalog subsystem is integrated with a manufacturing, inventory, and traffic management accounting subsystems (not shown). Within this framework, the geospatial information can participate in a fully accountable just-in-time product creation andmanufacturingresourceplanning (MRP) cycles, involving multiple sub-assemblies and product suppliers, delivered over the appropriate transport mechanisms. Once a spatial data asset is within the inventory and manufacturing subsystems, it can participate in multiple product "food chains" simultaneously at next to zero incremental cost.

Derivative information products can be defined as a directed graph of specialized activities, using the syntax of software, such as Makfile and the like. Using such a mechanism, multiple load-balanced activities can be chained together and coordinated to create derivative information products. FIG. 9 illustrates a obj ect flow for generating a derivative information product according to one embodiment of the present invention. As shown in FIG. 9, an geospatial image and an accompanying street map can be generated and then re-projected and combined to produce a derivative product. To generate the geospatial image, first, the image (e.g., satellite image) is processed. For example, the processing algorithm can include multiplying band 2 by 0.2, dividing by band 5, and then performing a CYMK convert with band 3. Second, the image undergoes a filtering process (e.g., run Sobel 3x3 edge sharpening filter). Third, the image is alpha-blended (e.g., USGS topo map overlay at 0.1 weight). The aforementioned three steps represent only one exemplary method for preparing an image. As would be apparent to one skilled in the relevant art(s), other techniques can be used and is considered to be within the scope of the present invention. Each element in FIG. 9 utilizes load balanced resources and performs metering of the computed resources required to make the output.

II. Data Partitioning, Compression and Storage

FIG. 2 illustrates one embodiment of an image rectangle 200 that has been partitioned into four image tiles and indexed by image tile cache 127. As discussed above, image tile cache 127 contains recently rendered image tiles of geospatial images and makes the imagery available for subsequent requests. As shown in FIG. 2, image tile cache 127 embeds an index into newly created tiles within a hierarchical quadtree directory structure. The quadtree directory is recursively composed of subdirectories numbered 0 - 3 in counter-clockwise order, beginning from the lower-right. As would be apparent to one skilled in the relevant art(s), other indexing schemes can be used to identify each subdirectory. Using a hierarchical quadtree directory structure, any two dimensional space can be progressively partitioned into a quadtree in which an arbitrary rectangular area can be quickly subdivided and indexed into particular directories. Image tile cache 127 can offset any coordinates associated with a geospatial image to establish a common basis. To enhance system performance, all coordinates are first transformed from double-precision floating-point values to 32 bit unsigned integers. Given that the Earth is approximately 40,000,000 meters in circumference, or approximately 64 Meg (2**27), then an unsigned integer (2 ** 32), should be able to divide the world into 2**27 / 2**32 or 1/32 of a meter. In one embodiment, traditional latitude and longitude coordinates are offset by 90 degrees latitude and 180 degrees longitude, in order to begin at 0,0 and extend to 360.0 in the "x" direction and 180.0 in the "y" direction. When queried by sessions controller 145, image tile cache 127 can check to see which quad the query falls within, and whether the resultant rectangle of interest can be further subdivided.

FIG. 4 illustrates a hierarchy 400 of image tile quadtrees being recursively queried according to one embodiment of the present invention. As shown, image rectangle 410 is partitioned into a quadtree and its coordinates have been offset by 90 and 180 degrees as discussed above. The lowest level within image tile hierarchy 400 identifies the individual image tiles and determines the number of tiles located in the highest level. In other words, at the top level, and for any subdivided quad, image tile cache 127 would arbitrarily assign a gridding of 16x8 tiles with each tile being 64x64 pixels. Therefore, for the first level (comprising 360 degrees x 180 degrees of extent), each image tile would have 22.5 x 22.5 degrees of extent.

Image tile hierarchy 400 demonstrates the technique used by image tile cache 127 to locate index information pertaining to the area "lower-left = (91 ,68); upper-right = (110, 70)" would reside. First, the quadtrees of image 410 would be searched to select the subdirectory for image rectangle 415. Image rectangle 415 would likewise be searched to select the subdirectory for image rectangle 420. Image rectangle 420 would be searched to select image rectangle 425. Image rectangle 425 would be searched to select image rectangle 430. Finally, the quadtrees of image rectangle 430 would be searched to select the subdirectory for image rectangle 435 which contains the region "lower-left = (91,68); upper-right = (110, 70)." Within the scope of a single query, the overall process is single-threaded.

If a query rectangle should fall across a quadtree boundary, the query rectangle is split, and each piece is processedrecursively down different branches of the quadtree. The recursion would stop when the density of the underlying grid associated with a level is greater than the mapping scale of the original query, hi one embodiment, when a maximum query depth is reached, a UNIX.dbm file of pre-existing (Joint Photographic Experts Group) JPEG tiles associated with that quad is searched. The search result can include a list of up to 8x8 tile entries, which contain the location of the corresponding JPEG files within the back end content servers 136 and 139 "farm," the last time the image tile was accessed, and the .sid object identifier of the underlying .sid file. In one embodiment, an 8x8 grid size is the fundamental unit of the JPEG compression/decompression processing algorithms. The thread would compare the search result list with the requirements for fulfilling the query, and update a global list of rectangles (thread-specific data within the scope of the query) with both those found and needed to complete the subquery, along with the path to this particular area of the cache index. As recursive calls return, image cache 127 accumulates the child results until all subqueries have returned. The parent then examines the aggregate results and takes appropriate action, such as inserting new index entries for newly created JPEG tiles required to complete the query.

In one embodiment, the image tiles within image tile cache 127 would fall onto a regular grid, extending out from the quad's lower left corner. Image content initially transformed from Mr. Sid™ to JPEG format would be first uncompressed into a slightly larger (geographically) sized Red, Green, Blue (RGB) buffer in order to match the regular grid, and that the final JPEG returned is subsetted from the intermediate RGB buffer. Image tile cache 127 introduces no more than a half second overhead in cache miss situations because JPEG conversions to and from RGB images, as well as coordinate transformations of

RGB images, are relatively inexpensive when utilizing the Sun mediaLib™ toolkit routines. This has been seen to be the case, as wavelet decompression is seen to be approximately forty times more CPU expensive than JPEG compression/decompression. Referring to FIG.5, flowchart 500 represents the general operational flow of an embodiment of the present invention. More specifically, flowchart 500 shows an example of a control flow for querying image tile cache 127 for geographic image content.

Referring to FIG. 5, the control flow of flowchart 500 begins at step 501 and passes immediately to step 505. At step 505, image tile cache 127 receives a query request and offsets the query area so the queries are from (0,0) to (360, 180) in the x and y directions. At step 510, image tile cache 127 multiplies the coordinates by 2**32 / 360.0 to transform the coordinates to unsigned integers. At step 515, image tile cache 127 recursively call the image rectangles using the format (rect *query, rect *child_quad). At step 525, cached and missing rectangles are determined at the leaf nodes or the lowest level within the quadtree. A timestamp for the cached image tiles are also updated. At step 530, image tile cache 127 determines which rectangles need to be created after the completion of recursion. At step 535, image tile cache 127 creates the required JPEG tiles and archives the newly created tiles in content management database

133 by implementing a call add_cache_tile(char *index_directory, char* where jpeg_is). At this point, the control flow ends as indicated by step 595.

To avoid cache overflow, image tile cache 127 includes a garbage collection mechanism (not shown) that is periodically activated by a separately dedicated thread. To avoid the situation where a tile is garbage collected between the time a query thinks it can utilize a cached JPEG and the time it actually is to be used, the .dbm files of the leaf nodes contain readers-writer locks. Queries, therefore, must obtain readers' locks. Likewise, the garbage collection mechanism and cache inserts must obtain a writer's lock.

HI. Three Dimensional Navigation

Geospatial information management system 100 supports three dimensional navigation of its content by streaming surface imagery tiles that are geographically registered with corresponding bald earth terrain elevation and formatted for VRML and the like. Streaming can be achieved by a client-server proxying mechanism, whereby a server proxy would fetch data associated with the client's (computer workstation 103) current area of interest requested from the core content delivery image. Digital elevation .tin and VRML tiles would be pre-cut into patches and a quadtree directory structure that matches al28xl28 tile structure of the image cache, both in terms of resolution and unsigned integer format coordinates.

Using way points along a flight path that includes viewing position, orientation and frustrum, a new streaming geometry file type can be added to the Synchronized Multimedia Interpretive Language (SMIL) specifications to facilitate synchronized audio and video presentation with three dimensional fly-throughs for applications such as education and virtual travel. In one embodiment, the three dimensional fly-through navigation capability can be augmented with an octree-based proximity engine (not shown) that enables multiple users to interact with other users based on where the other users ' proxy agents are currently positioned. IV. Content Metering

Referring back to FIG. 1, each front end application server 121 includes a security agent 142 that maintains system security. Security agent 142 also supports content metering for geospatial information sent over computer network 110. As such, each us ers ' utilization of content data for runtime map production can be continuously logged and processed in batch-mode on a daily or weekly basis for billing and royalty purposes.

As discussed, security agent 142 maintains and controls system access control rights throughout each user session. Billing is performed by processing the access log files located within access agent 142 against stored procedural pricing models. Billing can be based on content type (i.e., satellite imagery, three dimensional streaming, and the like) and or customer agreement. The pricing models can reflect map creation traffic and advertising revenues generated against the underlying geospatial imagery. In one embodiment, users can be charged by the number of pageviews that system 100 generates and sends to the user. The terms of individual customer agreements can be stored in user profiles

, that are accessed and implemented by security agent 142.

Additionally, the pricing models can reflect subscription-based flat rates for authenticated access. The pricing models can include selective area-based pricing for high-value content. The pricing models can also reflect retail and derivative just-in-time product creation for compact disc (CD) or global network (e.g., Internet) distribution. It would be readily apparent to one skilled in the relevant art(s) that other pricing models can be included and is within the scope of the present invention.

V. Delivering Content to External Web Sites

As described, geospatial information management system 100 prepares and delivers, in real or near time, geospatial information or a derivative product over a widely distributed, integrated communications network (i.e., network 110). In an embodiment, a third party geographic information system (such as ESRI ArcJJVIS™ developed by Environmental Systems Research Institute, Inc., and the like) or third party network node (e.g., web site) communicates with geospatial information management system 100 to receive its content. The requisite content and processing resources are prepared, employed in a metered, load-balanced manner to produce the desired output product, and the product is delivered directly into the external information system or web site. Since the geospatial information or derivative product is typically formatted as a JPEG file, and therefore, no specially designed plug-in is required to receive and display the content at the external location. Nonetheless, system 100, in an embodiment, utilizes a native application program interface (API) developed by GlobeXplorer to deliver or display the content into other applications. Accordingly, third party hosts can integrate geospatial images, maps, or customizable databases from system 100 into their web sites and application programs.

For example, an e-business can download the content to support its ongoing business operations. A realty company, mortgage agency, and the like can download images of neighborhoods onto its web site to solicit potential home- buyers or enable commercial buyers to evaluate properties . Supportive web links can include neighborhood school and crime statistics, insurance risks, mortgage financing and refinancing agents, and the like. Travel agencies can integrate images from the archives of system 100 into their web sites to promote vacation packages, provide pictorial images of outdoor travel destinations, and the like. The content from system 100 can be used to show real-time weather conditions, river flows, ski slopes, and the like for outdoor recreation-based e-businesses.

The web sites for news services can use the content to display geospatial images to complement news stories and current events.

Web-enabled classrooms can use the imagery content to support a variety of educational purposes, such as courses on geography, monitoring environmental conditions regarding deforestation and river flows, and the like. In fact, nonprofit organization or government entities can use the content to monitor the overall health of the planet. Government institutions can integrate the content into their web sites to support tax assessment, zoning, disaster preparedness, and like city planning, utilities and regulations. Companies can rely on the present invention as a single-source location for accessing and utilizing earth imagery for the purpose of assessing property damage in the aftermath of a natural disaster, reviewing topographic information to assess flood risks and formulating rates, and the like.

As discussed, content load balancer 130 is configurable to meter, track or count all content requested and delivered to the system users. As the content is transmitted to the external location, content load balancer 130 maintains a log to record the number of times a particular user requests or receives a particular item of content. This tracking information can be used to calculate royalty payments for a licensor of the requested data. A subscription to the geospatial information available on system 100 includes installing an API that is customizable to permit subscribers to integrate earth images, maps and/or specific business databases into their Web sites as part of an e-commerce solution. Each subscriber is provided a unique, encrypted identifier, which is used to authenticate requests for content and other services. A request for a specific image is processed via the API, which locates imagery after the user has typed in a location such as a country, city, address, or postal code, or has made a selection from a "Popular Places" drop-down menu. Once again, images are stored in the system 100 in a compressed state. The requested image is decompressed, projected and re-sampled to create a compressedJPEGimage in sub-second time. Projection involves custom creation of the requested image from multiple images, as described above. As w know to one skilled in the relevant art(s), re-sampling refers to a process that ensures the fidelity (or clarity) of the image is maintained.

In an embodiment, a custom-created JPEG image is sent to the subscriber's Web site for viewing. After the image is sent to the subscriber, the method and system of the present invention tracks each transaction daily, records which subscriber receives the image and credits the original owner of the content (e.g., map, image, information) so that royalties can be paid. In an embodiment, if multiple images from different owners are used to generate a derivative product, royalties calculations are determined by the percentage of the derivative product that is attributable to the owner of the images used.

VI. Client Graphical User Interface

As discussed above, geospatial information management system 100 communicates with one or more client workstations 103 over computer network 110. Each user's computer workstation 103 can be apersonal computer, personal digital assistant (PDA), telephone, television or like devices linked to computer network 110 and including a display device with the ability to receive geospatial imagery. The display device for the client apparatus provides a text or graphical user interface (GUI) and enables a user to interactively communicate with front end application s ervers 121 and front end load balancer 118. FIG. 6 illustrates an embodiment of client GUI 600.

GUI 600 can include one or more windows. In one embodiment, GUI 600 includes imagery window 610, supportingmediawindow614, and query window 612. In one embodiment, front end application server 121 prepares and send a Java application to display geospatial media streams on GUI 600. The media streams contain the geospatial images and supporting information prepared by front end application server 121. Imagery window 610 displays and permits user interaction with the geospatial images. The images can include aerial photographs, satellite images, scanned maps, three dimensional terrain, building models depicting cities and like image content produced in geospatial information management system 100, as would be apparent to one skilled in the relevant art(s). Supporting media window 614 displays the supporting information sent in the geospatial media streams and permits the user to interact with the supporting information. The supporting information can include street maps, routing or driving directions, video or audio clips and like information. Supporting media window 614 can als o display accounting information, such as the amount of time the user has spent accessing server 121 , number of pages that has been downloaded in a given session, amount due for a session, and the like. As would be apparent to one skilled in the relevant art(s), supporting media window 614 can be used to display any type of information that can be used to provide additional data about the image supplied in imagery window 610. The information can be any form of media or multimedia (including text, sound, video, graphics, or any combination thereof). Accordingly, imagery window 610 and supporting media window 614 can be used to support live and on-demand content streams or downloads. Moreover, computer workstations 103 can be configured to support Network 24, RealNetworks®, Microsoft® and Apple® applications, or other applications for downloading and/or streaming media as would be apparent to a person skilled in the relevant art(s).

GUI 600 also includes query window 612 that enables the user to submit a request for an geospatial image. As shown in FIG. 6, the user can request the image by address or place. By place, the user can enter a famous location, such as the Grand Canyon, Taj Mahal, Mount Everest and the like; famous city, such as Moscow, Tokyo, Jakarta, Caracas, and the like; or similar geographic areas as would be apparent to one skilled in the relevant art(s).

Referring again to FIG. 6, GUI 600 also includes one or more navigational keys, namely zoom buttons 616A and 616B, pan button 618 and world button 620. Using input device, such as pointing device (i.e., amouse and the like), a user can activate zoom buttons 616A and 616B to get a closer or more distant view of a designated region in imagery window 610. Pan button 618 enables the user to receive imagery data beyond the boundaries of imagery window 610. World button 620 sends a request for a map extent for the entire world.

For example, as shown in FIG. 6, supporting media window 614 can contain a map of a region that is being displayed in imagery window 610. If the user wanted to move the map or image to view areas beyond the boundaries, the user can use a pointing device to activate pan button 618. As an alternative, the user can use the pointing device to click and drag either the map or image in the desired direction. For example, by depressing and holding the right click button while moving the cursor, the user can cause the contents of imagery window 610 or supporting media 614 to move in the direction of the cursor.

The contents of imagery window 610 and supporting media window 614 are linked, for example, by geocoordinates, such that altering the data in one window would generate corresponding data in the other window. In otherwords, the geocoordinates used to identify and send the imagery and supporting data to GUI 600 are stored in system 100 (e.g., geocode data bank 124), as discussed above. When the user requests different content for either imagery window 610 or supporting media window 614, the respective geocoordinates for the imagery and supporting data are requested and delivered from front end application server 121. To the user, both imagery window 610 and supporting media window 614 would change synchronously with each other. An API on computer workstation 103 converts the signals generated by the pointing device into requests to front end application server 121 for the relevant content.

As discussed above, the present invention can be used in combination with additional information, such as directions . For example, a us er may request directions from point A to point B . These directions can be displayed along with a map of the general area and an image of the general area. A user may further request the display of an image of an area of interest from the directions. For example, assume the directions call for a right hand turn to be made at the intersection of Main St. and Broad St. A user can request an image of this intersection (e.g., by selecting a portion of the directions via a pointing device). This feature of the present invention would provide a user with information regarding landmarks that will aid in navigation. In an embodiment, the images can be supplemented with text to identify specific landmarks (e.g., 7-11, Texaco, etc.) The image displayed can be a two or three dimensional image depending on available data. Obviously, multiple images along the path from point A to

Point B can be displayed.

In an embodiment, an image is overlaid on a map of an area of interest. As discussed, this derivative product is generated and routed from front end application server 121, and is displayed (comparable to GUI 600) on a client device. By combining an image and map, the method and system of the present invention enables one to, for example, label a map to indicate points of interest, highlight routes to give directions, or provide similar descriptive content. Various types of content and media can be combined and delivered from front end application server 121, such as overlaying driving directions on aerial photographs, photographs of landmarks over amap, historical references over an aerial photographs, and the like.

As discussed, a user can interact with GUI 600 by manipulating an input device to generate and submit requests to front end application servers 121. In one embodiment of the present invention, the user can use a keyboard and/or mouse to interact with geospatial information management system 100 to manipulating the graphical controls of GUI 600. In another embodiment, computer workstations 103 are configurable to receive verbal commands to execute various tasks during the sessions. Using a rule-based expert system, a processing unit enables a voice recognition unit to identify the voice of the user and to recognize and process verbal commands to activate the graphical controls.

Other input devices can be a mouse wheel, joystick, rudder pedals, touch screen, microphone, joystick, stylus, light pen, or any other type of peripheral unit. The aforementioned is a representative list of input devices that can be used with the present invention, it should be understood that any other type of input device, as would be apparent to one skilled in the relevant art(s), could be easily included and would not change the scope of the invention. Any presently available or future developed device that is responsive to a general purpose interface is encompassed by the present invention.

An application program interface (API) interfaces between GUI 600 and the input device to support real time visual feedback and communications with the other components of geospatial information management system 100. Accordingly, in response users activating a graphical control on GUI 600, the computer workstations 103 transmit signals to front end application servers 121 corresponding to the activated graphical control.

VII. Exemplary Geospatial Information Session

Referring to FIG 7, flowchart 700 represents the general operational flow of an embodiment of the present invention. More specifically, flowchart 700 shows an example of a control flow for processing a request for geospatial information. Referring to FIG. 7, the control flow of flowchart 700 begins at step 701 and passes immediately to step 715. At step 715, a user logs onto computer workstation 103 and activates the graphic controls to send a request for geospatial information from geospatial information management system 100. The users of system 100 can include portal websites industries related to media, entertainment, travel, tourism, real estate, outdoor recreation, local government, insurance, transportation, news media, education, and the like. System 100 can be used to facilitate management of land based assets in these industries. System 100 can also be used by individual users browsing the world wide web or by, for example, a traveler seeking directions to a location or a potential home buyer scouting a neighborhood of a property of interest.

Front end load balancer 118 receives and pre-processes the user request to forecast the processing requirements . Afterwards , front end load balancer 118 routes the user request to an available front end application server 121. At step 720, sessions controller 145, located within front end application server 121, queries security agent 142 to authorize the user and authenticate the session. Several active or passive authorization techniques can be used to determine the user's identity such as processing a username/password, reading cookies or IP addresses, and the like. Once the user has been identified, security 142 would determine the user role. For instance, the user can be approved to receive full or limited access to the system components. In one embodiment, security agent 142 can grant access to an anonymous user for limited data, as discussed above. After the user has been authorized to access the contents of system 100, security agent 142 would notify sessions controller 145 to authenticate the session. Otheiwise, if the user is denied authorization, control passes to step 790. At step 790, sessions controller notifies the user that access has been denied and the control flow ends at step 795.

If, however, the session is authenticated, at step 725, sessions controller 145 would read the data packet containing the user request to determine if it includes the geocoordinates. If the geocoordinates are not present, but the request specifies an address or place name, sessions controller 145 would query geocode databank 124 for the geocoordinates. If geocode databank 124 cannot locate or determine the geocoordinates, control passes to step 790 where sessions controller 145 notifies user that no data is available, and once again, the control flow ends at step 795.

If geocode databank can determine the geocoordinates, or if the geocoordinates are present in the user request, control passes to 730 where sessions controller 145 queries image tile cache 127 for the path to the geospatial information. As discussed in reference to control flow 500 in FIG. 5, image tile cache 127 makes recently rendered imagery available for user requests to improve system response time. As discussed, if the image(s) or path information for the image(s) are present in image tile cache 127, this data would be sent to content generator 148 for processing, at step 740. However, if the image(s) or path information are not present, at step 735, sessions controller 145 queries content management database 133 for the path to the "master copy" of the relevant content. To locate the content, the database management system searches the storage banks of content management database 133 or within the "farm" of primary and auxiliary back end content servers 136 and 139. In one embodiment, content management database 133 uses its master metadata catalog to determine the location. Upon finding the data, content management database 133 provides sessions controller 145 with the content path that includes the machine, disk, and specific file. In one embodiment, content management database 133 implements a two-step process to select the content.

Based upon the geocoordinates, a lookup is performed to determine the scale factor of the request and category of content to query. The categories can include graphicimages from global A VHRR imagery down through three-inch resolution aerial imagery. If images (and/or path) can be located, content management server 133 sends the path information to content generator 148. If the requested images are not present in content management database 133 or elsewhere within system 100, at step 790, sessions controller 145 notifies user that the data is not available to end the control flow at 795.

At step 740, content generator 148 receives the path information and notifies content load balancer 130. Thereafter, content load balancer 130 determines the best machine(s) to process the user request. Content loadbalancer 130 uses both real time performance statistics and near-term trend analysis to determine hot spots. Since user demand for the geospatial information is dynamic, at any given time, any piece of content can suddenly become extremely hot due to, for example, major news event, holiday seasons, natural disasters and the like. Content load balancer 130 can forecast the periods of high demand, or in real time, detect periods of high demand and reallocate the available resources within system 100 to generate the hot content.

In one embodiment, content load balancer 130reviews alisting of servers (136 and 139) available in the load balance pool to determine the amount of disk space each server (136 and 139) has for local replicate files. Content load balancer 130 also determines a thresholding profile for the processing request that is being load balanced. When the access patterns for a particular processing request or job passes the threshold, content load balancer 130 searches for copies of the file (based on the location supplied by sessions controller 145). If copies are found, content load balancer 130 determines how busy the machines (servers 136 and 139) hosting the copies are, and if any are suitable for processing more requests. Suitability means that the full content path is intact, and the machine is not reaching its processing threshold for either the specific piece of content or the machine's aggregate processing load. If no suitable hosts are found, the least loaded is sought, and a replication of the content is initiated to another candidate machine in the pool. Replication candidates are machines that do not already have a copy of the file, and are not at their aggregate processing capacity threshold. Content load balancer 130 contains monitoring agents (not shown) to mark any unusable path elements. For example, if aparticular disk began to fail, all access requests to that disk can be diverted to alternate content copies until the problem is resolved.

Depending on processing requirements, availability, and other suitability criteria, content load balancer 130 can assign a primary back end content server 136 to process the entire job or it can assign a primary back end content server

136 and one or more auxiliary back end content s ervers 139. Auxiliary back end content servers 139 can be selected for a number of reasons. For instance, the content can be hot and the processing must be balanced over several servers. Another reason can be that a fault has been detected along the path to the master copy located on the primary back end server 136. Auxiliary back end content servers 139 can also be selected when mosaicing content from different sources, such as at the edges of metropolitan areas where very high resolution data runs out and surrounding areas must be filled in with lower resolution content. If content load balancer 130 dispatches the request to one or more auxiliary back end content servers 139, the primary back end content server 136 would be responsible for aggregating the results.

Referring again to FIG. 7, at step 745, the assigned primary back end content server 136 and, if necessary, auxiliary back end content server(s) 139 processes the job. The results are aggregated, re-projected to a common projection, and mosaiced together. The results are not only sent to content generator 148 that made the request, it is also partitioned into image tiles and stored into image tile cache 127 for subsequent requests. In one embodiment, primary and auxiliary back end content servers 136 and 139 transcode the wavelet images into 24 bit JPEG images for delivery to the user.

At step 750, content generator 148 receives the results and retrieves any required vector overlays from the necessary data sources, primarily content management database 133. The vector overlays are drawn on a mosaiced raster backdrop. In one embodiment, content management database 133 can query other third party vector sources for the required overlays. For example, content management server 133 can query the mapviewer libraries of Global Geomatics Inc. to overlay symbology on top of the raster content. Other data sources for overlaid vector content can include ESRI™ SHAPE files, Oracle 8i™ tables, and AutoCAD® Drawing Interchange File (DXF) files, remote GLTP servers and the like. In another embodiment, a Windows® client-based authoring tool can interactively generate the metafiles. This file format can be translated into extensive markup language (XML) and the like tags, and extended with information concerning authorized access groups, aggregate raster layers, natively streamed wavelet-based files in Mr. Sid™ format "sidlets," three dimensional Virtual Reality Modeling Language (VRML) and the like.

After content generator 148 has compressed the resulting raster image, content generator 148 returns the image to sessions controller 145. At step 755, sessions controller 145 wraps the resulting raster image with additional presentation information to format the data for the user's computer workstations 103. As discussed, the data can be formatted to support Apple®, Microsoft®, and RealNetworks® multimedia applications, HTML, SMIL, Allaire® Cold Fusion, Apple® Web Objects® and the like).

In one embodiment, sessions controller 145 prepares a Java applet to communicate with computer workstations 103 via a simple HTTP URL. The URLs typically return text responses . The resultant image is embedded in the text response as a separate URL. The remaining text is metadata about the image. Computer workstation 103 would receive the text response and then open an additional connection to a front end application server 121 to request the image. In another embodiment, the URLs can migrate to where their responses are multi-part responses. The text metadata about the image is still returned as text, but the binary image itself is also returned in-line as part of the single response. A single multi-part response improves system efficiency because only one connection is required with the front end application server 121 rather than two.

However, some web browsers for computer workstation 103 cannot not handle multi-part responses without a helper application. In such cases, sessions controller 145 can use a Java API to wrap the requests and handle the processing of the multi-part responses. For example, an typical map request can be submitted as follows:

"http : I Is erver . domain/gexs ervlets/gex?cmd=map&xul=- 122.43229099 333843&yul=37.76780456926209&xlr=-122.4286265278958&ylr=37

.76490469722993&iw=489&ih=365"

In this example, the geocoordinates are specified in floating point decimal degrees. The longitude values are negative west of the Greenwich meridian and positive to the east. The latitude values are positive north of the equator and negative to the south. The parameter "xul" is the x coordinate of the upper left corner of a image rectangle. The parameter "yul" is the y coordinate of the upper left corner of the image rectangle. The parameter "xlr" is the x coordinate of the lower right corner of the image rectangle. The parameter "ylr" is the y coordinate of the lower right corner of the image rectangle. The parameter "Iw" is the width of the resultant image in pixels, and "Ih" is the width of the resultant image in pixels.

The request would return a multi-part text response in the following format:

"url=http://proto. globexplorer.com: 80/jpegs/pilots/8106/rendermapl.jp g,xul=-122.4124,yul=37.7892,xlr=122.409,ylr=37.7864,ctd_l=SanFra ncis coCityInfo , ctl_l=http: //proto . gl obexplorer . com/ demo_multimedia.htm"

The parameter "url" is the URL of the resultant image. The parameters "xul" and

"yul" are the coordinates of the upper left point of the rectangle of the resultant image in decimal degrees. These can vary slightly from the coordinates of the request. The parameters "xlr" and "ylr" are the coordinates of the lower right point of the rectangle of the resultant image in decimal degrees. These can also vary slightly from the coordinates of the request. The parameter "ctd_x" is the description for the information item at index x. Likewise, the parameter "ctl_x" is the URL for the information item at index x. The output from this request would quickly migrate to a multi-part response where the URL for the image is replaced by the in-line binary image data. An example of an overview map request can be submitted as:

"http://server.domain/gexservlets/gex?cmd=ovm&xul=-134.64263115 451482&vul=41.56765004855089&xlr=- 134.64242884548517&ylr=4 1.56748995144911 &imagewidth=200&imageheight=150"

The parameters in this request have the same definitions as indicated for the exemplary map request, above. Generally, the return from the overview map request is same as for a map request. However, shortly the overview map request would return imagery (i.e., aerial or satellite photographs) above a prescribed scale and a vector map below a prescribed scale value. The vector map can also be returned as an image, but it would be an image of a vector map and not photography. Like the map request, the overview map request would also migrate to a multi-part response request with in-line binary imagery.

A third example of a request is a geolocate request that can be submitted as follows:

"http://server.domain/gexservlets/gex?cmd=geo&address=600+market +st&city=san+fransisco&state=ca&iw=489&ih=365"

The parameter "address" is the street address of the area of interest. "City" represents the city of the area of interest. "State" is the state of the area of interest. "Zip" is the zip code of the area of interest. "County" is the county of the area of interest."Country" is the country of the area of interest. Finally, the parameters "iw" and "i " carry the same definition as in the map request. The return from the geolocate request is also the same as for the map request. Also, the geolocate request would migrate to a multi-part response like the map request. However, if the result of the geolocate request is ambiguous (i.e. more than one match), the first matching area of interest would be returned.

Multi-part responses can be handled by programs (such as Java applets or ActiveX controls) that can sort through the multi-part response and pick it apart. However, multi-part responses are not easily processed on simple (or dynamically generated) web browsers or HTML pages, and the like. To support these types of clients, sessions controller 145 can provide an additional set of URLs that return their responses as a single mime type. For example, an typical HTML map request can read: "http://server.domain/gexservlets/gex?cmd@hmap&xul=-122.4322909 9333843&yul=37.76780456926209&xlr=-122.4286265278958&ylr= 37.76490469722993&iw=489&ih=365"

The parameters have the same definitions as discussed above. Unlike the previous map request example, in this case, the "hmap" request returns only the image with a mime-type of image/JPEG.

An example of a HTML overview map request can be:

http://server. domain gexservlets/gex?cmd=hovm&xul=-l 34.64263115 451482&yul=41.56765004855089&xlr=-134.64242884548517&ylr= 41.5674899514491 l&imagewidth=200&imageheight=150

Once again, the parameters have the same definition as previously discussed. The "hovm" request, however, returns only the image with a mime-type of image/JPEG.

Similarly, a exemplary HTML geolocate request can read as:

http://server.domain/gexservlets/gex?cmd=hgeo&address=600+market

+st&city=san+fransisco&state=ca&iw=489&ih=365

The parameters are handled as previously discussed. However, the "hgeo" request returns only the image with a mime-type of image/JPEG.

Although the HTTP URLs are generally submitted to front end application servers 121 as plain text, in an alternate embodiment, the requests can migrate to the format:

"http://serτer.domain/gexservlets/gex?Crypt=q984ty9parf8vsg" The query part of the URL contains one "name=value" pair that is the encrypted request to the front end application server 121. A Java API can handle the encryption of the URLs without programmer intervention. Other tools can be provided to allow the HTML page author to encrypt the URLs. Referring again to FIG.7, after sessions controller 145 has formatted the content data and returned the composite resultto the user's computer workstation 103, the control flow ends as indicated by step 795.

VIII. Software and Hardware Embodiments

The present invention (e.g., system 100, content load balancer 118, front end application servers 121, primary back end content servers 136, auxiliary back end content servers 139, image tile cache 127, content load balancer 130, geocode databank 124, content management database 133, or any part thereof) can be implemented using hardware, software or a combination thereof and can be implemented in one or more computer systems or other processing systems. In fact, in one embodiment, the invention is directed toward one or more computer systems capable of carrying out the functionality described herein.

Referring to FIG. 3, an example computer system 300 useful in implementing the present invention is shown. The computer system 300 includes one or more processors, such as processor 304. The processor 304 is connected to a communication infrastructure 306 (e.g., a communications bus, crossover bar, or network). Various software embodiments are described in terms of this exemplary computer system. After reading this description, it will become apparent to a person skilled in the relevant art(s) how to implement the invention using other computer systems and/or computer architectures. Computer system 300 can include a display interface 302 that forwards graphics, text, and other data from the communication infrastructure 306 (or from a frame buffer not shown) for display on the display unit 330. Computer system 300 also includes a main memory 308, preferably random access memory (RAM), and can also include a secondary memory 310. The secondary memory 310 can include, for example, a hard disk drive 312 and/or a removable storage drive 314, representing a floppy disk drive, a magnetic tape drive, an optical disk drive, etc. The removable storage drive 314 reads from and/or writes to a removable storage unit 318 in a well-known manner. Removable storage unit 318, represents a floppy disk, magnetic tape, optical disk, etc. which is read by and written to removable storage drive 314. As will be appreciated, the removable storage unit 318 includes a computer usable storage medium having stored therein computer software and/or data.

In alternative embodiments, secondary memory 310 can include other similar means for allowing computer programs or other instructions to be loaded into computer system 300. Such means can include, for example, a removable storage unit 322 and an interface 320. Examples of such can include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM, or PROM) and associated socket, and other removable storage units 322 and interfaces 320 which allow software and data to be transferred from the removable storage unit 322 to computer system 300. Computer system 300 can also include a communications interface 324.

Communications interface 324 allows software and data to be transferred between computer system 300 and external devices. Examples of communications interface 324 can include a modem, a network interface (such as an Ethernet card), a communications port, a PCMCIA slot and card, etc. Software and data transferred via communications interface 324 are in the form of signals 328 which can be electronic, electromagnetic, optical or other signals capable of being received by communications interface 324. These signals 328 are provided to communications interface 324 via a communications path (i.e., channel) 326. This channel 326 carries signals 328 and can be implemented using wire or cable, fiber optics, a phone line, a cellular phone link, an RF link and other communications channels.

In this document, the terms "computer program medium" and "computer usable medium" are used to generally refer to media such as removable storage drive 314, a hard disk installed in hard disk drive 312, and signals 328. These computer program products are means for providing software to computer system

300. The invention is directed to such computer program products.

Computer programs (also called computer control logic) are stored in main memory 308 and/or secondary memory 310. Computer programs can also be received via communications interface 324. Such computer programs, when executed, enable the computer system 300 to perform the features of the present invention as discussed herein. In particular, the computer programs, when executed, enable the processor 304 to perform the features of the present invention. Accordingly, such computer programs represent controllers of the computer system 300.

In an embodiment where the invention is implemented using software, the software can be stored in a computer program product and loaded into computer system 300 using removable storage drive 314, hard drive 312 or communications interface 324. The control logic (software), when executed by the processor 304, causes the processor 304 to perform the functions of the invention as described herein.

In another embodiment, the invention is implemented primarily in hardware using, for example, hardware components such as application specific integrated circuits (ASICs). Implementation of the hardware state machine so as to perform the functions described herein will be apparent to persons skilled in the relevant art(s).

In yet another embodiment, the invention is implemented using a combination of both hardware and software. IX. Conclusion

While various embodiments of the present invention have been described above, it should be understood that they have been pres ented by way of example, and not limitation. It will be apparent to persons skilled in the relevant art(s) that various changes in form and detail can be made therein without departing from the spirit and scope of the invention. Thus, the present invention should not be limited by any of the above described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

Claims

What Is Claimed Is:

1. A method for interactively displaying geographic information, comprising the steps of:

(a) entering an address of an location to be displayed; (b) accessingadatabase,whereinsaiddatabaseincludesmaps and images of a plurality of locations;

(c) displaying a map of said location and an image of said location; and

(d) allowing auser to manipulate said image of said location.

2. The method for rendering geospatial information in response to ahighlevel of requests fromaplurality of simultaneous users, said users sending requests from a data processing unit communicating with a geospatial data server, comprising: pre-processing a request for geospatial information to evaluate a level of demand and requisite processing requirements; sending said request to a geospatial processing unit; selecting one or more servers capable of implementing said requisite processing requirements; selecting one or more geospatial images that corresponds to geocodes associated with said request; selecting one or more supporting data that corresponds to said geocodes; transcoding said geospatial images and supporting data to support formatting requirements of the data processing unit; and sending said transcoded information to the user generating said request.

3. The method of claim 2, wherein said step of selecting geospatial images further comprises the step of searching an image tile cache to select said geospatial images.

4. The method of claim 3, further comprising the steps of: evaluating said level of demand and requisite processing requirements for said geospatial images in response to not finding all of said images in said image tile cache; and searching a geospatial database to select said geospatial images.

5. The method for delivering imagery to a plurality of clients over an network, comprising the steps of: preparing imagery data in response to a request for said imagery data; creating a metered record of said request, wherein the record includes an identifier for the requestor and for said imagery data; and delivering said imagery data to the requestor.

6. The method of claim 5, wherein said step of preparing imagery data includes the step of decompressing, projecting and resampling an archived compressed image to produce the imagery data.

7. The method of claim 5, wherein said step of creating a metered record includes the step of logging the number of times the requestor requests or receives said imagery data.

8. The method of claim 5, further comprising the step of: using a pricing model to determine payments owed to a licensee or owner of said imagery data.

9. The method of claim 8, wherein said step of using apricing model comprises the step of determining at least one of: map creation traffic or advertisingrevenues generated against said imagery data; a number of pageviews generated or sent to the requestor; subscription-based flat rates for authenticated access by the requestor; and selective area-based pricing for high-value content.