Address search device, address search method, and address search program

Abstract

To reduce a processing load in address search and increase the efficiency of processing search processing.SOLUTION: An address search device 10 stores: an address table; a hash table for managing the correspondence between a hash value for a mesh ID of a mesh and an entry of an address table of the address of the mesh; and a look-up table for managing the correspondence between the mesh ID of a first-size mesh and a use mesh size used to calculate the hash value associated with the entry of the address table in the hash table. A processor unit calculates the mesh ID of the first-size mesh including a position of coordinate information, specifies the use mesh size with reference to the look-up table, specifies the mesh ID of the mesh of the use mesh size including the position of the coordinate information, specifies the entry of the address table corresponding to the hash value of the mesh ID with reference to the hash table, and specifies the address.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention relates to a technique for searching for one or more addresses based on coordinate information measured by, for example, a global positioning satellite system.

Background Art

[0002] For example, global positioning satellite systems (GNSS: Global Navigation Satellite System) such as GPS (Global Positioning System) are known, and various analysis processes are performed using coordinate information and the like measured by these global positioning satellite systems. In such an analysis process, for example, the address may be specified from GPS data indicating the position of a person, a vehicle, or the like, and various analyses may be performed.

[0003] For example, a technique using partitions (meshes) of different sizes is disclosed when extracting k pieces of data in ascending order of distance with location information as a search key (see, for example, Patent Document 1).

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] For example, when managing meshes of different sizes as in Patent Document 1, it is necessary to manage data of meshes of a plurality of sizes. As the data to be managed increases, the processing load for specifying the identification information of the meshes increases, and there is a risk that the processing efficiency in the search will decrease.

[0006] This invention has been made in view of the above circumstances, and its purpose is to provide a technology that can reduce the processing load in address search processing and improve the processing efficiency of address search processing. [Means for solving the problem]

[0007] To achieve the above objective, an address search device relating to one perspective is an address search device that searches for one or more addresses corresponding to coordinate information based on coordinate information, the address search device comprising a storage unit and a processor unit, the storage unit storing an address table that stores addresses and coordinate information of the addresses, a hash table that manages the correspondence between a hash value for a mesh ID of a mesh and an entry in the address table of an address belonging to the mesh, and a lookup table that manages the correspondence between a mesh ID of a first size mesh and information that identifies the usable mesh size, which is the size of the mesh of the mesh ID used in the calculation of the hash value associated in the hash table with the entry in the address table for an address included in the mesh of the mesh ID, the processor unit calculates the mesh ID of the first size mesh including the position indicated by the coordinate information, refers to the lookup table to identify the usable mesh size corresponding to the calculated mesh ID, identifies a mesh ID for the hash table which is the mesh ID of the mesh of the usable mesh size including the position indicated by the coordinate information, refers to the hash table to identify an entry in the address table corresponding to the hash value of the mesh ID for the hash table, and identifies an address based on the identified entry. [Effects of the Invention]

[0008] According to the present invention, the processing load in address search processing can be reduced, and the processing efficiency of address search processing can be improved. [Brief explanation of the drawing]

[0009] [Figure 1]Figure 1 is a functional configuration diagram of the address search device according to the first embodiment. [Figure 2] Figure 2 is a hardware configuration diagram of the address search device according to the first embodiment. [Figure 3] Figure 3 is a diagram illustrating the mesh and mesh ID according to the first embodiment. [Figure 4] Figure 4 illustrates an example of an existing address in two mesh sizes according to the first embodiment. [Figure 5] Figure 5 illustrates another example of existing addresses in two mesh sizes according to the first embodiment. [Figure 6] Figure 6 is a diagram showing the configuration of the address table according to the first embodiment. [Figure 7] Figure 7 is a diagram showing the configuration of the address table after assignment according to the first embodiment. [Figure 8] Figure 8 is a diagram showing the configuration of a lookup table according to the first embodiment. [Figure 9] Figure 9 is a diagram showing the configuration of the GPS table according to the first embodiment. [Figure 10] Figure 10 is a diagram showing the configuration of the GPS table after assignment according to the first embodiment. [Figure 11] Figure 11 is a diagram showing the configuration of a hash table according to the first embodiment. [Figure 12] Figure 12 is a flowchart of the lookup table creation process according to the first embodiment. [Figure 13] Figure 13 illustrates the method for specifying the mesh size used in the processing according to the first embodiment. [Figure 14] Figure 14 is a flowchart of the process for determining the mesh size to be used according to the first embodiment. [Figure 15] Figure 15 is a diagram illustrating the overview of the hash join process according to the first embodiment. [Figure 16] Figure 16 is a flowchart of the hash join process according to the first embodiment. [Figure 17]FIG. 17 is a flowchart of utilization mesh size determination processing according to a modification example. [Figure 18] FIG. 18 is a functional configuration diagram of an address search device according to the second embodiment. [Figure 19] FIG. 19 is a configuration diagram of a past resource data table according to the second embodiment. [Figure 20] FIG. 20 shows the configuration of a labeled past resource data table according to the second embodiment. [Figure 21] FIG. 21 is a configuration diagram of a request reception screen according to the second embodiment. [Figure 22] FIG. 22 is a configuration diagram of a resource lookup table according to the second embodiment. [Figure 23] FIG. 23 is a diagram showing an example of an area according to the second embodiment. [Figure 24] FIG. 24 is a diagram showing a first example of a detection result of a resource according to the second embodiment. [Figure 25] FIG. 25 is a diagram showing a second example of a detection result of a resource according to the second embodiment. [Figure 26] FIG. 26 is a diagram for explaining a hash join according to a modification example. [Figure 27] FIG. 27 is a diagram for explaining an example of a query showing integration of meshes to be joined according to a modification example. MODE FOR CARRYING OUT THE INVENTION

[0010] Embodiments will be described with reference to the drawings. Note that the embodiments described below do not limit the invention according to the claims, and not all of the elements and combinations thereof described in the embodiments are essential for the solution means of the invention.

[0011] In the following description, information may be described in terms of a "AAA table", but the information may be represented in any data structure. That is, in order to indicate that the information is independent of the data structure, the "AAA table" can be referred to as "AAA information".

[0012] Figure 1 is a functional configuration diagram of the address search device according to the first embodiment.

[0013] The address search device 10 includes a mesh ID generation and assignment unit 101, an address table statistical analysis unit 102, a usage mesh ID management unit 103, a GPS information acquisition unit 104, a hash join processing unit 105, a distance calculation unit 106, a nearest neighbor table extraction unit 107, an address table 110, a post-assigned address table 111, a lookup table 112, a GPS table 113, a post-assigned GPS table 114, and a hash table 115.

[0014] The mesh ID generation and assignment unit 101 generates mesh IDs for multiple mesh sizes for the location representing the address in each row of the address table 110, and assigns them to each row, thereby creating the post-assignment address table 111.

[0015] The address table statistical analysis unit 102 performs a process to aggregate the number of each mesh ID in the assigned address table 111.

[0016] The Mesh ID Management Unit 103 determines the Mesh ID to be used in the hash join process for each location within a mesh based on the processing results from the Address Table Statistical Analysis Unit 102, and registers it in the Lookup Table 112. The Mesh ID Management Unit 103 also notifies the Hash Join Processing Unit 105 of the Mesh ID to be used in the hash join process for a given location within a mesh.

[0017] The GPS information acquisition unit 104 acquires GPS data to be used to search for an address, for example, via a network.

[0018] The hash join processing unit 105 creates a hash table 115 based on the assigned address table 111 and the lookup table 112. The hash join processing unit 105 also identifies the mesh ID (used mesh ID) to be used in the hash join process based on the assigned GPS table 114, which contains the GPS data to be searched for addresses, and the lookup table 112, matches it with the hash table 115, and creates a joined table by joining the assigned GPS table 114 and the assigned address table 111.

[0019] The distance calculation unit 106 calculates the distance between the location indicated by one row in the assigned GPS table 114 and the address indicated by each row, when there are multiple rows in the assigned address table 111 that are joined with one row in the assigned GPS table 114.

[0020] The nearest neighbor table extraction unit 107 extracts the address closest to the location indicated by the row in the assigned GPS table 114 as a search result, based on the distance calculated by the distance calculation unit 106.

[0021] Figure 2 is a hardware configuration diagram of the address search device according to the first embodiment.

[0022] The address search device 10 is composed of a computer, such as a PC (Personal Computer), and includes a communication interface (I / F) 11, a CPU (Central Processing Unit) 12 as an example of a processor unit, an input device 13, a storage device 14, a memory 15 as an example of a storage unit, and a display device 16. The communication I / F 11, CPU 12, input device 13, storage device 14, memory 15, and display device 16 are connected via a bus 17.

[0023] Communication I / F11 is an interface such as a wired LAN card or a wireless LAN card, which communicates with other devices over a network.

[0024] The CPU 12 executes various processes according to the program stored in the memory 15 and / or the storage device 14. In this embodiment, the CPU 12 executes a program (address search program) to configure the mesh ID generation and assignment unit 101, the address table statistical analysis unit 102, the used mesh ID management unit 103, the GPS information acquisition unit 104, the hash join processing unit 105, the distance calculation unit 106, and the nearest neighbor table extraction unit 107.

[0025] Memory 15 is, for example, RAM (RANDOM ACCESS MEMORY), which stores programs executed by the CPU 12 and other necessary information.

[0026] The storage device 14 is, for example, a hard disk or flash memory, and stores programs executed by the CPU 12 and data used by the CPU 12. In this embodiment, the memory 15 and / or the storage device 14 stores the address table 110, the assigned address table 111, the lookup table 112, the GPS table 113, the assigned GPS table 114, and the hash table 115.

[0027] The input device 13 is, for example, a mouse or keyboard, and accepts information input from the user. The display device 16 is, for example, a display, and outputs a user interface containing various information.

[0028] Next, we will explain meshes and mesh IDs.

[0029] Figure 3 is a diagram illustrating the mesh and mesh ID according to the first embodiment.

[0030] In this embodiment, multiple meshes of different sizes are used as the mesh that includes a certain location. For example, the multiple mesh sizes used may be a mesh of size 25 (approximately 25m x 25m), a mesh of size 50 (approximately 50m x 50m), a mesh of size 100 (approximately 100m x 100m), a mesh of size 200 (approximately 200m x 200m), a mesh of size 500 (approximately 500m x 500m), or a mesh of size 1000 (approximately 1km x 1km).

[0031] In this embodiment, the mesh ID for each mesh size is a two-dimensional code obtained by a simple calculation (arithmetic processing) based on GPS data (longitude (lng), latitude (lat)) of the location included in that mesh. Specifically, if the mesh ID is (x, y), then x = INT(lng * corresponding multiplier for mesh size) and y = INT(lat * corresponding multiplier for mesh size). Here, INT is a function that performs integer conversion (rounding down of decimal places).

[0032] Furthermore, in this embodiment, as shown in Figure 3, the corresponding magnification ratio for the mesh size is 4000 for a mesh of size 25, 2000 for a mesh of size 50, 1000 for a mesh of size 100, 500 for a mesh of size 200, 200 for a mesh of size 500, and 100 for a mesh of size 1000, which is an inversely proportional magnification ratio depending on the mesh size.

[0033] For example, if the GPS data for a certain location is (140.4694,37.65843), then the mesh ID for size 25 (25m mesh ID) is (561877,150633), the mesh ID for size 50 (50m mesh ID) is (280938,75316), the mesh ID for size 100 (100m mesh ID) is (140469,37658), the mesh ID for size 200 (200m mesh ID) is (70234,18829), the mesh ID for size 500 (500m mesh ID) is (28093,7531), and the mesh ID for size 1000 (1k mesh ID) is (14046,3765).

[0034] With this type of mesh ID, it is possible to easily calculate the mesh ID of a larger mesh containing a smaller mesh from the mesh ID of the smaller mesh. Specifically, the mesh ID of a smaller mesh can be easily calculated by dividing it by the ratio between the corresponding ratios of the larger and smaller meshes (corresponding ratio of the smaller mesh / corresponding ratio of the larger mesh) and converting it to an integer.

[0035] For example, to calculate a mesh ID of size 200 from a mesh ID of size 100, the mesh ID of size 200 can be calculated as follows: (INT(140469 / (1000 / 500)),INT(37658 / (1000 / 500)))=(70234,18829).

[0036] In this embodiment, since the mesh ID can be calculated from GPS data using a simple calculation, the processing load can be reduced and the processing time can be shortened.

[0037] Note that the mesh ID is not limited to this. For example, the latitude and longitude of GPS data may be multiplied by 100,000 to obtain an integer while retaining significant figures, and the resulting number up to the upper predetermined character may be used as the mesh ID. For example, if the GPS data for a certain location is (140.4694,37.65843), multiplying by 10,000 gives (14046940,3765834), and for a mesh of size 100, the upper six digits may be used, which is (140469,37658).

[0038] Next, we will explain the differences in processing load depending on the mesh size used.

[0039] Figure 4 illustrates an example of existing addresses in two mesh sizes according to the first embodiment. Figure 5 illustrates another example of existing addresses in two mesh sizes according to the first embodiment.

[0040] For example, if there are four houses (addresses) in a mesh of size 25, as shown in Figure 4, there may be many houses (18 in the figure) densely clustered in a mesh of size 100 that includes that mesh. In this case, if a hash join is performed using the mesh ID of the size 100 mesh, many addresses in the size 100 mesh will be joined to a single location. To identify the nearest address to a given location from among these, it becomes necessary to perform a process to calculate the distance to many of these addresses, which increases the processing load. Therefore, it is better to use a mesh of size 25 for such areas.

[0041] On the other hand, if there are four houses in a mesh of size 25, as shown in Figure 5, there may be a few houses (eight in the figure) scattered in a mesh of size 100 that includes that mesh. In this case, if hash join processing is performed using the mesh ID of the mesh of size 100, only a few addresses existing in the mesh of size 100 will be joined to a single location. To identify the nearest address to a given location from among these, it is only necessary to perform a process to calculate the distance to a small number of addresses, and the processing load does not increase significantly. In contrast, if hash join processing is performed using the mesh ID of the mesh of size 25, the number of hashes that need to be managed in the hash table increases, and the data size of the hash table becomes larger. Therefore, it is considered better to use a mesh of size 100 for such areas.

[0042] Next, we will explain address table 110.

[0043] Figure 6 is a diagram showing the configuration of the address table according to the first embodiment.

[0044] The address table 110 is a table that manages the addresses to be searched. The address table 110 stores an entry (row) for each address. The entries in the address table 110 include the following fields (items): area ID 110a, prefecture name 110b, city name 110c, town name 110d, street number 110e, latitude 110f, and longitude 110g.

[0045] Area ID 110a stores the ID of the area to which the address corresponding to the entry belongs. Prefecture name 110b stores the prefecture name of the address corresponding to the entry. City name 110c stores the city name of the address corresponding to the entry. Town name 110d stores the town name of the address corresponding to the entry. Street number 110e stores the street number from the town name onwards of the address corresponding to the entry. Latitude 110f stores the latitude of the address corresponding to the entry. Longitude 110g stores the longitude of the address corresponding to the entry.

[0046] Next, we will explain the address table 111 after assignment.

[0047] Figure 7 is a diagram showing the configuration of the address table after assignment according to the first embodiment.

[0048] The assigned address table 111 is a table in which a field for storing mesh IDs for multiple mesh sizes has been added to each row of the address table 110.

[0049] After assignment, the entries in address table 111 will include, in addition to the entries in address table 110, the following items: 25m mesh_x_ID110h, 25m mesh_y_ID110i, 100m mesh_x_ID110j, and 100m mesh_x_ID110k.

[0050] The 25m_mesh_x_ID110h stores the x component of the mesh ID of a mesh of size 25 (an example of the first size) that contains the address corresponding to the entry. The 25m_mesh_y_ID110i stores the y component of the mesh ID of a mesh of size 25 that contains the address corresponding to the entry. The 100m_mesh_x_ID110j stores the x component of the mesh ID of a mesh of size 100 (the second size) that contains the address corresponding to the entry. The 100m_mesh_y_ID110k stores the y component of the mesh ID of a mesh of size 100 that contains the address corresponding to the entry.

[0051] Next, we will explain the lookup table 112.

[0052] Figure 8 is a diagram showing the configuration of a lookup table according to the first embodiment.

[0053] The lookup table 112 is a table that manages the mesh IDs used when hash joining for locations belonging to a mesh. The lookup table 112 stores entries for each mesh of size 25. The entries in the lookup table 112 include the following items: 25m mesh_x_ID112a, 25m mesh_y_ID112b, number 112c, 100m mesh_x_ID112d, 100m mesh_x_ID112e, number 112f, and the mesh ID used 112g.

[0054] 25m_mesh_x_ID112a stores the x component of the mesh ID of the mesh of size 25 corresponding to the entry. 25m_mesh_y_ID112b stores the y component of the mesh ID of the mesh of size 25 corresponding to the entry. Number 112c stores the number of addresses stored in the address table 110 contained within the mesh of size 25 corresponding to the entry. 100m_mesh_x_ID112d stores the x component of the mesh ID of the mesh of size 100 containing the mesh of size 25 corresponding to the entry. 100m_mesh_y_ID112e stores the y component of the mesh ID of the mesh of size 100 containing the mesh of size 25 corresponding to the entry. Number 112f stores the number of addresses stored in the address table 110 contained within the mesh of size 100 containing the mesh of size 25 corresponding to the entry. Usage_mesh_ID112g stores information (e.g., mesh size) that identifies the mesh ID (usage_mesh_ID) to be used for hash join for the mesh of size 25 corresponding to the entry. For example, if a mesh ID of a mesh with size 25 is used in a hash join process, 25 will be stored in the used mesh ID 112g. If a mesh ID of a mesh with size 100 is used in a hash join process, 100 will be stored.

[0055] Next, we will explain GPS table 113.

[0056] Figure 9 is a diagram showing the configuration of a GPS table according to one embodiment.

[0057] The GPS table 113 is a table that manages the location (coordinate information) of a moving object (in this example, a vehicle) whose address is to be identified. The GPS table 113 stores entries (GPS data) for each point in time regarding the moving object. The entries in the GPS table 113 include items for vehicle number 113a, employee number 113b, latitude 113c, and longitude 113d.

[0058] Vehicle number 113a stores the number of the vehicle corresponding to the entry. Employee number 113b stores the number of the employee using the vehicle corresponding to the entry. Latitude 113c stores the latitude of the vehicle corresponding to the entry. Longitude 113d stores the longitude of the vehicle corresponding to the entry. Here, latitude and longitude are examples of coordinate information.

[0059] Next, we will explain the GPS table 114 after assignment.

[0060] Figure 10 is a diagram showing the configuration of a GPS table after assignment according to one embodiment.

[0061] The modified GPS table 114 is a table in which, for each row of the GPS table 113, an item is added to store the mesh ID for multiple mesh sizes.

[0062] After assignment, the entries in GPS table 114 will include, in addition to the entries in GPS table 113, the following items: 25m mesh_x_ID113e, 25m mesh_y_ID113f, 100m mesh_x_ID113g, and 100m mesh_y_ID113h.

[0063] The 25m_mesh_x_ID113e stores the x component of the mesh ID of a mesh of size 25 that contains the location of the object being moved corresponding to the entry. The 25m_mesh_y_ID113f stores the y component of the mesh ID of a mesh of size 25 that contains the location of the object being moved corresponding to the entry. The 100m_mesh_x_ID113g stores the x component of the mesh ID of a mesh of size 100 that contains the location of the object being moved corresponding to the entry. The 100m_mesh_y_ID113h stores the y component of the mesh ID of a mesh of size 100 that contains the location of the object being moved corresponding to the entry.

[0064] Next, we will explain hashtable 115.

[0065] Figure 11 is a diagram illustrating the configuration of a hash table according to one embodiment.

[0066] The hash table 115 manages the correspondence between hash values ​​corresponding to mesh IDs and rows in the assigned address table 111 corresponding to the mesh IDs whose hash values ​​are generated. The hash table 115 includes a group of hash values ​​115a and a plurality of linked links 115b.

[0067] The hash value group 115a stores hash values ​​corresponding to multiple mesh IDs. The mesh size of the mesh IDs corresponding to the hash values ​​stored in the hash value group 115a is different depending on the number of addresses in each area (in this embodiment, size 25 or size 100).

[0068] Linked links 115b are provided for each hash value in the hash value group 115a. Linked links 115b include a link (also called a bucket) of reference information that refers to one or more rows in the post-assigned address table 111 corresponding to the mesh ID that has the corresponding hash value. Using these linked links 115b, it is possible to identify the row in the post-assigned address table 111 for a mesh ID that has a specific hash value.

[0069] For example, if N is the number of mesh ID entries in the address table 110 (the number of entries in the lookup table 112), and if a mesh IDs for a 100m mesh can be utilized, then the number of connections (buckets) in the hash table 115 will be N - 4*a + a = N - 3*a. Therefore, the memory capacity required for the hash table 115 can be reduced compared to the case where only 25m meshes are used. Here, if the average number of 25m meshes is h, and the number of data used per connection is B, then the capacity required for the hash table 115 is (N - 3*a) × h × B. If we want to secure twice the capacity to prevent memory overflow, then it becomes (N - 3*a) × h × B × 2.

[0070] Next, the processing operation of the address search device 10 according to this embodiment will be described.

[0071] Figure 12 is a flowchart of the lookup table creation process according to one embodiment.

[0072] The mesh ID generation and assignment unit 101 calculates 25m mesh IDs and 100m mesh IDs based on the latitude and longitude of each entry in the address table 110, and assigns these mesh IDs to each entry to create the post-assignment address table 111 (S11).

[0073] Next, the address table statistical analysis unit 102 groups the 25m mesh ID and 100m mesh ID in the assigned address table 111 by each mesh ID, aggregates the number of times the same mesh ID is used, and creates a lookup table 112 (S12).

[0074] In step S11, the mesh sizes for the created mesh IDs were set to size 25 and size 100, but this is not limited to these. For example, the mesh size may be determined based on the population density of the target area, or it may be determined based on user specifications.

[0075] Figure 13 illustrates a method for specifying the mesh size used in processing according to one embodiment.

[0076] For users to specify the mesh size, they can either specify the mesh size directly, or, as shown in Figure 13, they can specify the mesh size by specifying the error in the distance from the center of the mesh. As shown in Figure 13, by accepting a specification of 12.5m as the error from the center, a mesh size of 25 can be specified.

[0077] Next, we will explain the process for determining the mesh size to be used.

[0078] Figure 14 is a flowchart of the process for determining the mesh size to be used according to one embodiment.

[0079] The process for determining the mesh size to be used is executed, for example, after the lookup table creation process is completed, targeting each row of the lookup table 112. In this explanation, the rows being processed will be referred to as target rows.

[0080] The usage mesh ID management unit 103 determines whether the number of 100m mesh IDs in the target row of the lookup table 112 is less than or equal to the average number of 25m mesh IDs in the lookup table 112 (S21).

[0081] As a result, if the number of 100m mesh IDs in the target row is less than or equal to the average number of 25m mesh IDs (S21: Yes), the number of mesh IDs managed by the hash table 115 can be reduced by using a mesh of size 100. Therefore, the usage mesh ID management unit 103 registers the 100m mesh ID as the usage mesh ID 112g of the target row (S22) and terminates the process. On the other hand, if the number of 100m mesh IDs in the target row is not less than or equal to the average number of 25m mesh IDs (S21: No), then using a mesh of size 100 would result in a large number of addresses having the same mesh ID, which would increase the processing load for distance calculation. Therefore, the usage mesh ID management unit 103 registers a 25m mesh ID for the usage mesh ID 112g of the target row (S23) and terminates the process.

[0082] Next, we will explain hash join processing.

[0083] Figure 15 is a diagram illustrating the overview of the hash join process according to the first embodiment. Figure 16 is a flowchart of the hash join process according to one embodiment.

[0084] The mesh ID generation and assignment unit 101 calculates 25m mesh IDs and 100m mesh IDs based on the latitude and longitude of each entry in the GPS table 113, and assigns these mesh IDs to each entry to create a post-assignment GPS table 114 (S31).

[0085] Next, the hash join processing unit 105 refers to the lookup table 112 for each row in the assigned address table 111 to identify the mesh ID (used mesh ID: mesh ID for the hash table) to be used in the hash join process for the position of each row, and calculates a hash value corresponding to the used mesh ID corresponding to each row. Next, the hash join processing unit 105 creates a hash table 115 that manages the correspondence between the calculated hash values ​​and each row in the assigned address table 111 (S32: (1) in Figure 15).

[0086] Next, the hash join processing unit 105 refers to the lookup table 112 for each row in the assigned GPS table 114 to identify the usage mesh ID to be used in the hash join process for the location of each row (Figure 15 (2)), and calculates the hash value of the identified usage mesh ID. Next, the hash join processing unit 105 matches the calculated hash value with the hash table 115 (Figure 15 (3)), and creates a joined table that includes rows formed by joining each row in the assigned GPS table 114 with the corresponding row in the assigned address table 111 (S33).

[0087] This hash join process allows us to create a joined table containing rows of candidate addresses corresponding to the latitude and longitude of each entry in GPS table 113 (GPS table 114 after assignment).

[0088] Next, we will explain the process for determining the mesh size used in the modified example.

[0089] Figure 17 is a flowchart of the process for determining the mesh size used in the modified example.

[0090] This mesh size determination process is performed in place of the mesh size determination process shown in Figure 14. Alternatively, this mesh size determination process may be performed only if the address search process using the mesh ID determined by the mesh size determination process shown in Figure 14 is slow.

[0091] The process for determining the mesh size to be used is performed on each row of the lookup table 112. In this explanation, the row being processed will be referred to as the target row.

[0092] The Mesh ID Management Unit 103 determines whether the number of 100m mesh IDs in the target row of the lookup table 112 is at least twice (1st time) the average number of 25m mesh IDs in the lookup table 112 (S41).

[0093] As a result, if the number of 100m mesh IDs in the target row is more than twice the average number of 25m mesh IDs (S41: Yes), it means that using a mesh of size 100 will result in a large number of addresses with the same mesh ID, increasing the processing load for distance calculation. Therefore, the usage mesh ID management unit 103 registers a 25m mesh ID for the usage mesh ID 112g of the target row (S42) and terminates the process.

[0094] On the other hand, if the number of 100m mesh IDs in the target row is not more than twice the average number of 25m mesh IDs (S41: No), then it is determined whether the number of 100m mesh IDs in the target row of the lookup table 112 is less than or equal to the average number of 25m mesh IDs in the lookup table 112 (less than or equal to 1x (2x) the average) (S43).

[0095] As a result, if the number of 100m mesh IDs in the target row is less than or equal to the average number of 25m mesh IDs (S43: Yes), the number of mesh IDs managed by the hash table 115 can be reduced by using a mesh of size 100. Therefore, the usage mesh ID management unit 103 registers the 100m mesh ID as the usage mesh ID 112g of the target row (S44) and terminates the process.

[0096] On the other hand, if the number of 100m mesh IDs in the target row is not less than or equal to the average number of 25m mesh IDs (greater than average and less than or equal to twice the average) (S43: No), it means that using size 50 (third size) between size 25 and size 100 is more efficient for processing. Therefore, the usage mesh ID management unit 103 creates a 50m mesh ID corresponding to the 25m mesh of the target row, assigns the 50m mesh ID to the 25m mesh entry of the target row in the post-assignment address table 111, registers the 50m mesh ID as the usage mesh ID 112g of the target row (S45), and terminates the process.

[0097] According to this modified version, the mesh size ID used for hash join can be selected from 25m mesh ID, 50m mesh ID, and 100m mesh ID, thereby improving the efficiency of address search processing.

[0098] Next, the address search device 10A according to the second embodiment will be described.

[0099] Figure 18 is a functional configuration diagram of the address search device according to the second embodiment. In the address search device 10A, the same reference numerals are used for functional parts that are the same as those in the address search device 10.

[0100] The address search device 10A includes, in addition to the configuration of the address search device 10, a processing time measurement unit 201, a user interface unit 202, a past resource data table 203 (labeled past resource data table 204), a resource utilization information extraction unit 205, a resource lookup table 206, and a resource matching processing unit 207. The address search device 10A may be configured using a VM (virtual machine) of a cloud service, or it may be configured using a physical computer such as a general-purpose server. In this embodiment, the CPU 12 executes a program (address search program) to configure the processing time measurement unit 201, the user interface unit 202, the resource utilization information extraction unit 205, and the resource matching processing unit 207.

[0101] The processing time measurement unit 201 measures the processing time required for address search processing for GPS data to be processed (for example, GPS data within a predetermined area) based on the processing status of the hash join processing unit 105, the distance calculation unit 106, and the nearest neighbor table extraction unit 107, and registers the measured processing time in the past resource data table 203.

[0102] The user interface unit 202, for example, displays a request reception screen 210 (see Figure 21) to receive information (processing request information) from the user to be requested for the address search process to be executed, and passes it to the resource matching processing unit 207. The user interface unit 202 also receives the detection results of resources that satisfy the processing request information (220A (see Figure 24), 220B (see Figure 25)) from the resource matching processing unit 207 and displays them.

[0103] The Resource Information Extraction Unit 205 extracts (collects) various information about the resources used for processing. Using the Past Resource Data Table 203, the Resource Information Extraction Unit 205 labels the number of address tables, processing time, cost, etc., to create a Labeled Past Resource Data Table 204, and extracts information about the processes actually executed in the past and the resources used for those processes from the Labeled Past Resource Data Table 204. The Resource Information Extraction Unit 205 also extracts information such as CPU type, memory capacity, number of VMs, and hash table size from the computers that actually performed processing in the past (including its own computer). The Resource Information Extraction Unit 205 also extracts the number of address tables, the number of GPS data points per day, and the Mesh ID from the Mesh ID Management Unit 103. The Resource Information Extraction Unit 205 also creates a Resource Lookup Table 206 based on the extracted information.

[0104] The resource matching processing unit 207 receives processing request information from the user interface unit 202, detects resources that match the processing request information based on the resource lookup table 206, and passes the detection results of the matching resources to the user interface unit 202. Furthermore, if the resource matching processing unit 207 receives an instruction to actually execute a process based on the resource detection results, it notifies the mesh ID generation / assignment unit 101 of the representative mesh sizes (the two mesh sizes to be used). In this case, the mesh ID generation / assignment unit 101 can execute the process using the two mesh sizes of the notified representative mesh sizes.

[0105] Next, we will explain the historical resource data table 203.

[0106] Figure 19 is a diagram showing the configuration of the historical resource data table according to the second embodiment.

[0107] The historical resource data table 203 stores various information related to past address search processes. The historical resource data table 203 stores entries for each process. The entries in the historical resource data table 203 include fields such as district 203a, number of address tables 203b, 1 day's worth of GPS data 203c, CPU type 203d, number of VMs 203e, memory 203f, processing time 203g, cost 203h, representative mesh size 203i, and hash table size 203j.

[0108] 203a contains the name of the district targeted by the process corresponding to the entry. 203b contains the number of entries in the address table for the district corresponding to the entry. 203c contains the number of entries in the GPS data for one day targeted by the process corresponding to the entry. 203d contains the type of CPU assigned to the process corresponding to the entry. 203e contains the number of VMs assigned to the process corresponding to the entry. 203f contains the memory capacity assigned to the process corresponding to the entry. 203g contains the processing time for the address search process for the target corresponding to the entry. 203h contains the cost incurred for the process corresponding to the entry. 203i contains the two mesh sizes (referred to as representative mesh sizes) used in the process corresponding to the entry. 203j contains the size of the hash table used in the process corresponding to the entry.

[0109] Next, we will describe the labeled historical resource data table 204.

[0110] Figure 20 is a diagram showing the configuration of a labeled historical resource data table according to the second embodiment.

[0111] The labeled historical resource data table 204 is a table in which data from some fields of the historical resource data table 203 has been labeled. Labeling is performed, for example, by the resource utilization information extraction unit 205.

[0112] In the labeled historical resource data table 204, the following information is labeled: address table count 203b, processing time 203g, and cost 203h.

[0113] Address table number 203b stores the number of entries in the address table for the district corresponding to the entry, and a label indicating the scale of that number of entries (e.g., large, medium, small).

[0114] Labeling of the number of addresses in the address table can be done using one of the following methods:

[0115] One method is to compare the number of entries in the address table with a fixed threshold, for example, classifying it as small if the number of entries is less than 50,000, medium if it is between 50,000 and 100,000, and large if it is 100,000 or more. A second method would be to sort each entry in the past resource data table 203 in ascending order of the number of addresses in the address table, divide the total number of entries into three groups, and label them small, medium, and large in order from the group with the smallest number of addresses in the address table. A third method would be to calculate the average number of address tables in the past resource data table 203, divide it into three groups according to the deviation from the average, and label them small, medium, and large in order from the group with the smallest number of address tables. A fourth method involves using machine learning techniques such as k-means or support vector machines to cluster data with similar numbers of address tables, classifying them into three groups. These groups can then be labeled as small, medium, and large, in descending order of the number of address tables. In this example, we are labeling the items as one of three categories: large, medium, or small. However, you could also label them as one of more than three categories.

[0116] The processing time column 203g stores the processing time for the address search process for the target corresponding to the entry, as well as a label indicating the magnitude of that processing time (e.g., high, medium, low). The label for processing time can be implemented using a similar process to the labeling of the number of address tables.

[0117] Cost 203h stores the cost incurred for processing the entry, along with a label indicating the magnitude of this cost (e.g., high, medium, low). The cost label can be implemented using a similar process to the labeling of the address table entries.

[0118] Next, we will explain the request acceptance screen 210.

[0119] Figure 21 is a diagram showing the configuration of the request reception screen according to the second embodiment.

[0120] The request reception screen 210 is a screen that receives various requests from the user for address search processing via the user I / F unit 202. The request reception screen 210 includes a city size selection area 210a, a processing time selection area 210b, a cost selection area 210c, and a priority selection area 210d. The city size selection area 210a is an area for selecting the city size of the district to be targeted by the address search processing. The processing time selection area 210b is an area for selecting the processing time request for the address search processing. The cost selection area 210c is an area for selecting the cost request for the address search processing. The priority selection area 210d is an area for selecting the request to be prioritized in the address search processing. In this embodiment, the request reception screen 210 allows the user to select at least one of city size, processing time, cost, and priority. In the example in Figure 21, the request reception screen 210 allows the user to select a request from the selection items, but it may also allow the user to directly input numerical values, etc.

[0121] Next, we will explain resource lookup table 206.

[0122] Figure 22 is a diagram showing the configuration of a resource lookup table according to the second embodiment.

[0123] The resource lookup table 206 manages information such as resources and mesh size for each request for address search processing. The resource lookup table 206 stores an entry for each request for address search processing. The entries in the resource lookup table 206 include fields for city size 206a, processing time 206b, cost 206c, priority 206d, CPU type 206e, number of VMs 206f, memory 206g, representative mesh size 206h, processing time 206i, and cost 206j.

[0124] 206a stores the size of the city targeted by the request corresponding to the entry. 206b stores the processing time request for the entry. 206c stores the cost request for the entry. 206d stores the priority conditions that should be prioritized for the request corresponding to the entry. 206e stores the CPU type required to handle the request corresponding to the entry. 206f stores the number of VMs required to handle the request corresponding to the entry. 206g stores the memory capacity required to handle the request corresponding to the entry. 206h stores the representative mesh size used to handle the request corresponding to the entry. 206i stores the estimated processing time for the request corresponding to the entry, using the resources (CPU type, number of VMs, memory capacity) and representative mesh size at the entry. 206j stores the estimated cost for the request corresponding to the entry, using the resources (CPU type, number of VMs, memory capacity) and representative mesh size at the entry.

[0125] Next, we will explain the process of creating the resource lookup table 206 by the resource information extraction unit 205.

[0126] Here, we will explain using the example of creating a resource lookup table 206 using the labeled historical resource data table 204 shown in Figure 20. In this case, the resource lookup table 206 will have multiple entries corresponding to multiple anticipated requests, and in these entries, values ​​will be set in the fields for each condition in the request (206a to 206d), while the fields related to resources, etc. (206e to 206j) will not have values ​​set.

[0127] The resource information extraction unit 205 identifies entries in the resource lookup table 206 where no values ​​are set in the resource-related fields (206e to 206j) (referred to as target entries in this explanation of the process), and obtains the values ​​for city size, processing time, and cost for the target entries.

[0128] Next, the resource utilization information extraction unit 205 identifies entries from the labeled historical resource data table 204 that correspond to the acquired values ​​for city size, processing time, and cost. For example, if the entry in the first row of the resource lookup table 206 in Figure 22 is the target entry, the resource utilization information extraction unit 205 identifies the entry for district A in the first row of the labeled historical resource data table 204, where the city size (number of address tables) is medium, the processing time is high, and the cost is medium.

[0129] Next, the resource information extraction unit 205 sets the values ​​of the CPU type 206e, VM count 206f, memory 206g, representative mesh size 206h, processing time 206i, and cost 206j fields of the target entry based on the CPU type, number of VMs, memory capacity, representative mesh size, processing time, and cost of the identified entry. This completes the creation of one entry in the resource lookup table 206.

[0130] As described above, if the entry for area A in the first row is identified, for example, CPU type 206e will be set to high, which is the value for CPU type 203d; VM count 206f will be set to 2, which is the value for VM count 203e; representative mesh size 206h will be set to 25m,100m, which are the values ​​for representative mesh size 203i; memory 206g will be set to 128GB, which is half the memory capacity of memory 203f, since priority 206d of the target entry is cost, in order to reduce the cost; processing time 206i will be set to 3.6, which is the predicted value for processing time 203g, taking into account the effect of halving the memory capacity; and cost 206j will be set to 648,000, which is the predicted value for cost 203h, taking into account the effect of halving the memory capacity.

[0131] Subsequently, the resource information extraction unit 205 performs this process on all entries in the resource lookup table 206 to create the resource lookup table 206.

[0132] Next, we will explain the detection results obtained by the resource matching processing unit 207.

[0133] Figure 23 shows an example of a district according to the second embodiment. Figure 24 shows a first example of resource detection results according to the second embodiment.

[0134] Here, as an example, in this process, as shown in Figure 23, we will perform address search processing on GPS data for each of the following areas: Area A (small city size) containing 30,000 households, Area B (large city size) containing 110,000 households, Area C (large city size) containing 150,000 households, and Area D (medium city size) containing 60,000 households. For Area A, a small city size, high processing time, and medium cost are required; for Area B, a large city size, high processing time, and medium cost are required; for Area C, a large city size, high processing time, and medium cost are required; and for Area D, a medium city size, high processing time, and medium cost are required.

[0135] In this case, the resource matching processing unit 207 refers to the resource lookup table 206 and identifies an entry for district A that is small in size, has high processing time, and medium in cost. It then obtains the CPU type, number of VMs, memory, representative mesh size, processing time, and cost for that entry. Similarly, it performs the same processing for the other districts B to D, and based on these, it creates a detection result 220A, which is then output via the user I / F unit 202.

[0136] The detection result 220A has entries for detection results for each district. Each district entry includes fields for district 220a, city size 220b, processing time 220c, cost 220d, CPU type 220e, number of VMs 220f, memory 220g, representative mesh size 220h, processing time 220i, and cost 220j.

[0137] District 220a stores the name of the district corresponding to the entry. City size 220b stores the city size request for the district corresponding to the entry. Processing time 220c stores the processing time request for the address search process for the district corresponding to the entry. Cost 220d stores the cost request for the address search process for the district corresponding to the entry. CPU type 220e stores the CPU type that satisfies the requirements for the address search process for the district corresponding to the entry. Number of VMs 220f stores the number of VMs that satisfies the requirements for the address search process for the district corresponding to the entry. Memory 220g stores the memory capacity that satisfies the requirements for the address search process for the district corresponding to the entry. Representative mesh size 220h stores the representative mesh size that satisfies the requirements for the address search process for the district corresponding to the entry. Processing time 220i stores the expected processing time when using the resources of this entry for the address search process for the district corresponding to the entry. Cost 220j stores the expected cost when using the resources of the entry for the address search process for the district corresponding to the entry. Furthermore, the detection result 220A has a total row 220k which is the sum of the processing time and cost for all areas.

[0138] In the example described above, the resource matching processing unit 207 was configured to output a detection result 220A containing an appropriate amount of resources for each district, as shown in Figure 24. However, if, for example, the cost and processing time of performing an address search on a district group made up of multiple districts is predicted and it is determined that combining multiple districts is more advantageous in terms of cost and processing time for at least some districts, then the system may output a detection result 220B containing an appropriate amount of resources for the district group made up of multiple districts, as shown in Figure 25.

[0139] Figure 25 shows a second example of the resource detection results according to the second embodiment.

[0140] Detection result 220B includes entries for the groups District A and District D, an entry for District B, and an entry for District C. The composition of the entries is the same as in detection result 220A.

[0141] Based on these detection results, it is possible to appropriately notify users of resource settings and other factors that are advantageous when combining multiple districts.

[0142] Next, a modified example of this embodiment will be described.

[0143] Figure 26 is a diagram illustrating a hash join related to a modified example.

[0144] For example, if you perform an address search using hash joins and only use the 25m mesh 301a to which location A belongs, you can find addresses a and b which belong to mesh 301a, but you cannot find addresses c which belong to mesh 301b, or address d which belong to mesh 301d, which are closer to location A than addresses a and b. In other words, there is a possibility that the address closest to location A may not be found correctly.

[0145] Therefore, in this modified example, the hash join processing unit 105 assumes a virtual frame 302 of the same size as the mesh centered on position A (25m in this example) and integrates four meshes (301a, 301b, 301c, 301d) containing the positions of each vertex of the virtual frame 302 to perform an address search using a hash join. As a result, addresses a, b, c, and d belonging to the four meshes (mesh groups) are searched as candidates, and the appropriate address can be searched (extracted) based on the distance between the positions indicated by these addresses and position A.

[0146] Next, we will explain query 303, which is used when searching for location A by integrating the four meshes shown in Figure 26.

[0147] Figure 27 illustrates an example of a query that shows the integration of the scope of the join target in a modified example.

[0148] In query 303, "lat" indicates the latitude of the location to be searched (target location: location A in the example in Figure 26), and "lng" indicates the longitude of the target location. Each SELECT statement specifies an expression to calculate the mesh ID of the mesh containing each vertex of the 25m virtual frame 302 centered on the target location.

[0149] This allows a hash join to be performed using the mesh IDs of the meshes containing each vertex of the virtual frame 302, and addresses belonging to these meshes can be searched. This enables the appropriate search for the nearest address to the target location.

[0150] It should be noted that the present invention is not limited to the embodiments described above, and can be implemented with appropriate modifications without departing from the spirit of the invention.

[0151] For example, in the above embodiment, the process for determining the mesh size to be used was based on whether the number of 100m mesh IDs in the target row of the lookup table 112 was less than or equal to the average number of 25m mesh IDs in the lookup table 112, etc. However, the present invention is not limited to this, and for example, the condition may be whether or not it is less than or equal to a predetermined multiple of the average number of 25m mesh IDs, or in short, the condition may be based on the number of 100m mesh IDs and the number of 25m mesh IDs, or the condition may be whether or not the number of 100m mesh IDs is less than or equal to a predetermined threshold.

[0152] Furthermore, in the above embodiment, some or all of the processing performed by the CPU may be performed by hardware circuits. Also, the programs constituting at least some of the functional units in the above embodiment may be installed from program source. The program source may be a program distribution server or a recording medium (for example, a portable recording medium). [Explanation of Symbols]

[0153] 10…Address search device, 12…CPU, 15…Memory, 101…Mesh ID generation / assignment unit, 102…Address table statistical analysis unit, 103…Use mesh ID management unit, 104…GPS information acquisition unit, 105…Hash join processing unit, 106…Distance calculation unit, 107…Nearest neighbor table extraction unit, 110…Address table, 111…Address table after assignment, 112…Lookup table, 113…GPS table, 114…GPS table after assignment, 115…Hash table

Claims

1. An address search device that searches for one or more addresses corresponding to coordinate information based on coordinate information, The address search device comprises a storage unit and a processor unit. The aforementioned storage unit is An address table that stores the address and the coordinate information of the said address, A hash table that manages the correspondence between the hash value of the mesh ID of a mesh and the entry in the address table of the address belonging to the mesh, A lookup table is stored that manages the correspondence between the mesh ID of a first-size mesh and information that identifies the usable mesh size, which is the size of the mesh of the mesh ID used in the hash table, and is associated with the entry in the address table for the address included in the mesh of the mesh ID. The aforementioned processor unit is The mesh ID of the first size mesh that includes the position indicated by the coordinate information is calculated. By referring to the lookup table, the usable mesh size corresponding to the calculated mesh ID is identified, Identify a mesh ID for a hash table, which is the mesh ID of the mesh of the used mesh size that includes the position indicated by the coordinate information, and refer to the hash table to identify the entry in the address table corresponding to the hash value of the mesh ID for the hash table. Identify the address based on the aforementioned identified entry. Address search device.

2. The mesh ID of the aforementioned mesh is a numerical value obtained by performing a predetermined calculation on the coordinate information of the positions included in the mesh. The address search device according to claim 1.

3. The predetermined calculation process involves multiplying the coordinate information by a predetermined value corresponding to the mesh size, and then converting it to an integer. The address search device according to claim 2.

4. The aforementioned processor unit is Based on the number of addresses in the address table belonging to each of the first-size meshes and the number of addresses in the address table belonging to the second-size meshes which are larger than the first-size meshes, the usable mesh size corresponding to each of the first-size meshes is determined and stored in the lookup table. The address search device according to claim 1.

5. The aforementioned processor unit is If the number of addresses in the address table belonging to one of the second-size meshes is greater than the average number of addresses in the address tables belonging to multiple first-size meshes, the usable mesh size corresponding to the first-size mesh belonging to one of the second-size meshes is determined to be the first size. If the number of addresses in the address table belonging to one of the second-size meshes is less than or equal to the average number of addresses in the address tables belonging to multiple first-size meshes, the usable mesh size corresponding to the first-size mesh belonging to one of the second-size meshes is determined to be the second size. The address search device according to claim 4.

6. The aforementioned processor unit is If the number of addresses in the address table belonging to one of the second-size meshes is one or more times the average number of addresses in the address tables belonging to a plurality of first-size meshes, the usable mesh size corresponding to the first-size mesh belonging to one of the second-size meshes is determined to be the first size. If the number of addresses in the address table belonging to one of the second-size meshes is less than or equal to two times the average number of addresses in the address tables belonging to a plurality of first-size meshes, the usable mesh size corresponding to the first-size mesh belonging to one of the second-size meshes is determined to be the second size. If the number of addresses in the address table belonging to one of the second-size meshes is greater than two times the average number of addresses in the address tables belonging to multiple first-size meshes, but less than one times the average number of addresses in the address tables belonging to multiple first-size meshes, the usable mesh size corresponding to the first-size mesh belonging to one of the second-size meshes is determined to be a third size between the second size and the first size. The address search device according to claim 4.

7. The aforementioned processor unit is When multiple entries are identified as entries in the address table corresponding to the hash value of the mesh ID for the hash table, Based on multiple entries, identify the address closest to the location of the coordinate information. The address search device according to claim 1.

8. The aforementioned processor unit is Instead of the mesh ID of the mesh of the used mesh size that includes the position indicated by the coordinate information, identify a group of mesh IDs of meshes included in the range of the used mesh size centered on the position indicated by the coordinate information, and refer to the hash table to identify the entry in the address table corresponding to the hash value of each of the group of mesh IDs. Identify the address based on the aforementioned identified entry. The address search device according to claim 1.

9. The aforementioned storage unit is The system stores information indicating the correspondence between the size of the region, the processing time required for address search processing, the cost, the amount of resources to be allocated for address search processing, and the first and second sizes to be used for address search processing. The aforementioned processor unit is The system receives requests from the user regarding at least one of the following: the size of the region where correspondences are stored in the memory unit, the processing time required for the address search process, and the cost. Based on the above request, the amount of resources to be allocated to the address search process and / or the first and second sizes to be used are identified. The address search process is executed using the specified resource amount and / or the first and second sizes. The address search device according to claim 1.

10. An address search method using an address search device that searches for one or more addresses corresponding to coordinate information based on the coordinate information, The address search device described above is An address table that stores the address and the coordinate information of the said address, A hash table that manages the correspondence between the hash value of the mesh ID of a mesh and the entry in the address table of the address belonging to the mesh, A lookup table is stored that manages the correspondence between the mesh ID of a first-size mesh and information that identifies the usable mesh size, which is the size of the mesh of the mesh ID used in the hash table, and is associated with the entry in the address table for the address included in the mesh of the mesh ID. The address search device described above is The mesh ID of the first size mesh that includes the position indicated by the coordinate information is calculated. By referring to the lookup table, the usable mesh size corresponding to the calculated mesh ID is identified, Identify a mesh ID for a hash table, which is the mesh ID of the mesh of the used mesh size that includes the position indicated by the coordinate information, and refer to the hash table to identify the entry in the address table corresponding to the hash value of the mesh ID for the hash table. Identify the address based on the aforementioned identified entry. How to search for an address.

11. An address search program to be executed by a computer constituting an address search device that searches for one or more addresses corresponding to the coordinate information based on the coordinate information, The aforementioned computer, An address table that stores the address and the coordinate information of the said address, A hash table that manages the correspondence between the hash value of the mesh ID of a mesh and the entry in the address table of the address belonging to the mesh, It stores a lookup table that manages the correspondence between the mesh ID of a first-size mesh and information that identifies the usable mesh size, which is the size of the mesh of the mesh ID used in the hash table, and is associated with the entry in the address table for the address included in the mesh of the mesh ID. The aforementioned address search program, To the aforementioned computer, The mesh ID of the first size mesh, which includes the position indicated by the coordinate information, is calculated. By referring to the aforementioned lookup table, the mesh size to be used corresponding to the calculated mesh ID is identified. The system identifies a mesh ID for a hash table, which is the mesh ID of the mesh of the used mesh size that includes the position indicated by the coordinate information, and refers to the hash table to identify the entry in the address table corresponding to the hash value of the mesh ID for the hash table. The address is identified based on the aforementioned identified entry. Address search program.

Images