Spatial information management device and spatial information management method
The spatial information management device and method convert spatial shapes into spatial IDs using primary and secondary filters, addressing the complexity of real-time sensor notification in three-dimensional environments by reducing management efforts and enhancing data processing efficiency.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- HITACHI LTD
- Filing Date
- 2024-12-05
- Publication Date
- 2026-06-17
AI Technical Summary
Existing systems for real-time notification of sensor information in three-dimensional spatial environments become complex and require excessive maintenance due to the specification of various spatial shapes, leading to increased management man-hours.
A spatial information management device and method that converts spatial shapes into spatial IDs, using primary and secondary filters to process sensor information in real-time while minimizing management efforts, employing a processor, memory, and external sensors to manage and filter data efficiently.
Enables real-time notification of sensor information corresponding to various spatial shapes without significantly increasing management man-hours, optimizing system maintenance and data processing efficiency.
Smart Images

Figure 2026098340000001_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to a spatial information management device and a spatial information management method.
Background Art
[0002] For example, in order to realize automatic control and remote control of a flying object such as a drone, it is important to notify a control system that controls the flying object of sensor information such as weather information, radio wave conditions, and obstacles associated with a three-dimensional space in real time.
[0003] As the background art in this technical field, there is U.S. Patent No. 12038895 (Patent Document 1). The technology described in Patent Document 1 searches for time-series data on a three-dimensional space at high speed using a spatio-temporal hash. The spatio-temporal hash is a hash value that combines a horizontal GeoHash, a vertical hash, and a time hash, and by combining it with a tree structure or a bitmap, the search for spatio-temporal data is accelerated.
Prior Art Documents
Patent Documents
[0004]
Patent Document 1
Summary of the Invention
Problems to be Solved by the Invention
[0005] Patent Document 1 describes a method for accelerating geospatial data search and data search on a three-dimensional spatio-temporal space. However, since the technology described in Patent Document 1 assumes the use of a database, when various spatial shapes are specified from a client, the internal implementation of the system for notifying sensor information in real time becomes complicated, and thus the maintenance management work of the system may increase.
[0006] Therefore, one aspect of the present invention enables real-time notification processing of sensor information corresponding to various spatial shapes while suppressing an increase in management man-hours. [Means for solving the problem]
[0007] To solve the above problems, one aspect of the present invention adopts the following configuration. The spatial information management device comprises a processor and a memory, and is connected to an external system and a sensor that acquires sensor information including sensor values linked to three-dimensional position information. The memory each holds one or more spatial conditions that are specified by the external system and indicate a spatial shape. The processor converts the spatial shape indicated by each of the one or more spatial conditions into a spatial ID, generates a primary filter common to the one or more spatial conditions based on the spatial ID, generates a secondary filter indicating each of the one or more spatial conditions, receives the sensor information from the sensor, performs primary filtering on the received sensor information using the primary filter, then performs secondary filtering using the secondary filter to generate filtered sensor information, and notifies the external system of the information indicating the filtered sensor information. [Effects of the Invention]
[0008] According to one aspect of the present invention, real-time notification processing of sensor information corresponding to various spatial shapes can be realized while suppressing an increase in management man-hours.
[0009] Other issues, configurations, and effects not mentioned above will be clarified by the following description of the embodiments. [Brief explanation of the drawing]
[0010] [Figure 1] This figure shows an example of the functional configuration of the spatial information management system in Example 1. [Figure 2] This block diagram shows a detailed configuration example of the notification unit, API (Application Programming Interface) unit, and API condition registration unit in Example 1. [Figure 3] This is a block diagram showing a detailed configuration example of the spatial condition integration transformation unit in Example 1. [Figure 4] This is a block diagram showing an example of the hardware configuration of the spatial information management server in Example 1. [Figure 5] This flowchart shows an example of the API reception process in Example 1. [Figure 6] This figure shows an example of the data structure of the common space condition table in Example 1. [Figure 7] This figure shows an example of the data structure of the common spatial condition table in which spatial IDs are aggregated in Example 1. [Figure 8A] This is an explanatory diagram showing a first configuration example of an index having a bitmap data structure in Example 1. [Figure 8B] This is an explanatory diagram showing a second configuration example of an index having a bitmap data structure in Example 1. [Figure 9A] This is an explanatory diagram showing a first example of the configuration of the tree structure index in Example 1. [Figure 9B] This is an explanatory diagram showing a second example of the configuration of the tree structure index in Example 1. [Figure 10] This flowchart shows an example of the sensor information update process in Example 1. [Modes for carrying out the invention]
[0011] Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. In this embodiment, the same components will be denoted by the same reference numerals in principle, and repeated descriptions will be omitted. It should be noted that this embodiment is merely one example for realizing the present invention and does not limit the technical scope of the present invention. [Examples]
[0012] FIG. 1 is a diagram showing a functional configuration example of a spatial information management system 1. The spatial information management system 1 includes, for example, a client 100, a spatial information management server 200, and one or more sensors 300. The spatial information management server 200 is connected to the client 100 and the sensors 300 via a network such as the Internet. The spatial information management server 200 is an example of a spatial information management device.
[0013] Each of the sensors 300 acquires sensor information including three-dimensional position information, time, and sensor values, and transmits it to the spatial information management server 200. Weather conditions (such as precipitation, wind conditions, and temperature), radio wave conditions of wireless, and the presence or absence of obstacles are all examples of sensor values acquired by the sensors 300.
[0014] The client 100 is a computer such as a PC (Personal Computer), and requests data acquisition from the spatial information management server 200 via an API (Application Programming Interface). When requesting data acquisition, the client 100 specifies spatial conditions. The client 100 is an example of an external system for the spatial information management server 200.
[0015] The spatial conditions indicate a spatial shape (such as a polygon, line, point, and / or range of spatial IDs) on a three-dimensional space. The client 100 acquires sensor information that matches the conditions from the spatial information management server 200. Note that the spatial conditions may indicate not only the spatial shape but also a time range.
[0016] The spatial shape in the spatial conditions is specified by, for example, a plurality of points on the space defined by latitude, longitude, and altitude, and the way of connecting the plurality of points (such as a polygon or a line). Also, for example, the spatial shape in the spatial conditions may be specified by a cylinder which is an example of a specific shape, two points on the space (the centers of both bottom surfaces of the cylinder), and the length of the radius of the bottom surface of the cylinder.
[0017] Furthermore, the spatial shape in the spatial conditions may be specified by one or more spatial IDs, as described later, or by the range of the minimum and maximum values of z, f, x, and y that constitute the spatial ID. In this way, the spatial shape indicated by the spatial conditions shown in this embodiment indicates not only the shape itself, but also the position in which the shape is placed and the size of the shape, etc.
[0018] The spatial information management server 200 includes, for example, an API unit 210, a cache storage unit 220, a notification unit 240, an API condition registration unit 250, and a data conversion unit 260, all of which are functional units. The spatial information management server 200 also includes a database 230 for storing data.
[0019] The data conversion unit 260 calculates a spatial ID corresponding to the three-dimensional position information (indicated by latitude, longitude, and altitude, etc.) contained in the sensor information received from the sensor 300, and assigns the calculated spatial ID to the received sensor information. The spatial ID is, for example, an ID assigned to each region when the three-dimensional space is divided into multiple regions, and the space indicated by the spatial ID is uniquely identified. Methods for dividing the three-dimensional space include equal division using boxes (spatial voxels) and division using Geohash.
[0020] The data conversion unit 260 converts the received sensor information into a format that can be stored in the database 230 and / or processed by the notification unit 240. The data conversion unit 260 performs processing such as normalization and numerical correction of the values contained in the received sensor information. The format includes, for example, JSON (JavaScript® Object Notation), CSV (Comma Separated Values), protobuf (Protocol Buffers), and database queries. The data conversion unit 260 stores the sensor information it has processed in the database 230 and transmits it to the notification unit 240.
[0021] The database 230 stores sensor information in a format that associates sensor values (e.g., wind speed and wind direction) with latitude, longitude, altitude, and spatial IDs that indicate the spatial information for which the sensor values pertain. Furthermore, if the database 230 is PostgreSQL, it may also store Geometry type data corresponding to the spatial IDs to simplify and speed up the search process.
[0022] Furthermore, the API process described later may, for example, obtain sensor information from database 230 by searching database 230 with a specified target space ID, or it may first convert the spatial shape specified as a search condition to Geometry type, then compare it with Geometry type data in the sensor information of database 230, and obtain intersecting sensor information.
[0023] The notification unit 240 receives sensor information from the data conversion unit 260, filters the sensor information to be notified based on the spatial shape information received from the API condition registration unit 250, and transmits it to the API unit 210.
[0024] The cache holding unit 220 holds sensor information notified to the API from the notification unit 240 as a cache. When the API process requires aggregation processing, the API unit 210 combines the sensor information notified from the notification unit 240 with the cache of the cache holding unit 220 and aggregates them to perform the aggregation processing.
[0025] Since there is an upper limit to the data size that the notification unit 240 can notify at once, for example, if the spatial shape or time range in the spatial conditions specified by the API process is wide, the API unit 210 needs to combine sensor information from multiple notifications and perform aggregation processing. To realize this aggregation processing, the cache holding unit 220 holds the sensor information as a cache. This enables the API unit 210 to combine and aggregate sensor information from multiple notifications.
[0026] The API unit 210 accepts API connections from the client 100. The API unit 210 includes an API process and sends the spatial conditions specified by the API process to the API condition registration unit 250, which then sends the spatial conditions to the notification unit 240.
[0027] Furthermore, the API unit 210 switches between obtaining sensor information by searching the database 230 or obtaining sensor information from the notification unit 240, based on spatial conditions corresponding to the API process.
[0028] Generally, accessing the database 230 involves accessing slow hardware and a search process to find the data to be retrieved from a large amount of data, resulting in a long data retrieval time. In contrast, the notification unit 240 can immediately notify the API process of updated sensor information without going through the database 230, thus reducing the data retrieval time.
[0029] On the other hand, the notification unit 240 is not suitable for transmitting large amounts of data compared to the database 230, as it notifies sensor information as a message. Therefore, when the client 100 checks weather forecasts along a sea route, for example, real-time information is not required, so it uses an API to retrieve information from the database 230.
[0030] When client 100 acquires real-time sensor information, it uses an API to acquire sensor information from notification unit 240. Situations in which client 100 utilizes real-time sensor information include, for example, situations where the sensor information is visualized on the screen, or situations where the aircraft is controlled when an obstacle is detected.
[0031] In the former scenario, a protocol is used as the API, such as the REST (Representational State Transfer) API, in which the connection between the spatial information management server 200 and the client 100 is terminated after a response is received to the data retrieval request.
[0032] In the latter scenario, a protocol is used that maintains the connection between the spatial information management server 200 and the client 100 even after the client 100 has sent a data acquisition request to the spatial information management server 200, and allows the spatial information management server 200 to send data over the maintained connection at any time, such as WebSocket or gRPC (Remote Procedure Call) Streaming.
[0033] Figure 2 is a block diagram showing a detailed configuration example of the notification unit 240, the API unit 210, and the API condition registration unit 250. The API unit 210, for example, starts the same number of API processes 211 as the number of APIs connected from the client 100. Each API process 211 includes a secondary filter 212. The secondary filter 212 is a filter based on the spatial shape indicated by the spatial conditions specified by the API, and is different for each API process 211.
[0034] The API condition registration unit 250 includes a spatial condition integration and conversion unit 251, which is a functional unit. The spatial condition integration and conversion unit 251 converts the spatial conditions specified by each API process 211 into spatial IDs and sends these spatial IDs to the notification unit 240.
[0035] The notification unit 240 includes a primary filter unit 241, which is a functional unit. The primary filter unit 241 includes, for example, a notification destination API information storage unit 242, a common space condition table 243, and an index 244.
[0036] The common spatial condition table 243 holds spatial IDs received from the API condition registration unit 250. The notification unit 240 registers information indicating the API process 211 to which the sensor information is to be notified (for example, the destination of the API process 211) in the notification destination API information storage unit 242. The primary filter unit 241 generates an index 244, which is a data structure for filtering sensor information, based on the spatial ID conditions held in the common spatial condition table 243.
[0037] While the secondary filter 212 is a module maintained for each API process 211 (a filter that indicates the spatial conditions for each API process 211), the primary filter 241 is a module common to all APIs (a filter that indicates spatial conditions common to all APIs).
[0038] When the spatial information management server 200 receives sensor information from the sensor 300, the sensor information is transmitted to the notification unit 240 via the data conversion unit 260 and processed by the primary filter unit 241 of the notification unit 240.
[0039] The primary filter unit 241 performs a search using the index 244 and selects only sensor information that (may) need to be notified to at least one API process 211.
[0040] The notification unit 240 notifies the API processes 211 registered in the notification destination API information storage unit 242 of the sensor information selected by the primary filter unit 241. At this time, the same sensor information is notified to all API processes 211. Each API process 211 filters the received sensor information using its own secondary filter 212, obtains sensor information that matches the spatial shape conditions indicated by the spatial conditions specified by the API, and transmits the sensor information to the client 100 via the API.
[0041] As described above, by making the notification unit 240 a common module for all APIs and standardizing the filtering process of the notification unit 240 across all APIs, it is possible to prevent changes to the implementation of the notification unit 240 even when multiple APIs specify different spatial shapes in spatial conditions.
[0042] Furthermore, the notification unit 240 performs filtering using a primary filter unit 241 common to all APIs, and each API process 211 obtains sensor information of the spatial shape specified by the API from the filtered sensor information using a secondary filter 212. This reduces the amount of data notified from the notification unit 240 to the API unit 210, while also reducing the search processing load on the secondary filter 212, enabling real-time filtering.
[0043] Furthermore, by separating the spatial conditions between the API and the notification unit 240, it becomes possible to implement the notification unit 240 without depending on the OSS (Open Source Software) used by the API.
[0044] Figure 3 is a block diagram showing a detailed configuration example of the spatial condition integration and transformation unit 251. The spatial condition integration and transformation unit 251 includes a database linkage module 252 and an OSS module 253, both of which are functional units.
[0045] The database integration module 252 converts the spatial shape under the spatial conditions specified by the API into a spatial ID by referring to the spatial ID conversion table 231 stored in the database 230. The spatial ID conversion table 231 shows, for example, the range of latitude, longitude, and altitude belonging to each spatial ID.
[0046] The database integration module 252 enables the conversion of a specified spatial shape into a spatial ID when a spatial shape that assumes the use of a database 230, such as PostGIS (Post Geographic Information System), is specified. The OSS module 253 performs the conversion to a spatial ID using open-source software (such as Python®) other than the database 230.
[0047] Figure 4 is a block diagram showing an example of the hardware configuration of the spatial information management server 200. The spatial information management server 200 is composed of a computer having a CPU (Central Processing Unit) 1001, memory 1002, auxiliary storage device 1003, communication device 1004, and input / output interface 1005, which are connected to each other by internal communication lines such as a bus.
[0048] The CPU 1001 is an example of a processor that executes programs stored in memory 1002. Memory 1002 includes non-volatile memory elements such as ROM (Read Only Memory) and volatile memory elements such as RAM (Random Access Memory). ROM stores immutable programs (e.g., BIOS (Basic Input / Output System)). RAM is a high-speed, volatile memory element such as DRAM (Dynamic Random Access Memory) that temporarily stores programs executed by the CPU 1001 and data used during program execution.
[0049] The auxiliary storage device 1003 is a high-capacity, non-volatile storage device such as a magnetic storage device (HDD (Hard Disk Drive)) or flash memory (SSD (Solid State Drive)), and stores the program executed by the CPU 1001 and the data used when the program is executed. In other words, the program is read from the auxiliary storage device 1003, loaded into memory 1002, and executed by the CPU 1001.
[0050] The communication device 1004 is a network interface device that controls communication with other devices according to a predetermined protocol. The communication device 1004 may also include a serial interface such as USB (Universal Serial Bus).
[0051] The input / output interface 1005 is an interface device for connecting to input and output devices. Input devices are devices that receive input from the operator, such as a keyboard or mouse. Output devices are devices that output the results of program execution in a format that the operator can see, such as a display device or printer.
[0052] Some or all of the program executed by the CPU 1001 may be provided to the spatial information management server 200 via a network from an external computer equipped with a non-temporary storage medium such as removable media (CD-ROM, flash memory, etc.) or non-temporary storage device, and stored in the non-volatile auxiliary storage device 1003, which is also a non-temporary storage medium. For this reason, the spatial information management server 200 may have an interface for reading data from the removable media.
[0053] The spatial information management server 200 is a computer system that is physically located on a single computer or on multiple computers configured logically or physically. It may operate in separate threads on the same computer, or it may operate on a virtual computer built on multiple physical computer resources.
[0054] The CPU 1001 has the functional units described above. For example, the CPU 1001 functions as a data conversion unit 260 by operating according to a data conversion program loaded into memory 1002, and functions as a notification unit 240 by operating according to a notification program loaded into memory 1002. The relationship between the program and the functional unit is similar for the other functional units included in the CPU 1001.
[0055] Furthermore, some or all of the functions performed by the aforementioned functional unit may be implemented by dedicated hardware such as an ASIC (Application Specific Integrated Circuit) or an FPGA (Field-Programmable Gate Array).
[0056] The database 230 is implemented by a storage area on memory 1002 or auxiliary storage device 1003. In this embodiment, the information used by the spatial information management system 1 is independent of the data structure and can be represented in any data structure. For example, a data structure appropriately selected from tables, lists, databases, or queues can store the information.
[0057] Figure 5 is a flowchart showing an example of API reception processing. API reception processing is the process executed when client 100 connects to spatial information management server 200 via API.
[0058] Step S301: The spatial information management server 200 receives an API connection request from the client 100. The API connection request includes the spatial conditions that the client 100 wants to obtain (i.e., information on the spatial shape and time range in 3D space).
[0059] Step S302: The API unit 210 creates an API process 211 in response to an API connection request from client 100. The API process 211 registers the spatial conditions included in the API connection request as its secondary filter 212.
[0060] Step S303: The API unit 210 determines whether the API requests immediate notification. If the API unit 210 determines that the API requests immediate notification, it proceeds to step S304; otherwise, it proceeds to step S320.
[0061] The API unit 210 determines whether the API requests immediate notification, for example, from flag information in the API's fields or the API's protocol type. For example, the API unit 210 determines that immediate notification is not requested if REST API is used as the API's protocol type, and that immediate notification is requested if WebSocket or gRPC Streaming is used.
[0062] Step S304: The API unit 210 sends the spatial conditions included in the API connection request received in step S301 and the destination of the API process 211 created in step S302 to the API condition registration unit 250. The spatial condition integration conversion unit 251 of the API condition registration unit 250 converts the spatial shape indicated by the spatial conditions into (one or more) spatial IDs, and then sends the spatial conditions and the destination to the notification unit 240. The spatial condition integration conversion unit 251 identifies, for example, the minimum number of spatial IDs that encompass the entire region indicated by the spatial shape (the zoom level of the spatial IDs is predetermined, such as by specifying it in the API or by the user of client 100), and converts the spatial shape into the set of spatial IDs.
[0063] Step S305: The notification unit 240 registers the received spatial conditions and information indicating the API corresponding to those spatial conditions in the common spatial conditions table 243.
[0064] Step S306: The primary filter unit 241 determines whether the space IDs on the common space condition table 243 can be aggregated. If the primary filter unit 241 determines that the space IDs can be aggregated, it proceeds to step S307; otherwise, it proceeds to step S308. Details of the determination process in step S306 will be described later with reference to Figures 6 and 7.
[0065] Step S307: The primary filter unit 241 performs aggregation processing of the spatial IDs in the common spatial condition table 243. Details of the aggregation processing in step S307 will be described later with reference to Figures 6 and 7.
[0066] Step S308: The primary filter unit 241 creates an index 244 based on the information in the common space condition table 243. Specific examples of the index 244 will be described later using Figures 8A, 8B, 9A, and 9B.
[0067] Step S309: The primary filter unit 241 registers the destination of the API process 211 received from the API condition registration unit 250 as a notification destination, and the API unit 210 terminates the API acceptance process without disconnecting the API connection with the client 100.
[0068] Step S320: The API unit 210 obtains sensor information from the database 230 that matches the spatial conditions specified by the API.
[0069] Step S321: The API unit 210 transmits the sensor information acquired in step S320 to the client 100.
[0070] Step S322: The API unit 210 disconnects the API connection with client 100 and terminates the API reception process.
[0071] Figure 6 shows an example of the data structure of the common spatial conditions table 243. The common spatial conditions table 243 includes, for example, a corresponding API column 2431, a spatial ID column 2432, and a time range column 2433.
[0072] The corresponding API field 2431 indicates the API corresponding to the spatial conditions shown in the spatial ID field 2432 and the time range field 2433. The spatial ID field 2432 indicates the spatial ID obtained by the spatial condition integration conversion unit 251, which converts the spatial shape under the spatial conditions specified by the API. The time range field 2433 indicates the time range under the spatial conditions specified by the API, that is, the time range that the API has designated as the target for acquiring sensor information.
[0073] As an example of a spatial ID format, there is the z / f / x / y format, where a vertical index is assigned to an XYZ tile that uniquely determines the horizontal geographic location. Z refers to the zoom level (which can be said to be an index indicating the degree of reduction, or an index indicating the spatial granularity), and f, x, and y represent the indices in the height, longitude, and latitude directions, respectively.
[0074] The formulas for each index are as follows. In the following formulas, lng represents longitude and lat represents latitude.
[0075] x = floor(n * ((lng + 180) / 360)) ... (Equation 1) y=floor(n*(1-log(tan(lat)+(1 / cos(lat))) / π) / 2)...(Equation 2) f = floor(n*h / H) ... (Equation 3) h=height [m]...(Formula 4) n=2^z...(Formula 5) H=2^25...(Formula 6)
[0076] Furthermore, the spatial ID may be defined not in the z / f / x / y format, but as a combination of two hash values: a GeoHash that uniquely determines the horizontal position range, and a hash that indicates the vertical position range. For example, if the vertical range is repeatedly divided into two parts, a hash string is assigned to each vertical range at each division level (number of divisions), and the length of the hash string differs depending on the number of divisions (i.e., similar to GeoHash, the length of the hash string indicates the height precision). This defines a hash that indicates the vertical position range.
[0077] Figure 7 shows an example of the data structure of the common spatial condition table 243, in which spatial IDs are aggregated. The common spatial condition table 243 in Figure 7 is a table obtained by aggregating the spatial IDs in the common spatial condition table 243 in Figure 6.
[0078] The common spatial condition table 243 in Figure 6 contains many records with spatial IDs that have a dense spatial granularity (large z value (z value is 18 in the example in Figure 6)), which may increase the size of the index 244 and degrade search performance. Therefore, the primary filter unit 241 may consolidate the spatial IDs in multiple records into a single record by aggregating them into spatial IDs with a coarser spatial granularity (smaller z value).
[0079] An example of spatial ID aggregation when the spatial ID is in z / f / x / y format is described below. The spatial ID for the zoom level one level lower (i.e., with z reduced by 1) that encompasses the region indicated by the z / f / x / y format spatial ID is obtained by combining the values of x, y, and f divided by 2, along with z, as shown in (Equations 1) to (3) and (5).
[0080] For example, the primary filter unit 241 selects the maximum zoom level (value of z) in the common spatial condition table 243, and aggregates the spatial IDs of the selected zoom level that, when converted to a spatial ID of one lower zoom level (with a predetermined level of coarser spatial granularity) that encompasses the selected spatial ID, result in the same spatial ID and satisfy a predetermined condition. The predetermined condition is that a predetermined percentage (0 or more and less than 1) of the area (volume) of the area indicated by the spatial ID of the lower zoom level is occupied by the area indicated by the spatial ID before conversion. Furthermore, if the converted spatial ID already exists in the common spatial condition table 243, the primary filter unit 241 aggregates the spatial ID before conversion to the already existing spatial ID. The primary filter unit 241 repeats the above process while decreasing the value of the selected zoom level (value of z) by one step at a time.
[0081] The smaller the predetermined ratio, the more records are aggregated, thus speeding up the filtering process by the primary filter unit 241. However, since a wider area is specified by the common spatial condition table 243, there is a higher possibility that sensor information unnecessary for all API processes 211 will pass through the primary filter unit 241 and be notified to the API unit 210. Conversely, the larger the predetermined ratio, the fewer records are aggregated, thus suppressing the speedup of the filtering process by the primary filter unit 241. However, since the area specified by the common spatial condition table 243 becomes smaller, there is a lower possibility that sensor information unnecessary for all API processes 211 will pass through the primary filter unit 241 and be notified to the API unit 210. Therefore, the predetermined ratio should be set considering these trade-offs.
[0082] Let's explain a specific example of aggregation processing. In Figure 6, the zoom level of the spatial IDs shown in records 2434, 2435, 2436, and 2437 of the common spatial condition table 243 is z=18. The primary filter unit 241 converts each of the spatial IDs of records 2434, 2435, 2436, and 2437 of the common spatial condition table 243 to a spatial ID of z=17, resulting in "17 / 1 / 116422 / 51615".
[0083] Furthermore, it is assumed that a predetermined percentage (for example, 50%) or more of the region indicated by the spatial ID "17 / 1 / 116422 / 51615" is occupied by the region indicated by the spatial ID of the group of records z=18, including records 2434, 2435, 2436, and 2437 of the common spatial condition table 243 in Figure 6.
[0084] Therefore, the primary filter unit 241 aggregates the record group into record 2438 of the common spatial condition table 243 in Figure 7. Specifically, for example, the primary filter unit 241 includes all corresponding APIs included in the record group in the corresponding API field 2431 of record 2438, includes "17 / 1 / 116422 / 51615" in the spatial ID field 2432 of record 2438, and includes the union of all time ranges included in the record group in the time range field 2433 of record 2438. The primary filter unit 241 also deletes the record group before aggregation.
[0085] This section describes an example of spatial ID aggregation when the spatial ID is defined as a combination of two hash values: a GeoHash and a height-direction hash. When using a GeoHash as the base, a spatial ID with a coarser spatial granularity can be calculated by shortening the hash string by one step. Other processing steps are the same as for aggregating spatial IDs in z / f / x / y format.
[0086] Figure 8A is an explanatory diagram showing a first configuration example of an index 244 having a bitmap data structure. The index 244 in Figure 8A has a bitmap data 800 structure in which the spatial ID, which is the search condition, is converted into a hash value, and the bit position corresponding to the hash value is set to 1.
[0087] This type of data structure is called a bloom filter. It is suitable for fast filtering, but because it is a probabilistic data structure, it can produce false positives (data that does not meet the criteria is judged to meet the criteria), but it does not produce false negatives (data that does meet the criteria is judged to not meet the criteria).
[0088] In this embodiment, the amount of data is reduced by filtering by the primary filter unit 241, and accurate data matching the conditions is obtained by filtering by the secondary filter 212. Therefore, the above-mentioned characteristics of high speed and tolerance of false positives are considered suitable. The structure of index 244 in Figure 8A is applicable whether the spatial ID is in z / f / x / y format or GeoHash format.
[0089] Figure 8B is an explanatory diagram showing a second configuration example of index 244 having a bitmap data structure. In Figure 8A, an example was shown in which spatial IDs are stored as a single bitmap data 800. However, when the number of spatial IDs to be acquired is large, most of the bits in the bitmap data 800 become 1, which may reduce the effectiveness of reducing the amount of data.
[0090] Therefore, as shown in Figure 8B, by dividing the spatial ID into z, f, x, and y units, and having index 244 have bitmap data 801, bitmap data 802, bitmap data 803, and bitmap data 804 corresponding to z, f, x, and y respectively, it becomes possible to have a larger bitmap address space, thereby suppressing the decrease in the effect of reducing the amount of data.
[0091] In the example above, we showed the case where the spatial ID is in z / f / x / y format. However, when combining two hashes, GeoHash and a hash in the height direction, the resulting configuration will have two bitmap data: bitmap data for the horizontal GeoHash and bitmap data for the hash value in the height direction.
[0092] Figure 9A is an explanatory diagram showing a first example of the structure of index 244 in a tree structure. Figure 9A shows an example where the spatial ID is expressed in z / f / x / y format. Index 244 in Figure 9A has tree structures 2001, 2002, 2003, and 2004 corresponding to z, f, x, and y respectively, and each value is searched using tree structures 2001 to 2004. Although Figure 9A shows an example of a binary tree, a multi-tree structure with multiple branches is also acceptable.
[0093] Figure 9B is an explanatory diagram showing a second example of the structure of the tree-structured index 244. Figure 9B also shows an example where the spatial ID is represented by a combination of two hash values: a GeoHash and a hash value in the height direction. The index 244 in Figure 9B has a GeoHash and a hash in the height direction, and corresponding tree structures 2011 and 2012. In tree structures 2011 and 2012, the nodes of the tree hold hash strings of one or more characters, and by traversing the nodes from the top of the tree, it is possible to search for the spatial ID by prefix matching.
[0094] Figure 10 is a flowchart showing an example of the sensor information update process. The sensor information update process is executed, for example, whenever sensor information is notified to the spatial information management server 200.
[0095] Step S401: The spatial information management server 200 receives sensor information from the sensor 300.
[0096] Step S402: The data conversion unit 260 performs data conversion processing of the received sensor information (including processing to convert position information into spatial IDs).
[0097] Step S403: The data conversion unit 260 writes the converted sensor information to the database 230 and transmits the converted sensor information to the notification unit 240.
[0098] Step S404: The primary filter unit 241 determines whether one or more API processes 211 are registered in the notification destination API information storage unit 242. If the primary filter unit 241 determines that one or more API processes 211 are registered in the notification destination API information storage unit 242, it proceeds to step S405; otherwise, it terminates the sensor information update process.
[0099] Step S405: The primary filter unit 241 filters the received sensor information using the index 244 (primary filtering).
[0100] Step S406: The primary filter unit 241 notifies all API processes 211 registered in the notification destination API information storage unit 242 of the sensor information that has passed the primary filtering (matches the search by index 244). If there is no sensor information that has passed the primary filtering, the processing from step S406 onwards is omitted.
[0101] Step S407: For each API process 211 included in the API unit 210, the processing in steps S408 to S412 is executed. Once the processing in steps S408 to S412 has been completed for all API processes 211, the sensor information update process is terminated.
[0102] Step S408: The API process 211 filters the notified sensor information using the secondary filter 212 that the API process 211 has (secondary filtering).
[0103] Step S409: The API process 211 determines whether the information retrieved by the API (the information retrieved is predetermined, for example) includes aggregation processing. If the API process 211 determines that the information retrieved by the API includes aggregation processing, it proceeds to step S410; otherwise, it proceeds to step S412. If there is no sensor information that has passed the secondary filtering, the processing from step S409 onwards is omitted.
[0104] Step S410: The API process 211 performs aggregation processing as indicated by the API information acquisition content, using the necessary information from the cache data held by the cache holding unit 220 and the sensor information (an example of filtered sensor information) that has passed secondary filtering (matching the spatial conditions corresponding to the API process 211). If the API process 211 lacks the sensor information necessary for the aggregation processing, it skips the processing in step S410 and proceeds to step S411.
[0105] Step S411: The API process 211 updates the cache data in the cache holding unit 220 by adding the sensor information that has passed the secondary filtering to the cache data.
[0106] Step S412: The API process 211 notifies the client 100 of the sensor information and / or the results of the aggregation process in step S410 via the API connection generated in step S302 when the API connection request is made.
[0107] In the example described above, the processes from step S404 onwards are executed after the write operation to the database 230 in step S403. However, the write operation to the database 230 in step S403 and the processes from step S404 onwards may be executed in parallel.
[0108] As described above, the spatial information management server 200 according to this embodiment converts the spatial shape indicated by the spatial conditions specified by the client 100 into a spatial ID, and performs a filtering process that combines a high-speed primary filter based on the spatial IDs of multiple spatial conditions and a secondary filter 212 corresponding to each of the spatial IDs of the multiple spatial conditions, thereby enabling real-time notification processing that supports diverse spatial shapes without requiring significant implementation and operational effort.
[0109] Furthermore, because the primary filter is a fast filter that tolerates false positives, and the secondary filter 212 is a slow but accurate filter, it is possible to reduce the amount of data processed by the secondary filter 212 while achieving high-speed filtering.
[0110] It should be noted that the present invention is not limited to the embodiments described above, and various modifications are included. For example, the embodiments described above are described in detail to make the present invention easier to understand, and are not necessarily limited to those having all the configurations described. It is also possible to replace parts of the configuration of one embodiment with the configuration of another embodiment, and it is also possible to add configurations from other embodiments to the configuration of one embodiment. Furthermore, it is possible to add, delete, or replace parts of the configuration of each embodiment with other configurations.
[0111] Furthermore, each of the above configurations, functions, processing units, and processing means may be implemented in hardware, either partially or entirely, by designing them as integrated circuits, for example. Alternatively, each of the above configurations and functions may be implemented in software by having the processor interpret and execute programs that implement each function. Information such as programs, tables, and files that implement each function can be stored in memory, a recording device such as a hard disk or SSD (Solid State Drive), or a recording medium such as an IC card, SD card, or DVD.
[0112] Furthermore, the control lines and information lines shown are those deemed necessary for explanatory purposes, and not all control lines and information lines are necessarily shown in the actual product. In reality, it is safe to assume that almost all components are interconnected. [Explanation of symbols]
[0113] 100 Client, 200 Spatial Information Management Server, 210 API Unit, 211 API Process, 212 Secondary Filter, 220 Cache Holding Unit, 230 Database, 240 Notification Unit, 241 Primary Filter Unit, 243 Common Spatial Condition Table, 244 Index, 250 API Condition Registration Unit, 260 Data Conversion Unit, 300 Sensor, 1001 CPU, 1002 Memory, 1003 Auxiliary Storage Device, 1004 Communication Device, 1005 Input / Output Interface
Claims
1. A spatial information management device, Equipped with a processor and memory, It is connected to an external system and a sensor that acquires sensor information including sensor values linked to 3D position information. Each of the aforementioned memories holds one or more spatial conditions that are specified by the external system and represent a spatial shape. The aforementioned processor, The spatial shape indicated by each of the above one or more spatial conditions is converted into a spatial ID. Based on the aforementioned spatial ID, a primary filter common to the one or more spatial conditions is generated. A quadratic filter is generated that represents each of the one or more spatial conditions mentioned above. The sensor information is received from the aforementioned sensor, The received sensor information is subjected to primary filtering by the primary filter, and then secondary filtering by the secondary filter to generate filtered sensor information. A spatial information management device that notifies the external system of information indicating the filtered sensor information.
2. A spatial information management device according to claim 1, The aforementioned processor, The primary filter is generated by aggregating multiple spatial IDs that satisfy predetermined conditions and have the same spatial granularity, The predetermined condition includes that, when each of the plurality of spatial IDs is converted to a spatial ID with a predetermined level of coarseness, the region indicated by the plurality of spatial IDs occupies a predetermined proportion or more of the region indicated by the converted spatial ID.
3. A spatial information management device according to claim 2, The spatial ID includes information that uniquely identifies each of the three-dimensional spaces after a three-dimensional space has been divided in a predetermined manner, and is provided for use as a spatial information management device.
4. A spatial information management device according to claim 3, The spatial ID includes information indicating the latitude, longitude, height, and spatial granularity of the three-dimensional space after division, and is a spatial information management device.
5. A spatial information management device according to claim 4, The processor generates an index by converting the latitude, longitude, height, and spatial granularity of the spatial ID into a tree structure or a bitmap. A spatial information management device that generates the primary filter based on the index.
6. A spatial information management device according to claim 3, The spatial ID is a spatial information management device that includes information indicating a horizontal hash value indicating horizontal position information and a height hash value indicating height position information.
7. A spatial information management device according to claim 6, The processor generates an index by converting the horizontal hash value and the height hash value of the spatial ID into a tree structure or a bitmap, A spatial information management device that generates the primary filter based on the index.
8. A spatial information management device according to claim 1, The aforementioned processor, The filtered sensor information is added to the cache data. New sensor information is received from the aforementioned sensor, The primary filter is performed on the new sensor information, and then the secondary filter is performed to generate new filtered sensor information. The following aggregation process is performed based on the filtered sensor information contained in the cached data and the newly filtered sensor information: A spatial information management device that notifies the external system of the results of the aggregation process.
9. A spatial information management device according to claim 1, The aforementioned processor, A process corresponding to each of the one or more spatial conditions is generated, Within each of the aforementioned generated processes, a secondary filter is generated that corresponds to the spatial conditions of that process. The received sensor information is filtered using the primary filter to generate sensor information after primary filtering. The sensor information after primary filtering is transmitted to the generated process. A spatial information management device in which each of the generated processes performs filtering by the secondary filter on the sensor information after the primary filtering.
10. A spatial information management device according to claim 1, The aforementioned processor, Identify the spatial ID corresponding to the location information indicated by the received sensor information, The primary filtering is performed based on the identified spatial ID and the primary filter. A spatial information management device that performs secondary filtering based on the location information indicated by the received sensor information and the secondary filter.
11. A method for managing spatial information using a spatial information management device, The spatial information management device is It has a processor and memory, It is connected to an external system and a sensor that acquires sensor information including sensor values linked to 3D position information. Each of the aforementioned memories holds one or more spatial conditions that are specified by the external system and represent a spatial shape. The aforementioned spatial information management method is: The processor converts the spatial shape represented by each of the one or more spatial conditions into a spatial ID. The processor generates a first-order filter common to the one or more spatial conditions based on the spatial ID, The processor generates a quadratic filter that represents each of the one or more spatial conditions, The processor receives the sensor information from the sensor, The processor performs primary filtering on the received sensor information using the primary filter, and then performs secondary filtering using the secondary filter to generate filtered sensor information. A spatial information management method wherein the processor notifies the external system of information indicating the filtered sensor information.