The Contextual Data Store is used to load features from Oracle within a spatial extent, but also to include additional features that are related to them.
It is used instead of the standard Oracle Data Store to ensure that all of the relevant referenced features required to validate the data are present, particularly for features with no geometry.
The contextual Data Store requires global temporary tables to temporarily record information when the data is being loaded for efficiency. These do not persist any data but are used during the open data task.
You will need to create temporary tables for each table in your schema by using the SQL below, e.g. TID0, TID1, TID2 etc:
CREATE GLOBAL TEMPORARY TABLE TID<table index>(FID VARCHAR2(38));
The Contextual Data Store provides a reader and a writer for loading the features using more complex relationships from an Oracle schema.
It is configured using an XML file called the "load policy" which defines which tables to load and which references to follow in order to load this data.
Load Policy Definitions
primitive-table-hint
primitive-table-hint represents the standard way to load tables, if more complex loading is required then other table-hints may be appropriate. Primitive-table-hint represents the simplest possible file to load data from a single table when no special processing is required:
<schema-hint>
<primitive-table-hint>
<name>EXAMPLE_TABLE_NAME</name>
</primitive-table-hint>
</schema-hint>
Note: A table should not be marked as both primitive and grouped, if this happens duplicate features will be loaded into the session .If you want to load features as primitives and form a group, or load features as primitives via a reference, then add the table only as primitive-with-grouping-table or primitive-with-reference-table to the load policy.
dependent-table-hint
A spatially indexed table that has a reference to another table. Rows in the target table are loaded as separate features when they are referenced from the primitive table.
In the following example, when an object is created from the spatially indexed SPATIALLY_INDEXED_TABLE, the referenced row from OTHER_TABLE will also be loaded and stored in a separate object.
<dependent-table-hint>
<name>OTHER_TABLE</name>
<geometry-table-name>SPATIALLY_INDEXED_TABLE</geometry-table-name>
</dependent-table-hint>
simple-join-table-hint
This specifies a join table used to represent a many-to-many relationship with no attributes. These become references with multiple cardinality (lists of objects). In the example below, EXAMPLE_TABLE has two columns referencing the primary key of two other tables, the Data Store works out which tables are implicated automatically.
<simple-join-table-hint>
<name>EXAMPLE_TABLE</name>
</simple-join-table-hint>
attributed-join-table-hint
Specifies a join table used to represent a many-to-many relationship where each instance of the relationship has its own attributes.
<attributed-join-table-hint>
<name>EXAMPLE_TABLE/name>
</attributed-join-table-hint>
grouping-table-hint
Features grouping other features. These are not loaded spatially but by reference, i.e. groups including any loaded features are automatically loaded. Also, if any features in a group is loaded then all features in that group are loaded. The example below ensures that all referenced features by EXAMPLE_TABLE in the session extent are loaded, even if they are outside the session extent.
Note: A grouped table must not also be specified as a primitive table or duplicate features will be loaded. If you want to load features as primitives and form a group, then add the table only as primitive-with-grouping-table to the load policy.
<grouping-table-hint>
<name>GROUPING_EXAMPLE_TABLE</name>
<join-table>EXAMPLE_JOIN_TABLE</join-table>
</grouping-table-hint>
primitive-with-grouping-table-hint
The example below is similar to grouping-table-hint but will also ensure all features in PRIMITIVE_EXAMPLE_TABLE inside the extent are loaded.
A primitive-with-grouping table must not also be specified as a primitive table or duplicate features will be loaded.
<primitive-with-grouping-table-hint>
<name>PRIMITIVE_GROUPING_EXAMPLE_TABLE</name>
<join-table>EXAMPLE_JOIN_TABLE</join-table>
</primitive-with-grouping-table-hint>
referenced-table-hint
Features referenced by other features. The referenced features are not loaded spatially but by reference i.e. where feature A inside the session extent has a reference to feature B outside the extent it should still load B (as B is being referenced by A). This behaviour is similar to grouping-table-hint but it will NOT load any other features of the same class as A that are referenced from B. The example below ensures that all REFERENCED_EXAMPLE_TABLEs referenced are loaded, even if they are outside the session extent.
Note: A referenced table must not be specified as a primitive table or duplicate features will be loaded. If you want to load features as primitives via a reference, then add the table only as primitive-with-reference-table to the load policy.
<referenced-table-hint>
<name>REFERENCED_EXAMPLE_TABLE</name>
<join-table>EXAMPLE_JOIN_TABLE</join-table>
</referenced-table-hint>
primitive-with-reference-table-hint
The example is similar to referenced-table-hint, and will ensure all features in PRIMITIVE_WITH_REF_EXAMPLE_TABLEs inside the extent are loaded.
Note: A primitive-with-reference table must not be specified as a primitive table or duplicate features will be loaded.
<primitive-with-reference-table-hint>
<name>PRIMITIVE_WITH_REF_EXAMPLE_TABLE</name>
<join-table>EXAMPLE_JOIN_TABLE</join-table>
</primitive-with-reference-table-hint>
out-of-line-table-hint
A feature that adds attributes to another table through a left join. The out-of-line table contains the geometry through which features should be loaded. The following example adds columns from OUT_OF_LINE_EXAMPLE_TABLE to the object created for each feature referenced in the join.
<out-of-line-table-hint>
<name>OUT_OF_LINE_EXAMPLE_TABLE</name>
</out-of-line-table-hint>
extend-load-by-ref
This will ensure that any referenced features are loaded, even if they fall outside of the extent or any buffers applied. This parameter can be particularly useful if a job fails due to incorrectly missing references.
<primitive-table-hint>
<name>ROAD_FEATURES</name>
<extend-load-by-ref>
<name>ROAD</name>
</extend-load-by-ref>
<extend-load-by-ref>
<name>ROAD_MOTORWAY</name>
</extend-load-by-ref>
</primitive-with-reference-table-hint>
post-process-table-hint
Timeslice temporal data can be loaded by executing a <extend-load-sql-statement> within a <post-process-table-hint>.
Multiple <extend-by-sql-statement> hints can be executed within a <post-process-table-hint>. An <id> must be provided for each post-process-table-hint.
Note: This hint should be run in the last loading tasks after all GUIDs have been gathered into all the temporary tables from the other primitive hints.
<post-process-table-hint>
<id>executeSeq1</id>
<name>ABSTRACTAIXMFEATURETYPE</name>
<extend-load-sql-statement>...</extend-load-sql-statement>
...
<extend-load-sql-statement>...</extend-load-sql-statement>
</post-process-table-hint>
<post-process-table-hint>
<id>executeSeq2</id>
<name>ABSTRACTAIXMFEATURETYPE</name>
<extend-load-sql-statement>...</extend-load-sql-statement>
...
<extend-load-sql-statement>...</extend-load-sql-statement>
</post-process-table-hint>
extend-by-sql-statement
Rows can be loaded from one table where the column matches a column in another table.
<type> will support INSERT and DELETE statements.
<filter> is the conditional clause in the sql query.
The <filter> must use the table alias L (for the Loading Table), and P (for the primary table); This will allow the same table to be both the primary and loading tables.
The example below shows that the AIRSPACE_PROPERTY table has a HREF column, and loads the ABSTRACTAIXMFEATURETYPE referenced by the HREF value.
Note: IDENTIFIER holds the value of the HREF, but the first 10 characters of href can be ignored.
<primitive-table-hint>
<name>AIRSPACE_PROPERTY</name>
<extend-by-sql-statement>
<type>INSERT</type>
<load-table>ABSTRACTAIXMFEATURETYPE</load-table>
<filter>L.IDENTIFIER = substr(P.HREF,10,250)</filter>
</extend-by-sql-statement>
</primitive-table-hint>
extend-load-by-proximity
This allows additional features to be loaded from another class if they are within the specified distance from the current class. If <primitive-geometry> is not defined, <locate-geometry> and <load-geometry> can be used multiple times if there are multiple geometry columns in the database table.
In the example below, AIRPORTHELIPORT can also load RUNWAYCENTRELINEPOINT if either the airport centre point or its boundary is within 10KM of a RUNWAYCENTRELINEPOINT's primary geometry.
Note: For performance and avoid duplicates, use temporary tables.
<primitive-table-hint>
<name>AIRPORTHELIPORT</name>
<extend-load-by-proximity>
<locate-geometry>the_airport_centre_geom_column<locate-geometry>
<locate-geometry>the_airport_boundary_geom_column<locate-geometry>
<load-table>RUNWAYCENTRELINEPOINT</load-table>
<within-distance>10000</within-distance>
<load-geometry>a_none_primary_geometry_column</load-geometry> This tag is needed if the geometry column is not the primary_geometry
</extend-load-by-proximity>
<extend-load-by-proximity>
.
.
.
</extend-load-by-proximity>
</primitive-table-hint>
Example Load Policy
The following simple load policy will load data required for pipes, points of interest, flood zones and other connected features.
<schema-hint>
<simple-join-table-hint>
<name>JUNCTIONS_TO_PIPES_JOIN_TABLES</name>
</simple-join-table-hint>
<grouping-table-hint>
<name>SITES</name>
<join-table>JUNCTIONS_TO_PIPES_JOIN_TABLES</join-table>
</grouping-table-hint>
<primitive-table-hint>
<name>POINT_OF_INTEREST</name>
</primitive-table-hint>
<primitive-table-hint>
<name>FLOOD_ZONE</name>
</primitive-table-hint>
<primitive-table-hint>
<name>STREETS</name>
</primitive-table-hint>
</schema-hint>
