I've just come across a very recently published U.S. Patent application by Google that appears to explain the inner workings of Google Earth.
More specifically, the technology described in this Patent app deals with how mapping-related information within a database makes its way into a Google Earth display you request.
The Patent app is
Technology here is a bit complicated, but will be more easily understandable if you follow along with me. I'll be showing you two Figures from the Application, and supporting those with accompanying text from the relevant sections of this App.
FIG. 1 is a schematic diagram of a system 100 for providing users with objects in a geographic information system.
In general, the system 100 uses a geography server 114 to generate views of a geographic area on an application running on terminal 110--such as a web browser (with or without a plug-in directed to the geographic display) or other application (such as Google Earth).
The system 100 may also in cooperation use an object server 116 to deliver information concerning objects associated with the geography. Such objects may include 3D models of building, bridges, or other structures, and may also include geographic data such as earthquake data, weather data, or the like.
The coordinated use of the servers 114, 116 may allow objects to be layered over the top of geography so that users may more readily review such objects in a natural manner, and may also interact with the objects in helpful manners.
The various components of the system 100 may communicate through network 112, which may include one or more local area networks (LANs), wide area networks (WANs), the internet, or other appropriate networking structures. The particular arrangement of network 112 is not critical.
Geography server 114 may store a geographic model in geography database 115, and may use a mapping module 122 to receive and respond to user requests through an interface 118. The interface 118 may be, or be part of, a web server or other similar structure or structures.
The geography database 115 may include one or more database that contain information showing geographic information, such as a map, satellite images, or visual terrain (e.g., satellite images applied to topography).
The mapping module 122 may receive requests from users, such as a user at terminal 110 through interface 118, and may determine what information in geography database 115 the user needs.
For example, the interface 118 may pass certain location information, such as an identifier of a latitude and longitude at which the user has located his or her application, along with information that permits the determination of a bounding box for the area viewed by the user.
The mapping module 122 may then query geography database 115 to obtain data for the area inside the bounding box or other defined area. The mapping module 122 may then pass the information to terminal 110, such as in the form of tiled geographic information around the area the user is viewing, or in another appropriate format.
The object server 116 may contain an object database 117 that stores information about various objects that may be associated with particular areas in a geography. The object database 117 may store, for example, a geographic location identifier for each object so that it may be located within, and overlaid on, a representation of the geography.
The database 117 may also store information about the object that may be displayed in a geographic representation on terminal 110, including in the form of hyperlinks to additional information. For example, the database 117 may include a label, such as "Eiffel Tower models" that may be displayed over a map of Paris.
When a user selects the label, which may be in the form of a hyperlink, the user may be presented with one or more images showing various 3D models of the Eiffel Tower, such as in a pop-up window. (The models may be ordered in various manners, such as by placing most popular models near the top or placing models from certain "trusted" object builders at the top.)
The user may select one of the models, such as by selecting one of the images, and the model may be added to the geography displayed on terminal 110.
Object selection engine 124 may operate through interface 120 to identify objects to be displayed on terminal 110. Interface 120 may again be a web server or servers, or may be part of a web server or other appropriate structure. Object server 116 may receive the same commands as does geography server 114, and may, in parallel with geography server 114, obtain information about objects to be sent to terminal 110.
The object selection engine 124 may, for example, receive information about a location (including information about a boundary for the location, or information that permits the boundary to be determined), and may query object database 117 to find appropriate objects in the area. The objects may be classified into particular groups, such as types of buildings, weather information, etc., and subsets of database 117 may be searched based on particular groups selected by a user of terminal 110.
Object information obtained from object database 117 may be provided in a variety of forms, including via extensible mark-up language (XML) or an XML extension known as Keyhole Mark-up Language (KML).
KML is an XML grammar and file format for modeling and storing geographic features for display in the Google Earth Client application. Particular definitions for version 2.0 of KML are shown in the attached Appendix A.
Labeled arrows that are layered over the components of system 100 show an exemplary flow of information in the system 100. Arrow 1 from rack server 128 shows the submission of information about a particular object to system 100.
Rack server 128 represents, for example, a commercial object generator, such as an architectural firm or other such firm. Such an object generator might also produce objects, such as 3D building models, so as to be able to place advertising on the buildings and thereby generate revenue from users who view such objects.
Server 130 may also submit objects to system 100. Server 130 represents, for example, smaller object providers.
As one example, a user of a computer may generate an object using an application such as SketchUp, AutoCAD, or 3DStudio, and may submit the object to system 100 for display as part of a geographic information system.
In one implementation, the user may visit a web site associated with system 100, and provide information about the object. For example, the user of server 130 may provide a URL where the object may be accessed, such as when other users later choose to incorporate the object into geographies they are viewing.
In addition, the user may provide additional information, such as an exemplary image of the object, and other information about the object (e.g., labels for hyperlinks associated with the object). Rack server 128 may provide similar information when submitting an object, and may do so via an interactive web form, or via another application programming interface.
Information about objects submitted to system 100 may be received by object server 116, which may parse such submissions and store the relevant information in object database 117. The information may include a geographic identifier for the object, so that the object may be readily identified later when a user at client 110 is viewing geography, and requests to see objects associated with that geography.
The lettered flow arrows show actions that may occur when a user at terminal 110 begins looking at information in a geographic information system. At arrow A, the user navigates to a particular area of geography, so that a request for visual information about that area is sent through network, as further indicated by Arrow B, to geography server 114.
The message may also be routed to object server 116, if the user has selected to have displayed any categories of objects associated with the geography. Geography server 114 determines what information is needed to provide interaction for the user with the particular area, and returns that information via Arrow C and Arrow D. The terminal 110 may then begin constructing a view of the area as the information is downloaded.
At Arrow E, the user may select to view additional information about an object displayed in the area of geography. For example, the user may see a link representing a model of a monument (or group of monuments), and may elect to see the model or models.
As one example, a user at rack server 128 may have modeled the monuments on and around the National Mall in Washington D.C., and the terminal 110 may show a link to such models. The user at terminal 110 may select a link displayed over a geographic representation of the Mall (e.g., a map or satellite photo) to obtain more information about the models.
Arrow F shows the user's request being received by object server 116. The request may be formed, for example, in the form of an HTTP request or an XML message. An identifier for the object may be parsed out of the request by server 116, for example, and submitted to object database 117 as a query.
The database 117 may then return information, such as an image of the models, which may be returned to terminal 110 via Arrow G and Arrow H.
If the user of terminal 110 likes the models shown in the image, he or she may select to receive the full models. That selection may occur, for example, by clicking on the image. Such an action may cause a message to be delivered to rack server 128 via Arrow I and Arrow J, and rack server may respond by sending information needed to display the model or models via Arrow K and Arrow L.
Now let me show you Figure 2, along with the accmpanying documentation:
FIG. 2 is a swim-lane diagram of actions that may be taken to provide a user with information about objects associate with a geography. At act 200, a user of a client device navigates to a geographic location, such as by entering a lat/long combination or an address, or by moving a graphical representation of the geographic area into view on a display.
Messages are sent to a geography server and an object server, and may define the currect viewport for the application running on the user's terminal.
The message may take the form, for example, of a query parameter that identifies a viewport showing a particular geographic area. In one example, if a user is viewing the city of San Francisco, the message may take the form of: Bbox=37.9% 2C37.7% 2C-122.2% 2C-122.4
The geography server returns a representation of the location, such as by obtaining satellite or map tiles for the area and for a geography a set distance around the area (act 202). The object server uses geographic information received from the client to look-up and return objects that may be in the requested area/location (act 204).
The information returned by the object server may be, as noted above, textual or image information, along with hyperlink information relating to architectural or other objects in the geographic area.
The information may be transmitted, as indicated above, in a KML document, which may contain, for each object or model:
A placemark that pin-points the location of the model on the earth;
A link to a preview image of a thumbnail of the model; and
Links to allow a user to download the model, such as in applications like Google Earth and Google SketchUp or other display and editing applications.
At act 206, the client displays the geographic information at the particular locations, along with object indicators, such as hyperlinks. The indicators may be displayed, for example, overlaid on the geographic information, or to the side of the geographic information, such as in a list of objects relevant to the display.
A user at the client may then select an object indicator 208, such as an indicator for a preview image of an object (act 208).
This selection may cause the object server (or another appropriate structure) to deliver a preview image to the client (act 210).
The user at the client may then select to view more complete information about an object (act 212), such as information needed to define a full 3D model. Such selection may occur, for example, by selecting an image of the model having a hyperlink associated with it.
The link may send a message to the object server, or to another server that requests information about the model or models. The server may then retrieve information about the model or models and transmit it back to the client (act 214).
Upon receiving the information, the client may use the information to locate and render the object for visual review by a user (act 216).
For example, the client may render the object as a 3D item on top of a representation of the earth.