JP2010504560A - Method and system for displaying graphic objects on a digital map - Google Patents

Abstract

According to an embodiment of the present invention, a method for displaying a graphic object on a digital map includes: for a graphic object, a parameter indicating the type of the graphic object; Receiving metadata including a set of parameters indicating the geographic location of the object represented by the graphic object. The type of the graphic object is one of a group of stored types. The method further includes rendering the graphic object on the digital map by generating a set of geographic coordinates for the graphic object based on the received metadata.

Description

  The present invention relates generally to a method and system for displaying graphic objects on a digital map, and more particularly on a digital map.

  Digital maps have been developed to search, identify and discover information about geographic locations. Some mapping programs generate digital maps using satellite imaging. Examples of such mapping programs include "Google Earth" and Microsoft's "Virtual Earth". Such existing mapping programs typically provide a basic digital map with simple lines that draw simple graphics and annotations that describe the map features.

  However, these existing mapping programs do not natively support the display of more complex 2D and 3D graphic objects.

  According to an embodiment of the present invention, a method for displaying a graphic object on a digital map includes: for a graphic object, a parameter indicating the type of the graphic object; Receiving metadata including a set of parameters indicating the geographic location of the object represented by the graphic object. The type of the graphic object is one of a group of stored types. The method further includes rendering the graphic object on the digital map by generating a set of geographic coordinates for the graphic object based on the received metadata.

  Technical advantages of the individual embodiments of the present invention include a method and system for displaying a graphic object on a digital map that generates markup language code from simple metadata describing the graphic object. including. This dramatically reduces the development time and software maintenance costs for rendering graphic objects.

  Another technical advantage of the individual embodiments of the present invention is a method for displaying graphic objects on a digital map that automatically obtains graphic object information through a subscription mechanism and Includes system. Thus, the present invention dynamically updates graphic objects in real time.

  Other technical advantages of the present invention will be readily apparent to one skilled in the art from the following figures, descriptions, and claims. Furthermore, although individual advantages are listed above, various embodiments may include all of the listed advantages, some, or none.

  For a more complete understanding of the present invention and its features and advantages, reference is now made to the following description, which is to be referred to in conjunction with the accompanying drawings.

1 is a block diagram illustrating a system for displaying graphic objects on a digital map in accordance with the teachings of the present invention. FIG. 2 is a representative image illustrating a graphic object on a digital map in accordance with the present invention. 3 is a flowchart illustrating an exemplary operation associated with a method of displaying a graphic object on a digital map.

  Embodiments of the present invention and their advantages are best understood by referring to FIGS. 1-3 of the drawings. Like reference numerals are used for like and corresponding parts of the various figures.

  FIG. 1 is a block diagram illustrating a system 10 for displaying graphic objects on a digital map in accordance with the teachings of the present invention. As shown in FIG. 1, the system 10 generally includes a digital map client 20, a digital map server 30, and a graphic object server 40. System 10 is particularly adapted for displaying graphic objects on a digital map.

  Digital map client 20 may refer to any suitable device operable to display a digital map. A digital map may refer to any computerized representation of a geographical area that can be displayed and analyzed by a computer. For example, the most common method of digital map generation is digitization, where a hardcopy map is converted to a digital medium through the use of computer programs and geographic information. As another example, a digital map may be generated by converting existing digital information that may not yet be in the form of a map into a form that can be recognized and used by a computer. Thus, digital satellite images generated through remote sensing may be combined to produce a layer of digital information that results in a flat projection of the Earth's surface.

  In particular embodiments of the present invention, the digital map client 20 may be operable to run an application that allows a user to interact with the digital map, such as “Google Earth”. “Google Earth” is an application that maps the Earth by combining images obtained from satellite imaging. By entering the appropriate command, the user will instruct “Google Earth” to “zoom” to a lower relative viewpoint position, which will result in “Google Earth” being displayed at a higher resolution. A digital map of a small geographic area can be displayed. “Google Earth” also allows the user to “scroll” or “fly” to different lateral positions on the digital map. In other embodiments of the present invention, the digital map client 20 is operable to run other applications that allow the user to interact with the digital map over the Internet, such as Microsoft's “Internet Explorer” browser. It may be.

  The digital map client 20 runs on any of the well-known MS-DOS, PC-DOS, OS-2, MAC-OS, Windows ™, UNIX, or other suitable operating systems including future OSs. May be. The digital map client 20 may include, for example, a personal digital assistant, a computer such as a laptop, a mobile phone, a mobile terminal, or any other device operable to display a digital map.

  Digital map server 30 may refer to any suitable device operable to deliver digital maps, images, scripting languages, and other static elements that are sent to digital map client 20 as indicated by reference numeral 31. .

  According to one particular embodiment of the present invention, the digital map server 30 is a tile serving system operable to deliver individual digital map tiles in response to requests from the digital map client 20. Software that is operable to facilitate processing may be included. For example, the digital map server 30 proceeds a series of mapping data from the first highest magnification with the lowest resolution to the last magnification with the highest resolution to present the mapping data with variable resolution. It can be organized in a hierarchical structure of magnification. Thus, the tile supply system may have fewer tiles at the top and may include four times as many tiles as the next level up one level. This software may properly interface with the corresponding software supplied in the digital map client 20. Alternatively, the digital map server 30 may include any other suitable software operable to deliver individual map tiles in response to requests from the digital map client 20.

  Graphic object server 40 represents any suitable device operable to render graphic objects for display on a digital map at digital map client 20. Although FIG. 1 provides an example of a graphic object server 40 as operating separately from the digital map server 30, in other embodiments, the graphic object server 40 operates within the digital map server 30. May be. In yet another embodiment, digital map client 20, digital map server 30, and graphic object server 40 may operate within the same server. Additional details of an example graphic object server 40 are described in more detail below.

  In various embodiments of the present invention, existing mapping programs such as “Google Earth” may provide a markup language for displaying points and lines on a digital map. Markup language refers to a language having codes that indicate the layout, style and placement of graphics. Keyhole Markup Language (KML) is one such markup language for handling geographic data on "Google Earth". A KML document can contain code that describes a basic feature along with the latitude and longitude coordinates of the feature. For example, in a KML document, a placemark such as the location of a state capital may be defined along with a representative icon. However, existing mapping programs such as “Google Earth” are generally limited to displaying simple lines using the markup language, and display more complex 2D and 3D graphic objects. Is not natively supported.

  In accordance with certain embodiments of the present invention, systems and methods are provided for displaying complex graphic objects on a digital map. This is provided in some embodiments by a mechanism that generates multi-line markup language code from simple metadata describing a graphic object. The markup language code is then used to render the graphic object for display on the digital map. Additional details of exemplary embodiments of the present invention are described in greater detail below, along with portions of FIGS.

  In accordance with the illustrated embodiment of the present invention, the graphic object server 40 includes a metadata catalog (MDC) 42 and a graphic object manager 44. In the illustrated embodiment, the MDC 42 is in the graphic object server 40, but in other embodiments the MDC 42 may be on a separate server.

  MDC 42 may refer to any suitable device that stores metadata and is operable to facilitate the addition, modification and retrieval of such metadata. In general, metadata is data describing other data. In the context of MDC 42, MDC 42 stores the metadata as descriptive data about the graphic object to be displayed. In accordance with one particular embodiment of the present invention, the MDC 42 utilizes a relational database management system to store metadata, and the metadata is structured query language (SQL) that is easy to use and well understood. : Available and accessible through an access language such as Structured Query Language). In other embodiments, the MDC 42 may utilize other metadata management systems.

  According to one embodiment, the MDC 42 may store metadata corresponding to the graphic object type to be displayed on the digital map locally. A graphic object type may refer to the name of any computer data that can be rendered on a computer in the form of an image. A geometric object drawn in a geometric space. For example, the MDC 42 may store a type value that specifies the type of 3D graphic, such as an ellipsoid to be displayed at a particular location. In other embodiments, a graphic object type may refer to the name of any digital photograph, figure, icon, symbol or other data that can be rendered on a computer in the form of an image. For example, the MDC 42 may store a type value that specifies the type of icon, such as a military symbol, to be displayed at a particular location.

  According to some embodiments of the present invention, the MDC 42 may locally store metadata corresponding to the geographic location of the graphic object to be displayed on the digital map. For example, the MDC 42 may store latitude, longitude, and altitude values that describe the center point of a 3D graphic such as an ellipsoid to be displayed. As another example, MDC 42 may describe latitude, longitude, and altitude values that describe a center point for a symbol, such as a military symbol to be displayed.

  According to an embodiment, the MDC 42 may store metadata corresponding to the size description of the graphic object to be displayed on the digital map locally. For example, the MDC 42 may store width, height and length values that describe the size for a 3D graphic such as an ellipsoid to be displayed. As another example, MDC 42 may store a radius value that describes the size for a 2D graphic, such as a circle to be displayed.

  Table 1 is an exemplary document with document tags populated with attributes for graphic objects that can be stored as metadata in MDC 42, in accordance with an embodiment of the present invention. A tag can refer to any marker embedded in a document that indicates the data contained within the element. For example, in Table 1, line 1, the first tag indicates that the document is an Extensible Markup Language (XML) document. XML refers to a flexible syntax for describing data. Based on data type definition (DTD) files and XML schema language files, clients such as administrators or automated scripts can create documents with XML tags. A self-describing XML tag maps to information related to various graphic objects. However, other documents can equally be used in alternative embodiments. For example, the document may be a standard ASCII text file, HTML file or other suitable document, for example with some proprietary format.

  Table 1, row 2 shows latitude, longitude, and altitude values that describe the center point for the graphic object. Row 3 of Table 1 shows a graphic object type, a type value that specifies an ellipsoid, a width (height), a height (height), and a length (length) that describe the size of the ellipsoid. ) Together with the value.

しかしながら、本開示はグラフィック・オブジェクト属性の多くの型を構想している。さまざまな実施形態は、列挙された属性の一部を含んでいてもよいし、全部を含んでいてもよいし、あるいは一つも含んでいてなくてもよい。

However, this disclosure contemplates many types of graphic object attributes. Various embodiments may include some, all, or none of the listed attributes.

  Graphic object manager 44 is embodied in a computer readable medium and refers to any suitable logic operable to render a graphic object for display on digital map client 20 when executed. May be. In the illustrated embodiment of the present invention, the graphic object manager 44 is on the graphic object server 40. In other embodiments of the present invention, the graphic object manager 44 may be on the digital map client 20 or on any other suitable device operable to connect to the MDC 42.

  In accordance with the illustrated embodiment of the present invention, the graphic object manager 44 includes various modules operable to perform various functions. It includes an inquiry module 46, an applicator module 48 and a rendering module 50.

  In accordance with an embodiment of the present invention, query module 46 may query MDC 42 for metadata, as indicated by reference numeral 41. In particular embodiments of the present invention, the query module 46 queries the MDC 42 for any type of metadata, such as location metadata, graphic object metadata, state metadata, or any other suitable metadata. May be. The query module 46 may query the MDC 42 for metadata that matches the specified criteria. For example, the specified criteria used by query module 46 may include spatial criteria. Spatial criteria may specify location attributes such as latitude and longitude values as a search filter for graphic object metadata. As another example, the specified criteria used by query module 46 may include context criteria. The context criteria may specify a pattern, such as a string pattern, as a search filter for graphic object metadata. As another example, the specified criteria used by the query module 46 may include temporal criteria. The temporal criteria may specify a time attribute, such as the date and time last modified, as a search filter for graphic object metadata. However, the present disclosure envisions many types of query criteria. Various embodiments may include some, all, or none of the listed query criteria.

  Query module 46 may query MDC 42 for graphic object metadata using Java Server Pages (JSP) in accordance with an embodiment of the present invention. JSP can generate a markup language that can be defined using tags. When executed by a JSP container, a definable markup language can produce results in a variety of formats, such as XML. For example, according to the runtime behavior of the JSP container, the open element of the query tag is interpreted and loaded into system memory. Any attribute specified in the tag can be loaded at runtime. The JSP container then interprets all nested child tags and their body contents are translated and then passed back to the parent query tag. The parent query tag now has the criteria needed to query the MDC 42.

  According to an embodiment of the present invention, search criteria collected by query module 46 from nested tags can be consolidated and passed to MDC 42. In other embodiments, the query module 46 may query the MDC 42 without search criteria. The results from MDC 42 from query module 46 are loaded into a collection object. By obtaining the aggregate object generated by the query tag, the JSP can generate a markup language document defined by the developer, such as the document in Table 1, at runtime.

  According to some embodiments of the present invention, a subscriber module 48 may subscribe to the MDC 42 to receive continuous updates to the metadata from the MDC 42. The applicator module 48 can apply to the MDC 42 for metadata that matches the specified criteria. For example, the specified criteria used by the applicator module 48 may include spatial criteria as described above. As another example, the specified criteria used by the applicator module 48 may include context criteria as described above. As another example, the specified criteria used by the applicator module 48 may include temporal criteria as described above. However, the present disclosure envisions many types of application criteria. Various embodiments may include some, all, or none of the listed application criteria.

  The applicator module 48 may subscribe to the MDC 42 to receive ongoing updates to the metadata from the MDC 42 using JSP, according to an embodiment of the invention. For example, a user session at the digital map client 20 may be obtained from a JSP container and a lookup may be performed on a “sub ID” attribute. The “sub-Id” attribute may refer to a unique identifier for storing and locating the MDC 42 applicator instance within the user session. If an instance is found, the application process continues. Otherwise, a new instance is created. The instance is bound to the user's session supplied by the JSP container.

  For any updates to the metadata in MDC 42, applicator module 48 may receive an update for each user session. The application result is loaded into the aggregate object. The aggregate object is then bound to the user session. By obtaining the aggregate object generated by the query tag, the JSP can generate a markup language document defined by the developer, such as the document in Table 1, at runtime.

  According to one embodiment of the invention, rendering module 50 receives metadata and renders the metadata into a markup language for display on a digital map. For example, the rendering module 50 may identify the graphic object type to be displayed from the received metadata. The graphic object type may be a 3D graphic such as an ellipsoid to be displayed on a digital map.

  The rendering module 50 may use the received object type metadata to generate a model representing the graphic object, according to an embodiment of the invention. For example, the rendering module 50 may generate an ellipsoid model for a particular graphic object type. To generate the model, the rendering module 50 can input ellipsoid attributes such as length, width and height from the metadata to the ellipsoid generation algorithm. The ellipsoid generation algorithm can generate the coordinates of the vertices of the ellipsoid model in Cartesian coordinates. As an example, without limitation, Table 2 illustrates an ellipsoid generation algorithm.

本発明のある実施形態によれば、レンダリング・モジュール５０はレンダリング属性をモデルの生成された座標に適用しうる。たとえば、レンダリング・モジュール５０によって適用される属性は、回転および傾き属性を含みうる。回転属性は、モデルの座標をある軸に沿って回転させる属性を指しうる。z軸に沿った回転（rotation along the z-axis）を適用するためには、レンダリング・モジュール５０は次の公式：
x＝x座標
y＝（ cos(回転)×y座標）＋（sin(回転)×z座標）
z＝（−sin(回転)×y座標）＋（cos(回転)×z座標）
を使ってもよい。

According to some embodiments of the invention, rendering module 50 may apply rendering attributes to the generated coordinates of the model. For example, attributes applied by the rendering module 50 can include rotation and tilt attributes. The rotation attribute may refer to an attribute that rotates the coordinates of the model along an axis. To apply rotation along the z-axis, the rendering module 50 uses the following formula:
x = x coordinate
y = (cos (rotation) x y coordinate) + (sin (rotation) x z coordinate)
z = (-sin (rotation) x y coordinate) + (cos (rotation) x z coordinate)
May be used.

The tilt attribute can refer to an attribute that tilts the coordinates of the model along the north / south axis and the east / west axis. To apply the tilt along the East / West axis, the rendering module 50 uses the following formula:
x = (cos (tiltE) × x coordinate) + (− sin (tiltE) × z coordinate)
y = (y coordinate)
z = (sin (tiltE) x x coordinate) + (cos (tiltE) x z coordinate)
May be used. To apply the tilt along the North / South axis, the rendering module 50 uses the following formula:
x = (cos (tiltN) x x coordinate) + (sin (tiltN) x y coordinate)
y = (− sin (tiltN) × x coordinate) + (cos (tiltN) × y coordinate)
z = z coordinate may be used.

  According to some embodiments of the invention, rendering module 50 may apply other rendering attributes such as scale, altitude mode, resolution and shadow attributes to the generated coordinates of the model. The scale attribute can refer to an attribute that determines the size of the model. The altitude mode attribute may refer to an attribute that determines the relationship of the model to the ground. The resolution attribute may refer to an attribute that determines the number of line segments in the model. The shadow attribute may refer to an attribute that positions a corresponding shadow element under the model. However, the present disclosure envisions displaying many types of rendering attributes. Various embodiments may include some, all, or none of the listed rendering attributes.

  According to an embodiment of the invention, the rendering module 50 may convert the generated Cartesian coordinates of the model into a polar coordinate representation. For example, the following formula for solving for the polar coordinates of the model's projected latitude and longitude using the latitude, longitude, and altitude values (latx / longx) passed in the metadata:

が、レンダリング・モジュール５０によって使用されうる。与えられた例で、latおよびlongはモデルの中心点を表し、distance〔距離〕はモデルの点からモデル中心までの距離を表し、heading〔方位〕は北から時計回りに測ったモデル点の角度を表す
極座標表現では、レンダリング・モジュール５０は、原点からの距離と座標までの角度を使って、その座標をマークアップ言語を使ってデジタル地図上にレンダリングしうる。マークアップ言語文書が、モデルの投影された緯度（latx）および経度（longx）座標に基づいて生成されうる。たとえば、一般的なマークアップ言語は、ハイパーテキスト・マークアップ言語（HTML）およびKMLを含む。たとえば、KML文書は、デジタル地図における表示のためのグラフィック・オブジェクトを、それらのグラフィック・オブジェクトのさまざまな線および座標を表すKMLノードを使って指定しうる。

Can be used by the rendering module 50. In the given example, lat and long represent the center point of the model, distance represents the distance from the model point to the model center, and heading is the angle of the model point measured clockwise from north. In the polar coordinate representation, the rendering module 50 may render the coordinates on a digital map using a markup language using the distance from the origin and the angle to the coordinates. A markup language document may be generated based on the projected latitude (latx) and longitude (longx) coordinates of the model. For example, common markup languages include hypertext markup language (HTML) and KML. For example, a KML document may specify graphic objects for display on a digital map using KML nodes that represent the various lines and coordinates of those graphic objects.

  Table 3 is an exemplary KML document that the rendering module 50 may generate for the graphic objects of Table 1 according to an embodiment of the present invention. Rows 4 to 12 and rows 14 to 22 in Table 3 show polygon information forming a 3D ellipsoid. Lines 8-9 and 18-19 in Table 3 show the coordinates of the points of the respective polygons. The ellipsis in row 13 of Table 3 indicates that multiple rows of polygon data may be generated to render a 3D ellipsoid. Thus, several rows of tags from Table 1 can generate multiple rows of KML content from Table 3.

本発明のある実施形態によれば、レンダリング・モジュール５０は、表３におけるサンプルKML文書のような文書を、参照符号２３によって示されるように、デジタル地図クライアント２０に表示のために送ってもよい。たとえば、デジタル地図クライアント２０は、参照符号２１によって示されているように、グラフィック・オブジェクト・サーバー４０に、現在、ユーザーに対して表示されている特定の位置を通信してもよい。レンダリング・モジュール５０は、その特定の位置に表示されるべきグラフィック・オブジェクトについて、図１の文書のような文書を受信してもよい。レンダリング・モジュール５０は前記文書をレンダリングしてKMLのようなマークアップ言語文書にし、その特定の位置に前記グラフィック・オブジェクトを表示するために、そのマークアップ言語文書をデジタル地図クライアント２０に渡しうる。

According to an embodiment of the invention, rendering module 50 may send a document, such as a sample KML document in Table 3, to digital map client 20 for display, as indicated by reference numeral 23. . For example, digital map client 20 may communicate to graphic object server 40 the particular location currently displayed to the user, as indicated by reference numeral 21. The rendering module 50 may receive a document, such as the document of FIG. 1, for a graphic object that is to be displayed at that particular location. The rendering module 50 may render the document into a markup language document such as KML and pass the markup language document to the digital map client 20 to display the graphic object at that particular location.

  FIG. 2 is a representative image 110 showing a graphical object on a digital map according to an embodiment of the present invention. As shown in FIG. 2, the image 110 is generally a 2D circle object 120, a 3D sphere object 122, a 3D cone object 124, a 2D ring object 126, a 3D cylinder object 128, a 3D cuboid object 130, and a 3D hemisphere object. 132. However, the present disclosure envisions displaying many types of graphic objects. Various embodiments may include some, all, or none of the listed graphic objects.

  According to some embodiments of the present invention, image 110 may be generated by drawing a graphic object with 2D and 3D object wireframes and triangular mesh lines using a markup language document such as KML. The coordinates of the line defining the object can have latitude, longitude and altitude values stored in the respective KML document. These coordinates may be generated from metadata that describes the graphic object using type, size and position.

  The image 110 can be generated by obtaining a basic map image for a specified location. The specified location can be used to query the metadata catalog for a graphic object at the specified location. Next, a model of each graphic object at the specified location can be generated in Cartesian coordinates. Cartesian coordinates may be converted to polar coordinates for projection onto a digital map. A markup language document such as a KML document can be generated based on the transformed coordinates. The KML document is used by the digital map client to render a graphic object at a specified location. According to various embodiments, depending on the complexity of the graphic object to be displayed, several lines of graphic object attributes can generate thousands of lines of KML code. This approach significantly reduces development time and software maintenance costs to produce similar results.

  FIG. 3 is a flowchart illustrating exemplary operations associated with a method for displaying a graphic object on a digital map. These exemplary operations may be performed by the graphic object manager 44 discussed above with reference to FIG. In step 302, graphic object metadata may be received. In particular embodiments of the present invention, the received metadata may include graphic object types to be displayed on the digital map. For example, a metadata catalog may store a type value that specifies an ellipsoid to be displayed at a given location. In particular embodiments of the present invention, the received metadata may include the geographic location of the graphic object to be displayed at a particular location. For example, the metadata catalog may store latitude, longitude, and altitude that describe the center point for 3D graphics such as ellipsoids to be displayed. In particular embodiments of the present invention, the received metadata may include a description of the size of the graphic object to be displayed on the digital map. For example, the metadata catalog may store width, height, and length values that describe the dimensions for a 3D graphic, such as an ellipsoid to be displayed.

  In step 304, a model can be generated based on the received metadata. The type of graphic object can determine the algorithm used to generate the model. For example, an ellipsoid model can be generated for a particular graphic object type. Ellipsoid attributes from metadata such as length, width and height can be applied to the ellipsoid generation algorithm to generate the model. The ellipsoid generation algorithm can generate ellipsoid model coordinates in Cartesian coordinates.

  In step 306, the model coordinates are transformed and projected onto the digital map. In particular embodiments of the present invention, the generated Cartesian coordinates of the model can be converted to a polar coordinate representation. For example, to solve for the projected latitude and longitude polar coordinates of the model, a conversion formula using latitude, longitude and altitude values in the metadata can be used.

  In step 308, the graphic object may be rendered based on the transformed coordinates. For example, using a polar coordinate representation, the distance from the origin and the angle to the coordinate can be used to project the coordinate onto the digital map. A markup language document may be generated based on the projected latitude (latx) and longitude (longx) coordinates. For example, common markup languages include HTML and KML.

  Thus, by providing size, center location and type metadata about a graphic object, geographic coordinates can be generated to display that graphic object on a digital map. For example, a KML document may be used to define the graphic object using KML nodes in order to associate various lines and geographic coordinates that represent the graphic object.

  Although the present invention has been described in several embodiments, numerous changes, variations, alterations, transformations and modifications can occur to those skilled in the art. The present invention is intended to embrace such alterations, modifications, variations, changes and modifications that fall within the spirit and scope of the appended claims.

Claims (20)

A method for displaying graphic objects on a digital map:
For a graphic object, metadata that includes a parameter that indicates the type of the graphic object, multiple parameters that indicate the size of the graphic object, and multiple parameters that indicate the geographic location of the object represented by the graphic object And the mold is one of a plurality of stored molds; and
Rendering the graphic object on the digital map by generating a plurality of geographical coordinates for the graphic object based on the received metadata.
Method. Rendering the graphic object on the digital map by generating a plurality of geographic coordinates for the graphic object based on the received metadata:
Generating a model including a plurality of Cartesian coordinates representing the graphic object;
Generating a plurality of polar coordinates by transforming the plurality of Cartesian coordinates;
The method of claim 1. The step of rendering the graphic object on the digital map includes:
Render 3D graphics;
Render 2D graphics; and render icons
The method of claim 1, comprising a step selected from the group consisting of:   The plurality of parameters indicating the geographical position of the object represented by the graphic object are a parameter indicating the longitude of the graphic object, a parameter indicating the latitude of the graphic object, and a parameter indicating the altitude of the graphic object. The method of claim 1 comprising:   The method of claim 1, further comprising applying a plurality of rendering attributes including one or more tilt attributes to the graphic object.   The method of claim 1, further comprising: subscribing to a metadata catalog to receive updates to the received metadata.   The method of claim 1, wherein the step of rendering the graphic object on the digital map includes generating a keyhole markup language (KML) document based on the transformed coordinates. A system for displaying graphic objects on a digital map:
A digital map client operable to display the digital map;
A digital map server operable to store the digital map and deliver the digital map to the digital map client;
A graphic object manager coupled to the digital map client comprising:
For a graphic object, metadata that includes a parameter that indicates the type of the graphic object, multiple parameters that indicate the size of the graphic object, and multiple parameters that indicate the geographic location of the object represented by the graphic object And the mold is one of a plurality of stored molds; and
Rendering the graphic object on the digital map by generating a plurality of geographical coordinates for the graphic object based on the received metadata; Having a manager,
system. The graphic object manager further includes:
Generating a model including a plurality of Cartesian coordinates representing the graphic object;
Generating a plurality of polar coordinates by transforming the plurality of Cartesian coordinates;
The system of claim 8. The step of rendering the graphic object on the digital map by the graphic object manager:
Render 3D graphics;
Render 2D graphics; and render icons
The system of claim 8, further operable to perform according to a process selected from the group consisting of:   The plurality of parameters indicating the geographical position of the object represented by the graphic object are a parameter indicating the longitude of the graphic object, a parameter indicating the latitude of the graphic object, and a parameter indicating the altitude of the graphic object. The system of claim 8, comprising:   The system of claim 8, wherein the graphic object manager is further operable to apply a plurality of rendering attributes including one or more tilt attributes to the graphic object.   The system of claim 8, wherein the graphic object manager is further operable to subscribe to a metadata catalog to receive updates to the received metadata.   The graphic object manager performs the step of rendering the graphic object on the digital map by generating a keyhole markup language (KML) document based on the transformed coordinates. The system of claim 8, wherein the system is operable. Logic encoded in a computer readable medium when executed:
For a graphic object, metadata that includes a parameter that indicates the type of the graphic object, multiple parameters that indicate the size of the graphic object, and multiple parameters that indicate the geographic location of the object represented by the graphic object And the mold is one of a plurality of stored molds; and
Rendering the graphic object on the digital map by generating a plurality of geographical coordinates for the graphic object based on the received metadata.
logic. Generating a model including a plurality of Cartesian coordinates representing the graphic object;
Generating a plurality of polar coordinates by transforming the plurality of Cartesian coordinates;
The logic of claim 15. The logic may render the graphic object on the digital map:
Render 3D graphics;
Render 2D graphics; and render icons
The logic of claim 15, operable to perform by a process selected from the group consisting of:   The plurality of parameters indicating the geographical position of the object represented by the graphic object are a parameter indicating the longitude of the graphic object, a parameter indicating the latitude of the graphic object, and a parameter indicating the altitude of the graphic object. The logic of claim 15, comprising:   The logic of claim 15, wherein the logic is further operable to apply a plurality of rendering attributes including one or more tilt attributes to the graphic object.   The logic is operable to perform the step of rendering the graphic object on the digital map by generating a keyhole markup language (KML) document based on the transformed coordinates. The logic of claim 15.

Images