JP2012242183A - Side-trip search device, method and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To enable a user to make a request for a search satisfying a time constraint of the user and to set a schedule including a waiting time.SOLUTION: A side-trip search device is configured to: acquire category information including a departure point, an arrival point, a side-trip point, and a user-specified time condition from the user; acquire side-trip points consistent with the category information by referring to a graph database; exclude a side-trip point, among the side trip points, inconsistent with information and a service time condition specified by the user; generate, with respect to the side-trip point which is not excluded, a schedule which satisfies the user-specified time condition and includes a departure time at the departure point, an arrival time at the side-trip point, a visit duration thereat, an ending time of a visit thereat, the departure time thereat, the arrival time at the arrival point and a waiting time; and search for a route which enables the user to receive a service at the side-trip point and takes a minimum required time in total from the departure point to the arrival point via the side-trip point.

Description

  The present invention relates to a detour search device, method and program, and in particular, in a search service on the Internet such as traffic and gourmet, a navigation system such as a car navigation system, a plan creation support such as a travel schedule creation support, etc. The present invention relates to a detour search apparatus, method, and program for searching for the shortest path among paths passing through.

  As techniques for obtaining the shortest path in a graph, graph search techniques such as Dijkstra method and A * method have been established (for example, see Non-Patent Document 1). These techniques are methods for obtaining a “shortest” route that minimizes the total cost in a graph in which a movement cost between nodes (eg, required time) is given. This technology is used in a service for searching for a desired route from a railway network or a road network.

  On the other hand, there is a recommendation service that recommends a place to be visited to the user according to the user's wishes or preferences. There are the following two typical technologies for recommendation services.

・ Recommendation of gourmet information using location information;
・ Recommendation of shops and services near the route when searching for routes;
The former is a technique in which a user has a mobile phone with a GPS function, a smartphone, and the like, and recommends a store in accordance with the user's desires and preferences from its location information.

  The latter is a technique for displaying a gas station, a fast food restaurant, or the like along a route when the route to the destination is searched by a car navigation system or the like.

  As a means for accumulating / retrieving graph information, a graph database has been proposed (see, for example, Non-Patent Document 2).

  There are the following requirements related to the above technology, but with slightly different purposes. For example, when a user makes a business trip somewhere, it is not always the shortest route, and it may be a little detour, so there is a request that the user wants to reach his destination after having his favorite lunch on the route. A search that satisfies this requirement will be referred to as a “detour search”. The waypoints that pass through this time are called POI (Point Of Interest). It is assumed that the user does not specify a specific POI directly, but specifies a category of a place where he / she wants to go, such as “I want to eat sushi” or “I want to go to the bank”. If a specific POI is determined in advance, two routes of the starting point-POI / POI-arrival point may be obtained by the shortest path search method, so that it can be technically solved by the existing technology. However, in the detour search, it is necessary to find a route that is as close as possible to the shortest route while searching for a POI that is not known in advance. For the detour search, a search method based on the Dijkstra method has been proposed.

  A specific approach for searching for a detour will be described below.

  FIG. 1 shows a flowchart of the entire process of the conventional sidewalk search and system, and FIG. 2 shows a flowchart of the process of the conventional POI check function.

  FIG. 2 is a flow in “Check if the node determined on the S side (E side) is POI” in S5 and S6 of FIG. The flows on the S side and E side are shared.

  The basic concept of the flow of FIGS. 1 and 2 is as follows.

-The Dijkstra method is executed from both the departure point side (S side) and the arrival point side (E side);
Start from the S side and E side respectively, and when the POI is reached, register the route to the node in the candidate table;
If there is a route that reaches the same POI from the S side / E side in the candidate table, it is registered in the result table;
・ Repeat the above until the end condition is satisfied.

  The result table is sorted by the total cost (= cost from the S side + cost from the E side). By predetermining the number of elements included in the result table as k, and finally returning the k results, the top k detour search results with the lowest cost can be returned.

  The search termination condition may be terminated when the end code is fixed (cost is determined) when searching for the shortest path by the Dijkstra method, but in the case of a detour search, the determination method cannot be used. In the case of a detour search, it is determined as follows.

  End when k solutions are already obtained and the following conditions are satisfied on both the S side and the E side (a route with a lower cost cannot be obtained).

Condition: Maximum cost of result table ≦ Minimum cost of candidate table + cost of current node. Under the above condition alone, when k solutions are not found, the solution is not completed and searched for a solution. Therefore, an upper limit is set with a realistic value of cost (for example, a route within 180 minutes is obtained) as an end condition.

  The processing of FIG. 2 will be described below.

  Step 101) It is determined whether or not the category of the node matches the category specified by the user. If the category does not match, the process ends.

  Step 102) If the categories match, determine whether the route from the opposite side (S side if E side, E side if S side) to the node is already registered in the candidate table, and register If it has been registered, the process proceeds to step 103. If it is not registered, the process proceeds to step 105.

  Step 103) The route from the opposite side to the route to the node is registered as a set in the result table.

  Step 104) The result table is sorted by cost, and the process ends.

  Step 105) If the node is not registered in the candidate table, the node is registered in the candidate table, and the process is terminated.

Takeo Igarashi “Data Structure and Algorithm” (Mathematical Engineering, 2007). Neo4j http://now4j.org/

  In the above detour search, when detouring, there is no point if the detour store is not open. The opening time of the store is limited as from 12:00 to 22:00. I would like you to drop by a store that satisfies this restriction. For example, when leaving late at night, it is necessary to detour as close as possible from the departure point in time before closing. This is not only the opening time but also the same issue as the request to visit the store during time-limited time sales such as “12:00 to 13:00, 2 discounts for lunch” and “After 17:00, 3 discounts before closing” It can be said. Such a side trip search having a time constraint is called “time sale side trip search”. In the above, POI time constraints such as opening hours were taken as an example, but for users such as "I want to relax at the store for 2 hours" or "I just need to be close in time because I'll drop money at the bank" There are also search requests that satisfy various restrictions, and a search that satisfies these restrictions is also called “time sale detour search”.

  In the time sale detour search, the procedure and conditions for checking the basic time constraints become an issue. In ordinary sidewalk search, the total time required is simply to add the time required from the starting point to the POI and the time required from the POI to the arrival point. Service effective. Even if you arrive at POI 5 minutes earlier than the start of the service, the total required time may be small if you include the waiting time. Thus, it becomes a problem to be able to propose an entire schedule including waiting.

  The conventional method of detour search is based on the Dijkstra method, but the Dijkstra method has greedy features and expands all nearby nodes. Therefore, in the conventional approach search method, the divergence of the search is suppressed by constraining the total required time in advance. This increase in search range and unnatural restrictions are challenges in applying to large and complex networks. In the time sale detour search, there is a possibility that the search range may be narrowed using time constraints. In the Dijkstra method, a numerical value given to an edge corresponding to a required time is often called a cost (meaning wider than the required time), and hence the required time may be called a cost in the future.

  The present invention has been made in view of the above points, and provides a detour search apparatus, method, and program capable of responding to a search request that satisfies time constraints for a user and capable of scheduling including waiting time. The purpose is to provide.

In order to solve the above-mentioned problem, the present invention (Claim 1) is a detour search device for obtaining a shortest detour in a graph,
Implemented on nodes, node information with node ID, name, category information, graph information consisting of edge information with relationship between nodes represented by a pair of two node IDs and travel time between the nodes, and node information A graph database that stores the service start and end times and service details;
Category information including departure point, destination point, and waypoint specified by the user, maximum and minimum values of departure time at the departure point, maximum value and minimum value of stay time at the waypoint, and the waypoint User interface means for acquiring user specified time conditions including maximum and minimum values of arrival time at the destination, maximum and minimum values of departure time at the waypoint, and maximum and minimum values of arrival time at the destination When,
POI (Point Of Interest) check means for obtaining a waypoint that matches the category information input by the user interface means with reference to the graph database;
Among the via points acquired by the POI check means, user service condition check means for excluding via points that do not match the service time condition with the information specified by the user;
For via points that are not excluded by the user service condition check means, satisfy the user specified time condition, departure point departure time, via point arrival time, via point stay time, via point stay end time, via point departure time, arrival point A schedule including a point arrival time and a waiting time is generated, a service is received at the waypoint, and a route from the departure point to the destination point via the waypoint is searched with a minimum required time as a whole. An overall schedule calculation means;
Have

  In addition, the present invention (Claim 2) further includes a search restriction unit that excludes from the processing points a route point that does not match the condition specified by the user before the execution of the POI check unit.

  According to the present invention, it is possible to realize a navigation service that responds to a detour request requested by a user. It enables services such as finding a route through your favorite store or finding a route in time for the ATM's end time. Further, the search range can be limited and the response time can be improved by the effect of the search restriction. However, the limitation of the search range depends on user-specified conditions. For example, when the user specifies a very loose condition (the extreme example is to receive a service at any time), the effect of limiting the search range is lost. However, when the time is limited, such as lunch time or banquet time, for example, the search range for going is roughly limited to the range from the scheduled start time to the start of the banquet, and random search is suppressed. There is.

It is a flowchart of the conventional detour search device. It is a flowchart of the POI check function in the conventional detour search device. It is a lineblock diagram of a detour search device in one embodiment of the present invention. It is a flowchart (scheme 1) of the time sale detour search in one embodiment of the present invention. It is a flowchart of the matching process of the user condition and the service condition in an embodiment of the present invention. It is an example of POI stay start / end and a service condition constraint check in an embodiment of the present invention. It is an example of restriction check of POI stay time in an embodiment of the present invention. It is an example of a constraint check of cost information and POI stay start / end conditions in an embodiment of the present invention. It is a determination image of the individual value in the example of strategy of one embodiment of the present invention. It is an example of determination of the individual value in the example of strategy of one embodiment of the present invention. It is an image of the preparation phase in one embodiment of this invention. It is a determination image of the time in the strategy to start immediately of one embodiment of this invention. It is a flowchart (scheme 2) of the time sale detour search in one embodiment of this invention. It is a flowchart of detailed operation | movement of S406 of the time sale detour search of the system 2 in one embodiment of this invention. It is a detailed flowchart of S404 of FIG. 13 in one embodiment of this invention. It is an image of conditions 1-4 in one embodiment of the present invention. It is an example of the graph of one Example of this invention. It is an example of the graph database of one Example of this invention. It is an image of the cost table of the departure road side of one Example of this invention. It is an image of the cost table by the side of the arrival path of one Example of this invention. It is an example of the candidate table and result table of one Example of this invention. It is an example of designation | designated of the value in the time sale detour search of one Example of this invention. It is an example of the cost information of one Example of this invention, and the check of a POI stay start / end case. It is an individual value determination phase when calculating | requiring the whole cost of one Example of this invention. It is the determined individual value of one Example of this invention. It is an image of the adjustment phase of one Example of this invention.

  Embodiments of the present invention will be described below with reference to the drawings.

  FIG. 3 shows a configuration of a detour search device according to an embodiment of the present invention.

  The detour search device shown in the figure includes a cost table 101, a graph database 102, a user interface unit 105, a search control unit 110, a POI check unit 120, a cost table update unit 130, a search end determination unit 140, and a user / service condition check unit. 150, an overall schedule calculation unit 160, a search result creation unit 170, a search restriction unit 180, and a graph DB control unit 190. Further, although not shown, a memory for holding a result table and a candidate table is also provided.

  The cost table 101 includes the searched node, the minimum cost at that time until reaching the node, and information on the previous edge reaching the node. There are two cost tables 101: a cost table searched from the starting point and a cost table searched from the arriving point (FIGS. 19 and 20).

  The graph database 102 includes node information including node ID, name, and category information, edge information including a relationship between nodes expressed by a set of two node IDs, and time required for movement between the nodes, and is implemented at each node. The time constraint information such as the start / end time of the service to be performed, the opening time and the time sale is permanently stored in the secondary storage in the form of a graph data model (FIG. 18).

  The user interface unit 105 has a function of inputting a starting point, an arriving point, a category of a place to go to, and a time constraint specified by the user. Specifically, the category information including the departure point, the arrival point, and the waypoint, the maximum value and the minimum value of the departure time at the departure point, the maximum value and the minimum value of the stay time at the waypoint, and the arrival at the waypoint User specified time conditions including the maximum and minimum values of time, the maximum and minimum values of departure time at the waypoint, and the maximum and minimum values of arrival time at the arrival point are acquired.

  The search control unit 110 performs overall control from execution of a search to creation of a search result based on information specified by the user interface unit 105.

  The POI check unit 120 has a function of determining whether a point where the user is currently satisfies a specified category during the search. By making inquiries to the user service condition check unit 150 and the overall schedule calculation unit 160, it is checked that they match the categories such as “sushi” and “bank”. Sometimes it is determined whether or not the desired conditions are met (whether it is in time for opening hours or time sale, or can it be slow for 2 hours, etc.).

  The cost table updating unit 130 has a function of obtaining all edges adjacent to the point where the user is currently located, and updating the cost table 101 if the route passing through the edge is the minimum cost.

The search end determination unit 140 determines whether the search can be ended. Judgment is
-Both the route from the departure store to the POI and the route from the arrival point to the POI are required;
Deriving a preset number of routes;
-A route with a better cost is not required;
・ Below the limit of cost;
Etc. are used for determination.

  The user service condition check unit 150 has a function of checking whether there is a contradiction by comparing the user condition and the service condition when the POI check unit 120 performs the POI check. If there is a contradiction, NG is returned to the POI check unit 120.

  The overall schedule calculation unit 160 satisfies the cost and service conditions for starting point to POI route (hereinafter referred to as “departure route”), POI to arrival point route (hereinafter referred to as “arrival route”). It receives the user condition corrected in the above, has a function of calculating the entire schedule, and returns the result to the POI check unit 120.

  The search result creation unit 170 has a function of configuring all routes from the information in the cost table 101 after the search is completed. By following the previous cost table 101 in order from the cost table at the end point, all routes can be found.

  The search restriction unit 180 determines whether further expansion is necessary based on the position being searched and the user condition, and if unnecessary, expands the node by making the cost of the node in the cost table 101 infinite. It has the function to stop and limit the search.

  The graph DB control unit 190 provides a search function for the graph database 102. The provided functions include a function for searching basic graph information such as obtaining an adjacent node from a certain node and obtaining nodes on both sides of a certain edge.

  Among the above-described configurations, the user / service condition check unit 150 and the overall schedule calculation unit 160 are functions necessary for performing “time sale side trip search” instead of mere side trip search. The search control unit 180 and the POI check unit 120 indicated by bold lines call the functions of the added user / service condition check unit 150 and the overall schedule calculation unit 160 when performing a time sale detour search. It is different from technology. It should be noted that the time sale detour search is naturally different in that POI service conditions are added to the graph database 102. The search control unit 180 indicated by a thick double line is a function necessary for efficiently executing a search in a time sale detour search.

<Time sale trip search>
Below, the realization method of a time sale detour search is demonstrated.

  First, the definition of the information necessary for realizing will be described. There are two types of this information: information on the service providing side and information on convenience on the user side. These are called “service conditions” and “user conditions”. First, service conditions will be described.

<Service conditions>
・ Time sale start time: service_start
・ Time sale end time: service_end
・ Time sale service: serice_content
The start time and end time of the time sale are defined as the name suggests. For a lunch service, “service_start = 11: 30 • service_end = 14: 00” or the like. Also, this value is used for the opening time and closing time.

  Further, in the following example, an example in which the train network is taken into account will be described. However, a search considering the first and last trains can be performed. The start time and the last train time of the train are defined as “serive_start” and “service_end” of the node representing the station. When searching for a train network, it is originally necessary to consider the relationship between timetables and connections, but since this is easy, it will not be considered here for simplicity.

  “service_content” is the service content of the time sale, and can take values such as “all-you-can-eat lunch”, “3 discounts on all remaining products”, and the like. In consideration of designating the service content desired by the user, for example, there is designation of a combination such as “lunch and 3 discount”. For that purpose, “serivce_content” needs to be structured and searchable. However, since the method is easy, it is assumed here that “serivce_content” is not structured as one item.

  Next, user conditions are defined.

<User conditions>
・ The maximum and minimum time of departure from the starting point are respectively start_max and start_min;
・ The maximum and minimum values of POI stay time are pos_stay_max and pos_stay_min;
-POI arrival time maximum and minimum values are poi_start_max, poi_start_min;
・ Poi_end_max, poi_end_min are the maximum and minimum POI departure times;
・ Maximum and minimum time of arrival at the arrival point, end_max, end_min;
The meaning of these definitions will be explained. The maximum value of the starting point means “time to depart as late as possible”, and the minimum value means “time to depart as early as possible”. An example is shown below.

(1) POI stay time:
・ If you want to eat slowly for at least one hour, set "poi_stay_min = 60".

  ・ If you want to round up the meal in 2 hours, set "poi_stay_max = 120".

  ・ If you just need to slip into the window like ticket purchase, you can set “poi_stay_max (= poi_stay_min) = 0”.

  ・ The POI arrival time should be "poi_start_max = 19:00" if you want to start eating at 19:00 at the latest.

  ・ If you do not want to start meals before 18:00, use "poi_start_min = 18:00".

(2) POI departure time:
・ If the meal is always rounded up at 22:00, “poi_end_max = 22: 00”.

  ・ If you want to eat until 21:00, you must use "poi_end_min = 21:00".

(3) Arrival time-The maximum value of the arrival time is "end_max = 24: 00" if you want to go home at 24:00 even if it is late.

  ・ The house key will not open until 23:00, so if you need to go home later than that, set "end_min = 23: 00".

  In order to realize a time sale detour search, the user / service condition check unit 150 needs to perform a search while checking whether the user condition matches the service condition. There are two methods depending on the method of checking.

One is a method of checking the time sale condition last, and is a method of checking whether the time sale condition is satisfied at the timing when the detour is completed. (Corresponding to claims 1 and 3)
The other is a method of checking the time sale condition in advance, and there are cases where the search can be stopped by using the time sale condition even when the detour is not completed. This is a method in which the search range is narrowed in advance by actively using the conditions. (Corresponding to claims 2 and 4)
Hereinafter, the above two methods will be described in detail.

<Method 1: Method to check time sale conditions last>
Since the detour is completed within the POI check process, the flow shown in FIG. 2 is changed as shown in FIG. 4 so that the process corresponds to the time sale.

  Below, a change part is demonstrated. Note that the same processing as in FIG. 2 is assigned the same step number as in FIG. 2, and description thereof is omitted.

  Step 201) After the routes from both sides are found (step 102, Yes), the user / service condition check unit 150 checks whether or not the route satisfies the user conditions / service condition regarding the time sale. Here, if the user condition and the service condition are checked and contradicted, they are eliminated. If you are not satisfied (eg, if you cannot detour within the time sale time), the POI check will be NG and stop. By the processing so far, the “time (length)” of going / returning / POI staying is determined.

  Step 202) The overall schedule calculation unit 160 calculates the overall schedule and registers it in the result table. Here, in consideration of the case where there is a waiting time, the entire schedule such as the departure time and the waypoint departure time is obtained and registered in the result table. In the normal side trip search, the costs on the S side and E side are simply added, but in the case of the time sale side trip search, this is insufficient. This is because there is a possibility of waiting until the service starts. The cost sequence can be reversed without waiting. The final cost is the difference between departure time and arrival time. In this step, all “time” from going to returning is determined.

  Next, the matching (comparison) by the user service condition check 150 will be described.

  FIG. 5 is a flowchart of the user condition / service condition matching process according to the embodiment of the present invention.

  Step 301) First, it is checked that “the POI stay start / stay end condition and the service condition are consistent”. FIG. 6 shows the situation. “poi_start” and “poi_end” are “intervals” that are candidates for POI start / end times, respectively, and “poi_stay” represents the “length” of POI stay time (maximum value is poi_stay_max, minimum value is poi_stay_min ). “service” is a section representing a service condition. Since the POI stay start and stay end need to be included in the service time, the following relationship needs to be satisfied (assuming that the service is expressed in one section).

service_start ≦ poi_start_max
poi_end_min ≦ service_end
Step 302) Next, the POI stay start section and the POI stay end section are corrected. Since POI stay start / end sections that are not included in the service section may be substantially excluded, the POI stay start section / end section and the service section are crossed and corrected POI stay start / end sections Used in future processing ("poi_start '" and "poi_end'" in FIG. 6).

  Step 303) Next, it is checked that there is no contradiction between the corrected POI stay start / stay end condition and the POI stay time. FIG. 7 shows the relationship between POI stay time and start / end time. As shown in FIG. 7, the case where the length of stay time is shorter than the stay start / end time (case 1) is contradictory. The condition that is OK is expressed below.

  The former is exclusion when "poi_stay" is short, and the latter is exclusion when "poi_stay" is long.

poi_end'_min <poi_start'_max + poi_stay_min
poi_start'_min + poi_stay_max ≤ poi_end'_max
Step 304) Next, referring to the cost table 101 and the graph database 102, it is checked whether the cost information up to POI and the POI stay information are consistent. The cost from the S side to the POI is “cost_s”, and the cost from the E side to the POI plan is “cost_e”. FIG. 8 shows their relative relationship. Cases that do not satisfy the constraints include a case (Case 1) where the cost of going too far is too late to start the POI stay (Case 1), and a case where the cost of returning is too large to be in time for arrival at the destination (Case 2). When “waiting” is allowed, the case of waiting until the POI stay starts after arriving at the POI as in Case 3 or waiting until moving after the POI stay ends can be allowed.

  If you write an expression under this condition, it will be as follows. Check this condition.

start_min + cost_s <poi_start'_max
start_end'_min + cost_e <end_max
In addition, since the total length from departure to arrival must not exceed the maximum width of the section (Case 5), the following conditions are checked.

cost_s + poi_stay_min + cost_e <end_max-start_min
This completes the association between the user condition and the service condition.

  Step 202) Next, the overall schedule calculation unit 160 calculates the overall schedule including the waiting time and registers it in the result table. The previous check in step 201 eliminates inconsistent conditions for “time (length)”, but with the constraints given so far, when we leave, stay at POI, The “time” of arrival is not uniquely determined (the overall cost is not uniquely determined). In order to determine the overall plan, it is necessary to have a knowledge of strategies for searching for detours with time constraints. Here, a method for determining an overall plan based on a representative strategy example and obtaining an overall cost is presented. This strategy is simplified and not always effective in real applications. In practice, it is necessary to realize a strategy suitable for the application, but this can be easily realized by applying the following strategy.

  First, some terms are defined for explanation.

  ・ The departure and arrival times of the whole are assumed to be total_start and total_end.

  -Total cost (The time from departure to arrival is defined as total_cost.

・ As an obvious relationship, total_cost = total_end-total_start holds (Relation 1)
・ The start time and end time of the actual stay at POI are poi_stay_start and poi_stay_end, respectively (image of banquet start and end time)
・ The arrival time and departure time at POI are poi_arrive and poi_leave.

  As an obvious relationship, poi_arrive = total_start + cost_s holds (Relationship 2).

  -As an obvious relationship, total_end = poi_leave + cost_e holds (Relationship 3).

  Although the terminology is somewhat confusing, it should be noted that staying at POI is an image of the time at which POI was in the store, and is distinct from POI arrival and departure times. In order to understand the stay at POI figuratively, we may express the stay as an example of the start and end of a “banquet” in the future. The goal in the future is to determine six values of “total_start”, “poi_arrive”, “poi_stay_start”, “poi_stay_end”, “poi_leave”, “total_end” according to the strategy (substantially relationship 2) , 3, so it is sufficient to determine four, and if these are determined, “total_cost” is also determined by relation 1). In the following example, for the sake of simplicity, it is assumed that the staying time (banquet time) at the POI is fixed. This means that the maximum value and the minimum value of the POI staying time are equal (this value is referred to as “poi_stay”).

poi_stay_min = poi_stay_max
<Strategy example> Take action as quickly as possible without waiting:
The characteristics of this strategy are as follows.

・ Start a banquet as soon as possible;
・ Trying to go home as soon as possible;
・ Let's wait as little as possible → Departure approaches the start of the banquet;
The calculation of the schedule is composed of two phases of “individual value determination phase” and “adjustment phase”.

  In the individual value determination phase, the consistency of the schedule as a whole is ignored, and the three values of departure time (Start), arrival time (End), and transit stop (POI) are based on the respective constraints. decide.

  In the adjustment phase, adjustment is performed so as not to contradict the entire schedule from the previously determined values.

● Individual value determination phase:
FIG. 9 shows an image of the individual value determination phase. In this phase, there are three major sections: a departure route section (S section, cases 1 to 3), an arrival path section (E section; cases 1 and 2), and a stay section (P section. Cases 1 and 2). Determine the interval. When the cost_s value is small, the departure route section in this strategy starts at the limit (start_max) that is allowed, and waits until the start of the banquet after arrival at POI (Case 1). When “cost_s” becomes larger and waiting time becomes shorter, and “poi_arrive” arrives at “poi_start_min”, “total_start” is moved forward (case 2). When “total_start” reaches “start_min”, “poi_arrive” shifts backward (case 3). The maximum value of "cost_s" is "poi_start_max-start_min" and will not be larger than this (the case has already been excluded in advance).

  When the value of “cost_e” is small in the arrival path section, the POI is departed so as to arrive at the allowable limit (end_min). After the banquet, wait until POI departure (Case 1). When “cost_e” becomes larger and waiting time becomes shorter and “poi_leave” reaches “por_end_min”, “total_end” is shifted backward (case 2). The maximum value of "cost_e" is "end_max-poi_end_min" and will not be larger than this (the case has already been excluded in advance).

  In the stay section, when the POI stay time (poi_stay) is small, a banquet is held so as to be accommodated at the allowable limit (poi_end_min) (case 1). When POI stay time gradually increases and “poi_stay_start” reaches “por_start_min”, “poi_stay_end” is shifted backward (case 2). The maximum POI stay time is "poi_end_max-poi_start_min", which will never be greater.

  The individual values determined in the above strategy example are shown in FIG.

● Adjustment phase:
Next, the adjustment phase will be described. Although the whole is determined by the combination of the above patterns, there are generally the following two cases where adjustment is necessary.

・ When there is a space between each section;
・ When there is overlap in each section;
However, since the POI stay time is fixed, if there is a vacancy, it becomes a waiting time and there is no room for adjustment. Next, FIG. 11 shows a solution when there is an overlap. In the above-described individual value determination, the schedule is determined to be advanced as much as possible. Therefore, if overlap occurs, it is only necessary to shift the back section backward. When the S section and the P section overlap, the P section is shifted backward (after adjustment 1), and when the P section and the E section overlap further, the E section is shifted backward (after adjustment 2). As a result, “total_end” is excluded in advance so as not to exceed “end_max”.

  An example of a strategy that is slightly different from the above strategy example is that you want to start immediately. The time determination image in that case is shown in FIG. In this case, you must start at "start_min" and wait if you arrive early. The above strategy example can be used as it is for the P and E sections. The same applies to the adjustment phase.

<Method 2: Method to check time sale conditions in advance>
Method 2 is a method of narrowing the search range in advance by actively using time sale conditions. There are three points in the algorithm where the search range can be narrowed in advance.

Step1: When the shortest distance to the node is determined;
・ Step 2: When POI is discovered;
-Step 3: When the path from both sides to POI is found;
It can be said that the above-described method 1 is a method in which all checks are performed in Step 3, which is the last check timing. The processing flow to which the above Steps 1 to 3 are added is shown in FIGS. FIG. 14 is a flow in “Check if node determined on S side (E side) is POI” in step 406 in FIG. 13. (The flow is shared between S side and E side).

  In FIG. 13, after the cost determination on each of the S side and the E side (after the processing of steps 402 and 403), the node is checked (step 404). If it can be excluded from search candidates at this point, the number of subsequent node expansions can be greatly reduced. Details of the check in step 404 are shown in FIG. This process is performed by the search restriction unit 180. Here, a condition check is performed on each of the determined nodes on the S side and the E side. If the check is not satisfied (No in Steps 601 and 602), the cost of the node is set to infinity (Step 603). . If the cost of the node is infinite, the point beyond that node is not expanded because the cost is infinite.

  In FIG. 14, when it is found that the node is POI (Yes in Step 501), the above Step 2 (at the time when POI is found) is checked. If the check is not satisfied (step 502, No), the node is not added to the candidate table or the result table. Therefore, since it is not necessary to create useless candidate table and result table elements, the processing amount can be reduced. After the path from both sides to POI is found (step 503, Yes), Step 3 (when the path from both sides to POI is found) is checked (step 505). This is the same as the timing of the method 1 described above. If this condition is not satisfied (step 505, not satisfied), the registration in the result table is cancelled.

  Next, the possible checks in Steps 1 to 3 will be summarized. There are a total of seven check conditions (OK if the following conditions are met): The search restriction unit 180 implements these checks.

・ Condition 1: Search from the S side and pass the “poi_start” section before reaching the POI;
・ Condition 2: Search from the E side and do not pass the "poi_end" section before reaching the POI;
・ Condition 3: When searching from the S side and adding the minimum value of the stay time to the cost, it should not be more than the “poi_end” section;
・ Condition 4: When searching from the E side and adding the minimum value of the stay time to the cost, there should be only “poi_start” section;
・ Condition 5: POI stay start / end and service condition constraint check shown in FIG. 6;
Condition 6: POI stay time constraint check shown in FIG. 7;
・ Condition 7: Cost information from S side and restriction check of POI stay end shown in FIG. 8;
・ Condition 8: Cost information from E side and restriction check of POI stay end shown in FIG. 8;
・ Condition 9: Overall cost information constraint check shown in FIG. 8;
Since the above conditions 1 to 4 can be checked before reaching the POI, the check in Step 1 is possible. The processing by the search restriction unit 180 in Step 1 is as shown in FIG. 15, and an example corrected in Step 1 is shown in FIG. On the other hand, conditions 5 to 8 cannot be checked unless the POI is reached, but since costs are not requested from both sides, it is possible to check at Step 2 (at the time of finding the POI). Condition 9 requires costs from both sides, so it is necessary to check at Step 3 (when the path from both sides to POI is found) (Conditions 5 and 6 are multiple expressions, otherwise one is one expression) Here, the conditions are in units of S side, E side, and POI).

  The formulas representing the above conditions 1 to 9 are shown below.

・ Condition 1: start_min + cost_s ≤ pos_start_max
・ Condition 2: poi_endo_min + cost_e ≦ end_max
・ Condition 3: start_min + cost_s + poi_stay_min ≤ poi_end_max
・ Condition 4: poi_start_min ≦ end_max-(cost_e + poi_stay_min)
・ Condition 5: service_start ≦ poi_start_max, poi_end_min ≦ service_end
・ Condition 6: poi_end'_min <poi_start'_max + poi_stay_min,
poi_start'_min + poi_stay_max ≤ poi_end'_max
・ Condition 7: start_min + cost_s ≤ poi_start'_max
・ Condition 8: poi_end'_min + coste ≦ end_max
・ Condition 9: cost_s + poi_stay_min + cost_e <end_max-start_min
By checking these conditions in the search restriction unit 180, the search range can be narrowed down and the same result can be obtained efficiently.

<Correction of end condition>
In the time sale detour search, it is necessary to consider the POI stay time, so the following end conditions used in the normal detour search cannot be used as they are.

The maximum cost of the result table ≦ the minimum cost of the candidate table + the cost of the current node The corrected end condition is as follows.

Maximum cost of results including POI stay ≤ Minimum cost of candidate table + Cost of current node + poi_stay_min

  Examples of the present invention will be described below.

<Departure search>
In the following, an embodiment of the detour search will be described.

  A graph used in the example is shown in FIG. In the figure, ○ and ☆ are nodes, ☆ is a POI, and ○ is the other. S is the departure place and E is the destination. Edges are defined between the nodes, and the number above them represents the movement cost between the nodes (for the sake of simplicity, the unit of cost is not a minute / hour, but a unit time). An example in which this graph is expressed as a graph database 102 is shown in FIG. In the example shown in the figure, the graph database 102 is expressed in a tabular form like a relational database, but the node relation can be expressed by a pointer or can be implemented by other than the relational database. As the function of the graph database 102, “specify a node name to obtain a node id”, “obtain a node id and obtain an edge connected to it”, and the like are assumed. These can be easily implemented in a relational database, for example.

  FIGS. 19 (departure route side) and FIG. 20 (arrival route side) show an image of the cost table 101 when the detour search is executed. Each is execution of a Dijkstra search starting from S and E, which is the same as the method described in Non-Patent Document 1 and the like. However, when the POI is reached, the node (and the cost up to that point) is registered in the candidate table. For example, in the departure road side cost table, P1 is determined in Step 3, and information “reach P1 from start side, cost is 3” is registered as a candidate.

  FIG. 21 shows a candidate table and a result table. For example, in Step 7 in the figure, a POI called P2 that is common to the S side and the E side appears, and is registered in the result table (P2, P + 12). The reason why the numbers in the figure are added is that the cost from the S side and the cost from the E side are clearly specified in the later explanation. The result table shown in the figure is sorted by total cost. Therefore, the detour route to be obtained in this case is a route via P1, and the total cost is “18”. A specific route can be obtained by a method similar to the Dijkstra method (for example, a node before each node is stored).

<Time sale trip search>
Next, an example of time sale detour search will be shown.

  The target graph uses the same example as above.

  An example of designation of each time is shown in FIG. The number line represents time, and the unit is assumed to be the same unit as the cost on the graph. For example, the value of “start_min” is time 0, and “poi_start_min” is time 13. Now, an example of a condition check relating to time will be described.

  First, a check (FIG. 6) of “no conflict between POI stay start / end conditions and service conditions” will be described.

  FIG. 22 shows an example of service times P1 to P5. In this example, the end of P2 is inconsistent (poi_end_min ≦ service_end is not satisfied), and is excluded from the candidates. The POI stay start / end conditions are corrected in consideration of the service conditions, but the example is shown in the same figure (example of P1). We are looking for fellowship as a number line. It is necessary to continue the following discussion in the section corrected in this way, but in the future discussion, for the sake of simplicity, it is assumed that all service conditions of P1 to P5 are 13 to 28, and no correction occurs here. And

<Check that there is no contradiction between the corrected POI stay start / end conditions and POI stay time>
Next, the check (FIG. 7) of “there is no contradiction between the corrected POI stay start / end conditions and the POI stay time” will be described. In this example, if the POI stay time is 5 to 15 (eg, “poi_stay_min = 5 and poi_stay_max = 15”), this constraint is satisfied. In the following, it is assumed that “poi_stay_min = poi_stay_max = 10” (just 10 stays).

A check on “Contradiction between cost information and POI stay start / end conditions” (FIG. 8) will be described. Conditional expression
start_min + cost_s <poi_start'_max
start_end'_min + cost_e <end_max
cost_s + poi_stay_min + cost_e <end_max-start_min
Check if is satisfied. The state of the check is shown in FIG. For example, in P1, “start_min + cost_s” exceeds “poi_start'_max”, so the condition is not satisfied. At this point, P5 is excluded from the candidate POI. The total cost check is satisfied because the value of “end_max−stat_min” is 38 and the value of “cost_s + poi_stay_min + cost_e” is 28 to 36 (P5 is not satisfied but has already been excluded).

<Processing “Calculate overall cost including waiting time”>
An example of “determining the total cost including the waiting time” (S506 in FIG. 14) is shown.

  FIG. 24 shows an individual value determination phase in which FIG. 9 showing its image is applied to this embodiment. The number lines and values shown in Case 1, Case 2, etc. are the thresholds in each case. For example, Case 1 of the S section is a case where the head of the section is time 0-5, and Case 2 is a case where the end point of the section is 13-18.

  FIG. 25 shows the result of determining cases and determining individual values (total_start and poi_leave) according to the embodiment. Further, although it is necessary to determine the P section as well, in this embodiment, since “poi_stay = 10”, the case is case 1 and “poi_stay_start” is 10.

  An example of the adjustment phase is shown in FIG. P1, P2, and P4 do not need to be adjusted because there is no overlap. P1 has a pattern of waiting on the departure route. Since P3 has an overlap, shift back to get the final result. From these final results, the total cost (total_end−total_start) is obtained. The value is shown at the right end of FIG. It can be seen that the minimum is the case via P2. When searching for a detour that does not take into account time constraints, the route via P1 was the optimal solution.However, when routed via P1, the location of P1 is close to the starting point, so it arrives at the POI early and waits. Occur. So P2 is reversed. For example, this means that you have not been able to visit POI at the right time for a banquet. In other words, by using this time sale detour search, it is possible to visit a place of interest at an optimal time.

<Method 2: When condition evaluation is performed first>
Finally, method 2 (when condition evaluation is performed first) will be described.

  When this method 2 is adopted, in this embodiment, P5 which is NG in FIG. 23 is not a final check, but the search after that is stopped when P5 is reached by the search on the departure road side. Can do. In FIG. 19 of the present embodiment, since the time point of reaching P5 is step 11, it is not a reduction in the number of steps, but in general, it can contribute to a reduction in the number of developments.

  In addition, the operation of the components of the detour search device shown in FIG. 3 in the above embodiment is constructed as a program, installed and executed on a computer used as the detour search device, or distributed via a network. Is possible.

  The present invention is not limited to the above-described embodiments and examples, and various modifications and applications can be made within the scope of the claims.

DESCRIPTION OF SYMBOLS 100 Side trip search apparatus 101 Cost table 102 Graph database 105 User interface part 110 Search control part 120 POI check part 130 Cost table update part 140 Search end determination part 150 User service condition check part 160 Overall schedule calculation part 170 Search result creation part 180 Search restriction unit 190 Graph database control unit

Claims (5)

A detour search device for finding the shortest path of detour in a graph,
Implemented on nodes, node information with node ID, name, category information, graph information consisting of edge information with relationship between nodes represented by a pair of two node IDs and travel time between the nodes, and node information A graph database that stores the service start and end times and service details;
Category information including departure point, destination point, and waypoint specified by the user, maximum and minimum values of departure time at the departure point, maximum value and minimum value of stay time at the waypoint, and the waypoint User interface means for acquiring user specified time conditions including maximum and minimum values of arrival time at the destination, maximum and minimum values of departure time at the waypoint, and maximum and minimum values of arrival time at the destination When,
POI (Point Of Interest) check means for obtaining a waypoint that matches the category information input by the user interface means with reference to the graph database;
Among the via points acquired by the POI check means, user service condition check means for excluding via points that do not match the service time condition with the information specified by the user;
For via points that are not excluded by the user service condition check means, satisfy the user specified time condition, departure point departure time, via point arrival time, via point stay time, via point stay end time, via point departure time, arrival point A schedule including a point arrival time and a waiting time is generated, a service is received at the waypoint, and a route from the departure point to the destination point via the waypoint is searched with a minimum required time as a whole. An overall schedule calculation means;
A detour search device characterized by comprising: 2. The detour search device according to claim 1, further comprising a search restriction unit that excludes, from the processing target, via points that do not match the conditions specified by the user before the POI check unit is implemented. A detour search method for finding the shortest path of detour in a graph,
Implemented on nodes, node information with node ID, name, category information, graph information consisting of edge information with relationship between nodes represented by a pair of two node IDs and travel time between the nodes, and node information In a device having a graph database storing service start / end times and service contents,
The user interface means the category information including the departure point, the arrival point, and the waypoint designated by the user, the maximum value and the minimum value of the departure time at the departure point, and the maximum value and the minimum time of stay at the waypoint. A user-specified time condition including a value, a maximum value and a minimum value of the arrival time at the waypoint, a maximum value and a minimum value of a departure time at the waypoint, and a maximum value and a minimum value of the arrival time at the destination A user input step to obtain;
POI (Point Of Interest) check means, a POI check step for obtaining a waypoint that matches the category information input in the user input step with reference to the graph database;
User service condition check means, the user service condition check step of eliminating the via point that does not match the information specified by the user and the service time condition among the via points acquired in the POI check step,
The whole schedule calculation means satisfies the user-specified time condition for the waypoints not excluded in the user service condition check, and the departure point departure time, waypoint arrival time, waypoint stay time, waypoint stay end time, waypoint A schedule including a point departure time, an arrival point arrival time, and a waiting time is generated, and a service is received at the waypoint, and the route travels from the departure point via the waypoint to the arrival point with a minimum required time as a whole. An overall schedule calculation step for searching the route to reach,
A detour search method characterized by comprising: 4. The detour search method according to claim 3, further comprising a search restriction step of excluding from the processing points via points that do not match the conditions specified by the user before the execution of the POI check step. Computer
A detour search program for functioning as each means of the detour search device according to claim 1.

Images