Patent Grant
10346131
The present application is related to U.S. patent application Ser. No. 14/669,715 filed on Mar. 26, 2015 and entitled “Enhanced Conversion Between Geohash Codes and Corresponding Longitude/Latitude Coordinates,” the disclosure of which is hereby incorporated by reference herein. A copy of this unpublished application is submitted herewith and cited in an accompanying Information Disclosure Statement. Each of the named inventors of the aforementioned application is also named as an inventor in the present application, and both applications are assigned to International Business Machines Corp. (IBM). The aforementioned application was filed less than one year before the filing date of the present application, and had not yet been published as of the filing date of the present application.
A paper entitled “Fast and Flexible Conversion of Geohash Codes to and from Latitude/Longitude Coordinates,” the disclosure of which is hereby incorporated by reference herein, was presented at the 23rd Annual IEEE International Symposium on Field-Programmable Custom Computing Machines in May 2015. A copy of this paper is submitted herewith and cited in an accompanying Information Disclosure Statement (IDS). Each of the authors of this paper is also named as an inventor in the present application. This paper was not published or otherwise made available to the public more than one year before the filing of the present application.
The present invention relates generally to the electrical, electronic and computer arts, and, more particularly, to geographical information management.
In the era of Big Data and the Internet-of-Things-That-Move, embedded location sensing (e.g., Global Position System or GPS) devices are becoming ubiquitous within smart phones, laptops, smart watches, navigation systems, and even digital cameras. These embedded devices continuously produce time-stamped spatial (i.e. spatiotemporal) data, thus allowing for querying of devices, cars, and/or individuals in motion. Analyzing this data (e.g., extracting patterns) presents significant business opportunities, such as by enabling the resolving of complex problems pertaining to fields including but not limited to crime pattern analysis, epidemic spread characterization, insurance pricing, and traffic congestion prediction.
However, analyzing spatiotemporal data also creates new challenges arising from the overwhelming amounts of such data being produced, as well as the complexity of the queries coupled with processing performance constraints (in many cases real-time). Moreover, the volume of such data is rapidly increasing, especially due to the widespread use of GPS-enabled smart-phones. Thus, new high-performance techniques are needed to attain improved levels of processing performance for spatial (e.g., geographic) queries.
Geohash is a geographic coordinate system which was recently introduced in 2009, and which is widely used for indexing in geographical information systems (GIS). 0/1/2-D geometries can be represented using one or more geohash codes of potentially varying precisions (i.e. code lengths) by encoding a point (0-dimension), line (1-dimension) or 2-D shape as a 2-D shape (collection of boxes) when encoded with geohashes. Geohash codes have many benefits over the conventional longitude latitude system, including integer indexing, arbitrary precision (shortening the code lowers precision), and simple proximity estimation (prefix matching).
However, traditional spatial algorithms operate on data represented using the conventional latitude/longitude geographical coordinate system, and as such spatial predicates on 0/1/2-D geometries are instead evaluated using the Dimensionally Extended Nine-Intersection Model (DE-9IM) matrix, which lacks the aforementioned benefits associated with geohash-coded geometries. Geometries (such as geographical regions) can be represented in several ways, such as by a list of edges (and respective vertices) or by a list of geohash blocks. Spatial predicates are operations applied to determine relations between geometries. Spatial predicates are evaluated using the DE-9IM model for non-geohash-encoded geometries, but there exists no defined mechanism to evaluate spatial predicates on geohash-encoded regions.
Principles of the invention, in accordance with one or more embodiments thereof, provide techniques for geohash-based evaluation of spatial predicates and/or spatial primitives. In one aspect, a method of performing an evaluation of a spatial predicate for a first region and a second region comprises: receiving a first set of one or more geohashes representing the first region, and receiving a second set of one or more geohashes representing a second region. The method also comprises, for each geohash within the first set of one or more geohashes: performing a respective pairwise evaluation of a first spatial primitive for the geohash within the first set and each of the geohashes within the second set to produce a set of first binary results corresponding to respective ones of the geohashes within the second set; and combining the set of first binary results using a first Boolean logic operator to produce one of a set of second binary results corresponding to respective ones of the geohashes within the first set. The method further comprises combining the set of second binary results using a second Boolean logic operator to produce a third binary result corresponding to the first one of the set of spatial primitives.
In another aspect, a method of evaluating each of plurality of spatial primitives for a pair of geohashes comprises the steps of: detecting which of the pair of geohashes is a shorter geohash and which of the pair of geohashes is a longer geohash; identifying a breakpoint for the pair of geohashes; determining a set of one or more masks each associated with at least one of the pair of geohashes; evaluating a first one of the spatial primitives for the pair of geohashes, the first one of the spatial primitives being a “contain” spatial primitive; and evaluating at least a second one of the spatial primitives for the pair of geohashes, the at least second one of the spatial primitives being at least one “touch” spatial primitive.
As used herein, “facilitating” an action includes performing the action, making the action easier, helping to carry the action out, or causing the action to be performed. Thus, by way of example and not limitation, instructions executing on one processor might facilitate an action carried out by instructions executing on a remote processor, by sending appropriate data or commands to cause or aid the action to be performed. For the avoidance of doubt, where an actor facilitates an action by other than performing the action, the action is nevertheless performed by some entity or combination of entities.
One or more embodiments of the invention or elements thereof can be implemented in the form of a computer program product including a computer readable storage medium with computer usable program code for performing the method steps indicated. Furthermore, one or more embodiments of the invention or elements thereof can be implemented in the form of a system (or apparatus) including a memory, and at least one processor that is coupled to the memory and operative to perform exemplary method steps. Yet further, in another aspect, one or more embodiments of the invention or elements thereof can be implemented in the form of means for carrying out one or more of the method steps described herein; the means can include (i) hardware module(s), (ii) software module(s) stored in a computer readable storage medium (or multiple such media) and implemented on a hardware processor, or (iii) a combination of (i) and (ii); any of (i)-(iii) implement the specific techniques set forth herein.
Techniques of the present invention can provide substantial beneficial technical effects. By way of example only and without limitation, one or more embodiments may advantageously facilitate geohash-based evaluation of spatial predicates and/or spatial primitives, with significantly increased performance relative to conventional non-geohash-based evaluation techniques, such as DE-9IM discussed above.
These and other features and advantages of the present invention will become apparent from the following detailed description of illustrative embodiments thereof, which is to be read in connection with the accompanying drawings.
The following drawings are presented by way of example only and without limitation, wherein like reference numerals (when used) indicate corresponding elements throughout the several views, and wherein:
It is to be appreciated that elements in the figures are illustrated for simplicity and clarity. Common but well-understood elements that may be useful or necessary in a commercially feasible embodiment may not be shown in order to facilitate a less hindered view of the illustrated embodiments.
Principles of the present invention will be described herein in the context of illustrative methods and/or apparatuses for geohash-based evaluation of spatial predicates and/or spatial primitives. It is to be appreciated, however, that the invention is not limited to the specific apparatuses and/or methods illustratively shown and described herein. Rather, aspects of the present disclosure relate more broadly to methods and apparatus for performing geohash-based evaluation of spatial predicates and/or spatial primitives. Moreover, it will become apparent to those skilled in the art given the teachings herein that numerous modifications can be made to the embodiments shown that are within the scope of the claimed invention. That is, no limitations with respect to the embodiments shown and described herein are intended or should be inferred.
Geohash is a geographic coordinate system that hierarchically divides space into grid-shaped buckets.
A geohash code can be represented as a binary string, where the bits respective to the longitude and latitude space divisions are interleaved. For example, the geohash code 150 includes a bit sequence, with a first set of interleaved bits (e.g., read from left to right, the first, third and fifth bits) representing bits partitioning longitude from an initial interval {−180, 0, +180}, and a second set of interleaved bits (e.g., read from left to right, the second, fourth and sixth bits) representing bits partitioning latitude from an initial interval {−90, 0, +90}.
Thus, a geohash code is at its heart a string of bits, where each bit is generated by hierarchically dividing a two-dimensional space into grid shapes, interleaving vertical and horizontal divisions. One single geohash code represents one grid section on the earth. As a grid section is split into smaller ones, more bits are appended to the end of the geohash bit string. Smaller regions require more bits to be represented, as they are more precise. Note that 64-bit geohashes can represent any location on the surface of the earth with centimeter-scale precision.
With reference to
Alternatively, if the longitude of the point of interest 130 is smaller or equal to the mid of the interval, then a geohash bit of “0” is produced, and the new interval becomes
This process is repeated up to the desired precision (number of geohash bits) in a bit-serial fashion. The same method is applied to the latitude, where the initial interval is {−90, 0, +90}. Finally, the longitude and latitude bits are interleaved in the resulting geohash code 150.
With continued reference to
Although the techniques discussed herein are also applicable to variable length strings,
gL=l0,l1, . . . ,li, . . . ,lN−1
,liϵ{0,1}, where 0≤i<N
gS=si|siϵ{0,1}, if 0≤i<S;si=0, otherwise
gL=li|liϵ{0,1}, if 0≤i<L;li=0, otherwise
where size(gS)=S,size(gL)=L, and S<L (or S≤L)
The hierarchical structure of a geohash code entails several properties and intuitions, which can be used to process geohash operations. For example, a single code can represent two directions (axes) on a two dimensional space at once because it interleaves digits, or bits, for each of latitude horizontally and longitude vertically. On the other hand, two distinct values are needed when using the conventional latitude/longitude coordinate system. As another example, a shorter geohash code represents a larger region than a longer code. As it narrows down to a more precise region, more bits are needed for accuracy.
When multiple geohash codes share a common prefix, that common prefix substring code represents the larger region covering all of the said geohashes. Two locations with a long common geohash prefix are close to each other, and nearby locations usually share a similar prefix. However, it is not always guaranteed that two close locations share a long common prefix (when they are located near the border of two bounding boxes).
The first bit after this common prefix is referred to herein as the breakpoint, and may be more formally defined as a bit index, K, where the first different bit value between two geohashes, S and L appears such that LK≠SK and Li=Si where 0≤i<K. The breakpoint divides these two geohash codes into multiple substrings. The prefix region is the substring of common bits at [0, K−1], where K is the breakpoint. prefixS=prefixL and size(prefix)=K. The suffixes are the substrings of valid bits (i.e., the valid regions) starting from the breakpoint K:
suffixS: a substring of gS from K to the end S−1.
suffixL: a substring of gL from K to the end L−1.
suffixC: a substring of gL from K to S−1.
suffixT: a substring of gL from S to L−1.
As used herein, the boundary, interior and exterior of a geohash code are defined as follows: A point is a boundary point of a geohash if every neighborhood of the point contains at least one point in the corresponding geohash box and at least one point not in the corresponding geohash box. The interior of a geohash is all points that are part of the corresponding geohash box, including the boundary points. The exterior of a geohash is all points that are not part of the interior (i.e. including boundary) points of the corresponding geohash box.
For a given geometry that is represented using multiple geohash codes, the definitions are similar. The interior of a geohash-coded geometry is the union of all the individual geohashes' interiors. The boundary of a geohash-coded geometry is the union of all the individual geohashes' boundaries, with the exception of the intersecting individual boundaries of adjacent individual geohashes. The exterior of a geohash-coded geometry is all points that are not part of the interior of that geohash-coded geometry.
The one-dimensional black portion of box 321 represents the intersection of a's boundary B(a) and b's interior I(b). The zero-dimensional black shape(s) in box 322 represents the intersection of a's boundary B(a) and b's boundary B(b). The one-dimensional black shape(s) in box 323 represents the intersection of a's boundary B(a) and b's exterior E(b).
The two-dimensional black shape in box 331 represents the intersection of a's exterior E(a) and b's interior I(b). The one-dimensional black shape in box 332 represents the intersection of a's exterior E(a) and b's boundary B(b). The two-dimensional black shape(s) in box 333 represents the intersection of a's exterior E(a) and b's exterior E(b).
Illustrative embodiments of the present invention provide methods for evaluating spatial predicates on geohash-coded geometries which include replacing the traditional DE-9IM model with spatial primitives, such as equals, contains, and touches (internal, external, corner). Geohash spatial primitive calculation is about analyzing the spatial relations between two geographical regions each defined by a single geohash.
A geohash gS contains a geohash gL if the region RS defined by gS is larger than and can entirely cover a region RL defined by gL. In other words, geohash gS contains geohash gL if the region RL defined by geohash gL is part of the region RS defined by geohash gS. From the perspective of geohash properties, gS is the prefix of gL. The contain primitive 360 is illustrated in 365 and 369.
For two geohashes gA and gB, regardless of relative lengths, geohash gA and a geohash gB touch each other if their intersection is zero or one dimensional region (i.e. point or line). In other words, if the boundaries of the regions defined by the geohashes gA and gB share a (zero-dimensional) point or a (one-dimensional) line segment, then gA touches gB (and vice versa). Whereas the contain primitive corresponds to the relations between the prefixes of two geohashes, the touch primitives pertain to the relations between their suffixes. The touch primitives 370 are illustrated in 374, 376 and 378.
There are three forms of geohash touch: internal touch, external touch, and corner touch. Internal touch is illustrated in 374, which is identical to 365 discussed above with regard to the contain primitive. Internal touch also requires satisfaction of the contain primitive. External touch is illustrated in 376. Corner touch is illustrated in 378.
To facilitate further discussions, two geometric concepts are defined herein: push towards and overlap. While generating a geohash code, if after some point in either (latitude, longitude) dimension only 0's or only 1's are generated, then the region being defined by the geohash code is said to push towards one particular direction/edge as narrowing down to smaller region from a bigger region. Given two geohashes and regardless of their relative lengths, if the segment projection of the two geohashes on either (latitude, longitude) axis overlay, then the regions defined by the geohashes overlap in a given dimension.
A geohash gS and a geohash gL touch each other internally if the region defined by gS contains the region defined by gL and their boundaries overlap on one or two edges such that their intersection is a one dimensional line on each of these edge(s). Equivalently, gL and gS touch each other internally if gL is contained in gS AND gL pushes toward an edge of gS. gL pushes toward an edge of gS when, after the breakpoint, all the remaining latitude (or longitude) bits in gL hold same values (either all 1's or all 0's).
For the external touch, no geohash contains the other, but rather they intersect only at the boundary. After splitting at a breakpoint, the geohashes push toward each other in one dimension (either latitude or longitude) and overlap in the other perpendicular direction. Equivalently, for two geohashes gA and gB, regardless of their relative lengths, geohash gA and geohash gB touch each other externally if the region defined by gA does not contain the region defined by gB and their boundaries overlap on one edge.
A geohash gS and a geohash gL touch each other at a corner, if the region defined by gS does not contain the region defined by gL and their boundaries overlap only at a corner, with a zero-dimensional intersection (i.e., the single point at that corner). More broadly, regardless of their relative lengths, two geohashes gA and gB touch each other at a corner if they push toward each other in both dimensions (latitude and longitude).
The discussion thus far has been focused on evaluating spatial relations between pairs of geohash codes. The techniques introduced above can be extended to apply to arbitrary-shaped geohash-coded regions A and B, which are represented as geohash codes {A1, A2, A3, . . . , Aa} and {B1, B2, B3, . . . , Bb}, respectively; the actual number of geohash codes per region (i.e. a for A and b for B) can vary, with a minimum of 1 code per region.
By analyzing spatial relations of geohash codes pairwise, one from each set (region A and region B), one can in turn express the spatial relations of the two geometric shapes. For example, if all geohash codes from region A are contained in geohash codes from region B, then A is contained in B. Another example is if at least one geohash code from region A touches a geohash code from region B, then region A touches region B.
Architecture 400 shown in
Within architecture 400 shown in
Component 410 also includes subcomponent 440 corresponding to a last geohash of region A (Aa 441). Subcomponent 440 includes modules each corresponding to a respective geohash within region B (b1, . . . , b2). Module 443 evaluates first spatial primitive pr1 on the last geohash of region A (Aa 441) and the first geohash of region B (B1442) to produce bit 444. Module 445 evaluates first spatial primitive pr1 on the last geohash of region A (Aa 441) and the last geohash of region B (Bb 449) to produce bit 446. Within subcomponent 440, logic gate 447 receives the respective bits (e.g., 444 and 446) produced by each module and combines them using Boolean operation R1 to produce bit 448, which is output from subcomponent 440.
Component 410 further includes logic gate 417, which receives the respective bits (e.g., 428 and 448) produced by each module and combines them using Boolean operation R2 to produce bit 418, which is output from component 410. The logic gates (e.g., 427 and 447) within respective subcomponents (e.g., 420 and 440) of a given component (e.g., 410) all perform the same Boolean operation R1. Logic gate 417 performs Boolean operation R2, which may or may not be the same as Boolean operation R1.
Within architecture 400 shown in
Component 450 also includes subcomponent 480 corresponding to a last geohash of region A (Aa 481). Subcomponent 480 includes modules each corresponding to a respective geohash within region B (b1, . . . , b2). Module 483 evaluates last spatial primitive prP on the last geohash of region A (Aa 481) and the first geohash of region B (B1482) to produce bit 484. Module 485 evaluates first spatial primitive pr1 on the last geohash of region A (Aa 481) and the last geohash of region B (Bb 489) to produce bit 486. Within subcomponent 480, logic gate 487 receives the respective bits (e.g., 484 and 486) produced by each module and combines them using Boolean operation R3 to produce bit 488, which is output from subcomponent 480.
Component 450 further includes logic gate 457, which receives the respective bits (e.g., 468 and 488) produced by each subcomponent and combines them using Boolean operation R2 to produce bit 458, which is output from component 450. The logic gates (e.g., 467 and 487) within respective subcomponents (e.g., 460 and 480) of a given component (e.g., 450) all perform the same Boolean operation R3. Logic gate 457 performs Boolean operation R4. Any one of Boolean operations R1-R4 may or may not be the same as any other one of Boolean operations R1-R4.
Architecture 400 also includes logic gate 497, which receives the respective bits (e.g., 418 and 458) produced by each component and combines them using Boolean operation R5 to produce bit 498, which is output from architecture 400 as the evaluation of the spatial predicate for regions A and B. Boolean operation R5 may or may not be the same as any one of Boolean operations R1-R4.
Where evaluation of a given spatial predicate only requires evaluation of a single spatial primitive, only a single component (e.g., 410) is required, with the output of that component (e.g., 418) being output as the evaluation of the spatial predicate for regions A and B. In such an embodiment, component 450 and logic gate 497 are unused and may be eliminated, although it may be desirable to retain them in order to retain the ability to evaluate special predicates which require evaluation of multiple spatial primitives. An embodiment of the present invention may use the aforementioned spatial primitives to implement one or more of the following spatial predicates: equals, disjoint, touch (also known as meet), contain, cover, within (also known as inside), coveredBy, intersect, overlap, touchBorder.
The spatial predicate equals (A, B) is true when regions A and B are topologically equal; in other words, the interiors of A and B intersect and no part of the interior or boundary of one region intersects the exterior of the other. When evaluating the “equals” spatial predicate using the conceptual architecture shown in
The spatial predicate disjoint (A, B) is true when A and B have no point in common and thus form a set of disconnected geometries. When evaluating the “disjoint” spatial predicate using the conceptual architecture shown in
The spatial predicate touch (A, B) is true when A and B have at least one boundary point in common but no interior points. When evaluating the “touch” spatial predicate using the conceptual architecture shown in
The spatial predicate touchBorder (A, B) is true when A and B have at least one boundary point in common. When evaluating the “touchBorder” spatial predicate using the conceptual architecture shown in
The spatial predicate contains (A, B) is true when B lies in A and their interiors intersect. Equivalently, contains (A, B) is true when no points of B lie in the exterior of A, and at least one point of the interior of B lies in the interior of A. When evaluating the “contains” spatial predicate using the conceptual architecture shown in
The spatial predicate intersects (A, B) is true when regions A and B have at least one point in common. When evaluating the “intersects” spatial predicate using the conceptual architecture shown in
The spatial predicate covers (A, B) is true when region B lies in region A. An equivalent definition is that covers (A, B) is true when no points lie in the exterior of A. Another equivalent definition is that covers (A, B) when every point of B is a point of (the interior or boundary of) A. The foregoing definitions are broadly applicable to geohash-coded geometries and also to non-geohash geometries such as points and line segments. However, for geohash-coded geometries, point and line segment geometries are coded as one or more 2-D shapes (geohash boxes). Thus, an embodiment of the present invention may implement covers (A, B) in the same way as contains (A, B).
The spatial predicate within (A, B) is true when A lies in the interior of B. An embodiment of the present invention may implement within (A, B) in the same way as contains (B, A).
The spatial predicate coveredBy (A, B) is true when every point of A is a point B, and the interiors of the two regions have at least one point in common. An embodiment of the present invention may implement coveredBy (A, B) in the same way as covered (B, A).
Embodiments of the present invention may implement the generic architecture shown in
More particularly, an exemplary module comprises novel circuitry for calculating primitives at the logic circuit level. Since bit level operations are required, primitive evaluation in hardware has considerable benefits against software design in terms of performance, throughput as well as latency. Using parallel hardware, these operations are parallelizable, scalable, and able to be implemented in a fully pipelined manner regardless of the length or size of the geohash. Additional advantages associated with embodiments in which spatial primitives are evaluated using hardware include: (1) deterministic high throughput operation (one geohash per cycle), (2) deterministic low latency operation, (3) low power consumption in customizable hardware, (4) low resource utilization due to the ability to efficiently implement bit level operation in logic circuit(s), and/or (5) flexible circuit design with respect to an architected maximum geohash code size. Moreover, an embodiment can employ field-programmable gate arrays (FPGAs) for efficiently exploiting the bit-level granularity of geohash codes, resulting in a resource-friendly architecture operating at wire-speed (e.g., without stalls).
Geohash primitive calculation module 500 has four outputs 550, 560, 570 and 580. Each of these outputs consists of a single bit indicating whether a respective spatial primitive is satisfied with respect to input geohashes gA and gB. Output 550 indicates whether one of the input geohashes contains the other input geohashes. Output 560 indicates whether the input geohashes touch internally. Output 570 indicates whether the input geohashes touch externally. Output 580 indicates whether the input geohashes touch at a corner. Thus, geohash primitive calculation module 500 performs a parallel computation of each of the spatial primitives discussed above with reference to
The output 650 of breakpoint identification stage 640 is provided to mask generation stage 660. Mask generation stage 660 is also provided with one or more constants 665 (e.g., 0xFFFF, 0xAAAA, 0x5555, etc.) and produces output 670. Output 670 may comprise a set of six masks: maskprefix 671, maskshort 672, masklong 673, masksuffix:S 674, masksuffix:L 675, and masksuffix:T 676. The outputs 670 of mask processing stage 660 are provided to the main stage, geohash contain/touch operation stage 680.
The main stage, geohash contain/touch operation stage 680, includes four modules 685-688 which execute in parallel to generate the four outputs 550-580 shown in
As shown in
The output 725 of multiplexer 720 is equal to gA:value 510 if select signal 715 is 0 and is equal to gB:value 530 if select signal is 1. Thus, the output 725 of multiplexer 720 is the value of the shorter of the two input geohashes, gS:value (or more simply gS), which has N bits. The output 745 of multiplexer 740 is equal to gA:size 520 if select signal 715 is 0 and is equal to gB:size 540 if select signal is 1. Thus, the output 745 of multiplexer 740 is the size of the shorter of the two input geohashes, gS: size, which has log N bits. In addition to being a component of the output 630 of preprocessing stage 620, the output 745 of multiplexer 740 is also provided to a binary decoder 750 which produces output 755, which has N bits representing the decoded size of gS or D(gS).
The output 765 of multiplexer 760 is equal to gB:value 530 if select signal 715 is 0 and is equal to gA:value 510 if select signal is 1. Thus, the output 765 of multiplexer 760 is the value of the longer of the two input geohashes, gL:value (or more simply gL), which has N bits. The output 785 of multiplexer 780 is equal to gB:size 540 if select signal 715 is 0 and is equal to gA:size 560 if select signal is 1. Thus, the output 785 of multiplexer 780 is the size of the longer of the two input geohashes, gL:size, which has log N bits. In addition to being a component of the output 630 of preprocessing stage 620, the output 785 of multiplexer 780 is also provided to a binary decoder 790 which produces output 795, which has N bits representing the decoded size of gL or D(gL).
Binary decoders 750 and 790 each receive as input log N bits representing a geohash size (gS:size 745 for decoder 750 and gL:size 785 for decoder 790) and produce decoded data signals D(gS) 755 and D(gL) 795 respectively. Each of these decoded data signals is a one-hot N-bit vector consisting of all zeros except for a single “1” bit at the position reflecting the size. Shown below are representations of exemplary geohashes denoted by gS (shorter geohash) and gL (longer geohash), and their decoded sizes D(gS) and D(gL). Note that the “1” in D(gS) occurs to the left of (i.e., before when read left-to-right) the “1” in D(gL) because gS is shorter than gL. In other words, because gL is at least as long as gS, the index of the “1” in D(gL) is equal to or larger than the “1” in D(gS). When S is the size of the shorter geohash, and L is the size of the longer one (i.e., S≤L≤N):
gS={s0s1 . . . sK−2sK−1}∥{sKsK+1 . . . sS−2sS−1}∥{0S . . . 0L−20L−1}∥{0L . . . 0N−1}
D(gS)={0001 . . . 0K−20K−1}∥{0K0K+1 . . . 0S−20S−1}∥{1S . . . 0L−20L−1}∥{0L . . . 0N−1}
gL={l0l1 . . . lK−2lK−1}∥{lKlK+1 . . . lS−2lS−1}∥{lS. . . lL−2lL−1}∥{0L . . . 0N−1}
D(gL)={0001 . . . 0K−20K−1}∥{0K0K+1 . . . 0S−20S−1}∥{0S . . . 0L−20L−1}∥{1L . . . 0N−1}
As discussed above with reference to
gL={l0l1 . . . lK−1}∥{lKlK+1 . . . lS−2lS−1}∥{lS . . . lL−2lL−1}∥{0L . . . 0N−1}
gS={s0s1 . . . sK−1}∥{sKsK+1 . . . sS−2sS−1}∥{0S . . . 0L−20L−1}∥{0L . . . 0N−1}
gL⊕gS={l0⊕s0 . . . lK−1⊕sK−1}∥{lK⊕sK . . . lS−1⊕sS−1}∥{lS⊕0S . . . lL−1⊕0L−1}∥{0L . . . 0N−1}
gL⊕gS={0001 . . . 0K−20K−1}∥{lK . . . lS−1⊕sS−1}∥{lS⊕0S . . . lL−1⊕0L−1}∥{0L . . . 0N−1}
Using x, the breakpoint signal BP is computed as an N-bit one-hot signal in which one bit is “1,” and all other bits are “0.” The “hot” bit (i.e. equal to “1”) in BP occurs at the breakpoint. The breakpoint signal of two geohashes BP(gS, gL) can be found by applying the following equation at each bit of x:
BP(gS,gL)i=(
In other words, for each bit xi of x, if xi is equal to “1,” and all preceding bits in x (i.e. x0 . . . xi−1) are zeros, then BPi=1, else BPi=0. A generic representation of the resulting BP signal is:
BP(gS,gL)={0001 . . . 0K−20K−1}∥{1K0K+1 . . . 0S−20S−1}∥{0S . . . 0L−20L−1}∥{0L . . . 0N−1}
Breakpoint identification stage 640 also includes the circuit 800 shown in
Masks 670 are generated in mask generation stage 660 to be used in the main stage 680. Masks block unnecessary bits of code and let the modules 685-688 see only necessary bits, for example, prefix or suffix, which greatly simplifies later processing. These masks can be easily applied in stage 680 by using a bit-wised AND (^) logic gate operation. The masks 671-676 generated by mask generation stage 660 are formally defined in
Maskprefix 671 includes ones for valid bits of the common prefix of the geohashes gS and gL and zeros elsewhere. Maskshort 672 indicates the valid bits of the shorter geohash (gS). Masklong 673 indicates the valid bits of the longer geohash (gL). Masksuffix:S 674 indicates the valid suffix bits of the shorter geohash (suffixS). Masksuffix:L 675 indicates the valid suffix bits of the longer geohash (suffixL). Masksuffix:T 676 indicates the portion of the valid suffix bits of the longer geohash that are after the index of the last valid bit in the shorter geohash (suffixT).
In one embodiment, masks are generated in stage 660 from BP(gS, gL), D(gS), and D(gL), which are generated in stages 620 and 640 as discussed above. Generic representations include:
BP(gS,gL)={0001 . . . 0K−20K−1}∥{1K0K+1 . . . 0S−20S−1}∥{0S . . . 0L−20L−1}∥{0L . . . 0N−1}
D(gS)={0001 . . . 0K−20K−1}∥{0K0K+1 . . . 0S−20S−1}∥{1S . . . 0L−20L−1}∥{0L . . . 0N−1}
D(gL)={0001 . . . 0K−20K−1}∥{0K0K+1 . . . 0S−20S−1}∥{0S . . . 0L−20L−1}∥{1L . . . 0N−1}
Initially, Maskprefix 671, Maskshort 672, and Masklong 673 are generated as follows:
(Maskprefix)i=
(Maskshort)i=
(Masklong)i=
Subsequently, Maskprefix 671, Maskshort 672, and Masklong 673 are used to compute Masksuffix:S 674, Masksuffix:L 675, and Masksuffix:T 676 as follows (with the Boolean inverse and AND operations all being bit-wise):
Masksuffix:S=Maskshort^
Masksuffix:L=Masklong^
Masksuffix:T=Masklong^
In another embodiment, masks 671-673 are generated by using shift operators in which it shifts left a constant value 665 of N bits having all ones, as shown in
If Constantones 665 is shifted left by N−S (the number of shorter geohash bits), then the resulting value will have ones in bit positions 0≤i<S−1 and zeros for the rest, thus generating Maskshort 672. Maskprefix 671 can be similarly generated by shifting Constantones 665 left by N−K, while Masklong 673 can be generated by shifting Constantones 665 left by N−L. The sizes of the geohashes S and L are provided by preprocessing stage 620, as discussed above with reference to
As with the first method discussed above, Maskprefix 671, Maskshort 672, and Masklong 673 can be used to compute Masksuffix:S 674, Masksuffix:L 675, and Masksuffix:T 676 as follows (with the Boolean inverse and AND operations all being bit-wise):
Masksuffix:S=Maskshort^
Masksuffix:L=Masklong^
Masksuffix:T=Masklong^
While the functionality of the contain module 685 in main stage 680 can be implemented in several different ways, the fundamental concept is determining if the valid bits of a shorter geohash are a prefix of a longer geohash. If so, both input geohashes will have a common prefix, with that common prefix being the shorter geohash. If one pair of geohashes is in contain, then the size of shorter geohash, S, and the breakpoint index, K, should typically be same or K is larger than S (K≥S).
BP(gS,gL)={0001 . . . 0K−20K−1}∥{1K≥S . . . 0L−20L−1}∥{0L . . . 0N−1}
Decoded(gS)={0001 . . . 0S−20S−1}∥{1S . . . 0L−20L−1}∥{0L . . . 0N−1}
Note that the breakpoint should happen at most at S from the graphical intuition of geohash, but while handling an N number of bits including invalid bits, it could be over S. Such instances will not affect the result of the geohash primitive calculation. Here is an example, where K is larger than S, with K=L−2:
gS={0001 . . . 0K−20K−1}∥{0K0K+1 . . . 0S−20S−1}∥{0S . . . 0L−20L−1}∥{0L . . . 0N−1}
gL={0001 . . . 0K−20K−1}∥{0K0K+1 . . . 0S−10S−1}∥{0S . . . 1L−20L−1}∥{0L . . . 0N−1}
One embodiment of the contain module 685 in main stage 680 involves subtracting the breakpoint index from a geohash size. A decoded gS has only one active bit (“1”), which is located at the end point of valid gS bits. When gS contains gL, they have a shared prefix and the breakpoint always happens at or over the end point of gS. As shown above, Decoded (gS) is always equal or less than BP(gS, gL) when gS contains gL. Thus, contain (gS, gL) can be computed as follows:
If Decoded (gS)≥BP(gS, gL),
Then gS contains gL,
Else gS does not contain gL
Another embodiment of the contain module 685 in main stage 680 includes, at each geohash size bit, checking all previous bits, as shown in
Thus, contain (gS, gL) can be computed as follows:
For 0≤i<N
A further embodiment of the contain module 685 in main stage 680 includes using a prefix mask. Since gL and gS have a common prefix {l0l1 . . . lS−2lS−1}={s0s1 . . . sS−2sS−1}, applying an XOR operation to gL and gS, gL⊕gS, should result in all zeros in the prefix region if contain (gS, gL) is true. In order to focus only on the prefix region, the remaining bits can be cleared by applying Maskshort 672. gL is contained in gS only if the short-masked XOR of gL and gS (i.e. gS⊕gS^Maskshort) contains all zeros.
gL={l0l1 . . . lS−2lS−1}∥{lS . . . lL−1}∥{0L . . . 0N−1}
gS={s0s1 . . . sS−2sS−1}∥{0S . . . 0L−1}∥{0L . . . 0N−1}
gL⊕gS={l0⊕s0 . . . lS−1⊕sS−1}∥{lS⊕0S . . . lL−1⊕0L−1}∥{0L . . . 0N−1}
(gL⊕gS)^Maskshort={l0⊕s0 . . . lS−1⊕sS−1}∥{0S . . . 0L−1}∥{0L . . . 0N−1}
This algorithm can be equivalently expressed in pseudocode as follows:
Evaluating whether two geohash regions touch internally requires checking (1) if a large region contains a smaller one, and (2) if the smaller region pushes toward an edge of the large one from the inside. The first of these conditions is evaluated by the contain module 685 of main stage 680, discussed above. With respect to the second condition, when a geohash region pushes towards one direction, latitude or longitude, bit values for that direction should be all same, zeros (0) or ones (1) because of the hierarchical structure: lK+2=lK+4= . . . =lK
The remainder of the internal touch operation deals with checking a suffix of the longer geohash code, suffixL. However, if one of the geohash regions contains the other, i.e., if the first condition is true, then they will have a common prefix whose length is the same as the size of the smaller geohash. Thus, it is sufficient to check only the portion of the suffix of the longer geohash (suffixL) which is beyond the endpoint of the shorter geohash: suffixT shown in
An embodiment of the internal touch module 686 of the main stage 680 masks and checks all latitude or longitude bits by applying a suffix mask to the longer geohash to isolate suffix data in valid bits to check all bit values of latitude or longitude in a suffix. The following algorithm generates Masksuffix:T:lat or Masksuffix:T:long depending on which dimension includes the breakpoint. If the breakpoint is a latitude bit, then Masksuffix:T:lat is needed, else Masksuffix:T:long. These can be generated by applying Masksuffix:T 676 to respective binary constants, 101010 . . . and 010101 . . . . The proper mask is then applied to the longer geohash and the remaining bits are checked to be zeros (0) or ones (1).
Masksuffix:T 676 is also separated into components for latitude 1011 (Masksuffix:T:lat) and longitude 1012 (Masksuffix:T:lon), for example by applying Masksuffix:T 676 to respective binary constants, 101010 . . . and 010101 . . . . The respective latitude components of Masksuffix:T 1011 and masked output 1017 are provided to a comparator 1040, which produces a binary output 1045 having a value of 1 if the aforementioned latitude components are equal and a value of 0 otherwise. The respective longitude components of Masksuffix:T 1012 and masked output 1018 are provided to another comparator 1060, which produces a binary output 1065 having a value of 1 if the aforementioned longitude components are equal and a value of 0 otherwise.
The aforementioned bit output values 1035, 1045, 1055 and 1065 are then input into an OR gate 1070 to produce push 1075 similar to that produced by the above pseudocode. Push 1075 is combined with the output 550 of contain module 685 in AND gate 1080 to produce the final output value 560.
When two geohash regions touch each other externally, they split at the breakpoint, push toward each other in one dimension, and overlap in the other dimension. When two geohash regions, RL and RS, push towards each other, one of two cases can occur at the breakpoint K: (1) sK=1 and lK=0 or (2) sK=0 and lK=1. Note that, by definition, sK≠lK. In both of the aforementioned cases, the remaining latitude or longitude bits after K, should be the inverse of sK and lK, in order to stay touching:
sK+2=sK+4= . . . =
lK+2=lK+4= . . . =
By way of example, if the two geohash regions split into different sides of a longitude line, such as a left side of zero in latitude and a right side of one latitude (i.e., the breakpoint is a latitude value), then the region with zero in latitude at the breakpoint must have all ones in latitude beyond the breakpoint, and the region with one in latitude at the breakpoint must have all zeros in latitude beyond the breakpoint. This is necessary for the regions to push towards one direction and thereby stay touching. For example, when the breakpoint K is a latitude value:
gL:lat={prefix}∥{lKlK+2lK+4 . . . }∥{0L . . . 0N−1}
gS:lat={prefix}∥{sKsK+2sK+4 . . . }∥{0L . . . 0N−1}
gL:long={prefix}∥{lK+1lK+3lK+S . . . lS−1lS . . . }∥{0L . . . 0N−1}
gS:long={prefix}∥{sK+1sK+3sK+5 . . . sS−1}∥{0L . . . 0N−1}
The latitude values should therefore be either:
At the same time, the regions defined by the geohashes must overlap in the other dimension. The remaining bits, <lK+1, lK+3, . . . > in suffixC should be same as <sK+1, sK+3, . . . > in suffixS. For example, where breakpoint K is a latitude value as discussed above, the longitude of gS should be a prefix of gL. Expressed differently:
sK+1=lK+1,sK+3=lK+3, . . . si=li,
where i=K+2n+1≤S, s·t·nϵ{0, }
By definition of breakpoint and prefix, gL⊕gS has all zeros in the prefix <0 . . . K−1>. In order for the conditions discussed above in the previous section to be true, gL⊕gS should have all ones at {K, K+2, K+4, . . . } and all zeroes at {K+1, K+3, K+5, . . . } in the range between K and S−1. In other words, gL⊕gS must have a pattern of {1, 0, 1, 0, . . . } in the range between K and S−1. This requirement is referred to as the XOR condition:
gL={l0l1 . . . lK−1}∥{lKlK+1 . . . lS−2lS−1}∥{lS . . . lL−2lL−1}∥{0L . . . 0N−1}
gS={s0s1 . . . sK−1}∥{sKsK+1 . . . sS−2sS−1}∥{0S . . . 0L−20L−1}∥{0L . . . 0N−1}
gL⊕gS={l0⊕s0 . . . lK−1⊕sK−1}∥{lK⊕sK . . . lS−1⊕sS−1}∥{lS⊕0S . . . lL−1⊕0L−1}∥{0L . . . 0N−1}
gL⊕gS={0001 . . . 0K−20K−1}∥{lK . . . lS−1⊕sS−1}∥{lS⊕0S . . . lL−1⊕0L−1}∥{0L . . . 0N−1}
Note that other values {lS, . . . , lL−1} will remain past S, but these can be removed by masking gL⊕gS with masksuffix:S. Such masking will result in data being present only between K and S−1. When the XOR condition holds, two separate cases must be considered to check for an external touch: sK=1 (lK=0) or lK=1 (sK=0). Either the latitude or longitude bits can be isolated by applying bit operations or masks.
Mux output 1115 is applied to Masksuffix:S 674 using a bitwise AND operation by gate 1120 to produce output 1125. Depending on which of the two aforementioned values of mux output 1115 is selected, output 1125 will be either Masksuffix:S:lat or Masksuffix:S:lon. Masksuffix:S 674 is also applied to gL⊕gS 1150 using a bitwise AND operation by gate 1130 to produce output 1135. Comparator 1140 performs a bitwise comparison of signals 1125 and 1135 to produce a single-bit output 1145. If signals 1125 and 1135 are equal, then the XOR condition is true and the output 1145 of comparator 1140 is 1; otherwise the XOR condition is false and the output 1145 of comparator 1140 is 0.
Performing a bitwise AND of gL⊕gS with gS will isolate latitude values of gS: {sK, sK+2, sK+4, . . . }:
(gL⊕gS)^gS={00 . . . 0K−1}∥{1K0K+11K+20K+3 . . . }∥{lS . . . lL−1}∥{0L . . . 0N−1}={00 . . . 0K−1}∥{1K^sK0K+1^sK+11K+2^sK+20K+3^sK+3. . . }∥{lS^0S . . . lL−1^0L−1}∥{0L . . . 0N−1}={00 . . . 0K−1}∥{sK0K+1sK+20K+3 . . . }∥{0S . . . 0L−1}∥{0L . . . 0N−1}
Performing a bitwise AND of gL⊕gS with Masksuffix:S (as discussed above with reference to 1130 in
(gL⊕gS)^gL={00 . . . 0K−1}∥{lK0K+1lK+20K+3 . . . }∥{lS+1lS+2lS+3 . . . lL−1}∥{0L . . . 0N−1}
Applying either Masksuffix:S or an inverted version of Masksuffix:T to (gL⊕gS)^gL will generate ((gL⊕gS)^gL)C. Using Masksuffix:T 676 and the signal of latitude/longitude signal of a breakpoint (similar to signal 1105 in
((gL⊕gS)^gL)C={00 . . . 0K−1}∥{lK0K+1lK+20K+3 . . . }∥{0S0S+10S+20S+3 . . . 0L−1}∥{0L . . . 0N−1}
((gL⊕gS)^gL)T={00 . . . 0K−1}∥{0K0K+10K+20K+3 . . . }∥{lS0S+10S+20S+3 . . . 0L−1}∥{0L . . . 0N−1}
((gL⊕gS)^gL)C+T={00 . . . 0K−1}∥{lK0K+1lK+20K+3 . . . }∥{lS0S+1lS+20S+3 . . . 0L−1}∥{0L . . . 0N−1}
As discussed above, if a geohash pair of gS and gL touch each other, there are only two cases: (1) sK=1 and lK=0 or (2) sK=0 and lK=1. In case (2), ((gL⊕gS)^gL)C+T has a single bit of one at K, lK, which is same is BP(gS, gL). By checking the XOR value in circuit 1100, the sK values are known to be satisfied. In case (2), (gL⊕gS)^gS has only a single bit of one at K, sK, but it does not guarantee all ones at {lS, lS+2, . . . } over S. So it is necessary to check if {lS, lS+1, lS+2, . . . } is all ones using ((gL⊕gS)^gL)T.
If sK=1 in case (1), then the rest of ith bits (where i is an integer) in gS nϵ{0,}, between K+2 and K+2n, s·t should be all zeros and ith bits in gL nϵ{0,
}, between K+2 and K+2n, s·t. should be all zeros. Since it is already known that the ith bits of gS and gL between K+2 and K+2n are exclusive to each other, then it is only necessary to check if gL satisfies this condition. It applies to other case (2) as same when 1K=1. The evaluation of the external touch can thus be concluded by simply evaluating only whether (gL)suffix:L:lat/long is equal to BP(gS, gL).
Comparator 1230 determines whether the latitude/longitude version of Masksuffix:T 1215 is equal to ((gL⊕gS)^gL)T 1225. Output 1235 of comparator 1230 will be 1 if the latitude/longitude version of Masksuffix:T 1215 is equal to ((gL⊕gS)^gL)T 1225, and otherwise will be zero. Comparator 1270 determines whether (gL⊕gS)^gS 1205 is equal to BP(gS, gL) 650. Output 1275 of comparator 1270 will be 1 if (gL⊕gS)^gS 1205 is equal to BP(gS, gL) 650, and otherwise will be zero. The aforementioned outputs 1235 and 1275 are combined by AND gate 1280 to produce signal 1285. Signals 1265 and 1285 are processed by OR gate 1290 to produce output signal 1295.
Pseudocode for an exemplary algorithm for performing an external touch operation according to an embodiment of the present invention includes:
gL⊕gS 1150 is combined with gL 765 in AND gate 1320 to produce (gL⊕gS)^gL 1203. gL⊕gS 1150 is combined with gS 725 in AND gate 1330 to produce (gL⊕gS)^gS 1205. Signals 1203 and 1205 are provided as inputs into a module 1200 of the type shown in
Another embodiment of external touch module 687 of the main stage 680 splits latitude and longitude bits with a min-contain operation. For example, assume that breakpoint K is a latitude value. The latitude and longitude of two geohashes gS and gL would then be:
gL:lat={prefix}∥{lKlK+2lK+4 . . . }∥{0L . . . 0N−1}
gS:lat={prefix}∥{sKsK+2sK+4 . . . }∥{0L . . . 0N−1}
gL:long={prefix}∥{lK+1lK+3lK+S . . . lS−1lS . . . }∥{0L . . . 0N−1}
gS:long={prefix}∥{sK+1sK+3sK+5 . . . sS−1}∥{0L . . . 0N−1}
The exact value of gL at the breakpoint K can be found by performing a bitwise AND operation on BP(gS,gL)lat and gL:lat, which only has a valid bit value at K:
BP(gS,gL)lat={0 . . . 0}∥{1K0K+20K+4 . . . }∥{0L . . . 0N−1}
gL:lat={prefix}∥{lKlK+2lK+4 . . . }∥{0L. . . 0N−1}
BP(gS,gL)lat^gL:lat={0 . . . 0}∥{lK0K+20K+4 . . . }∥{0L . . . 0N−1}
Next, by performing a bitwise AND operation on gL:lat and Masksuffix:L:lat, the valid suffix values, {lK, lK+2, lK+4, . . . } can be isolated:
gL:lat={prefix}∥{lKlK+2lK+4 . . . }∥{0L . . . 0N−1}
Masksuffix:L:lat={0 . . . 0}∥{1K1K+21K+4 . . . }∥{0L . . . 0N−1}
gL:lat^Masksuffix:L:lat={0 . . . 0}∥{lKlK+2lK+4 . . . }∥{0L . . . 0N−1}
As previously discussed, there are only two possible cases depending on lK/sK value to touch externally in latitude dimension:
Accordingly, if one geohash region pushes toward other, there are only two possible conditions for {lK, lK+2, lK+4, . . . }:
IN Case (1), IF:
{00 . . . 0K−1}∥{lKlK+2lK+4 . . . }∥{0L . . . 0N−1}={00 . . . 0K−1}∥{0K1K+21K+4 . . . }∥{0L . . . 0N−1}
THEN gL pushes towards gS.
IN Case (2), IF:
{00 . . . 0K−1}∥{lKlK+2lK+4 . . . }∥{0L . . . 0N−1}={00 . . . 0K−1}∥{1K0K+20K+4 . . . }∥{0L . . . 0N−1}
THEN gL pushes towards gS
Likewise, if one geohash region pushes toward other, there are only two possible conditions for {sK, sK+2, sK+4 . . . }:
IN Case (1), IF:
{00 . . . 0K−1}∥{sKsK+2sK+4 . . . }∥{0L . . . 0N−1}={00 . . . 0K−1}∥{1K0K+20K+4 . . . }∥{0L . . . 0N−1}
THEN gS pushes towards gL.
IN Case (2), IF:
{00 . . . 0K−1}∥{sKsK+2sK+4 . . . }∥{0L . . . 0N−1}={00 . . . 0K−1}∥{0K1K+21K+4 . . . }∥{0L . . . 0N−1}
THEN gS pushes towards gL.
In either Case (1) or Case (2), the regions must also satisfy both gL:lat and gS:lat in latitude dimension:
IF (BP(gS,gL)lat^gL)lat=0)
AND (gL:lat^Masksufflx:L:lat+BP(gS,gL)lat=Masksuffix:L:lat)
AND (gS:lat^Masksuffix:S:lat=BP(gS,gL)lat)
In longitude dimension, one can consider that is gL:long contains gS:long. gL:long and gS:long should stay overlapped with each other with no splitting in longitude dimension. So it can be decided by reusing contain operation previously described, but with different size of geohashes because it only considers part of the full geohash. Interleaving of the geohash starts from longitude, so an example operation to calculate sizes of latitude and longitude from the original size of the geohash is:
gA size=7 bits (4 bits for longitude+3 bits for latitude)
gA size=0111=7
gA:lat size=011
1=3
gA:long size=011+1=4
The size of latitude can be obtained by shifting one bit right, and the size of longitude can be done by adding the shifted end bit. With given latitude or longitude geohash data values and size values, the contain operation can be performed. Thus, external touch can be determined by checking if two geohashes push towards each other in one dimension and if they are in contain in other dimension.
Mux outputs 1435 and 1445 are provided as inputs to a one-dimensional push check module 1450 and a mini-contain module 1460. Mux output 1435 is coupled to a lower input of one-dimensional push check module 1450 and an upper input of mini-contain module 1460, while mux output 1445 is coupled to an upper input of one-dimensional push check module 1450 and a lower input of mini-contain module 1460.
One-dimensional push check module 1450 receives additional inputs latitude/longitude select signal 1105 and BP(gS, gL) 650, and generates a single-bit output 1455, according to the following pseudocode:
IF (BP(gS,gL)lat^gL:lat=0)
AND (gL:lat^Masksuffix:L:lat+BP(gS,gL)lat=Masksuffix:L:lat)
AND (gS:lat^Masksuffix:S:lat=BP(gS,gL)lat)
Mini-contain module 1460 receives additional inputs gS:size 745 and gL:size 785, and generates a single-bit output 1465. Mini-contain module 1460 is similar to contain module 685 discussed above, except that mini-contain module 1460 only operates on bits filtered to only include either longitude or latitude.
Outputs 1455 and 1465, respectively generated by one-dimensional push check module 1450 and mini-contain module 1460 are combined using a bitwise AND operation in gate 1470 to produce signal 1475, which in turn is combined with the inverse of the contain signal 550, generated by contain module 685 of main stage 680, using a bitwise AND operation in gate 1480 to produce output 570 of external touch module 687 of main stage 680.
There are only limited cases for corner touch. After the breakpoint, the regions defined by the two geohashes push toward each other in two directions, vertical and horizontal, at same time, i.e. in the diagonal direction on grid. Thus, they must be in accordance with one of these two bit patterns:
Pattern (a):
gS=< . . . >∥<1K1K+10K+20K+30K+40K+5 . . . 0S−20S−1>∥< . . . >
gL=< . . . >∥<0K0K+11K+21K+31K+41K+51K+6 . . . 1L−20L−1>∥< . . . >
Pattern (b):
gS=< . . . >∥<0K1K+11K+20K+31K+40K+5 . . . 0S−21S−1>∥< . . . >
gL=< . . . >∥<1K0K+10K+21K+30K+41K+50K+6 . . . 1L−20L−1>∥< . . . >
As was described earlier for the external touch, bit values for latitude and longitude can be considered separately. For the corner touch, the condition for pushing towards should hold for both directions:
sK+2=sK+4= . . . =
sK+3=sK+5= . . . =
AND
lK+2=lK+4= . . . =
lK+3=lK+5= . . . =
Considering the entire geohash strings at once, there are only two particular bit patterns at the suffix strings. (a) If one of them, for example, gS has <1,1> at {K, K+1}, then it should have all zeros for the remainder of the suffix string; while the other, gL, should have <0,0> at {K, K+1} and all ones afterwards. (b) If gS has <0,1> at {K, K+1} then it should keep continuing <1,0> behind K+1, and the other should have the inverse of this pattern.
By shifting left and then right to cancel prefix bits at [0,K) and invalid bits at [S or L, N), only the suffix regions are left for gS and gL. Next, the valid bit strings left after shifting are checked to match to the same length of constants given, such as 11000 . . . (2), 001111 . . . (2), 011010 . . . (2), or 100101 . . . (2). If one of the cases holds, then the regions defined by the two input geohashes touch at a corner.
If two geohash regions touch at their corner, they push toward each other in both dimensions, latitude and longitude. Thus, an illustrative embodiment can detect corner touch by adopting similar conditions from external touch for both latitude and longitude to push towards each other:
gL={l0l1 . . . lK−1}∥{lKlK+1 . . . lS−2lS−1}∥{lS . . . lL−2lL−1}∥{0L . . . 0N−1}
gS={s0s1 . . . sK−1}∥{sKsK+1 . . . sS−2sS−1}∥{0S . . . 0L−20L−1}∥{0L . . . 0N−1}
lK≠lK+2=lK+4=lK+6= . . . =sK
sK≠sK+2=sK+4=sK+6= . . .
lK+1≠lK+3=lK+5=lK+7= . . . =sK+1
sK+1≠sK+3=sK+5=sK+7= . . .
Therefore, these two geohashes should be in this form:
gL={prefix}∥{xy
gS={prefix}∥{
There are only two cases depending on a bit at a breakpoint of each geohash for latitude or longitude:
Corner touch can be decided by checking if the geohash pair is in one of these cases. Using suffix masks, gS transforms to the following form:
gS0={00 . . . 0K−1}∥{sKsK+2sK+3 . . . sS−2sS−1}∥{0S . . . 0N−1}
gS1={10 . . . 1K−1}∥{sKsK+2sK+3 . . . sS−2sS−1}∥{1S . . . 1N−1}
gS is then split into a set of latitude only and longitude only data. Note that in case (A-1) presented above, inverting one sK bit makes all zeros in gS0:lat.
gS0:lat={0 . . . 0}∥{sKsK+2sK+4sK+6 . . . }∥{0 . . . 0}
gS0:long={0 . . . 0}∥{sK+1sK+3sK+5sK+7 . . . }∥{0 . . . 0}
BP(gS,gL)={0 . . . 0}∥{1K000 . . . }∥{0 . . . 0}
BP′(gS,gL)={0 . . . 0}∥{1K1K+100 . . . }∥{0 . . . 0}
Each bit of BP′(gS,gL) 1605 (e.g., b0 1601) is used to switch a multiplexer (e.g., 1610) having a corresponding bit of gS0 1525 (e.g., s0 1611) coupled to a 0 input and the inverse of that bit of gS0 1525 (e.g., s′0 1621) coupled to a 1 input. Thus, when a kth bit, bk, in BP′(gS,gL) 1605 is 0, a multiplexer (e.g., 1610) just returns Sk (e.g., 1611) as output (e.g., 1615), while an active 1 as a kth bit in BP′(gS,gL) 1605 causes Sk to be inverted and returns S′k (e.g., 1621) as output (e.g., 1615). The multiplexer outputs (e.g., 1615-1645) are rejoined to form signal 1650. Signal 1650 is then split into latitude 1656 and longitude 1657, each of which is coupled to a respective NOR gate 1660, 1670 to form a corresponding output 1665, 1675. Output 1665 will be 1 if
It is similar for gL, but with ones instead of zeroes:
gL0={00 . . . 0K−1}∥{lKlK+2lK+3 . . . lL−2sL−1}∥{0L . . . 0N−1}
gL1={10 . . . 1K−1}∥{lKlK+2lK+3 . . . lL−2lL−1}∥{1L . . . 1N−1}
From gL1 above, taking only latitude makes the form below such that inverting one lK bit causes gL1:lat to have all ones:
gL1:lat={1 . . . 1}∥{lKlK+2lK+4lK+6 . . . }∥{1 . . . 1}
gL1:long={1 . . . 1}∥{lK+1lK+3lK+5lK+7 . . . }∥{1 . . . 1}
Combining Case(A-1), Case(A-2), Case(B-1), and Case(B-2) results in a corner touch:
(Case(A-1) or Case(A-2)) and (Case(B-1) or Case(B-2))=corner touch
IF ((gS0:lat and gL1:lat) or (gS1:lat and gL0:lat)) and ((gS0:long and gL1:long) or (gS1:long and gL0:long))
THEN gS and gL touch each other in the corner
ELSE gS and gL do not touch each other in the corner
Masksuffix:L 675 is applied to gL 765 by apply mask module 1815. Apply mask module 1815 is structurally and functionally similar to module 1500, but is coupled to different inputs and therefore produces different outputs. Specifically, apply mask module produces gL0 1825, which is coupled to a zeros check module 1816, and gL1 1845, which is coupled to a ones check module 1817. Zeros check module 1816 and ones check module 1817 are structurally and functionally similar to modules 1600 and 1700, respectively, but are coupled to different outputs and therefore different outputs. However, BP′(gS,gL) 1605 is coupled to modules 1816 and 1817 as well as 1600 and 1700. Zeros check module 1816 produces outputs 1865 and 1875, and ones check module produces outputs 1885 and 1895.
A naive software implementation would be bit-serial, in that the input geohashes would be processed bit by bit. While hardware approaches can process all geohash bits in parallel using custom circuitry as discussed above, doing so in software would prove to be inefficient and slow. Embodiments of the present invention provide methods to evaluate spatial primitives on geohash pairs while processing all geohash input bits in parallel, thereby avoiding the serial bottleneck. The spatial primitives are contain, and touch (internal, external, corner).
In order to achieve the most performance benefits, each developed routine frequently makes use of vector-wide bit level operations, namely shift left/right, AND, OR, and XOR. The general function flow comprises (1) restructuring data for the following steps (2) generating bit masks (3) processing the restructured data using the generated masks to check for certain conditions (depending on the spatial primitive). The actual order of the aforementioned steps may be different depending on the spatial primitive at hand, and/or may have more stages.
The input to the spatial primitive evaluation functions is a pair of geohashes (gA and gB), each of which represented using an N-bit vector, alongside respective actual geohash sizes (A and B). A first step (corresponding to preprocessing stage 620 in the hardware implementation) is to identify which of the geohashes is the shorter one (gS), and conversely the longer one (gL). This may be achieved using the following algorithm:
When given inputs of a shorter and longer geohashes and their sizes, gS, gL, S, and L, func_contain returns true if gS contains gL, otherwise false. Exemplary pseudocode follows:
In line 3, func_contain generates a mask by left-shifting a constant of N-bits of ones by N-S, as shown in
After left shifting in line 3, the result will be a binary number as follows:
Maskshort={1θ11 . . . 1K−21K−1}∥II {θSθL−2θL−1}∥{θL . . . θN−1}
Software programming supports basic bit level logic operations, such as AND, OR, and XOR. So line 6 of func_contain applies XOR to gS and gL and then performs an AND operation with Maskshort, applying a bitmask to isolate the prefix:
(gL⊕gS)^Maskshort={l0⊕s0 . . . lS−1⊕sS−1}∥{0S . . . 0L−1}∥{0L . . . 0N−1}
As shown in lines 9-12, if this result is all zeroes, then func_contain returns true meaning gS contains gL, otherwise func_contain returns false meaning gS does not contain gL.
Exemplary pseudocode for a software implementation of touch internal follows:
All three touch operations use the result of func_contain result. Internal touch can only exist where gS contains gL, while external touch and corner touch can only exist where gS does not contain gL. More particularly, external touch and corner touch require that gS and gL do not overlap except at an edge or a corner. Thus, func_touch_in checks the result of func_contain in line 3, and only proceeds with additional processing if contain is true in line 6. If contain is false in line 6, then func_touch_in merely returns false in line 18.
When contain is true for two geohashes in line 6, lines 8-11 generate necessary masks maskshort, masksuffix:T:lat, masksuffix:T:lon using shift operations. (This functionality is similar to that discussed above with reference to mask generation stage 660 of the hardware implementation.) To handle latitude bits and longitude bits separately, lines 10 and 11 use two constants of interleaving ones and zeros in a different order. For longitude bits, the constant starts with one (1) then zero (0), and for latitudes, the constant starts with zero (0) then one (1):
Constantlong={10011203 . . . 1i−20i−11i0L+1 . . . }
Constantlat={00110213 . . . 0i−21i−10i1L+1 . . . }
Moreover, touch operations are relations of suffixes, so the inverse mask of maskshort is applied in lines 10-11 to isolate the suffix region of the geohash codes. As shown in lines 14-15, to check if all latitude or longitude bits are ones, func_touch_in compares gL & masksuffix:T:lat(or lon) with the masksuffix:lat. To check for all zero bits on latitude or longitude, func_touch_in compares gL & Masksuffix:T:lat(or lon) with one or more zeros (0).
The fundamental concepts used by a software algorithm for touch external operation are similar to those discussed above with reference to a hardware implementation. When the breakpoint K is a latitude value:
gL:lat={prefix}∥{lKlK+2lK+4 . . . }∥{0L . . . 0N−1}
gS:lat={prefix}∥{sKsK+2sK+4 . . . }∥{0L . . . 0N−1}
gL:long={prefix}∥{lK+1lK+3lK+S . . . lS−1lS . . . }∥{0L . . . 0N−1}
gS:long={prefix}∥{sK+1sK+3sK+5 . . . sS−1}∥{0L . . . 0N−1}
The latitude values should therefore be either:
At the same time, the longitude of gS should a prefix of gL, such as containing:
sK+1=lK+1,sK+3=lK+3,sK+5=lK+5, . . . si<S=li<S.
(for all i=K+2m+1<S, such as m is a positive integer)
Exemplary pseudocode for a software implementation of touch external follows:
As previously noted, external touch can only exist where gS does not contain gL. Thus, func_touch_ex checks the result of func_contain in line 3, and only proceeds with additional processing if contain is false in line 6. If contain is true in line 6, then func_touch_ex merely returns false in line 29.
The result of bit-wised xor(gS, gL) (or gL⊕gS) performed in line 9 has its first one (1) bit at the breakpoint K. The function func_find_breakpoint called in line 12 is analogous to the breakpoint identification stage 640 in the hardware implementation discussed above. Specifically, func_find_breakpoint finds the first nonzero position, leading zeros, from xor(gS, gL), and returns two outputs, K and BP(gS, gL), breakpoint. This function can be implemented in different ways, with one example being:
////example codes of
//(K, breakpoint)=func_find_breakpoint(gSxorgL)
0: K=_builtin_clzl(gSxorgL)
1: breakpoint=0x8000000000000000>>K;
Note that _builtin_clzl( ) is a gcc (GNU C Compiler) built-in function that potentially makes use of processor assembly instructions. The purpose of _builtin_clzl( ) is to count the leading zeros in a bit vector. This example assumes N is 64, and the breakpoint is thus generated by left-shifting a 64 bit hexadecimal constant number 0x8000000000000000 by K, which is 10000000 . . . (2) in binary numbering system.
Next, using N, S and K, func_touch_ext at lines 14-18 generates multiple masks needed. Then, depending on whether the breakpoint K is located at latitude or longitude, func_touch_ex at lines 20-23 generates a constant selectlatlong. Using these masks and input variables provided thereto, func_touch_ex at line 26 checks three binary results returned by each of three functions: xorcheck, case1 and case2. When xorcheck is true and either case1 or case2 is also true, then func_touch_ex returns true at line 27. Otherwise, func_touch_ex returns false at line 27.
The function xorcheck is analogous similar to the XOR check module 1100 previously described with reference to
gL⊕gS={l0⊕s0 . . . lK−1⊕sK−1}∥{lK⊕sK . . . lS−1⊕sS−1}∥{lS⊕0S . . . lL−1⊕0L−1}∥{0L . . . 0N−1}
When XORing gS and gL, a prefix region by K−1 is all zero, and all latitude values at {K, K+2, K+4, . . . } are ones, all longitude values at {K+1, K+3, K+5,} are zeros, and {lS, . . . lL−1} remain at the backend:
gL⊕gS={00 . . . 0K−1}∥{1K0K+11K+20K+3 . . . 1(0)S−2}∥{l5 . . . lL−1}∥{0L . . . 0N−1}
Here, xor(gL,gS) must have a pattern of {1 0 1 0 . . . } at the range between K and S−1. By masking xor(gL,gS) using masksuffix:S, the aforementioned range is isolated.
Exemplary pseudocode for a software implementation of xorcheck follows:
The function case1 and case2 respectively correspond to the cases below:
Exemplary pseudocode for a software implementation of case1 follows:
The first portion of line 6 of easel checks if the lower bits of xor(gL,gS)&gL is same as the breakpoint, which means sK=1 and the rest of bits from sK+2 are zeros:
(gL⊕gS)^gS={00 . . . 0K−1}∥{1K0K+11K+20K+3 . . . }∥{lS . . . lL−1}∥{0L . . . 0N−1}={00 . . . 0K−1}∥{1K^sK0K+1^sK+11K+2^sK+20K+3^sK+3 . . . }∥{lS^0S . . . lL−1^0L−1}∥{0L . . . 0N−1}={00 . . . 0K−1}∥{sK0K+1sK+20K+3 . . . }∥{0S . . . 0L−1}∥{0L . . . 0N−1}
The second portion of line 6 of easel checks whether the remaining suffix of the longer geohash beyond S is still at the edge.
Exemplary pseudocode for a software implementation of case2 follows:
Lines 5-8 of case2 generates (xor(gL,gS)&gL)C+T as discussed above with reference to
xor(gL,gS)&gL={00 . . . 0K−1}∥{lK0K+1lK+20K+3 . . . }∥{lSlS+1lS+2lS+3 . . . lL−1}∥{∥0L . . . 0N−1}
Using an masksuffix:T and the sellatlong, line 3 of case2 makes a latitude/longitude version of masksuffix:T, sellatlong:suffix:T. At lines 5-6 of case2, sellatlong:suffix:T and maskshort are applied to xor(gL,gS)&gL to generate (xor(gL,gS)&gL)C and (xor(gL,gS)&gL)T):
(xor(gL,gS)&gL)C={00 . . . 0K−1}∥{lK0K+1lK+20K+3 . . . }∥{0S0S+10S+20S+3 . . . 0L−1}∥{0L . . . 0N−1}
(xor(gL,gS)&gL)T={00 . . . 0K−1}∥{0K0K+10K+20K+3 . . . }∥{lS0S+1lS+20S+3 . . . 0L−1}∥{0L . . . 0N−1}
Adding these two variables at line 8 of case2 generates (xor(gL,gS)&gL)C+T, which only remains valid values of {lK, lK+2, lK+4, . . . }:
(xor(gL,gS)&gL)C+T={00 . . . 0K−1}∥{lK0K+1lK+20K+3 . . . }∥{lS0S+1lS+20S+3 . . . 0L−1}∥{0L . . . 0N−1}
Thus, case2 returns true at line 9 only if this value is the same as breakpoint, otherwise case2 returns false at line 11.
Exemplary pseudocode for a software implementation of corner touch follows:
Like func_touch_ex, func_touch_corner first checks func_contain at line 3 and performs further processing only if it returns false at line 6. If func_contain returns true, func_touch_corner immediately returns false at line 34.
For func_touch_corner to be true, there are only four possible cases for gS and gL pair. These geohashes can have different lengths, but their bit patterns are strictly fixed:
gL={l0l1 . . . lK−1}∥{lKlK+1 . . . lS−2lS−1}∥{lS . . . lL−2lL−1}∥{0L . . . 0N−1}
gS={s0s1 . . . sK−1}∥{sKsK+1 . . . sS−2sS−1}∥{0S . . . 0L−20L−1}∥{0L . . . 0N−1}
lK≠lK+2=lK+4=lK+6= . . . =sK
sK≠sK+2=sK+4=sK+6= . . .
lK+1≠lK+3=lK+5=lK+7= . . . =sK+1
sK+1≠sK+3=sK+5=sK+7= . . .
Therefore, these two geohashes should be in the form:
gL={prefix}∥{xy
gS={prefix}∥{
There are only two cases depending on a bit at a breakpoint of each geohash for latitude or longitude:
Corner touch can be decided by checking if the geohash pair is in one of these cases. Therefore, func_touch_corner isolates a specific region of . . . ∥{x y
To transform the constants and two geohashes into the proper form to be compared, func_touch_comer at lines 17-21 cuts off constant values into L-K or S-K bits, as shown in
Therefore, cut_interest basically performs mask operations as shown below:
The gS and gL should be shifted to match the bit locations gS and gS:new shown in
An excerpt of an exemplary cut_prefix includes:
////example codes of
//gS:new=cut_prefix(gS);
0: gS:new=Shift left gS by (N−K);
1: return gS:new;
Lines 27-32 of func_touch_corner determine whether the targeted bit locations of the geohashes match any of four cases enumerated above, and if so func_touch_corner returns true. Otherwise, func_touch_corner returns false at line 34.
The inventors named herein have actually reduced the invention to practice. Specifically, the inventors have developed and tested embodiments of both the hardware implementation discussed in Section II and the software implementation discussed in Section III. (The inventors have not patented, described in a printed publication, offered for sale, or otherwise made these embodiments available to the public prior to the filing of the present application.) The inventors compared the performance of a hardware embodiment and a software embodiment of the present invention relative to each other, and also relative to software using conventional techniques to evaluate spatial predicates using DE-9IM.
Experimental results indicate that both hardware-based and software-based embodiments of the present invention provided significant performance improvements relative to the best known prior art. For example, when employing FPGAs for exploiting the bit-level granularity of geohash codes, experimental results show end-to-end speedup of more than 20× and 90× over highly optimized single-threaded DE-9IM implementations of the contain and touch predicates, respectively.
The target board employed for this project was the ADM-PCIE-7v3 board commercially available from Alpha Data Inc. The board was coupled to a Virtex® 7 FPGA (XC7VX690T-2) commercial available from Xilinx, Inc. The inventors connected the board to a host via 8 lanes of PCIe® (Peripheral Component Interconnect Express) Gen. 3, using the driver and PCIe® core provided by Alpha Data, Inc. In order to simplify development, the inventors implemented the proposed processing core using Vivado® High-Level Synthesis (HLS) 2015.2 commercially available from Xilinx, Inc. Vivado® 2015.2 was also used for bitstream generation. An embodiment of the core takes as input two geohash codes (with respective size fields) and produces four output bits per input pair (contain, touch internal, touch external, touch corner). The generated core was connected to the Alpha Data PCIe® engine via an AXI-Stream interface, and runs at 250 MHz. End-to-end performance is reported, which includes data transfer time to and from the host's main memory. The predicates evaluation core operates in a fully pipelined manner, and does not make use of the on-board memory. Virtex® and Vivado® are registered trademarks of Xilinx, Inc. PICe® and PCI Express® are registered trademarks of PCI-SIG Corp.
The inventors used the C programming language and the GNU C Compiler to develop a software-based embodiment of the present invention which performed optimized geohash-based spatial predicates evaluation. The software was executed on a single socket 8-core high-end Intel® Xeon® processor with a 24 MB cache, running at 2.6 GHz, coupled with 256 GB of main memory. Performance is reported with input and output data being in main memory. Intel® and Xeon® are registered trademarks of Intel Corp.
The aforementioned hardware and software embodiments of the present invention were compared with the closest known prior art: state-of-the-art software employing DE-9IM for predicate evaluation within the IBM® Streams and SPSS® software packages commercially available from the assignee of the present invention, International Business Machines Corp. IBM® and SPSS® are registered trademarks of International Business Machines Corp. The software was executed on a single socket 8-core high-end Intel® Xeon® processor with a 24 MB cache, running at 2.6 GHz, coupled with 256 GB of main memory. Performance is reported with input and output data being in main memory.
Since the performance of the hardware and software solutions discussed above is mostly agnostic to the properties of the input data (i.e. whether or not regions contain/touch), the experiments described herein used of synthetic datasets. Geohashes were represented using 64-bits (actual geohash size could be less), while latitude/longitude are represented using double precision (64-bit) floating point each. Regions were defined using a single 64-bit geohash (for the inventive geohash-based embodiments), or 2 latitude and 2 longitude points (for the commercially-available DE-9IM software). Performance is reported in MPairs/sec, referring to the millions of pairs of regions that can be processed per second (evaluating spatial predicates).
The performance of an embodiment of the present invention was evaluated utilizing FPGA hardware for predicate evaluation using batches of varying sizes. Here, a batch consists of pairs of 64-bit geohash codes that start off by residing on the host's main memory.
As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.
One or more embodiments of the invention, or elements thereof, can be implemented in the form of an apparatus including a memory and at least one processor that is coupled to the memory and operative to perform exemplary method steps.
One or more embodiments can make use of software running on a general purpose computer or workstation which, when configured according to one or more embodiments of the invention, becomes a special-purpose apparatus. With reference to
Accordingly, computer software including instructions or code for performing the methodologies of the invention, as described herein, may be stored in one or more of the associated memory devices (for example, ROM, fixed or removable memory) and, when ready to be utilized, loaded in part or in whole (for example, into RAM) and implemented by a CPU. Such software could include, but is not limited to, firmware, resident software, microcode, and the like.
A data processing system suitable for storing and/or executing program code will include at least one processor 2302 coupled directly or indirectly to memory elements 2304 through a system bus 2310. The memory elements can include local memory employed during actual implementation of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during implementation.
Input/output or I/O devices (including but not limited to keyboards 2308, displays 2306, pointing devices, and the like) can be coupled to the system either directly (such as via bus 2310) or through intervening I/O controllers (omitted for clarity).
Network adapters such as network interface 2314 may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters.
As used herein, including the claims, a “server” includes a physical data processing system (for example, system 2312 as shown in
As noted, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon. Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. Media block 2318 is a non-limiting example. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any non-transitory medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that at least a portion of one or more modules of the flowchart illustrations and/or block diagrams, and combinations of modules in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved and/or the specific application in which the method is employed. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
It should be noted that any of the methods described herein can include an additional step of providing a system comprising distinct software modules embodied on a non-transitory computer readable storage medium; the modules can include, for example, any or all of the elements depicted in the block diagrams and/or described herein; by way of example only and without limitation, an equal operator, a subtraction operator, a shift-right-by-one operator, a shift-left-by-one operator, an adder, a divide-by-two operator and a multiplexer. The method steps can then be carried out using the distinct software modules and/or sub-modules of the system, as described above, executing on one or more hardware processors 2302. Further, a computer program product can include a non-transitory computer-readable storage medium with code adapted to be implemented to carry out one or more method steps described herein, including the provision of the system with the distinct software modules.
In any case, it should be understood that the components illustrated herein may be implemented in various forms of hardware, software, or combinations thereof for example, application specific integrated circuits (ASICs), functional circuitry, one or more appropriately programmed general purpose digital computers with associated memory, and the like. Given the teachings of the invention provided herein, one of ordinary skill in the related art will be able to contemplate other implementations of the components of the invention.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms “a,” “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. The embodiment was chosen and described in order to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.
| Number | Name | Date | Kind |
|---|---|---|---|
| 8715088 | Kohlhoff | May 2014 | B2 |
| 8938686 | Erenrich et al. | Jan 2015 | B1 |
| 20120233210 | Bogosian | Sep 2012 | A1 |
| 20130013661 | Inakoshi et al. | Jan 2013 | A1 |
| 20130054647 | Terauchi | Feb 2013 | A1 |
| 20130097163 | Oikarinen et al. | Apr 2013 | A1 |
| 20140280318 | Simms et al. | Sep 2014 | A1 |
| 20150046086 | Krauss | Feb 2015 | A1 |
| 20150052154 | Krauss | Feb 2015 | A1 |
| 20150095333 | Porpora et al. | Apr 2015 | A1 |
| 20150215409 | Chow et al. | Jul 2015 | A1 |
| Entry |
|---|
| R. Moussalli et al., “Fast and Flexible Conversion of Geohash Codes to and from Latitude/Longitude Coordinates,” 23rd Annual International IEEE Symposium on Field-Programmable Custom Computing Machines (FCCM 2015), May 2015, p. 179-186, Institute of Electrical and Electronics Engineers (IEEE). |
| C. Strobl, “Dimensionally Extended Nine-Intersection Model (DE-9IM),” in Encyclopedia of GIS (S. Shekhar & H. Xiong, eds.), 2008, p. 240-245, Springer Science+Buisiness Media. |
| A. Fox et al., “Spatio-temporal Indexing in Non-relational Distributed Databases,” 2013 IEEE International Conference on Big Data, Oct. 2013, p. 291-299, Institute of Electrical and Electronics Engineers (IEEE). |
| J. Fender et al., “A High-speed Ray Tracing Engine Built on a Field-Programmable System,” 2003 IEEE International Conference on Field-Programmable Technology (FPT), Dec. 2003, p. 188-195, Institute of Electrical and Electronics Engineers (IEEE). |
| J. Schmittler et al., “Realtime Ray Tracing of Dynamic Scenes on an FPGA Chip,” Proceedings of the ACM SIGGRAPH/Eurographics Conference on Graphics Hardware (GH '04), Aug. 2004, p. 95-106, Association for Computing Machinery (ACM). |
| M. Woulfe et al., “Hardware Accelerated Broad Phase Collision Detection for Realtime Simulations,” 4th Workshop in Virtual Reality Interactions and Physical Simulation (VRIPHYS), 2007, 10 pages, The Eurographics Association. |
| H. Hussain et al., “An Adaptive FPGA Implementation of Multi-Core K-Nearest Neighbour Ensemble Classifier Using Dynamic Partial Reconfiguration,” 22nd International Conference on Field Programmable Logic and Applications (FPL 2012), Aug. 2012, p. 627-630, Institute of Electrical and Electronics Engineers (IEEE). |
| E.S. Manolakos et al., “Flexible IP Cores for the k-NN Classification Problem and Their FPGA Implementation,” 2010 IEEE International Symposium on Parallel & Distributed Processing, Workshops and Phd Forum (IPDPSW), Apr. 2010, p. 1-4, Institute of Electrical and Electronics Engineers (IEEE). |
| L. Woods et al., “Complex Event Detection at Wire Speed with FPGAs,” Proceedings of the VLDB Endowment, Sep. 2010, v. 3, n. 1-2, p. 660-669, VLDB Endowment. |
| R. Moussalli et al., “Stream-Mode FPGA Acceleration of Complex Pattern Trajectory Querying,” in Advances in Spatial and Temporal Databases, 13th International Symposium (SSTD 2013), Aug. 2013, Lecture Notes in Computer Science (LNCS) 8098, Springer-Verlag. |
| R. Moussalli et al., “High Performance FPGA and GPU Complex Pattern Matching Over Spatio-Temporal Streams,” GeoInformatica, Apr. 2015, v. 19, n. 2, p. 405-434, Springer Science+Buisiness Media. |
| ESRI (Environmental Systems Research Institute), “Understanding spatial relations,” as of Mar. 4, 2016, 14 pages, http://edndoc.esri.com/arcsde/9.0/general_topics/understand_spatial_relations.htm. |
| Wikipedia,“DE-9IM,” as of Mar. 4, 2016, 13 pages, https://en.wikipedia.org/w/index.php?title=DE-9IM&printable=yes. |
| geohash.org, “Tips & Tricks,” as of Mar. 4, 2016, 3 pages, http://geohash.org/site/tips.html. |
| Wikipedia, “Geohash,” as of Mar. 4, 2016, 7 pages, https://en.wikipedia.org/w/index.php?title=Geohash&printable=yes. |
| Alpha Data, “ADM-PCIE-7V3,” as of Mar. 4, 2016, 2 pages, http://www.alpha-data.com/dcp/products.php?product=adm-pcie-7v3. |
| MongoDB, Inc., “MongoDB Manual 3.2: Geospatial Indexes and Queries,” as of Mar. 4, 2016, 2 pages, https://docs.mongodb.org/manual/applications/geospatial-indexes/. |
| Oracle Corporation, “MySQL 5.7 Reference Manual 12.15.10 Spatial Geohash Functions,” as of Mar. 4, 2016, 3 pages, http://dev.mysql.com/doc/refman/5.7/en/spatial-geohash-functions.html. |
| International Business Machines (IBM), “IBM Streams,” as of Mar. 4, 2016, 2 pages, http://www-03.ibm.com/software/products/en/ibm-streams. |
| International Business Machines (IBM), “IBM SPSS software,” as of Mar. 4, 2016, 3 pages, http://www-01.ibm.com/software/analytics/spss/. |
| V. Singala, “Finding Nearest Location with Open Box Query using Geohashing and MapReduce,” Thesis for Master of Engineering, Jul. 2013, Computer Science and Engineering Department, Thapar University, Patiala, India. |
| Moussalli et al., “Enhanced Conversion Between Geohash Codes and Corresponding Longitude Latitude Coordinates,” U.S. Appl. No. 14/669,715, filed Mar. 26, 2015, not yet published, 43 pages. |
| Number | Date | Country | |
|---|---|---|---|
| 20170277717 A1 | Sep 2017 | US |
