public class GISStore extends Object
This is a placeholder for a GIS design. While GIS systems are typically R-trees, I am considering an approach that leverages the existing scale-out B+-Tree architecture using a design similar in many ways to the triple store.
There would be a feature dictionary with a foward and reverse map assigning feature identifiers. The feature identifiers should problably reserve the lower 2-3 bits for coarse coding of broad feature categories so that they may be filtered on those categories without having to resolve them against the feature dictionary - filtering on the feature dictionary is a scattered read.
The core indices would use keys formed as lat, lon, alt, feature.
The feature needs to show up in the key since there can be more than one
feature at the same spatial location. Alternative indices would provide for
different access paths for the same key, but the feature would always appear
in the last key position giving 3 indices (unless scan of all locations for a
feature is common in which case this gives 6 indices, much like a quad
store).
The value for the coordinate indices could either be unusued or could be a row identifier, much like the sid of the triple store, for making metadata statements about a specific {coordinate,feature} tuple. Other flags might also be carried on the value, but note that the value is replicated on each coordinate access path.
If coordinates are entered into the database as of their "event" time then
this design would make it easy to obtain the set of spatial features for a
given moment in time using a historical read for that event time. However,
this is likely to prove difficult when aggregating historical data so the
temporary dimension may also need to enter into the key:
lat, lon, alt, time, feature
I am assuming that latitude, longitude, altitude, and time can all be 64-bit long values assigned from a standard representation such as decimal degrees, meters above/below sea-level, and UTC milliseconds. Equally the (X,Y,Z) could be a polar coordinate system. This is really one level above the data model. Regardless, and unlike the triple store, this means that most of the tuple is directly generated from "natural" units without the aid of a dictionary. Only the feature identifiers are assigned by a dictionary.
Features need to be extensible metadata that can be used to link together the spatial extent of both stationary and moving "objects" (tracks). Features could doubtless be related together in additional ways, e.g., through part-whole relations, either within the GIS or in an external metadata database.
The basic queries would be things such as "Find me all features F of category X within REGION (X,Y,Z) between TIME (T1,T2)." This would be coded as a JOIN of the various coordinate indices with a filter (where appropriate) on the bits coding coarse feature categories within the identifier and a scatter query doing fine-grained filtering against the reverse map of the feature dictionary.
Copyright © 2006–2019 SYSTAP, LLC DBA Blazegraph. All rights reserved.