Rendering map images using modifications of non-raster map data

A map server generates vector descriptors in a non-raster format, each indicating a geometry of a respective map element, to render a first map image of a selected geographic region at a client device. The map server then provides the vector descriptors to the client device. Upon receiving an indication that a second map image for the selected geographic region is to be rendered at the client device, the map server generates a modification indication that indicates a set of one or more vector descriptors, each of which corresponds to a respective map element that is rendered in one but not both of the first map image and the second map image, and provides the modification indication to the client device, so that the client device can render the second map image using at least some of the vector descriptors and the modification indication.

FIELD OF THE DISCLOSURE

The present disclosure relates to map rendering systems, such as electronic map display systems, and more specifically to a map rendering system in which map images are rendered using map data provided in a non-raster format.

BACKGROUND

Today, maps of geographic regions may be displayed by software applications running on a wide variety of devices, including mobile phones, car navigation systems, hand-held global positioning system (GPS) units, and computers. Depending on the application and/or user preferences, maps may display topographical data, street data, urban transit information, traffic data, etc. Further, some applications display maps in an interactive mode, so that a user may operate various controls (radio buttons, scrollbars, etc.) to change the zoom level or pan the “camera” to a new location, for example. A user in some cases also may select or unselect the display of certain information. For example, the user may operate the appropriate control to turn on the display of bicycle trails.

To render a map image, a device typically receives raster images from a dedicated server. For example, a map server may operate on the Internet and provide images in a Portable Network Graphics (PNG) format to various client devices for the specified geographic regions. While raster images are relatively easy to render at a client device, raster image data typically requires a large amount of storage space for a comprehensive map. Also, it is difficult to efficiently manipulate raster images at a client device. For example, to zoom in on a selected region, either new raster image data is retrieved from the server, or the available raster image data is enlarged with a noticeable loss in quality.

SUMMARY

In an embodiment, a computer-implemented method for providing map data to a client device includes generating several vector descriptors for rendering, at the client device, a first map image for a selected geographic region, where each vector descriptor indicates a geometry of a respective map element in accordance with a vector graphics format. The method further includes causing the vector descriptors to be transmitted to the client device via the communication network, receiving an indication that a second map image for the selected geographic region is to be rendered at the client device, such that the second map image is different from the first map image, generating a modification indication that indicates a set of one or more vector descriptors, each of which corresponds to a respective map element that is rendered in one but not both of the first map image and the second map image, and causing the modification indication to be transmitted to the client device via the communication network for rendering the second map image using at least some of the vector descriptors and the modification indication.

In another embodiment, a tangible non-transitory computer-readable medium stores instructions that, when executed by one or more processors, cause the one or more processors to generate map data in a non-raster format for a selected geographic region, where the map data is interpretable at a client device to generate a first map image in a raster format and cause the map data to be transmitted to the client device via a communication network. Further, the instructions, when executed by one or more processors, cause the one or more processors to receive, from the client device, an indication that a second map image for the selected geographic region is to be rendered at the client device, generate a modification indication descriptive of one or more modifications to the map data for transforming the first map image into the second map image, and cause the modification indication to be transmitted to the client device via a communication network for rendering the second map image in the raster format at the client device using at least a portion of the map data and the modification indication.

In another embodiment, a method in a computing device for generating map images includes receiving, via a communication network, several vector descriptors for rendering a first map image for a selected geographic region, where each vector descriptor indicates a geometry of a respective map element in accordance with a vector graphics format and rendering the first map image using the plurality of vector descriptors. The method also includes receiving, via the communication network, a modification indication that indicates a modification of the several vector descriptors for rendering a second map image for the selected geographic region and rendering the second map image for the selected geographic region using at least some of the vector descriptors and the modification indication.

In yet another embodiment, a computing device operating in a communication network includes a processor, a memory coupled to the processor, a network interface for communicating via the communication network, and several routines stored in the memory. A first routine executes on the processor to cause a request for map data corresponding to a selected geographic region to be transmitted via the network interface. A second routine executes on the processor to render a first map image using a plurality of vector descriptors received via the network interface in response to the request, where the plurality of vector descriptors is in a non-raster format. A third routine executes on the processor to cause a request for modification data corresponding to the selected geographic region to be transmitted via the network interface. A fourth routine executes on the processor to render a second map image using at least some of the plurality of vector descriptors and the modification data.

DETAILED DESCRIPTION

In embodiments of systems and methods discussed below, a map server efficiently provides map data for rendering map images to a client device. According to some embodiments, after the map server provides map data to a client device for rendering a first map image (e.g., a basic map image) corresponding to a certain area or geographic region, the map server provides modification data to the client device for rendering a second, different map image (e.g., a traffic map image) corresponding to the same area. The client device then may render the second map image using the map data previously provided for rendering the first map image and the modification data, and the map server need not necessarily provide map data used in rendering both the first map image and the second image to the client device more than once. Depending on the scenario, the modification data may include one or more additions to the previously provided map data, deletions of one or several portions of the previously provided map data, or modifications of one or several portions of the previously provided map data.

In an embodiment, the map server provides map data in a non-raster format, and the client interprets some or all of the map data to generate the first map image and the second map image as a respective raster images. The map data additionally may include text data to specify map labels to be displayed with individual or aggregate map elements. To render the first map image, the client device may request map data from the map server via a communication network, and the map server in response may provide map data that describes map content according to a vector graphics format. The map data may specify various geometric shapes (e.g., using mathematical descriptions of points and paths connecting the points) and indicate how these shapes should be positioned for rendering various map elements such as roads, buildings, parks, bodies of water, etc. For example, rather than specifying each pixel that makes up a raster image of a line segment, a vector-based description of the line segment may specify the two endpoints of the line segment and indicate that the two endpoints are connected by a straight line. Vector-based descriptions of map elements may be referred to herein as vector descriptors or simply vectors, and a set of one or several vector descriptors may be referred to as vector data. Further, an individual map element (e.g., a building) or an aggregation of several map elements (e.g., buildings, parks, bicycle paths, and pedestrian paths of a college campus) in some scenarios may define a map feature (or simply feature). In an embodiment, a map feature is assigned a unique identifier which the map server and the map client may utilize for identification. In general, a map feature may be described using one or more vector descriptors.

The client device may request map data for rendering the first map image and the second map image in response to respective user commands, for example. The user commands may indicate a selection of a different map type, a different zoom level, etc. According to an example scenario, a user selects a geographic region and a basic map type, e.g., the type of a map that illustrates roads, streets, major landmarks, etc. The client device generates a request for rendering a map image and transmits the request to the map server, which in response provides map data in a vector graphics format (or other non-raster format suitable for rendering a raster image at the client device). The map data may include several vector descriptors and, in some cases, additional data such as style data, label data, etc. More specifically, label data may include characters in the American Standard Code for Information Interchange (ASCII) format, a Unicode format, or any other suitable character format. The client device then interprets the map data to render the map image and display the map image on a display device. To continue with the scenario above, the user then may select a transit map for the same geographic region, and the client device in response may generate an indication that a new map image corresponding to a transit map is to be generated and transmit the indication to the map server. According to one implementation, the client device generates a request for map data of the new type (e.g., “provide map data for a transit map of region R”), and the map server checks previous communications with the client device to determine what kind of map data was previously sent to, and therefore is already available at, the client device. In another implementation, the client device specifies what kind of map data for the selected region is already available at the client device in addition to requesting map data of the new type (e.g., “provide map data for a transit map of region R, given that I already have map data for a basic map of region R at the same zoom level”). The map server in this case does not need to know what map data, if any, was previously sent to the client device. More generally, a history of transactions between a map server and a client device may be maintained by the map server and/or the client device.

The map server then may determine which map elements and labels must be added to, removed from, or modified in the map data already available at the client device. For example, the map server may determine how a basic map for a certain region and a certain zoom level differs from a transit map for the same region and the same zoom level, and generate an appropriate modification indication. For example, the modification indication may include vector descriptors for rendering subway lines not included in the basic map image. The map server then provides the modification indication to the client device for rendering the transit map image using, at least partially, the map data provided for rendering the basic map image as well as the modification indication.

These and other example scenarios in which map data for rendering map images is efficiently provided to a client device are further discussed with reference to the accompanying drawings. Some of the figures may have been simplified by the omission of certain elements for the purpose of more clearly showing other elements. Such omissions of elements in some figures are not necessarily indicative of the presence or absence of particular elements in any of the exemplary embodiments, except as may be explicitly delineated in the corresponding written description.

First referring toFIG. 1, techniques for transferring map data may be implemented in a system10. In an embodiment, the system10includes a map server12, a client device14communicatively coupled to the map server12via a network16, and a map database18communicatively coupled to the map server12. The network16may be a wide area network (WAN) such as the Internet, a local area network (LAN), or any other suitable type of a network. Depending on the embodiment, the map database18may be coupled to the map server12via the network16or via another communication link as illustrated inFIG. 1. For simplicity, only one instance of the map server12, the client device14, and the map database18is illustrated inFIG. 1. However, in other embodiments, the system10may include more than one map server12, more than one client device14, and/or more than one map database18.

The map server12may include a processor20and a computer-readable memory22that stores a map controller30in the form of computer instructions, for example, that may be executable on the processor20directly (e.g., as compiled code) or indirectly (e.g., as a script interpreted by another application executing on the processor20). The computer-readable memory22may include volatile memory to store computer instructions and data on which the computer instructions operate at runtime (e.g., Random Access Memory or RAM) and, in an embodiment, persistent memory such as a hard disk, for example. In an embodiment, the map controller30includes a dynamic feature controller32that generates vector data for various map elements and/or map features including one or more map elements that are provided as map content to the client device14. The dynamic feature controller32also may be configured to determine the difference in a vector-based description of a map image relative to another map image corresponding to the same geographic area, generate an appropriate modification indication, and provide the modification indication to the client device12. In other words, rather than providing a complete vector-based description of a map image, the dynamic feature controller32can efficiently provides a description of modifications of a previously provided vector-based description of another map image.

To generate a modification indication, the dynamic feature controller32compares a serialized representation of vector data corresponding to a certain map image to a serialized representation of vector data corresponding to another map image, according to an embodiment. For example, the dynamic feature controller32may request vector data for a basic map for a region R at zoom level Z, and, in response, the map server18may provide a series of vector descriptors V1, V2, V5, . . . VN. At another time, the dynamic feature controller32may request vector data for a transit map for the region R at zoom level Z, and the map server18in response may provide a series of vector descriptors VI, V3, . . . VL. Based on the two sets of vector descriptors, the dynamic feature controller32may determine that, for the region R at zoom level Z, (i) both the basic map and the transit map include a map element corresponding to vector descriptor V1, (ii) the basic map but not the transit map includes map elements corresponding to vector descriptors V2and V5, and (iii) the transit map but not the basic map includes a map element corresponding to vector descriptor V3. The dynamic feature controller32may generate a modification indication to indicate that in order to generate a transit map image using the vector data previously provided for rendering a basic map image, vector modifier V3is added to the previously provided vector data, while vector descriptors V2and V5are removed from the previously provided vector data. More specifically, the dynamic feature controller32may generate a modification indication that includes one or more add indications and one or more remove indications, each of which may identify an operation (e.g., add, remove) and an operand (e.g., a vector descriptor, a map feature or map element).

Further, in some embodiments, the dynamic feature controller32may determine that although a certain map element is rendered when generating both the first map image and the second map image, one or more properties of the map element must be modified to reuse the map element in rendering the second map image. For example, some or all map elements may be associated with respective depth values indicative of positioning of these map elements relative to other, partially or fully overlapping, map elements in the same area. As a more specific example, a map element that depicts a road segment and corresponds to a vector descriptor Vimay be rendered at a depth D1in a basic map image but rendered at a depth D2in a transit map image. In this scenario, dynamic feature controller32may generate a modification indication that indicates that the depth associated with vector descriptor Vi, previously provided to the client device14, should be updated to depth D2.

Still further, in addition to vector data, the dynamic feature controller32may provide label data for the added or modified map features as a part of the modification indication or, alternatively, as a separate indication. The label data may include characters in any suitable format and, in some implementations, identifiers of map features or groups of map features to which the corresponding labels belong.

In some embodiments, in addition to vector data, the map controller30may provide style data that indicates how vector data should be rendered. More particularly, style data may describe such visual characteristics or properties as line thickness (e.g., width in pixels), line color, one or more fill colors, etc. In an embodiment, style data is provided for various visual styles that may be applied to the vector data. The map server also may specify which visual styles the client device should apply to various vector-based descriptions of map elements (also referred to herein as vector descriptors or simply vectors). Further, in some embodiments, the map server indicates which visual style applies to a vector-based description of a map element for a particular map type, such as terrain, transit, traffic, bicycle trail, etc. To this end, several styles, each identified by a respective unique style identifier, may be defined.

The map controller30may provide map data for a certain geographic region and zoom level in a non-raster format, such as vector data, to the client device14in a single electronic message or a series of electronic messages, depending on the embodiment. Further, in an embodiment, the map controller30generates map data as a set of map tile descriptors, such that each map tile descriptor describes a map tile, i.e., a portion of a map image of a certain size (e.g., 256 by 256 pixels). The size of a geographic region represented by an individual map tile may depend on the zoom level with which the map tile is associated, so that a single map tile at a lower zoom level illustrates a larger geographic area than a single map tile at a higher zoom level. The map controller30may generate each map tile descriptor according to a vector graphics format, and a client device, such as the client device14ofFIG. 1, may locally generate a raster image for each tile.

With continued reference toFIG. 1, the client device14may include a processor50to execute instructions and a memory52to store instructions and data. The client device14also may include an input device54and an output device56to receive input from a user and provide output to the user, respectively. The input device54may include one or more of a keyboard, a mouse, and a touchscreen, and the output device56may include a display or monitor device such as a touchscreen or a “regular” (output-only) screen, for example. The client device14may include various software components, such as device drivers, operating system (OS) event handlers, etc. to control the input device54and the output device56so as to implement an interactive user interface. Further, software applications executing on the processor50may utilize these software components to provide an application-specific user interface.

Depending on the embodiment, the client device14may be a personal computer, such as a desktop computer, a laptop computer, or a tablet PC, a workstation, a portable communication device such as smartphone, or any other suitable computing device. In an embodiment, the client device14is a so-called thin client that depends on another computing device for certain computing and/or storage functions. For example, in one such embodiment, the memory52includes only volatile memory such as RAM, and a program and/or storage unit having persistent memory is external to the client device14. In another embodiment, the memory52includes both volatile and persistent memory components.

A browser application60may include a set of computer-readable instructions that execute on the processor50. In general, the browser application60accesses web pages that include content such as text, images, embedded video, etc. and instructions in a mark-up language such as Hypertext Markup Language (HTML), and renders the content on the output device56according to the instructions in the mark-up language. To this end, the browser application60may implement functions for generating and processing data packets that conform to the Hypertext Transfer Protocol (HTTP), parse HTML content, encode data according to the Secure Socket Layer (SSL) protocol, request and verify digital certificates, etc., as well as user interface functions for receiving various user commands related to navigation, rendering, and managing web page data. In some embodiments, the browser application60is configured to interpret instructions in a scripting language (e.g., Javascript) provided in a web page.

A dynamic map rendering engine62may execute as a component of the browser application60. However, in other embodiments, a software module similar to the map rendering engine62may execute as a standalone application or as a component of another application. Depending on the embodiment, the dynamic map rendering engine62may be a plugin (e.g., a set of compiled instructions that extends the functionality of the browser application60and executes on the processor50), a script (e.g., a set of instructions in a scripting language interpreted by the browser application60at runtime), or another suitable software component. According to one example scenario, the dynamic map rendering engine62is downloaded when a user operating the client device14visits a web page that includes an embedded interactive map. More specifically, the web page may include a first hyperlink to an online map server and a certain geographic location as well as a second hyperlink to a copy of the dynamic map rendering engine62, which is required for rendering map data received from the online map server according to the first hyperlink.

The dynamic map rendering engine62may provide interactive controls via the user interface of the browser application60, for example. The interactive controls may allow a user to select a geographic region or area, a map type (e.g., basic, traffic, transit), a zoom level, etc. According to an example scenario, user first requests a basic map of a geographic region and then requests another type of a map for the same region. The dynamic map rendering engine62may request and receive map data in a vector graphics format in response to user commands.

During operation, the dynamic map rendering engine62may receive vector data (and, in some embodiments, style data) from the map server12, render the corresponding map image using the received vector data, and cause the map image to be displayed within a certain region allocated by the browser application60. For example, the browser application60may create an HTML5 Canvas element for displaying map images. The dynamic map rendering engine62also may receive, from the map server12, a modification indication that indicates one or more modifications to the received vector data for rendering another map image.

For simplicity, the client device14is illustrated with a single processor50. However, the client device14in other embodiments may include additional processing units (not shown) such as a graphics processing unit (GPU) configured to facilitate image rendering on the output device56, for example. Further, in an embodiment, the browser application60may utilize a library of graphics functions for efficiently generating a map image. For example, the memory52may store a plugin, such as an OpenGL® or Direct3D® library, having functions for rendering graphics which various applications executing on the client14, including the browser application60, may access via an application programming interface (API). In another embodiment, the memory52stores a plugin particularly suitable for browser applications, such as WebGL, for example. Also, in some embodiments, the memory52stores additional software components that facilitate efficient rendering of images via the output device56. For example, the memory52may store an Adobe® Flash® plugin or an O3D plugin.

It is noted that in general, the dynamic map rendering engine62can operate in any suitable application. For example, a client device70may be a portable device such as a smartphone, for example, in which the dynamic map rendering engine62operates in a mapping application74. Similar to the browser application60, the mapping application74may include a set of instructions stored in a memory72and executable on one or more processors of the client device70(not shown). In some implementations, the mapping application74utilizes networking functions provided by a browser application executing on the client device70(via a corresponding browser API, for example). In another implementation, the mapping application74includes at least partial browser functionality, such as the communication stack that supports TCP, IP, HTTP, etc. to access the map server12.

Next, to better illustrate operation of a map server and a client device in the system ofFIG. 1or a similar environment, several scenarios are considered with reference to the interaction diagrams illustrated inFIGS. 2-6. In particular, an example exchange of information between a map server and a client device for rendering two map images for a certain region is discussed with reference toFIG. 2, followed by a discussion of several specific scenarios: providing a modification indication for rendering additional map elements (FIG. 3), providing a modification indication for modifying the depth at which a map feature or element is rendered (FIG. 4), providing a modification indication for removing a map feature or element included in previously provided map data (FIG. 5), and providing a modification indication for modifying a composite map feature associated with several map elements (FIG. 6).

Referring toFIG. 2, an example message exchange100involves a user interface102, included in or otherwise associated with a client device (such as the client14ofFIG. 1), a dynamic map rendering engine104operating in the client device, and a server106(such as the map server12ofFIG. 1). Referring back toFIG. 1, the user interface may be provided by the browser60, while the dynamic map rendering engine104and the server106may be implemented in the components62and12, respectively.

In response to a user command, the user interface102may generate a request110for basic map data for a certain region R1and provide the request to the dynamic map rendering engine104. The request110may be transmitted as an electronic message internal to the client device in which the components102and104are implemented, for example. The dynamic map rendering engine104in turn may generate a request112for basic map data, to be transmitted via a communication network to the server106. The request112may specify the region R1using Global Positioning Service (GPS) coordinates or in any other suitable manner. Further, the request112may include a map type indication to specify that map data is being requested for rendering a basic map. Still further, in some embodiments, the request102indicates whether any vector-based map data for the region R1is already available at the client device that implements the components102and104.

In response to the request112, the server106may generate a response114that includes map data in a non-raster format, such as in a vector graphics format, for rendering a basic map image. According to an example scenario, the response114includes a vector-based description of the basic map image for the region R1that does not rely on any previously provided vector data. In other words, the response114includes a complete description of the basic map image for the region R1. The response114may include map data that is organized in any suitable manner, such as in a one or several tile descriptors T1, T2, . . . TN. In general, map data may be provided for any number of tiles, including a single tile. For each tile, the response112may describe various features F1, F2, etc., each of which may be specified using one or several vector descriptors in accordance with a suitable vector graphics format (as indicated above, a feature may be associated with a single map element or a group of map elements). Features may correspond to simple map elements such as buildings or more complex groupings of map elements. In some embodiments, the response114may provide unique identifiers for the map features for use in future identification. The response114in some embodiments additionally includes style data that specifies various visual attributes of the map elements.

The dynamic map rendering engine104may render the basic map image, provide the basic map image to the user interface102and generate a corresponding event116, and store the received map data (and, when available, style data) in a memory for future use. In an embodiment, the dynamic map rendering engine104additionally stores an indication that the map data is associated with a basic map.

In the scenario ofFIG. 2, the user later decides to change the map type from basic to transit without changing the geographic coordinates and activates the appropriate control via the user interface102. In response, the user interface102generates a request120for transit map data and forwards the request120to the dynamic map rendering engine104, which in turn provides an indication121to the server106that a different map image is to be rendered at the client device. In an embodiment, the indication121is a request for transit map data similar to the request112. In another embodiment, the indication121specifically requests modification data for modifying the previously provided map data so as to render a transit map image.

In an embodiment, the server106provides a modification indication to the client device as a series of electronic messages1221. . .122N. In another embodiment, however, the modification indication is provided as a single message. Each of the messages1221. . .122Nmay include an indication of how vector data for the corresponding tile T1. . . TNis to be modified. In some scenarios, however, only some of the tiles T1. . . TNdescribed in the response114are modified. For example, a map tile that depicts a body of water may have the same appearance when displayed as a portion of a basic map or as a portion of a transit map.

For each tile being modified, the message122imay provide one or more modification descriptors M1, M2, . . . MM. In general, a modification descriptor may specify a vector descriptor for a map elements to be added to previously provided map data, identify a map element in the previously provided map data to be removed, specify a new value for a property of a map element in the previously provided map data, etc. In an embodiment, each of the modification descriptors M1, M2, . . . MMidentifies the operation to be performed, such as add, delete, modify, modify depth, etc., and also includes one or more operands or parameters such as a vector descriptor for a map feature or map element being added, an identifier of a map feature or map element being removed, etc.

Upon receiving the messages1221. . .122N, the dynamic map rendering engine104map render the tiles for the requested transit map image using some or all of the vector data provided in the response114and the modification indication provided in the messages1221. . .122N. More specifically, the dynamic map rendering engine104may interpret the previously provided vector descriptors, modified according to the messages1221. . .122N, to render a raster transit map image, and generate an event126to cause the transit map image to be rendered via the user interface102. The dynamic map rendering engine104may also store the modified map data in the memory. In an embodiment, the dynamic map rendering engine104stores both the originally provided map data and the modified map data as different versions of map data.

During an example message exchange150illustrated inFIG. 3, the map server106provides vector descriptors of additional map features to the dynamic map rendering engine104via respective messages1521. . .152N. The additional map features are used with some or all of previously provided map data to render a new map image at the client device that implements the user interface102and the dynamic map rendering engine104. In an embodiment, the messages1521. . .152Ndescribe additions to a certain map tile. In other embodiments, the messages1521. . .152Nare not associated with any particular tile.

Each of the messages1521. . .152Nmay include a description, in a vector graphics format or other suitable non-raster format, of a map feature having one or more map elements. A message152also may include a depth indication that specifies how the corresponding map feature is rendered relative to another map feature or element disposed at approximately the same location. For example, a new map feature added via one of the messages1521. . .152Nmay be a segment of railroad tracks, and the previously provided may include a map feature that is a segment of a road. Depending on the respective depth indications of the new map feature and the previously provided map feature, the segment of the railroad tracks may be rendered over or under the segment of the road at the point where the railroad tracks and road intersect.

Upon receiving the messages1521. . .152N, the dynamic map rendering engine104may render a new map image and generate an event156so as to cause the new map image to be displayed at the user interface102. In an embodiment, the dynamic map rendering engine104also stores the augmented map data in a memory as a new version of map data.

Referring toFIG. 4, an example message exchange200may occur when the server106determines that a certain map feature included in previously provided map data is rendered in a new map image at a new depth. The server106may generate and transmit to the dynamic map rendering engine104a modification indication202which indicates, for a map feature identified by a unique feature identifier, a new depth at which the map feature is to be rendered. In another embodiment, the modification indication202indicates new depth values for several map features or elements. Upon receiving the modification indication202, the dynamic map rendering engine104may render a new map image in view of the modification indication202and generate an event204so as to cause the new map image to be displayed at the user interface102.

Further, an example message exchange250ofFIG. 5may occur when the server106determines that a certain map feature included in previously provided map data is not rendered in a new map image. The server106may generate and transmit to the dynamic map rendering engine104a modification indication252which identifies a map feature using a unique feature identifier, for example. In another embodiment, modification indication252identifies an individual map element using an appropriate identifier of the map element. Further, in some embodiments, the modification indication252identifies several map features or elements to be removed. Upon receiving the modification indication252, the dynamic map rendering engine104may render a new map image in view of the modification indication252and generate an event254so as to cause the new map image to be displayed at the user interface102.

FIG. 6illustrates an example message exchange300during which the server106provides modification data to the dynamic map rendering engine104for modifying a composite map feature having several sub-features or elements. For example, a map feature F1may include sub-features F1-1, F1-2, F1-3, F1-4, and F1-5. When rendering the map feature F1as a part of a basic map, each of the sub-features F1-1, F1-2, F1-3, F1-4, and F1-5may be used. However, when rendering the map feature F1as a part of a transit map, the map feature F1may be rendered with only the sub-features F1-1and F1-2. In an embodiment, the server106generates a message302that indicates that the map feature F1should be removed. Similar to the example scenario discussed above with reference toFIG. 5, the message302may include a unique identifier of the map feature F1. The server106then generates messages304and306to add sub-features F1-1and F1-5, respectively. Similar to the example scenario ofFIG. 3, the messages304and306may include a description of the corresponding map features or elements in a non-raster format, such as a vector graphics format. Upon receiving the messages302,304, and306, the dynamic map rendering engine104may render a new map image with a new version of the map feature F1and generate an event310so as to cause the new map image to be displayed at the user interface102.

Next, several example methods that may be implemented in computing devices operating in the system ofFIG. 1or a similar environment are discussed with reference toFIGS. 7-9. These methods may be implemented as computer programs developed in any suitable programming language and stored on the tangible, non-transitory computer-readable medium (such as one or several hard disk drives) and executable on one or several processors. For example, the methods ofFIGS. 7 and 8may be implemented in the map server12, and the method ofFIG. 9may be implemented in the client device14. Although the methods ofFIGS. 7-9can be executed on individual computers, such as servers or personal computers (PCs), it is also possible to implement at least some of these methods in a distributed manner using several computers, e.g., in a cloud computing environment.

Referring first toFIG. 7, an example method350for generating map data for several map images may be implemented in the map controller30of the map server12or a similar component of the server106, for example. According to an embodiment, vector descriptors for rendering a first map image for a certain region are generated at block352. The vector descriptors may conform to a vector graphics format and describe respective map elements. In some embodiments, the vector descriptors may be grouped according to map features, each including one or more map elements. Further, in some embodiments, the vector descriptors may be provided as a part of non-raster map data that also includes style data for efficiently rendering and re-rendering vector data, text-based label data, icons or symbols such as road shields, etc.

Next, at block354, the vector descriptors are provided to a client device. For example, the vector descriptors may be transmitted as one or several electronic messages via a communication network such as the network16ofFIG. 1, for example.

At block356, a request for data for rendering a second map image for the same region is received. In some scenarios, the request is transmitted in response to the user selecting a different map type at the client device, as illustrated in the interaction diagram inFIG. 2, for example. A modification indication that includes a description of one or several modifications to the previously provided vector descriptors is generated at block358and provided to the client device at block360.

In another scenario, the request received at block356is transmitted in response to the user selecting a new zoom level at which the map image corresponding to the same region and the same map type is to be rendered. For example, the vector descriptors generated at block352may describe several tiles at zoom level Z1of a basic map type for a geographic region R. After the user selects the zoom level Z2and an appropriate request for data is issued at block356, a modification indication may be generated and provided to the client device at blocks358and360, respectively. The client device may add, remove, or modify the previously provided vector descriptors in accordance with the modification indication, as well as re-scale some or all of the vector descriptors to render the corresponding map elements at the zoom level Z2. As a more specific example, the vector descriptors provided at block354may include a vector-based description of a park at zoom level Z1, and the same vector-based description of the park may be used to re-render the park at zoom level Z2as a part of the modified map image.

Referring toFIG. 8, an example method400for generating a description of a modification of previously provided map data that may be implemented in the map controller30of the map server12or a similar component of the server106, for example. In an embodiment, at least some of the steps of method400are executed at blocks356-360of the method350discussed above.

At block402, an indication is received that a map image is to be updated at the client device. Additions to the previously provided vector descriptors are identified, and the corresponding descriptions are generated, at block404. At block406, deletions of some of the previously provided vector descriptors are identified, and the corresponding descriptions of modifications are generated. As discussed above, modifications of certain map features in some scenarios are represented as deletions and additions of some of the sub-features. A modification indication, such as a description of modifications to the vector data, is transmitted to the client device408at a single electronic message or several electronic messages.

FIG. 9is a flow diagram of an example method450for rendering map images that may be implemented in the dynamic map rendering engine62or104, for example. At block452, vector descriptors for a certain area or region are received, and a first map image is rendered using the received vector descriptors at block454. To this end, the received vector data may be interpreted to generate a raster image.

Next, at block456, a request to render a second map image is received from the user interface such as the interface of a browser application, for example. The second map image may be for the same region but may correspond to a different map type or zoom level, as discussed above. A modification indication, such as a description of one or more modifications to the vector descriptors received at block452, is received at block458. The second map image is then rendered using some or all of the vector descriptors received at block452and the description of modifications received at block458. As discussed above, modifications to vector data in general may include additions, deletions, modifications, changes in depth, etc.

To further illustrate an example application of the techniques discussed above,FIGS. 10A and 10Bmaps that correspond to the same geographic region and are displayed according to the basic map type and the transit map type, respectively. A map image500of a basic map, depicted inFIG. 10A, may include a rendering500of multiple map elements such as roads and parks. As illustrated inFIG. 10B, the map image of a transit map may include the map elements of the map image500as well as a subway line504superimposed on the corresponding portions of the map image500. Depending on the embodiment, the subway line504may be defined as a single map feature or several map features, each corresponding to a respective section of the tracks. Further, a subway symbol506may be rendered over a portion of the map image500. Depending on the embodiment, the subway symbol506may be provided as an added map feature or element, as a label, or as an icon, for example. In an embodiment, the subway symbol506is specified as a universal resource locator (URL) that can be used to retrieved a standard subway symbol in a raster format from a server that generates standard icons.

To generate the map image ofFIG. 10Bat a client device after the map image ofFIG. 10Ahas been rendered at the client device, a map server may provide only a modification indication that describes, in a vector format, the one or more map features corresponding to the subway line504. In an embodiment, the modification indication also provide a depth indication to cause the subway line504to appear over the roads depicted in the map image ofFIG. 10A. Further, in an embodiment, the modification indication additionally includes a description of the subway symbol506as a label or an icon.