Contextual Datastore

The Contextual Datastore 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 datastore to ensure that all of the relevant referenced features required to validate the data are present, particularly for features with no geometry.

Examples of the Contextual Datastore in use would be:

  • If you are checking that a pipe has a logical connection to a valve and the pipe is in the spatial extent, the valve will also be loaded if there is a foreign key or join table reference between them, even if the valve is outside the extent.
  • If a building is referenced by a non-spatial 'building group', which is a collection of other buildings whose membership is defined via a join table, then the referencing 'building group' and all the other members of that group can be loaded if only a single building is within the extent.

Note: This is separate functionality to the 1SMS ability to automatically grow a job extent based on the spatial data. If automatic job growing is enabled then that may be sufficient to load surrounding spatial features.

The Contextual Datastore 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 (the "load policy" that specifies how each table will be loaded), which defines which tables to load and which references to follow in order to load this data.

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 only used during the open data task. The contextual data store is delivered with a script to create these global temporary tables.

Contextual Datastore Parameters

The Contextual Data Store takes the following parameters:

  • Data Store Schema Name: The name of the schema from which data should be read.
  • Datasource JNDI Location: A data source containing temporary tables with read access rights to the schema through which the data will be read.

  • Load Policy URL: A URL to a file defining how the data should be loaded.

    Note: 1Integrate will need to be able to call this file each time the schema is refreshed. Once refreshed, the config file does not need to be accessed at runtime because it is stored in the data store.

Load Policy Definitions

Closedprimitive-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.

Closeddependent-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 ADDRESS_COMMON_COMP table, the referenced row from ROYAL_MAIL_PO_BOX_FEAT will also be loaded and stored in a separate object.

<dependent-table-hint>

<name>ROYAL_MAIL_PO_BOX_FEAT</name>

<geometry-table-name>ADDRESS_COMMON_COMP</geometry-table-name>

</dependent-table-hint>

Closedsimple-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, BOUNDLK_BOUNDARYLI_TA_REF has two columns referencing the primary key of two other tables (in this case BOUNDARY_LINK_FEAT and TOPOGRAPHY_AREA_FEAT, the data store works out which tables are implicated).

<simple-join-table-hint>

<name>BOUNDLK_BOUNDARYLI_TA_REF</name>

</simple-join-table-hint>

Closedattributed-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. In the example below, references between NETWORK_LINK_FEAT and TURN_OR_MANOEUVRE_FEAT have attributes GROUP_ORDER and LINK_DIRECTION, which are loaded as attributes of the intermediate reference object.

<attributed-join-table-hint>

<name>TURNMAN_ORDERTOPO_NL_REF</name>

</attributed-join-table-hint>

Closedgrouping-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 TOPOGRAPHY_AREA_FEATs referenced by FUNCTIONAL_SITE_FEATs in the session extent are loaded, even if they are outside the session extent. It also ensures that all FUNCTIONAL_SITE_FEATs referenced by TOPOGRAPHY_AREA_FEATs in the session extent are loaded.

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>FUNCTIONAL_SITE_FEAT</name>

<join-table>FS_DETAILDEFD_TA_REF</join-table>

</grouping-table-hint>

Closedprimitive-with-grouping-table-hint

The example below is similar to grouping-table-hint but will also ensure all NAMED_WAY_OR_JUNCT_FEATs 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>NAMED_WAY_OR_JUNCT_FEAT</name>

<join-table>NDWYJCT_DETAILDEFD_NL_REF</join-table>

</primitive-with-grouping-table-hint>

Closedreferenced-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 NAMED_WAY_OR_JUNCT_FEATs referenced by NETWORK_LINK_FEATs are loaded, even if NAMED_WAY_OR_JUNCT_FEATs 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>NAMED_WAY_OR_JUNCT_FEAT</name>

<join-table>NDWYJCT_DETAILDEFD_NL_REF</join-table>

</referenced-table-hint>

Closedprimitive-with-reference-table-hint

The example is similar to referenced-table-hint, but will also ensure all NAMED_WAY_OR_JUNCT_FEATs 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>NAMED_WAY_OR_JUNCT_FEAT</name>

<join-table>NDWYJCT_DETAILDEFD_NL_REF</join-table>

</primitive-with-reference-table-hint>

Closedout-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 TURN_OR_MANOEUVRE_PROD to the object created for each TURN_OR_MANOEUVRE_FEAT.

<out-of-line-table-hint>

<name>TURN_OR_MANOEUVRE_PROD</name>

</out-of-line-table-hint>

Closedextend-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>WATER_FEATURES</name>

<extend-load-by-ref>

<name>WATER</name>

</extend-load-by-ref>

<extend-load-by-ref>

<name>WATER_STREAMS</name>

</extend-load-by-ref>

</primitive-with-reference-table-hint>

Example Load Policy

The following simple load policy will load data required for roads, buildings, functional sites and other connected features.

<schema-hint>

<simple-join-table-hint>

<name>FS_DETAILDEFD_TA_REF</name>

</simple-join-table-hint>

<grouping-table-hint>

<name>FUNCTIONAL_SITE_FEAT</name>

<join-table>FS_DETAILDEFD_TA_REF</join-table>

</grouping-table-hint>

<primitive-table-hint>

<name>HISTORIC_SITE_FEAT</name>

</primitive-table-hint>

<primitive-table-hint>

<name>NETWORK_NODE_FEAT</name>

</primitive-table-hint>

<primitive-table-hint>

<name>TOPOGRAPHY_AREA_FEAT</name>

<primitive-table-hint>

</schema-hint>

 

SupportContact Us

Copyright © 2019 1Spatial
US Patent Number 9542416 B2 (2017-01-10)