RU2580335C1 - Method of processing map data - Google Patents

Abstract

FIELD: physics.

SUBSTANCE: method of processing map data includes: displaying a route comprising a sequence of transport segments, which is located between start and end points on a map, analysing the potential places of displaying graphical representations relating to individual transport segments within the sequence for each map zoom level, displaying the combined graphical representation of neighbouring individual transport segments together with the ordinary graphical representations of individual transport segments upon crossing potential places for displaying the graphical representations of neighbouring individual transport segments and displaying the combined graphical representation on the fragment of the said map on the said zoom level.

EFFECT: invention provides clear and easy routing planning.

16 cl, 5 dwg

Description

FIELD OF THE INVENTION

The invention relates to the field of processing cartographic data.

State of the art

It is known that when a map is displayed on the monitor of a computing device, a grouping of objects on the map (for example, places of high interest (POI)) occurs in accordance with the scale of proximity of the map. For example, Yandex API. Maps (http://api.vandex.com/maps) YANDEX LLC (Russia) offers a platform that allows applying different approaches to grouped objects on a map (http://api.vandex.ru/maps/features/?p = cluster). Such a grouping may indicate a certain number of places of increased interest at one level of approximation within a given territory, and at the next level of approximation indicate their specific location.

In US Application No. US 20120316782, publ. 12/13/2012 describes the map display at the first level of approximation and the display of the enlarged part of the map at the second level of approximation. Map magnifiers can be displayed at waypoints along a route, on map markers corresponding to places of high interest, or at places associated with search results.

In US application No. US 20130338918, publ. 12/19/2013 a route search module is described that is configured to determine the main route on the map from the start point to the end point. The route search module is additionally configured to make one or more changes on the map depending on the main route. The modification module is configured to use the main route and one or more basic modifications on the map. One or more modifications includes at least one of: a) adding a first object to the map that would not be included in the map if the main route were not applied to it, and b) removing the second object from the map that would be added to the map if the main route were not applied to it.

Disclosure of invention

The object of this technology is a method for processing cartographic data. A method for processing map data includes the following. At the first stage, providing a route containing at least one sequence of transport segments that is located between the start and end points on the map. At the second stage, the analysis of potential places for displaying graphic representations related to individual transport segments within the sequence for each level of map approximation. In a third step, providing a combined graphical representation of adjacent individual transport segments instead of the usual graphical representations of individual transport segments while intersecting potential locations to display graphical representations of neighboring individual transport segments. In a fourth step, displaying at least said combined graphical representation on a fragment of said map at said approximation level.

An embodiment is possible in which, in a first step: a route including a plurality of segments is obtained; and grouping the segments into at least one said sequence of transport segments.

An embodiment is possible in which said grouping includes providing one or more parts of a sequence within said route, and each part of the sequence refers to one type of transport, the second and third steps of the method are performed for each of the parts of the sequence.

An embodiment is possible in which each of the second third and fourth steps is performed when a user requests a change in the approximation level of the map; or when the user changes the mentioned route.

An embodiment is possible in which said graphical representations of individual transport segments preliminarily include at least a graphical component and a text component, and preferably each combined graphical presentation is based on a combination of only graphical components for said individual transport segments.

An embodiment is possible in which each combined graphical representation is based on a combination of data for said neighboring individual transport segments.

An embodiment is possible in which each combined graphical representation is based on a combination of data for said neighboring individual transport segments.

An embodiment is possible in which, within the bounds of the integrated graphical representation, an indication of the sequence of said neighboring individual transport segments within the said route is provided.

An embodiment is possible in which, at a potential intersection of said potential display of locations for graphical representations of adjacent individual transport segments, the text component is removed from at least one graphical presentation; and repeat the second stage.

An embodiment is possible in which said route includes at least one user-specified waypoint, and in which each of said start and end points and said at least one waypoint are associated with graphical representations, each of which has a potential display location , and in which the aforementioned method further performs the positioning and orientation of the aforementioned graphical representations for the said start and end points of the route and at least one waypoint to minimize intersection with places of other graphical representations of the route.

An embodiment is possible in which positioning and orientation are performed before and / or after the second and third stages.

An embodiment is possible in which additionally corresponding potential display locations for each graphical representation for said starting and ending points and at least one said waypoint are further analyzed; and at least partially reducing said graphical representation in response to a potential display location of one of said graphical representations potentially intersecting the graphical representation for any other segment on said route.

An embodiment is possible in which said route includes one or more pedestrian segments, each pedestrian segment contains a potential display location for a corresponding graphical representation, and in which further corresponding potential display locations for each said graphical representation of each pedestrian segment are further analyzed; and at least partially reducing the graphical representation of the pedestrian segment in response to the potential display location of the pedestrian segment potentially intersecting the graphical representation of any other segment along the route.

An embodiment is possible in which, with said at least partial reduction, the text component is removed from said graphic representation.

An embodiment is possible in which, at said third step, additionally combined data is provided for said neighboring individual transport segments, and in which additionally, said combined data is displayed in response to user interaction with a corresponding displayed combined graphical representation.

An embodiment is possible in which segment information is moved from one part of a sequence to another in response to user interaction with a first displayed combined graphical representation for part of a sequence of route segments and with a second combined graphical representation for an adjacent part of the sequence of at least one route segment.

An embodiment is possible in which a route can be provided in response to user interaction with the application — indicating the start and end points.

An embodiment is possible in which one or more parts of a sequence of transport segments can be represented within a route, each part of a sequence refers to the same type of transport, and analysis and integration procedures are applied to each part.

An embodiment is possible in which the method is performed in response to a user’s request to change the map’s proximity level or in response to a user determining a change in route.

An embodiment is possible in which the types of transport may include: public and private transport.

An embodiment is possible in which the route may include at least one segment indicating a public transport connection.

An embodiment is possible in which the method may further include providing pooled data for adjacent individual transport segments and, in response to user interaction with a corresponding displayed pooled graphical representation, displaying pooled data. The combined data may include either static or dynamic data.

An embodiment is possible in which the method may further include moving segment information from one part of the sequence to another in response to user interaction with the first displayed combined graphical representation for part of the sequence of segments along the route and a second graphical representation for adjacent parts of at least one segment on the route.

This technology is useful for digital map applications to provide clear and easy route planning with enhanced user interface ergonomics.

In the context of the present description, unless specifically indicated otherwise, the term “computer-supported computer information medium” means a medium of absolutely any type and nature, including RAM, ROM, disks (CDs, DVDs, diskettes, hard drives, etc.). e.), USB flash drives, solid state drives, tape drives, etc.

In the context of the present description, unless specifically indicated otherwise, “server” means a computer program running on appropriate equipment that is able to receive requests (for example, from electronic devices) over the network and to fulfill these requests or initiate the execution of these requests. The equipment may be one physical computer or one physical computer system, but neither one nor the other is mandatory for this technology. In the context of this technology, the use of the expression “server” does not mean that each task (for example, received instructions or requests) or any specific task will be received, completed or initiated to be executed by the same server (that is, by the same software software and / or hardware); this means that any number of software elements or hardware devices can be involved in the reception / transmission, execution or initiation of any request or the consequences of any request associated with the client device, and all this software and hardware can be one server or several servers , both options are included in the expression “at least one server”.

In the context of the present description, unless specifically indicated otherwise, the term "database" means any structured data set that is independent of the specific structure, database management software, hardware of the computer on which data is stored, used, or otherwise are available for use. The database may reside on the same hardware that runs the process that stores or uses the information stored in the database, or it may reside on separate hardware, such as a dedicated server or multiple servers.

In the context of the present description, unless specifically indicated otherwise, the term “component” means software (corresponding to a particular hardware context) that is necessary and sufficient to perform the specific specified (s) function (s).

In the context of the present description, unless specifically indicated otherwise, the words "first", "second", "third", etc. used in the form of adjectives solely to distinguish the nouns to which they relate from each other, and not for the purpose of describing any specific relationship between these nouns. So, for example, it should be borne in mind that the use of the terms “first server” and “third server” does not imply any ordering, chronology, hierarchy or ranking (for example) of servers / between servers, as well as their use (in itself) does not imply that a certain "second server" must exist in a given situation. Hereinafter, as indicated here in other contexts, reference to the “first” element and the “second” element does not exclude the possibility that it is one and the same actual real element. So, for example, in some cases, the “first” server and the “second” server can be the same software and / or hardware, and in other cases they can be different software and / or hardware.

In the context of the present description, unless specifically indicated otherwise, "electronic device" means a hardware device capable of working with software suitable for solving the corresponding problem. Examples of electronic devices, among others, are personal computers (desktop computers, laptops, etc.), smartphones and tablets, and satellite navigation devices. It should be borne in mind that a device behaving like an electronic device in the present context can behave like a server with respect to other electronic devices. The use of the expression “electronic device” does not exclude the possibility of using multiple electronic devices to receive / send, execute or initiate the execution of any task or request, or the consequences of any task or request, or the steps of any method described above.

Each embodiment of the present technology includes at least one of the aforementioned objectives and / or objects. It should be borne in mind that some objects of this technology, obtained as a result of attempts to achieve the aforementioned goal, can also satisfy other goals not specifically indicated here.

Those skilled in the art will understand that in the present description, the expression “receiving data” from a user means receiving by the electronic device data from the user in the form of an electronic (or other) signal. In addition, those skilled in the art will understand that displaying data to a user via a graphical user interface (e.g., an electronic device screen and the like) may include transmitting a signal to the graphical user interface, this signal contains data that can be processed, and at least a portion of this data may be displayed to the user via a graphical user interface.

Some of these steps, as well as signal transmission-reception, are well known in the art and, therefore, have been omitted in specific parts of this description for simplicity. Signals can be transmitted-received using optical means (for example, optical connection), electronic means (for example, wired or wireless connection) and mechanical means (for example, based on pressure, temperature or other suitable parameter).

Additional and / or alternative characteristics, embodiments, and advantages of embodiments of the present technology will become apparent from the following description, the accompanying drawings, and the appended claims.

Brief Description of the Drawings

Next will be described various examples of technology with reference to the relevant drawings, where:

In FIG. 1 shows a diagram of a system including a client device on which an application for processing map data is installed, the application is implemented in accordance with non-limiting embodiments of the present technology;

In FIG. 2 is a flowchart illustrating the operation of a tag operator related to the application of FIG. one; and

In FIG. 3-5 shows an approximate set of overlays that can occur at different levels of approximation of a particular part of the map.

The implementation of the invention

In FIG. 1 shows a system including an electronic device 100 and a server 140. It is important to bear in mind that the system is only one embodiment of the present technology. Thus, the entire following description is presented only as a description of an illustrative example of the present technology. This description is not intended to determine the scope or scope of this technology. Some useful examples of system modifications may also be covered by the following description.

The purpose of the description is also solely an aid to understanding, and not a determination of the scope and boundaries of the present technology. These embodiments are not an exhaustive list, and those skilled in the art will appreciate that other options are possible. Furthermore, this should not be interpreted so that where no embodiments have been set forth, no other embodiments are possible, and / or something that is described is the only embodiment of this element of the present technology. As will be clear to a person skilled in the art, this is most likely not the case. In addition, it should be borne in mind that the system is in some specific manifestations a fairly simple embodiment of the present technology, and in such a case is presented here in order to facilitate understanding. As will be clear to a person skilled in the art, many embodiments of the present technology will have much greater complexity.

The client electronic device 100 includes a screen 120 for processing information from the application 130, at least part of which includes a card 105. In the example of FIG. 1, an application 130 is a client application that communicates with a server 140 via a network 150, such as the Internet. One type of client application is a browser application that communicates with server 140 via an application programming interface (API) 160, for example, the Yandex.Maps API mentioned above. Typically, server 140 includes access to a map database (not shown) in order to provide the map or route with requests from application 130 via API 160.

A general embodiment of the device 100 is known in the art and therefore will not be described in detail here. Suffice it to say that the electronic device 100 comprises a user input interface (not shown in the drawings), such as a keyboard, mouse, touch panel, touch screen, etc.) for receiving user input. The aforementioned screen 120 (e.g., screen, touch screen, printer, etc.) for providing visual or audio output to a user; a network communication interface (not shown) (for example, a modem, network card, etc.) for two-way communication over a data network 150; and a processor (not shown) connected to an input user interface, an output user interface, and a network communication interface that is configured to perform various operations, including those described below. To this end, the processor may store or have access to computer-readable instructions, the execution of which initiates the processor to perform the various procedures described herein.

When an application, such as application 130, requests a map through API 160, for example, by specifying the required location on the map and the level or zoom level, a map object element is created and any part of it can be processed by application 130 on screen 120, for example, as in the case of a variant of the portion of the card 105 shown in FIG. one.

As with ordinary map data (which can be considered as “mother card objects”) that can be requested and processed by application 130 on screen 120, various daughter card objects can be added to the mother card object to expand the map display and, for example, enabling interaction with the end user of the electronic device 100.

An example of such a child entity is also referred to as a “geographical entity”. Such objects usually have two features: graphical geometry and meta-data. The geometry can be of various types, for example, graphic, point, linear, multilinear (a line consisting of several segments), polygonal, and so on, and, as a rule, it determines how the object will be graphically represented on screen 120. For example, a geographic object for the street can be linear or multilinear geometric data that can be used to overlap or overlap the corresponding line on the overlapping map image (which can be created from other geographic their objects). The geographic object for creation may contain polygonal data that can be used to superimpose the contour of the building on the overlapping map image.

A geographic feature may also include a simple label, for example, the Starbucks Cafe label may have point geometry and data that includes hours of operation, address, type of property, and so on. This allows the application 130 to potentially show a point on the map along with text data, for example: cafe, open daily and around the clock, address and so on.

In the present example, the graphical representation for the child of the map that will be shown on the map is considered to be an “overlay” of the object (Overlay of any geographical object can be implemented as a child of the geographical object itself or as a feature of a geographical object). An overlay for an object can include any combination of text or graphics for the object, or an overlay for the object can be marked as hidden if it should not be displayed for any reason. Data to be included in the overlay of a geographic feature may be static and permanently associated with the geographic feature, such as the address or street name; or the information may be dynamic and come from data sources, for example: the departure time of a geographic feature, such as a bus or rail segment, or an urgent message to the road segment.

In FIG. 1, overlay 110 for a point feature has been added to display on a part of the map, and this overlay 110 includes a graphic point and text indicating the name of the city.

There may be several classes of overlays available for each type of geographic feature, for example, marks for landmarks or points of start and end of a route may be accompanied by distinctive graphic overlays, and waypoints along the route may be indicated by other graphic overlays. The overlay for any geographic feature may vary depending on the zoom level of the map.

The map and its overlays can be provided to application 130 in the form of, for example, hypertext markup language (HTML) or scalable vector drawing (SVG) for processing in application 130. It should be noted that any suitable format can be used.

One component of the mapping API 160 is the router API 165. It allows an application to request a route from a start point to an end point through one or more waypoints.

Router API 165 can output a route object that includes an ordered sequence of geographic objects connecting an object that corresponds to a starting point with an object that corresponds to an end point through a series of segment and route objects.

A route can include various types of transport, including walking and various types of non-pedestrian transport — public or private — and each segment is associated with a particular type of transport. The “pedestrian segment” may include multilinear data for the street or part of the route that you must pass, as well as meta-data, including the name of the street, the length, time required to complete the street, and so on. The “transport segment” can again include multilinear data, as well as details about the buses, trams, metro or even ferries that serve this part of the route. In alternative embodiments of the technology, the transport segment may correspond to a road segment of a route that includes several segments on different roads. Other geographic features that are included in the itinerary may include marks indicating a change in the subway or tram.

It is worth noting that it is necessary to perform overlay processing for the route in order to ensure convenient display of information to the user without cluttering the screen and without overlapping map data. It is necessary to carry out this carefully, as well as adapt it taking into account changes in the level of proximity of the map and user interaction with the map. If at a lower level of approximation the user can be provided with more useful information, then there will be no need to zoom in on the map, which may lead to loss of the general context of the route. Similarly, the user can interact with the displayed route, for example, by moving, adding or deleting waypoints, which may require a convenient and smart reorganization of the map display, providing the user with a similar option.

In the present example, the mapping API 160 includes a tag operator 170. The tag operator 170 provides the ability to control the displayed information for places and waypoints along the route, as well as information for segments, including pedestrian and transport segments of the route.

In general, the tag operator 170 controls the following:

1. The presence of overlapping important text labels for points and segments along the route.

2. The position and orientation of the overlay text and / or graphics that relate to the waypoint or segment. For example, the first point of the route may be located to the left of the second point. In this case, the overlay for the first point can be located to the left of the first point, and the overlay for the second point can be located to the right of the second point, so as not to interfere with the display of the route between the points. More complex scenarios are naturally possible, and the operation of the tag operator 170 for such scenarios will be explained in more detail below.

3. Combining information in an overlay for a sequence of transport segments within a single route.

It should also be noted that at any given moment there may be several routes associated with a particular part of the map. The tag operator 170 may take into account the requirements for displaying information for the respective routes relative to each other in determining these characteristics, which will be described in more detail below.

In FIG. 2 is a flowchart illustrating processing performed by an example tag operator 170.

The tag operator 170 operates when at least one route has been requested by the application 130, and the route has been received from the server application 140 through the router API 165. A tag operator 170 may be associated with each route displayed on the map, or a tag operator 170 may process the displayed information for all routes within a specific area on the map.

At step 200, the tag operator 170 responds either to a request from the user to change the map's proximity level or to a request from the user to change the route, for example, when adding, moving or changing the position of the start and end points of the route or waypoints along it was completed.

Based on the description below, it will be clear that when changing the route or level of approximation, significant changes in overlays for the geographical features of the route may be required. The tag operator 170 in this example completely updates the overlays for the route each time it is accessed, and accordingly, the tag operator 170 is not accessed at the time the route was created, but only at the moment when the user explicitly requests changes in the proximity level or confirms route updates . In the present example, this reduces the load on the server 140 processing API requests from many potential client applications (only one is shown), however, it should be noted that in cases where the processing capability is available or, for example, in other separate embodiments, the call to The operator of 170 tags occurs continuously as the route changes.

At step 210, the tag operator 170 restores the initial overlay state for the route. Thus, if the information for the sequence of segments was combined in the previous iteration by the tag operator 170, then, as described below in step 240, such combined overlays will be deleted. Any text labels for segments that were hidden in the previous iteration by the tag operator 170, as described below in steps 230, 240, and 260, will be flagged to become potentially visible.

At step 220, the tag operator 170 determines the corresponding position and orientation for each overlay associated with the waypoint (including the start and end points), relative to the position of the waypoint. For example, if the waypoint on the route is located to the right of the previous waypoint, the overlay for the previous waypoint can be located to the left of the previous waypoint, while the overlay for the next waypoint will ideally be located to the right of the waypoint location to provide the best possible display route between two points. Nevertheless, in those places where the route turns, or where it is necessary to take into account other overlays, the criterion for positioning and orienting overlays corresponding to the location of waypoints will become more complicated.

In the present example, for each overlay for waypoints (including the start and end points), the tag operator 170 checks each possible position and orientation to determine the amount of overlays at the intersection with existing overlays of other geographical features on the route and any other routes or other overlays associated with from map fragments. Positioning and orientation provide the smallest number of intersections selected for overlapping waypoints. To begin with, it should be noted that the overlay for waypoints includes graphic and text components. The decision as to whether to save the text component will be made later at step 260, and yet in the present example, at least for a specific route, the graphic component for the waypoint is always displayed and it is given priority over other overlays, i.e. e. waypoints are always displayed as far as possible.

In FIG. 3-5, as can be seen in this case, the overlay of the waypoint for the starting point A (19 Admiral Lazarev Street) is located under its graphic component, indicating the location of the starting point. In FIG. 3, the imposition of waypoint B (Leo Tolstoy Street 16) is first located to the right of the location of the waypoint, but as the user increases the level of approximation in FIG. 4 and FIG. 5, the overlay moves under the location of the waypoint. The overlay for end point C (6 Oboronnaya Street) is first located above the point, and then moves under the point and to the position to the right of it as the user increases the level of approximation in FIG. 4 and FIG. 5.

At step 230 (FIG. 2), the tag operator 170 determines the extent to which it is important to display overlays for pedestrian segments. For each pedestrian segment on the route, the tag operator 170 determines the intersections of the overlays of the pedestrian segments with other overlays on the route, as well as possible other routes associated with the map fragment. If there are such intersections, then any text component for the pedestrian route is marked as hidden, removed or minimized from the overlay, and the tag operator 170 then recalculates the area for the intersection with the same overlay, the intersection with which was determined. If the intersection area is zero, the remaining text is collapsed, and the tag operator 170 continues to determine the remaining overlays. If there is an intersection or there is an intersection with subsequent overlays (despite the fact that the text was hidden / deleted / collapsed), the overlay for the pedestrian segment is marked as completely hidden.

On the route shown in FIG. 3-5, there are pedestrian segments between start point A and the first transport segment (metro Admiral Ushakov Boulevard) and between the last transport segment (metro Babushkinskaya) and end point C. It should be noted that due to the potential intersection between overlays for geographical features , including start and end points, as well as first and last transport segments, respectively, text components for overlapping pedestrian segments are not shown in FIG. 3-5. On the other hand, if the user increases the zoom level relative to that shown in FIG. 5, it is possible that street names for these pedestrian segments will be displayed.

At step 240 (FIG. 2), the tag operator 170 analyzes the overlays for the sequences of the transport segments to determine if they should be displayed, and if a potential combination of these overlays is necessary so that information for part of the sequence of transport segments can be simultaneously displayed to some extent at a specific level approximations, instead of, for example, transport segment information taking precedence over another.

If route objects are not grouped in a sequence along the route, for example, via router API 165, then the tag operator 170 first groups at least the transport segments for the route, step 242. This can be done by matching the start and end points of the segments with other segments and waypoints or using any other suitable means. In the embodiments of FIG. 3-5, transport segments begin at the following points: Metro Admiral Ushakov Boulevard and Dmitry Donskoy Boulevard Metro, and end at Turgenevskaya Metro and Babushkinskaya Metro. Two intermediate transport segments associated with the subway are also shown, the text of which is not shown in FIG. 3-5.

In this case, the transport segments are a single sequence. If the transport segments, however, are separated by pedestrian segments or transport segments of another type, then parts of the sequences of transport segments of the same type will be analyzed separately, as described below.

In the examples of FIG. 3-5, the tag operator 170 starts from the first transport segment in the sequence and, by default, has an overlay that includes graphic and text components, i.e. symbol of the metro and Admiral Ushakov Boulevard, the 170 tag operator checks for intersections with the overlay on the next transport segment, i.e. symbol of the metro and Dmitry Donskoy Boulevard, step 243. At the approximation levels shown in FIG. 3-4, these overlays will intersect.

If there is an intersection, the tag operator 170 checks if the current overlay is a merged overlay, step 249. If the current overlay is not merged, then the tag operator 170 collapses the text component of the overlay, step 244, and again checks for overlays with the overlay for the next transport segment, step 245.

If there is no intersection, for example, when the text component for the third transport segment is deleted at the approximation level shown in FIG. 4, this helps to avoid overlapping with other overlays, including overlays for the fourth transport segment, and the tag operator 170 proceeds to process the next transport segment, step 246, and repeats the above steps.

On the other hand, if only the graphic overlay of the transport segment overlaps with the overlay of the next segment, the tag operator 170 creates a combined overlay for the two transport segments and marks the overlay for the individual transport segments as hidden, step 247. The combined overlay can be based on any combination of data for adjacent individual transport segments that have been combined to provide a combined overlay, and in the present example, the combined overlay includes ebya only graphics components of the original transport segments. The tag operator 170 then creates the merged overlay, step 248, and continues to check the merged overlay with the next transport segment at the next iteration in step 243.

In the example of FIG. 3, in the second iteration, at step 243, the overlay of the third metro segment can be fixed as intersecting with the combined overlay for the first and second transport segments, and the graphic component of the third transport segment is combined with the combined overlay for the first and second transport segments, and an individual overlay for the third transport the segment is marked as hidden in the second iteration of step 247.

On the other hand, at the approximation level shown in FIG. 3, in the second iteration of step 243, the individual overlay for the third transport segment does not intersect with the combined overlay for the first and second transport segments, and accordingly, the tag operator 170 moves from combined overlay for the first and second transport segments to the analysis of whether to combine overlay for the third segment with the overlay of the next transport segment.

At the approximation level shown in FIG. 3, in the third iteration, at step 243, the overlay for the fourth transport segment (including graphics and text) will not intersect the combined overlays for the first, second and third segments, and accordingly, the tag operator 170 analyzes the potential intersection between the fourth transport segment and the fifth transport segment of the Turgenevskaya metro .

Nevertheless, in this case, regardless of whether the text component of the fourth transport segment is deleted, its overlay will overlap the overlay for the fifth transport segment of the Turgenevskaya metro station, and accordingly, at step 247, a second combined overlay for these transport segments appears, and individual overlays for these segments become hidden.

The processes in steps 242 and 249 continue to the last transport segment in the sequence and their last sequence in the route. As will be seen in the examples in FIG. 3-5, at the minimum approximation level in FIG. 3, two combined overlays were created from transport segments 1-3 and 4-6, respectively. On the other hand, at an intermediate level of approximation in FIG. 4 combined overlays are created from the first and second and from the fourth and fifth transport segments, respectively, but it should be noted that the sixth transport segment does not intersect with other overlays of the transport segments, its individual overlay is displayed with the graphics and the text "Metro Babushkinskaya".

Merged Overlay Position for FIG. 3 and 4 can be calculated as the point closest to the center position of the transport segments for the combined overlay.

It should also be noted that it is possible to analyze whether it is possible to avoid the intersection of neighboring overlay positions for any transport segment - regardless of whether the text is minimized or not at steps 243 and 245 - with an overlay for other transport segments of the route, thereby eliminating the need to combine overlays .

It should be noted that there are various ways to display merged overlays for transport segments. In the examples shown in FIG. 3 and 4, graphics are displayed in line format in each combined overlay. However, other options are possible.

It should be noted that in the examples shown in FIG. 3 and 4, the combined overlays indicate the sequence of components of the individual transport segments that have been combined into the combined overlays by displaying the graphs of the components of the transport segments from left to right in the combined overlays. Other known methods may be used to provide this indication.

An embodiment is possible in which any data from individual transport segments can be combined to create combined overlays, including text, raster or vector graphic data from individual transport segments. It is also worth noting that in the present example, the data is static (including only metro symbols) and accordingly the combined overlay is also static, but the combined overlay can be dynamically updated by marking the combined overlay as an interceptor of the corresponding data streams that are associated with individual transport segments, which were combined into a combined overlay. Thus, for example, a merged overlay can change color if there are problems with the subway line.

In any case, as will be seen later, the overlays for the combined transport segments will be located graphically on the z plane under the waypoints A, B, C, and thus, even if they intersect to some extent, and this can be optimized, the overlays for waypoints can be displayed on top of overlays of transport segments.

After determining all the overlays of the transport segments, and since the unification of the overlays of the transport segments can create hidden and moved overlays, at step 250, the tag operator 170 again analyzes the position and orientation of the waypoints, as described at step 220.

Finally, at step 260, the tag operator 170 checks whether the text component of the overlay for waypoints intersects with other overlays. The overlay for each waypoint is checked for intersections with other overlays, including merged overlays from step 240. If there is an intersection with another overlay, the tag operator 170 collapses the overlay text of the waypoint and recalculates the intersection area with the other overlay. If the intersection area has become smaller, the text for overlaying the waypoint remains collapsed. If not, the text component for the waypoint overlay is positioned in such a way that there will be no benefit from collapsing the text part of the waypoint overlay.

It will be seen below that overlay processing for several routes displayed on the same map fragment can occur in several different ways. If one route has priority over others, for example, if it was previously selected by the user as the preferred one, then overlays for this route will be given priority in displaying over overlays for other routes.

One way to manage multiple routes is to work with the tag operator 170 for each route, and each tag operator 170 knows the priority or advantage of its route over other tag operators 170. Each tag operator 170 may accordingly arrange the overlays of its routes on sequences in z-planes in order of increasing priority.

In an alternative embodiment, overlays for the respective routes may be displayed in a transparent form, and the degree of transparency will be inversely proportional to their priority level.

In an alternative embodiment, a single tag manager 170 may be responsible for overlays for multiple routes, while taking into account the advantages and priority of one route over others in the steps above.

In any case, at step 270, after determining all overlays for all routes for a given map fragment, as described, the application can re-process the overlays and / or part of the map, as in the examples in FIG. 3-5.

It will be seen that the approach described above offers a map display option on which the displayed overlays for geographic features at any zoom level can include any combination of hidden, graphic, and / or text components that are combined with overlays for other geographic features into combined overlay. This is done to ensure that the user is provided with the optimal amount of information at any level of proximity, and to eliminate the need for the user to further zoom in or out in order to understand the route context and obtain the necessary information about the route segments.

In the case of combined overlays for transport segments, their data can be combined in such a way that, for example, when you hover over a user or click on a combined overlay, more detailed information related to the sequence of transport segments is displayed.

Again, the detailed information may be static (for example, a list of bus routes or timetables), but also the detailed information for the combined overlays can be dynamically updated by marking the combined overlay as an interceptor of the corresponding data streams that are associated with individual transport segments and which were combined into a combined overlay. Thus, for example, a detailed display of the combined overlay may include the nearest bus or metro or emergency information.

To clarify the example described above, a user may obtain one set of information related to various combinations of transport segments that were originally calculated in accordance with step 240.

In this refinement, any merged overlays for the corresponding sequences of transport segments are made in response to user interaction, thus, for example, if a user first clicks on a merged overlay and drags it to the target merged overlay for an adjacent sequence of transport segments, the transport segment that is associated with the first pressed merged overlay adjacent to the target merged overlay will be moved from the first pressed overlay to the target united overlay.

Thus, for example, in the case of FIG. 3, if the user clicked on the combined overlay for the first, second and third transport segments and drags it onto the combined overlay for the fourth, fifth and sixth transport segments, then the information for the third transport segment will be moved to the combined overlay for the third, fourth, fifth and sixth transport segments. Now, if the user hovers over the second merged overlay, he can get more detailed information about the third, fourth, fifth and sixth transport segments in one click. Users can copy and use this information in other places.

Other ways to use the user interface, other than the click and drag mechanics, may include simply clicking on the combined overlay and clicking with the Ctrl key held down or double clicking on the target overlay, or in the case of the touch screen, using appropriate gestures, indicating the intent of the user.

It is also clear that when using this method, the user can select an overlay for a single transport segment and drag it into a neighboring combined overlay. For example, in FIG. 4, the user can select an overlay for the third transport segment and drag it into the combined overlay for the fourth and fifth transport segments.

In fact, overlays for individual transport segments, as well as any segments of FIG. 5 can be combined manually using this method; or in some cases, the combined overlays may be disconnected back to a certain extent.

In any case, this function is usually available in cases where the combined investments belong to the same type of transport segment.

It should be noted that the above description of the present technology supports the sequential grouping of geographical objects within a route, which may include heterogeneous parts of a sequence of transport segments.

Usually, when reducing the approximation level of a part of the map, some of the information about transport segments is omitted.

The above example has been described in terms of a general purpose device 100 on which a client application 130 is running, but the present technology can nevertheless be implemented in a large number of other ways, including a standalone application or specific devices, for example satellite navigation devices.

The technology has also been described in terms of object-oriented implementation, however, it should be noted that any other suitable programming method can be used to implement the technology.

Modifications and improvements to the above-described embodiments of the present technology will be apparent to those skilled in the art. The preceding description is provided as an example only and is not subject to any restrictions. Thus, the scope of the present technology is limited only by the scope of the attached claims.

Claims (16)

1. A method of processing cartographic data, including:
at the first stage, provide a route containing at least one sequence of transport segments located between the start and end points on the map;
at the second stage, potential places for displaying graphic representations related to transport segments within the sequence for each level of map approximation are analyzed;
in a third step, a combined graphical representation of adjacent transport segments is provided instead of graphical representations of transport segments when crossing potential locations to display graphical representations of neighboring transport segments, and
in a fourth step, at least said combined graphical representation is displayed on a fragment of said map at said approximation level. 2. The method according to p. 1, in which at the first stage: receive a route that includes many segments; and grouping the segments into at least one said sequence of transport segments. 3. The method according to claim 2, in which, when said grouping is performed, one or more parts of the sequence are provided within the said route, each part of the sequence refers to one type of transport, the second and third steps of the method are performed for each of the parts of the sequence. 4. The method according to p. 1, in which each of the second, third and fourth stages is performed when the user requests to change the level of approximation of the map; or when the user changes the mentioned route. 5. The method of claim 1, wherein said graphical representations of the transport segments preliminarily include at least a graphical component and a text component, and preferably each combined graphical representation is based on a combination of only graphical components for said transport segments. 6. The method of claim 1, wherein each combined graphical representation is based on a combination of data for said neighboring transport segments. 7. The method of claim 5, wherein each combined graphical representation is based on a combination of data for said neighboring transport segments. 8. The method according to p. 1, in which within the framework of the aforementioned integrated graphical representation provide an indication of the sequence of said neighboring transport segments within the said route. 9. The method according to claim 5, in which at a potential intersection of said potential display of locations for graphical representations of adjacent transport segments, the text component is removed from at least one graphical presentation and the second step is repeated. 10. The method of claim 1, wherein said route includes at least one user-specified waypoint, and in which each of said start and end points and said at least one waypoint are associated with graphical representations , each of which has a potential display location, and in which further the positioning and orientation of the aforementioned graphical representation are performed for said starting and ending points of the route and said at least one route points to minimize the intersection with places other graphic representations of the route. 11. The method according to p. 10, in which the positioning and orientation are performed before and / or after the second and third stages. 12. The method of claim 10, further comprising analyzing the respective potential display locations for each graphical representation for said starting and ending points and at least one said waypoint; and at least partially reducing said graphical representation in response to a potential display location of one of said graphical representations potentially intersecting the graphical representation for any other segment on said route. 13. The method according to claim 1, wherein said route includes one or more pedestrian segments, each pedestrian segment contains a potential display location for a corresponding graphical representation, and in which further, the corresponding potential display locations for each said graphical representation of each pedestrian segment are further analyzed ; and at least partially reducing the graphical representation of the pedestrian segment in response to the potential display location of the pedestrian segment potentially intersecting the graphical representation of any other segment along the route. 14. The method according to any one of paragraphs. 12-13, wherein in said at least partial reduction, the text component is removed from said graphical representation. 15. The method of claim 1, wherein said third step further provides combined data for said neighboring transport segments, and wherein further said combined data is displayed in response to user interaction with a corresponding displayed combined graphical representation. 16. The method of claim 1, wherein the segment information is moved from one part of the sequence to another in response to user interaction with the first displayed combined graphical representation for part of the sequence of route segments and with the second combined graphical representation for the adjacent part of the sequence, at least at least one route segment.

Images