Geospatial data analysis and visualization platform
The hex tile format addresses inefficiencies in conventional geospatial analysis systems by enabling high-performance data transfer and real-time analysis of large datasets, supporting both local and global analyses with reduced load times and bandwidth needs.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- FOURSQUARE LABS INC
- Filing Date
- 2021-11-16
- Publication Date
- 2026-07-07
AI Technical Summary
Conventional geospatial analysis systems face challenges in efficiently transmitting large datasets over networks, with raster tile systems causing difficulties on front-end devices and vector tile systems being computationally expensive.
The implementation of a hex tile format for geospatial data transfer using a discrete global grid system, which allows for high-performance data transfer, efficient encoding, and unified dataset representation, enabling analysis, exploration, and visualization on both front-end and back-end devices.
The hex tile system facilitates rapid computation and real-time data delivery to client devices, reducing load time and bandwidth requirements while supporting both local and global analyses, even with large datasets.
Smart Images

Figure 0007886327000003 
Figure 0007886327000004 
Figure 0007886327000005
Abstract
Description
Technical Field
[0001] Cross - reference to Related Applications This application claims the priority of U.S. Provisional Patent Application No. 63 / 114,381, entitled "Geospatial Data Analytics and Visualization", filed on November 16, 2020, and the entire disclosure of this provisional application is hereby incorporated by reference in its entirety into this specification.
Background Art
[0002] Performing geospatial analysis on a network gives rise to several problems, such as the difficulty of transmitting the large amounts of data required to perform the analysis on the network. Further, conventional geospatial analysis systems are generally implemented using a raster tile system or a vector tile system. Each of these systems has specific drawbacks. For example, the raster tile system causes difficulties when used to perform analysis on a front - end device. Further, encoding data in a vector tile system can be computationally expensive.
[0003] Embodiments have been described with respect to these and other conventional considerations. Also, while relatively specific problems have been considered, it should be understood that embodiments should not be limited to solving the specific problems identified in the background art.
Summary of the Invention
Means for Solving the Problems
[0004] The technologies introduced herein overcome, at least partially, the shortcomings and limitations of prior art by providing systems and methods for facilitating geospatial processing of datasets and providing visualization of geospatial analysis data over networks. In particular, the systems include a unique implementation and specification of the hex tile format. Hex tile is a system for transferring geospatial analysis data over networks (e.g., the Internet). The hex tile format enables high-performance data transfer using a geospatial grid system and allows for the unification of different datasets using the same tile system. Hex tile has similarities to conventional raster tile and vector tile systems. Unlike raster tile systems, hex tile systems can be used for front-end analysis. Unlike vector tile systems, hex tile systems can encode data more efficiently for representation of analytical datasets. Hex tile systems provide a unique analytical tile system that enables data to be analyzed, explored, visualized, and integrated with other datasets.
[0005] This summary is provided to introduce in a simplified form the selection of concepts further described below in the “Modes for Carrying Out the Invention.” This summary is not intended to identify any important or essential features of the claims, nor is it intended to be used to limit the scope of the claims.
[0006] The technologies introduced herein are shown as examples, but not as limitations, in the figures of the attached drawings, where similar reference numbers are used to refer to similar elements. [Brief explanation of the drawing]
[0007] [Figure 1] This is a high-level block diagram illustrating one embodiment of a system for providing a platform for performing geospatial analysis, unification, and visualization of datasets. [Figure 2] This is a block diagram showing one embodiment of a computing device that includes a geospatial analysis application. [Figure 3] This flowchart illustrates one embodiment of an exemplary method for performing geospatial analysis on a dataset. [Figure 4] This flowchart illustrates an exemplary method for performing offline coding of a dataset to hex tile. [Figure 5] This flowchart illustrates an exemplary method for performing online encoding of a dataset to hex tile. [Figure 6] This flowchart illustrates an exemplary method for displaying hex tile data received from an analysis server. [Figure 7] This is a simplified block diagram of a device in which an aspect of the disclosure may be implemented. [Modes for carrying out the invention]
[0008] The aspects of this disclosure generally relate to providing a platform for performing geospatial analysis, unification, and visualization of datasets. This disclosure relates to a system and method for facilitating geospatial processing and analysis of datasets and for providing visualization of geospatial analysis data on a network. The platform utilizes a discrete global grid system to divide an area (e.g., a map, city, state, country, continent, world, etc.) into a set of discrete grid cells. The set of grid cells can be subdivided into grids of finer resolution. In an example, the platform generates and employs the use of hexagonal tiles for the grid cells. The use of hexagonal tiles provides a computationally efficient and consistent hierarchical grid that offers analytical advantages of hexagonal cells, such as constant distance between adjacent cells, the ability to form concentric circles of cells, compact cell representation, and aggregation of data within hexagonal tiles with minimal computational complexity.
[0009] Hexagonal grid-based geospatial indexing systems represent a significant technological advancement in geospatial grid systems. Hexagonal grid-based geospatial indexing systems are computationally efficient, consistent, and hierarchical grids that offer the analytical advantages of hexagonal cells. While the analytical advantages of hexagonal cells are clear, there remains a persistent need to address significant technical challenges and create globally consistent and efficient hexagonal grids for use in geospatial data analysis.
[0010] Aspects of this disclosure enable the computation and execution of global analyses using hex tile data. In an example, a global analysis applies a computation or set of computations with a high level of detail to data spanning a large area of a location (e.g., a country, the world). For large datasets, performing such analyses generally involves processing a relatively large amount of data that can fit into memory, even on a very large server. By utilizing hex tile data, the data can be loaded in chunks as needed to advance the computation and unloaded as new areas are processed. Furthermore, if multiple datasets are encoded as hex tile data, corresponding portions from different datasets can be easily identified and loaded for analysis.
[0011] The use of hextiles can also be performed on the fly, meaning that the device performing the analysis can apply the analysis to a specific hextile or set of hextiles before providing the hextile. In this way, only the portion of the dataset represented by the relevant hextile is computed upon client request. This is performed before each client request, thereby making it appear as if one or more large, global datasets have been computed based on the requested analysis, when in reality only a small subset of the dataset has been computed upon client request. In this way, the embodiments disclosed herein can rapidly perform computations on datasets in response to client requests, thereby reducing the load time and bandwidth requirements of individual client devices.
[0012] In a further embodiment, the use of hextiles supports the processing of local analyses. Local analyses are processed on the client device, for example, using a web browser or other application. The use of hextiles allows analyses to be performed locally on the client device, even when the underlying dataset is too large to transfer to the client system. Furthermore, in doing so, the use of hextiles enables the delivery of relevant data on demand, making the calculation of the local analysis by the client device appear to the user of the client device as if it were a calculation of a global analysis. For example, when a user adjusts the map view, a request for additional hextiles required to display the new area is automatically generated. The analysis calculation is automatically performed for the additional hextiles, thereby maintaining a constant level of data granularity as the client device changes the view. In doing so, the embodiments disclosed herein can easily transmit relevant data to the client device in real time, thereby making it appear as if a global dataset has been transferred to the client device without requiring the transfer of the entire dataset. While the examples in this disclosure relate to the use of hex tiles in a grid system, those skilled in the art will understand that other types of tiles may be used in conjunction with the embodiments disclosed herein without departing from the scope of this disclosure. For example, square, rectangular, or other geometrically shaped tiles may be used without departing from the scope of this disclosure.
[0013] Figure 1 is a high-level block diagram showing one embodiment of a system 100 for providing a platform for performing geospatial analysis, unification, and visualization of a dataset. The shown system 100 may have one or more client devices 115a...115n that can be accessed by users, a geospatial analysis server 101, and a number of third-party servers 125. In Figure 1 and the remaining figures, the letters following a reference number, for example, "115a", represent a reference to the element having that particular reference number. A reference number in the body without following letters, for example, "115", represents a general reference to an instance of the element having that reference number. In the shown embodiment, these entities of system 100 are linked so that they can communicate over a network 105.
[0014] Network 105 may be of the usual type, wired or wireless, and may have many different configurations, including star configuration, token ring configuration, or other configurations. Furthermore, Network 105 may include any number of networks and / or network types. For example, Network 105 may include a local area network (LAN), a wide area network (WAN) (e.g., the Internet), a virtual private network (VPN), a mobile (cellular) network, a wireless wide area network (WWAN), a WiMAX® network, a Bluetooth® communication network, a peer-to-peer network, and / or other interconnected data paths through which multiple devices may communicate, and various combinations thereof. Network 105 may also be coupled to or part of a telecommunications network for transmitting data using various different communication protocols. In some implementations, Network 105 may include a Bluetooth communication network or a cellular communication network for sending and receiving data via Short Message Service (SMS), Multimedia Messaging Service (MMS), Hypertext Transfer Protocol (HTTP), Direct Data Connection, WAP, email, etc. In some implementations, the data transmitted by network 105 may include packetized data (e.g., Internet Protocol (IP) data packets) that are routed to designated computing devices coupled to network 105. Figure 1 shows one network 105 coupled to a client device 115, a geospatial analysis server 101, and several third-party servers 125, but in practice, one or more networks 105 may be connected to these entities.
[0015] Client devices 115a...115n (also individually referred to as client device 115) may be computing devices having data processing and communication capabilities. In some implementations, client device 115 may include software and / or hardware components such as memory, a processor (e.g., virtual, physical, etc.), a power supply, a network interface, a display, a graphics processing unit (GPU), a wireless transceiver, a keyboard, a camera (e.g., a webcam), sensors, firmware, an operating system, a web browser, applications, drivers, and various physical connection interfaces (e.g., USB, HDMI®, etc.). Client devices 115a...115n may connect to and communicate with each other and other entities of system 100 via network 105 using wireless and / or wired connections. Examples of client device 115 may include, but are not limited to, laptops, desktops, tablets, mobile phones (e.g., smartphones, feature phones, etc.), server appliances, servers, virtual machines, smart TVs, media streaming devices, user-wearable computing devices, or any other electronic devices that can access network 105. In the example in Figure 1, client device 115a is configured to implement a geospatial analysis application 103a, which is described in more detail below. Client device 115 includes a display for viewing information provided by one or more entities connected to the network 105. For example, client device 115 may be adapted to send data to and receive data from the geospatial analysis server 101. Although two or more client devices 115 are depicted in Figure 1, system 100 may include any number of client devices 115. Furthermore, client devices 115a...115n may be the same or different types of computing devices.
[0016] In the example in Figure 1, each of the geospatial analysis server 101 and the multiple third-party servers 125 may be a computing device including a processor, memory, applications, a database, and network communication capabilities, or may be implemented by such a computing device.
[0017] In the example in Figure 1, the components of the geospatial analysis server 101 are configured to implement the geospatial analysis application 103b, which is described in more detail below. In some implementations, the geospatial analysis server 101 may provide a platform for performing geospatial analysis, unification, and visualization of datasets via web, mobile, and / or cloud applications.
[0018] In some implementations, the geospatial analysis server 101 may be a hardware server, a software server, or a combination of software and hardware. For example, the geospatial analysis server 101 may include one or more hardware servers, virtual servers, server arrays, storage devices, and / or systems, and / or may be centralized or distributed / cloud-based. In some implementations, the geospatial analysis server 101 may include one or more virtual servers that operate within a host server environment and access the physical hardware of the host server, including, for example, a processor, memory, applications, databases, storage, and network interfaces, via an abstraction layer (e.g., a virtual machine manager). In some implementations, the geospatial analysis server 101 may be a hypertext transfer protocol (HTTP) server, a Representational State Transfer (REST) service, or other type of server having the structure and / or functionality to process, satisfy, and / or receive content requests from one or more of the client devices 115 and multiple third-party servers 125 connected to the network 105.
[0019] Alternatively, or in addition, the geospatial analysis server 101 may implement its own application programming interface (API) for the transmission of instructions, data, results, and other information between the geospatial analysis server 101 and applications installed or otherwise implemented on one or more of the client devices 115 and the multiple third-party servers 125. For example, the API may be a software interface exposed by the geospatial analysis server 101 via the HTTP protocol. The API exposes internal data and functionality of services hosted by the geospatial analysis server 101 in response to API requests arising from, for example, the geospatial analysis application 103a. The geospatial analysis server 101 may also include a database connected to the geospatial analysis server 101 via the network 105 for storing structured data in a relational database, and a file system (e.g., HDFS, NFS, etc.) for unstructured or semi-structured data.
[0020] In some implementations, the geospatial analysis server 101 transmits data to and receives data from other entities in the system 100 via the network 105. For example, the geospatial analysis server 101 transmits data containing instructions to and receives data containing instructions from the client device 115. In some implementations, the geospatial analysis server 101 may be operable to enable users of client devices 115a...115n to create and manage individual user accounts, receive and store hex tile data for geospatial analysis and visualization tasks, and / or manage the transfer of such hex tile data from the geospatial analysis server 101 to the client device 115 via the network 105. The geospatial analysis server 101 may transmit data to and receive data from other entities in the system 100, including the client device 115 and a number of third-party servers 125, via the network 105. It should be understood that the geospatial analysis server 101 is not limited to providing the actions and / or functions described above, and may include other network-accessible services. Furthermore, although Figure 1 depicts a single geospatial analysis server 101, it should be understood that any number of geospatial analysis servers 101 or server clusters may exist.
[0021] In the example of FIG. 1, system 100 includes a plurality of third-party servers 125. The plurality of third-party servers 125 may communicate with one or more entities of system 100, such as a plurality of client devices 115 and the geospatial analysis server 101. For example, the third-party servers 125 may include a social media server, a web mapping server, a satellite image server, a telecommunications server, a spatial database server, a remote sensing server, a healthcare server, a public sector server, an insurance server, a weather server, and the like. In some implementations, each of the plurality of third-party servers 125 may be configured to provide or facilitate an application programming interface (API) that enables a trusted third-party application or system to access geospatial or geospatial-related information to perform the functions described herein.
[0022] The geospatial analysis application 103 may include software and / or logic for providing functions for performing geospatial analysis, consolidation, and visualization of datasets. In some implementations, the geospatial analysis application 103 may be implemented using programmable or special hardware, such as a field programmable gate array (FPGA) or an application specific integrated circuit (ASIC). In some implementations, the geospatial analysis application 103 may be implemented using a combination of hardware and software. In other implementations, the geospatial analysis application 103 may be stored and executed on a combination of the client device 115 and the geospatial analysis server 101, or by either the client device 115 or the geospatial analysis server 101 alone.
[0023] In some implementations, the geospatial analysis application 103a may be a thin-client application where some functions are executed on the client device 115 and additional functions are executed on the geospatial analysis server 101 by the geospatial analysis application 103b. In some implementations, the geospatial analysis application 103 may, in some cases, generate and present various user interfaces for performing these actions and / or functions that are at least partially based on information received from the geospatial analysis server 101, the client device 115, and / or the plurality of third-party servers 125 via the network 105. In some implementations, the geospatial analysis application 110 may be code operable in a web browser, a web application accessible via a web browser, a native application on the client device 115 (e.g., a mobile application, an installed application, etc.), combinations thereof, and the like. Additional structure, actions, and / or functions of the geospatial analysis applications 103a and 103b are further considered below, at least with reference to FIG. 2.
[0024] In some implementations, geospatial analysis applications 103a and 103b may require a user to register with the geospatial analysis server 101 in order to access the actions and / or functions described herein. For example, in order to access the various actions and / or functions provided by geospatial analysis application 103, geospatial analysis application 103 may require a user to authenticate their identity. For example, geospatial analysis application 103 may require a user seeking access to authenticate their identity by entering credentials in the relevant user interface. In another example, geospatial analysis application 103 may interact with a federated identity server (not shown) to register and / or authenticate a user.
[0025] System 100, shown in Figure 1, is representative of an exemplary system for providing a platform for performing geospatial analysis, unification, and visualization of datasets. It should be understood that a variety of different system environments and configurations are conceivable and within the scope of this disclosure. For example, various functions may be transferred from the geospatial analysis server 101 to the client device 115 or vice versa, and some implementations may include additional or fewer computing devices, services, and / or networks, and various functions may be implemented on the client or server side. Furthermore, various entities of System 100 may be integrated into a single computing device or system, or into additional computing devices or systems, etc.
[0026] Figure 2 is a block diagram showing one embodiment of a computing device 200 including a geospatial analysis application 103. In some examples, the computing device 200 may also include a processor 235, memory 237, a display device 239, a communication unit 241, and data storage 243. The components of the computing device 200 are coupled together for communication via a bus 220. The bus 220 may represent one or more buses, including an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, a Universal Serial Bus (USB), or any other bus known in the art for providing similar functionality. In some embodiments, the computing device 200 may be a client device 115, a geospatial analysis server 101, or a combination of the client device 115 and the geospatial analysis server 101. In such embodiments where the computing device 200 is the client device 115 or the geospatial analysis server 101, it should be understood that the client device 115 and the geospatial analysis server 101 may include other components described above but not shown in Figure 2.
[0027] The processor 235 may execute software instructions by performing various input / output, logical, and / or mathematical operations. The processor 235 may have various computing architectures for processing data signals, including, for example, a composite instruction set computer (CISC) architecture, a reduced instruction set computer (RISC) architecture, and / or architectures that implement combinations of instruction sets. The processor 235 may be physical and / or virtual and may include a single processing unit or multiple processing units and / or cores. In some implementations, the processor 235 may be able to generate electronic display signals, provide them to a display device, support the display of images, capture and transmit images, and perform complex tasks. In some implementations, the processor 235 may be coupled to memory 237 via bus 220 to access data and instructions in memory 237 and to store data in memory 237. Bus 220 may connect the processor 235 to other components of the computing device 200, including, for example, memory 237, a communication unit 241, a geospatial analysis application 103, and data storage 243. It will be apparent to those skilled in the art that other processors, multiple processors, operating systems, sensors, displays, and physical configurations are possible.
[0028] Memory 237 may store data for other components of the computing device 200 and provide access to such data. Memory 237 may be contained within a single computing device or distributed among multiple computing devices, as discussed elsewhere in this specification. In some implementations, memory 237 may store instructions and / or data that may be executed by the processor 235. Instructions and / or data may include code for performing the techniques described herein. For example, in one embodiment, memory 237 may store a geospatial analysis application 103. Memory 237 may also store other instructions and data, including, for example, an operating system, hardware drivers, other software applications, a database, etc. Memory 237 may be coupled to a bus 220 for communication with the processor 235 and other components of the computing device 200.
[0029] Memory 237 may include one or more non-temporary computer-usable (e.g., readable, writable) devices, static random access memory (SRAM) devices, dynamic random access memory (DRAM) devices, embedded memory devices, discrete memory devices (e.g., PROM, FPROM, ROM), hard disk drives, optical disc drives (CD, DVD, Blu-ray®, etc.), and may be any tangible device or apparatus that can store, transmit, or transfer instructions, data, computer programs, software, code, routines, etc., for processing by or in connection with the processor 235. In some implementations, memory 237 may include one or more of volatile and non-volatile memory. It should be understood that memory 237 may be a single device or may include multiple types of devices and configurations.
[0030] The display device 239 is a liquid crystal display (LCD), a light-emitting diode (LED), or any other similarly equipped display device, screen, or monitor. The display device 239 represents any device equipped for displaying a user interface, electronic images, and data, as described herein. In different embodiments, the display may be binary (only two distinct values with respect to pixels), monochrome (multiple shades of one color), or allow for multiple colors and shades. The display device 239 is coupled to the bus 220 for communication with the processor 235 and other components of the computing device 200. It should be noted that the display device 239 can be optional. For example, if the computing device 200 is a geospatial analysis server 101, the display device 239 is not part of the system.
[0031] The communication unit 241 is hardware for receiving and transmitting data by linking the processor 235 to the network 105 and other processing systems. The communication unit 241 receives data such as user input from the client device 115 and transmits the data to the user interface engine 208. The communication unit 241 also transmits commands from the user interface engine 208 to display the user interface on the client device 115, for example. The communication unit 241 is coupled to the bus 220. In one embodiment, the communication unit 241 may include a port for a direct physical connection to the client device 115 or another communication channel. For example, the communication unit 241 may include an RJ45 port for wired communication with the client device 115. In another embodiment, the communication unit 241 may include a wireless transceiver (not shown) for exchanging data with the client device 115 or any other communication channel using one or more wireless communication methods such as IEEE 802.11, IEEE 802.16, Bluetooth®, or another preferred wireless communication method.
[0032] In yet another embodiment, the communication unit 241 may include a cellular communication transceiver for sending and receiving data over a cellular communication network, such as via Short Message Service (SMS), Multimedia Message Service (MMS), Hypertext Transfer Protocol (HTTP), Direct Data Connection, WAP, email, or another preferred type of electronic communication. In yet another embodiment, the communication unit 241 may include a wired port and a wireless transceiver. The communication unit 241 also provides other common connections to the network 105 for the delivery of files and / or media objects using standard network protocols such as TCP / IP, HTTP, HTTPS, and SMTP, as will be understood by those skilled in the art.
[0033] Data storage 243 is non-temporary memory for storing data to provide the functions described herein. Data storage 243 may be included in the computing device 200, or it may be included in another computing device and / or storage system separate from the computing device 200, but coupled to or accessible by the computing device 200. Data storage 243 may include one or more non-temporary computer-readable media for storing data. In some implementations, data storage 243 may be merged with memory 237, or it may be separate from memory 237. Data storage 243 may be a dynamic random access memory (DRAM) device, a static random access memory (SRAM) device, flash memory, or any other memory device. In some implementations, data storage 243 may include a database management system (DBMS) that can operate on the computing device 200. For example, the DBMS may include a Structured Query Language (SQL) DBMS, a NoSQL DBMS, or various combinations thereof. In some cases, the DBMS may store data in a multidimensional table consisting of rows and columns, and use program operations to manipulate rows of data, for example, insert, query, update, and / or delete. In other implementations, the data storage 243 may include non-volatile memory or similar persistent storage devices and media, including hard disk drives, CD-ROM devices, DVD-ROM devices, DVD-RAM devices, DVD-RW devices, flash memory devices, or any other mass storage devices for more persistent storage of information. The data storage 243 is coupled to the bus 220 for communication. The data storage 243 stores data related to performing geospatial analysis, unification, and visualization of datasets, as well as other functions described herein.The data storage 243 may store, in particular, the hex tile data catalog 253 and the geospatial dataset 251. The data stored in the data storage 243 is described in more detail below.
[0034] As shown in Figure 2, memory 237 may contain geospatial analysis applications 103a and / or 103b. In some implementations, geospatial analysis applications 103a and / or 103b may include a hex tile encoder engine 202, a hex tile loader engine 204, a hex tile decoder engine 206, and a user interface engine 208. Components 202, 204, 206, and 208 may be coupled together by bus 220 and / or processor 235 to communicate with each other and / or with other components 237, 239, 241, and 243 of computing device 200 for cooperation and communication. Components 202, 204, 206, and 208 may include software and / or logic to provide their respective functionalities. In some implementations, components 202, 204, 206, and 208 may be implemented using programmable or specialized hardware, including field-programmable gate arrays (FPGAs) or application-specific integrated circuits (ASICs). In some implementations, components 202, 204, 206, and 208 may be implemented using a combination of hardware and software executable by processor 235. In some implementations, each of components 202, 204, 206, and 208 may be a set of instructions stored in memory 237 and configured to be accessible and executable by processor 235 to provide the actions and / or functions of those components. In some implementations, components 202, 204, 206, and 208 may transmit data to and receive data from one or more of client devices 115 and third-party servers 125 via communication unit 241.
[0035] The hex tile encoder engine 202 may include software and / or logic to provide functionality for receiving one or more datasets as input and generating hex tile files as output. In some implementations, the hex tile encoder engine 202 accesses arbitrarily large datasets 251 from data storage 243 and processes those datasets 251 into hex tile format to facilitate efficient geospatial analysis. For example, a dataset may be larger (e.g., in the range of petabytes) than what can be transferred to the client device 115. The hex tile encoder engine 202 creates hex tile format so that a portion of the dataset can be transferred to the client device 115 as needed. The hex tile format may be made available for immediate local and global analysis. The hex tile encoder engine 202 stores the hex tile format in a hex tile data catalog 253 within data storage 243. The hex tile data catalog 253 may include information about the data source (e.g., author, license, etc.), the data itself, how the data was created, available resolutions, screenshots of maps using this data, etc.
[0036] The hextile system described herein is a proprietary specification of the hextile format. The specification of the hextile format may be defined by the enclosing format, the discrete global grid system, and the compression scheme. For example, in implementation, the proprietary specification of the hextile format described herein uses Apache ARROW® as the binary transfer format, the H3 hexagonal hierarchical geospatial indexing system as the discrete global grid system (DGGS), and GNU zip (gzip) as the compression scheme. Apache ARROW® defines a language-independent column-oriented memory format for flat and hierarchical data organized for efficient analytical operation on modern hardware such as CPUs and GPUs. The H3 hexagonal hierarchical geospatial index system is suitable for analysis and designed for high performance in big data systems using 64-bit cell indexes; however, those skilled in the art will understand that other types of indexing systems may be employed. The gzip compression scheme may be used because it is widely implemented in web browsers. Other implementations of the Hextile format may use Apache PARQUET® and non-binary formats such as comma-separated values (CSV) and JavaScript Object Notation (JSON) as the encapsulation format, the S2 geometry library, Geohash, and PLACEKEY® as the discrete global grid system, and Zstandard (zstd) and LZ4 as the compression scheme. While specific implementations of the Hextile format are disclosed herein, those skilled in the art will understand that other implementations may be adopted without departing from the scope of this disclosure.
[0037] The hex tile systems described herein transfer data tile by tile. A tile covers a spatial cell of the Discrete Global Grid System (DGGS) used in the hex tile system. The DGGS divides the world into a set of discrete grid cells. A set of grid cells can be further subdivided into grids of finer resolution. A tile contains data of finer resolution within the same DGGS. A tile may also contain metadata indicating the resolution of the data within it, and / or metadata indicating which subtiles are available. This metadata prevents loading subtiles when data does not exist. For example, the metadata may include a list of seven direct subtiles and optionally list finer resolution tiles two levels below (e.g., 7*7=49 tiles).
[0038] The data within a tile may be in tabular format. A tile contains data relating to the area within its cell. For example, a tile with cell H3 "8428347ffffff" may contain the following data points shown in Table 1.
[0039] [Table 1]
[0040] In the example in Table I, the hex tile is encoded in a "sparse" format, containing all possible data points within the tile except for "85283477fffff". Alternatively, the hex tile may contain a subset of the available data. The hex tile may also support "dense" encoding, where the data points do not have explicit grid identifiers (grid IDs) stored in a file, but instead implicitly define the grid IDs by ordering (using ordering defined by grid IDs, or more broadly, using a space-filling curve). Dense encoding eliminates the need to encode grid IDs within tiles, reducing storage, memory, and transfer costs associated with the hex tile system. The dense mode is indicated per tile as part of the tile's metadata. It is possible to reconstruct the grid IDs of dense tiles. In dense encoding, the data points shown in Table I may be encoded as shown in Table 2 below.
[0041] [Table 2]
[0042] In some implementations, hextiles may carry time data by adding a time dimension (for example, by adding a new column "timestamp"). In some implementations, hextiles may increment the number of columns by one for each time index in which data exists. For example, the column "attribute_1" may be expanded to "attribute_1T2020-01-01", "attribute_1T2020-01-02", "attribute_1T2020-01-03", etc. When client device 115 requests hextiles from geospatial analysis server 101, client device 115 may give additional constraints in its request, such as requesting only data from the most recent month, data from the month before the most recent month, etc., in order to support an arbitrarily long history. This technique of adding dimensions may be used to support dimensions of other categories, or dimensions that can be classified into buckets similar to time.
[0043] In some implementations, the hextile encoder engine 202 uses an offline encoder to pre-encode the hextiles. The offline encoder implementation utilizes mass storage provided by systems such as Google® Cloud Storage, Amazon® Simple Storage Service, and other content delivery networks to output a set of files. The offline encoder receives the original dataset and projects it onto the DGGS at the finest resolution used in the hextiles. For each resolution of the generated hextiles, the offline encoder is configured to (a) reaggregate the data to a coarser resolution if the tile data resolution is coarser than the finest resolution (e.g., truncate the grid IDs, group the data by the truncated IDs, and aggregate the data), (b) group the data by the grid IDs truncated down to the resolution of the tile ID (e.g., the truncated grid IDs become the tile IDs at this resolution), (c) encode each tile file along with its contents according to the specifications of the hextile format, and (d) write additional metadata about the resolution, such as which tile IDs are valid. The offline encoder includes additional metadata about the tileset, such as which resolutions are valid or when the client device 115 should use different resolutions of the data during visualization. In some implementations, the hex tile encoder engine 202 performs the offline encoder on a distributed parallel data processing system such as Apache Spark® or Dask. The hex tile encoder engine 202 may also perform the offline encoder on a schedule from a pipeline orchestration system such as Apache Airflow® or Prefect to update the data.
[0044] In some implementations, the hextile encoder engine 202 uses an online encoder to encode hextiles when they are needed. The online encoder implementation generates hextiles only when they are requested by the client device 115. This allows for the use of the most up-to-date data and supports dynamic queries on the underlying data. The online encoder receives a request for a specific tile ID from the client device 115, performs a database query on the data, and identifies the data where the truncated grid ID matches the tile ID. In some implementations, the request from the client device 115 may include additional information or criteria, such as the desired data resolution, time range, etc. The online encoder encodes the data into tile format according to the hextile format specification and sends a response to the client device 115 containing the requested tile corresponding to the tile ID. In some implementations, the hex-tile encoder engine 202 implements the online encoder as a REST web service using one or more of the following: in-memory databases (e.g., Apache PINOT®, Redis, etc., for service delivery performance), analytics databases (e.g., Elasticsearch, Apache DRUID®, Apache PINOT®, etc., for a combination of service delivery performance and flexibility), and data warehouses (e.g., Google® BigQuery, Snowflake, etc., for flexibility and large datasets).
[0045] The hex tile loader engine 204 may include software and / or logic to provide functionality for determining and requesting one or more hex tiles for decoding. The hex tile loader engine 204 tracks the map view of the geospatial analysis data visualization displayed on the client device 115. The hex tile loader engine 204 determines which portion of the map view is currently visible to the user on the client device 115, the hex tile resolution required for the map view, and the hex tile corresponding to the resolution that needs to be requested. The hex tile loader engine 204 requests the hex tile corresponding to the data storage 243 and passes those hex tile to the hex tile decoder engine 206 for decoding.
[0046] In some implementations, the hex tile loader engine 204 determines which resolution hex tiles need to be requested based on the zoom level or altitude of the user's view of the map on the client device 115. The hex tile loader engine 204 requests coarser tiles when the map is zoomed out (e.g., when the user sees the global differences between large areas on the map) and finer tiles when the map is zoomed in (e.g., when the user sees the finer details of a dataset on the map). In some implementations, the hex tile loader engine 204 determines which tiles need to be specifically requested based on which parts of the world are visible or will become visible on the map view. The behavior defined in DGGS provides all spatial cells visible on the map view and further supports adding adjacent cells when cells adjacent to the current view may become visible based on user selection. Tiles of different resolutions are related to each other based on the hierarchical features of DGGS. This forms the basis for caching tiles and their derived analysis on the client device 115, and forms a technique for replacing coarser tiles only when their finer tiles are fully loaded or when partial data becomes available. In some implementations, the hex tile loader engine 204 receives a uniform resource locator (URL) to a tiled dataset in a remote third-party server 125. For example, a user may specify a URL reference to a tiled dataset. The hex tile loader engine 204 accesses and / or requests the tiled dataset from the URL.
[0047] In some implementations, the hex tile loader engine 204 facilitates local analysis performed on the client device 115 (for example, in a web browser) even when the underlying tiled dataset is too large to transfer to the client device 115. The hex tile system transparently presents local analysis as global analysis by making it appear as if the entire dataset is loaded, even when only a small portion of the dataset may have been loaded. As the user moves around in the map view, the hex tile loader engine 204 automatically requests additional tiles needed to display new areas on the client device 115, facilitating the execution of user-specified data operations while maintaining a consistent level of data granularity. For example, data operations or calculations are immediately applied to the data currently visible to the user on the client device 115. User changes to parameters may instantly update the visualization of the underlying dataset at "60 frames per second" using GPU technology to create an extremely fluid analysis experience.
[0048] In some implementations, the hex tile loader engine 204 facilitates global analysis by applying a set of calculations to data spanning large areas within a map view or the entire world at a high level of detail. The hex tile loader engine 204 loads data in segments as needed to proceed with the calculations, and then unloads the data as new areas are processed. If multiple datasets are hex tiles, the hex tile loader engine 204 loads the corresponding portions from the multiple tile sets. In some implementations, the hex tile loader engine 204 facilitates on-the-fly global analysis applied tile by tile before the analysis provides it. This means that only the portion actually needed by the client device 115 needs to be calculated, and it appears as if the global dataset has been processed when only a small subset actually used by the client device 115 has been processed. A hex tile using the H3 hexagonal hierarchical geospatial indexing system as a discrete global grid system has 7 child tiles. Thus, the length scale of each tile is the square root of 7 = 2.65. The zoom increment at which the hex tile loader engine 204 loads new tiles to maintain a constant resolution is 2.65 base-2 logarithm = 1.41. Hex tiles have relatively low levels, resulting in relatively few breaks when zooming in and out, leading to less network load.
[0049] The hex tile decoder engine 206 may include software and / or logic to provide functionality for receiving one or more tile files as input and generating data as output. In some implementations, the hex tile decoder engine 206 reverses the steps taken to receive the tiles and encode the data into hex tile format. For example, this decoding operation may include adding grid IDs to dense tiles and performing conversions between incompatible data formats. Depending on the needs of the application receiving the output data, the hex tile decoder engine 206 may generate data that may be within the same grid system used for the tiles or in an entirely different geographical form. For example, a visualization application on the client device 115 may need to render the tiled data as points rather than using grid cell boundaries. The visualization application may also choose to render the tiles as polygonal regions or in an entirely different shape.
[0050] The user interface engine 208 may include software and / or logic for providing a user interface to the user. In some embodiments, the user interface engine 208 receives instructions from components 202, 204, and 206 to generate a user interface. In some implementations, the user interface engine 208 sends graphical user interface data to an application on a client device 115 (e.g., a browser) via a communication unit 241, causing the application to display the data as a graphical user interface.
[0051] Figure 3 is a flowchart illustrating one embodiment of exemplary method 300 for performing geospatial analysis on a dataset. For example, Figure 3 shows an exemplary method for performing hex-tile offline coding. The overall sequence of operations of method 300 is shown in Figure 3. Method 300 may include more or fewer steps, or the order of steps may be arranged differently from the steps shown in Figure 3. Method 300 may be executed by a cloud system and performed as a set of computer-executable instructions that are encoded or stored in a computer-readable medium. Furthermore, method 300 may be executed by gates or circuits associated with a processor, ASIC, FPGA, SOC, or other hardware device.
[0052] In operation 302, a device, process, and / or application performing method 300, such as the hex-tile encoder engine 202 in Figure 2, accesses one or more datasets. In the example, a decision may be made regarding which of the one or more datasets will be accessed. For example, if a particular type of analysis is to be performed, one or more datasets related to the calculations of the analysis may be accessed in operation 302. Alternatively or additionally, one or more datasets may be specifically identified in a request, for example, by a client device requesting specific data and / or analysis, or by selecting one or more datasets via a user interface.
[0053] In operation 304, a device, process, and / or application performing method 300, such as the hex tile encoder engine 202 in Figure 2, encodes data from one or more datasets into hex tile. The process for encoding data from datasets into hex tile is described in Figure 4 and the accompanying text. In 306, a decision is made regarding the map view of the dataset. In one example, the decision is based on the current view of the map. In the example, the view decision is based on the zoom level of the map view and / or the current resolution of the map that is displayed or requested to be displayed. Additionally or alternatively, determining the view may also determine which datasets should be loaded. For example, aspects of this disclosure are operable to convert any number of different datasets into hex tile. Different datasets may contain different kinds of information, such as population census data, weather data (i.e., precipitation, temperature, snowfall, etc.), and venue data. Those skilled in the art will understand that any kind of data can be encoded into hex tile, insofar as the data contains a spatial component (e.g., location information). Since any number of different datasets may be used, determining the view in operation 306 may also include determining which datasets should be drawn. The decision may be based on receiving a selection of one or more datasets. Alternatively or additionally, the datasets may be determined based on a specific analysis or computation to be performed, in which case the hex tile associated with the dataset related to the analysis or computation is automatically identified. In the example, operation 306 may be performed by the hex tile loader engine 204 in Figure 2.
[0054] In operation 308, hex styles are loaded based on the map view. Loading hex styles may involve identifying hex styles that correspond to both the resolution of the map view and one or more datasets corresponding to the view, as discussed above. Thus, in operation 308, multiple different hex styles may be loaded for multiple different datasets. In one example, different hex styles (e.g., hex styles encoding data from different datasets) may be layered. Alternatively, different hex styles may be combined into a single hex style encoding data from related datasets. As already discussed, only hex styles related to the view (e.g., the current zoom level / resolution of the map view and / or related datasets) are loaded in operation 308. That is, hex styles related to the location currently being depicted or requested for depiction on the map, and matching the requested resolution, are loaded in operation 308.
[0055] As discussed, aspects of the present disclosure enable the efficient loading of large datasets by determining the relevant portion of a dataset and loading only the portion required based on the current view. Specifically, based on the decision made in operation 306, method 300 determines which portion of the map is visible and, based on the map view, determines what resolution of hex tiles is required. The tile resolution is determined based on the zoom level or altitude of the current map view. Thus, when the view is zoomed out (e.g., to provide a global view of differences between areas), coarser tiles are loaded, and when the view is zoomed in (e.g., to provide finer detail of a dataset encoded by hex tiles), finer tiles are loaded. In this way, relevant portions of one or more datasets can be quickly identified and loaded. Furthermore, when the view changes (for example, the map view zooms in or out, or the location changes), the decision made in action 306 can be repeated, loading a new set of hex tiles, thereby providing an efficient loading process that emulates the feeling that the global dataset has been transferred to the client device, without actually transferring the global dataset to the device.
[0056] Even if a particular hex tile is not currently needed by the view, caching those specific hex tiles can sometimes provide further efficiency. For example, since users often slightly adjust the position of the map view, hex tiles adjacent to the current view may also be loaded in operation 308. Furthermore, hex tiles of different resolutions are hierarchically related to one another. Since users often zoom in or out of the view, the hierarchical nature of hex tiles allows for loading and caching tiles of different resolutions than the current view.
[0057] When tiles are loaded in operation 308, the flow follows operation 310 in which the loaded hex tiles are decoded into output data. In one example, the decode operation 310 includes extracting dataset information from the loaded hex tiles. Alternatively or additionally, the decode process may include performing analysis on the hex tile data, coding the hex tile data to indicate which dataset the hex tiles are associated with (for example, decode data from a first dataset using a first display color and data from a second dataset using a second color so that they can be easily distinguished when different datasets are displayed), applying one or more filters to the hex tile data (for example, filtering for a specific age range in census data, filtering for a specific level of precipitation, etc.), and performing data enrichment, or performing additional modifications to the data. In the example, the decode operation 310 may be performed by the server device or the client device in a client-server interaction. Alternatively, the decode operation may be performed by both the client device and the server device.
[0058] In further examples, the decryption process may include performing data enrichment operations on hextile data. For example, various different types of analysis may be performed as part of the decryption process based on requests received on the client device. Examples of enrichment operations may include combining hextile data with local datasets on the client device (thus maintaining data security and privacy), or comparing or combining data from different datasets represented by hextiles (e.g., combining census data and venue data to determine venue popularity by age group, or combining precipitation data and population data to determine population trends based on precipitation). Those skilled in the art will understand that any kind of spatially related data can be encoded in hextiles, thereby providing flexibility in the types of analysis, computation, and / or data enrichment operations that can be performed using hextiles.
[0059] After the hex tile data is decrypted, the flow proceeds to operation 312, which provides the decrypted data. In one example, providing the decrypted data may include rendering it on a client device, or being made to be rendered. In one example, the decrypted data may be rendered as an overlay on the current map view. As considered above, the decrypted data may be rendered in a way that provides indication of data enrichment or analytical operations performed, such as distinguishing data from different data types (e.g., using different colors or other indicators). Alternatively, the decrypted data may be stored for later use, such as being provided to other applications or processes accessed using an API.
[0060] In one example, the output data may be rendered within a user interface that provides additional functionality for manipulating or viewing the decoded data. For example, the user interface may be operable to receive requests to filter or manipulate the decoded data based on the user's requests. In embodiments where the hex data includes time data, the user interface may be operable to display the changes in the decoded data over time. In such an example, the user interface may include a play button that triggers an animation of the decoded data showing the changes over time. The user interface may also be operable to allow the user to select a specific point in time from which to display or control the animation, for example, via a slider provided in the user interface that is operable to trigger playback of the animation of the decoded data in a forward or backward direction in time.
[0061] Figure 4 shows an exemplary method 400 for encoding a dataset into hex tile. The overall sequence of operations of method 400 is shown in Figure 4. Method 400 may include more or fewer steps, or the order of steps may be arranged differently from the steps shown in Figure 4. Method 400 may be executed by a cloud system as a set of computer-executable instructions that are encoded or stored on a computer-readable medium. Furthermore, method 400 may be executed by gates or circuits associated with a processor, ASIC, FPGA, SOC, or other hardware device.
[0062] The flow begins with operation 402, in which data is accessed from one or more datasets. In one example, the one or more datasets may be determined based on a received selection of one or more datasets, or may be determined automatically based on the type of analysis to be performed. The flow continues with operation 404, in which spatial information associated with the dataset is analyzed to determine the finest level of resolution for the dataset. In the example, the finest level is determined by the level of resolution associated with the data points in the dataset. For example, a particular latitude / longitude component may have a finer resolution than the data associated by a city, the data associated by a city may have a finer resolution than the data associated by a state, and so on. The level of resolution for a hex tile is determined based on the level of resolution of the spatial information in the dataset. In the example, all data in a dataset may be associated with the same level of resolution, but the dataset may contain different levels of resolution for the spatial data without exceeding the scope of this disclosure.
[0063] After determining the finest resolution of the spatial information within the dataset, and thereby the finest level of resolution for the corresponding hex tile, the flow proceeds to operation 404. In operation 406, the data from the dataset is encoded into hex tile. More specifically, the data from the dataset is encoded into hex tile using, for example, the dense or sparse formats already considered. However, those skilled in the art will understand that the dataset may be encoded into hex tile in any kind of different format, as long as the specific portion of the data is encoded into the correct hex tile based on the spatial information associated with that specific portion of the data. In doing so, operation 404 projects the data from the dataset into the corresponding hex tile DGGS based on the location and resolution defined by the spatial information associated with the dataset or various different data points within the dataset. In the example, the encoding process may also assign grid identifiers along with the encoded data. In the example, the grid identifiers may be associated with the hex tile updated or created in operation 404. As described above, hex tiles may exist as part of a hierarchical grid of hex tiles, or they may be used to construct a hierarchical grid of hex tiles, where each level in the hierarchy represents a different resolution (for example, a different zoom level in a map view). In the example, a grid identifier may represent a hierarchical relationship of hex tiles, where the first part of the identifier may be identified with the coarsest level of the hierarchy, the next part with the next coarsest level, and so on until the finest level of resolution of the hex tile hierarchy is reached.
[0064] The flow then proceeds to operation 408, where a decision is made as to whether additional hextiles with different resolutions exist and / or can be created. After first encoding the data from the dataset into hextiles representing the finest level of resolution based on the spatial data of the dataset, a decision is made as to whether the data should be encoded into hextiles with coarser resolutions. If it should be encoded, the flow branches to YES from operation 408 to operation 410. In operation 410, the grid identifier associated with the hextile is truncated. As described above, the grid identifier represents an individual hextile relative to other hextiles in the hextile hierarchy. For example, as described above, each hextile can be subdivided into seven subtiles. The grid identifier of each subtile also includes the identifier of the parent hextile of the subtile. Thus, the parent tile of a hextile can be identified by truncating the grid identifier of the hextile and reconstructing the grid identifier of the parent hextile. In operation 410, the parent hextile of the hextile into which the data was encoded in operation 406 is identified by truncating each grid identifier of the hextile.
[0065] Once the parent tile is identified, the flow proceeds to operation 412, in which the data encoded in operation 406 is grouped. In an example, the encoded data is grouped together based on a comparison of truncated grid identifiers generated in operation 410. Data with matching truncated identifiers are grouped together and proceed to operation 414, where they are aggregated into a parent hex tile (e.g., a hex tile with a coarser resolution) and encoded. Those skilled in the art will understand that any process for aggregating the data may be performed in operation 414. Furthermore, additional metadata may be generated in operation 414 and stored with the parent hex tile. Such metadata may include, but is not limited to, information about the resolution of the parent hex tile, the identifier of the parent hex tile (e.g., generated by truncating the identifier of the child hex tile), etc. In certain embodiments, aggregation may not be necessary. For example, an offload encoder may be performed without aggregating the tile data. More precisely, aggregation during the offline encoding process may be used to encode individual points of data into hex tiles, but may not be necessary. Thus, operation 414 may be an optional step. After the data is aggregated, or optionally skipped, in operation 414 and encoded into a parent hex tile, the flow returns to operation 408 to determine again whether the data should be aggregated into a hex tile with a coarser resolution. In one example, when grouping the next level of tiles, the grouping may be based on the parent level, or alternatively, the next level of tiles may generate groups based on the finest resolution set of tiles encoded in operation 406. In such embodiments, the identifier of the finest level of tiles may be truncated two or more times in order to determine the identifier of the next level of tiles (depending on the resolution level of the next level of tiles). This process continues until the coarsest resolution of the hex tile is reached, at which point the flow branches from operation 408 to operation 416.
[0066] In operation 416, an encoded hextile is provided. In one example, providing an encoded hextile may include transmitting the encoded hextile to a client device. In an alternative example, providing a hextile may include storing the hextile in a hextile catalog that can be accessed later. In a further embodiment, the provided hextile may be continuously updated with new encoded information. As already considered, one or more datasets may contain time data that is updated periodically. When such datasets are encoded as hextiles, previously encoded hextiles may be updated to include new time information when their underlying datasets are updated. Alternatively or additionally, a new hextile may be created when new time data is received.
[0067] Figure 5 is a flowchart illustrating an exemplary method 500 for performing online encoding of a dataset to hex tile. The overall sequence of operations of method 500 is shown in Figure 5. Method 500 may include more or fewer steps, or the order of steps may be arranged differently from the steps shown in Figure 5. Method 500 may be performed by a cloud system as a set of computer-executable instructions that are encoded or stored on a computer-readable medium. Furthermore, method 500 may be performed by gates or circuits associated with a processor, ASIC, FPGA, SOC, or other hardware device.
[0068] As previously discussed, the embodiments disclosed herein provide a means of delivering a portion of a global dataset to a client device on demand in a manner that makes it appear to the client as if the entire global dataset were provided. This is achieved by determining specific data related to the current view of a map displayed on the client and delivering the data encoded in hex-tiles related to the view. One process for doing so is shown in the offline encoding method 500 shown in Figure 5. The flow begins with an operation 502 in which a request for view-related data is received from the client device. In one embodiment, the request is associated with the current view of a map displayed on the client. As discussed above, the view may include the current location being displayed, the current zoom level or resolution of the map, and / or one or more related datasets. As discussed, the dataset may be determined based on a positive selection of datasets provided by the client device, or based on an analysis or enrichment operation requested by the client device, or requested to be performed by the client device itself.
[0069] Upon receiving a request with view information, the flow proceeds to operation 504, in which one or more datasets corresponding to the view are determined. The determination may be based on an analysis of the spatial information of one or more datasets to identify data related to the location and resolution of the view associated with the request. For example, location and resolution information associated with the view may be used to query one or more datasets to identify datasets that have spatial information corresponding to the view's location and resolution. Alternatively, location and information data may be used, for example, to identify existing hex styles corresponding to the view from a hex style catalog.
[0070] The flow identifies the data corresponding to the view, followed by operation 506 in which the identified data is encoded into hextiles. In the example, encoding the data into hextiles may be performed as described in relation to Figure 4. Alternatively or additionally, instead of encoding the data in operation 506, already encoded hextiles corresponding to the view may be retrieved in operation 506. Once the identified data is encoded into hextiles and / or the associated hextiles are retrieved from the hextile catalog, the hextiles are provided to the client in operation 508. In one example, the hextiles may be sent to the client over the network in operation 508.
[0071] Figure 6 is a flowchart illustrating an exemplary method 600 for displaying hex-tile data received from an analysis server. The overall sequence of operations of method 600 is shown in Figure 6. Method 600 may include more or fewer steps, or the order of steps may be arranged differently from the steps shown in Figure 6. Method 600 may be executed by a cloud system as a set of computer-executable instructions that are encoded or stored in a computer-readable medium. Furthermore, method 600 may be executed by gates or circuits associated with a processor, ASIC, FPGA, SOC, or other hardware device.
[0072] The flow begins with operation 602, in which a request is sent to the analysis server. In one example, the request may be automatically generated based on the current map view displayed on the device performing method 600. For example, upon receiving an operation on the map view, such as zooming in or out on the map or changing the location shown on the map, a request for hextile data related to the new view may be automatically generated and sent to the analysis server in response to receiving the operation. The request may include view information such as location, zoom level, and / or resolution, as well as dataset information such as data that identifies a particular dataset. In response to sending the request, the flow continues with operation 604, in which hextile data is received from the global analysis server.
[0073] The flow follows operation 606, in which the hex tile data is decoded and rendered on the map view. As already discussed, the decoded data may be rendered as an overlay on the current map view. As discussed above, the decoded data may be rendered in a way that provides indication of the data enrichment or analytical operation performed, such as distinguishing data from different data types (for example, by using different colors or other indicators).
[0074] In one example, the output data may be rendered within a user interface that provides additional functionality for manipulating or viewing the decoded data. In operation 608, requests to manipulate the decoded hextile data are received through the user interface. For example, the user interface may be operable to receive requests to filter or manipulate the decoded data based on the user's requests. In embodiments where the hex data includes time data, the user interface may be operable to display the changes in the decoded data over time. In such an example, the user interface may include a play button that triggers an animation of the decoded data showing the changes over time. The user interface may also be operable to allow the user to select a specific point in time from which to display or control the animation, for example, via a slider provided in the user interface that is operable to trigger playback of the animation of the decoded data in a forward or backward temporal direction.
[0075] When a request is received to manipulate the decrypted hextile data, the operation is performed, and the manipulated data is rendered and displayed in operation 610. Although not shown, method 600 may be performed whenever the view changes. For example, when the user zooms in or out or changes the map location, a new request may be generated, and in response, the corresponding hextile data may be received and rendered. Since the request corresponds to the current view displayed to the user, in the example, only the hextiles relevant to the review (and potentially some adjacent hextiles for caching) may be received in response to the request, thereby reducing the amount of data that needs to be exchanged between the analysis server and the client device. In this way, data may be delivered in a way that makes it appear to the user that the entire global dataset resides on the client device without requiring the transfer of large amounts of data. Alternatively, instead of rendering and displaying the data in operation 610, in operation 610, the data may be stored, further processed, or provided to another application or process.
[0076] Figure 7 shows a simplified block diagram of a device in which an embodiment of the Disclosure may be implemented. The device may be, for example, a mobile computing device. One or more of these embodiments may be implemented in operating environment 700. This is merely an example of a suitable operating environment and is not intended to imply any limitation on the scope of use or functionality. Other well-known computing systems, environments, and / or configurations that may be suitable for use include, but are not limited to, personal computers, server computers, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, programmable consumer electronics such as smartphones, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices.
[0077] In its most basic configuration, the operating environment 700 generally includes at least one processing unit 702 and memory 704. Depending on the exact configuration and type of computing device, the memory 704 (instructions for generating and / or manipulating hex tiles as described herein) may be volatile (e.g., RAM), non-volatile (e.g., ROM, flash memory), or some combination of the two. This most basic configuration is shown by the dashed line 706 in Figure 7. Furthermore, the operating environment 700 may also include storage devices (removable, 708, and / or non-removable, 710), including but not limited to magnetic or optical disks or tapes. Similarly, the operating environment 700 may also have input devices 714, such as remote controllers, keyboards, mice, pens, voice inputs, and onboard sensors, and / or output devices 712, such as displays, speakers, printers, and motors. Further elements that may be included in the environment are one or more communication connections 716, such as LANs, WANs, short-range communication networks, cellular broadband networks, and point-to-point connections.
[0078] In general, the operating environment 700 includes at least some form of computer-readable medium. Computer-readable medium can be any available medium that can be accessed by the processing unit 702 or other devices constituting the operating environment. Computer-readable medium may include, but not limited to, computer storage medium and communication medium. Computer storage medium includes volatile and non-volatile removable and non-removable media implemented in any way or technology for storing information such as computer-readable instructions, data structures, program modules, or other data. Computer storage medium includes RAM, ROM, EEPROM, flash memory, or other memory technologies, CD-ROM, digital versatile disk (DVD), or other optical storage, magnetic cassette, magnetic tape, magnetic disk storage, or other magnetic storage devices, or any other tangible non-temporary medium that can be used to store desired information. Computer storage medium does not include communication medium. Computer storage medium does not include carrier waves or other propagating or modulated data signals.
[0079] Communication media include any information distribution medium that embodies computer-readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave, or other carrier mechanism. The term “modulated data signal” means a signal that sets or modulates one or more of its characteristics in such a way that information is encoded within the signal. Communication media include, but are not limited to, wired media such as wired networks or direct wired connections, as well as wireless media such as acoustic, RF, infrared, and other wireless media.
[0080] Operating environment 700 may be a single computer operating in a networked environment using logical connections to one or more remote computers. Remote computers may be personal computers, servers, routers, network PCs, peer devices, or other typical network nodes, and generally include many or all of the elements described above, as well as other elements not specifically mentioned. Logical connections may include any method supported by available communication media. Such networking environments are commonly found in offices, enterprise-scale computer networks, intranets, and the internet.
[0081] The embodiments disclosed herein relate, in general, to systems and methods for providing a platform for performing geospatial analysis, unification, and visualization of datasets. In the above description, for illustrative purposes, many specific details have been described to bring about a full understanding of the technology introduced above. However, it will be apparent to those skilled in the art that the technology can be implemented without these specific details. In other cases, structures and devices are shown in the form of block diagrams to avoid obscuring the description and to facilitate understanding. For example, the technology is described in one embodiment above primarily in relation to software and specific hardware. However, the present invention applies to any type of computing system that can receive data and commands and present information as part of any peripheral device that provides services.
[0082] In this specification, any reference to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in relation to an embodiment is included in at least one embodiment. The phrase “in one embodiment” appearing in various places in this specification does not necessarily refer to the same embodiment in all instances.
[0083] Some parts of the detailed explanation above are presented in terms of algorithms and symbolic representations of operations on data bits in computer memory. These descriptions and representations of algorithms are sometimes used by those familiar with data processing techniques to communicate the content of their work to others familiar with the same technique. Here and generally, an algorithm is considered a self-consistent set of steps that produce a desired result. A step is one that requires the physical manipulation of a physical quantity. These quantities, though not always, usually take the form of electrical or magnetic signals that can be stored, transferred, combined, compared, and other operations. It has been found that it is sometimes convenient, primarily for reasons of common use, to refer to these signals as bits, values, elements, symbols, characters, words, numbers, etc.
[0084] However, it should be noted that all these and similar terms should be associated with appropriate physical quantities and are merely convenient labels attached to those quantities. As will be evident from the following considerations, unless otherwise specified, throughout this explanation, any use of terms such as “processing,” “computing,” “calculating,” “determining,” and “displaying” is understood to refer to the actions and processes of a computer system or similar electronic computing device that manipulate data represented as physical (electronic) quantities in the registers and memory of a computer system and convert it into other data similarly represented as physical quantities in the memory or registers of a computer system or other such information storage, transmission, or display device.
[0085] The technology also relates to apparatus for performing the operations described herein. Such apparatus may include a multipurpose computer that is specifically constructed for a required purpose or that is selectively activated or reconfigured by a computer program stored in the computer. Such computer programs may be stored on non-temporary computer-readable storage media, including, but not limited to, disks of any kind, including floppy disks, optical disks, CD-ROMs, and magnetic disks, read-only memory (ROM), random access memory (RAM), EPROM, EEPROM, magnetic or optical cards, flash memory including USB keys with non-volatile memory, or any kind of medium suitable for storing electronic instructions, each coupled to a computer system bus.
[0086] Some embodiments may take the form of all-hardware embodiments, all-software embodiments, or embodiments that include both hardware and software elements. One embodiment is implemented in software, including but not limited to firmware, resident software, and microcode.
[0087] Furthermore, some embodiments may take the form of a computer program product accessible from a computer-usable or computer-readable medium that provides program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, the computer-usable or computer-readable medium may be any device that can contain, store, transmit, propagate, or transfer a program for use by or in connection with an instruction execution system, apparatus, or device.
[0088] A data processing system suitable for storing and / or executing program code may include at least one processor directly or indirectly coupled to a memory element via a system bus. The memory element may include local memory used during the actual execution of the program code, mass storage, and cache memory that provides temporary storage for at least some of the program code to reduce the number of times the code must be retrieved from mass storage during execution.
[0089] Input / output or I / O devices (including, but not limited to, keyboards, displays, and pointing devices) may be coupled to the system either directly or through an intermediary I / O controller.
[0090] Network adapters may also be connected to a system to enable a data processing system to connect to other data processing systems or remote printers or storage devices through an intervening private or public network. Modems, cable modems, and Ethernet cards are just a few of the types of network adapters currently available.
[0091] Finally, the algorithms and representations presented herein are not inherently related to any particular computer or other device. Various general-purpose systems may be used with the program according to the teachings herein, or it may be convenient to construct a more specialized device to perform the steps in the required manner. The required structures for various such systems will be evident from the above description. Furthermore, the technology is not described in relation to any particular programming language. It will be understood that various programming languages may be used to carry out the teachings of various embodiments as described herein.
[0092] The above description of embodiments is presented for illustrative and explanatory purposes only. The above description of embodiments is not intended to be exhaustive or to limit this specification to the exact forms disclosed. Many modifications and changes are possible in light of the above teachings. The scope of embodiments is not limited by this detailed description but is intended to be limited more by the claims of this application. As will be understood by those skilled in the art, examples may be embodied in other particular forms without departing from their spirit or essential features. Similarly, the specific naming and divisions of modules, routines, features, attributes, methods, and other embodiments are not essential or material, and mechanisms implementing this specification or its features may have different names, divisions, and / or formats. Furthermore, as will be apparent to those skilled in the art, modules, routines, features, attributes, methods, and other embodiments of this specification may be implemented as software, hardware, firmware, or any combination of these three. Furthermore, whenever a component of this Specified, such as a module, is implemented as software, the component may be implemented as a standalone program, as part of a larger program, as multiple separate programs, as a statically or dynamically linked library, as a kernel-loadable module, as a device driver, and / or in any and any other way currently known or hereafter known to those familiar with the field of computer programming. Moreover, this Specified is by no means limited to embodiments in any particular programming language or embodiments for any particular operating system or environment. Accordingly, this disclosure is intended to describe, and not to limit, the scope of this Specified as set forth in the appended claims. [Explanation of Symbols]
[0093] 100 Systems 101 Geospatial Analysis Server 103, 103a, 103b Geospatial Analysis Applications 105 Network 115, 115a...115n client devices 125 Multiple third-party servers 200 computing devices 202 Hex-tile encoder engine 204 Hex Tile Loader Engine 206 Hextile Decoder Engine 208 User Interface Engine 220 bus 235 processors 237 memory 239 Display Devices 241 Communication Unit 243 Data Storage 251 geospatial datasets 253 Hex Tile Data Catalog 300 ways 400 ways 500 ways 600 ways 700 Operating environment 702 Processing Unit 704 memory 706 Basic Configuration 708 Removable Storage Devices 710 Non-removable storage devices 712 Output Devices 714 Input Devices 716 Communication connection
Claims
1. A method performed by a computer, Steps to access data from one or more datasets, A step of determining a first resolution level of a hex tile based on spatial information related to one or more datasets, wherein the first resolution level is determined based on altitude on a map. A step of encoding the data from one or more datasets into a first set of hex tiles, wherein one or more hex tiles are associated with a first resolution level. A step of determining whether a second set of hex tiles should be generated, wherein the second set of hex tiles is associated with a second resolution level that is coarser than the first resolution level. When it is decided to produce the aforementioned second set of hex tiles, A step of grouping data from at least a first hex tile and a second hex tile from a first set of hex tile data, The steps include aggregating the data from the first hex tile and the second hex tile, A method comprising the steps of encoding the aggregated data into at least a third hex tile, wherein the second set of hex tiles includes the third hex tile.
2. The method according to claim 1, wherein the step of encoding the data into the first set of hex tiles includes generating a hex tile identifier for the hex tiles included in the first set of hex tiles.
3. At least the step of grouping the data from the first hex tile and the second hex tile is, To generate a first truncated identifier, the first hex-style identifier of the first hex-style is truncated, In order to generate a second truncated identifier, the second hex-style identifier of the aforementioned second hex-style is truncated, Comparing the first truncated identifier with the second truncated identifier, The method according to claim 1, further comprising grouping data from the first hex tile and the second hex tile when the first truncated identifier and the second truncated identifier are the same.
4. The method according to claim 3, wherein the third hex tile is associated with a third hex tile identifier, and the third hex tile identifier is the same as the first truncated identifier and the second truncated identifier.
5. The method according to claim 1, wherein the first resolution level is based on the finest resolution level included in the spatial information.
6. A step of determining whether a third set of hex tiles should be generated, wherein the third set of hex tiles is associated with a third resolution level that is coarser than the second resolution level, When it is determined to produce the third set of hex tiles, The steps include grouping data from at least the fourth and fifth hex tiles from a second set of hex tile data, The steps include aggregating the data from the fourth hex tile and the fifth hex tile, The method according to claim 5, further comprising the step of encoding the aggregated data into at least a sixth hex tile, wherein the third set of hex tiles includes the sixth hex tile.
7. A method performed by a computer, Steps to access data from one or more datasets, A step of determining a first resolution level of a hex tile based on spatial information related to one or more datasets, wherein the first resolution level is determined based on altitude on a map. A step of encoding the data from one or more datasets into a set of hex tiles, wherein one or more hex tiles are associated with the first resolution level. A step of determining a map view which is a visualization of the aforementioned data, A step of loading a subset of available data contained in hex tiles from the set of hex tiles based on the map view, wherein the subset of hex tiles corresponds to the map view. The steps include decoding the subset of hex tiles, A method comprising the step of rendering the subset of hex tiles.
8. The method according to claim 7, wherein a subset of hex tiles represents a part of a discrete global grid system corresponding to the map view.
9. The step of decoding the subset of hex tiles is, Adding grid identifiers to dense hex tiles within the subset of hex tiles, or The method according to claim 7, comprising converting between incompatible data formats of one or more datasets.
10. The method according to claim 7, wherein the subset of hex tiles includes time data encoded in the subset of hex tiles.
11. The method according to claim 10, wherein the step of rendering the subset of hex tiles is to generate an animation to be overlaid on the map view, the animation being generated to depict changes in the hex tile data based on time data encoded in the subset of hex tiles.
12. The method according to claim 7, wherein the step of rendering the hex tiles is to overlay the decoded data from the decoded subset of the hex tiles onto the map view.
13. At least one processor, When executed by at least one of the aforementioned processors, Accessing data from one or more datasets, Determining a first resolution level of a hex tile based on spatial information associated with one or more datasets, wherein the first resolution level is determined based on altitude on a map. Encoding the data from one or more datasets into a first set of hex tiles, wherein one or more hex tiles are associated with the first resolution level. To determine whether a second set of hex tiles should be generated, that the second set of hex tiles is associated with a second resolution level coarser than the first resolution level, and When it is decided to produce the aforementioned second set of hex tiles, Grouping data from at least a first hex tile and a second hex tile from the aforementioned first set of hex tile data, Aggregating the data from the first hex tile and the second hex tile, Encoding the aggregated data into at least a third hex tile, wherein the second set of hex tiles includes the third hex tile. Memory that encodes computer executable instructions that perform a method including A system that includes this.
14. The system according to claim 13, wherein encoding the data into the first set of hex tiles is to generate a hex tile identifier for a hex tile included in the first set of hex tiles.
15. Grouping data from at least the first hex tile and the second hex tile is possible. To generate a first truncated identifier, the first hex-style identifier of the first hex-style is truncated, In order to generate a second truncated identifier, the second hex-style identifier of the aforementioned second hex-style is truncated, Comparing the first truncated identifier with the second truncated identifier, The system according to claim 13, further comprising grouping data from the first hex tile and the second hex tile when the first truncated identifier and the second truncated identifier are the same.
16. The system according to claim 15, wherein the third hex tile is associated with a third hex tile identifier, and the third hex tile identifier is the same as the first truncated identifier and the second truncated identifier.
17. The system according to claim 13, wherein the first resolution level is based on the finest resolution level included in the spatial information.
18. The method described above is To determine whether a third set of hex tiles should be generated, wherein the third set of hex tiles is associated with a third resolution level that is coarser than the second resolution level. When it is determined to produce the third set of hex tiles, Grouping data from at least the fourth and fifth hex tiles from the second set of hex tile data, The data from the fourth hex tile and the fifth hex tile is aggregated, The system according to claim 13, further comprising encoding the aggregated data into at least a sixth hex tile, wherein the third set of hex tiles includes the sixth hex tile.